Réseau IPv6

GitGuardian Self-Hosted prend en charge les configurations réseau IPv4, IPv6 et dual-stack pour une flexibilité maximale dans les environnements modernes cloud et on-premises. IPv6 est disponible exclusivement pour les installations Helm.

Quand utiliser IPv6

Le support IPv6 est utile lorsque :

Votre cluster Kubernetes est IPv6-only ou dual-stack
Vous migrez d'IPv4 vers IPv6
Exigences du fournisseur cloud (certaines régions AWS encouragent IPv6-only)
Les politiques de sécurité d'entreprise exigent IPv6

Démarrage rapide

Values Helm

Le support IPv6 peut être activé via la value du Helm chart network.ipFamily.

Configuration de votre cluster	Utilisez `network.ipFamily`	Notes
IPv4-only (par défaut)	`ipv4`	Compatible en arrière, aucune modification nécessaire
IPv6-only	`ipv6`	Tous les services utilisent uniquement des adresses IPv6
Dual-stack	`dualstack` ou `ipv6`	Voir notes spécifiques aux plateformes ci-dessous

Considérations spécifiques aux plateformes

AWS EKS

Limitation dual-stack EKS

AWS EKS ne supporte pas les vrais services Kubernetes dual-stack. Même quand votre VPC est dual-stack, les services Kubernetes doivent être soit IPv4 soit IPv6, pas les deux.

Utilisez toujours ipFamily: 'ipv6' sur EKS, même quand votre VPC est dual-stack.

Vos pods dans un VPC EKS dual-stack peuvent toujours atteindre les services externes IPv4 et IPv6 (bases de données, Redis, APIs), mais les services Kubernetes eux-mêmes n'auront que des adresses IPv6.

Google GKE

GKE prend pleinement en charge les services dual-stack où les services reçoivent simultanément des adresses IPv4 et IPv6.

Prérequis :

Cluster GKE avec stack_type = "IPV4_IPV6"
Advanced Datapath (Dataplane V2) activé
Kubernetes 1.28+

Vous pouvez utiliser n'importe quelle valeur ipFamily (ipv4, ipv6 ou dualstack) selon vos besoins.

Azure AKS

AKS prend en charge les services dual-stack de manière similaire à GKE. Les services peuvent avoir à la fois des adresses IPv4 et IPv6.

Vous pouvez utiliser n'importe quelle valeur ipFamily selon vos besoins.

On-premises

Le support IPv6 dépend de votre plugin CNI et de la configuration du cluster :

Plugin CNI	Support IPv6
Calico	✅ Support complet
Cilium	✅ Support complet
Flannel	⚠️ Limité (IPv6-only, pas de dual-stack)
Weave Net	⚠️ Expérimental

Nous recommandons de tester les capacités IPv6 de votre cluster avant un déploiement en production.

Prérequis

Prérequis cluster

Kubernetes 1.28+ (requis pour le support dual-stack stable)
Cluster compatible IPv6 : vérifiez avec :
```
kubectl get nodes -o jsonpath='{.items[*].spec.podCIDRs}'
```
Vous devriez voir des CIDR IPv6 comme 2001:db8::/64
Plugin CNI avec support IPv6 : AWS VPC CNI, Calico, Cilium, etc.

PostgreSQL

Votre PostgreSQL doit être accessible en IPv6 :

Fournisseurs cloud :

AWS RDS : définissez network_type = "DUAL"
Google Cloud SQL : IPv6 est automatiquement disponible
Azure Database for PostgreSQL : activez IPv6 dans les paramètres réseau

Self-hosted : assurez-vous que listen_addresses inclut IPv6 :

# postgresql.conf
listen_addresses = '::'  # Listen on all IPv4 and IPv6 addresses

Et configurez pg_hba.conf pour les connexions IPv6 :

host    all    all    2001:db8::/32    md5

Redis

Votre Redis doit être accessible en IPv6 :

Fournisseurs cloud :

AWS ElastiCache : définissez network_type = "dual_stack"
Google Memorystore : IPv6 est automatiquement disponible pour certains tiers. Cependant, les instances Memorystore for Redis ne sont pas compatibles avec IPv6.
Azure Cache for Redis : activez IPv6 dans les paramètres réseau

Self-hosted : assurez-vous que Redis se lie à IPv6 :

