Je suis nouveau dans le domaine de Kubernetes et d'openshift (je viens du monde de Docker Swarm) et j'ai des difficultés avec certaines documentations de Kubernetes et d'openshift, notamment en ce qui concerne les points suivants itinéraire y services . Je cherchais à savoir comment exposer un ensemble de conteneurs répliqués en externe et j'ai trouvé documentation kubernetes utilise un service pour exposer le pod tandis que openshift utilise les routes . quelqu'un peut-il m'expliquer les différences ?
Réponses
Trop de publicités?
Il n'y a que des différences mineures dans les outils utilisés. OpenShift est une distribution Kubernetes, ce qui signifie qu'il s'agit d'une collection de composants présélectionnés par l'opinion publique. Ainsi, pour Ingress, OpenShift utilise HAProxy pour faire entrer le trafic (HTTP) dans le cluster. D'autres distributions Kubernetes utilisent peut-être le NGINX Ingress Controller ou quelque chose de similaire.
Así que Services sont utilisés pour équilibrer le trafic à l'intérieur du cluster. Ainsi, lorsque vous créez un ReplicaSet vous aurez plusieurs Pods en fonctionnement. Pour "parler" à ces pods, vous créez généralement un fichier de type Service . Ce Service distribuera le trafic de manière égale entre vos Pods.
Donc pour avoir du trafic HTTP(S) de l'extérieur vers ton Service OpenShift utilise Routes ( Ingress dans d'autres distributions Kubernetes) :
+-----+
+-->+ Pod |
+-------+ +---------+ | +-----+
Traffic--->+ Route +------>+ Service +--+-->+ Pod |
+-------+ +---------+ | +-----+
+-->+ Pod |
+-----+Ainsi, pour exposer votre application au monde extérieur, vous créez généralement une interface interne. Service en utilisant oc create service et ensuite créer un Route en utilisant oc expose :
# Create a new ClusterIP service named myservice
oc create service clusterip myservice --tcp=8080:8080
oc expose service myservice
eamazaj
Points
64
Red Hat avait besoin d'une solution automatisée de proxy inverse pour les conteneurs fonctionnant sur OpenShift bien avant que Kubernetes ne propose Ingress. Ainsi, dans OpenShift, nous avons maintenant des objets Route qui font presque le même travail qu'Ingress dans Kubernetes. La principale différence est que les routes sont mises en œuvre par le bon vieux HAproxy qui peut être remplacé par une solution commerciale basée sur F5 BIG-IP. Sur Kubernetes, cependant, vous avez beaucoup plus de choix, car Ingress est une interface mise en œuvre par de multiples serveurs, à commencer par les plus populaires : nginx, traefik, AWS ELB/ALB, GCE, Kong et autres, y compris HAproxy.
Alors, quel est le meilleur, me direz-vous ? Personnellement, je pense que HAproxy dans OpenShift est beaucoup plus mature, bien qu'il n'ait pas autant de fonctionnalités que certaines implémentations d'Ingress. Sur Kubernetes cependant, vous pouvez utiliser différentes améliorations - ma préférée est une intégration avec cert-manager qui vous permet d'automatiser la gestion des certificats SSL. Plus d'actions manuelles pour l'émission et le renouvellement des certificats et, en plus, vous pouvez utiliser gratuitement une autorité de certification de confiance grâce à l'intégration avec Letsencrypt !
Il est intéressant de noter qu'à partir d'OpenShift 3.10, les objets Kubernetes Ingress sont reconnus par OpenShift et sont traduits/implémentés par un routeur. C'est un grand pas vers la compatibilité avec la configuration préparée pour Kubernetes qui peut maintenant être lancée sur OpenShift sans aucune modification.
