Aller vers le contenu principal

Avis d'expert

S’affranchir des contraintes du nombre d’IP utilisées dans un environnement Elastic Kubernetes Service (EKS)

Publié le 17/11/2022

Les grands groupes sont dans une démarche d’hybridation entre AWS et leurs datacenters. Ils ne peuvent mettre à disposition des environnements AWS qu’un nombre limité d’adresses IPV4s privées.

Les clusters EKS

Les clusters EKS doivent être des plateformes pérennes pouvant héberger les applications containerisées existantes ou à venir. Ces clusters doivent donc être capables d’avoir un nombre important de pods, et donc par extension d’adresse IP. Ce nombre d’IP est généralement difficile à estimer à priori.

Ce challenge difficilement identifiable et quantifiable est présent dans les environnements de non-production, tout comme de production. Cela peut mener à des blocages, puisque de nouveaux pods pourraient ne pas être créés par manque d’IPs.

Prérequis

Choisir une plage d’IP qui sera associée aux pods EKS, et qui sera considérée comme non routable sur le réseau de l’entreprise.
Dans notre exemple nous choisissons la plage 10.100.0.0/16

Déployer une AWS Transit Gateway (TGW). Ce routeur cloud permet de connecter les Amazon Virtual Private Cloud (VPC) ainsi que les réseaux sur site.

Dans notre exemple, la transit gateway et les éléments liés ont été livrés par l’équipe réseau.

Architecture

Mise en place

Elle s’effectue en plusieurs étapes :

1 – Déclarer la plage d’IP en tant que blackhole dans les tables de routage de la transit gateway

2 – Ajouter cette plage d’IP à chaque VPC hébergeant des clusters EKS, et créer des subnets avec ce range d’IP.

En ayant créé précédemment la route blackhole sur la transit gateway, nous nous assurons qu’aucune connexion ne pourra s’effectuer entre les VPC modifiés.

3 – Créer une private NAT Gateway sur un subnet privé routable pour autoriser les flux sortant des pods :

4 – Configurer la table de routage des subnets des pods pour utiliser la NAT gateway

5 – Conserver le point d’entrée du cluster EKS dans les réseaux privés routables.

Il est nécessaire que le load balancer soit dans des subnets routables, sinon le cluster EKS ne pourra plus être accessible en dehors du VPC.

Flux réseau

Entre les pods et les autres workload de VPC1

La plage d’IP supplémentaire associée au VPC permet aux pods d’échanger directement avec n’importe quel workload interne au VPC. Les tables de routages créées dans ce VPC incluent automatiquement toutes les plages d’IPs du VPCs

Depuis les pods de VPC1 vers l’extérieur du VPC

Le flux réseau est initié par le pod (1) et celui-ci va utiliser la private NAT Gateway. La translation d’IP est effectuée par la NAT Gateway et le flux (2) devient donc routable à l’extérieur du VPC, et peut par exemple joindre le datacenter (3). Pour les workloads de production, l’utilisation d’au moins 2 private NAT gateway est recommandée.

Depuis un client hors de VPC1

Un client externe va utiliser le load balancer pour utiliser les services exposés, ce design n’a pas d’influence sur ce point.

Entre les Pods de VPC1 et VPC2

Le Pod de la VPC1 va passer par la Nat Gateway pour envoyer sa requête (1), la translation d’IP va s’effectuer et la requête va pouvoir sortir du VPC (2). La requête va ensuite traverser le load balancer de l’EKS du VPC2 (3) et va être redirigée vers un pod pouvant répondre à la requête (4).

Résultats

La solution proposée n’a de l’influence que sur les flux réseaux partant d’un pod vers l’exterieur de la VPC.

Nous avons mesuré via 100 requêtes ICMP (Internet Control Message Protocol) un délai moyen supplémentaire d’environ 100ms.

Commande exécutée

> ping -c 100 -A -n

-c 100 : envoi de 100 requêtes ICMP

-A : L’intervalle inter-paquets s’adapte au délai aller-retour, pour réduire l’attente du résultat

-n : pas de résolution de nom

Architecture source (sans NAT Gateway)

— 10.1.0.19 ping statistics —

100 packets transmitted, 100 received, 0% packet loss, time 19900ms

rtt min/avg/max/mdev = 0.635/0.730/1.229/0.094 ms, ipg/ewma 201.016/0.725 ms

Architecture cible (traversant la Private NAT Gateway)

— 10.1.0.19 ping statistics —

100 packets transmitted, 100 received, 0% packet loss, time 19884ms

rtt min/avg/max/mdev = 0.737/0.893/2.360/0.220 ms, ipg/ewma 200.850/1.031 ms

Limites

Il en existe 2 principales :

Les exemples, cités en introduction, montrent qu’il est nécessaire d’avoir un inventaire précis des adresses IP disponibles, et une stratégie d’utilisation. 

Cette solution utilise des concepts réseaux classiques de NAT, exploités pour palier à la quantité limitée d’adresse IP en IPV4, qui peut se présenter lors de l’utilisation d’EKS.

Elle pourrait être également utilisée on-premise. Cela n’est pas forcément nécessaire, car d’autre outils directement intégrables à Kubernetes (tel que cilium par exemple) permettent de gérer plus facilement les IPs disponibles.

D’autres CNI peuvent être utilisées pour obtenir une solution équivalente. L’intérêt de ce qui est proposé ici est la visibilité du mécanisme de réseau non routable, qui reste au niveau AWS. La responsabilité peut donc être conservée par les équipes réseaux, et les services managés par AWS.

La solution présentée et illustrée par les schémas décrit une plateforme n’ayant que des flux applicatifs privés entre les différents VPCs et le datacenter on-premise. Celle-ci peut facilement être adaptée pour une plateforme qui serait exposée sur internet.


Notre expert

Photo Sylvain Bruas, TeamWork

Sylvain Bruas

Senior Solutions Architect, TeamWork