Bonnes pratiques pour la mise en réseau GKE

Ce document décrit les bonnes pratiques à suivre pour configurer les options de mise en réseau pour les clusters Google Kubernetes Engine (GKE). Il s'agit d'un guide de planification de l'architecture destiné aux architectes cloud et aux ingénieurs réseau, avec des recommandations de configuration des clusters qui sont applicables à la plupart des clusters GKE. Avant de créer vos clusters GKE, nous vous recommandons de consulter toutes les sections de ce document pour comprendre les options de mise en réseau compatibles avec GKE et leurs implications.

Les options de mise en réseau que vous choisissez ont une incidence sur l'architecture de vos clusters GKE. Certaines de ces options ne peuvent pas être modifiées une fois configurées sans recréer le cluster.

Ce document n'est pas destiné à présenter les concepts ou la terminologie de mise en réseau Kubernetes. Nous partons du principe que vous disposez déjà d'un certain niveau de connaissances générales en la matière et que vous maîtrisez les concepts de mise en réseau dans Kubernetes. Pour en savoir plus, consultez la présentation du réseau GKE.

Lors de l'examen du présent document, vous devez tenir compte des points suivants :

  • La manière dont vous prévoyez d'exposer les charges de travail en interne sur votre réseau cloud privé virtuel (VPC), d'autres charges de travail dans le cluster, d'autres clusters GKE, ou en externe sur Internet.
  • La manière dont vous prévoyez de faire évoluer vos charges de travail.
  • Les types de services Google que vous souhaitez utiliser.

Pour obtenir un résumé de toutes les bonnes pratiques, consultez la checklist.

Conception de VPC

Lorsque vous concevez vos réseaux VPC, suivez les bonnes pratiques en matière de conception des VPC.

La section suivante fournit des recommandations spécifiques à GKE pour la conception de réseaux VPC.

Bonnes pratiques

Utilisez des clusters de VPC natif.
Utilisez des réseaux VPC partagés.

Utiliser des clusters de VPC natif

Nous vous recommandons d'utiliser des clusters de VPC natif. Les clusters de VPC natif utilisent des plages d'adresses IP d'alias sur les nœuds GKE. Ils sont requis pour les clusters GKE privés et pour la création de clusters sur des VPC partagés et présentent de nombreux autres avantages. Pour les clusters créés en mode Autopilot, le mode VPC natif est toujours activé et ne peut pas être désactivé.

Les clusters de VPC natif évoluent plus facilement que les clusters basés sur le routage sans consommer de routes Google Cloud. Ils sont donc moins sensibles aux limites de routage.

Les avantages liés à l'utilisation de clusters de VPC natif vont de pair avec la compatibilité des adresses IP d'alias. Par exemple, les groupes de points de terminaison du réseau (NEG, Network Endpoint Groups) ne peuvent être utilisés qu'avec des adresses IP secondaires. Ils ne sont donc compatibles qu'avec les clusters de VPC natif.

Utiliser des réseaux VPC partagés

Les clusters GKE nécessitent une planification minutieuse des adresses IP. La plupart des entreprises ont une structure de gestion centralisée avec une équipe d'administration réseau qui peut allouer un espace d'adresse IP aux clusters et un administrateur de plate-forme pour l'exploitation des clusters. Ce type de structure d'organisation fonctionne bien avec l'architecture de réseau VPC partagé de Google Cloud. Dans l'architecture réseau VPC partagé, un administrateur réseau peut créer des sous-réseaux et les partager avec des VPC. Vous pouvez créer des clusters GKE dans un projet de service et utiliser les sous-réseaux partagés depuis le VPC partagé sur le projet hôte. Le composant d'adresse IP reste dans le projet hôte et les autres composants de votre cluster résident dans le projet de service.

En général, un réseau VPC partagé est une architecture fréquemment utilisée, adaptée à la plupart des organisations disposant d'une équipe de gestion centralisée. Nous vous recommandons d'utiliser des réseaux VPC partagés afin de créer des sous-réseaux pour vos clusters GKE et d'éviter les conflits d'adresses IP au sein de votre organisation. Vous pouvez également utiliser des VPC partagés pour la gouvernance des fonctions opérationnelles. Par exemple, vous pouvez disposer d'une équipe réseau qui ne travaille que sur les composants et la fiabilité du réseau, et d'une autre équipe qui travaille sur GKE.

Stratégies de gestion des adresses IP

Tous les clusters Kubernetes, y compris les clusters GKE, nécessitent une adresse IP unique pour chaque pod.

Pour en savoir plus, consultez le modèle de gestion de réseaux GKE.

Dans GKE, toutes ces adresses IP peuvent être routées à travers le réseau VPC. Par conséquent, la planification d'adresses IP est nécessaire, car les adresses ne doivent pas chevaucher l'espace d'adresses IP internes utilisé sur site ou dans d'autres environnements connectés. Les sections suivantes proposent des stratégies en vue la gestion des adresses IP avec GKE.

