KubeIP v2 : des IP publiques statiques pour vos nœuds Kubernetes, sur n'importe quel cloud

Dans certains cas, les nœuds Kubernetes ont tout intérêt à disposer d'adresses IP publiques statiques dédiées.

KubeIP, un utilitaire open source, répond à ce besoin en attribuant des IP publiques statiques aux nœuds Kubernetes. La dernière version, KubeIP v2, étend la prise en charge de GKE (Google Cloud) à EKS (Amazon), avec une architecture prête à accueillir d'autres fournisseurs cloud. Il fonctionne sous forme de DaemonSet, gage d'une meilleure fiabilité, d'une plus grande souplesse de configuration et d'une convivialité accrue par rapport à l'ancienne approche reposant sur un contrôleur Kubernetes. KubeIP v2 prend en charge l'attribution d'adresses IPv4 comme IPv6.

Cet article détaille les cas d'usage spécifiques de KubeIP, le compare aux passerelles NAT cloud et explore son architecture ainsi que sa configuration.

KubeIP s'avère utile dans de nombreux scénarios où les nœuds Kubernetes ont besoin d'IP publiques statiques.

Voici quelques cas d'usage courants :

Applications de gaming

Dans les scénarios de gaming, une console peut avoir besoin d'établir une connexion directe avec une VM dans le cloud afin de réduire au minimum les sauts réseau et la latence. Attribuer une IP publique dédiée au nœud qui héberge le serveur de jeu permet à la console de se connecter directement. L'expérience de jeu s'en trouve améliorée, avec moins de latence et de pertes de paquets.

Whitelisting des IP d'agents

Si plusieurs agents ou services s'exécutent sur Kubernetes et nécessitent des connexions directes à un serveur externe qui doit en autoriser les adresses IP, KubeIP simplifie la gestion en attribuant des IP publiques stables aux nœuds, plutôt que d'autoriser de larges plages CIDR. C'est particulièrement précieux lorsque le serveur externe applique des contrôles d'accès stricts basés sur les IP.

Éviter le SNAT pour certains pods

Par défaut, les pods reçoivent des IP privées issues de la plage CIDR du VPC. Lorsqu'ils communiquent avec des adresses IPv4 externes, le plugin Amazon VPC CNI traduit l'IP du pod en l'IP privée principale de l'interface réseau du nœud, via SNAT (source network address translation).

Il peut arriver que vous souhaitiez éviter le SNAT pour certains pods, afin que les services externes voient les véritables IP des pods. En attribuant des IP publiques aux nœuds avec KubeIP et en définissant hostNetwork: true dans la spécification du pod, vous obtenez ce résultat. Le pod peut alors communiquer directement avec les services externes via l'IP publique du nœud.

Connexions entrantes directes et scénarios réseau personnalisés

Attribuer des IP publiques aux nœuds avec KubeIP ouvre la voie à de nombreux scénarios réseau. Vous pouvez par exemple acheminer le trafic directement vers les pods s'exécutant sur ces nœuds, ce qui se révèle pratique lorsque vous devez exposer sur Internet des services hébergés sur le nœud sans passer par un load balancer traditionnel.

Concrètement, vous pouvez exécuter un serveur web dans un pod et lui acheminer le trafic via l'IP publique du nœud.

KubeIP permet également de mettre en place des scénarios réseau personnalisés nécessitant des IP publiques sur les nœuds. Vous pourriez par exemple créer un load balancer sur mesure qui redirige le trafic vers des nœuds spécifiques en fonction de leur IP publique. Cette souplesse fait de KubeIP un outil puissant pour tester ou déployer des solutions réseau sur mesure dans Kubernetes.

KubeIP étend ses fonctionnalités au-delà d'IPv4 en prenant aussi en charge l'attribution d'adresses IPv6 publiques statiques aux nœuds. Cette capacité gagne en importance à mesure qu'Internet poursuit sa transition vers IPv6, conséquence de l'épuisement des adresses IPv4.

