我发现了一篇非常有趣的文章，它解释了NodePort、LoadBalancer和Ingress之间的区别。

从文章的内容来看:

loadbalance:

A LoadBalancer service is the standard way to expose a service to the internet. On GKE, this will spin up a Network Load Balancer that will give you a single IP address that will forward all traffic to your service. If you want to directly expose a service, this is the default method. All traffic on the port you specify will be forwarded to the service. There is no filtering, no routing, etc. This means you can send almost any kind of traffic to it, like HTTP, TCP, UDP, Websockets, gRPC, or whatever. The big downside is that each service you expose with a LoadBalancer will get its own IP address, and you have to pay for a LoadBalancer per exposed service, which can get expensive!

入口:

Ingress is actually NOT a type of service. Instead, it sits in front of multiple services and act as a “smart router” or entrypoint into your cluster. You can do a lot of different things with an Ingress, and there are many types of Ingress controllers that have different capabilities. The default GKE ingress controller will spin up a HTTP(S) Load Balancer for you. This will let you do both path based and subdomain based routing to backend services. For example, you can send everything on foo.yourdomain.example to the foo service, and everything under the yourdomain.example/bar/ path to the bar service. Ingress is probably the most powerful way to expose your services, but can also be the most complicated. There are many types of Ingress controllers, from the Google Cloud Load Balancer, Nginx, Contour, Istio, and more. There are also plugins for Ingress controllers, like the cert-manager, that can automatically provision SSL certificates for your services. Ingress is the most useful if you want to expose multiple services under the same IP address, and these services all use the same L7 protocol (typically HTTP). You only pay for one load balancer if you are using the native GCP integration, and because Ingress is “smart” you can get a lot of features out of the box (like SSL, Auth, Routing, etc)

由于入口控制器运行在集群内部，具有查询和列出服务的clusterrole权限，因此它有能力发现未在外部公开的服务。这有助于根据入口规则将来自外部源的请求路由到正确的服务。

pod有自己的IP:PORT，但它本质上是动态的，如果删除或重新部署会发生变化。

服务被分配ClusterIPor NodePort(创建服务资源的虚拟机中的端口)，可以映射到一组pod或其他后端[参见:无头服务]

要访问正确的Pod，请使用ClusterIP(从集群内部) NodePort可以用于从集群外部访问pods

LoadBalancer[外部/内部]:由云提供商提供，指向ClusterIP或NodePort。您可以通过LB的IP访问该服务

LB ~> SERVICE(ClusterIP或NodePort) ~> POD

入口资源是集群的入口点。负载均衡可以侦听入路规则，并路由到特定的服务。[请看这个例子]

LB(Ingress-managed) ~> SERVICE(ClusterIP或NodePort) ~> POD

There are 4 ways to allow pods in your cluster to receive external traffic: 1.) Pod using HostNetworking: true and (Allows 1 pod per node to listen directly to ports on the host node. Minikube, bare metal, and rasberry pi's sometimes go this route which can allow the host node to listen on port 80/443 allow not using a load balancer or advanced cloud load balancer configurations, it also bypasses Kubernetes Services which can be useful for avoiding SNAT/achieving similar effect of externalTrafficPolicy: Local in scenarios where it's not supported like on AWS.) 2.) NodePort Service 3.) LoadBalancer Service (Which builds on NodePort Service) 4.) Ingress Controller + Ingress Objects (Which builds upon the above)

假设你的集群中有10个网站，你想把它们全部暴露给外部流量。 *如果你使用LoadBalancer服务类型，你将生成10个HA云负载均衡器(每个都需要花钱) *如果你使用类型Ingress Controller，你将生成1个HA云负载均衡器(节省资金)，它将指向一个Ingress Controller在你的集群中运行。 一个入口控制器是:

由集群中运行的pod部署支持的负载均衡器类型的服务。 每个豆荚做两件事: 充当在集群内运行的第7层负载均衡器。(Nginx很受欢迎) 根据集群中的入口对象动态配置自身 (入口对象可以被认为是第7层负载均衡器的声明性配置片段。)

集群内的L7 LB/Ingress Controller负载均衡/反向代理流量到集群内的集群IP服务，如果你有一个TLS证书类型的Kubernetes Secret，它也可以终止HTTPS，并引用它的Ingress对象。)

我强烈推荐阅读NodePort vs LoadBalancer vs Ingress?知识++

Ingress基于L7规则(header, uri等)在内部将流量路由到多个服务

负载均衡器将外部流量路由到单个服务。