Bonnes pratiques

Planifiez l'attribution des adresses IP requises.
Si nécessaire, utilisez un espace non-RFC 1918.
Utilisez le mode de sous-réseau personnalisé.
Planifiez la densité des pods par nœud.
Évitez de chevaucher des adresses IP utilisées dans d'autres environnements.
Créez un sous-réseau d'équilibreur de charge.
Réservez suffisamment d'espace d'adresse IP pour l'autoscaler de cluster.
Partagez les adresses IP entre les clusters.
Partagez les adresses IP des services LoadBalancer internes.

Planifier l'attribution des adresses IP requises

Les clusters privés sont recommandés et sont décrits plus en détail dans la section Sécurité du réseau. Dans le contexte des clusters privés, seuls les clusters de VPC natif sont acceptés et nécessitent les plages d'adresses IP suivantes :

  • Plage d'adresses IP du plan de contrôle : utilisez un sous-réseau /28 dans les plages privées d'adresses IP incluses dans RFC 1918. Vous devez vous assurer que ce sous-réseau ne chevauche aucun autre routage CIDR du réseau VPC.
  • Sous-réseau de nœud : sous-réseau avec la plage d'adresses IP principale que vous souhaitez attribuer à tous les nœuds de votre cluster. Les services de type LoadBalancer qui utilisent l'annotation cloud.google.com/load-balancer-type: "Internal" utilisent également ce sous-réseau par défaut. Vous pouvez également utiliser un sous-réseau dédié aux équilibreurs de charge internes.
  • Plage d'adresses IP des pods : plage d'adresses IP que vous attribuez à tous les pods de votre cluster. GKE provisionne cette plage en tant qu'alias du sous-réseau. Pour en savoir plus, consultez la section Plages d'adresses IP pour les clusters de VPC natif.
  • Plage d'adresses IP de service : plage d'adresses IP que vous attribuez à tous les services de votre cluster. GKE provisionne cette plage en tant qu'alias du sous-réseau.

Pour les clusters privés, vous devez définir un sous-réseau de nœud, une plage d'adresses IP de pod et une plage d'adresses IP de service.

Si vous souhaitez utiliser l'espace d'adresses IP plus efficacement, consultez la page Réduire l'utilisation des adresses IP internes dans GKE.

La plage d'adresses IP du plan de contrôle est dédiée au plan de contrôle géré par GKE qui réside dans un projet locataire géré par Google qui est appairé à votre VPC. Cette plage d'adresses IP ne doit pas chevaucher les adresses IP de votre groupe d'appairage de VPC, car GKE importe cette route dans votre projet. Cela signifie que si vous disposez de routes vers le même CIDR dans votre projet, vous pouvez rencontrer des problèmes de routage.

Lors de la création d'un cluster, le sous-réseau possède une plage principale pour les nœuds du cluster. Il doit exister avant la création du cluster. Le sous-réseau doit s'adapter au nombre maximal de nœuds prévus dans le cluster et aux adresses IP de l'équilibreur de charge interne dans le cluster utilisant le sous-réseau.

Vous pouvez utiliser l'autoscaler de cluster pour limiter le nombre maximal de nœuds.

Les plages d'adresses IP des pods et des services sont représentées comme des plages secondaires distinctes de votre sous-réseau, mises en œuvre en tant qu'adresses IP d'alias dans les clusters de VPC natif.

Choisissez des plages d'adresses IP suffisamment étendues pour pouvoir accueillir tous les nœuds, pods et services du cluster.

Tenez compte des limites suivantes :

Utiliser plus d'adresses IP privées RFC 1918

Pour certains environnements, l'espace RFC 1918 de grands blocs CIDR contigu larges peut déjà être alloué dans une organisation. Vous pouvez utiliser un espace non-RFC 1918 pour des CIDR supplémentaires pour les clusters GKE s'ils ne chevauchent pas les adresses IP publiques appartenant à Google. Nous vous recommandons d'utiliser la partie 100.64.0.0/10 de l'espace d'adressage RFC, car l'espace d'adressage de classe E peut présenter des problèmes d'interopérabilité avec le matériel sur site. Vous pouvez utiliser des adresses IP publiques réutilisées en mode privé (PUPI).

Lorsque vous utilisez des adresses IP publiques réutilisées en privé, faites preuve de prudence et envisagez de contrôler les annonces de routage dans les réseaux sur site vers Internet lorsque vous choisissez cette option.

Vous ne devez pas utiliser la traduction d'adresses réseau source (SNAT) dans un cluster avec du trafic entre pods et entre pods et services. Cela casse le modèle de mise en réseau Kubernetes.