# redis.conf
bind :: 0.0.0.0

Connectivité réseau

Différentes configurations de cluster IPv6 ont différentes capacités de connectivité :

Type de cluster	Peut atteindre les services IPv4	Peut atteindre les services IPv6	Configuration courante
Dual-stack	✅ Oui	✅ Oui	Le plus courant, recommandé
IPv6-only avec NAT64/DNS64	✅ Oui (via traduction)	✅ Oui	Par défaut sur AWS EKS
IPv6-only sans NAT64	❌ Non	✅ Oui	Rare, non recommandé

NAT64/DNS64

NAT64 et DNS64 permettent aux pods IPv6-only d'atteindre les services externes IPv4-only en traduisant les requêtes IPv6 en IPv4. AWS EKS l'active par défaut pour les clusters IPv6.

Configuration

Configuration des values Helm

Ajoutez la configuration network.ipFamily à votre fichier de values Helm :

IPv4-only (par défaut)

# No configuration needed - this is the default
network:
  ipFamily: 'ipv4'

IPv6-only

network:
  ipFamily: 'ipv6'

# PostgreSQL and Redis must be IPv6-accessible
postgresql:
  host: '2001:db8::1234'  # IPv6 address or hostname with AAAA record
redis:
  main:
    host: '2001:db8::5678'

Vous devez aussi configurer Loki pour IPv6. Voir Configuration IPv6 Loki ci-dessous.

Dual-stack (GKE/AKS)

network:
  ipFamily: 'dualstack'

postgresql:
  host: 'postgres.example.com'  # Must have A or AAAA DNS record
redis:
  main:
    host: 'redis.example.com'

La configuration IPv6 Loki est optionnelle pour le dual-stack (les composants peuvent utiliser IPv4).

Configuration IPv6 Loki

Loki nécessite une configuration IPv6 explicite dans les clusters IPv6-only car il utilise memberlist pour la découverte de services entre composants. Ajoutez ceci à vos values Helm :

loki:
  loki:
    commonConfig:
      ring:
        instance_enable_ipv6: true
        kvstore:
          store: "memberlist"
    compactor:
      compactor_ring:
        instance_enable_ipv6: true
    distributor:
      ring:
        instance_enable_ipv6: true
    extraMemberlistConfig:
      bind_addr:
        - '::'
    frontend:
      instance_enable_ipv6: true
    index_gateway:
      ring:
        instance_enable_ipv6: true
    ingester:
      lifecycler:
        enable_inet6: true
    pattern_ingester:
      enabled: true
      lifecycler:
        enable_inet6: true
    query_scheduler:
      scheduler_ring:
        instance_enable_ipv6: true
    ruler:
      ring:
        instance_enable_ipv6: true

Exigence	Notes
IPv6-only	Requis - les composants ne peuvent pas communiquer sans cela
Dual-stack	Optionnel - les composants peuvent se rabattre sur IPv4

Déploiement

Preflights

Lorsque vos bases de données externes sont prêtes pour IPv6, testez la connectivité via nos preflights.

Mise à niveau d'un déploiement IPv4 existant

Vers dual-stack (GKE/AKS - sans interruption)

Les mises à niveau dual-stack sont transparentes car les services IPv4 existants continuent de fonctionner pendant qu'IPv6 est ajouté :

# values-ipv6.yaml
network:
  ipFamily: 'dualstack'

helm upgrade gitguardian gitguardian/gitguardian \
  --namespace gitguardian \
  -f values.yaml \
  -f values-ipv6.yaml

Vers IPv6-only (nécessite planification)

Interruption requise

La migration vers IPv6-only nécessite une interruption de service car les adresses IP changent.

Sauvegardez vos données
Migrez PostgreSQL et Redis vers IPv6

Mettez à jour les values Helm :

network:
  ipFamily: 'ipv6'

postgresql:
  host: '2001:db8::1234'  # New IPv6 address

redis:
  main:
    host: '2001:db8::5678'  # New IPv6 address

Déployez :

helm upgrade gitguardian gitguardian/gitguardian \
  --namespace gitguardian \
  -f values.yaml \
  -f values-ipv6.yaml

Mettez à jour les enregistrements DNS vers des enregistrements AAAA
Testez la connectivité

Validation

