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

少年乘勇气,百战过乌孙。这篇文章主要讲述Kubernetes出于什么考虑,放弃DNS轮询,而依赖代理模式将入站流量转发到后端呢?相关的知识,希望能为你提供帮助。
说说究竟出于什么考虑,Kubernetes放弃DNS轮询,而依赖代理模式将入站流量转发到后端呢?

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

文章图片

囧么肥事-胡说八道
Kubernetes出于什么考虑,放弃DNS轮询,而依赖代理模式将入站流量转发到后端呢()

文章图片

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

文章图片

面试官:" 简单描述一下什么是service?"
k8s定义服务是一种将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。Kubernetes 为 Pods 提供自己的 IP 地址,并为一组 Pod 提供相同的 DNS 名, 并且可以在它们之间进行负载均衡。而且使用 Kubernetes,你无需修改应用程序,即可使用不熟悉的服务发现机制,黑盒式使用,简单易上手。
Kubernetes出于什么考虑,放弃DNS轮询,而依赖代理模式将入站流量转发到后端呢()

文章图片

面试官:" k8s为什么需要服务机制呢?理由?"
k8s需要服务的动机是:Pod 是非永久性资源,面临各种适应性创建和销毁,服务机制的目标是,不管k8s集群因为什么情况,导致的Pods为了适配集群环境状态,而进行创建和销毁 Pod 后,k8s 依然能正确的匹配集群状态。
以 Deployment 工作负载为例,它可以动态创建和销毁 Pod ,k8s 设计架构决定了每个 Pod 都有自己的 IP 地址,在 Deployment 中,在某一时刻运行的 Pod 集合可能与稍后运行该应用程序的 Pod 集合不同。
这导致了一个问题:如果一组 Pod(称为“后端”)为集群内的其他 Pod(称为“前端”)提供功能, 那么前端如何找出并跟踪要连接的 IP 地址,以便前端可以使用提供工作负载的后端部分?
Kubernetes出于什么考虑,放弃DNS轮询,而依赖代理模式将入站流量转发到后端呢()

文章图片

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

文章图片

面试官:" 为什么Kubernetes放弃DNS轮询,而依赖代理模式将入站流量转发到后端呢?"
前面简单介绍了什么是Service,以及它在 k8s中的作用,维持 k8s 集群Pod匹配稳态。
下面进入正题

    推荐阅读