Kubernetes suppose que toutes les adresses IP non-RFC 1918 sont des adresses IP publiques réutilisées en mode privé et utilisent la SNAT pour tout le trafic provenant de ces adresses.

Si vous utilisez une adresse IP non-RFC 1918 pour votre cluster GKE, vous devez désactiver explicitement SNAT ou configurer la l'agent de masquage d'adresses IP pour exclure les adresses IP des pods de votre cluster et les plages d'adresses IP secondaires des services de SNAT. Pour les clusters Autopilot, aucune étape supplémentaire n'est requise.

Utiliser le mode de sous-réseau personnalisé

Lorsque vous configurez le réseau, vous sélectionnez également le mode de sous-réseau : auto (par défaut) ou custom (recommandé). En mode auto, Google attribue le sous-réseau. Cette option est intéressante pour commencer sans planifier d'adresse IP. Toutefois, nous vous recommandons de sélectionner le mode custom, car vous pouvez choisir des plages d'adresses IP qui ne chevauchent pas d'autres plages de votre environnement. Si vous utilisez un VPC partagé, un administrateur de l'organisation ou un administrateur réseau peut sélectionner ce mode.

L'exemple suivant crée un réseau appelé my-net-1 avec le mode de sous-réseau personnalisé :

gcloud compute networks create my-net-1 --subnet-mode custom

Planifier la densité des pods par nœud

Par défaut, les clusters standards réservent une plage /24 pour chaque nœud en dehors de l'espace d'adressage de pod dans le sous-réseau et permettent jusqu'à 110 pods par nœud. Toutefois, vous pouvez configurer un cluster Standard pour accepter jusqu'à 256 pods par nœud, avec une plage /23 réservée pour chaque nœud. Selon la taille de vos nœuds et le profil d'application de vos pods, vous pouvez exécuter considérablement moins de pods sur chaque nœud.

Si vous n'envisagez pas d'exécuter plus de 64 pods par nœud, nous vous recommandons d'ajuster le nombre maximal de pods par nœud afin de préserver l'espace d'adresses IP dans votre sous-réseau de pod.

Si vous prévoyez d'exécuter plus de pods par nœud que les 110 par défaut, vous pouvez augmenter le nombre maximal de pods par nœud jusqu'à 256, avec une plage /23 réservé pour chaque nœud. Avec ce type de configuration à densité de pod élevée, nous vous recommandons d'utiliser des instances avec au moins 16 cœurs de processeur pour garantir l'évolutivité et les performances de votre cluster.

Pour les clusters Autopilot, le nombre maximal de pods par nœud est défini sur 32, ce qui réserve une plage de taille /26 pour chaque nœud. Ce paramètre n'est pas configurable dans les clusters Autopilot.

Éviter les chevauchements d'adresses IP utilisées dans d'autres environnements

Vous pouvez connecter votre réseau VPC à un environnement sur site ou à d'autres fournisseurs de services cloud via Cloud VPN ou Cloud Interconnect. Ces environnements peuvent partager des routes, le schéma de gestion des adresses IP sur site est donc important en vue de la planification des adresses IP pour GKE. Nous vous recommandons de veiller à ce que les adresses IP ne chevauchent pas celles d'autres environnements.

Créer un sous-réseau d'équilibreur de charge

Créez un sous-réseau d'équilibreur de charge distinct pour exposer les services avec un équilibrage de charge TCP/UDP interne. Si aucun sous-réseau d'équilibreur de charge distinct n'est utilisé, ces services sont exposés à l'aide d'une adresse IP du sous-réseau de nœud, ce qui peut entraîner l'utilisation de la totalité de l'espace alloué dans ce sous-réseau plus tôt que prévu et peut vous empêcher d'adapter votre cluster GKE au nombre de nœuds prévus.

L'utilisation d'un sous-réseau d'équilibrage de charge distinct signifie également que vous pouvez filtrer le trafic vers et depuis les nœuds GKE séparément des services exposés par l'équilibrage de charge TCP/UDP interne, vous permettant de définir des limites de sécurité plus strictes.

Réserver suffisamment d'espace d'adresses IP pour l'autoscaler de cluster

Vous pouvez utiliser l'autoscaler de cluster pour ajouter et supprimer des nœuds de manière dynamique dans le cluster, afin de contrôler les coûts et d'améliorer l'utilisation. Toutefois, lorsque vous utilisez l'autoscaler de cluster, assurez-vous que votre planification d'adresses IP prend en compte la taille maximale de tous les pools de nœuds. Chaque nouveau nœud nécessite sa propre adresse IP de nœud, ainsi que son propre ensemble d'adresses IP attribuées aux pods en fonction des pods configurés par nœud. Le nombre de pods par nœud peut être configuré différemment de celui défini au niveau du cluster. Vous ne pouvez pas modifier le nombre de pods par nœud après avoir créé le cluster ou le pool de nœuds. Vous devez tenir compte de vos types de charges de travail et les attribuer à des pools de nœuds distincts pour optimiser l'attribution d'adresses IP.