Après le déploiement, vérifiez qu'IPv6 fonctionne :

Vérifier les adresses IP des services

kubectl get svc -n gitguardian -o wide

Les services devraient afficher des adresses IPv6 (par exemple 2001:db8:1234:5678::a) ou à la fois IPv4 et IPv6 pour le dual-stack.

Tester la connectivité

# Get service IP and test health endpoint
SERVICE_IP=$(kubectl get svc internal-api -n gitguardian -o jsonpath='{.spec.clusterIP}')
kubectl run test-ipv6 --rm -it --image=curlimages/curl -- \
  curl -v "http://[$SERVICE_IP]:5050/api/v1/health"

Vérifier les logs applicatifs

kubectl logs -n gitguardian deployment/webapp-internal-api --tail=50

Cherchez le binding Gunicorn sur [::] et l'absence d'erreurs de connexion vers PostgreSQL/Redis.

Troubleshooting

Les services n'obtiennent pas d'adresses IPv6

Symptômes : les services affichent <none> ou seulement des adresses IPv4

Checklist :

Vérifiez que le cluster a un service CIDR IPv6 : kubectl cluster-info dump | grep -i service-cluster-ip-range
Vérifiez que network.ipFamily est correctement défini dans les values Helm
Pour EKS, vérifiez que le cluster a été créé avec ip_family = "ipv6"

Échecs de connexion PostgreSQL

Symptômes : could not translate host name to address

Checklist :

Testez la connectivité : kubectl run test-pg --rm -it --image=postgres:16 -- psql -h 2001:db8::1234 -U gitguardian
Vérifiez que le DNS retourne des enregistrements AAAA (si vous utilisez un hostname)
Vérifiez que les listen_addresses PostgreSQL incluent ::
Vérifiez que pg_hba.conf autorise votre sous-réseau IPv6

Échecs de connexion Redis

Symptômes : ConnectionError: Error connecting to Redis

Checklist :

Testez la connectivité : kubectl run test-redis --rm -it --image=redis:7 -- redis-cli -h 2001:db8::5678 PING
Vérifiez que la config bind Redis inclut ::
Utilisez le bon format d'URL : redis://[2001:db8::5678]:6379 (crochets requis pour IPv6)

Nginx échoue au démarrage

Symptômes : bind() to [::]:80 failed (99: Cannot assign requested address)

Solution : votre cluster ne supporte pas IPv6. Vérifiez que le plugin CNI supporte IPv6 ou utilisez network.ipFamily: 'ipv4'.

L'application crashe avec une erreur de parsing de port

Symptômes : '' is not a valid port number

Solution : ne définissez pas à la fois redis.main.url et redis.main.host. Utilisez l'un ou l'autre :

Format URL : redis.main.url: 'redis://[2001:db8::5678]:6379'
Ou host/port : redis.main.host: '2001:db8::5678' avec redis.main.port: 6379

Loki échoue au démarrage ou les composants ne communiquent pas

Symptômes : failed to join memberlist, no healthy instances in ring, ou too many unhealthy instances in the ring

Solution : assurez-vous que la configuration IPv6 Loki complète est appliquée. Le paramètre le plus souvent oublié est extraMemberlistConfig.bind_addr: ['::'].

Après avoir corrigé la configuration, redémarrez Loki :

kubectl rollout restart deployment/loki-backend -n gitguardian
kubectl rollout restart statefulset/loki-write -n gitguardian
kubectl rollout restart statefulset/loki-read -n gitguardian

Ingress et load balancers

AWS Application Load Balancer (ALB)

ingress:
  controller: aws_alb
  annotations:
    alb.ingress.kubernetes.io/scheme: internet-facing
    alb.ingress.kubernetes.io/ip-address-type: dualstack
    alb.ingress.kubernetes.io/target-type: ip

Nginx Ingress Controller

controller:
  service:
    ipFamilyPolicy: PreferDualStack
    ipFamilies: [IPv4, IPv6]

Istio Gateway

kubectl patch svc istio-ingressgateway -n istio-system \
  -p '{"spec":{"ipFamilyPolicy":"PreferDualStack","ipFamilies":["IPv4","IPv6"]}}'

Considérations de performance

