Cette page décrit les insights de Network Analyzer sur l'utilisation des adresses IP dans Google Kubernetes Engine (GKE). Pour en savoir plus sur tous les types d'insights, consultez la section Groupes et types d'insights.
Afficher les insights dans l'API Recommender
Pour afficher ces insights dans gcloud CLI ou l'API Recommender, utilisez le type d'insight suivant :
google.networkanalyzer.container.ipAddressInsight
Vous devez disposer des autorisations suivantes :
recommender.networkAnalyzerGkeIpAddressInsights.listrecommender.networkAnalyzerGkeIpAddressInsights.get
Pour en savoir plus sur l'utilisation de l'API Recommender pour les insights de Network Analyzer, consultez la section Utiliser la CLI et l'API Recommender.
Allocation élevée de plages de pods GKE
Cet insight indique que l'utilisation de l'adresse IP sur les plages d'adresses des pods d'un cluster GKE est supérieure à 80%. La stratégie d'attribution d'adresses IP pour les pods GKE varie selon que votre cluster a été créé en tant que cluster de VPC natif ou cluster basé sur le routage.
Clusters basés sur le routage
GKE comprend deux types de clusters, caractérisés par la manière dont ils acheminent le trafic d'un pod à un autre. Un cluster qui utilise des routes Google Cloud est appelé cluster basé sur le routage. Pour en savoir plus, consultez la section Créer un cluster basé sur des routes.
Un cluster basé sur le routage possède une plage d'adresses IP utilisables pour les pods et les services. Bien que cette plage soit destinée à la fois aux pods et aux services, elle est désignée par le terme plage d'adresses des pods.
Le dernier /20 de la plage d'adresses des pods est utilisé pour les services. Une plage /20 contient 212 = 4096 adresses. Ainsi, les adresses 4096 sont utilisées pour les services, et le reste de la plage est utilisé pour les pods.
Chaque nœud de la plage d'adresses des pods dispose d'une plage d'adresses IP /24 pour les pods.
Une plage /24 contient 28 = 256 adresses. Rappelez-vous que les adresses 4096 de la plage d'adresses des pods sont utilisées pour les services. La partie restante de la plage d'adresses des pods est utilisée pour les pods et doit être suffisamment grande pour contenir un nombre d'adresses égal au nombre de nœuds multiplié par 256.
Le taux d'allocation pour la plage d'adresses des pods est calculé comme suit:
Par exemple, vous prévoyez de créer un cluster de nœuds 900. Vous avez donc besoin d'adresses 900 x 256 = 230,400 pour les pods. Supposons à présent que vous disposiez d'une plage d'adresses des pods de taille /14. Une plage /14 contient 218 = 262,144 adresses. Soustrayez les adresses 4096 utilisées pour les services, et vous obtenez 258,048, ce qui est suffisant pour les nœuds 900.
Clusters de VPC natif
GKE comprend deux types de clusters, caractérisés par la manière dont ils acheminent le trafic d'un pod à un autre. Un cluster qui s'appuie sur des plages d'adresses IP d'alias est appelé cluster de VPC natif. Pour en savoir plus, consultez la page sur les clusters de VPC natif.
Lorsque vous créez un pool de nœuds dans un cluster de VPC natif, vous sélectionnez une plage d'adresses IP secondaire pour allouer des adresses IP aux pods GKE. Différents pools de nœuds peuvent utiliser des plages secondaires différentes pour allouer des adresses IP de pods. Pour en savoir plus, consultez la page CIDR multi-pods. L'analyseur réseau calcule le taux d'allocation pour chaque plage d'adresses IP secondaire utilisée pour allouer des adresses IP de pod à un cluster donné. Si le taux d'allocation global est supérieur à 80%, vous obtenez un insight élevé sur l'utilisation.
Le taux d'allocation pour une seule plage d'adresses IP secondaire est calculé comme suit:
Par exemple, une plage de pods secondaires /24 peut contenir des pods 256. S'il n'y a qu'un seul nœud 1 avec des pods max_pods_per_node, 110 et 16 par défaut en cours d'exécution, le ratio indique 100% (256/256) au lieu de 6,25% (16/256), car même si les adresses IP des pods 240 ne sont pas utilisées, elles appartiennent toujours à ce nœud. Un autre nœud ne peut être créé avec succès que s'il existe 256 adresses IP de pod inutilisées.
L'allocation globale est calculée comme suit:
Par exemple, si l'adresse IP de pod par défaut et la plage d'adresses IPv4 de pod supplémentaire sont définies sur /22 et qu'il existe 2 pools de nœuds, un pool de nœuds utilise la plage d'adresses IP de pod par défaut et compte 3 nœuds, tandis que le deuxième pool de nœuds utilise une plage d'adresses IP de pod supplémentaire et compte également 3 nœuds, avec un nombre maximal de pods par défaut défini sur 110. Kubernetes attribue une plage CIDR /24 aux nœuds du cluster. Avec 6 nœuds et une plage CIDR /24 allouée, un total de 256 * 6 = 1536 adresses IP est disponible. Cela représente 75% du nombre total d'adresses IP disponibles dans les deux plages d'adresses IP de pod (1024 * 2 = 2048).
Notez que si l'adresse IP secondaire est partagée entre différents clusters, les insights affichent la valeur totale agrégée de tous les clusters. Pour afficher l'utilisation d'une seule plage d'adresses IP de cluster, vous pouvez exécuter gcloud container cluster describe CLUSTER_NAME pour afficher l'état d'utilisation de chaque adresse IP secondaire.
Remplacez CLUSTER_NAME par le nom du cluster.
Articles associés
- Informations sur l'adresse IP des pods de cluster basé sur les routes
- Plage d'adresses IP secondaire du sous-réseau utilisée par les pods
- CIDR multi-pod
Recommandations
- Pour les clusters basés sur le routage, si vous devez créer des pools de nœuds supplémentaires dans ce cluster et que vous manquez d'espace, recréez ce cluster avec une taille de plage d'adresses de pod plus grande.
- Pour les clusters de VPC natif, créez des pools de nœuds futurs avec une plage d'adresses IP de pod plus étendue.
- Réduire le nombre maximal de pods.
- Ajoutez des plages d'adresses IPv4 de pod supplémentaires en utilisant le CIDR multipod pour les clusters Standard et Autopilot.
L'allocation des plages de pods GKE limite l'autoscaling
Cet insight indique que les plages d'adresses IP des pods du cluster ne disposent pas d'assez d'adresses pour permettre la création du nombre maximal de nœuds dans tous les pools de nœuds. La page d'informations de l'insight inclut un tableau qui indique le nombre d'adresses IP de pod actuellement utilisées et le nombre maximal d'adresses IP de pod dans chacune des plages d'adresses IP de pod de votre cluster GKE.
Network Analyzer génère cet insight lorsque la valeur d'utilisation des adresses IP entièrement autoscaling dépasse 100%.
La valeur d'utilisation des adresses IP entièrement autoscalable dépasse 100% lorsque le nombre d'adresses IP de pod requises pour prendre en charge le nombre maximal de nœuds du cluster dépasse le nombre d'adresses IP dans les plages d'adresses IP de pod du cluster. Le nombre maximal de nœuds dans le cluster correspond à la somme du nombre maximal de nœuds dans chaque pool de nœuds du cluster (maxNodeCount).
La valeur d'utilisation des adresses IP entièrement ajustée automatiquement est calculée à l'aide de la formule indiquée dans la section Allocation élevée de plages de pods GKE.
Clusters basés sur le routage
Cet insight est généré lorsque le taux d'allocation de la plage d'adresses des pods est supérieur à 100% et que tous les pools de nœuds sont entièrement soumis à l'autoscaling. Les nœuds GKE ne seront pas créés en raison du manque d'espace d'adresses IP.
Clusters de VPC natif
Cet insight est généré si une plage d'adresses IP secondaire utilisée pour allouer des adresses IP de pod ne dispose pas de suffisamment d'espace d'adresses IP non allouées. L'espace d'adressage IP insuffisant ne peut pas gérer la situation lorsque tous les pools de nœuds sont soumis à un autoscaling complet.
Articles associés
Pour en savoir plus, consultez les pages Bonnes pratiques de mise en réseau GKE et Limites de l'autoscaler de cluster.
Recommandations
- Pour les clusters basés sur le routage, recréez le cluster avec une plage d'adresses des pods plus étendue. Créez ce cluster en tant que cluster de VPC natif, car il s'agit du mode réseau recommandé. Consultez la section Clusters de VPC natif et clusters basés sur le routage.
- Pour les clusters de VPC natif, ajoutez des plages de pods supplémentaires au niveau du cluster à l'aide du CIDR multipod et activez le provisionnement automatique des nœuds pour automatiser le scaling des nœuds avec l'allocation automatique des adresses IP des pods. Si vous souhaitez mieux contrôler les adresses IP de pod utilisées pour chaque pool de nœuds, vous pouvez créer des pools de nœuds qui utilisent une plage d'adresses IP secondaire spécifique à l'aide d'un CIDR multipod. Toutefois, cette fonctionnalité ne s'applique qu'aux clusters standards.