APISIX Ingress 是如何支持上千个 Pod 副本的应用

最新推荐文章于 2024-08-06 04:31:29 发布

API7.ai 技术团队

最新推荐文章于 2024-08-06 04:31:29 发布

阅读量458

点赞数

分类专栏：技术布道文章标签： kubernetes 运维 docker APISIX 开源

本文链接：https://blog.csdn.net/ApacheAPISIX/article/details/128081440

版权

本文详细介绍了在Kubernetes中处理大流量场景时，为何会出现上千个Pod副本的应用需求，以及Endpoints和Endpointslices的区别与应用场景。重点探讨了APISIX Ingress如何支持Endpointslices，确保在高并发时的性能和稳定性，同时提供了在APISIX Ingress中启用Endpointslices特性的实践步骤。

摘要由CSDN通过智能技术生成

作者：容鑫，Apache APISIX Committer

在 K8s 中为什么会遇到上千个 Pod 副本的应用场景？

在 Kubernetes 中，Pod 是最小的调度单元。应用程序实际是以 Pod 在运行的，通常情况下出于可扩展性和降低爆炸半径等方面的考虑，只会给 Pod 设置有限的资源。那么对于大流量的场景，一般都是通过水平扩容的方式进行应对。

例如电商行业在进行促销活动或秒杀抢购活动时，业务流量相对较大。为了应对这种场景，通常会设置弹性扩容。在活动进行时，服务会进行弹性伸缩直到能够承载流量，这时会基于弹性扩容的策略，为业务增加副本数，也就是 Pod 会变多。

每个 Pod 都有各自唯一的 IP ，但同时 Pod 的 IP 也不是固定的。为了及时追踪 Pod IP 的变化，从而进行负载均衡，Endpoints API 提供了在 Kubernetes 中跟踪网络端点的一种简单而直接的方法。
但随着 Kubernetes 集群和服务逐渐开始为更多的后端 Pod 进行处理和发送请求，比如上文提到大流量场景下，Pod 数量会被不断扩容，Endpoints API 也将变得越大。这种情况下，Endpoints API 局限性变得越来越明显，甚至成为性能瓶颈。

为了解决这个局限性问题，在 Kubernetes v1.21 的版本中引入了对 Endpointslice API 的支持，解决了 Endpoints API 处理大量网络端点带来的性能问题，同时提供了可扩展和可伸缩的能力。
通过下图我们可以明显看到它们之间的区别：

Endpoints 在流量高峰时的变化：
Endpointslices 在流量高峰时的变化：

在 Kubernetes 中，应用之间是如何进行相互访问的呢？Endpoints 和 Endpointslice 具体区别又是什么？和 Pod 有着什么样的关系？APISIX Ingress 中为什么要支持这些特性，以及如何进行安装和使用？本文将着重介绍这些问题。

Kubernetes 中如何访问应用

在 Kubernetes 中，每个 Pod 都有其自己唯一的 IP 地址。通常情况下，Service 通过 selector 和一组 Pod 建立关联，并提供了相同的 DNS 名，并可以在它之间进行负载均衡。Kubernetes 集群内不同应用之间可通过 DNS 进行相互访问。

在 Service 创建时，Kubernetes 会根据 Service 关联一个 Endpoints 资源，若 Service 没有定义 selector 字段，将不会自动创建 Endpoints。

什么是 Endpoints

Endpoints 是 Kubernetes 中的一个资源对象，存储在 etcd 中，用来记录一个 Service 对应一组 Pod 的访问地址，一个 Service 只有一个 Endpoints 资源。Endpoints 资源会去观测 Pod 集合，只要服务中的某个 Pod 发生变更，Endpoints 就会进行同步更新。
比如部署 3 个 httpbin 副本，查看 Pod 的情况，包括 IP 信息。

$ kubectl get pods -o wide
NAME                                 READY   STATUS    RESTARTS        AGE   IP            NODE             NOMINATED NODE   READINESS GATES
httpbin-deployment-fdd7d8dfb-8sxxq   1/1     Running   0               49m   10.1.36.133   docker-desktop   <none>           <none>
httpbin-deployment-fdd7d8dfb-bjw99   1/1     Running   4 (5h39m ago)   23d   10.1.36.125   docker-desktop   <none>           <none>
httpbin-deployment-fdd7d8dfb-r5nf9   1/1     Running   0               49m   10.1.36.131   docker-desktop   <none>           <none>

创建 httpbin 服务，并查看应 Endpoints 端点情况。

