Comparer les modèles de réseau dans GKE

Ce document décrit le modèle de réseau utilisé par Google Kubernetes Engine (GKE) et les différences avec les modèles de réseau dans d'autres environnements Kubernetes. Ce document traite des concepts suivants :

  • Les modèles réseau les plus courants utilisés par diverses mises en œuvre de Kubernetes.
  • Les mécanismes d'adressage IP des modèles réseau les plus courants
  • Avantages et inconvénients de chaque modèle de réseau.
  • Description détaillée du modèle de réseau par défaut utilisé par GKE.

Ce document est destiné aux architectes de cloud, aux ingénieurs d'exploitation et aux ingénieurs réseau qui sont familiarisés avec les autres mises en œuvre de Kubernetes et prévoient d'utiliser GKE. Dans ce document, nous partons du principe que vous connaissez Kubernetes et son modèle de mise en réseau de base. Vous devez également connaître les concepts de mise en réseau tels que l'adressage IP, la traduction d'adresses réseau (NAT), les pare-feu et les proxys.

Ce document n'explique pas comment modifier le modèle de mise en réseau GKE par défaut pour répondre à différentes contraintes d'adresses IP. Si vous constatez un manque d'adresses IP lors de la migration vers GKE, consultez la section Stratégies de gestion des adresses IP lors de la migration vers GKE.

Mises en œuvre de modèles de réseau classiques

Vous pouvez mettre en œuvre le modèle de mise en réseau Kubernetes de différentes manières. Cependant, toute mise en œuvre doit toujours répondre aux exigences suivantes :

  • Chaque pod a besoin d'une adresse IP unique.
  • Les pods peuvent communiquer avec les autres pods sur tous les nœuds sans utiliser la NAT.
  • Les agents d'un nœud, par exemple kubelet, peuvent communiquer avec tous les pods de ce nœud.
  • Les pods du réseau hôte d'un nœud peuvent communiquer avec tous les pods sur tous les nœuds sans utiliser la NAT.

Plus de 20 mises en œuvre différentes du modèle de réseau Kubernetes ont été développées pour répondre à ces exigences.

Ces mises en œuvre peuvent être regroupées dans trois types de modèles de réseau. Ces trois modèles présentent les différences suivantes :

  • Comment les pods peuvent communiquer avec les services non Kubernetes sur le réseau d'entreprise.
  • Comment les pods peuvent communiquer avec d'autres clusters Kubernetes au sein de la même organisation.
  • Si la NAT est requise pour la communication en dehors du cluster.
  • Selon si les adresses IP des pods peuvent être réutilisées dans d'autres clusters ou ailleurs dans le réseau d'entreprise.

Chaque fournisseur de services cloud a mis en œuvre un ou plusieurs de ces types de modèles.

Le tableau suivant identifie les trois types de modèles couramment utilisés et dans lesquels la mise en œuvre de Kubernetes est appliquée :

Nom du modèle de réseau Utilisé dans ces mises en œuvre
Entièrement intégré ou plat
Mode île ou avec pont
Isolé
  • Non utilisé couramment par les mises en œuvre Kubernetes, mais peut être utilisé avec n'importe quelle mise en œuvre lorsque le cluster est déployé dans un réseau distinct ou dans un cloud privé virtuel (VPC).

Lorsque ce document décrit ces modèles réseau, il fait référence à leurs effets sur les réseaux connectés sur site. Cependant, vous pouvez appliquer les concepts décrits pour les réseaux sur site connectés à des réseaux connectés via un réseau privé virtuel (VPN) ou via une interconnexion privée, y compris les connexions à d'autres fournisseurs cloud. Pour GKE, ces connexions incluent toute la connectivité via Cloud VPN ou Cloud Interconnect.

Modèle de réseau entièrement intégré

Le modèle de réseau entièrement intégré (ou plat) facilite la communication avec les applications en dehors de Kubernetes et dans d'autres clusters Kubernetes. Les principaux fournisseurs de services cloud mettent en œuvre ce modèle de manière courante, car ils peuvent intégrer étroitement leur mise en œuvre Kubernetes à leur réseau défini par logiciel (SDN, Software-Defined Network).

