Configuration des proxies dans les clusters Kubernetes : guide complet pour les ingénieurs DevOps

Lors du déploiement de Kubernetes dans un environnement d'entreprise ou derrière un pare-feu, il est souvent nécessaire de configurer un serveur proxy pour accéder aux ressources externes. Cela est crucial pour le téléchargement d'images de conteneurs, la mise à jour de paquets et l'interaction avec des API externes. Dans ce guide, nous examinerons tous les niveaux de configuration du proxy dans Kubernetes — de la configuration des nœuds aux pods individuels.

Pourquoi un proxy est-il nécessaire dans les clusters Kubernetes

Les clusters Kubernetes dans un environnement d'entreprise fonctionnent souvent dans des réseaux isolés avec un accès Internet limité. Un serveur proxy résout plusieurs problèmes critiques :

• Téléchargement d'images de conteneurs — Docker Hub, Google Container Registry, des registres privés nécessitent un accès externe
• Mise à jour des paquets — installation des dépendances via apt, yum, pip à l'intérieur des conteneurs
• Accès aux API externes — intégration avec des services cloud, surveillance, journalisation
• Sécurité — contrôle du trafic, filtrage des domaines, journalisation des requêtes
• Mise en cache — accélération des requêtes répétées vers les mêmes ressources

Sans une configuration correcte du proxy, vous rencontrerez des erreurs telles que "image pull failed", "connection timeout" ou "network unreachable" lors de la tentative de déploiement d'applications. Cela est particulièrement critique pour les pipelines CI/CD automatisés, où chaque seconde d'arrêt coûte de l'argent.

Niveaux de configuration du proxy dans Kubernetes

Kubernetes a une architecture à plusieurs niveaux, et le proxy doit être configuré à chaque niveau en fonction des tâches :

Chaque niveau nécessite une configuration distincte, et négliger l'un d'eux peut entraîner des problèmes. Par exemple, si vous configurez le proxy uniquement pour Docker, mais pas pour les pods, les images seront téléchargées, mais les applications à l'intérieur des conteneurs ne pourront pas accéder aux API externes.

Configuration du proxy pour Docker et containerd

Le runtime de conteneur est le premier composant à configurer, car il est responsable du téléchargement des images de conteneurs à partir de registres externes. Examinons la configuration pour les deux runtimes populaires.

Configuration du proxy pour Docker

Pour Docker, vous devez créer un fichier drop-in systemd qui ajoutera des variables d'environnement au service Docker :

# Créez un répertoire pour la configuration
sudo mkdir -p /etc/systemd/system/docker.service.d

# Créez un fichier avec les paramètres du proxy
sudo tee /etc/systemd/system/docker.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local,.svc"
EOF

# Rechargez la configuration systemd
sudo systemctl daemon-reload

# Redémarrez Docker
sudo systemctl restart docker

# Vérifiez que les paramètres ont été appliqués
sudo systemctl show --property=Environment docker

Après cela, Docker pourra télécharger des images via le serveur proxy. Vous pouvez vérifier le fonctionnement avec la commande :

docker pull nginx:latest

Configuration du proxy pour containerd

Containerd est utilisé dans les clusters Kubernetes modernes comme runtime principal. La configuration du proxy pour lui est légèrement différente :

# Créez un répertoire pour la configuration
sudo mkdir -p /etc/systemd/system/containerd.service.d

# Créez un fichier avec les paramètres du proxy
sudo tee /etc/systemd/system/containerd.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.cluster.local,.svc"
EOF

# Rechargez la configuration
sudo systemctl daemon-reload
sudo systemctl restart containerd

# Vérifiez le statut
sudo systemctl status containerd

Configuration du proxy pour kubelet

Kubelet est l'agent Kubernetes qui fonctionne sur chaque nœud du cluster. Il a également besoin d'accéder au serveur API et aux ressources externes. La configuration dépend de la méthode d'installation de Kubernetes.

Pour les clusters kubeadm

Si vous utilisez kubeadm, configurez le proxy via systemd :

# Créez un répertoire pour la configuration de kubelet
sudo mkdir -p /etc/systemd/system/kubelet.service.d

