Découvrir l'architecture réseau GKE

La mise en réseau Google Kubernetes Engine (GKE) utilise et étend l'infrastructure de réseau défini par logiciel (SDN) fournie par le cloud privé virtuel (VPC). La mise en réseau GKE permet à vos composants de communiquer au sein d'un cluster Kubernetes, ainsi qu'avec des services et réseaux externes. Le modèle de mise en réseau GKE s'appuie sur le principe de mise en réseau Kubernetes, où chaque pod reçoit sa propre adresse IP, pour fournir l'adressage IP, l'équilibrage de charge, la résolution DNS et l'application des règles de réseau. Ce document explique comment les composants principaux tels que les nœuds, les pods et les services interagissent avec le plan de contrôle dans le contexte de la mise en réseau GKE. Il aborde les points suivants :

  • Interaction de ces composants dans votre VPC
  • Attribution et gestion des adresses IP
  • Comment le trafic entre, circule et sort du cluster

Architecture d'un réseau GKE

Un réseau GKE s'appuie sur le cloud privé virtuel (VPC) de Google Cloud. Cette base fournit une connectivité robuste et évolutive pour toutes vos applications conteneurisées.

Bases du VPC et plages d'adresses IP

Dans votre VPC, vous définissez des sous-réseaux, qui sont des plages d'adresses IP régionales. GKE utilise stratégiquement différentes plages d'adresses IP dans ces sous-réseaux pour différents composants de cluster, en utilisant souvent des plages d'adresses IP d'alias VPC :

  • Plage d'adresses IP des nœuds : il s'agit de la plage d'adresses IP principale du sous-réseau dans lequel les nœuds de votre cluster sont déployés. Tous vos nœuds de calcul GKE, qui sont des VM Compute Engine, obtiennent leur adresse IP principale à partir de cette plage. Ces adresses IP sont utilisées pour la communication entre les nœuds et pour les vérifications de l'état des équilibreurs de charge. L'adresse IP du nœud est également la source du trafic qui provient du nœud lui-même. Dans les clusters de VPC natif, le trafic provenant des pods utilise l'adresse IP du pod comme adresse source, sauf si l'adresse IP du pod est traduite par une fonctionnalité telle que Cloud NAT.
  • Plage d'adresses IP des pods : plage d'adresses IP secondaire dédiée, souvent un bloc CIDR plus grand, qui se trouve dans votre sous-réseau. Chaque nœud reçoit un pool d'adresses IP de cette plage. GKE attribue ces adresses IP aux pods qui s'exécutent sur ce nœud. Chaque pod de votre cluster reçoit une adresse IP unique de cette plage. Ces adresses IP de pod sont acheminées en mode natif au sein de votre cloud privé virtuel. Par défaut, chaque nœud reçoit une plage /24, qui fournit 256 adresses IP. Toutefois, GKE limite le nombre maximal de pods par nœud à 110. Ce tampon permet de garantir la disponibilité des adresses IP lors de la création et de la suppression rapides de pods, également appelées "churn". Ces adresses IP permettent une communication directe entre les pods de différents nœuds sans nécessiter de traduction d'adresse réseau (NAT).
  • Plage d'adresses IP de service (ClusterIP) : plage d'adresses IP secondaire pour les adresses IP virtuelles (ClusterIP) attribuées aux services Kubernetes. Ces adresses IP stables ne sont utilisées que pour la communication au sein du cluster.
  • Adresse IP du plan de contrôle : chaque plan de contrôle possède une adresse IP publique ou interne, en fonction du type de cluster, de la version et de la date de création. Cette adresse IP est utilisée par les nœuds de calcul et les clients externes, tels que kubectl, pour communiquer de manière sécurisée avec le serveur d'API Kubernetes. GKE Frontend (GKFE) fournit un point de terminaison basé sur le DNS pour chaque cluster, ce qui offre un moyen sécurisé et fiable d'accéder au plan de contrôle sans gérer directement les adresses IP.

Les trois piliers de la mise en réseau GKE

