Quelle est la différence entre les types de service ClusterIP, NodePort et LoadBalancer dans Kubernetes?

Question

1 - je suis en train de lire la documentation et je suis un peu confus avec le libellé. Il dit:

ClusterIP: Expose le service de cluster-IP interne. Le choix de cette valeur rend le service est accessible à partir de l'intérieur du cluster. C'est la valeur par défaut ServiceType

NodePort: Expose le service sur chaque Nœud IP à un port statique (le NodePort). Un ClusterIP service, à qui l'NodePort service de la route, est automatiquement créé. Vous serez en mesure de communiquer avec le NodePort service, à partir de l'extérieur du cluster, en demandant <NodeIP>:<NodePort>.

LoadBalancer: Expose le service extérieur à l'aide d'un fournisseur de cloud de l'équilibreur de charge. NodePort et ClusterIP services, à qui la charge externe équilibrage de la route, sont créés automatiquement.

Le NodePort type de service toujours utiliser l' ClusterIP , mais seulement à un port différent, qui est ouvert aux clients de l'extérieur? Dans ce cas, est - <NodeIP>:<NodePort> le même que <ClusterIP>:<NodePort>?

Ou est l' NodeIP en fait l'IP trouvée lorsque vous exécutez kubectl get nodes et non pas l'adresse IP virtuelle utilisée pour la ClusterIP type de service?

2 - Aussi dans le diagramme à partir du lien ci-dessous:

http://kubernetes.io/images/docs/services-iptables-overview.svg

Est-il une raison particulière de l' Client est à l'intérieur de l' Node? Je suppose qu'il aurait besoin d'être à l'intérieur d'un Clusterdans le cas d'un ClusterIP type de service.

Si le même schéma a été élaboré pour NodePort, serait-il valable pour attirer le client complètement à l'extérieur à la fois l' Node etCluster ou suis-je complètement à côté du sujet?

Answer 1

Un ClusterIP expose les éléments suivants:

• spec.clusterIp:spec.ports[*].port

Vous ne pouvez accéder à ce service, tandis que l'intérieur du cluster. Il est accessible à partir de son spec.clusterIp port. Si un spec.ports[*].targetPort est défini, il prendra le chemin du port à l'targetPort. Le CLUSTER-IP vous obtenez lorsque vous appelez kubectl get services est l'adresse IP affectée à ce service au sein du cluster à l'interne.

Un NodePort expose les éléments suivants:

• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Si vous accédez à ce service sur un nodePort à partir du nœud IP externe, il acheminera la demande d' spec.clusterIp:spec.ports[*].port, ce qui permettra d'itinéraire à votre spec.ports[*].targetPort, si elle est définie. Ce service peut également être accessibles de la même manière que ClusterIP.

Votre NodeIPs sont les adresses IP externes de nœuds. Vous ne pouvez pas accéder à votre service de <ClusterIP>:spec.ports[*].nodePort.

Un LoadBalancer expose les éléments suivants:

• spec.loadBalancerIp:spec.ports[*].port
• <NodeIP>:spec.ports[*].nodePort
• spec.clusterIp:spec.ports[*].port

Vous pouvez accéder à ce service à partir de votre programme d'équilibrage de charge de l'adresse IP, qui achemine votre demande à un nodePort, qui achemine la demande au clusterIP port. Vous pouvez accéder à ce service, comme vous le feriez un NodePort ou un ClusterIP service.

Answer 2

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 de 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.
 

Answer 3

ClusterIP: les Services sont accessibles par des cosses et des services dans le Cluster
Si je fais un service appelé myservice dans l'espace de noms par défaut de type: ClusterIP alors la suivante prévisible adresse DNS statique pour le service va être créé:

