Kubernetes:Ingress vs Load Balancer

Question

我很担心Ingress和Load Balancer在Kubernetes中的角色.

据我所知,Ingress用于将来自互联网的传入流量映射到群集中运行的服务.

负载均衡器的作用是将流量转发到主机.在这方面,入口与负载平衡器有何不同？与Amazon ELB和ALB相比,kubernetes中的负载均衡器的概念是什么？

Answer 1

负载均衡器: kubernetes负载均衡器服务是指向不在您的kubernetes集群中但存在于其他地方的外部负载均衡器的服务.假设您的pod可以从外部路由,它们可以与您的pod一起使用.Google和AWS本身就提供此功能.就Amazon而言,在AWS中运行时直接映射到ELB和kubernetes可以为部署的每个LoadBalancer服务自动配置和配置ELB实例.

Ingress:入口实际上只是一组传递给正在监听它们的控制器的规则.您可以部署一组入口规则,但除非您有可以处理它们的控制器,否则不会发生任何事情.如果配置为执行此操作,则LoadBalancer服务可以侦听入口规则.

您还可以创建NodePort服务,该服务在群集外部具有可外部路由的IP,但指向群集中存在的Pod.这可能是一个入口控制器.

Ingress Controller只是一个配置为解释入口规则的pod.nuberx是kubernetes支持的最受欢迎的入口控制器之一.就亚马逊而言,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集群中的服务.

以下是如何使用nginx入口控制器实现kubernetes集群的示例.希望这可以帮助!

Answer 2

我发现这篇非常有趣的文章解释了NodePort,LoadBalancer和Ingress之间的区别.

从文章中的内容:

负载平衡器:

LoadBalancer服务是将服务公开给Internet的标准方法.在GKE上,这将启动一个网络负载均衡器,它将为您提供一个IP地址,将所有流量转发到您的服务.

如果要直接公开服务,这是默认方法.您指定的端口上的所有流量都将转发到该服务.没有过滤,没有路由等.这意味着您可以向其发送几乎任何类型的流量,如HTTP,TCP,UDP,Websockets,gRPC等等.

最大的缺点是您使用LoadBalancer公开的每个服务都将获得自己的IP地址,并且您必须为每个公开的服务支付LoadBalancer,这可能会变得昂贵!

入口:

Ingress实际上不是一种服务.相反,它位于多个服务的前面,充当集群中的"智能路由器"或入口点.

您可以使用Ingress执行许多不同的操作,并且有许多类型的Ingress控制器具有不同的功能.

默认的GKE入口控制器将为您启动HTTP(S)负载均衡器.这将允许您执行基于路径和子域的路由到后端服务.例如,您可以将foo.yourdomain.com上的所有内容发送到foo服务,以及yourdomain.com/bar/条目下的所有内容.

Ingress可能是最有效的公开服务的方式,但也可能是最复杂的.有许多类型的Ingress控制器,来自Google Cloud Load Balancer,Nginx,Contour,Istio等.还有Ingress控制器的插件,如cert-manager,可以自动为您的服务配置SSL证书.

如果要在同一IP地址下公开多个服务,Ingress是最有用的,并且这些服务都使用相同的L7协议(通常是HTTP).如果您使用本机GCP集成,您只需支付一个负载均衡器,并且因为Ingress是"智能"的,您可以获得大量开箱即用的功能(如SSL,身份验证,路由等)

Answer 3

有 4 种方法可以让集群中的 pod 接收外部流量：
1.) 使用 HostNetworking 的 Pod：true 和（允许每个节点 1 个 pod 直接侦听主机节点上的端口。Minikube、裸机和 rasberry pi 有时会去这条允许主机节点监听 80/443 端口的路由允许不使用负载均衡器或高级云负载均衡器配置，它还绕过了 Kubernetes 服务，这对于避免 SNAT/在场景中实现类似 externalTrafficPolicy: Local 效果很有用在 AWS 上不支持它。）
2.）NodePort 服务
3.）LoadBalancer 服务（建立在 NodePort 服务上）
4.）入口控制器 + 入口对象（建立在上述之上）

假设您的集群中托管了 10 个网站，并且您希望将它们全部公开给外部流量。
*如果你使用 LoadBalancer Service 类型，你将产生 10 个 HA 云负载均衡器（每个都要花钱）
*如果你使用 Ingress Controller 类型，你将产生 1 个 HA 云负载均衡器（省钱），它会指向一个 Ingress在您的集群中运行的控制器。

入口控制器是：

• 负载均衡器类型的服务，由在集群中运行的 pod 部署提供支持。
• 每个 Pod 做两件事：
  1. 充当在集群内运行的第 7 层负载均衡器。（Nginx 流行的有多种口味）
  2. 根据集群中的
     入口对象动态配置自身 （入口对象可以被认为是第 7 层负载均衡器的声明性配置片段。）

集群内的 L7 LB/入口控制器负载平衡/反向代理到集群内的集群 IP 服务的流量，如果您有 TLS 证书类型的 Kubernetes Secret 和引用它的 Ingress 对象，它也可以终止 HTTPS。）

Answer 4

\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n \n\n\n\n\n\n\n\n\n\n\n

