wake-up-neo.net

Was ist der Unterschied zwischen den Service-Typen ClusterIP, NodePort und LoadBalancer in Kubernetes?

1 - Ich lese die Dokumentation und bin etwas verwirrt mit dem Wortlaut. Es sagt:

ClusterIP: Macht den Dienst auf einer clusterinternen IP verfügbar. Wenn Sie diesen Wert auswählen, ist der Dienst nur innerhalb des Clusters erreichbar. Dies ist der Standard-ServiceType

NodePort: Macht den Dienst auf der IP eines jeden Knotens an einem statischen Port (NodePort) verfügbar. Ein ClusterIP-Dienst, zu dem der NodePort-Dienst geroutet wird, wird automatisch erstellt. Sie können den NodePort-Dienst von außerhalb des Clusters anrufen, indem Sie <NodeIP>:<NodePort> anfordern.

LoadBalancer: Macht den Dienst mithilfe des Lastausgleichs eines Cloud-Providers extern verfügbar. Die NodePort- und ClusterIP-Dienste, zu denen der externe Load Balancer routen wird, werden automatisch erstellt.

Verwendet der NodePort-Diensttyp weiterhin ClusterIP, jedoch nur an einem anderen Port, der für externe Clients geöffnet ist? In diesem Fall ist also <NodeIP>:<NodePort> dasselbe wie <ClusterIP>:<NodePort>?

Oder ist NodeIP tatsächlich die IP, wenn Sie kubectl get nodes ausführen, und nicht die virtuelle IP-Adresse, die für den ClusterIP-Diensttyp verwendet wird?

2 - Auch im Diagramm aus dem Link unten:

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

Gibt es einen bestimmten Grund, warum Client innerhalb von Node ist? Ich nahm an, dass es in einem Cluster im Fall eines ClusterIP-Diensttyps sein muss. 

Wenn dasselbe Diagramm für NodePort gezeichnet wurde, wäre es dann gültig, den Client vollständig außerhalb von Node undCluster zu ziehen, oder fehlt mir der Punkt vollständig?

92
AmazingBergkamp

Ein ClusterIP macht Folgendes verfügbar:

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

Sie können nur innerhalb des Clusters auf diesen Dienst zugreifen. Es ist über seinen spec.clusterIp-Port erreichbar. Wenn ein spec.ports[*].targetPort eingestellt ist, wird er vom Port zum targetPort geleitet. Die CLUSTER-IP, die Sie erhalten, wenn Sie kubectl get services aufrufen, ist die IP, die diesem Dienst innerhalb des Clusters intern zugewiesen ist. 

Ein NodePort macht Folgendes verfügbar:

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

Wenn Sie auf diesen Dienst in einem nodePort von der externen IP-Adresse des Knotens aus zugreifen, wird die Anforderung an spec.clusterIp:spec.ports[*].port weitergeleitet, der sie ggf. an Ihren spec.ports[*].targetPort weiterleitet. Auf diesen Dienst kann auch wie auf ClusterIP zugegriffen werden.

Ihre NodeIPs sind die externen IP-Adressen der Knoten. Sie können nicht über <ClusterIP>:spec.ports[*].nodePort auf Ihren Dienst zugreifen.

Ein LoadBalancer macht Folgendes verfügbar:

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

Sie können auf diesen Dienst über die IP-Adresse Ihres Load Balancers zugreifen, die Ihre Anfrage an einen nodePort weiterleitet, der die Anfrage wiederum an den clusterIP-Port weiterleitet. Sie können auf diesen Dienst genauso wie auf einen NodePort- oder einen ClusterIP-Dienst zugreifen.

98
kellanburket

Um zu klären, wer sucht, was ist der Unterschied zwischen den 3 auf einer einfacheren Ebene. Sie können Ihren Service mit minimalem ClusterIp (innerhalb von k8s clusteR) oder mit NodePort (innerhalb eines Clusters außerhalb des k8s-Clusters) oder LoadBalancer (externe Welt oder was Sie in Ihrer LB definiert haben) verfügbar machen.

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.
47
Tomer Ben David

ClusterIP: Dienste sind über Pods/Dienste im Cluster erreichbar  
Wenn ich einen Dienst namens myservice im Standardnamespace vom Typ: ClusterIP erstelle, wird die folgende vorhersagbare statische DNS-Adresse für den Dienst erstellt: 

myservice.default.svc.cluster.local (oder einfach nur myservice.default oder von pods im Standard-Namespace, nur "myservice" funktioniert)

Dieser DNS-Name kann nur von Pods und Services innerhalb des Clusters aufgelöst werden.

NodePort: Dienste sind für Clients im selben LAN/Clients erreichbar, die ein Ping an die K8s-Hostknoten (und Pods/Services im Cluster) senden können. (Hinweis: Aus Sicherheitsgründen sollten sich die k8s-Hostknoten in einem privaten Subnetz befinden, also Clients im Internet kann diesen Dienst nicht erreichen)  
Wenn ich einen Dienst namens mynodeportservice im Namespace mynamespace vom Typ "NodePort" in einem Kubernetes-Cluster mit 3 Knoten benutze. Dann wird ein Dienst vom Typ: ClusterIP erstellt, der für Clients innerhalb des Clusters unter der folgenden vorhersehbaren statischen DNS-Adresse erreichbar ist:

mynodeportservice.mynamespace.svc.cluster.local (oder einfach nur mynodeportservice.mynamespace)

