Déployer des applications sur OpenShift, c’est génial, surtout pour moi qui vient du dev. Et puis un jour on se dit que comprendre un peu mieux l’outil en allant faire un tour du coté de Kubernetes ça serait cool, au moins pour comprendre les gens qui le remettent en cause et savoir quelle est la magie qui tourne sous le capot. Et puis… on se heurte à la complexité des différentes couches et surtout sur la partie réseau. Entre les CNI, ingress, services, runtime, policies, le Service Mesh … l’empilement technologique peut devenir un vrai labyrinthe. Petit tour d’horizon :
1. Le runtime (CRI)
Depuis la dépréciation de Docker pour k8s, il faut choisir un runtime compatible avec la CRI (Container Runtime Interface) : containerd, CRI-O, CRI-Dockerd… Ces choix impactent les performances, la sécurité, la compatibilité avec les outils DevSecOps.
2. Le réseau des pods (CNI)
Chaque pod reçoit une IP unique via un plugin CNI (Container Network Interface) comme Calico, Flannel, Cilium, etc. Ce plugin gère la connectivité, mais aussi parfois les politiques de sécurité, le BGP, le VXLAN… À vous de le choisir, l’installer, le maintenir, sans quoi vos pods CoreDNS restent à vous regarder.
3. Les Services
Kubernetes fournit des abstractions réseau comme ClusterIP, NodePort ou LoadBalancer. Mais tout cela reste « bas niveau » : les connexions interservices, la résolution DNS, le routage… tout est à modéliser.
4. Ingress / Gateway API
Expose les applications au monde extérieur. Cela implique de déployer un contrôleur (NGINX, Istio, etc.), gérer les certificats, configurer les règles de routage, et assurer la haute dispo.
5. Les Network Policies
Elles sécurisent les flux réseau entre pods. Mais leur efficacité dépend du CNI et d’une bonne compréhension du modèle de communication. Mal configurées, elles peuvent casser la prod ou ouvrir des failles.
6. Le Service Mesh
Pour les architectures microservices (mais pas que!), un service mesh (comme Istio, Linkerd) devient essentiel : il permet d’ajouter observabilité, sécurité (mTLS), gestion fine du trafic, retries, circuit breakers, etc.
Mais l’intégration est lourde : injection de sidecars, gestion des CRD, configuration complexe, surcoût en ressources.
Et si on rajoute la concurrence des stacks avec Calico qui coche 2 points, Istio qui en fait 3 mais pas les mêmes que Calico, enfin pas pour tout … BREF
Why do I need a Service Mesh as well as a CNI? | by Martin Hodges | Medium
Pourquoi OpenShift et ce qu’il m’a invisibilisé toutes ces années?
OpenShift prend tout ce puzzle et vous livre une plateforme intégrée, supportée et prête pour la prod, comme ça le bêbête dev junior que j’étais s’en sort avec de la bidouille le temps de se faire les dents sur Spring. Bon il faut l’avouer, le fait que ITS4U GROUP soit un partenaire historique de Red Hat et des solutions OpenShift m’a mis le pied à l’étrier !
On y trouve :
- CRI intégré : CRI-O, optimisé pour Kubernetes.
- CNI intégré : OVN-Kubernetes, supporté par Red Hat avec network policies activées nativement.
- Ingress Controller & TLS managés, via une API simplifiée et des routes explicites.
- Console & CLI modernes pour gérer la sécurité réseau et la visibilité sans manipulations complexes parce que le RTFM pour le scale up c’est sympa, mais le click bouton c’est moins frustrant.
- OpenShift Service Mesh (basé sur Istio) : intégré, supporté, avec une expérience unifiée via la console, des dashboards clairs, et une gestion simplifiée des policies mTLS, du trafic et des observabilités.
- Support enterprise : fini les heures de troubleshooting par ton équipe DevOps adoré dans les forums GitHub pour un bug obscur d’interface chaise-clavier.
En résumé : Kubernetes est modulaire et puissant, mais cela vous oblige à assembler (et maintenir) vous-même un puzzle complexe. OpenShift vous offre une plateforme cohérente, sécurisée, et orientée production, sans sacrifier la flexibilité.