Grâce à la prise en charge d'IPv6 par KubeIP, vous pouvez attribuer des adresses IPv6 publiques statiques à vos nœuds Kubernetes pour leur permettre de communiquer directement avec des services externes en IPv6. C'est particulièrement bénéfique pour les applications qui exigent une connectivité IPv6. Si vous développez ou déployez une application devant prendre en charge IPv6, KubeIP peut fournir cette connectivité aux pods qui l'exécutent.

Par ailleurs, IPv6 offre un espace d'adressage plus vaste, un format d'en-tête simplifié, une meilleure prise en charge des extensions et des options, un routage multicast amélioré et bien d'autres avancées par rapport à IPv4.

Les passerelles NAT sont des services cloud managés qui assurent l'accès Internet sortant des ressources hébergées dans des sous-réseaux privés, en traduisant leurs IP privées en IP publiques. Elles permettent à ces ressources d'établir des connexions sortantes vers Internet tout en préservant leur confidentialité et leur sécurité.

En revanche, les passerelles NAT ne gèrent pas les connexions entrantes et n'attribuent pas d'IP publiques directement aux ressources. Autrement dit, si elles excellent pour fournir un accès sortant sécurisé, elles ne sont pas conçues pour les scénarios nécessitant des connexions entrantes ou exigeant que les ressources disposent de leur propre IP publique.

KubeIP, à l'inverse, attribue des IP publiques statiques directement aux nœuds Kubernetes. Les connexions entrantes peuvent ainsi atteindre directement les pods exécutés sur ces nœuds, le trafic étant redirigé du nœud vers le pod. C'est particulièrement utile pour les applications devant être accessibles depuis Internet ou pour des scénarios réseau sur mesure.

De plus, lorsque hostNetwork est activé, les pods peuvent établir des connexions sortantes en utilisant directement l'adresse IP de l'hôte. Cela peut améliorer les performances réseau et faciliter le diagnostic, mais reste à utiliser avec précaution en raison des implications potentielles en matière de sécurité.

En résumé, si les passerelles NAT constituent une excellente solution pour un accès sortant sécurisé, KubeIP offre une souplesse et un contrôle accrus sur la connectivité entrante comme sortante de pods et de nœuds spécifiques.

Plusieurs facteurs entrent en jeu lorsqu'il s'agit de comparer le coût de KubeIP à celui des passerelles NAT cloud.

Coûts des passerelles NAT cloud

Les passerelles NAT cloud sont un service managé, et donc payant. Le tarif dépend généralement du volume de données traitées et de la durée pendant laquelle la passerelle NAT est provisionnée et disponible.

À titre d'exemple, à l'heure où nous écrivons ces lignes, AWS facture 0,045 $ par heure pour une passerelle NAT, auxquels s'ajoutent des frais de traitement des données. Les frais standards de transfert de données AWS s'appliquent par ailleurs à toutes les données transitant par la passerelle NAT.

Le modèle tarifaire de Google Cloud NAT est similaire.

Coûts de KubeIP

KubeIP, à l'inverse, est un outil open source : son utilisation n'engendre aucun coût direct. Plusieurs coûts indirects méritent toutefois d'être pris en compte :

1. Adresses IP publiques statiques : vous devez payer les adresses IP publiques statiques attribuées à vos nœuds. Leur tarif varie selon le fournisseur cloud. AWS, par exemple, facture 0,005 $ par heure pour une adresse Elastic IP, qu'elle soit utilisée ou non. Google Cloud applique le même tarif pour une IP statique.
2. Transfert de données : les frais standards de transfert s'appliquent aux données transitant par les IP publiques statiques attribuées. Ces coûts dépendent de la grille tarifaire de transfert de données de votre fournisseur cloud.
3. Charge supplémentaire sur le cluster : KubeIP s'exécute sous forme de DaemonSet et consomme peu de CPU et de mémoire, mais il reste un workload supplémentaire sur votre cluster Kubernetes. Cela peut éventuellement affecter les performances d'autres workloads, en particulier sur des clusters aux ressources limitées. Dans la plupart des cas, l'impact reste néanmoins minime.
4. Maintenance et support : KubeIP étant un outil open source, il ne bénéficie pas d'un support dédié. Toute opération de maintenance, de diagnostic ou de mise à jour incombe à votre équipe. Cela ne représente pas un coût direct, mais demande du temps et des efforts qui peuvent se traduire par un coût pour votre organisation.

