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
- Aller sur https://console.aws.amazon.com/vpc/home#TransitGatewayRouteTables,
- Sélectionner une des tables de routage à modifier,
- Sélectionner l’onglet Routes et cliquer sur Créer une route statique
- Cocher la case Blackhole pour le Type et créer la route
- 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.
- Aller sur https://console.aws.amazon.com/vpc/home#vpcs
- Choisir le VPC à modifier puis Edit CIDRs dans les actions
- Ajouter la plage
- Créer une private NAT Gateway sur un subnet privé routable pour autoriser les flux sortant des pods :
- Aller sur https://console.aws.amazon.com/vpc/home#NatGateways
- Cliquer sur créer une NAT Gateway
- Choisir le type de connexion privée, et installer cette NAT Gateway dans un subnet privé routable.
- 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 :
-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)
- Architecture proposée (ie utilisant une Private NAT Gateway)
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.