Retour aux articles
blog — devops — zsh$ cat devops.md# 30 mars 2025Google bloque Hetzner auhasard et casse ton clusterKubernetes
3 min de lecture

Google Cloud Armor bloque des IPs Hetzner au hasard pour pull les images Kubernetes. Ton cluster casse et le message d'erreur t'aide pas.

KubernetesHetznerCloud

Tu démarres un cluster Kubernetes sur Hetzner. Un node pull les images sans problème. Un autre node reçoit 403 Forbidden. Même réseau, même config, résultat différent

unexpected status from HEAD request to
https://registry.k8s.io/v2/pause/manifests/3.7: 403 Forbidden

Google Cloud Armor bloque ton IP Hetzner parce que quelqu’un d’autre qui avait cette plage d’IP a fait un truc que Google a pas aimé. Peut-être il y a des mois. Peut-être des années

registry.k8s.io est derrière le load balancer de Google avec la protection Cloud Armor. Certaines plages d’IP Hetzner sont sur la blocklist. L’issue GitHub #138 documente ça depuis 2023. L’issue #1664 montre que ça arrive encore en 2025

Le côté aléatoire rend ça pire. Tu construis un cluster 3 nodes. Node 1 marche. Node 2 marche. Node 3 reçoit des 403. Même réseau, même région. Ça change rien

Pourquoi ça arrive

Hetzner recycle les IPs. Tu hérites de la réputation de celui qui avait ton IP avant. Il a fait tourner un botnet? T’es bloqué. Il a scraped Google? T’es bloqué

L’équipe du registry Kubernetes est au courant. De l’issue #138: “we’re using cloud armor, configured here”

Ils ont pas corrigé. Position de Google: ces IPs ont montré un comportement abusif. Peu importe si c’était toi

Ce qui marche

Utilise Quay ou Docker Hub

La plupart des images Kubernetes sont mirrorées sur d’autres registries:

# /etc/rancher/k3s/registries.yaml
mirrors:
  registry.k8s.io:
    endpoint:
      - "https://quay.io/kubernetes"

Ou update tes manifests directement. Au lieu de registry.k8s.io/pause:3.7, utilise quay.io/kubernetes/pause:3.7

Teste avant de déployer

Check si ton IP est bloquée:

curl -I https://registry.k8s.io/v2/

403 = bloqué. Prends une IP différente avant de construire ton cluster

Pour les clusters existants, teste tous les nodes:

for node in $(kubectl get nodes -o name); do
  kubectl debug $node -it --image=busybox -- \
    wget -O- https://registry.k8s.io/v2/ 2>&1 | grep -q 403 && \
    echo "$node: BLOCKED" || echo "$node: OK"
done

Contacte le support Hetzner

Ouvre un ticket sur https://console.hetzner.cloud/support. Dis-leur que ton IP est bloquée par Google Cloud Armor

Ils peuvent la swap. Ou pas. D’après l’issue #138, certains users ont eu de nouvelles IPs, d’autres non

Dernier recours: lance un mirror

Si les images existent pas sur d’autres registries, mirrorise-les toi-même:

# /etc/rancher/k3s/registries.yaml
mirrors:
  registry.k8s.io:
    endpoint:
      - "https://your-mirror.example.com"

Essaie Quay d’abord. Le self-hosting c’est overkill dans la plupart des cas

Pourquoi ça sera pas corrigé

Google devrait allowlist les gros cloud providers. Hetzner héberge des milliers de clusters prod

Bloquer des plages d’IP entières à cause d’abus historiques, c’est de la sécurité fainéante. Le message d’erreur devrait dire “bloqué par Cloud Armor” au lieu de “403 Forbidden”

Ça arrivera jamais. Les registries de conteneurs sont de l’infrastructure critique. Kubernetes peut pas fonctionner sans. Mais le projet utilise Google Cloud Armor quand même. Les issues sont fermées. Les users implémentent des workarounds

Ça affecte n’importe quel provider qui recycle les IPs. DigitalOcean, Vultr, OVH, Linode. L’hébergement partagé = réputation partagée. L’historique de ton IP, c’est pas toi qui le contrôles

Planifie en conséquence. Utilise Quay. Teste tes IPs. Suppose pas que registry.k8s.io va marcher

Vous avez aimé cet article ?

Faites-le savoir ! Un partage, c'est toujours apprécié.

À propos de l'auteur

Sofiane Djerbi

Sofiane Djerbi

Architecte Cloud & Kubernetes, Expert FinOps. J'aide les entreprises à construire des infrastructures scalables, sécurisées et rentables.

Commentaires