En résumé, KubeIP n'a pas de coût direct, mais ses coûts indirects ne doivent pas être négligés. Pour de nombreux cas d'usage, la souplesse et le contrôle qu'il apporte compensent largement ces coûts.

Points à considérer côté coûts

Pour évaluer la rentabilité de KubeIP, il est essentiel de prendre en compte à la fois ses coûts directs et indirects : prix des IP publiques statiques, frais de transfert de données, impact potentiel d'un workload supplémentaire sur votre cluster Kubernetes, ainsi que le temps et l'effort consacrés à la maintenance et au support.

Même si KubeIP n'engendre pas de coût direct, ces coûts indirects peuvent rapidement s'accumuler, en particulier sur les clusters de grande taille. Cela dit, la souplesse et le contrôle qu'il offre apportent une valeur significative, notamment pour les cas d'usage nécessitant des connexions entrantes directes ou des scénarios réseau personnalisés.

Les passerelles NAT cloud, à l'inverse, fournissent un service managé qui simplifie la connectivité sortante des ressources situées dans des sous-réseaux privés. Leur coût s'accompagne d'avantages tels que la simplicité d'usage, la scalabilité et la fiabilité.

En conclusion, le choix entre KubeIP et une passerelle NAT cloud dépendra de votre cas d'usage, de la taille et des exigences de votre cluster Kubernetes, ainsi que de votre budget. Nous vous conseillons d'estimer les coûts à partir du transfert de données prévu, du nombre de nœuds et d'IP, et de vos besoins de maintenance afin de prendre une décision éclairée.

KubeIP s'exécute sous forme de DaemonSet sur les nœuds de votre choix. Sur chaque nœud, il :

