IPv6, double pile et maillage de services

Pourquoi

Cette leçon réunit deux sujets qui concernent la manière dont un cluster grandit : en nombre d'adresses, et en nombre de services qui se parlent.

IPv6. Les adresses IPv4 sont épuisées, et la leçon IPv6 du cours TCP/IP en a rappelé les conséquences : une grande partie des utilisateurs en France ont déjà une connectivité IPv6, et le nombre de pods d'un grand cluster met à l'épreuve les plages privées IPv4. Un cluster peut donc devoir parler les deux familles : c'est la double pile. Un client public, des clients mobiles, des administrations qui demandent l'IPv6 dans les marchés : le sujet arrive dans les cahiers des charges, et mieux vaut savoir ce que Kubernetes permet et ce qu'il impose.

Le maillage. Quand l'application se compose de dizaines de services qui s'appellent, on rencontre vite les mêmes besoins : chiffrer et authentifier chaque appel entre services (mTLS), réessayer proprement, limiter les délais, mesurer chaque requête (taux d'erreur, latence) sans modifier le code. Chaque équipe peut les mettre dans sa bibliothèque cliente, dans son langage. Un maillage de services (service mesh) les met dans l'infrastructure, uniformément. Cela a un coût en complexité et en ressources, qu'il faut mettre en regard du besoin : la plupart des clusters n'en ont pas besoin, et la leçon sert aussi à savoir le reconnaître.

Les concepts

La double pile dans Kubernetes

La documentation de Kubernetes décrit la double pile comme l'attribution simultanée d'adresses IPv4 et IPv6 aux pods et aux Services. La fonction est stable depuis Kubernetes 1.23 et activée par défaut depuis 1.21. Elle suppose trois choses : des nœuds qui ont des interfaces IPv4 et IPv6 routables, un plugin réseau (CNI) qui la gère, et un cluster configuré avec les plages des deux familles.

Ce que reçoit un pod. Une adresse de chaque famille, dans status.podIPs (une liste ; status.podIP désigne la première). Sur un nœud, le contrôleur de nœuds lui attribue deux plages, une de chaque famille, dont sont tirées les adresses des pods de ce nœud.

Ce que reçoit un Service. Le comportement est réglé par deux champs de spec :

• ipFamilyPolicy : SingleStack (une seule famille, la première des plages configurées), PreferDualStack (les deux si le cluster le permet, sinon une) ou RequireDualStack (les deux, sinon échec) ;
• ipFamilies : l'ordre des familles, par exemple [IPv4, IPv6]. La première est la famille primaire, et on ne peut pas la changer sur un Service existant. Une famille secondaire s'ajoute ou se retire.

Un Service en double pile reçoit deux adresses (spec.clusterIPs), et ses EndpointSlices se dédoublent : une tranche par type d'adresse, IPv4 et IPv6 (voir Services et DNS pour les EndpointSlices). Le DNS du cluster renvoie alors un enregistrement A et un enregistrement AAAA pour le nom du Service (Le DNS du cluster), et le client choisit, en général en préférant IPv6.

Les plages à fixer

Un cluster double pile se configure à plusieurs endroits, d'après la documentation. Les valeurs ci-dessous sont des exemples :

Notez les tailles : un /64 par nœud en IPv6 (la taille standard d'un réseau local, voir la leçon IPv6), contre un /24 en IPv4. Un cluster managé fixe ces plages à la création ; elles ne se changent pas facilement ensuite, ce qui rend le choix initial important.

Un Service de Signalements en double pile

apiVersion: v1
kind: Service
metadata:
  name: signalements
  namespace: signalements
spec:
  type: ClusterIP
  ipFamilyPolicy: PreferDualStack
  ipFamilies: [IPv4, IPv6]
  selector:
    app.kubernetes.io/name: signalements
    app.kubernetes.io/component: api
  ports:
    - name: http
      port: 80
      targetPort: http

PreferDualStack est le choix prudent : sur un cluster double pile, le Service reçoit les deux adresses, et sur un cluster simple pile, il fonctionne quand même avec une seule. RequireDualStack fait échouer la création si le cluster ne le permet pas, ce qui convient quand l'IPv6 fait partie du contrat.

Ce que propose Kapsule

D'après la documentation de l'API Kubernetes de Scaleway, consultée à la date de vérification de cette leçon, la double pile IPv4 et IPv6 n'est pas (encore) disponible sur Kapsule. Les plugins réseau proposés sont cilium, cilium_native et calico, avec des plages configurables à la création. Le fil rouge de ce cours est donc en IPv4 seulement sur Kapsule. Conséquences pratiques :

• l'exposition IPv6 d'une application passe par le répartiteur de charge ou un point d'entrée qui, lui, accepte l'IPv6 et parle IPv4 au cluster, selon ce que le fournisseur offre au moment où vous lisez ceci. Vérifiez la documentation de Scaleway avant de promettre l'IPv6 à un client ;
• pour apprendre et tester la double pile, on utilise kind, qui la gère nativement.

Le maillage : ce que c'est

Sans maillage, quand le service signalements appelle notifications, l'appel est du HTTP ordinaire sur le réseau du cluster : pas chiffré, sans identité vérifiée de l'appelant, avec les délais et retries réglés par chaque bibliothèque cliente. Un maillage ajoute, de façon transparente pour l'application, une couche entre les pods qui offre :

• mTLS automatique : chaque pod reçoit une identité cryptographique (un certificat à courte durée de vie émis par le maillage), et chaque connexion entre pods est chiffrée et authentifiée des deux côtés. Le principe est celui du TLS de la leçon précédente, mais pour tous les échanges internes et sans que l'application s'en occupe ;
• Politiques d'autorisation par identité : « le service signalements peut appeler notifications sur POST /envoyer », au lieu d'adresses IP ;
• Résilience : retries, délais, limitation de la concurrence, bascule hors des instances malades ;
• Observabilité L7 : taux de requêtes, d'erreurs et latences par service et par route (les « golden signals »), traces distribuées, sans instrumenter le code.

Ces fonctions complètent les NetworkPolicies : celles-ci filtrent les adresses et les ports, le maillage authentifie les services et voit les requêtes.

Les architectures

Où placer la logique du maillage ? Trois réponses, avec leurs compromis.

Un proxy par pod (sidecar). Chaque pod reçoit un conteneur de plus, un proxy, par lequel passent tout son trafic entrant et sortant. C'est le modèle historique d'Istio (le proxy est Envoy) et de Linkerd, dont le proxy est un « micro-proxy » écrit en Rust, spécialisé pour le maillage. Avantages : isolation (le proxy d'un pod ne sert que ce pod), maturité, un modèle simple à raisonner. Inconvénients : de la mémoire et du processeur par pod, une injection à l'ouverture du pod (donc un redémarrage de la charge pour adopter le maillage), et un ordre de démarrage à gérer entre le proxy et l'application.

Un proxy par nœud, sans sidecar : Istio ambient. Le mode ambient d'Istio sépare deux couches. Un composant par nœud, ztunnel (écrit en Rust), gère les fonctions L3 et L4 : mTLS, authentification, autorisation L4, métriques de base. Un proxy L7 optionnel, le waypoint (Envoy), s'ajoute par namespace ou par service quand on veut du routage ou des règles L7. La documentation d'Istio indique que l'adoption demande seulement d'étiqueter un namespace, sans redémarrer de pod, et présente ambient comme stable. Elle donne aussi ses limites actuelles (par exemple, pas encore d'interopérabilité entre sidecars et waypoints, ni de multi-cluster ambient à la date consultée) : à relire avant de choisir.

Dans le plugin réseau : Cilium. Le maillage de Cilium s'appuie sur les mêmes briques que son CNI, eBPF dans le noyau pour le L3 et le L4, et un proxy Envoy partagé pour le L7, sans sidecar. Son authentification mutuelle repose sur SPIFFE et SPIRE, et la documentation de Cilium la classe encore comme bêta, avec des fonctions manquantes (par exemple l'intégration avec le chiffrement). Sur Kapsule, où Cilium est déjà là, c'est un candidat naturel pour l'observabilité L7 et les politiques L7 ; pour le mTLS strict, pesez ce statut.

Un mot sur le statut de Linkerd : projet diplômé de la CNCF, il ne publie plus d'artefacts « stables » depuis février 2024 ; les versions stables sont publiées par l'écosystème de distributeurs (dont Buoyant), et le projet publie des versions « edge » presque chaque semaine. Cela compte pour votre politique de mise à jour et de support.

Gateway API pour le maillage : GAMMA

Gateway API a été conçue pour le trafic entrant (nord-sud). L'initiative GAMMA (Gateway API for Mesh Management and Administration) l'étend au trafic interne (est-ouest) avec très peu de changements : une HTTPRoute s'attache non pas à une Gateway, mais à un Service, qui devient son parent. Le travail est dans le canal standard depuis la version 1.1 de Gateway API, d'après la documentation.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: signalements-canari-interne
  namespace: signalements
spec:
  parentRefs:
    - group: ""
      kind: Service
      name: signalements
      port: 80
  rules:
    - backendRefs:
        - name: signalements
          port: 80
          weight: 90
        - name: signalements-canari
          port: 80
          weight: 10

Cette route dit : les appels internes au Service signalements sont répartis 90/10. C'est la répartition pondérée de la leçon 6, appliquée aux appels entre pods, et pas seulement à ceux de l'extérieur. Une route dans le namespace du Service est une route de producteur (le propriétaire du Service la décide) ; une route dans un autre namespace est une route de consommateur (elle ne change que le comportement des pods de ce namespace). Linkerd annonce la prise en charge de Gateway API, avec HTTPRoute et GRPCRoute ; vérifiez chez chaque maillage ce qui est réellement mis en œuvre.

En pratique

Les manifestes sont validés comme du YAML ; ce qu'on observe sur un cluster est décrit.

1. Un cluster kind en double pile

# kind-double-pile.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
networking:
  ipFamily: dual
nodes:
  - role: control-plane
  - role: worker

$ kind create cluster --name dualstack --config kind-double-pile.yaml

D'après la documentation de kind, ipFamily prend ipv4 (défaut), ipv6 ou dual. La double pile exige kind 0.11 ou plus. Les plages par défaut sont 10.244.0.0/16 et fd00:10:244::/56 pour les pods, 10.96.0.0/16 et fd00:10:96::/112 pour les Services. Un cluster ipFamily: ipv6 fonctionne seulement si l'hôte a l'IPv6 activé dans le noyau, et la redirection de ports vers l'API ne fonctionne pas en IPv6, d'après la même documentation.

2. Vérifier

Appliquez le Service de la section « Les concepts », puis lisez ce qui a été attribué :

$ kubectl get pods -n signalements -o jsonpath='{range .items[*]}{.metadata.name}{"\t"}{.status.podIPs}{"\n"}{end}'
$ kubectl get service signalements -n signalements -o jsonpath='{.spec.ipFamilyPolicy}{"\t"}{.spec.clusterIPs}{"\n"}'
$ kubectl get endpointslices -n signalements -l kubernetes.io/service-name=signalements

Sur ce cluster, chaque pod doit afficher deux adresses (une de chaque famille), le Service deux clusterIPs, et deux EndpointSlices doivent exister, l'une de type d'adresse IPv4, l'autre IPv6. Depuis un pod de test, curl -6 et curl -4 vers signalements.signalements.svc.cluster.local joignent l'API par l'une ou l'autre famille. Si le cluster n'est pas en double pile, PreferDualStack donne une seule adresse, sans erreur : la valeur de ipFamilyPolicy ne prouve pas que le cluster est double pile, seules les adresses attribuées le prouvent.

3. Exposer en double pile

Le Service de Traefik est un LoadBalancer. Sur un cluster double pile, on peut demander les deux familles par le fichier de valeurs du chart, dont la section service.spec accepte des champs de Service :

service:
  spec:
    type: LoadBalancer
    ipFamilyPolicy: PreferDualStack

Que l'adresse externe existe dans les deux familles dépend du fournisseur : c'est l'implémentation du LoadBalancer, non Kubernetes, qui le décide. Cette fonction se vérifie chez le fournisseur.

4. Un maillage minimal pour comprendre : Istio ambient

Pour voir le modèle sans sidecar sur kind, avec la CLI istioctl (installation selon la documentation d'Istio) :

$ istioctl install --set profile=ambient
$ kubectl label namespace signalements istio.io/dataplane-mode=ambient
$ kubectl get pods -n istio-system

La première commande installe le plan de contrôle, ztunnel en DaemonSet et le plugin CNI d'Istio. La deuxième inscrit le namespace au maillage : les pods de signalements ne sont pas redémarrés, et leur trafic passe désormais par ztunnel de leur nœud, qui l'enveloppe dans du mTLS avec les autres pods inscrits. La troisième doit montrer un pod ztunnel par nœud. Cette démonstration est à lire avec la documentation de la version d'Istio utilisée : les options d'installation changent d'une version à l'autre.

Sous le capot

Comment le trafic est capté. Un sidecar est inséré dans le pod avec une règle d'iptables (ou de nftables) qui redirige les connexions sortantes et entrantes vers lui, dans l'espace de noms réseau du pod (Le chemin d'un paquet). L'application croit parler à notifications:80 ; le proxy ouvre la vraie connexion, en TLS mutuel, vers le proxy de l'autre pod. En mode ambient, la redirection se fait dans l'espace de noms du pod, vers ztunnel du nœud, qui établit le tunnel chiffré vers le ztunnel du nœud de destination.

D'où viennent les identités. Chaque pod obtient un certificat dont le nom encode son identité (en général, un identifiant SPIFFE dérivé de son compte de service Kubernetes). Le plan de contrôle du maillage joue le rôle d'autorité de certification, avec des certificats qui durent des heures, renouvelés automatiquement : le même principe que cert-manager, à une échelle bien plus fine. C'est pourquoi le compte de service d'un pod devient une frontière de sécurité (voir Sécurité de Kubernetes).

Pourquoi le maillage coûte du temps de réponse. Chaque appel traverse deux proxys supplémentaires (celui de la source, celui de la destination) avec chiffrement, déchiffrement et copie de données. La documentation d'Istio met des chiffres sur cette différence entre modes (de l'ordre de 0,6 à 0,9 ms pour un sidecar, 0,2 ms pour le niveau nœud d'ambient, dans ses mesures) : c'est son ordre de grandeur, pas une garantie pour votre application.

Pourquoi GAMMA est possible. Une route attachée à un Service se traduit pour le maillage en configuration des proxys des clients de ce Service : quand le proxy du pod appelant résout signalements, il applique les règles de la route. Le Service garde son rôle de nom stable, et la route y ajoute le routage.

Pièges courants

Croire que PreferDualStack prouve la double pile. Voir la section 2 : il faut lire les adresses.

La famille primaire figée. Changer la première famille d'un Service existant est refusé. On recrée le Service, en tenant compte de ce qui référence son adresse.

Du code qui suppose l'IPv4. Une application qui écoute sur 0.0.0.0 ne répond pas en IPv6 : il faut :: (qui accepte, selon le système, les deux familles). Des listes d'autorisation à base d'adresses IPv4, des regex qui ne reconnaissent pas [::1], des journaux qui coupent les adresses longues : les surprises viennent des applications plus que de Kubernetes. Si l'image de Signalements lance Gunicorn avec --bind 0.0.0.0:8000, il n'écoute qu'en IPv4 ; pour l'IPv6, il faut [::]:8000. Vérifiez-le avant d'activer l'IPv6.

Les politiques réseau ne couvrent qu'une famille. Un ipBlock à 0.0.0.0/0 ne contient pas d'adresses IPv6 : en double pile, ajoutez ::/0 (et les exceptions de l'autre famille).

Un maillage adopté partout, d'un coup. Chaque service qui entre dans le maillage change de profil de latence, de ressources et de pannes possibles. On commence par un namespace, avec des mesures avant et après.

Le mTLS en mode permissif qui y reste. Beaucoup de maillages offrent un mode où le trafic en clair est encore accepté, pour migrer. Si on ne passe jamais au mode strict, on a payé le maillage sans la garantie.

Un maillage qui masque un problème de conception. Des retries automatiques sur des requêtes non idempotentes dupliquent des écritures ; une cascade de retries à plusieurs niveaux amplifie une panne. Les retries du maillage, de la bibliothèque et de la passerelle s'additionnent.

Sécurité

• Le mTLS authentifie des services, pas des utilisateurs. Il prouve que l'appelant est le service signalements, pas que l'utilisateur est autorisé : l'autorisation applicative reste dans l'application.
• L'autorité du maillage est un trésor. Qui obtient la clé de l'autorité émet des identités pour tout le cluster. Protégez-la comme une autorité de certification : accès restreint, sauvegardes chiffrées, rotation prévue.
• Le compte de service est l'identité. Un pod qui peut utiliser un compte de service obtient son identité de maillage. Un compte par application, jamais le default.
• Le chiffrement entre nœuds peut venir d'ailleurs. Cilium propose aussi du chiffrement transparent (WireGuard ou IPsec) entre nœuds, indépendamment d'un maillage : si votre besoin est « rien en clair sur le réseau », il suffit parfois à lui seul, sans authentification de service.
• IPv6 : un pare-feu pour les deux familles. Sans NAT, un pod en IPv6 est joignable directement si le réseau le route ; les groupes de sécurité et les NetworkPolicies doivent couvrir les deux familles. C'est une régression de sécurité classique : on filtre l'IPv4, on oublie l'IPv6.
• Mises à jour du maillage. Un maillage est un composant du chemin de toutes les requêtes : suivez ses avis de sécurité comme ceux d'un noyau.

En production

• Un maillage est un projet, pas une option. Compter : des ressources en plus, une montée en compétence, des mises à jour couplées à celles de Kubernetes, un nouveau domaine de pannes à diagnostiquer (leçon 10).
• Quand ne pas en avoir. Signalements est une API et une base dans un namespace : un maillage n'y apporterait rien que ne donnent déjà TLS à la passerelle, les NetworkPolicies et un tableau de bord Prometheus. Il se justifie à partir du moment où plusieurs équipes exploitent de nombreux services qui s'appellent, avec des exigences de mTLS partout (conformité) ou d'observabilité L7 uniforme qu'on ne veut pas coder dans chaque service.
• Les alternatives plus légères. Les NetworkPolicies et le mTLS ciblé (cert-manager et TLS de bout en bout sur quelques flux), l'instrumentation OpenTelemetry pour l'observabilité, et la bibliothèque cliente pour les retries.
• Choisir. Besoin d'observabilité et de politiques L7 sur Kapsule : voir ce que Cilium propose déjà. Besoin de mTLS strict, mature et indépendant du CNI : Istio ambient, ou Linkerd si la simplicité prime et si la politique de publication vous convient.
• Double pile. À décider à la création du cluster. Un client qui exige l'IPv6 sur un cluster sans double pile impose un point d'entrée dédié ; les plages ne se changent pas facilement après coup, donc la migration se prépare d'avance.
• Versions. Istio et Linkerd évoluent vite : relisez la page de statut du maillage choisi avant de vous engager, ce que la présente leçon ne peut pas garantir.

Exercices

Exercice 1 : lire les adresses

Sur un cluster kind en double pile, kubectl get service signalements -o jsonpath='{.spec.clusterIPs}' affiche une seule adresse IPv4. Le Service est en PreferDualStack. Donnez deux explications possibles.

Exercice 2 : faut-il un maillage ?

Lyneko héberge pour un client 40 services répartis dans 6 équipes. Le cahier des charges demande le chiffrement de tous les flux internes, une identité vérifiable pour chaque appel entre services, et des tableaux de bord de latence par route. Quelle architecture proposez-vous, et quel point devez-vous vérifier avant de promettre quoi que ce soit ?

Exercice 3 : une route interne

Écrivez la route GAMMA qui envoie à signalements-canari les appels internes qui portent l'en-tête X-Version: canari, et tout le reste à signalements.

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: signalements-interne
  namespace: signalements
spec:
  parentRefs:
    - group: ""
      kind: Service
      name: signalements
      port: 80
  rules:
    - matches:
        - headers:
            - name: X-Version
              value: canari
      backendRefs:
        - name: signalements-canari
          port: 80
    - backendRefs:
        - name: signalements
          port: 80

Récapitulatif

• La double pile (stable depuis Kubernetes 1.23) donne à chaque pod et Service une adresse de chaque famille ; elle exige des nœuds, un CNI et des plages des deux familles fixées à la création du cluster.
• Sur un Service : ipFamilyPolicy (SingleStack, PreferDualStack, RequireDualStack) et ipFamilies (la famille primaire ne change pas). On vérifie par les adresses attribuées et les deux EndpointSlices.
• Kapsule n'offre pas la double pile à la date de vérification : à revérifier avant tout engagement. kind la gère (networking.ipFamily: dual).
• Un maillage apporte mTLS automatique, autorisation par identité, résilience et observabilité L7, au prix de ressources, de latence et de complexité.
• Architectures : sidecar par pod (Istio, Linkerd), par nœud (Istio ambient : ztunnel et waypoint optionnel), dans le CNI (Cilium, mTLS encore bêta).
• GAMMA applique Gateway API aux appels internes : une HTTPRoute dont le parent est un Service.
• Un maillage n'est justifié qu'à l'échelle de nombreux services et de plusieurs équipes ; pour Signalements, TLS, NetworkPolicies et métriques suffisent.

Pour aller plus loin

• La leçon IPv6 du cours TCP/IP, pour l'adressage, SLAAC et NDP.
• Diagnostiquer le réseau d'un cluster, pour savoir lire un problème réseau avec un maillage dans le chemin.
• La page IPv4/IPv6 dual-stack de la documentation de Kubernetes, et la tâche de validation qui l'accompagne.
• La documentation d'Istio sur les modes sidecar et ambient, celle de Linkerd, et celle de Cilium sur son service mesh.
• Le cours Kapsule : Kubernetes managé chez Scaleway, pour l'état courant des fonctions réseau du service.
• Glossaire : Double pile (Kubernetes), Maillage de services, IPv6.