Pensez au provisionnement automatique des nœuds avec l'autoscaler de cluster, en particulier si vous utilisez des clusters de VPC natif. Pour en savoir plus, consultez la page Plages de limites de nœuds.

Partager des adresses IP entre les clusters

Vous devrez peut-être partager des adresses IP entre les clusters si vous disposez d'une équipe centralisée qui gère l'infrastructure des clusters. Pour partager des adresses IP entre des clusters GKE, consultez la page Partager des plages d'adresses IP entre des clusters GKE. Vous pouvez réduire l'épuisement des adresses IP en créant trois plages, respectivement pour les pods, les services et les nœuds, et en les réutilisant ou en les partageant, en particulier dans un modèle de VPC partagé. Cette configuration peut également faciliter la gestion des adresses IP par les administrateurs réseau, en leur évitant d'avoir à créer des sous-réseaux spécifiques pour chaque cluster.

Réfléchissez aux éléments suivants :

  • Il est recommandé d'utiliser des sous-réseaux et des plages d'adresses IP distincts pour tous les clusters.
  • Vous pouvez partager la plage d'adresses IP de pod secondaire, mais cette option n'est pas recommandée, car un cluster peut utiliser toutes les adresses IP.
  • Vous pouvez partager les plages d'adresses IP de services secondaires, mais cette fonctionnalité ne fonctionne pas avec le champ d'application VPC Cloud DNS pour GKE.

Si vous n'avez plus d'adresses IP, vous pouvez créer des plages d'adresses IP de pod supplémentaires à l'aide du CIDR multipod non contigu.

Partager les adresses IP des services LoadBalancer internes

Vous pouvez partager une adresse IP unique avec un maximum de 50 backends en utilisant différents ports. Vous pouvez ainsi réduire le nombre d'adresses IP dont vous avez besoin pour les services LoadBalancer internes.

Pour en savoir plus, consultez la section Adresse IP partagée.

Options de sécurité du réseau

Dans cette section, nous vous présentons quelques recommandations clés concernant l'isolation des clusters. La sécurité réseau pour les clusters GKE est une responsabilité partagée entre Google et le(s) administrateur(s) de cluster.

Bonnes pratiques :

Utiliser GKE Dataplane V2.
Choisir un type de cluster privé.
Réduire l'exposition du plan de contrôle du cluster.
Autoriser l'accès au plan de contrôle.
Autoriser la connectivité du plan de contrôle.
Déployer des proxys pour l'accès au plan de contrôle à partir de réseaux appairés.
Limiter le trafic du cluster à l'aide de règles de réseau.
Activer les règles de sécurité Google Cloud Armor pour Ingress.
Utiliser Identity-Aware Proxy pour assurer l'authentification pour les applications avec des utilisateurs IAM.
Utiliser des contraintes de règles d'administration pour renforcer la sécurité.

Utiliser GKE Dataplane V2.

GKE Dataplane V2 est basé sur eBPF et offre une expérience intégrée de sécurité et de visibilité du réseau. Lorsque vous créez un cluster à l'aide de GKE Dataplane V2, vous n'avez pas besoin d'activer explicitement les règles de réseau, car GKE Dataplane V2 gère le routage des services, l'application des règles de réseau et la journalisation. Activez le nouveau plan de données avec l'option --enable-dataplane-v2 de Google Cloud CLI lors de la création d'un cluster. Une fois les règles de réseau configurées, un objet CRD NetworkLogging par défaut peut être configuré pour enregistrer les connexions réseau autorisées et refusées. Nous vous recommandons de créer des clusters avec GKE Dataplane V2 pour tirer pleinement parti des fonctionnalités intégrées telles que la journalisation des règles de réseau.

Choisir un type de cluster privé

Les clusters publics disposent d'adresses IP privées et publiques sur les nœuds et seulement d'un point de terminaison public pour les nœuds du plan de contrôle. Les clusters privés offrent davantage d'isolation en ne disposant que des adresses IP internes sur les nœuds, et en possédant des points de terminaison privés et publics pour les nœuds du plan de contrôle (qui peuvent être davantage isolés et sont abordés dans la section Réduire l'exposition du plan de contrôle du cluster). Dans les clusters privés, vous pouvez toujours accéder aux API Google avec l'accès privé à Google. Nous vous recommandons de choisir des clusters privés.

Dans un cluster privé, les pods sont isolés des communications entrantes et sortantes (périmètre du cluster). Vous pouvez contrôler ces flux directionnels en exposant des services à l'aide de l'équilibrage de charge et de Cloud NAT, qui sont décrits dans la section Connectivité du cluster de ce document. Le schéma suivant illustre ce type de configuration :

