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
- Aller à console.aws.amazon.com
- 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
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.
- Aller à console.aws.amazon.com
- Choisir le VPC à modifier puis Edit CIDRs dans les actions
- Ajouter la plage
3 – Créer une private NAT Gateway sur un subnet privé routable pour autoriser les flux sortant des pods :
- Aller à console.aws.amazon.com
- Cliquer sur créer une NAT Gateway
- Choisir le type de connexion privée, et installer cette NAT Gateway dans un subnet privé routable.
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 :
- La taille limite que l’on peut réserver dans l’IPAM pour un seul réseau. il faudra é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 ici : https://docs.aws.amazon.com/fr_fr/vpc/latest/userguide/vpc-nat-gateway.html#nat-gateway-basics
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
Sylvain Bruas
Senior Solutions Architect, TeamWork