# Créez un fichier avec les paramètres du proxy
sudo tee /etc/systemd/system/kubelet.service.d/http-proxy.conf <<EOF
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,10.96.0.0/12,10.244.0.0/16,.cluster.local,.svc"
EOF

# Rechargez kubelet
sudo systemctl daemon-reload
sudo systemctl restart kubelet

Pour les Kubernetes gérés (EKS, GKE, AKS)

Dans les services Kubernetes gérés, la configuration de kubelet est généralement effectuée via les paramètres de démarrage des nœuds ou des scripts de données utilisateur. Par exemple, pour AWS EKS :

#!/bin/bash
# Script de données utilisateur pour les nœuds de travail EKS

# Configuration du proxy pour le système
cat <<EOF >> /etc/environment
HTTP_PROXY=http://proxy.company.com:8080
HTTPS_PROXY=http://proxy.company.com:8080
NO_PROXY=localhost,127.0.0.1,169.254.169.254,.ec2.internal,.cluster.local
EOF

# Configuration pour kubelet
mkdir -p /etc/systemd/system/kubelet.service.d
cat <<EOF > /etc/systemd/system/kubelet.service.d/http-proxy.conf
[Service]
Environment="HTTP_PROXY=http://proxy.company.com:8080"
Environment="HTTPS_PROXY=http://proxy.company.com:8080"
Environment="NO_PROXY=localhost,127.0.0.1,169.254.169.254,.ec2.internal,.cluster.local"
EOF

systemctl daemon-reload
systemctl restart kubelet

Notez l'ajout de 169.254.169.254 dans NO_PROXY — c'est l'adresse du service de métadonnées AWS, qui doit être accessible sans proxy.

Configuration du proxy au niveau des pods

Même si vous avez configuré le proxy pour Docker et kubelet, les applications à l'intérieur des pods n'utiliseront pas automatiquement le proxy. Vous devez explicitement indiquer les variables d'environnement dans les manifestes Kubernetes.

Configuration via le manifeste Deployment

La manière la plus simple consiste à ajouter des variables d'environnement à la spécification du conteneur :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: default
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: app
        image: my-company/my-app:latest
        env:
        - name: HTTP_PROXY
          value: "http://proxy.company.com:8080"
        - name: HTTPS_PROXY
          value: "http://proxy.company.com:8080"
        - name: NO_PROXY
          value: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"
        ports:
        - containerPort: 8080

Utilisation de ConfigMap pour une configuration centralisée

Pour éviter de dupliquer les paramètres du proxy dans chaque Deployment, créez un ConfigMap :

apiVersion: v1
kind: ConfigMap
metadata:
  name: proxy-config
  namespace: default
data:
  HTTP_PROXY: "http://proxy.company.com:8080"
  HTTPS_PROXY: "http://proxy.company.com:8080"
  NO_PROXY: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"

Ensuite, utilisez ce ConfigMap dans le Deployment :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  template:
    spec:
      containers:
      - name: app
        image: my-company/my-app:latest
        envFrom:
        - configMapRef:
            name: proxy-config

Cette approche simplifie la gestion : en cas de changement d'adresse du proxy, il suffit de mettre à jour le ConfigMap, et après le redémarrage des pods, les nouveaux paramètres seront appliqués automatiquement.

Injection automatique via MutatingWebhook

Pour ajouter automatiquement les variables de proxy à tous les pods, vous pouvez utiliser MutatingAdmissionWebhook. C'est une approche avancée qui nécessite le développement de votre propre service webhook, mais elle permet de gérer centralement les paramètres sans modifier les manifestes des applications.

Configuration correcte de NO_PROXY

La variable NO_PROXY définit les adresses et domaines qui doivent contourner le serveur proxy. Une configuration incorrecte de NO_PROXY est la cause la plus fréquente de problèmes dans les clusters Kubernetes.

Exceptions obligatoires pour Kubernetes

Les adresses et plages suivantes DOIVENT TOUJOURS être dans NO_PROXY :

Exemple de configuration complète de NO_PROXY

NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,10.96.0.0/12,.cluster.local,.svc,.default.svc,.default.svc.cluster.local,kubernetes.default.svc,kubernetes.default.svc.cluster.local

Configuration de kubectl pour fonctionner via un proxy

Si vous gérez un cluster depuis une station de travail qui se trouve derrière un proxy, configurez les variables d'environnement pour kubectl :