La mise en réseau GKE se compose de trois piliers interconnectés, chacun représentant une couche de communication distincte. Ce framework vous aide à comprendre comment vos applications communiquent au sein du cluster et avec les réseaux externes :

  • Mise en réseau des pods : couche de base qui définit la manière dont les conteneurs individuels (pods) communiquent entre eux au sein du cluster.
  • Mise en réseau des services : cette couche, basée sur la mise en réseau des pods, décrit comment les services Kubernetes fournissent des points de terminaison stables pour exposer les applications aux clients internes ou externes, y compris l'équilibrage de charge et la découverte de services.
  • Mise en réseau du cluster : couche la plus externe, qui couvre la façon dont l'ensemble de votre cluster GKE se connecte à l'écosystème réseau plus large, y compris la gestion de l'entrée depuis Internet, de la sortie vers les services externes et de la connectivité aux services Google Cloud et aux systèmes sur site.

Ces couches fonctionnent ensemble pour créer un modèle de communication complet qui prend en charge la connectivité interne et externe, la sécurité et l'évolutivité. Les sections suivantes explorent chaque pilier en détail.

Mise en réseau de pods

La mise en réseau des pods est la base de toute communication au sein d'un cluster GKE. Il définit la manière dont les applications exécutées dans les pods peuvent se trouver et interagir entre elles. Dans Kubernetes, un pod est l'unité déployable la plus petite et la plus élémentaire. Un pod sert d'hôte logique pour vos applications. Il exécute un ou plusieurs conteneurs qui partagent des ressources réseau. Lorsqu'un pod est planifié sur un nœud, Kubernetes crée un espace de noms réseau dédié dans le noyau Linux du nœud, ce qui isole son réseau des autres pods du même nœud.

Fonctionnement de la mise en réseau des pods

La mise en réseau des pods est établie grâce à une combinaison d'adresses IP uniques, d'appareils réseau virtuels et de plug-ins spécialisés qui gèrent la connectivité.

Container Network Interface (CNI) : GKE utilise des plug-ins CNI pour implémenter et gérer la mise en réseau des pods. Pour les clusters de VPC natif, la valeur par défaut est Google CNI. Les autres options incluent kubenet (pour les clusters non natifs au VPC), Calico et GKE Dataplane V2 (qui est basé sur Cilium). Ces plug-ins sont chargés de connecter les pods au réseau et d'appliquer les règles réseau.

  • Attribution d'adresses IP : chaque nœud reçoit un pool d'adresses IP de la plage d'adresses IP des pods à attribuer aux pods. GKE réserve une partie de ces adresses pour créer un tampon qui garantit la disponibilité des adresses IP lors d'un turnover rapide des pods (création et destruction). Cette réservation explique pourquoi le nombre d'adresses IP de pod pouvant être allouées par nœud est toujours inférieur à la taille de la plage.

  • Espaces de noms réseau et paires Ethernet virtuelles (veth) : pour faciliter la communication, Kubernetes connecte l'espace de noms réseau isolé du pod à l'espace de noms réseau principal (ou racine) du nœud. Kubernetes établit cette connexion à l'aide d'une paire Ethernet virtuelle, ou paire veth, qui agit comme un câble réseau virtuel. L'une des extrémités de la paire est placée dans l'espace de noms du pod et apparaît sous la forme eth0. L'autre extrémité se connecte à un pont réseau ou directement à la pile réseau du nœud dans l'espace de noms racine du nœud, ce qui permet ensuite aux paquets de circuler vers et depuis le pod.

    La méthode de connexion spécifique dépend du plug-in CNI utilisé par votre cluster :

    • Google CNI : il s'agit du CNI par défaut pour les clusters VPC natifs. La paire veth du pod se connecte à l'espace de noms réseau racine du nœud. Étant donné que les adresses IP des pods sont des adresses IP d'alias connues du réseau VPC, le routage Linux standard sur le nœud dirige le trafic vers et depuis le pod.
    • GKE Dataplane V2 : utilise des programmes eBPF pour gérer la mise en réseau des pods et contourne souvent les ponts Linux et les paires veth conventionnels pour gérer directement les flux de paquets dans le noyau afin d'améliorer les performances.
    • Kubenet : utilisé dans les clusters non VPC natifs. L'autre extrémité de la paire veth se connecte à un périphérique de pont Linux appelé cbr0 dans l'espace de noms racine du nœud. Ce pont gère le trafic entre les pods d'un même nœud et utilise NAT pour le trafic qui quitte le nœud.
    • Calico : lorsque les règles de réseau sont activées avec Calico, l'autre extrémité de la paire veth se connecte à l'espace de noms racine du nœud, et Calico programme ensuite les routes de l'hôte pour diriger le trafic vers les bons pods.

