入口与负载平衡器
Answers:
负载均衡器： kubernetes LoadBalancer服务是指向外部负载均衡器的服务，该负载均衡器不在您的kubernetes集群中，但在其他地方存在。他们可以与您的Pod一起使用，前提是您的Pod在外部是可路由的。Google和AWS本机提供此功能。对于Amazon而言，当在AWS中运行时，它直接与ELB和kubernetes映射，可以为部署的每个LoadBalancer服务自动配置和配置ELB实例。
入口：入口实际上只是一组要传递给正在侦听它们的控制器的规则。您可以部署一堆入口规则，但是除非您拥有可以处理它们的控制器，否则什么也不会发生。如果将LoadBalancer服务配置为侦听入口规则，则它可以侦听入口规则。
您还可以创建NodePort服务，该服务在群集外部具有可外部路由的IP，但指向群集中存在的容器。这可能是一个入口控制器。
入口控制器只是配置为解释入口规则的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控制器容器，您将看到以下规则定义/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您的集群中的服务。
我发现这篇非常有趣的文章解释了NodePort，LoadBalancer和Ingress之间的区别。
根据文章中的内容：
负载均衡器：
LoadBalancer服务是将服务公开到Internet的标准方法。在GKE上，这将启动网络负载平衡器，该网络负载平衡器将为您提供一个IP地址，该IP地址会将所有流量转发到您的服务。
如果要直接公开服务，这是默认方法。您指定的端口上的所有流量都将转发到服务。没有过滤，没有路由等。这意味着您可以向它发送几乎任何类型的流量，例如HTTP，TCP，UDP，Websockets，gRPC或其他任何内容。
最大的缺点是，您使用LoadBalancer公开的每个服务都将获得其自己的IP地址，并且您必须为每个公开的服务支付LoadBalancer的费用，这可能会变得昂贵！
入口：
入口实际上不是一种服务。相反，它位于多种服务的前面，并充当“智能路由器”或群集的入口点。
您可以使用Ingress进行很多不同的事情，并且有许多类型的Ingress控制器具有不同的功能。
默认的GKE入口控制器将为您启动HTTP（S）负载平衡器。这将使您可以进行基于路径的路由和基于子域的路由到后端服务。例如，您可以将foo.yourdomain.com上的所有内容发送到foo服务，并将yourdomain.com/bar/路径下的所有内容发送到bar服务。
Ingress可能是公开服务的最强大方法，但也可能是最复杂的。Google云端负载平衡器，Nginx，Contour，Istio等的Ingress控制器类型很多。还有一些用于Ingress控制器的插件，例如cert-manager，可以自动为您的服务设置SSL证书。
如果要在同一IP地址下公开多个服务，并且这些服务都使用相同的L7协议（通常为HTTP），则Ingress最有用。如果您使用的是本地GCP集成，则只需为一个负载平衡器付费，并且由于Ingress是“智能”的，因此您可以直接使用很多功能（例如SSL，Auth，Routing等）
TL：DR
- Ingress位于公共网络（Internet）和Kubernetes服务之间，这些服务公开公开了我们Api的实现。
- Ingress能够提供负载平衡，SSL终止和基于名称的虚拟主机。
- 入口功能允许从单个域名安全地公开多个API或应用程序。
让我们从实际的用例开始：您有多个由服务实现程序包支持的Apis（为方便而简洁的ASIP），可以在一个域名下进行部署。当您是尖端开发人员时，您实现了微服务体系结构，该体系结构要求为每个ASIP进行单独的部署，以便可以分别升级或扩展它们。当然，这些ASIP封装在单独的docker容器中，并且可以从容器存储库中供Kubernetes（K8）使用。
现在假设您要在Google的GKE K8上部署它。为了实现持续的可用性，每个ASIP实例（副本）都部署在不同的节点（VM）上，每个VM都有自己的云内部IP地址。每个ASIP部署都在一个恰当的名称“ deployment.yaml”文件中进行配置，您可以在其中以声明方式指定应部署给定ASIP K8的副本数量。
下一步是将API暴露给ouside世界，并将请求集中到已部署的ASIP实例之一。由于我们在不同的节点上运行着多个相同ASIP的副本，因此我们需要在这些副本之间分发请求的内容。为解决此问题，我们可以创建并应用“ service.yaml”文件，该文件将配置K8s服务（KServ），该服务将在外部公开并通过IP地址访问。该KServ将负责在已配置的ASIP之间分配API的请求。请注意，当ASIP的节点发生故障并重新启动时，K8的主服务器会自动重新配置KServ。在这种情况下，内部IP地址永远不会被重用，并且必须告知KServ新ASIP的部署位置。
但是，我们还有其他Api服务包，这些服务包应在同一域名上公开。旋转新的KServ将创建一个新的外部IP地址，我们将无法在相同的域名上公开它。好吧，这就是Ingress的来历。
入口位于Internet和我们向外界公开的所有KService之间。Ingress能够提供负载平衡，SSL终止和基于名称的虚拟主机。后一种能力能够通过分析URL来将传入请求路由到正确的服务。当然，必须为Ingress配置并应用一个...“ ingress.yaml”文件，该文件将指定将请求发送到正确的KServ的重写和路由。
互联网->入口-> K8s服务->副本
因此，通过正确的入口，KServices和ASIPs配置，我们可以使用相同的域名安全地公开许多API。
有四种方法允许群集中的
Pod 接收外部流量：
1.）使用HostNetworking的Pod：true和（每个节点允许1个Pod直接侦听主机节点上的端口。Minikube，裸机和rasberry pi有时会使用该路由可以允许主机节点在端口80/443上侦听，从而不使用负载均衡器或高级云负载均衡器配置，它还绕过Kubernetes服务，这对于避免SNAT /实现类似externalTrafficPolicy的效果很有用：在场景中为本地（例如，在AWS上不受支持。）
2.）NodePort服务
3.）LoadBalancer服务（基于NodePort服务构建）
4.）入口控制器+入口对象（基于以上构建）
假设您的群集中托管了10个网站，并且您希望将它们全部暴露给外部流量。
*如果使用类型LoadBalancer Service，将生成10个HA Cloud负载均衡器（每个都需要花钱）
*如果使用类型Ingress Controller，则将生成1个HA Cloud负载均衡器（可节省钱），它将指向一个Ingress在集群中运行的控制器。
入口控制器为：
- 由群集中运行的Pod部署支持的类型为Load Balancer的服务。
- 每个吊舱执行2件事：
- 充当在群集内运行的第7层负载均衡器。（Nginx有多种口味很受欢迎）
- 根据群集中的
入口对象动态配置自身 （入口对象可以看作是第7层负载均衡器的声明性配置片段。）
群集内的L7 LB / Ingress控制器负载均衡/向群集内的群集IP服务的反向代理流量，如果您具有TLS证书类型的Kubernetes Secret和引用它的Ingress对象，它也可以终止HTTPS。）
入口：入口对象+入口控制器
入口对象：
就像服务对象一样，不同之处在于它不会自行执行任何操作。入口对象只是通过指定诸如请求路径，请求域和目标kubernetes服务之类的东西来描述将第7层流量路由到群集中的方法，而服务对象实际上是在创建服务
入口控制器：
一项服务：
1. listens on specific ports (usually 80 and 443) for web traffic
2. Listens for the creation, modification, or deletion of Ingress Objects
3. Creates internal L7 routing rules based on these Ingress Objects
例如，Nginx Ingress Controller可以使用服务侦听端口80和443，然后读取新的Ingress对象并将其解析为新的server {}部分，然后将其动态放置到nginx.conf中。
LoadBalancer：外部负载平衡器提供程序+服务类型
外部负载平衡器提供程序：
外部负载均衡器提供程序通常在AWS和GKE等云中进行配置，并提供了一种通过创建外部负载均衡器来分配外部IP的方法。通过将服务指定为“ LoadBalancer”类型，可以使用此功能。
服务类型：
当服务类型设置为LoadBalancer时，Kubernetes尝试创建一个外部负载均衡器，然后使用Kubernetes Pod的条目对其进行编程，从而为其分配外部IP。
Kubernetes服务控制器自动执行外部负载均衡器的创建，运行状况检查（如果需要），防火墙规则（如果需要），并检索由云提供商分配的新创建或配置的LoadBalancer的外部IP，并将其填充到服务对象。
关系：
Ingress Controller Services通常以LoadBalancer类型配置，因此可以通过外部ip将http和https请求代理/路由到特定的内部服务。
但是，并非严格为此需要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/concepts/services-networking/ingress/