# Pour Linux/macOS - ajoutez dans ~/.bashrc ou ~/.zshrc
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
export NO_PROXY=localhost,127.0.0.1,kubernetes.default.svc,.cluster.local

# Pour Windows PowerShell
$env:HTTP_PROXY="http://proxy.company.com:8080"
$env:HTTPS_PROXY="http://proxy.company.com:8080"
$env:NO_PROXY="localhost,127.0.0.1,kubernetes.default.svc,.cluster.local"

Après cela, kubectl pourra se connecter au serveur API du cluster via le proxy. Vérifiez le fonctionnement :

kubectl cluster-info
kubectl get nodes

Configuration du proxy avec authentification

Si le serveur proxy nécessite une authentification, ajoutez les identifiants dans l'URL :

export HTTP_PROXY=http://username:password@proxy.company.com:8080
export HTTPS_PROXY=http://username:password@proxy.company.com:8080

Diagnostic et résolution des problèmes typiques

Même avec une configuration correcte, des problèmes peuvent survenir. Examinons les erreurs les plus fréquentes et comment les résoudre.

Erreur "ImagePullBackOff" lors du téléchargement d'images

Symptômes : Les pods ne démarrent pas, les événements montrent l'erreur "Failed to pull image" ou "connection timeout".

Diagnostic :

# Vérifiez les événements du pod
kubectl describe pod <pod-name>

# Vérifiez les paramètres du proxy dans Docker/containerd
sudo systemctl show --property=Environment docker
sudo systemctl show --property=Environment containerd

# Essayez de télécharger l'image manuellement sur le nœud
sudo docker pull nginx:latest
sudo crictl pull nginx:latest

Solution : Assurez-vous que le proxy est configuré pour le runtime de conteneur et que le domaine du registre d'images n'est pas dans NO_PROXY.

Problèmes de résolution DNS à l'intérieur du cluster

Symptômes : Les pods ne peuvent pas se connecter les uns aux autres par des noms DNS (par exemple, service-name.namespace.svc.cluster.local).

Diagnostic :

# Vérifiez DNS depuis le pod
kubectl run -it --rm debug --image=busybox --restart=Never -- nslookup kubernetes.default

# Vérifiez les variables de proxy dans le pod
kubectl exec -it <pod-name> -- env | grep PROXY

Solution : Ajoutez .cluster.local et .svc dans NO_PROXY.

Lenteur ou timeouts lors de l'accès aux API externes

Symptômes : Les applications fonctionnent lentement ou obtiennent un timeout lors des requêtes vers des services externes.

Diagnostic :

# Vérifiez la disponibilité du proxy depuis le pod
kubectl exec -it <pod-name> -- curl -v -x http://proxy.company.com:8080 https://www.google.com

# Mesurez le temps de réponse
kubectl exec -it <pod-name> -- time curl -x http://proxy.company.com:8080 https://api.example.com

Solution : Le problème peut être lié à la performance du serveur proxy. Envisagez d'utiliser des proxies résidentiels avec un emplacement géographique proche pour réduire les latences.

Erreurs SSL/TLS lors de l'utilisation via un proxy

Symptômes : Erreurs telles que "certificate verify failed" ou "SSL handshake failed".

Cause : Certains serveurs proxy effectuent une inspection SSL (décryptage du trafic HTTPS), ce qui nécessite l'installation du certificat racine du proxy.

Solution :

# Créez un ConfigMap avec le certificat du proxy
kubectl create configmap proxy-ca-cert --from-file=ca.crt=/path/to/proxy-ca.crt

# Montez le certificat dans le pod et ajoutez-le au magasin de certificats système
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        volumeMounts:
        - name: proxy-ca
          mountPath: /usr/local/share/ca-certificates/proxy-ca.crt
          subPath: ca.crt
      volumes:
      - name: proxy-ca
        configMap:
          name: proxy-ca-cert

Meilleures pratiques pour le proxy en production

Sur la base de l'expérience d'exploitation des clusters Kubernetes dans un environnement d'entreprise, voici des recommandations pour un fonctionnement fiable avec le proxy :

1. Utilisez des serveurs proxy hautement disponibles