myservice.par défaut.svc.cluster.local (ou juste myservice.par défaut, ou par des cosses dans l'espace de noms par défaut juste "myservice" de travail)

Et que nom DNS ne peuvent être résolus que par des cosses et des services à l'intérieur du cluster.

NodePort: les Services sont accessibles par les clients sur le même LAN/clients qui peuvent ping la K8s Hôte Nœuds (et les gousses et des services dans le cluster) (Note pour la sécurité de votre k8s hôte les nœuds doivent être sur un sous-réseau privé, ainsi les clients sur internet ne sera pas en mesure d'atteindre ce service)
Si je fais un service appelé mynodeportservice dans l'espace de noms mynamespace de type: NodePort sur un Nœud 3 Kubernetes Cluster. Ensuite, un Service de type: ClusterIP sera créé et il sera accessible par les clients à l'intérieur de la grappe à la suite prévisible adresse DNS statique:

mynodeportservice.mynamespace.svc.cluster.local (ou juste mynodeportservice.mynamespace)

Pour chaque port mynodeportservice écoute sur un nodeport dans la gamme de 30000 - 32767 sera choisi au hasard. De sorte que les clients Externes qui sont en dehors du cluster peut frapper que ClusterIP service qui existe à l'intérieur du cluster. Permet de dire que nos 3 K8s hôte nœuds ont des adresses ip 10.10.10.1, 10.10.10.2, 10.10.10.3, le Kubernetes service est à l'écoute sur le port 80, et le Nodeport choisi au hasard, a été 31852.

Un client qui existe à l'extérieur de la grappe pu visiter 10.10.10.1:31852, 10.10.10.2:31852, ou 10.10.10.3:31852 (comme NodePort est écouté par tous les Kubernetes Nœud d'Hôte) Kubeproxy transmettra la demande à mynodeportservice sur le port 80.

LoadBalancer: les Services sont accessibles par tout le monde connecté à internet* (architecture Commune est L4 LB est accessible au public sur internet en le mettant dans une DMZ ou de le donner à la fois privée et publique, propriété intellectuelle et k8s hôte noeuds sont sur un sous-réseau privé)
(Note: C'est le seul type de service qui ne fonctionne pas dans 100% de Kubernetes implémentations, comme le métal nu Kubernetes, ça marche quand Kubernetes a cloud fournisseur de intégrations.)

Si vous faites mylbservice, puis un L4 LB VM seront pondus (un cluster de service IP, et un NodePort Service sera implicitement donné naissance). Cette fois, notre NodePort est 30222. l'idée est que le L4 LB aura une IP publique de 1.2.3.4 et il se charge de l'équilibre et de transférer le trafic de la 3 K8s hôte nœuds qui ont des adresses IP privées. (10.10.10.1:30222, 10.10.10.2:30222, 10.10.10.3:30222) et puis Kube Proxy transmettra au service de type ClusterIP qui existe à l'intérieur du cluster.

---

Vous m'avez également demandé: Le NodePort type de service toujours utiliser le ClusterIP? Oui*
Ou est le NodeIP en fait l'IP trouvée lorsque vous exécutez kubectl obtenir des nœuds? Aussi Oui*

Permet de tracer un parallèle entre les principes Fondamentaux:
Un conteneur est à l'intérieur d'un conteneur. un pod est à l'intérieur d'un jeu de réplication. un jeu de réplication est à l'intérieur d'un déploiement.
Eh bien de la même façon:
Un ClusterIP Service fait partie d'un NodePort Service. Un NodePort Service fait Partie d'un Service d'Équilibrage de Charge.

---

Dans ce diagramme vous a montré, le Client serait une dosette à l'intérieur du cluster.

Answer 4

Supposons que vous avez créé une machine virtuelle Ubuntu sur votre machine locale. Son adresse IP est 192.168.1.104.

Vous vous connectez à une machine virtuelle, et installé Kubernetes. Ensuite, vous avez créé un pod, où nginx image en cours d'exécution sur elle.

1 - Si vous souhaitez accéder à ce nginx pod à l'intérieur de votre machine virtuelle, vous allez créer un ClusterIP lié à celui pod par exemple:

$ kubectl expose deployment nginxapp --name=nginxclusterip --port=80 --target-port=8080

Ensuite, sur votre navigateur, vous pouvez taper l'adresse ip de nginxclusterip avec le port 80, comme:

http://10.152.183.2:80

2 - Si vous souhaitez accéder à ce nginx pod à 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:

http://192.168.1.104:31865/

Dans mon tableau de bord, ils apparaissent comme:

Le diagramme ci-dessous montre la relation fondamentale.

Answer 5

1. clusterIP : IP accessible à l'intérieur de cluster (à travers les nœuds à l'intérieur d cluster).

nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.

pod3 pouvez parler à pod1 par l'intermédiaire de leur clusterIP réseau.

2. nodeport : faire gousses accessible depuis l'extérieur du cluster via nodeIP:nodeport, il va créer/maintenir clusterIP ci-dessus comme sa clusterIP réseau.

nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX

vous pouvez accéder à un service sur pod1 soit par l'intermédiaire de nodeIPA:nodeportX OU nodeIPB:nodeportX. De toute façon va travailler parce que kube-proxy (qui est installé dans chaque nœud) recevra votre demande et de les distribuer [redirection(iptables terme)] sur les nœuds à l'aide de clusterIP réseau.

3. Équilibreur de charge

fondamentalement, il suffit de mettre LB à l'avant, de sorte que le trafic entrant est distribué à nodeIPA:nodeportX et nodeIPB:nodeportX puis continuer avec le processus de flux numéro 2 ci-dessus.