Für jeden Port, den der mynodeportservice auf einen Nodeport im Bereich von 30000 - 32767 wartet, wird er zufällig ausgewählt. Damit externe Clients, die sich außerhalb des Clusters befinden, den ClusterIP-Dienst erreichen können, der sich innerhalb des Clusters befindet. Wir sagen, dass unsere 3 K8s-Hostknoten über die IP-Adressen 10.10.10.1, 10.10.10.2, 10.10.10.3 verfügen, der Kubernetes-Dienst wartet auf Port 80, und der zufällig ausgewählte Nodeport war 31852.

Ein Client, der sich außerhalb des Clusters befindet, kann 10.10.10.1:31852, 10.10.10.2:31852 oder 10.10.10.3:31852 besuchen (da NodePort von jedem Kubernetes-Host-Knoten überwacht wird). Kubeproxy leitet die Anforderung an den Port 80 von mynodeportservice weiter.

LoadBalancer: Dienste sind für jeden erreichbar, der mit dem Internet verbunden ist * (Übliche Architektur ist L4 LB ist im Internet öffentlich zugänglich, indem sie in eine DMZ gestellt wird oder es sowohl eine private als auch eine öffentliche IP- und k8s-Host-Node gibt in einem privaten Subnetz)  
(Hinweis: Dies ist der einzige Servicetyp, der in 100% der Kubernetes-Implementierungen nicht funktioniert, wie Bare-Metal-Kubernetes. Er funktioniert, wenn Kubernetes Cloud-Provider-Integrationen hat.) 

Wenn Sie mylbservice ausführen, wird ein L4 LB VM erstellt (ein Cluster-IP-Dienst und ein NodePort-Dienst wird implizit ebenfalls erstellt). Diesmal ist unser NodePort 30222. Die Idee ist, dass die L4 LB eine öffentliche IP-Adresse von 1.2.3.4 besitzt und den Datenverkehr auf die 3 K8s-Host-Knoten mit privaten IP-Adressen verteilt. (10.10.10.1:30222, 10.10.10.230222, 10.10.10.3:30222) und dann leitet Kube Proxy es an den Dienst des Typs ClusterIP weiter, der im Cluster vorhanden ist.


Sie haben auch gefragt: Verwendet der NodePort-Diensttyp immer noch die ClusterIP? Ja* 
Oder ist der NodeIP tatsächlich die IP, wenn Sie kubectl get-Nodes ausführen? Auch ja* 

Lasst uns eine Parallele zwischen den Grundlagen ziehen: 
Ein Container befindet sich in einer Pod. Eine Schote befindet sich innerhalb eines Replikats. Ein Replikatset befindet sich in einer Bereitstellung. 
Nun, ähnlich:
Ein ClusterIP-Dienst ist Teil eines NodePort-Dienstes. Ein NodePort-Service ist Teil eines Load Balancer-Services. 


In diesem Diagramm, das Sie gezeigt haben, wäre der Client ein Pod innerhalb des Clusters. 

9
neokyle

Nehmen wir an, Sie haben auf Ihrem lokalen Rechner ein Ubuntu VM erstellt. Ihre IP-Adresse lautet 192.168.1.104.

Sie loggen sich in VM ein und installierten Kubernetes. Dann erstellten Sie einen Pod, auf dem ein Nginx-Image ausgeführt wird. 

1- Wenn Sie auf diesen Nginx-Pod in Ihrer VM zugreifen möchten, erstellen Sie beispielsweise ein ClusterIP, das an diesen Pod gebunden ist:

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

Dann können Sie in Ihrem Browser die IP-Adresse von nginxclusterip mit Port 80 eingeben:

http://10.152.183.2:80

2- Wenn Sie von Ihrem Host-Computer aus auf diesen Nginx-Pod zugreifen möchten, müssen Sie Ihre Bereitstellung mit NodePort verfügbar machen. Zum Beispiel:

$ kubectl expose deployment nginxapp --name=nginxnodeport --port=80 --target-port=8080 --type=NodePort

Jetzt können Sie von Ihrem Host-Computer aus auf nginx zugreifen:

http://192.168.1.104:31865/

In meinem Dashboard erscheinen sie als:

 enter image description here

Das folgende Diagramm zeigt die grundlegende Beziehung.

 enter image description here

5
Teoman shipahi
  1. clusterIP: Innerhalb des Clusters zugreifbare IP (zwischen Knoten innerhalb eines Clusters).
nodeA : pod1 => clusterIP1, pod2 => clusterIP2
nodeB : pod3 => clusterIP3.

pod3 kann über ihr clusterIP-Netzwerk mit pod1 kommunizieren.

  1. nodeport: Um Pods von außerhalb des Clusters über nodeIP: nodeport zugänglich zu machen, wird clusterIP oben als ClusterIP-Netzwerk erstellt/beibehalten.
nodeA => nodeIPA : nodeportX
nodeB => nodeIPB : nodeportX

sie können entweder über nodeIPA auf den Dienst auf pod1 zugreifen: nodeportX OR nodeIPB: nodeportX. Beide Möglichkeiten funktionieren, da kube-proxy (der in jedem Knoten installiert ist) Ihre Anforderung empfängt und sie über ein ClusterIP-Netzwerk auf andere Knoten verteilt.

  1. Lastenausgleicher

im Grunde nur LB in den Vordergrund stellen, so dass der eingehende Verkehr auf nodeIPA: nodeportX und nodeIPB: nodeportX verteilt wird, und fahren Sie dann mit der Prozessablaufnummer 2 oben fort.

0
alfred