Mutating Registry Webhook : Comment j'ai résolu le cauchemar des registries Docker en entreprise

Après des années à gérer des clusters Kubernetes en entreprise, j'ai identifié un problème récurrent : la gestion des registries Docker. Entre les limitations de bande passante, les quotas des registries publics, et les politiques de sécurité d'entreprise, c'est rapidement devenu un cauchemar. C'est pour résoudre ce problème que j'ai développé Mutating Registry Webhook.

Le problème : pourquoi les registries Docker sont un enfer en entreprise

La dépendance aux registries externes

Dans un environnement Kubernetes moderne, chaque déploiement peut référencer des dizaines d'images Docker provenant de sources variées : Docker Hub, Google Container Registry, Quay.io, GitHub Container Registry... Cette diversité pose plusieurs problèmes :

• Rate limiting : Docker Hub impose des limites strictes (100 pulls/6h pour les utilisateurs anonymes)
• Bande passante : Télécharger des images de plusieurs gigaoctets depuis l'autre bout du monde n'est pas optimal
• Disponibilité : Une panne de Docker Hub ou GCR peut paralyser vos déploiements
• Sécurité : Les politiques d'entreprise exigent souvent que toutes les images passent par un registry interne

Les solutions traditionnelles et leurs limites

Les approches classiques sont laborieuses et fragiles :

1. Modifier manuellement toutes les références d'images dans les charts Helm, manifestes Kustomize ou Operators : Un cauchemar de maintenance
2. Scripts de réécriture : Fragiles et difficiles à maintenir
3. Proxies au niveau réseau : Complexes à configurer et peu flexibles
4. Pull-through caches : Utiles mais nécessitent toujours de modifier les URLs

La solution : Mutating Registry Webhook

J'ai créé Mutating Registry Webhook pour automatiser complètement ce processus. C'est un webhook d'admission Kubernetes qui intercepte la création et la modification des Pods pour réécrire automatiquement les URLs des images selon vos règles.

Comment ça marche ?

Le système repose sur quatre composants clés :

1. Une CRD (Custom Resource Definition) qui permet de définir des règles de réécriture
2. Un webhook mutant qui intercepte les créations/modifications de Pods
3. Un contrôleur qui surveille les changements de règles
4. Un cache en mémoire pour des performances optimales (lookups en O(1))

Exemple concret

Imaginons que vous voulez rediriger toutes les images Docker Hub vers votre registry interne. Vous créez simplement cette règle :

apiVersion: dev.flemzord.fr/v1alpha1
kind: RegistryRewriteRule
metadata:
  name: docker-hub-to-ecr
spec:
  rules:
    # Redirect Docker Hub images to ECR pull-through cache
    - match: '^docker\.io/(.*)'
      replace: 'internal-registry.company.com/dockerhub/$1'
    
    # Handle images without explicit registry (defaults to docker.io)
    - match: '^([^/]+/[^/]+)$'
      replace: 'internal-registry.company.com/dockerhub/$1'

Désormais, toute image comme docker.io/nginx:latest sera automatiquement réécrite en internal-registry.company.com/docker-hub/nginx:latest. Vos développeurs continuent à utiliser les URLs originales, le webhook s'occupe du reste.

Des règles flexibles et puissantes

Le système de règles est conçu pour être extrêmement flexible :

• Ciblage par namespace : Appliquez des règles différentes selon l'environnement
• Sélection par labels : Ciblez uniquement certains Pods
• Regex puissantes : Capturez et transformez n'importe quelle structure d'URL
• Priorités : Gérez l'ordre d'application des règles

Exemple avancé avec plusieurs registries :

apiVersion: dev.flemzord.fr/v1alpha1
kind: RegistryRewriteRule
metadata:
  name: multi-registry-routing
spec:
  rules:
    - match: '^(gcr\\.io|quay\\.io|ghcr\\.io)/(.*)$'
      replace: 'cache.internal.com/$1/$2'

Performance et fiabilité

Un des aspects critiques était la performance. Le webhook doit traiter chaque Pod créé dans le cluster sans introduire de latence notable :

• Temps de mutation : ~0.7μs par image
• Utilisation mémoire : ~50MB pour des milliers de règles
• Cache intelligent : Les règles sont pré-compilées et indexées
• Tests exhaustifs : Couverture de code complète

Intégration avec cert-manager

La sécurité est assurée par une intégration native avec cert-manager. Les certificats TLS sont automatiquement gérés et renouvelés, garantissant des communications sécurisées entre Kubernetes et le webhook.

Installation et utilisation

L'installation est simple et rapide :

# Installer cert-manager (si pas déjà présent)
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml

# Installer Mutating Registry Webhook
kubectl apply -f https://raw.githubusercontent.com/flemzord/mutating-registry-webhook/main/dist/install.yaml

Cas d'usage réels

1. Pull-through cache d'entreprise

Réduisez drastiquement votre bande passante en redirigeant toutes les images externes vers votre cache interne :

apiVersion: dev.flemzord.fr/v1alpha1
kind: RegistryRewriteRule
metadata:
  name: enterprise-cache
spec:
  rules:
    - match: '^(?!internal-registry\\.)(.*)$'
      replace: 'internal-registry.company.com/cache/$1'

2. Migration progressive

Migrez progressivement d'un registry à un autre sans toucher au code :

apiVersion: dev.flemzord.fr/v1alpha1
kind: RegistryRewriteRule
metadata:
  name: gradual-migration
spec:
  rules:
    - match: '^old-registry\\.company\\.com/(.*)$'
      replace: 'new-registry.company.com/$1'
      conditions:
        namespaces: ['canary', 'staging']

3. Environnements isolés

Créez des environnements complètement isolés avec leurs propres registries :

apiVersion: dev.flemzord.fr/v1alpha1
kind: RegistryRewriteRule
metadata:
  name: isolated-dev
spec:
  rules:
    - match: '^(.*)$'
      replace: 'dev-registry.local/$1'

Monitoring et observabilité

Le webhook expose des métriques Prometheus pour un monitoring complet :

• Nombre de mutations par règle
• Temps de traitement
• Erreurs éventuelles
• État du cache

Ces métriques permettent de suivre l'utilisation et d'identifier rapidement tout problème.

Conclusion

Mutating Registry Webhook transforme un problème complexe en solution simple et élégante. Plus besoin de modifier manuellement les références d'images dans les charts Helm, manifestes Kustomize ou Operators, de maintenir des scripts fragiles, ou de former les développeurs à utiliser des URLs spécifiques.

Le projet est open source et activement maintenu. J'accueille avec plaisir les contributions, suggestions et retours d'expérience. Si vous gérez des clusters Kubernetes en entreprise et que vous en avez assez de jongler avec les registries, essayez Mutating Registry Webhook.

Retrouvez le projet sur GitHub : github.com/flemzord/mutating-registry-webhook