Lorsque vous utilisez le modèle entièrement intégré, les adresses IP que vous utilisez pour les pods sont acheminées au sein du réseau dans lequel se trouve le cluster Kubernetes. En outre, le réseau sous-jacent sait sur quel nœud se trouvent les adresses IP des pods. Dans de nombreuses mises en œuvre, les adresses IP des pods sur le même nœud proviennent d'une plage d'adresses IP de pod spécifique et pré-attribuée. Toutefois, cette plage d'adresses pré-attribuée n'est pas obligatoire.

Le schéma suivant montre les options de communication de pod dans le modèle de mise en réseau entièrement intégré :

Schéma du réseau illustrant les modèles de communication dans le modèle de réseau entièrement intégré.

Le schéma précédent d'un modèle de réseau entièrement intégré montre les modèles de communication suivants :

  • Les pods d'un cluster Kubernetes peuvent communiquer directement entre eux.
  • Les pods peuvent communiquer avec d'autres pods d'autres clusters tant que ces clusters se trouvent sur le même réseau.
  • Les pods n'ont pas besoin de NAT pour communiquer avec d'autres applications en dehors du cluster, que ces applications se trouvent sur le même réseau ou sur des réseaux interconnectés.

Le schéma montre également que les plages d'adresses IP des pods sont distinctes entre différents clusters.

Le modèle de réseau entièrement intégré est disponible dans les mises en œuvre suivantes :

  • Par défaut, GKE met en œuvre ce modèle. Pour plus d'informations sur cette mise en œuvre, consultez la section Modèle de mise en réseau GKE plus loin dans ce document.
  • Par défaut, Amazon EKS met en œuvre ce modèle. Dans cette mise en œuvre, Amazon EKS utilise le plug-in CNI (Container Networking Interface) Amazon VPC pour Kubernetes afin d'attribuer des adresses IP de pod directement à partir de l'espace d'adresses VPC. Le plug-in CNI attribue les adresses IP du sous-réseau par défaut dans lequel les nœuds se trouvent ou d'un sous-réseau personnalisé. Les adresses IP des pods ne proviennent pas d'une plage d'adresses IP de pod dédiée par nœud.
  • Dans Azure, AKS met en œuvre ce modèle lors de l'utilisation d'Azure CNI (mise en réseau avancée). Cette mise en œuvre n'est pas la configuration par défaut. Dans cette mise en œuvre, chaque pod obtient une adresse IP du sous-réseau. Vous pouvez également configurer le nombre maximal de pods par nœud. Ainsi, le nombre d'adresses IP réservées à l'avance pour les pods sur ce nœud est identique au nombre maximal de pods par nœud.

L'utilisation d'un modèle de réseau entièrement intégré offre les avantages suivants :

  • Amélioration des données de télémétrie. Les adresses IP des pods sont visibles sur le réseau. Cette visibilité rend les données de télémétrie plus utiles que dans d'autres modèles, car les pods peuvent être identifiés même à partir des données de télémétrie collectées en dehors du cluster.
  • Configuration simplifiée du pare-feu Lorsque vous définissez des règles de pare-feu, la différenciation du trafic de nœuds et de pods est plus facile dans le modèle de réseau entièrement intégré que dans les autres modèles.
  • Meilleure compatibilité. Les pods peuvent communiquer à l'aide de protocoles non compatibles avec la NAT.
  • Débogage amélioré. Si le pare-feu l'autorise, les ressources extérieures au cluster peuvent atteindre les pods directement pendant le processus de débogage.
  • Compatibilité avec les maillages de services. Les maillages de services, tels qu'Istio ou Anthos Service Mesh, peuvent facilement communiquer entre les clusters, car les pods peuvent communiquer directement entre eux. Certaines mises en œuvre de maillage de services ne sont compatibles qu'avec la connectivité entre pods pour les maillages de services multiclusters.

