Le Blog Amazon Web Services

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

Cet article a été rédigé par Sylvain Bruas, Cloud Transformation Consultant et Senior Solutions Architect chez TeamWork, en collaboration avec Sébastien Allamand, Senior Container Specialist Solutions Architect pour la France.

Nos clients de taille importante sont souvent 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, contraint par leurs plans d’adressages on-premises.

Les clusters Amazon EKS doivent être des plateformes pérennes pouvant héberger les applications contenairisées existantes ou à venir. Ces clusters doivent donc être capables d’avoir un nombre important de pods, et donc par extension d’adresses IP. Ce nombre d’adresses IPs 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’adresses IP.

Prérequis

Choisir une plage d’adresses 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 et nous déployons une AWS Transit Gateway (TGW). Ce routeur cloud permet de connecter les Amazon Virtual Private Cloud (VPC) ainsi que les réseaux on-premises. Dans notre contexte, la transit gateway et les éléments liés ont été livrés par l’équipe réseau.

Architecture

Figure 1 – Architecture réseau

Mise en œuvre

Celle-ci s’effectue en plusieurs étapes :

  • Déclarer la plage d’adresses IP en tant que blackhole dans les tables de routage de la Transit Gateway
  • Ajouter cette plage d’adresses IP à chaque VPC hébergeant des clusters Amazon EKS, et créer des subnets avec ce range d’adresses 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.
  • Créer une private NAT Gateway sur un subnet privé routable pour autoriser les flux sortant des pods :
  • Configurer la table de routage des subnets des pods pour utiliser la NAT Gateway
  • Conserver le point d’entrée du cluster Amazon 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’adressesIP 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’adresses 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’adresses 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 pour assurer sa haute disponibilité.

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 du VPC1 va passer par la NAT Gateway pour envoyer sa requête (1), la translation d’adresses 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 d’impact que sur les flux réseaux partant d’un pod vers l’exterieur du 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 initiale (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 proposée (ie utilisant une 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

On voit donc que la solution mise en oeuvre a un impact limitée sur les performances des flux réseaux.

Limites

Il existe 2 limites principales :

  • La taille limite que l’on peut réserver dans l’IPAM pour un seul réseau. De fait, il est important d’échanger avec les équipes réseau pour connaitre les disponibilités et pour récupérer la taille la plus large possible,
  • Les limites de la Private Nat Gateway :
    • Protocoles pris en charge : TCP,UDP, ICMP,
    • 5 Gb/s de bande passante (mise à l’échelle automatique jusqu’à 45 Gb/s),
    • 1 million de paquets par seconde (mise à l’échelle automatique jusqu’à 4 millions de paquets par seconde),
    • 55 000 connexions simultanées pour chaque destination unique,
    • Liste complète disponible dans la documentation,

Conclusion

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’Amazon EKS à une échelle importante.

Cette solution pourrait être également utilisée on-premise, même si 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 adresses IPs disponibles. D’autres CNIs 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.

Contribution de Sylvain Bruas, Cloud Transformation Consultant et Senior Solutions Architect chez TeamWork, en collaboration avec Sébastien Allamand, Senior Container Specialist Solutions Architect pour la France.