Kubernetes出于什么考虑，放弃DNS轮询，而依赖代理模式将入站流量转发到后端呢？

Posted 2022-04-16 囧么肥事

说说究竟出于什么考虑，Kubernetes放弃DNS轮询，而依赖代理模式将入站流量转发到后端呢？

囧么肥事-胡说八道

面试官："简单描述一下什么是service？"

k8s定义服务是一种将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 DNS 名， 并且可以在它们之间进行负载均衡。而且使用 Kubernetes，你无需修改应用程序，即可使用不熟悉的服务发现机制，黑盒式使用，简单易上手。

面试官："k8s为什么需要服务机制呢？理由？"

k8s需要服务的动机是：Pod 是非永久性资源，面临各种适应性创建和销毁，服务机制的目标是，不管k8s集群因为什么情况，导致的Pods为了适配集群环境状态，而进行创建和销毁 Pod 后，k8s 依然能正确的匹配集群状态。

以 Deployment 工作负载为例，它可以动态创建和销毁 Pod ，k8s 设计架构决定了每个 Pod 都有自己的 IP 地址，在 Deployment 中，在某一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。

这导致了一个问题：如果一组 Pod（称为“后端”）为集群内的其他 Pod（称为“前端”）提供功能， 那么前端如何找出并跟踪要连接的 IP 地址，以便前端可以使用提供工作负载的后端部分？

举个例子，前端需要调用一个图片压缩的后端服务，这个图片压缩的后端服务假设叫 ImageResizeServer，它运行了 3 个副本，这些副本是可互换的。然而组成这一组后端程序的 Pod 实际上可能会发生变化，对于前端来说，前端不需要关心它们调用了哪个后端副本，前端客户端不应该也没必要知道，而且也不需要跟踪这一组后端的状态。你随意，爱咋咋地，只要最终给我处理好了就行。Service 定义的抽象能够解耦"前端"和"后端"服务关联，Service在其中起到了桥梁作用。

面试官："为什么Kubernetes放弃DNS轮询，而依赖代理模式将入站流量转发到后端呢？"

前面简单介绍了什么是Service，以及它在 k8s中的作用，维持 k8s 集群Pod匹配稳态。

下面进入正题