L'utilisation d'un modèle de réseau entièrement intégré présente les inconvénients suivants :

  • Utilisation de l'adresse IP. Vous ne pouvez pas réutiliser les adresses IP des pods au sein du réseau. Chaque adresse IP doit être unique. Ces exigences peuvent entraîner un grand nombre d'adresses IP devant être réservées pour les pods.
  • Exigences du SDN Un modèle de réseau entièrement intégré nécessite une intégration approfondie avec le réseau sous-jacent, car la mise en œuvre de Kubernetes doit programmer directement le SDN. La programmation du SDN est transparente pour l'utilisateur et ne produit aucun inconvénient pour l'utilisateur. Toutefois, ces modèles réseau profondément intégrés ne peuvent pas être facilement mis en œuvre dans des environnements sur site autogérés.

Modèle de réseau en mode île

Le modèle de réseau en mode île (ou avec pont) est couramment utilisé pour les mises en œuvre Kubernetes sur site où aucune intégration profonde au réseau sous-jacent n'est possible. Lorsque vous utilisez un modèle de réseau en mode île, les pods d'un cluster Kubernetes peuvent communiquer avec des ressources extérieures au cluster via une passerelle ou un proxy.

Le schéma suivant illustre les options de communication de pod dans un modèle de mise en réseau en mode île :

Schéma du réseau illustrant les modèles de communication dans le modèle de réseau en mode île.

Le schéma précédent d'un modèle de réseau en mode île montre comment les pods d'un cluster Kubernetes peuvent communiquer directement entre eux. Le schéma montre également que les pods d'un cluster doivent utiliser une passerelle ou un proxy pour communiquer avec des applications extérieures au cluster ou avec des pods d'autres clusters. Alors que la communication entre un cluster et une application externe nécessite une seule passerelle, la communication de cluster à cluster nécessite deux passerelles. Le trafic entre deux clusters passe par une passerelle lorsque vous quittez le premier cluster et une autre passerelle lorsque vous passez à l'autre cluster.

Il existe différentes manières de mettre en œuvre les passerelles ou les proxys dans un modèle de réseau isolé. Les mises en œuvre suivantes sont les deux passerelles ou proxys les plus courants :

  • Utilisation des nœuds en tant que passerelles. Cette mise en œuvre est couramment utilisée lorsque les nœuds du cluster font partie du réseau existant et que leurs adresses IP peuvent être routées en mode natif au sein de ce réseau. Dans ce cas, les nœuds eux-mêmes constituent les passerelles qui fournissent une connectivité depuis l'intérieur du cluster vers le réseau le plus grand. Le trafic sortant d'un pod vers l'extérieur du cluster peut être dirigé vers d'autres clusters ou vers des applications autres que Kubernetes, par exemple pour appeler une API sur site sur le réseau d'entreprise. Pour ce trafic de sortie, le nœud contenant le pod utilise la NAT source (SNAT) pour mapper l'adresse IP du pod à l'adresse IP du nœud. Pour permettre aux applications situées en dehors du cluster de communiquer avec les services du cluster, vous pouvez utiliser le type de service NodePort pour la plupart des mises en œuvre. Dans certaines mises en œuvre, vous pouvez utiliser le type de service LoadBalancer pour exposer des services. Lorsque vous utilisez le type de service LoadBalancer, vous attribuez à ces services une adresse IP virtuelle équilibrée entre les nœuds et acheminée vers un pod faisant partie du service.

    Le schéma suivant illustre le modèle de mise en œuvre lorsque les nœuds sont utilisés comme passerelles :

    Schéma du réseau montrant les modèles de communication dans le modèle de réseau en mode île qui utilise des nœuds comme passerelles.

    Le schéma précédent montre que l'utilisation de nœuds en tant que passerelles n'a aucun impact sur la communication entre pods au sein d'un cluster. Les pods d'un cluster continuent de communiquer directement entre eux. Cependant, le diagramme montre également les modèles de communication suivants en dehors du cluster :

    • La manière dont les pods communiquent avec d'autres clusters ou des applications autres que Kubernetes à l'aide de la configuration SNAT lorsqu'ils quittent le nœud.
    • La manière dont le trafic extérieur aux services d'autres clusters ou applications autres que Kubernetes entre dans le cluster via un service NodePort avant d'être transféré vers le pod approprié dans le cluster.

  • Utiliser des machines virtuelles (VM) proxy avec plusieurs interfaces réseau. Ce modèle de mise en œuvre utilise des proxys pour accéder au réseau contenant le cluster Kubernetes. Les proxys doivent avoir accès à l'espace d'adressage IP du pod et du nœud. Dans ce modèle, chaque VM proxy possède deux interfaces réseau : une interface dans le plus grand réseau d'entreprise et une interface dans le réseau contenant le cluster Kubernetes.

    Le schéma suivant illustre le modèle de mise en œuvre lors de l'utilisation de VM proxy :

    Schéma du réseau illustrant les modèles de communication dans le modèle de réseau en mode île qui utilise des VM proxy.

    Le schéma précédent montre que l'utilisation de proxys en mode île n'a pas d'impact sur la communication au sein d'un cluster. Les pods d'un cluster peuvent toujours communiquer directement. Cependant, le diagramme montre également comment la communication entre les pods et les autres clusters ou applications non Kubernetes passe par un proxy qui a accès au réseau du cluster et au réseau de destination. En outre, la communication entrant dans le cluster depuis l'extérieur passe également par le même type de proxy.