Le proxy devient un point de défaillance unique pour l'ensemble du cluster. Configurez plusieurs serveurs proxy derrière un équilibreur de charge :

HTTP_PROXY=http://proxy-lb.company.com:8080

Où proxy-lb.company.com est l'équilibreur de charge devant plusieurs serveurs proxy.

2. Gestion centralisée de la configuration

Utilisez ConfigMap ou Secret pour stocker les paramètres du proxy au lieu de les coder en dur dans chaque manifeste :

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-proxy-config
  namespace: kube-system
data:
  HTTP_PROXY: "http://proxy-lb.company.com:8080"
  HTTPS_PROXY: "http://proxy-lb.company.com:8080"
  NO_PROXY: "localhost,127.0.0.1,.cluster.local,.svc,10.0.0.0/8"

3. Surveillance et alertes

Configurez la surveillance de la disponibilité des serveurs proxy et des alertes en cas de problèmes :

• Temps de réponse du proxy (doit être < 100ms pour les proxys locaux)
• Nombre d'erreurs de connexion au proxy
• Nombre d'événements ImagePullBackOff dans le cluster
• Charge CPU et réseau sur les serveurs proxy

4. Documentez les exceptions NO_PROXY

Tenez une documentation sur les domaines et adresses IP ajoutés à NO_PROXY et pourquoi. Cela aidera lors du dépannage et de l'audit de sécurité.

5. Testez les modifications dans un environnement de développement

Avant de modifier les paramètres du proxy en production, testez toujours dans un cluster de développement/staging :

# Pod de test pour vérifier le proxy
apiVersion: v1
kind: Pod
metadata:
  name: proxy-test
spec:
  containers:
  - name: test
    image: curlimages/curl:latest
    command: ["sleep", "3600"]
    env:
    - name: HTTP_PROXY
      value: "http://new-proxy.company.com:8080"
    - name: HTTPS_PROXY
      value: "http://new-proxy.company.com:8080"

# Vérifiez la disponibilité des ressources externes
kubectl exec -it proxy-test -- curl -v https://registry.k8s.io
kubectl exec -it proxy-test -- curl -v https://docker.io

6. Utilisez différents types de proxy pour différentes tâches

Pour les composants critiques (téléchargement d'images, API du cluster), utilisez des proxies de datacenter rapides, et pour les applications nécessitant une diversité géographique des IP — des proxies résidentiels ou mobiles.

7. Mettez régulièrement à jour la liste NO_PROXY

Lors de l'ajout de nouveaux services ou de changements dans la topologie réseau, mettez à jour NO_PROXY. Automatisez cela via des charts Helm ou Kustomize :

# values.yaml pour Helm chart
proxy:
  enabled: true
  http: "http://proxy.company.com:8080"
  https: "http://proxy.company.com:8080"
  noProxy:
    - localhost
    - 127.0.0.1
    - .cluster.local
    - .svc
    - 10.0.0.0/8
    - internal-service.company.com

Conclusion

La configuration du proxy dans les clusters Kubernetes est une tâche à plusieurs niveaux qui nécessite une attention particulière aux détails à chaque niveau : du système d'exploitation et du runtime de conteneur aux pods individuels. Une configuration correcte garantit le bon fonctionnement du cluster, un accès sécurisé aux ressources externes et la conformité aux politiques de sécurité de l'entreprise.

Points clés à retenir :

• Configurez le proxy à tous les niveaux : OS, runtime de conteneur, kubelet, pods
• Configurez correctement NO_PROXY, en incluant tous les réseaux internes du cluster
• Utilisez une gestion centralisée via ConfigMap
• Surveillez la disponibilité et la performance des serveurs proxy
• Testez les modifications avant de les appliquer en production

Pour les clusters Kubernetes critiques, nous recommandons d'utiliser des proxies de datacenter fiables avec une haute disponibilité et de faibles latences. Cela garantira un fonctionnement stable de l'infrastructure et minimisera les risques d'arrêt dus à des problèmes d'accès réseau.

En cas de problèmes, utilisez une approche systématique pour le diagnostic : vérifiez les paramètres à chaque niveau, analysez les journaux et événements, testez la connexion manuellement. La plupart des problèmes de proxy dans Kubernetes peuvent être résolus par une configuration correcte des variables d'environnement et de NO_PROXY.