简单地说，负载均衡器将请求分配给多个后端服务(相同类型)，而入口更像一个API网关(反向代理)，它根据URL将请求路由到特定的后端服务。

短版:

在Kubernetes中，对象定义定义所需的状态，而控制器则监视对象定义以实现该状态。

入口:

“Ingress”对象，它自己做的很少，但定义了L7负载平衡规则 “入口控制器”，监视入口对象的状态，以根据在入口对象中定义的规则创建L7 LB配置

loadbalance:

"Service"类型为"LoadBalancer"的对象，允许将服务附加到LoadBalancer “负载均衡器控制器”，根据服务对象中定义的规则创建负载均衡器

入口

进入对象:

一个kubernetes对象，它自己不做任何事情，因为默认情况下不包括入口控制器。Ingress对象只是通过指定请求路径、请求域和目标kubernetes服务来描述将第7层流量路由到集群的方法，而添加服务对象实际上可能会创建服务，因为默认情况下kubernetes中包含了服务控制器。

入口控制器:

Kubernetes部署/DaemonSet +服务:

  1. listens on specific ports (usually 80 and 443) for web traffic
  2. Watches for the creation, modification, or deletion of Ingress Resources
  3. Creates internal L7 routing rules based on desired state indicated by Ingress Objects

例如，Nginx入口控制器可以:

使用服务在端口80和443监听传入的流量 注意Ingress对象的创建，并将所需的状态转换为新的服务器{}部分，这些部分将动态地放入nginx.conf中

loadbalance

负载均衡器控制器:

负载均衡器控制器可以在AWS和GKE等平台上配置，并提供一种通过创建外部负载均衡器分配外部ip的方法。此功能可用于:

部署负载均衡器控制器(如果尚未部署) 设置服务类型为“LoadBalancer” 在服务中设置适当的注释以配置负载均衡器

服务类型:

当服务类型设置为LoadBalancer并且存在云提供的负载均衡器控制器时，该服务将使用云提供商的负载均衡器对外公开。NodePort和ClusterIP服务(外部负载均衡器路由到的服务)自动创建，从而分配服务外部ip和或DNS。

的关系

入口控制器服务通常配置为LoadBalancer类型，以便http和https请求可以通过外部ip代理/路由到特定的内部服务。

然而，这并不严格需要LoadBalancer。因为，通过使用hostNetwork或hostPort，您可以在技术上将主机上的端口绑定到服务(允许您通过主机的外部ip:port访问它)。虽然官方不建议这样做，因为它会占用实际节点上的端口。

参考文献

https://kubernetes.io/docs/concepts/configuration/overview/#services

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/

https://kubernetes.io/docs/tasks/access-application-cluster/create-external-load-balancer/#external-load-balancer-providers

https://kubernetes.io/docs/concepts/services-networking/ingress/ https://kubernetes.io/docs/concepts/architecture/cloud-controller/ https://kubernetes-sigs.github.io/aws-load-balancer-controller/v2.3/

我发现了一篇非常有趣的文章，它解释了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)

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对象。)

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

负载均衡器:kubernetes LoadBalancer服务是一种指向外部负载均衡器的服务，这些负载均衡器不在kubernetes集群中，但存在于其他地方。它们可以与您的舱一起工作，假设您的舱是外部可路由的。谷歌和AWS在本地提供此功能。就Amazon而言，当在AWS中运行时，它直接与ELB和kubernetes映射，可以为部署的每个LoadBalancer服务自动提供和配置ELB实例。

Ingress: Ingress实际上就是一组要传递给正在监听它们的控制器的规则。你可以部署一堆入口规则，但是除非你有一个可以处理它们的控制器，否则什么都不会发生。LoadBalancer服务可以监听入口规则，如果它被配置为这样做的话。

您还可以创建NodePort服务，该服务在集群外有一个外部可路由的IP，但指向集群内存在的pod。这可能是一个入口控制器。

入口控制器是一个简单的pod，它被配置为解释入口规则。kubernetes支持的最流行的入口控制器之一是nginx。在Amazon方面，ALB可以用作入口控制器。

例如，这个nginx控制器能够摄取你定义的入口规则，并将它们转换为nginx.conf文件，并在它的pod中加载和启动。

假设你定义了一个入口，如下所示:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
   ingress.kubernetes.io/rewrite-target: /
 name: web-ingress
spec:
  rules:
  - host: kubernetes.foo.bar
    http:
      paths:
      - backend:
          serviceName: appsvc
          servicePort: 80
        path: /app

如果你检查你的nginx控制器pod，你会看到/etc/nginx.conf中定义了以下规则:

server {
    server_name kubernetes.foo.bar;
    listen 80;
    listen [::]:80;
    set $proxy_upstream_name "-";
    location ~* ^/web2\/?(?<baseuri>.*) {
        set $proxy_upstream_name "apps-web2svc-8080";
        port_in_redirect off;

        client_max_body_size                    "1m";

        proxy_set_header Host                   $best_http_host;

        # Pass the extracted client certificate to the backend

        # Allow websocket connections
        proxy_set_header                        Upgrade           $http_upgrade;
        proxy_set_header                        Connection        $connection_upgrade;

        proxy_set_header X-Real-IP              $the_real_ip;
        proxy_set_header X-Forwarded-For        $the_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $best_http_host;
        proxy_set_header X-Forwarded-Port       $pass_port;
        proxy_set_header X-Forwarded-Proto      $pass_access_scheme;
        proxy_set_header X-Original-URI         $request_uri;
        proxy_set_header X-Scheme               $pass_access_scheme;

        # mitigate HTTPoxy Vulnerability
        # https://www.nginx.com/blog/mitigating-the-httpoxy-vulnerability-with-nginx/
        proxy_set_header Proxy                  "";

        # Custom headers

        proxy_connect_timeout                   5s;
        proxy_send_timeout                      60s;
        proxy_read_timeout                      60s;

        proxy_redirect                          off;
        proxy_buffering                         off;
        proxy_buffer_size                       "4k";
        proxy_buffers                           4 "4k";

        proxy_http_version                      1.1;

        proxy_cookie_domain                     off;
        proxy_cookie_path                       off;

    rewrite /app/(.*) /$1 break;
    rewrite /app / break;
    proxy_pass http://apps-appsvc-8080;
    
    }

Nginx刚刚创建了一条规则，将http://kubernetes.foo.bar/app路由到集群中的服务appsvc。

下面是一个如何使用nginx入口控制器实现kubernetes集群的示例。