Le modèle de réseau en mode île est disponible dans les mises en œuvre suivantes :

  • Par défaut, Azure Kubernetes Service (AKS) utilise une mise en réseau en mode île lors de l'utilisation de la mise en réseau (de base) Kubenet. Lorsque AKS utilise la mise en réseau en mode île, le réseau virtuel qui contient le cluster n'inclut que les adresses IP des nœuds. Les adresses IP des pods ne font pas partie du réseau virtuel. À la place, les pods reçoivent des adresses IP d'un espace logique différent. Le modèle en mode île utilisé par AKS achemine également le trafic entre pods entre les nœuds en utilisant des routes définies par l'utilisateur avec le transfert IP activé sur l'interface des nœuds. Pour la communication de pod avec des ressources extérieures au cluster, le nœud utilise la SNAT pour mapper l'adresse IP du pod à l'adresse IP du nœud avant que le trafic de sortie ne quitte le nœud.
  • Dans Oracle Container Engine pour Kubernetes (OKE), la communication entre les pods utilise un réseau de superposition VXLAN. En outre, le trafic entre les pods et les applications extérieures au cluster utilise la SNAT pour mapper l'adresse IP du pod à l'adresse IP du nœud.

L'utilisation d'un modèle de réseau en mode île présente les avantages suivants :

  • Utilisation des adresses IP. Les adresses IP des pods du cluster peuvent être réutilisées dans d'autres clusters. Toutefois, les adresses IP déjà utilisées par des services externes du réseau d'entreprise ne peuvent pas être utilisées pour les pods si une communication doit être établie entre les pods et ces services. Par conséquent, une bonne pratique de mise en réseau en mode île consiste à réserver un espace d'adressage IP de pod unique au sein du réseau et à utiliser cet espace d'adresses IP pour tous les clusters.
  • Paramètres de sécurité simplifiés. Étant donné que les pods ne sont pas directement exposés au reste du réseau d'entreprise, vous n'avez pas besoin de les sécuriser contre le trafic entrant provenant du reste du réseau d'entreprise.