Schéma 1 : communication sur le cluster privé

Ce schéma montre comment un cluster privé peut communiquer. Les clients sur site peuvent se connecter au cluster avec le client kubectl. L'accès aux services Google est fourni via l'accès privé à Google, et la communication vers Internet n'est possible qu'à l'aide de Cloud NAT.

Pour plus d'informations, consultez les exigences, restrictions et limitations des clusters privés.

Réduire l'exposition du plan de contrôle du cluster

Dans un cluster privé, le serveur d'API GKE peut être exposé en tant que point de terminaison public ou privé. Vous pouvez décider du point de terminaison à utiliser lors de la création de cluster. Vous pouvez contrôler les accès à l'aide des réseaux autorisés, dans lesquels les points de terminaison publics et privés sont activés par défaut pour autoriser toutes les communications entre le pod et les adresses IP du nœud du cluster. Pour activer un point de terminaison privé lorsque vous créez un cluster, utilisez l'option --enable-private-endpoint.

Autoriser l'accès au plan de contrôle

Les réseaux autorisés peuvent aider à déterminer quels sous-réseaux d'adresses IP peuvent accéder aux nœuds du plan de contrôle GKE. Après avoir activé ces réseaux, vous pouvez limiter l'accès à des plages d'adresses IP sources spécifiques. Si le point de terminaison public est désactivé, ces plages d'adresses IP sources doivent être privées. Si un point de terminaison public est activé, vous pouvez autoriser les plages d'adresses IP publiques ou internes. Configurez des annonces de routage personnalisées pour permettre au point de terminaison privé du plan de contrôle du cluster d'être accessible depuis un environnement sur site. Vous pouvez rendre le point de terminaison privé de l'API GKE accessible à l'échelle globale à l'aide de l'option --enable-master-global-access lorsque vous créez un cluster.

Le schéma suivant illustre une connectivité typique du plan de contrôle à l'aide de réseaux autorisés :

Diagramme 2 : Connectivité du plan de contrôle à l'aide des réseaux autorisés

Le schéma précédent montre que les utilisateurs de confiance peuvent communiquer avec le plan de contrôle GKE via le point de terminaison public, car ils font partie de réseaux autorisés, tandis que l'accès d'utilisateurs non approuvés est bloqué. La communication vers et depuis le cluster GKE s'effectue via le point de terminaison privé du plan de contrôle.

Autoriser la connectivité du plan de contrôle

Certains pods système de chaque nœud de calcul devront accéder aux services tels que le serveur d'API Kubernetes (kube-apiserver), les API Google ou le serveur de métadonnées. kube-apiserver doit également communiquer avec certains pods système, tels que event-exporter. Cette communication est autorisée par défaut. Si vous déployez des règles de pare-feu VPC dans les projets (plus de détails dans la section Limiter le trafic du cluster), assurez-vous que ces pods peuvent continuer à communiquer avec kube-apiserver, ainsi qu'avec les API Google.

Déployer des proxys pour accéder au plan de contrôle à partir de réseaux appairés

L'accès au plan de contrôle des clusters GKE privés s'effectue via l'appairage de réseaux VPC. L'appairage de réseaux VPC est non transitif. Vous ne pouvez donc pas accéder au plan de contrôle du cluster depuis un autre réseau appairé.

Si vous souhaitez un accès direct à partir d'un autre réseau appairé ou sur site lorsque vous utilisez une architecture en étoile, déployez des proxys pour le trafic du plan de contrôle.

Limiter le trafic du cluster à l'aide de règles de réseau

Il existe plusieurs niveaux de sécurité réseau pour les charges de travail de cluster pouvant être combinés : règles de pare-feu VPC, règles de pare-feu hiérarchiques et règles de réseau Kubernetes. Les règles de pare-feu VPC et les règles de pare-feu hiérarchiques s'appliquent au niveau de la machine virtuelle (VM), qui correspond aux nœuds de calcul sur lesquels résident les pods du cluster GKE. Les règles de réseau Kubernetes s'appliquent au niveau du pod pour appliquer les chemins du trafic entre pods.

Si vous mettez en œuvre des pare-feu VPC, cette action peut rompre la communication par défaut requise du plan de contrôle, par exemple la communication kubelet avec le plan de contrôle. GKE crée les règles de pare-feu requises par défaut, mais vous pouvez les remplacer. Certains déploiements peuvent nécessiter l'accès du plan de contrôle au cluster sur le service. Vous pouvez utiliser des pare-feu VPC pour configurer une règle d'entrée qui permet l'accessibilité du service.

