Quelle est la différence entre les types de service ClusterIP, NodePort et LoadBalancer dans Kubernetes?
1 - Je lis la documentation et je suis un peu confus avec le libellé. Ça dit:
ClusterIP: expose le service sur une adresse IP interne à la grappe. En choisissant cette valeur, le service n'est accessible que depuis le cluster. C'est le ServiceType par défaut
NodePort: expose le service sur l’adresse IP de chaque nœud sur un port statique (NodePort). Un service ClusterIP, auquel le service NodePort acheminera, est automatiquement créé. Vous pourrez contacter le service NodePort, en dehors du cluster, en demandant
<NodeIP>:<NodePort>.LoadBalancer: expose le service en externe à l'aide de l'équilibreur de charge d'un fournisseur de cloud. Les services NodePort et ClusterIP, auxquels l’équilibreur de charge externe acheminera, sont automatiquement créés.
Le type de service NodePort utilise-t-il toujours la ClusterIP mais uniquement sur un port différent, ouvert aux clients externes? Donc, dans ce cas, <NodeIP>:<NodePort> est-il identique à <ClusterIP>:<NodePort>?
Ou est-ce que NodeIP est en fait l'adresse IP trouvée lors de l'exécution de kubectl get nodes et non l'adresse IP virtuelle utilisée pour le type de service ClusterIP?
2 - Également dans le diagramme à partir du lien ci-dessous:
http://kubernetes.io/images/docs/services-iptables-overview.svg
Y a-t-il une raison particulière pour laquelle la Client est à l'intérieur de la Node? J'ai supposé que cela aurait besoin d'être à l'intérieur d'une Clusterdans le cas d'un type de service ClusterIP.
Si le même diagramme a été dessiné pour NodePort, serait-il valide de dessiner le client complètement en dehors de Node et Cluster ou suis-je complètement en train de rater le point?
Un ClusterIP expose les éléments suivants:
spec.clusterIp:spec.ports[*].port
Vous ne pouvez accéder à ce service que dans le cluster. Il est accessible depuis son port spec.clusterIp. Si un spec.ports[*].targetPort est défini, il routera du port au targetPort. L'IP CLUSTER que vous obtenez lorsque vous appelez kubectl get services est l'adresse IP attribuée à ce service au sein du cluster en interne.
Un NodePort expose les éléments suivants:
<NodeIP>:spec.ports[*].nodePortspec.clusterIp:spec.ports[*].port
Si vous accédez à ce service sur un nodePort à partir de l'IP externe du nœud, la requête sera routée vers spec.clusterIp:spec.ports[*].port, qui la transmettra ensuite à votre spec.ports[*].targetPort, s'il est défini. Ce service est également accessible de la même manière que ClusterIP.
Vos NodeIP sont les adresses IP externes des nœuds. Vous ne pouvez pas accéder à votre service à partir de <ClusterIP>:spec.ports[*].nodePort.
Un LoadBalancer expose les éléments suivants:
spec.loadBalancerIp:spec.ports[*].port<NodeIP>:spec.ports[*].nodePortspec.clusterIp:spec.ports[*].port
Vous pouvez accéder à ce service à partir de l'adresse IP de votre équilibreur de charge, qui achemine votre demande vers un nodePort, qui à son tour achemine la demande vers le port clusterIP. Vous pouvez également accéder à ce service comme vous le feriez avec un service NodePort ou ClusterIP.
Pour clarifier pour quiconque cherche quelle est la différence entre le 3 sur un niveau plus simple. Vous pouvez exposer votre service avec un minimum ClusterIp (dans k8s clusteR) ou une exposition plus importante avec NodePort (dans un cluster externe au cluster k8s) ou LoadBalancer (monde externe ou tout ce que vous avez défini dans votre LB).
ClusterIp exposure < NodePort exposure < LoadBalancer exposure
ClusterIp -> Expose service through **k8s cluster** with ip/name:port
NodePort -> Expose service through **Internal network VM's** also external to k8s ip/name:port
LoadBalancer -> Expose service through **External world** or whatever you defined in your LB.
ClusterIP: les services sont accessibles par les pods/services du cluster
Si je crée un service appelé myservice dans l'espace de noms par défaut de type: ClusterIP, l'adresse DNS statique prévisible suivante pour le service sera créée:
myservice.default.svc.cluster.local (ou simplement myservice.default, ou par des pods dans l'espace de noms par défaut, "myservice" fonctionnera)
Et ce nom DNS ne peut être résolu que par des pods et des services au sein du cluster.
NodePort: les services sont accessibles aux clients du même réseau local/clients pouvant envoyer une requête ping aux nœuds d’hôte K8s (et aux pods/services du cluster) (remarque: pour la sécurité, les nœuds d’hôte k8s doivent se trouver sur un sous-réseau privé. Internet ne pourra pas accéder à ce service)
Si je crée un service appelé mynodeportservice dans l’espace de nommage mynamespace de type: NodePort sur un cluster Kubernetes à 3 nœuds. Ensuite, un service de type: ClusterIP sera créé et il sera accessible par les clients du cluster à l'adresse DNS statique prévisible suivante:
mynodeportservice.mynamespace.svc.cluster.local (ou simplement mynodeportservice.mynamespace)
Pour chaque port que mynodeportservice écoute, un port de nœud compris entre 30000 et 32767 sera choisi de manière aléatoire. Pour que les clients externes situés en dehors du cluster puissent accéder au service ClusterIP existant à l'intérieur du cluster ...__, disons que nos nœuds hôtes 3 K8 ont des adresses IP 10.10.10.1, 10.10.10.2, 10.10.10.3, le service Kubernetes est à l'écoute sur le port 80, et Nodeport choisi au hasard était de 31852.
Un client qui se trouve en dehors du cluster peut visiter 10.10.10.1:31852, 10.10.10.2:31852 ou 10.10.10.3:31852 (chaque nœud hôte de Kubernetes écoutant NodePort), Kubeproxy transmettra la demande au port 80 de mynodeportservice.
LoadBalancer: les services sont accessibles à toutes les personnes connectées à Internet * (l'architecture courante est L4. LB est accessible au public sur Internet en le plaçant dans une DMZ ou en lui donnant à la fois une adresse IP privée et publique et des nœuds hôtes k8. sur un sous-réseau privé)
(Remarque: il s’agit du seul type de service qui ne fonctionne pas dans 100% des implémentations de Kubernetes, comme Kubernetes sans système d'exploitation, il fonctionne lorsque Kubernetes dispose d'intégrateurs de fournisseur de cloud.)
Si vous créez mylbservice, un L4 LB VM sera créé (un service IP de cluster et un service NodePort seront également créés implicitement). Cette fois, notre NodePort porte le numéro 30222. L’idée est que le L4 LB aura une adresse IP publique de 1.2.3.4, qu’il équilibrera la charge et acheminera le trafic vers les nœuds d’hôte 3 K8s dotés d’adresses IP privées. (10.10.10.1:30222, 10.10.10.2:30222, 10.10.10.3:30222), puis Kube Proxy le transmettra au service de type ClusterIP existant dans le cluster.
Vous avez également demandé: Le type de service NodePort utilise-t-il toujours le ClusterIP? Oui*
Ou le NodeIP est-il réellement l'adresse IP trouvée lorsque vous exécutez kubectl get noeuds? Aussi oui *
Permet de tracer un parallèle entre les fondamentaux:
Un conteneur est à l'intérieur d'un pod. un pod est à l'intérieur d'un réplicaset. un réplicaset est à l'intérieur d'un déploiement.
Bien pareillement:
Un service ClusterIP fait partie d’un service NodePort. Un service NodePort fait partie d'un service Load Balancer.
Dans ce diagramme que vous avez montré, le client serait un pod à l'intérieur du cluster.
Supposons que vous ayez créé Ubuntu VM sur votre ordinateur local. Son adresse IP est 192.168.1.104.
Vous vous connectez à VM et avez installé Kubernetes. Vous avez ensuite créé un pod sur lequel l’image nginx s’exécute.
1- Si vous souhaitez accéder à ce pod nginx dans votre machine virtuelle, vous allez créer un ClusterIP lié à ce pod, par exemple:
$ kubectl expose deployment nginxapp --name=nginxclusterip --port=80 --target-port=8080
Ensuite, sur votre navigateur, vous pouvez saisir l'adresse IP de nginxclusterip avec le port 80, par exemple:
2- Si vous souhaitez accéder à ce pod nginx à partir de votre ordinateur hôte, vous devez exposer votre déploiement avec NodePort. Par exemple:
$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort
Maintenant, à partir de votre ordinateur hôte, vous pouvez accéder à nginx comme:
Dans mon tableau de bord, ils apparaissent comme:
Ci-dessous un diagramme montre la relation de base.
- clusterIP: IP accessible à l'intérieur du cluster (sur tous les noeuds du cluster d).
nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.
pod3 peut parler à pod1 via son réseau clusterIP.
- nodeport: pour rendre les pods accessibles de l'extérieur du cluster via nodeIP: nodeport, il créera/conservera clusterIP ci-dessus en tant que réseau clusterIP.
nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX
vous pouvez accéder au service sur pod1 via nodeIPA: nodeportX OR nodeIPB: nodeportX. Dans tous les cas, cela fonctionnera car kube-proxy (installé sur chaque nœud) recevra votre demande et la distribuera [redirigez-le (terme iptables)] sur tous les nœuds via le réseau clusterIP.
- Équilibreur de charge
en gros, il suffit de placer LB devant afin que le trafic entrant soit distribué à nodeIPA: nodeportX et nodeIPB: nodeportX, puis continuez avec le flux de processus numéro 2 ci-dessus.