Unité de transmission maximale (MTU) : elle détermine la taille maximale des paquets qui peuvent être envoyés sur un réseau sans être fragmentés. Dans GKE, la MTU de l'interface d'un pod est un paramètre essentiel qui dépend du plug-in CNI GKE utilisé par le cluster et des paramètres de MTU du réseau VPC sous-jacent. Une différence entre les valeurs de MTU peut entraîner une perte de paquets ou une dégradation des performances. La valeur de la MTU de l'interface de pod est de 1 460 octets ou est héritée de l'interface réseau principale du nœud, comme indiqué dans le tableau suivant.

CNI MTU Utilisation
Google CNI 1460 Valeur par défaut pour les clusters VPC natifs qui utilisent des versions de GKE antérieures à la version 1.26.1.
Google CNI Hérité Valeur par défaut pour les clusters de VPC natif qui utilisent GKE version 1.26.1 et ultérieure.
Calico 1460 Utilisé lorsque la règle de réseau est activée (--enable-network-policy).
GKE Dataplane V2 Hérité Utilisé lorsque GKE Dataplane V2 est activé (--enable-dataplane-v2).
netd Hérité Utilisé lorsque des fonctionnalités telles que la visibilité "Intranode", la fédération d'identité de charge de travail pour GKE ou la mise en réseau à double pile IPv4/IPv6 sont activées.

Flux de communication entre pods

Kubernetes utilise un modèle de réseau plat, dans lequel chaque pod possède une adresse IP unique et routable. Ce modèle permet d'assurer une connectivité fluide entre les pods.

Communication au sein d'un même nœud

Lorsqu'un pod envoie du trafic à un autre pod sur le même nœud, la requête transite de l'espace de noms réseau du premier pod, via sa paire veth, vers l'espace de noms réseau racine du nœud. Ce trafic reste dans le nœud. En fonction du plug-in CNI utilisé, le plug-in CNI transfère ensuite le trafic vers la paire veth du deuxième pod. Par exemple, avec kubenet, un appareil pont transfère le trafic. Avec GKE Dataplane V2, les programmes eBPF gèrent directement le flux de paquets.

Communication entre différents nœuds

Lorsqu'un pod d'un nœud envoie du trafic à un pod d'un autre nœud, le trafic est acheminé vers l'espace de noms réseau racine du premier nœud. Le trafic quitte ensuite l'interface réseau principale du premier nœud et entre dans le réseau VPC. Les adresses IP des pods étant routables en mode natif dans un cluster GKE natif au VPC, le réseau VPC achemine le trafic directement vers le deuxième nœud. Le deuxième nœud transfère ensuite le trafic vers le pod de destination.

Pods du réseau hôte

Pour des cas d'utilisation spécifiques, vous pouvez configurer un pod avec le paramètre hostNetwork: true. Ce paramètre contourne le réseau de pods isolé et permet au pod de partager directement l'espace de noms réseau du nœud. Grâce à cet accès direct, le pod utilise l'adresse IP du nœud et peut communiquer avec tous les autres pods sans avoir besoin de NAT. Dans les clusters qui utilisent le plug-in CNI kubenet, ce comportement est différent de celui des pods standards. Les pods standards nécessitent une traduction d'adresse réseau (NAT) pour le trafic sortant, car leurs adresses IP ne sont pas directement routables sur le réseau VPC. En revanche, la mise en réseau VPC-native de GKE rend cette traduction inutile pour tous les pods. Toutefois, lorsque vous configurez des pods avec le paramètre hostNetwork: true, veillez à éviter les conflits de ports avec d'autres processus ou pods qui s'exécutent sur le même nœud. Dans les clusters qui utilisent le CNI kubenet, le pont réseau virtuel cbr0 n'est créé que si le nœud comporte des pods qui ont le paramètre hostNetwork: false.