L'utilisation d'un modèle de réseau en mode île présente les inconvénients suivants :

  • Télémétrie imprécise Les données de télémétrie collectées en dehors du cluster ne contiennent que l'adresse IP du nœud, et non l'adresse IP du pod. L'absence d'adresses IP de pods complique l'identification de la source et de la destination du trafic.
  • Difficile à déboguer. Lors du débogage, vous ne pouvez pas vous connecter directement aux pods depuis l'extérieur du cluster.
  • Configuration de pare-feu plus difficile Vous ne pouvez utiliser les adresses IP des nœuds que lorsque vous configurez votre pare-feu. Ainsi, les paramètres de pare-feu obtenus permettent à tous les pods d'un nœud et au nœud lui-même d'atteindre des services externes, ou aucun d'eux d'atteindre des services externes.

  • Compatibilité avec les maillages de services. En mode île, la communication directe d'un pod à un autre dans les clusters du maillage de services comme Istio ou Anthos Service Mesh n'est pas possible.

    Il existe d'autres restrictions avec certaines mises en œuvre de maillage de services. La compatibilité multicluster Anthos Service Mesh pour les clusters GKE sur Google Cloud n'est possible qu'avec les clusters du même réseau. Pour les mises en œuvre d'Istio compatibles avec un modèle multiréseau, la communication doit se produire via des passerelles Istio, ce qui r de rend le déploiement des maillages de services multiclusters plus complexe.

Modèle de réseau isolé

Le modèle de réseau isolé (ou sous air gap) est le plus souvent utilisé pour les clusters qui n'ont pas besoin d'accéder au réseau d'entreprise plus grand, sauf via des API publiques. Lorsque vous utilisez un modèle de réseau isolé, chaque cluster Kubernetes est isolé et ne peut pas utiliser d'adresses IP internes pour communiquer avec le reste du réseau. Le cluster se trouve sur son propre réseau privé. Si un pod du cluster doit communiquer avec des services extérieurs au cluster, cette communication doit utiliser des adresses IP publiques pour l'entrée et la sortie.

Le schéma suivant illustre les options de communication de pod dans un modèle de réseau isolé :

Schéma du réseau montrant les modèles de communication dans le modèle de réseau isolé.

Le schéma précédent d'un modèle de réseau isolé montre que les pods d'un cluster Kubernetes peuvent communiquer directement entre eux. Il montre également que les pods ne peuvent pas utiliser d'adresses IP internes pour communiquer avec les pods d'autres clusters. De plus, les pods ne peuvent communiquer avec des applications extérieures au cluster que lorsque les critères suivants sont remplis :

  • Une passerelle Internet connecte le cluster à l'extérieur.
  • L'application externe utilise une adresse IP externe pour les communications.

Enfin, le schéma montre comment le même espace d'adresses IP pour les pods et les nœuds peut être réutilisé entre différents environnements.

Le modèle de réseau isolé n'est pas couramment utilisé par les mises en œuvre Kubernetes. Cependant, vous pouvez obtenir un modèle de réseau isolé dans n'importe quelle mise en œuvre. Il vous suffit de déployer un cluster Kubernetes sur un réseau ou un VPC distinct sans aucune connectivité à d'autres services ou au réseau d'entreprise. La mise en œuvre résultante aurait les mêmes avantages et inconvénients que le modèle de réseau isolé.

L'utilisation d'un modèle de réseau isolé présente les avantages suivants :

  • Utilisation des adresses IP. Vous pouvez réutiliser toutes les adresses IP internes du cluster : adresses IP des nœuds, adresses IP des services et adresses IP des pods. La réutilisation d'adresses IP internes est possible, car chaque cluster possède son propre réseau privé et sa communication avec des ressources extérieures au cluster ne se produit que via des adresses IP publiques.
  • Contrôle Les administrateurs de cluster ont un contrôle total sur l'adressage IP dans le cluster et n'ont pas besoin d'effectuer de tâches de gestion d'adresse IP. Par exemple, les administrateurs peuvent allouer l'espace d'adressage complet de 10.0.0.0/8 aux pods et aux services du cluster, même si ces adresses sont déjà utilisées dans l'organisation.
  • Sécurité : La communication en dehors du cluster est étroitement contrôlée et, lorsqu'elle est autorisée, utilise des interfaces externes bien définies et une NAT.

L'utilisation d'un modèle de réseau isolé présente les inconvénients suivants :

  • Aucune communication privée. La communication à l'aide d'adresses IP internes n'est pas autorisée pour les autres clusters ou autres services du réseau.

Modèle de mise en réseau GKE