Les règles de réseau GKE sont configurées via l'API Network Policy de Kubernetes pour appliquer la communication de pod d'un cluster. Vous pouvez activer des règles de réseau lorsque vous créez un cluster à l'aide de l'option gcloud container clusters create --enable-network-policy. Pour limiter le trafic à l'aide de règles de réseau, consultez le guide de mise en œuvre du plan d'action d'Anthos pour limiter le trafic.

Activer les règles de sécurité Google Cloud Armor pour Ingress

Les règles de sécurité Google Cloud Armor vous permettent de protéger les applications qui utilisent des équilibreurs de charge d'application externes contre les attaques DDoS et d'autres attaques Web en bloquant ce trafic à la périphérie du réseau. Dans GKE, activez les règles de sécurité Google Cloud Armor pour les applications en utilisant Ingress pour les équilibreurs de charge d'application externes et en ajoutant une règle de sécurité au BackendConfig associé à l'objet Ingress.

Utiliser Identity-Aware Proxy pour assurer l'authentification pour les applications avec des utilisateurs IAM

Si vous souhaitez déployer des services uniquement accessibles aux utilisateurs de l'organisation, mais sans utiliser le réseau de l'entreprise, Identity-Aware Proxy vous permet de créer une couche d'authentification pour ces applications. Pour activer Identity-Aware Proxy pour GKE, suivez les étapes de configuration afin d'intégrer Identity-Aware Proxy dans le cadre du service BackendConfig pour votre entrée de service. Identity-Aware Proxy peut être associé à Google Cloud Armor.

Utiliser des contraintes de règles d'administration pour renforcer la sécurité

Les contraintes de règles d'administration vous permettent de définir des règles visant à renforcer votre stratégie de sécurité. Par exemple, vous pouvez utiliser des contraintes pour restreindre la création de l'équilibreur de charge à certains types, tels que les équilibreurs de charge internes uniquement.

Effectuer le scaling de la connectivité du cluster

Cette section présente les options évolutives en matière de DNS et de connectivité sortante à partir de vos clusters vers Internet et les services Google.

Bonnes pratiques :

Utilisez Cloud DNS pour GKE.
Activez NodeLocal DNSCache.
Utilisez Cloud NAT pour accéder à Internet à partir de clusters privés.
Utilisez l'Accès privé à Google pour accéder aux services Google.

Utiliser Cloud DNS pour GKE

Vous pouvez utiliser Cloud DNS pour GKE pour fournir une résolution DNS de pod et de service avec un DNS géré sans fournisseur DNS hébergé par le cluster. Cloud DNS élimine les frais liés à la gestion d'un serveur DNS hébergé par le cluster, et ne nécessite aucun scaling, aucune surveillance ni aucune gestion des instances DNS, car il s'agit d'un service Google hébergé.

Activer NodeLocal DNSCache

GKE utilise kube-dns pour fournir le service DNS local du cluster en tant que module complémentaire de cluster par défaut. kube-dns est répliqué sur le cluster en fonction du nombre total de cœurs et de nœuds du cluster.

Vous pouvez améliorer les performances DNS à l'aide de NodeLocal DNSCache. NodeLocal DNSCache est un module complémentaire déployé en tant que DaemonSet et ne nécessite aucune modification de la configuration des pods. Les résolutions DNS envoyées au service de pod local ne créent pas de connexions ouvertes qui doivent être suivies sur le nœud pour permettre une plus grande évolutivité. Les recherches de noms d'hôte externes sont transférées vers Cloud DNS, où toutes les autres requêtes DNS sont envoyées à kube-dns.

Activez NodeLocal DNSCache pour des temps de recherche de requêtes DNS plus cohérents et une plus grande évolutivité du cluster. Pour les clusters Autopilot, NodeLocal DNSCache est activé par défaut et ne peut pas être remplacé.

L'option Google Cloud CLI suivante active NodeLocal DNSCache lorsque vous créez un cluster : --addons NodeLocalDNS.

Si vous contrôlez le nom que les applications cherchent à résoudre, il existe des moyens d'améliorer le scaling DNS. Vous pouvez par exemple utiliser un nom de domaine complet (point à la fin du nom d'hôte) ou désactiver l'extension du chemin de recherche via l'option du fichier manifeste Pod.dnsConfig.

Utiliser Cloud NAT pour accéder à Internet à partir de clusters privés

Par défaut, les clusters privés ne disposent pas d'un accès à Internet. Pour permettre aux pods d'accéder à Internet, activez Cloud NAT pour chaque région. Activez au moins Cloud NAT pour les plages principale et secondaire du sous-réseau GKE. Assurez-vous d'attribuer suffisamment d'adresses IP pour Cloud NAT et les ports par VM.