$ kubectl get endpoints httpbin
NAME      ENDPOINTS                                      AGE
httpbin   10.1.36.125:80,10.1.36.131:80,10.1.36.133:80   23d

从上述示例可以看到，Endpoints 中 httpbin 资源对象的所有网络端点，分别对应了每个 Pod 的 IP 地址。

当然， Endpoints 也有它的一些不足之处，比如：

Endpoints 具有容量限制，如果某个 Endpoints 资源中端口的个数超过 1000，那么 Endpoints 控制器会将其截断为 1000。
一个 Service 只有一个 Endpoints 资源，这意味着它需要为支持相应服务的每个 Pod 存储 IP 等网络信息。这导致 Endpoints 资源变的十分巨大，其中一个端点发生了变更，将会导致整个 Endpoints 资源更新。当业务需要进行频繁端点更新时，一个巨大的 API 资源被相互传递，而这会影响到 Kubernetes 组件的性能，并且会产生大量的网络流量和额外的处理。

什么是 Endpointslices

Endpointslices 为 Endpoints 提供了一种可扩缩和可拓展的替代方案，缓解处理大量网络端点带来的性能问题，还能为一些诸如拓扑路由的额外功能提供一个可扩展的平台。该特性在 Kubernetes v1.21+ 的版本中已提供支持。

EndpointSlice 旨在通过分片的方式来解决此问题，并没有使用单个 Endpoints 资源跟踪服务的所有网络端点，而是将它们拆分为多个较小的 EndpointSlice。

默认情况下，控制面创建和管理的 EndpointSlice 将包含不超过 100 个端点。你可以使用 kube-controller-manager 的 --max-endpoints-per-slice 标志设置此值，其最大值为 1000。

为什么需要 Endpointslices

首先，我们考虑具有 2000 个 Pod 的服务它最终可能具有 1.0 MB 的 Endpoints 资源。在生产环境中，如果该服务发生滚动更新或节点迁移，那么 Endpoints 资源将会频繁变更。

想象一下，如果滚动更新会导致全部 Pod 都被替换，由于 etcd 具有最大请求大小限制，Kubernetes 对 Endpoints 最大容量限制为 1000，如果网络端点数量超出了 1000，那么多出来的网络端点，将不会被 Endpoints 资源记录。

当然也可能因为一些需求，需要多次进行滚动更新，那么这个巨大的 API 资源对象将会 Kubernetes 组件中来回传递，极大影响了 Kubernetes 组件的性能。

如果使用了 Endpointslices，假设一个服务后端有 2000 个 Pod。如果将配置修改为每个 Endpointslices 存储 100 个端点，最终将获得 20 个 Endpointslices。添加或删除 Pod 时，只需要更新其中 1 个 Endpointslice 资源即可，这样操作后，可扩展性和网络可伸缩有了很大的提升。

比起在流量高峰时，服务为了承载流量，扩容出大量的 Pod，Endpoints 资源会被频繁更新，两个使用场景的差异就变得非常明显。更重要的是，既然服务的所有 Pod IP 都不需要存储在单个资源中，那么我们就不必担心 etcd 中存储的对象的大小限制。

Endpoints VS Endpointslice

因为 Endpointslice 是在 Kubernetes v1.21+ 的版本得到支持，所以该结论是基于 Kubernetes v1.21+ 版本。

通过上文的描述我们总结一下两种资源的适用情况。

Endpoints 适用场景：

有弹性伸缩需求，Pod 数量较少，传递资源不会造成大量网络流量和额外处理。
无弹性伸缩需求，Pod 数量不会太多。哪怕 Pod 数量是固定，但是总是要滚动更新或者出现故障的。

Endpointslice 适用场景:

有弹性需求，且 Pod 数量较多（几百上千）。
Pod 数量很多（几百上千），因为 Endpoints 网络端点最大数量限制为 1000，所以超过 1000 的 Pod 必须得用 Endpointslice。

在 APISIX Ingress 中的实践

APISIX Ingress Controller 是一个 Ingress 控制器的实现。可以将用户配置的规则转换为 Apache APISIX中的规则，从而使用 APISIX 完成具体的流量承载。

在具体实现过程中，APISIX Ingress 通过 watch Endpoints 或 Endpointslice 资源的变化，从而让 APISIX 能够对 Pod 进行负载均衡和健康检查等。为了能够支持 Kubernetes v1.16+ 的版本，APISIX Ingress 在安装时，默认使用 Endpoints 的特性。

如果你的集群版本为 Kubernetes v1.21+，在安装 APISIX Ingress 时，需要指定 watchEndpointSlice=true 标志来开启 Endpointslice 特性的支持。