服务

Service是将运行在一组Pods上的应用程序公开网络服务的抽象方法。

每个Pod都有自己的IP地址，但是在Deployment中，在同一时刻运行的Pod集合可能与之后运行该应用程序的Pod集合不同。如果一组Pod（称为“后端”）为集群内其他Pod（称为“前端”）提供功能，那么前端如何找出并跟踪要连接的IP地址，以便前端可以使用提供工作负载的后端部分？-- service

Service所针对的Pod集合通常是通过标签选择器来确定的。

定义Service

示例：
下面配置创建一个名称为"my-service"的Service对象，它会将请求代理到具有“app=MyApp”标签、TCP端口9376的Pod上。

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

Service会分配一个IP地址（集群IP，VIP），通过标签选择器的控制器不断扫描与其匹配的Pod，将其更新发布到Service的Endpoint对象。

没有标签选择器的Service

ExternalName Service是Service的特例，它没有选择算符，但是使用DNS名称。

当希望使用集群外部的服务时，可使用此方式。

示例：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
---
apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.0.2.42
    ports:
      - port: 9376

虚拟IP和Service代理

在集群中，每个Node运行一个kube-proxy进程。kube-proxy负责为Service实现了一种VIP（虚拟IP）形式。

userspace代理模式

用户空间代理模式下kube-proxy会监视Service对象和Endpoint对象的添加和移除操作。对每个Service，它会再本地Node上打开一个端口（随机选择）。任何连接到“代理端口”的请求，都会被代理到Service的后端Pods中的某个。使用哪个后端Pod，是kube-proxy基于SessionAffinity来确认的。

最后它配置iptables规则，捕获到达该Service的clusterIP（虚拟IP）和Port的请求，并重定向到代理端口，代理端口再代理请求到后端Pod。

默认情况下，用户空间模式下的kube-proxy通过轮询算法选择后端。

![services-userspace-overview]](https://img2020.cnblogs.com/blog/2286432/202102/2286432-20210225140728527-1532153658.png)

iptables代理模式

这种模式，kube-proxy会监视Service对象和Endpoint对象的添加和移除。对每个Service，它会配置iptables规则，从而捕获到达该Service的clusterIP和端口的请求，进而将请求重定向到Service的一组后端中的某个Pod。对于每个Endpoint对象，它也会配置iptables规则，这个规则会选择一个后端组合。

默认的策略是，kube-proxy在iptables模式下随机选择一个后端。

使用iptables处理流量具有较低的系统开销，因为流量由Linux netfilter处理，而无需在用户空间和内核空间之间切换。这种方法也可能更可靠。

如果kube-proxy在iptables模式下运行，并且所选的第一个Pod没有响应，则连接失败。这与用户空间模式不同，在用户空间模式下的这种情况，kube-proxy将检测到与第一个Pod的连接已失败，并会自动使用其他后端Pod重试。

可以使用Pod就绪探测器验证后端Pod可以正常工作，以便iptables模式下的kube-proxy仅看到测试正常的后端。这样做意味着你避免将流量通过kube-proxy发送到已知已失败的Pod。

services-iptables-overview

IPVS代理模式

在ipvs模式下，kube-proxy监视service和Endpoint，调用netlink接口相应地创建IPVS规则，并定期将IPVS规则与Kubernetes服务和端点同步。该控制循环可确保IPVS状态与所需状态匹配。访问服务时，IPVS将流量定向到后端Pod之一。

IPVS代理模式类似于iptables模式的netfilter挂钩函数，但是使用哈希表作为基础数据结构，并且在内核空间中工作。这意味着，与iptables模式下的kube-proxy相比，IPVS模式下的kube-proxy重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他模式相比，IPVS模式还支持更高的网络流量吞吐量。

IPVS提供更多选项来平衡后端Pod的流量：

rr：轮询（Round-Robin）
lc：最少链接（Least Connection）
dh：目标地址哈希（Destination Hashing）
sh：源地址哈希（Source Hashing）
sed：最短预期延迟（Shortest Expected Delay）
nq：从不排队（Never Queue）

要在IPVS模式下运行kube-proxy，必须在启动kube-proxy之前使IPVS在节点上可用。

当kube-proxy以IPVS代理模式启动时，它将验证IPVS内核模块是否可用。如果未检测到IPVS内核模块，则kube-proxy将退回到以iptables代理模式运行。

services-ipvs-overview

无头服务

无头服务（Headless Service）并不会分配Cluster IP，kube-proxy不会处理它们，也不会为它们进行负载均衡和路由。DNS如何实现自动配置，依赖于Service是否定义了标签选择器。

通过指定ClusterIP（spec.clusterIP）的值为None来创建HeadlessService。

带有标签选择器的服务

定义了标签选择器的无头服务，Endpoint控制器在API中创建了Endpoints记录，并且修改DNS配置返回A记录，通过这个地址直接到达Service的后端Pod上。

无标签选择器的服务

对没有定义标签选择器的无头服务，Endpoint控制器不会创建Endpoints记录。然后DNS系统会查找和配置：

- 对于ExternalName类型的服务，查找其CNAME记录。
- 对所有其他类型的服务，查找与Service名称相同的任何Endpoints记录。