IPv6 a des performances comparables à IPv4 avec une différence de latence négligeable. Dans les clusters IPv6-only avec NAT64/DNS64, attendez-vous à un overhead de traduction de ~5-10 ms lors de l'accès aux services externes IPv4-only.

Considérations de sécurité

Règles firewall : ajoutez des règles ip6tables à côté de vos règles iptables
Network policies : incluez les CIDR IPv6 dans vos règles ipBlock Kubernetes NetworkPolicy
TLS/SSL : fonctionne de manière identique à IPv4 (mêmes certificats, protocoles et cipher suites)

Compatibilité ascendante

Tous les changements IPv6 sont 100% compatibles en arrière. Les déploiements IPv4 existants continuent de fonctionner sans changements — aucune modification de values Helm ou de code applicatif requise sauf si vous activez IPv6.

Optimisation des coûts

Plateforme	Économies potentielles
AWS EKS	40-100 $/mois (pas de NAT Gateway ou de coûts d'IPv4 publiques)
GCP GKE	Impact minimal (les adresses IPv6 sont gratuites)

Ressources additionnelles

Support

Lors du signalement de problèmes liés à IPv6, fournissez :

# Kubernetes version
kubectl version --short

# Cluster IP families
kubectl cluster-info dump | grep -i service-cluster-ip-range

# CNI plugin
kubectl get pods -n kube-system | grep -i cni

# Service configuration
kubectl get svc internal-api -n gitguardian -o yaml

# Pod logs
kubectl logs deployment/webapp-internal-api -n gitguardian --tail=100

# Helm values (redact sensitive information)
helm get values gitguardian -n gitguardian

Démarrage rapide​

Values Helm​

Considérations spécifiques aux plateformes​

AWS EKS​

Google GKE​

Azure AKS​

On-premises​

Prérequis​

Prérequis cluster​

PostgreSQL​

Redis​

Connectivité réseau​

Configuration​

Configuration des values Helm​

IPv4-only (par défaut)​

IPv6-only​

Dual-stack (GKE/AKS)​

Configuration IPv6 Loki​

Déploiement​

Mise à niveau d'un déploiement IPv4 existant​

Vers dual-stack (GKE/AKS - sans interruption)​

Vers IPv6-only (nécessite planification)​

Validation​

Vérifier les adresses IP des services​

Tester la connectivité​

Vérifier les logs applicatifs​

Troubleshooting​

Les services n'obtiennent pas d'adresses IPv6​

Échecs de connexion PostgreSQL​

Échecs de connexion Redis​

Nginx échoue au démarrage​

L'application crashe avec une erreur de parsing de port​

Loki échoue au démarrage ou les composants ne communiquent pas​

Ingress et load balancers​

AWS Application Load Balancer (ALB)​

Nginx Ingress Controller​

Istio Gateway​

Considérations de performance​

Considérations de sécurité​

Compatibilité ascendante​

Optimisation des coûts​

Ressources additionnelles​

Support​

Was this page helpful?

Il manque quelque chose ?

Voir notre feuille de route

S'abonner sur GitHub

Soumettre une demande

Statut de l’API

Abonnez-vous à notre newsletter

Démarrage rapide

Values Helm

Considérations spécifiques aux plateformes

AWS EKS

Google GKE

Azure AKS

On-premises

Prérequis

Prérequis cluster

PostgreSQL

Redis

Connectivité réseau

Configuration

Configuration des values Helm

IPv4-only (par défaut)

IPv6-only

Dual-stack (GKE/AKS)

Configuration IPv6 Loki

Déploiement

Mise à niveau d'un déploiement IPv4 existant

Vers dual-stack (GKE/AKS - sans interruption)

Vers IPv6-only (nécessite planification)

Validation

Vérifier les adresses IP des services

Tester la connectivité

Vérifier les logs applicatifs

Troubleshooting

Les services n'obtiennent pas d'adresses IPv6

Échecs de connexion PostgreSQL

Échecs de connexion Redis

Nginx échoue au démarrage

L'application crashe avec une erreur de parsing de port

Loki échoue au démarrage ou les composants ne communiquent pas

Ingress et load balancers

AWS Application Load Balancer (ALB)

Nginx Ingress Controller

Istio Gateway

Considérations de performance

Considérations de sécurité

Compatibilité ascendante

Optimisation des coûts

Ressources additionnelles

Support