ClusterIP: Dienste sind über Pods / Dienste im Cluster erreichbar.
Wenn ich einen Dienst namens myservice im Standard-Namespace vom Typ ClusterIP erstelle, wird die folgende vorhersehbare statische DNS-Adresse für den Dienst erstellt:
myservice.default.svc.cluster.local (oder nur myservice.default oder nach Pods im Standard-Namespace funktioniert nur "myservice")
Und dieser DNS-Name kann nur von Pods und Diensten innerhalb des Clusters aufgelöst werden.
NodePort: Dienste sind für Clients im selben LAN / für dieselben Clients erreichbar, die die K8s-Hostknoten (und Pods / Dienste im Cluster) anpingen können
Ich kann diesen Dienst nicht erreichen.) Wenn ich einen Dienst namens mynodeportservice im Namespace mynamespace vom Typ NodePort in einem 3-Knoten-Kubernetes-Cluster erstelle. Anschließend wird ein Dienst vom Typ ClusterIP erstellt, der von Clients im Cluster unter der folgenden vorhersehbaren statischen DNS-Adresse erreicht werden kann:
mynodeportservice.mynamespace.svc.cluster.local (oder einfach mynodeportservice.mynamespace)
Für jeden Port, den mynodeportservice auf einem Nodeport im Bereich von 30000 - 32767 abhört, wird zufällig ausgewählt. Damit externe Clients außerhalb des Clusters den innerhalb des Clusters vorhandenen ClusterIP-Dienst erreichen können. Nehmen wir an, unsere 3 K8-Hostknoten haben IPs 10.10.10.1, 10.10.10.2, 10.10.10.3, der Kubernetes-Dienst überwacht Port 80 und der zufällig ausgewählte Knotenport war 31852.
Ein Client, der außerhalb des Clusters existiert, konnte ihn besuchen 10.10.10.1:31852, 10.10.10.2:31852 oder 10.10.10.3:31852 (da NodePort von jedem Kubernetes-Hostknoten abgehört wird) Kubeproxy leitet die Anforderung an den Port 80 von mynodeportservice weiter.
LoadBalancer: Dienste sind für alle erreichbar, die mit dem Internet verbunden sind * (Gemeinsame Architektur ist, dass L4 LB im Internet öffentlich zugänglich ist, indem es in eine DMZ gestellt oder sowohl eine private als auch eine öffentliche IP-Adresse zugewiesen wird und sich k8s-Hostknoten in einem privaten Subnetz befinden)
( Hinweis: Dies ist der einzige Diensttyp, der in 100% der Kubernetes-Implementierungen nicht funktioniert, wie z. B. Bare-Metal-Kubernetes. Er funktioniert, wenn Kubernetes Cloud-Provider-Integrationen hat.)
Wenn Sie mylbservice erstellen, wird eine L4 LB-VM erzeugt (ein Cluster-IP-Dienst und ein NodePort-Dienst werden implizit ebenfalls erzeugt). Diesmal ist unser NodePort 30222. Die Idee ist, dass der L4 LB eine öffentliche IP von 1.2.3.4 hat und den Lastausgleich und den Datenverkehr an die 3 K8s-Hostknoten mit privaten IP-Adressen weiterleitet. (10.10.10.1:30222, 10.10.10.2:30222, 10.10.10.3:30222) und dann leitet Kube Proxy es an den Dienst vom Typ ClusterIP weiter, der im Cluster vorhanden ist.
Sie haben auch gefragt: Verwendet der NodePort-Diensttyp noch ClusterIP? Ja *
Oder ist die NodeIP tatsächlich die IP, die beim Ausführen von kubectl get node gefunden wurde? Auch Ja *
Zeichnen wir eine Parallele zwischen den Grundlagen:
Ein Container befindet sich in einem Pod. Ein Pod befindet sich in einem Replikat. Ein Replikatsatz befindet sich in einer Bereitstellung.
Ähnlich:
Ein ClusterIP-Dienst ist Teil eines NodePort-Dienstes. Ein NodePort-Dienst ist Teil eines Load Balancer-Dienstes.
In dem von Ihnen gezeigten Diagramm wäre der Client ein Pod innerhalb des Clusters.
externalIPssich die Gleichung hier ändert? Insbesondere ist es möglich, einem Dienst vom Typ einexternalIPsArray zuzuweisenClusterIP, und dann wird der Dienst auch über die externe IP zugänglich. Wann würden Sie dies einem NodePort vorziehen?