Comprendre la mise en réseau dans GKE

Principes de base de la mise en réseau

L’orchestrateur Kubernetes s’est imposé comme la plateforme open source de référence pour gérer les workloads et services containerisés. Créé à l’origine par Google, il trouve en GKE (Google Kubernetes Engine) une implémentation optimale afin de vous permettre d’exécuter Kubernetes et vos containers au sein de l’infrastructure Google Cloud dans un environnement entièrement managé. 

GKE et Kubernetes reposent sur quelques piliers techniques communs qu’il est important de connaître. Le réseau est bien évidemment l’un d’eux. Nous vous proposons ici d’explorer les composantes réseau de GKE (Google Kubernetes Engine) et les différentes options disponibles.

L’adressage IP

Pour communiquer entre eux, les différents composants réseau de Kubernetes utilisent, comme on peut s’en douter, des adresses IP et des ports pour communiquer. Pour rappel, les adresses IP sont des adresses uniques qui identifient les différents composants du réseau.

Les composants clés :

• Les containers - Il s'agit des plus petits composants d'exécution des processus applicatifs. Un ou plusieurs containers sont exécutés au sein d’un « pod ».
  

• Les Pods – Les Pods regroupent « physiquement » une collection de containers. Les pods sont affectés à des nœuds.
  

• Les Nœuds - Les nœuds sont des machines de travail (des serveurs) au sein d’un cluster Kubernetes (un cluster est donc une collection de nœuds). Un nœud exécute zéro ou plusieurs pods.
  

Les services clés :

• ClusterIP - Ces adresses IP internes au cluster permettent d’exposer les services.
  

• Load Balancer – Assure l’équilibrage des charges du trafic interne ou du trafic externe vers les nœuds du cluster.
  

• Ingress – est un type spécial d'équilibreur de charge (load balancer) qui gère le trafic HTTP(S).

Les adresses IP sont attribuées aux composants et aux services à partir de différents sous-réseaux. Des masques de sous-réseau à longueur variable (VLSM) sont utilisés pour créer des blocs CIDR. Le nombre d'hôtes disponibles sur un sous-réseau dépend du masque de sous-réseau utilisé.

Remarque : la formule pour calculer le nombre d’hôtes disponibles dans Google Cloud est 2n- 4, et non 2n- 2 contrairement aux usages classiques des réseaux « on prem » (sur site).

Le flux d'attribution des adresses IP se présente comme suit :

1/ Les nœuds se voient attribuer des adresses IP à partir du réseau VPC du cluster.

2/ Par défaut, les adresses IP des Load Balancers internes sont automatiquement attribuées à partir du bloc IPv4 du nœud. Si nécessaire, vous pouvez créer une plage spécifique pour vos Load Balancers en utilisant l'option loadBalancerIP.

3/ Les pods se voient attribuer des adresses IP à partir de la plage assignée aux pods pour le nœud considéré. Par défaut, le nombre maximal de pods par nœud est de 110. Pour allouer une adresse à ce nombre, ce nombre est multiplié par 2 (110*2=220) et le sous-réseau le plus proche est utilisé, soit une place CIDR /24.
Ce mécanisme permet d'avoir un tampon pour la planification des pods. Il est important de se souvenir que si ce nombre maximal de pods par nœud est personnalisable au moment de la création, il ne peut être modifié une fois le cluster créé.

4/ Les containers partagent l'adresse IP des pods sur lesquels ils fonctionnent.

5/ Les adresses IP des services (Cluster IP) sont attribuées à partir d'un pool d'adresses réservé aux services.

Vous trouverez dans la bible technique « VPC-native clusters », au sein de la section dédiée aux plages d’adresses IP, un exemple de planification et de délimitation des plages d'adresses.

Le DNS (Système de nom de domaine)

Le DNS permet la résolution de noms en adresses IP. Des entrées de nom de domaine sont automatiquement créées dans le DNS pour les différents services. Il existe quelques options dans GKE pour contrôler le DNS.

• kube-dns - Service complémentaire natif de Kubernetes, Kube-dns permet par défaut aux différents pods d'un cluster de résoudre les requêtes DNS. Le document "Using kube-dns'' décrit son fonctionnement.
  

• Cloud DNS - Il s'agit du service DNS managé de Google Cloud. Il peut être utilisé pour gérer le DNS de votre cluster. Utiliser Cloud DNS en lieu et place de kube-dns présente quelques avantages. En effet, Cloud DNS :

• Élimine (au moins en partie) la gestion d'un serveur DNS hébergé au sein du cluster.

• Prend en charge la résolution locale DNS sur les nœuds GKE. Cela se fait par une mise en cache locale des réponses, ce qui offre à la fois vitesse et évolutivité.

• S'intègre à la suite de surveillance Google Cloud Operations.