GKE utilise un modèle de réseau entièrement intégré dans lequel les clusters sont déployés dans un réseau de cloud privé virtuel (VPC) pouvant également contenir d'autres applications.

Nous vous recommandons d'utiliser un cluster de VPC natif pour votre environnement GKE. Vous pouvez créer votre cluster de VPC natif en mode Standard ou Autopilot. Si vous choisissez le mode Autopilot, le VPC natif est toujours activé et ne peut pas être désactivé. Les paragraphes suivants décrivent le modèle de mise en réseau GKE en mode Standard avec des remarques sur les différences avec le mode Autopilot.

Gestion des adresses IP dans les clusters de VPC natif

Lorsque vous utilisez un cluster de VPC natif, les adresses IP des pods sont des adresses IP secondaires sur chaque nœud. Chaque nœud se voit attribuer un sous-réseau spécifique d'une plage d'adresses IP de pod que vous sélectionnez dans votre espace d'adresses IP internes lors de la création du cluster. Par défaut, un cluster de VPC natif attribue un sous-réseau /24 à chaque nœud à utiliser en tant qu'adresses IP de pods. Un sous-réseau /24 correspond à 256 adresses IP. En mode Autopilot, le cluster utilise un sous-réseau /26 correspondant à 64 adresses. Vous ne pouvez pas modifier ce paramètre de sous-réseau.

Le modèle de mise en réseau GKE ne permet pas de réutiliser les adresses IP sur le réseau. Lorsque vous migrez vers GKE, vous devez planifier votre allocation d'adresses IP pour réduire l'utilisation des adresses IP internes dans GKE.

Les adresses IP des pods pouvant être routées dans le réseau VPC, les pods peuvent recevoir par défaut le trafic des ressources suivantes :

Gérer la communication du trafic externe avec l'agent de masquage d'adresses IP

Lorsque vous communiquez depuis des pods sur des services extérieurs au cluster, l'agent de masquage d'adresses IP régit la manière dont le trafic apparaît vers ces services. L'agent de masquage d'adresses IP gère les adresses IP privées et externes différemment, comme indiqué dans les puces suivantes :

Vous pouvez également utiliser des adresses IP publiques utilisées en mode privé (Privately Used Public IPs ou PUPI) dans votre réseau VPC ou vos réseaux connectés. Si vous utilisez des adresses PUPI, vous pouvez toujours bénéficier du modèle de réseau entièrement intégré et afficher l'adresse IP du pod directement en tant que source. Pour atteindre ces deux objectifs, vous devez inclure les adresses PUPI dans la liste nonMasqueradeCIDRs.

Comprendre le flux du trafic des pods dans un réseau GKE

Le schéma suivant montre comment les pods peuvent communiquer dans le modèle de mise en réseau GKE :

Schéma du réseau illustrant les modèles de communication dans le modèle de réseau GKE.

Le schéma précédent montre comment les pods des environnements GKE peuvent utiliser des adresses IP internes pour communiquer directement avec les ressources suivantes :

  • Les autres pods du même cluster.
  • Les pods d'autres clusters GKE dans le même réseau VPC.
  • Les autres applications Google Cloud dans le même réseau VPC.
  • Applications sur site connectées via Cloud VPN

Il montre également ce qui se passe lorsqu'un pod doit utiliser une adresse IP externe pour communiquer avec une application. Lorsque le trafic quitte le nœud, le nœud dans lequel réside le pod utilise la configuration SNAT pour mapper l'adresse IP du pod à l'adresse IP du nœud. Une fois que le trafic a quitté le nœud, Cloud NAT traduit l'adresse IP du nœud en adresse IP externe.

Pour les avantages décrits précédemment dans ce document, en particulier pour l'affichage des adresses IP des pods dans toutes les données de télémétrie, Google a choisi un modèle de réseau entièrement intégré. Dans GKE, les adresses IP des pods sont exposées dans les journaux de flux VPC (y compris les noms de pods dans les métadonnées), dans la mise en miroir de paquets, Journalisation des règles de pare-feu et dans vos propres journaux d'application pour les destinations non masquées.

Étapes suivantes