Mise en réseau des services

Bien que la mise en réseau des pods fournisse la connectivité de base entre les pods individuels, elle ne suffit pas à créer des applications robustes et évolutives. Les pods sont éphémères : ils peuvent être créés, détruits et reprogrammés à tout moment. Dans ce cas, leurs adresses IP changent. Le réseau de services résout ce problème en fournissant un moyen stable et fiable d'exposer les applications et de gérer leur communication, à la fois au sein du cluster et avec le monde extérieur.

Un service Kubernetes est une abstraction qui définit un ensemble logique de pods et une règle permettant d'y accéder. Les services utilisent des libellés pour regrouper plusieurs pods associés dans une seule unité logique. Lorsque vous créez un service, Kubernetes lui attribue une adresse IP virtuelle stable, appelée ClusterIP, à partir d'un pool d'adresses réservées aux services. Cette adresse ClusterIP, ainsi que le nom DNS associé, restent constants pendant tout le cycle de vie du service. Ils fournissent un point de terminaison cohérent que les autres applications peuvent utiliser pour se connecter aux pods.

Fonctionnement du réseau de service

La mise en réseau des services repose sur deux mécanismes clés pour acheminer le trafic depuis le point de terminaison stable d'un service vers ses pods de backend dynamiques : la détection de services et l'équilibrage de charge.

Découverte des services : pour que les applications puissent se trouver et communiquer entre elles, GKE fournit un service DNS interne (kube-dns ou Cloud DNS). Lorsque vous créez un service, le service DNS crée automatiquement un enregistrement DNS correspondant. Cet enregistrement permet aux applications de se connecter au service à l'aide de son nom DNS (par exemple, my-app-service) au lieu d'avoir besoin de connaître son adresse ClusterIP. Bien que kube-dns soit la valeur par défaut pour les clusters standards, Cloud DNS pour GKE est la solution recommandée pour la plupart des environnements de production. Il s'agit également de la seule solution compatible avec les clusters GKE Autopilot. Ce service est entièrement géré, évolutif et à disponibilité élevée. Il s'intègre à la mise en réseau VPC et à Cloud Logging, ce qui améliore les performances et l'observabilité sans que vous ayez à gérer les pods kube-dns.

Mécanismes d'équilibrage de charge : l'implémentation de l'équilibrage de charge de service dépend du mode réseau de votre cluster GKE.

  • GKE Dataplane V2 : les clusters qui utilisent GKE Dataplane V2 (basé sur Cilium) n'utilisent pas kube-proxy pour l'équilibrage de charge des services. À la place, GKE Dataplane V2 utilise des programmes eBPF qui s'exécutent dans le noyau Linux. Ces programmes eBPF sont très efficaces pour intercepter le trafic vers les adresses ClusterIP de service et équilibrer directement la charge du trafic vers les pods de backend appropriés. Cette approche permet d'améliorer les performances et est étroitement intégrée aux fonctionnalités d'application des règles de réseau de GKE Dataplane V2.

  • kube-proxy (pour les clusters sans GKE Dataplane V2) : sur chaque nœud d'un cluster GKE qui n'utilise pas GKE Dataplane V2, un composant appelé kube-proxy implémente le mécanisme d'adresse IP virtuelle pour les services. kube-proxy surveille le serveur d'API Kubernetes pour détecter les modifications apportées aux services et aux points de terminaison, puis programme les règles réseau sur le nœud pour intercepter le trafic destiné à l'adresse ClusterIP d'un service.

    kube-proxy peut fonctionner dans différents modes, y compris les suivants :

    • Mode iptables : il s'agit du mode par défaut. kube-proxy ajoute et supprime des règles de traduction d'adresse réseau de destination (DNAT) dans le sous-système iptables du nœud. Lorsque du trafic arrive pour l'adresse ClusterIP d'un service, ces règles effectuent une traduction NAT et remplacent l'adresse IP de destination par l'un des pods de backend sains. L'équilibrage de charge entre les pods de backend est généralement aléatoire ou de type "round robin".
    • Mode ipvs : ce mode utilise le serveur virtuel IP (IPVS) Linux pour un équilibrage de charge hautes performances. kube-proxy configure les règles IPVS, qui peuvent gérer un grand nombre de services et fournir des algorithmes d'équilibrage de charge plus sophistiqués.