Appliquez les bonnes pratiques suivantes pour la configuration de la passerelle Cloud NAT lorsque vous utilisez Cloud NAT pour des clusters privés :

  • Lorsque vous créez votre passerelle Cloud NAT, activez-la uniquement pour les plages de sous-réseaux utilisées par vos clusters. En comptant tous les nœuds sur l'ensemble des clusters, vous pouvez déterminer le nombre de VM clientes du NAT dans le projet.

  • Utilisez l'allocation de ports dynamique pour allouer des nombres de ports différents par VM, en fonction de l'utilisation de la VM. Commencez avec un nombre minimal de ports de 64 et un nombre maximal de ports de 2048.

  • Si vous devez gérer de nombreuses connexions simultanées au même 3-tuple de destination, réduisez le délai d'attente TCP TIME_WAIT de sa valeur par défaut de 120s à 5s. Pour en savoir plus, consultez la section Spécifier différents délais avant expiration pour le NAT.

  • Activez la journalisation des erreurs Cloud NAT pour vérifier les journaux associés.

  • Consultez les journaux de la passerelle Cloud NAT après avoir configuré la passerelle. Pour réduire les problèmes d'état d'allocation, vous devrez peut-être augmenter le nombre maximal de ports par VM.

Vous devez éviter le doublon SNAT pour le trafic des pods (première traduction SNAT au niveau du nœud GKE, puis avec Cloud NAT). Sauf si vous avez besoin de la traduction SNAT pour masquer les adresses IP de pods vers des réseaux sur site connectés par Cloud VPN ou Cloud Interconnect, disable-default-snat et déchargez le suivi SNAT vers Cloud NAT à des fins d'évolutivité. Cette solution fonctionne pour toutes les plages d'adresses IP de sous-réseau principales et secondaires. Utilisez des règles de réseau pour limiter le trafic externe après l'activation de Cloud NAT. Cloud NAT n'est pas requis pour accéder aux services Google.

Utiliser l'Accès privé à Google pour accéder aux services Google

Dans les clusters privés, les pods n'ont pas d'adresses IP publiques pour contacter les services publics, y compris les API et services Google. L'Accès privé à Google permet aux ressources Google Cloud privées d'accéder aux services Google.

L'accès privé à Google est activé par défaut dans les clusters privés, sauf dans les clusters de VPC partagé.

Diffuser des applications

Lorsque vous créez des applications accessibles en externe ou en interne à votre organisation, veillez à utiliser le type et les options appropriés pour votre équilibreur de charge. Cette section présente des recommandations pour exposer et favoriser l'évolutivité des applications avec Cloud Load Balancing.

Bonnes pratiques

Utiliser l'équilibrage de charge natif en conteneurs.
Choisir la ressource GKE appropriée pour exposer votre application.
Créer des vérifications de l'état basées sur BackendConfig.
Utiliser une règle de trafic locale pour conserver les adresses IP d'origine.
Utiliser Private Service Connect.

Utiliser l'équilibrage de charge natif en conteneurs

Utilisez l'équilibrage de charge natif en conteneurs lors de l'exposition des services à l'aide de HTTP(S) en externe. L'équilibrage de charge natif en conteneurs permet de réduire le nombre de sauts de réseau, de limiter la latence et de favoriser une distribution du trafic plus précise. Il améliore également la visibilité du délai aller-retour et vous permet d'utiliser des fonctionnalités d'équilibrage de charge telles que Google Cloud Armor.

Choisir la ressource GKE appropriée pour exposer votre application

Selon le champ d'application de vos clients (interne, externe ou même cluster-interne), la régionalisation de votre application et les protocoles que vous utilisez, vous pouvez choisir parmi plusieurs ressources GKE pour exposer votre application. La section Présentation de la mise en réseau de services vous présente ces options. Elle peut vous aider à choisir la ressource la plus adaptée à exposer chaque partie de votre application à l'aide des options d'équilibrage de charge de Google Cloud.

Créer des vérifications de l'état basées sur BackendConfig

Si vous utilisez un objet Ingress pour exposer des services, utilisez une configuration de vérification de l'état dans un CRD BackendConfig pour utiliser la fonctionnalité de vérification d'état de l'équilibreur de charge d'application externe. Vous pouvez diriger la vérification de l'état vers le point de terminaison approprié et définir vos propres seuils. Sans CRD BackendConfig, les vérifications de l'état sont déduites des paramètres de vérification d'aptitude ou utilisent des paramètres par défaut.

Utiliser la règle de trafic local pour préserver les adresses IP d'origine

Lorsque vous utilisez un équilibreur de charge réseau interne à stratégie direte avec GKE, définissez l'option externalTrafficPolicy sur Local pour conserver l'adresse IP source des requêtes. Utilisez cette option si votre application nécessite l'adresse IP source d'origine. Toutefois, l'option local externalTrafficPolicy peut entraîner une répartition de la charge moins optimale. N'utilisez cette fonctionnalité que si elle est requise. Pour les services HTTP(S), vous pouvez utiliser des contrôleurs Ingress et obtenir l'adresse IP d'origine en lisant l'en-tête X-Forwarded-For dans la requête HTTP.