Feature	Ingress	Load Balancer
协议	HTTP 级别（网络第 7 层）	网络层4
附加功能	基于 cookie 的会话关联、入口规则、资源后端、路径类型	仅平衡负载
依赖性	入口控制器需要运行。不同的 Kubernetes 环境使用不同的控制器实现，但有几个根本不提供默认控制器。	无依赖性，内置 K8 支持
YAML 清单	它有单独的 API。apiVersion: networking.k8s.io/v1	type: LoadBalancer
它是如何工作的	客户端通过 Ingress 控制器连接到其中一个 Pod。客户端首先对 example.com 进行 DNS 查找，DNS 服务器（或本地操作系统）返回 Ingress 控制器的 IP。然后，客户端向 Ingress 控制器发送 HTTP 请求，并在 Host 标头中指定 example.com。根据该标头，控制器确定客户端尝试访问哪个服务，通过与该服务关联的Endpoints 对象查找 pod IP ，并将 client\xe2\x80\x99s 请求转发到其中一个 pod。	负载均衡器将流量重定向到所有节点上的节点端口。客户端通过负载均衡器\xe2\x80\x99s IP 连接到服务。

\n

\n

我强烈推荐阅读 NodePort vs LoadBalancer vs Ingress？对于知识++

\n

Answer 5

简而言之，负载均衡器在多个后端服务（相同类型）之间分配请求，而入口更像是一个 API 网关（反向代理），它根据 URL 等将请求路由到特定的后端服务。

Answer 6

入口：入口对象 + 入口控制器

入口资源：

就像服务资源一样，除了它自己不做任何事情。Ingress Resource 只是描述了一种将第 7 层流量路由到集群的方法，通过指定诸如请求路径、请求域和目标 kubernetes 服务之类的内容，而服务对象实际上是创建服务

入口控制器：

一项服务：

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

例如，Nginx Ingress Controller 可以使用服务侦听端口 80 和 443，然后读取新的 Ingress 资源并将它们解析为新的 server{} 部分，并动态放置到它的 nginx.conf 中

LoadBalancer：外部负载均衡器提供者 + 服务类型

外部负载均衡器提供程序：

外部负载均衡器提供商通常在 AWS 和 GKE 等云中配置，并提供一种通过创建外部负载均衡器来分配外部 IP 的方法。可以通过将服务指定为“LoadBalancer”类型来使用此功能。

服务类型：

当服务类型设置为 LoadBalancer 时，Kubernetes 会尝试使用 Kubernetes pod 的条目创建并配置外部负载均衡器，从而为它们分配外部 IP。

Kubernetes 服务控制器自动创建外部负载均衡器、健康检查（如果需要）、防火墙规则（如果需要），并检索由云提供商分配的新创建或配置的 LoadBalancer 的外部 IP 并将其填充到服务对象。

一个额外的云控制器可以安装在集群上，并被分配读取服务资源及其注释，以便自动部署和配置云负载均衡器，这些负载均衡器将接收 kubernetes 服务的流量。

关系：

Ingress Controller 服务通常被配置为 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/

Answer 7

TL:DR

1. Ingress位于公共网络(Internet)和Kubernetes服务之间,公开展示我们的Api实施.
2. Ingress能够提供负载平衡,SSL终止和基于名称的虚拟主机.
3. 入口功能允许从单个域名安全地公开多个API或应用程序.

让我们从实际用例开始:您有多个Apis支持服务实现包(ASIP为clariy和简洁),以便在一个域名下部署.由于您是一名前沿开发人员,因此您实施了一种微服务架构,该架构需要为每个ASIP单独部署,以便可以单独升级或扩展.当然,这些ASIP封装在单独的docker容器中,并可从容器存储库提供给Kubernetes(K8s).

现在让我们说你想在Google的GKE K8上部署它.为了实现持续可用性,每个ASIP实例(副本)部署在不同的节点(VM)上,其中每个VM都有自己的云内部IP地址.每个ASIP部署都配置在一个恰当的名称"deployment.yaml"文件中,您可以在其中声明性地指定给定ASIP K8应部署的副本数量.

下一步是将API暴露给外部世界,并将请求汇集到部署的ASIP实例之一.由于我们在不同节点上运行了相同ASIP的许多副本,因此我们需要一些能够在这些副本之间分发请求的东西.为了解决这个问题,我们可以创建并应用一个"service.yaml"文件,该文件将配置一个K8s服务(KServ),该服务将通过IP地址向外公开和访问.该KServ将在其配置的ASIP中负责API的请求分发.请注意,当ASIP的节点发生故障并重新启动时,K8主机将自动重新配置KServ.在这种情况下,永远不会重用内部IP地址,并且必须告知KServ新的ASIP部署位置.

但是我们有其他Api服务包,它们将在同一域名上公开.旋转新的KServ将创建新的外部IP地址,我们将无法在同一域名上公开它.好吧,这就是Ingress的用武之地.

Ingress位于互联网和我们向外界传播的所有KServices之间.Ingress能够提供负载平衡,SSL终止和基于名称的虚拟主机.后一种容量能够通过分析它的URL将传入请求路由到正确的服务.当然,Ingress必须配置并应用..."ingress.yaml"文件,该文件将指定将请求发送到正确的KServ所需的重写和路由.

互联网 - >入口 - > K8s服务 - >复制品

因此,通过正确的入口,KServices和ASIP配置,我们可以使用相同的域名安全地公开许多API.

Answer 8

负载均衡器服务：是第 4 层代理（TCP、UDP，..）。它在 Kubernetes 集群网络之外运行。它没有第 7 层的功能：CircuitBreaker、测量请求数量、请求的延迟、失败、路由……

ingress：是第 7 层代理（http、https、gRPC，..）。它是 Kubernetes 集群网络内 pod 中的应用程序。如果入口 Pod 死亡，Kubernetes 将重新启动它或将其移动到集群中的其他节点。