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

ClusterIp暴露< NodePort暴露< LoadBalancer暴露

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

Summary: There are five types of Services: ClusterIP (default): Internal clients send requests to a stable internal IP address. NodePort: Clients send requests to the IP address of a node on one or more nodePort values that are specified by the Service. LoadBalancer: Clients send requests to the IP address of a network load balancer. ExternalName: Internal clients use the DNS name of a Service as an alias for an external DNS name. Headless: You can use a headless service when you want a Pod grouping, but don't need a stable IP address. The NodePort type is an extension of the ClusterIP type. So a Service of type NodePort has a cluster IP address. The LoadBalancer type is an extension of the NodePort type. So a Service of type LoadBalancer has a cluster IP address and one or more nodePort values.

通过图像说明

Details ClusterIP ClusterIP is the default and most common service type. Kubernetes will assign a cluster-internal IP address to ClusterIP service. This makes the service only reachable within the cluster. You cannot make requests to service (pods) from outside the cluster. You can optionally set cluster IP in the service definition file. Use Cases Inter-service communication within the cluster. For example, communication between the front-end and back-end components of your app. NodePort NodePort service is an extension of ClusterIP service. A ClusterIP Service, to which the NodePort Service routes, is automatically created. It exposes the service outside of the cluster by adding a cluster-wide port on top of ClusterIP. NodePort exposes the service on each Node’s IP at a static port (the NodePort). Each node proxies that port into your Service. So, external traffic has access to fixed port on each Node. It means any request to your cluster on that port gets forwarded to the service. You can contact the NodePort Service, from outside the cluster, by requesting :. Node port must be in the range of 30000–32767. Manually allocating a port to the service is optional. If it is undefined, Kubernetes will automatically assign one. If you are going to choose node port explicitly, ensure that the port was not already used by another service. Use Cases When you want to enable external connectivity to your service. Using a NodePort gives you the freedom to set up your own load balancing solution, to configure environments that are not fully supported by Kubernetes, or even to expose one or more nodes’ IPs directly. Prefer to place a load balancer above your nodes to avoid node failure. LoadBalancer LoadBalancer service is an extension of NodePort service. NodePort and ClusterIP Services, to which the external load balancer routes, are automatically created. It integrates NodePort with cloud-based load balancers. It exposes the Service externally using a cloud provider’s load balancer. Each cloud provider (AWS, Azure, GCP, etc) has its own native load balancer implementation. The cloud provider will create a load balancer, which then automatically routes requests to your Kubernetes Service. Traffic from the external load balancer is directed at the backend Pods. The cloud provider decides how it is load balanced. The actual creation of the load balancer happens asynchronously. Every time you want to expose a service to the outside world, you have to create a new LoadBalancer and get an IP address. Use Cases When you are using a cloud provider to host your Kubernetes cluster. ExternalName Services of type ExternalName map a Service to a DNS name, not to a typical selector such as my-service. You specify these Services with the spec.externalName parameter. It maps the Service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is established. Use Cases This is commonly used to create a service within Kubernetes to represent an external datastore like a database that runs externally to Kubernetes. You can use that ExternalName service (as a local service) when Pods from one namespace talk to a service in another namespace.

假设你在本地机器上创建了一个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/

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

下图显示了基本关系。

实际的理解。

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

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

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

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

是的，这是唯一的区别。

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

实际使用案例

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

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

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。

来源:

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