Exemple de flux de communication interne

La liste suivante décrit le flux d'une requête d'un pod client vers un pod serveur à l'aide d'un service dans un cluster qui n'utilise pas GKE Dataplane V2 :

  1. L'application cliente effectue une requête DNS pour my-server-service.
  2. Le service DNS interne du cluster résout ce nom en adresse ClusterIP stable du service (par exemple, 10.0.32.8).
  3. Le pod client envoie une requête à l'adresse ClusterIP du service.
  4. Les règles iptables sur le nœud du client, gérées par kube-proxy, interceptent cette requête.
  5. Ces règles iptables effectuent la DNAT et sélectionnent l'un des pods de backend opérationnels pour my-server-service (par exemple, le pod 2 avec l'adresse IP 10.4.0.3). Les règles réécrivent également l'adresse IP de destination du paquet sur l'adresse IP du pod.
  6. Le paquet est acheminé via le réseau de pods plat vers le pod 2, qui traite la requête.

Dans les clusters qui utilisent GKE Dataplane V2, les programmes eBPF gèrent l'interception et l'équilibrage de charge du trafic vers l'adresse ClusterIP du service, en contournant kube-proxy et iptables.

Exemple de fichier manifeste de service

L'exemple suivant illustre un fichier manifeste de service. Le champ selector spécifie les pods qui reçoivent du trafic en fonction de leurs libellés.

apiVersion: v1
kind: Service
metadata:
  name: my-server-service
spec:
  selector:
    app: my-server # This should match the labels on your server Pods
  ports:
  - protocol: TCP
    port: 80 # The port the Service exposes
    targetPort: 8080 # The port the containers in the Pods are listening on

Fonctionnalités de la mise en réseau de services

La mise en réseau de services GKE offre plusieurs fonctionnalités pour gérer le flux de trafic et exposer les applications, en interne comme en externe.

  • Équilibrage de charge interne et externe : pour les services qui ne doivent être accessibles qu'à partir du cluster, kube-proxy (ou GKE Dataplane V2) gère l'équilibrage de charge en interne. Pour les services qui doivent être exposés à Internet, GKE provisionne automatiquement un équilibreur de charge cloud afin de distribuer le trafic externe aux nœuds du cluster.
  • Équilibreurs de charge d'application pour le routage HTTP(S) : pour le trafic HTTP(S), GKE utilise un équilibreur de charge de couche 7 spécialisé, l'équilibreur de charge d'application. Vous configurez cet équilibreur de charge à l'aide de l'API Kubernetes Gateway, qui est l'approche recommandée pour toutes les nouvelles applications. Le contrôleur GKE Gateway est l'implémentation par Google de l'API Gateway. Il est conçu pour être un successeur plus expressif, flexible et extensible de la ressource Ingress. L'API Gateway utilise les ressources suivantes pour configurer l'équilibreur de charge :
    • Gateway : définit les configurations d'écouteur telles que les ports, les protocoles et les noms d'hôte. Il sert de point d'entrée pour le trafic.
    • HTTPRoute : spécifie la manière dont le trafic reçu par une passerelle est acheminé vers les services. Il est compatible avec des fonctionnalités avancées telles que le routage basé sur le chemin d'accès, la correspondance des en-têtes et la répartition du trafic.
    • Policy : définit le fonctionnement de l'infrastructure Google Cloud sous-jacente en étant associée à une passerelle, une route ou un service.
  • Intégration du maillage de services : pour les architectures de microservices complexes, GKE est compatible avec les technologies de maillage de services. Un maillage de services est une couche d'infrastructure facultative qui fournit des fonctionnalités avancées pour la gestion du trafic, l'observabilité et la sécurité. Pour une expérience entièrement gérée et compatible, GKE propose Cloud Service Mesh, qui est basé sur Istio.

Mise en réseau des clusters

