首先我们来了解一下，在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 规则，而是把对这些“规则”的处理放到了内核态，从而极大地降低 了维护这些规则的代价。