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

少年乘勇气，百战过乌孙。这篇文章主要讲述Kubernetes出于什么考虑，放弃DNS轮询，而依赖代理模式将入站流量转发到后端呢？相关的知识，希望能为你提供帮助。
说说究竟出于什么考虑，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 地址，以便前端可以使用提供工作负载的后端部分？

文章图片

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