Utiliser Private Service Connect.

Vous pouvez utiliser Private Service Connect pour partager des services d'équilibrage de charge réseau internes à stratégie directe sur d'autres réseaux VPC. Cela est utile pour les services qui sont hébergés sur des clusters GKE, mais qui servent des clients exécutés dans des projets et des VPC différents.

Vous pouvez utiliser Private Service Connect pour réduire l'utilisation d'adresses IP en fournissant une connectivité entre les VPC avec des adresses IP qui se chevauchent.

Opérations et administration

Bonnes pratiques :

Utilisez les autorisations IAM pour GKE pour contrôler les stratégies dans les réseaux VPC partagés.
Utilisez des clusters régionaux et distribuez les charges de travail pour une haute disponibilité
Utiliser Cloud Logging et Cloud Monitoring et activer la journalisation des règles de réseau.

Les sections suivantes dévoilent des bonnes pratiques opérationnelles qui vous aident à choisir des options d'autorisation précises pour vos charges de travail. Pour éviter de créer des règles de pare-feu manuelles, suivez les bonnes pratiques opérationnelles décrites figurant dans cette section. Elle présente également des recommandations en vue de la répartition de vos charges de travail, ainsi que de la surveillance et de la journalisation dans GKE.

Utiliser les autorisations IAM pour GKE pour contrôler les stratégies dans les réseaux VPC partagés

Lorsque vous utilisez des réseaux VPC partagés, les règles de pare-feu des équilibreurs de charge sont automatiquement créées dans le projet hôte.

Pour éviter de devoir créer manuellement des règles de pare-feu, attribuez un rôle personnalisé selon le principe du moindre privilège au compte de service GKE dans le projet hôte nommé service-HOST_PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com.

Remplacez HOST_PROJECT_NUMBER par le numéro du projet hôte du VPC partagé.

Le rôle personnalisé que vous créez doit disposer des autorisations suivantes:

  • compute.firewalls.create
  • compute.firewalls.get
  • compute.firewalls.list
  • compute.firewalls.delete

De plus, les règles de pare-feu créées par GKE ont toujours une priorité par défaut de 1 000. Vous pouvez donc empêcher le trafic spécifique de transiter en créant des règles de pare-feu de priorité supérieure.

Si vous souhaitez limiter la création de certains types d'équilibreurs de charge, utilisez des règles d'administration pour limiter la création de l'équilibreur de charge.

Utiliser des clusters régionaux et distribuer les charges de travail pour une haute disponibilité

Les clusters régionaux peuvent augmenter la disponibilité des applications dans un cluster, car le plan de contrôle et les nœuds du cluster sont répartis sur plusieurs zones.

Toutefois, afin d'offrir la meilleure expérience utilisateur possible en cas de défaillance d'une zone, utilisez l'autoscaler de cluster pour que votre cluster puisse gérer la charge requise à tout moment.

Vous pouvez également utiliser l'anti-affinité de pod pour vous assurer que les pods d'un service donné sont planifiés dans plusieurs zones.

Pour plus d'informations sur la configuration de ces paramètres pour l'optimisation de la haute disponibilité et des coûts, consultez la page Bonnes pratiques pour les clusters GKE à disponibilité élevée.

Utiliser Cloud Logging et Cloud Monitoring et activer la journalisation des règles de réseau

Bien que chaque organisation possède ses propres exigences de visibilité et d'audit, nous vous recommandons d'activer la journalisation des règles de réseau. Cette fonctionnalité n'est disponible qu'avec GKE Dataplane V2. La journalisation des règles de réseau fournit une visibilité sur l'application des règles et les modèles de trafic des pods. Sachez que la journalisation des règles de réseau entraîne des coûts.

Pour les clusters GKE version 1.14 ou ultérieure, Logging et Monitoring sont tous deux activés par défaut. Monitoring fournit un tableau de bord pour vos clusters GKE. Logging active également les annotations GKE pour les journaux de flux VPC. Par défaut, Logging collecte les journaux de toutes les charges de travail déployées sur le cluster, mais il existe également une option de journaux système uniquement. Utilisez le tableau de bord GKE pour observer et définir des alertes. Pour les clusters créés en mode Autopilot, la surveillance et la journalisation sont automatiquement activées et non configurables.

Sachez que des coûts sont facturés pour l'observabilité de Google Cloud.

Checklist

Quartier Entrainement
Conception de VPC
Stratégies de gestion des adresses IP
Options de sécurité du réseau
Scaling
Diffuser des applications
Opérations et administration

Étapes suivantes