Lorsqu’une entreprise déploie un cluster Kubernetes, elle a souvent déjà des reverse proxies en place pour gérer l’accès à ses services web, qu’ils soient publics ou internes (DMZ, PROD, QUALIF). L’enjeu est d’intégrer ces reverse proxies existants avec Kubernetes sans perturber les configurations actuelles, notamment en gardant les vhosts en place. Kubernetes sera utilisé comme solution de dernier recours, avec un default_server dans le reverse proxy pour rediriger vers un Ingress Controller en cas de service non trouvé.
Table of Contents
Reverse Proxy : Fonction et Rôle
Un reverse proxy est un intermédiaire qui redirige les requêtes entrantes vers les serveurs appropriés. Dans une architecture d’entreprise, les reverse proxies sont souvent configurés pour des environnements spécifiques :
- DMZ : Pour les services publics.
- PROD : Pour les applications internes critiques.
- QUALIF : Pour les environnements de test.
Les vhosts (virtual hosts) sont utilisés pour rediriger les requêtes basées sur des noms d’hôtes spécifiques vers les services backend correspondants.
Intégration de Kubernetes avec les Reverse Proxies
Garder les vhosts existants
Les reverse proxies actuels continueront de rediriger les requêtes vers les services définis via des vhosts configurés. Il est important de ne pas toucher à ces configurations pour garantir la continuité des services existants.
Utiliser Kubernetes comme « default_server »
Kubernetes est utilisé en dernier recours pour gérer les requêtes qui ne correspondent à aucun vhost. Cela signifie que si un reverse proxy ne trouve pas le service demandé, il redirige la requête vers le Ingress Controller de Kubernetes.
Exemple de Configuration NGINX
# Configuration NGINX avec les vhosts existants et Kubernetes en fallback
server {
listen 80;
server_name app.prod.example.com;
location / {
proxy_pass http://backend_prod;
}
}
server {
listen 80;
server_name app.dmz.example.com;
location / {
proxy_pass http://backend_dmz;
}
}
# Kubernetes en tant que default_server
server {
listen 80 default_server;
server_name _;
location / {
proxy_pass http://kubernetes_ingress_controller;
}
}Gestion du SSL : Offloading ou Chiffrement de Bout en Bout
Dans de nombreuses architectures, il est courant que le reverse proxy gère le SSL (appelé SSL offloading). Cela signifie que le trafic entre le client et le reverse proxy est sécurisé via HTTPS, mais que les communications entre le reverse proxy et les services backend (ici, Kubernetes) se font en HTTP, généralement sur le port 80.
Scénario SSL Offloading :
- Client → Reverse Proxy : Le trafic est chiffré (HTTPS).
- Reverse Proxy → Kubernetes : Le trafic est redirigé en HTTP (port 80).
Cette approche simplifie la gestion des certificats SSL, car ils ne sont gérés qu’au niveau du reverse proxy. Cependant, l’idéal serait de chiffrer de bout en bout, c’est-à-dire :
- Client → Reverse Proxy : Trafic chiffré avec HTTPS.
- Reverse Proxy → Kubernetes : Trafic également chiffré avec HTTPS, jusqu’à l’Ingress Controller Kubernetes.
Cela garantit un niveau de sécurité maximal en évitant que les données soient transmises en clair, même dans les réseaux internes. Toutefois, pour les infrastructures où la gestion des certificats est centralisée, l’approche SSL offloading reste acceptable, tant que les réseaux internes sont bien sécurisés.
Surveillance et Sondes de Santé
Kubernetes est déjà configuré avec des probes (sondes de santé) pour surveiller les services déployés. Si un service dans Kubernetes rencontre un problème, il renverra une réponse 404, et le reverse proxy pourra afficher une page d’erreur globale préconfigurée. Il n’est donc pas nécessaire de configurer des sondes de santé supplémentaires au niveau du reverse proxy, car vos déploiements Kubernetes se doivent de déjà gérer ce mécanisme en interne.
Avantages de cette Approche
- Compatibilité : Les vhosts existants ne sont pas modifiés.
- Évolutivité : Kubernetes peut être intégré progressivement sans perturber l’infrastructure.
- Simplicité : Kubernetes est utilisé uniquement en dernier recours, simplifiant la gestion des routes.
- Sécurité : L’approche SSL offloading est simple, mais un chiffrement de bout en bout peut être envisagé pour plus de sécurité.
Conclusion
L’intégration d’un cluster Kubernetes dans une entreprise ayant déjà des reverse proxies en place se fait facilement en conservant les vhosts existants et en utilisant Kubernetes comme default_server. Cela garantit une transition en douceur et permet à Kubernetes de gérer les services nouveaux ou migrés sans modifier l’infrastructure actuelle. Pour la gestion des certificats, le SSL offloading est pratique, mais le chiffrement de bout en bout est recommandé pour un maximum de sécurité. Les sondes de santé déjà présentes dans Kubernetes assurent le suivi des services sans ajout de complexité.