La mise en réseau du cluster est la couche la plus externe de la mise en réseau GKE. Il se concentre sur la façon dont l'ensemble de votre cluster Kubernetes interagit avec les ressources et les réseaux externes, y compris la façon dont les clients Internet accèdent à vos applications, dont vos pods accèdent aux API externes et dont votre cluster se connecte aux centres de données sur site. La mise en réseau des clusters repose sur l'infrastructure VPC de Google Cloud.

Gérer le trafic entrant

Ingress est le trafic qui entre dans votre cluster depuis le monde extérieur. GKE utilise plusieurs fonctionnalités Google Cloud intégrées pour gérer et sécuriser ce trafic.

Flux de données d'accès externe : lorsqu'un client provenant d'Internet envoie une requête à votre application (généralement exposée via un service de type LoadBalancer ou une ressource Ingress ou Gateway), elle atteint d'abord un équilibreur de charge Google Cloud . L'équilibreur de charge achemine la requête vers un nœud opérationnel de votre cluster. Le nœud transfère le trafic vers le pod approprié. kube-proxy gère ce transfert sur les clusters qui n'utilisent pas GKE Dataplane V2, ou les programmes eBPF le gèrent dans les clusters qui utilisent GKE Dataplane V2. Le pod de destination peut se trouver sur le même nœud ou sur un nœud différent.

Règles de pare-feu : les clusters GKE utilisent des règles de pare-feu VPC pour contrôler le trafic entrant. Bien que GKE crée automatiquement des règles de pare-feu par défaut pour les opérations de cluster essentielles, comme autoriser le plan de contrôle à atteindre les nœuds, vous pouvez définir des règles personnalisées pour répondre à vos exigences de sécurité spécifiques. Ces règles de pare-feu VPC fonctionnent avec les règles de réseau Kubernetes pour assurer une défense en profondeur en contrôlant le trafic au niveau des nœuds et des pods.

Optimisation du flux de trafic externe : lorsqu'un équilibreur de charge envoie du trafic à un nœud, celui-ci peut avoir besoin de transférer ce trafic à un pod situé sur un autre nœud, ce qui nécessite des sauts de réseau supplémentaires. Pour éviter cette situation, définissez le champ externalTrafficPolicy sur Local dans le fichier manifeste du service. Lorsque cette règle est active, l'équilibreur de charge utilise une vérification de l'état'état pour identifier les nœuds qui possèdent des pods sains pour le service cible. L'équilibreur de charge n'envoie le trafic qu'aux pods opérationnels, ce qui évite le saut de réseau supplémentaire. L'inconvénient est que cette règle peut entraîner une répartition inégale du trafic si vos pods de backend ne sont pas répartis de manière égale entre les nœuds de votre cluster.

Gérer le trafic sortant

La sortie correspond au trafic qui quitte votre cluster. Pour qu'un cluster GKE fonctionne et que vos applications puissent accéder aux services externes, vous devez gérer plusieurs chemins de connectivité.

Exigences fondamentales en matière de connectivité : tous les clusters GKE nécessitent une connectivité sortante vers les domaines *.googleapis.com, *.gcr.io et *.pkg.dev. La connectivité sortante à l'adresse IP du plan de contrôle doit également fonctionner correctement. Accès à Internet pour les pods à l'aide de Cloud NAT : dans les clusters privés où les pods ne disposent pas d'adresses IP publiques, utilisez Cloud NAT pour activer l'accès à Internet sortant. Cloud NAT est un service géré qui permet aux pods de se connecter à Internet pour des tâches telles que le téléchargement de mises à jour ou l'accès à des API externes, sans les exposer aux connexions entrantes.

Connectivité aux services : si vous devez autoriser votre cluster à communiquer de manière sécurisée avec d'autres services Google Cloud , tels que Cloud Storage ou Cloud SQL, sans passer par l'Internet public, utilisez l'accès privé à Google. Google Cloud Il s'agit d'un mécanisme de sortie important pour les clusters privés qui interagissent avec les API Google.

Connectivité hybride et multicluster

