SylviaBABY commented on code in PR #1421: URL: https://github.com/apache/apisix-website/pull/1421#discussion_r1032098101
########## blog/zh/blog/2022/11/25/how-apisix-support-1000-pods.md: ########## @@ -0,0 +1,409 @@ +--- +title: "APISIX Ingress 是如何支持上千个 Pod 副本的应用" +author: "容鑫" +authorURL: "https://github.com/AlinsRan" +authorImageURL: "https://github.com/AlinsRan.png" +keywords: +- Kubernetes +- APISIX Ingress +- 开源 +- APISIX +- Pod +description: 本文通过介绍 Kubernetes 中上千个 Pod 副本应用场景的解析,提出技术实现的困难。介绍 APISIX Ingress 是如何解决这一难题的。 +tags: [Ecosystem] +--- + +> 本文通过介绍 Kubernetes 中上千个 Pod 副本应用场景的解析,提出技术实现的困难。介绍 APISIX Ingress 是如何解决这一难题的。 + +<!--truncate--> + +## 在 Kubernetes 中为什么会遇到上千个 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 在流量高峰时的变化: + + Review Comment: maybe we can add a [tab] to keep this section indented consistently 按 tab 键把图片与上行文字保持同一个缩进,看起来内容是所属关系 <img width="1157" alt="image" src="https://user-images.githubusercontent.com/39793568/203931104-6eff8b4e-c462-4cca-81c9-c6f5ad8b311c.png"> -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
