来源:

Kubernetes在行动 Kubernetes。io服务 Kubernetes Services简单直观地解释了

ClusterIP:集群中的pod /服务可达 如果我在默认的命名空间类型:ClusterIP中创建一个名为myservice的服务，那么将为该服务创建以下可预测的静态DNS地址:

myservice.default.svc.cluster.local(或者只使用myservice.default，或者在默认命名空间中使用pod，只使用“myservice”即可)

这个DNS名称只能由集群内的pod和服务解析。

NodePort: Services are reachable by clients on the same LAN/clients who can ping the K8s Host Nodes (and pods/services in the cluster) (Note for security your k8s host nodes should be on a private subnet, thus clients on the internet won't be able to reach this service) If I make a service called mynodeportservice in the mynamespace namespace of type: NodePort on a 3 Node Kubernetes Cluster. Then a Service of type: ClusterIP will be created and it'll be reachable by clients inside the cluster at the following predictable static DNS address:

local(或者只是mynodeportservice.mynamespace)

For each port that mynodeportservice listens on a nodeport in the range of 30000 - 32767 will be randomly chosen. So that External clients that are outside the cluster can hit that ClusterIP service that exists inside the cluster. Lets say that our 3 K8s host nodes have IPs 10.10.10.1, 10.10.10.2, 10.10.10.3, the Kubernetes service is listening on port 80, and the Nodeport picked at random was 31852. A client that exists outside of the cluster could visit 10.10.10.1:31852, 10.10.10.2:31852, or 10.10.10.3:31852 (as NodePort is listened for by every Kubernetes Host Node) Kubeproxy will forward the request to mynodeportservice's port 80.

LoadBalancer: Services are reachable by everyone connected to the internet* (Common architecture is L4 LB is publicly accessible on the internet by putting it in a DMZ or giving it both a private and public IP and k8s host nodes are on a private subnet) (Note: This is the only service type that doesn't work in 100% of Kubernetes implementations, like bare metal Kubernetes, it works when Kubernetes has cloud provider integrations.) If you make mylbservice, then a L4 LB VM will be spawned (a cluster IP service, and a NodePort Service will be implicitly spawned as well). This time our NodePort is 30222. the idea is that the L4 LB will have a public IP of 1.2.3.4 and it will load balance and forward traffic to the 3 K8s host nodes that have private IP addresses. (10.10.10.1:30222, 10.10.10.2:30222, 10.10.10.3:30222) and then Kube Proxy will forward it to the service of type ClusterIP that exists inside the cluster.

你还问: NodePort服务类型是否仍然使用ClusterIP?是的* 或者NodeIP实际上是运行kubectl get nodes时找到的IP ?还没错* 让我们在基本原理之间画一个平行图: 一个容器在一个豆荚里面。一个豆荚在一个复制集里。复制集位于部署内部。 类似的: ClusterIP服务是NodePort服务的一部分。NodePort服务是负载均衡器服务的一部分。

在您展示的图表中，客户端将是集群中的一个pod。

假设你在本地机器上创建了一个Ubuntu虚拟机。IP地址是192.168.1.104。

登录VM，安装Kubernetes。然后你创建了一个运行nginx图像的pod。

1-如果你想在你的虚拟机中访问这个nginx pod，你将创建一个绑定到该pod的ClusterIP，例如:

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

然后在浏览器上输入nginxclusterip的ip地址，端口为80，如下所示:

http://10.152.183.2:80

2-如果你想从你的主机上访问这个nginx pod，你需要用NodePort公开你的部署。例如:

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

现在你可以从你的主机上访问nginx，像这样:

http://192.168.1.104:31865/

在我的仪表板上，它们显示为:

下图显示了基本关系。

为了在更简单的层面上为那些正在寻找这三者之间的区别的人澄清。您可以使用最小的ClusterIp(在k8s集群内)公开您的服务，也可以使用NodePort(在k8s集群外部的集群内)或LoadBalancer(外部世界或您在LB中定义的任何东西)公开您的服务。

ClusterIp暴露< NodePort暴露< LoadBalancer暴露

ClusterIp 通过ip/name:port的k8s集群公开服务 NodePort 通过内部网络虚拟机的外部k8s ip/name:port公开服务 loadbalance 通过外部世界或您在LB中定义的任何方式公开服务。

来源:

Kubernetes在行动 Kubernetes。io服务 Kubernetes Services简单直观地解释了

实际的理解。

我已经为NodePort和ClusterIP创建了2个服务

如果我想访问集群内的服务(从主节点或任何工作节点)，那么两者都是可访问的。

现在，如果我想从集群外部访问服务，那么只能访问Nodeport，不能访问ClusterIP。

在这里你可以看到localhost不会监听端口80，即使我的nginx容器监听端口80。

是的，这是唯一的区别。

ClusterIP。公开只能从集群内部访问的服务。 NodePort。通过每个节点IP上的静态端口公开服务。 loadbalance。通过云提供商的负载平衡器公开服务。 ExternalName。通过返回CNAME记录的值，将服务映射到预定义的externalName字段。

实际使用案例

假设您必须在集群中创建以下架构。我想这很常见。

现在，用户只会在某个端口上与前端通信。后端和DB服务始终对外部世界隐藏。