1. Récupère les informations sur le nœud et le fournisseur cloud via la Kubernetes Downward API.
2. Acquiert un verrou à l'échelle du cluster pour qu'un seul nœud à la fois attribue une IP, évitant ainsi les conditions de concurrence et les conflits d'IP.
3. Sélectionne une IP statique disponible dans le pool configuré à l'aide de filtres et de sélecteurs.
4. Attribue l'IP à l'interface réseau principale du nœud via l'API du fournisseur cloud.
5. En cas d'échec de l'attribution dû à une erreur (interruption réseau, erreur d'API, etc.), KubeIP relance l'opération jusqu'à un nombre de tentatives configuré.
6. Lorsqu'un nœud est supprimé, KubeIP libère l'IP attribuée et la remet dans le pool, où elle redevient disponible pour d'autres nœuds.

KubeIP prend en charge les adresses IPv4 et IPv6, et peut être configuré pour utiliser des pools distincts pour chacune. Il accepte également des pools d'IP personnalisés selon les nœuds ou groupes de nœuds, offrant une grande souplesse de gestion des IP.

KubeIP v2 repose sur un DaemonSet Kubernetes standard, ce qui signifie qu'il s'exécute sur chaque nœud du cluster.

Cette conception améliore la fiabilité et la simplicité d'usage par rapport à l'ancienne approche basée sur un contrôleur. Elle simplifie également le déploiement et garantit que chaque nœud reçoit bien une IP publique. En tirant parti de fonctionnalités Kubernetes standards comme les node selectors ou la node affinity, vous contrôlez précisément les nœuds sur lesquels KubeIP est déployé. Cela permet une gestion fine de l'attribution des IP, en réservant des IP publiques à des nœuds spécifiques selon vos besoins.

L'architecture extensible de KubeIP v2 facilite l'intégration avec d'autres fournisseurs cloud que GKE et EKS, ce qui en fait un outil polyvalent pour gérer des IP publiques dans des environnements multi-cloud.

KubeIP nécessite un compte de service Kubernetes disposant des permissions pour récupérer les nœuds et gérer les leases.

Côté cloud, il lui faut un rôle IAM ou un compte de service avec les permissions pour attribuer/désattribuer et lister les IP publiques, et récupérer les informations des nœuds.

Voici un exemple de politique IAM AWS :

{
  "Version": "2012-10-17",
  "Statement": [\
    {\
      "Effect": "Allow",\
      "Action": [\
        "ec2:AssociateAddress",\
        "ec2:DisassociateAddress",\
        "ec2:DescribeInstances",\
        "ec2:DescribeAddresses"\
      ],\
      "Resource": "*"\
    }\
  ]
}

Et un rôle IAM Google Cloud :

title: "KubeIP Role"
description: "KubeIP required permissions"
stage: "GA"
includedPermissions:
- compute.instances.addAccessConfig
- compute.instances.deleteAccessConfig
- compute.instances.get
- compute.addresses.get
- compute.addresses.list
- compute.addresses.use
- compute.zoneOperations.get
- compute.subnetworks.useExternalIp
- compute.projects.get

Pour choisir les IP à utiliser, indiquez des filtres avec la même syntaxe que la CLI/API du cloud pour lister les IP. Par exemple :

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kubeip
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app: kubeip
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  template:
    metadata:
      labels:
        app: kubeip
    spec:
      serviceAccountName: kubeip-service-account
      terminationGracePeriodSeconds: 30
      priorityClassName: system-node-critical
      nodeSelector:
        nodegroup: public
        kubeip: "use"
      tolerations:
        - operator: "Exists"
          effect: "NoSchedule"
        - operator: "Exists"
          effect: "NoExecute"
      containers:
      - name: kubeip
        image: doitintl/kubeip-agent
        imagePullPolicy: Always
        resources:
          requests:
            cpu: "10m"
            memory: "32Mi"
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              fieldPath: spec.nodeName
        - name: LEASE_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        - name: FILTER
          value: "Name=tag:kubeip,Values=reserved;Name=tag:environment,Values=prod"
        - name: LOG_LEVEL
          value: "debug"
        - name: LOG_JSON
          value: "true"

Cela indique à KubeIP, sur AWS, de ne considérer que les IP portant les tags kubeip=reserved et environment=prod.

Le filtre AWS de KubeIP utilise la même syntaxe que la commande AWS describe-addresses. Pour plus d'informations, consultez describe-addresses. Si vous spécifiez plusieurs filtres, ils sont combinés par un AND, et la requête ne renvoie que les résultats correspondant à l'ensemble des filtres. Plusieurs filtres doivent être séparés par des points-virgules (;).

Le filtre Google Cloud de KubeIP utilise la même syntaxe que la commande Google Cloud gcloud compute addresses list. Pour plus d'informations, consultez gcloud topic filter. Si vous spécifiez plusieurs filtres, ils sont combinés par un AND, et la requête ne renvoie que les résultats correspondant à l'ensemble des filtres. Plusieurs filtres doivent être séparés par des points-virgules (;).

Le répertoire examples contient des configurations Terraform pour démarrer des clusters GKE et EKS avec KubeIP déployé.

Pour exécuter sur EKS :

cd examples/aws

terraform init

terraform apply

Et sur GKE :

cd examples/gcp

terraform init

# sans prise en charge IPv6
terraform apply -var="project_id=<your-project-id>"

# avec prise en charge IPv6
terraform apply -var="project_id=<your-project-id>" -var="ipv6_support=true"

Cela provisionne un cluster doté de node pools publics et privés, réserve quelques IP statiques et déploie le DaemonSet KubeIP configuré pour utiliser ces IP réservées.

En tant que projet open source, nous accueillons les contributions avec plaisir ! Soumettez des pull requests, ouvrez des issues, contribuez à la documentation ou faites passer le mot.

Avec la prise en charge cloud étendue et le modèle DaemonSet simplifié de la v2, nous avons hâte de découvrir les nouveaux cas d'usage rendus possibles par KubeIP. Essayez-le dans votre environnement et faites-nous part de votre retour !