首先我们来了解一下,在Kubernetes中,Service和apiServer是两个不同的概念。

Service是一种抽象,用于定义一组Pod的访问方式。它可以提供负载均衡、服务发现等功能,使得应用程序可以通过一个固定的地址和端口来访问这组Pod,而不需要关心Pod的具体IP地址和端口号。Service通常用于前台服务、中台服务等场景。

API Server是Kubernetes集群中的核心组件之一,它提供了Kubernetes API的访问接口。所有Kubernetes资源对象(如Pod、Service、Deployment等)都可以通过API Server进行创建、更新、查询和删除。API Server还负责对资源对象进行认证、授权和准入控制等操作,确保集群的安全性和稳定性。

kube-api是Kubernetes API Server的后端存储,它负责将Kubernetes API中的资源对象(如Pod、Service、Deployment等)持久化到etcd等数据存储中,并提供对这些资源对象的查询、修改、删除等操作。kube-api还负责对资源对象进行认证、授权和准入控制等操作,确保集群的安全性和稳定性。

kube-api还提供了一些附加功能,如API聚合、API扩展等,使得Kubernetes API可以支持更多的自定义资源对象和API扩展。

目录

为什么需要Service?

Service是如何工作的?

Servise的IPVS模式



我们今天来了解service。

为什么需要Service?

1,pod的IP不是固定的,我们可以利用固定的Service来访问Pod

2,pod实例之间有负载均衡的需求。

我们在这篇文章pod的编排扩张和收缩(1)_量子学习法的博客-CSDN博客​​​​​​提到两种Service对pod的转发方式。实际上,在这里被Service 选中的pod就称为Service的endpoints。

Service是如何工作的?

Service 是由 kube-proxy 组件,加上 iptables 来共同实现的。

iptables是Linux的机制,表示是一组转发规则,表示你要访问的IP应该跳到到哪个IP上。而S revise也正是根据这些规则实现负载均衡。

例如,Service代理三个pod。那么假设随机转发的目的地,分别是 KUBE-SEP-WNBA2IHDGP2BOBGZ、KUBE-SEP- X3P2623AGDH6CDF3 和 KUBE-SEP-57KPRZ3JQVENLNBR。而这三条链指向的最终目的地,其实就是这个 Service 代理的三个 Pod。而iptables 规则的匹配是从上到下逐条进行的,所以为了保证上述三条规则 每条被选中的概率都相同,我们应该将它们的 probability 字段的值分别设置为 1/3(0.333...)、1/2 和 1。

这样,访问 Service VIP 的 IP 包经过上述 iptables 处理之后,就已经变成了访问具体某一 个后端 Pod 的 IP 包了。不难理解,这些 Endpoints 对应的 iptables 规则,正是 kube- proxy 通过监听 Pod 的变化事件,在宿主机上生成并维护的。

Servise的IPVS模式

你的宿主机上有大量 Pod 的时候,成百上千条 iptables 规则不断地被刷新, 会大量占用该宿主机的 CPU 资源,甚至会让宿主机“卡”在这个过程中。所以说,一直以 来,基于 iptables 的 Service 实现,都是制约 Kubernetes 项目承载更多量级的 Pod 的 主要障碍。所以我们可以是使用Linux 的 IPVS 模块实现负载均衡和代理。

当我们创建Service之后,kuve-proxy会为Service创建VIP。kube-proxy 就会通过 Linux 的 IPVS 模块,为这个 IP 地址设置三个 IPVS 虚拟 主机,并设置这三个虚拟主机之间使用轮询模式 (rr) 来作为负载均衡策略。而这三个虚拟机对应的IP和端口正式对应的三个pod。

而相比于 iptables,IPVS 在内核中的实现其实也是基于 Netfilter 的 NAT 模式,所以在转 发这一层上,理论上 IPVS 并没有显著的性能提升。但是,IPVS 并不需要在宿主机上为每 个 Pod 设置 iptables 规则,而是把对这些“规则”的处理放到了内核态,从而极大地降低 了维护这些规则的代价。

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