Service Directory est un autre service de Google Cloud qui peut être intégré à GKE et à Cloud DNS pour gérer les services via des espaces de noms (namespaces). Le repo github « gke-networking-recipes » contient quelques exemples de Service Directory que vous pouvez essayer pour les LoadBalancers internes, ClusterIP, Headless et NodePort.

Pour une meilleure compréhension des différentes options DNS dans GKE, veuillez consulter l'article DNS sur GKE : tout ce que vous devez savoir.

Les Load Balancers

Les Load Balancers (ou services d’équilibrage de charge) contrôlent l'accès et distribuent le trafic sur les ressources du cluster. Voici quelques options à connaître dans GKE :

• Load Balancers internes

• Load Balancers externes

Ingress

Les Ingress sont des objets Kubernetes qui gèrent l’accès externe aux services d’un cluster et le trafic HTTP(S) correspondant. Lorsqu'un tel objet (une telle ressource) est utilisé, il crée un Load Balancer HTTP(S) pour GKE. Lors de la configuration, vous pouvez attribuer une adresse IP statique à l'équilibreur de charge, afin de garantir que l'adresse reste la même.

Dans GKE, vous pouvez provisionner à la fois des Ingress externes et internes. Les liens vers les guides ci-dessous vous montrent comment les configurer :

• Configuration d’ingress pour un load balancing interne HTTP(S)

• Configuration d'ingress pour un load balancing externe

GKE vous permet de tirer profit du load balancing natif des containers, qui dirige le trafic directement vers l'IP du pod à l'aide des groupes d'extrémité de réseau (NEG – Network Endpoint Group).

Le service de routage

Au niveau routage, trois concepts principaux doivent retenir votre attention : 

• Frontend - Votre service est exposé aux clients par le biais d'un « frontend » : ce dernier accepte le trafic en fonction de diverses règles. Il peut s'agir d'un nom DNS ou d'une adresse IP statique.
  

• Load Balancing - Une fois que le trafic est autorisé, l'équilibreur de charge distribue les ressources disponibles pour répondre à la demande en fonction des règles.
  

• Backend - Différents points de terminaison qui peuvent être utilisés dans GKE. 

Opérations

Dans GKE, vous avez plusieurs façons de concevoir la mise en réseau de vos clusters :

• Standard - Ce mode permet à l'administrateur de configurer l'infrastructure sous-jacente des clusters. Ce mode est avantageux si vous avez besoin d'un niveau de contrôle et de responsabilité plus approfondi.
  

• AutoPilot (Pilote automatique) - GKE fournit et gère l'infrastructure sous-jacente du cluster. Pratique et préconfiguré pour s’adapter à tous les usages, ce mode vous offre néanmoins une certaine liberté de gestion.
  

• Private Cluster (Cluster privé) - Ce mode n'autorise que les connexions IP internes. Si vous avez néanmoins besoin qu'un client ait accès à l'Internet (par exemple, pour des mises à jour), vous pouvez utiliser un Cloud NAT.
  

• Private Service Access – Ce mode permet à votre VPC de communiquer avec les services des fournisseurs (de service) via des adresses IP privées. Le service Private Service Connect permet la consommation privée de services à travers les réseaux VPC (Virtual Private Cloud).

En résumé

Regroupés, tous ces éléments permettent de rapidement tracer un paysage de la gestion réseau sous GKE. Une vue de haut niveau qui peut se résumer ainsi :

• Des adresses IP sont assignées aux différentes ressources de votre clusters : Nœuds, Pods, Containers et Services.

• Ces plages d’adresses IP sont réservées aux différents types de ressources. Vous avez la possibilité d'ajuster la taille de la plage pour répondre à vos besoins en définissant un sous-réseau. Il est recommandé de restreindre les accès externes inutiles à votre cluster.

• Par défaut, les pods ont la possibilité de communiquer à travers le cluster. 

• Pour exposer les applications fonctionnant sur les pods, vous avez besoin d'un service.

• Des adresses IP de clusters (Cluster IPs) sont attribuées aux services.

• Pour la résolution DNS, vous pouvez vous appuyer sur une option native telle que « kube-dns » ou utiliser Google Cloud DNS au sein de votre cluster GKE.

• Les Load Balancers peuvent être utilisés en interne et en externe avec votre cluster pour exposer les applications et distribuer le trafic.

• Ingress gère le trafic HTTP(S). Il utilise le service de load balancing HTTP(S) de Google Cloud. Ingress peut être utilisé pour des configurations internes et externes.

Pour en savoir plus sur la mise en réseau GKE, consultez les documents suivants :

Documentation : Stratégies de gestion des adresses IP lors de la migration vers GKE

Documentation : Bonnes pratiques pour la mise en réseau GKE

Blog : DNS sur GKE : tout ce que vous devez savoir

YouTube : Concepts de mise en réseau de GKE