Pour connecter vos clusters GKE à une infrastructure sur site, utilisez Cloud VPN pour les tunnels chiffrés ou Cloud Interconnect pour les connexions dédiées à bande passante élevée. Pour activer la communication entre plusieurs clusters GKE, utilisez les services multiclusters. Ils facilitent la détection de services et le flux de trafic entre différents clusters, régions ou projets.

Contrôles de sécurité du réseau

Pour protéger votre cluster et les applications qui y sont exécutées, GKE fournit plusieurs niveaux de contrôles de sécurité pour le trafic interne (est-ouest) et externe (nord-sud).

Sécuriser le trafic interne (est-ouest) avec des règles de réseau

Par défaut, tous les pods d'un cluster GKE peuvent communiquer librement entre eux. Pour sécuriser le trafic interne et appliquer le principe du moindre privilège, vous pouvez utiliser NetworkPolicy. Un NetworkPolicy est une ressource Kubernetes qui sert de pare-feu pour vos pods en contrôlant le trafic réseau entre eux. Les ressources NetworkPolicy vous permettent de définir des règles pour limiter le trafic d'entrée et de sortie d'un groupe de pods sélectionné en fonction d'une combinaison de libellés, de plages d'adresses IP et de numéros de port. Lorsque vous créez la première NetworkPolicy dans un espace de noms, tout le trafic qui n'est pas explicitement autorisé par cette règle est refusé. L'application de ces règles est directement intégrée à GKE Dataplane V2 ou gérée par le plug-in CNI du cluster, tel que Calico.

Exemple de fichier manifeste NetworkPolicy

L'exemple suivant illustre un fichier manifeste NetworkPolicy. Cette règle s'applique aux pods portant l'étiquette app: backend et n'autorise le trafic entrant que depuis les pods portant l'étiquette app: frontend sur le port TCP 6379.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-policy
spec:
  podSelector:
    matchLabels:
      app: backend
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend
    ports:
    - protocol: TCP
      port: 6379

Sécuriser l'accès externe au cluster

Il est essentiel de contrôler le trafic entrant et sortant de votre cluster pour protéger vos applications contre les menaces externes.

Règles de pare-feu VPC

Les clusters GKE résident dans un réseau VPC Google Cloud et sont protégés par des règles de pare-feu VPC qui contrôlent le trafic vers et depuis les nœuds du cluster. Les règles de pare-feu VPC et les stratégies réseau fonctionnent ensemble pour assurer une défense en profondeur. Les pare-feu VPC fonctionnent au niveau des nœuds (couche 3 ou 4) et contrôlent le trafic vers les VM elles-mêmes. Les règles de réseau fonctionnent au niveau du pod (couche 3 ou 4) et offrent un contrôle plus précis du trafic entre les applications à l'intérieur du cluster.

La création de règles de pare-feu d'entrée ou de sortie ciblant les nœuds de votre cluster peut avoir des effets négatifs. Par exemple, l'application de règles de refus de sortie aux nœuds de votre cluster peut interrompre des fonctionnalités telles que NodePort et kubectl exec.

Restreindre l'accès aux équilibreurs de charge

Lorsque vous exposez des applications à l'aide d'un service ou d'un Ingress Kubernetes, vous pouvez appliquer des contrôles de sécurité supplémentaires au niveau de l'équilibreur de charge. Pour les équilibreurs de charge externes, envisagez les options suivantes :

  • Si vous exposez un service à l'aide du champ type: LoadBalancer, vous pouvez spécifier le champ loadBalancerSourceRanges dans le fichier manifeste de votre service. Ce champ limite l'accès au Service aux plages d'adresses IP que vous définissez.

  • Pour les équilibreurs de charge d'application (Ingress), vous pouvez utiliser des services de sécurité plus avancés lorsque vous exposez des applications HTTP(S) :

    • Google Cloud Armor : ce service est un pare-feu d'application Web (WAF) qui vous aide à protéger vos applications contre les attaques DDoS et d'autres menaces sur le Web.
    • Identity-Aware Proxy (IAP) : pour un contrôle des accès précis, vous pouvez activer IAP sur vos points de terminaison. IAP vérifie l'identité d'un utilisateur et l'utilise pour déterminer si celui-ci doit être autorisé à accéder à l'application.

Étapes suivantes