K8S中Service详解（一）

Service介绍

在Kubernetes中，Service资源解决了Pod IP地址不固定的问题，提供了一种更稳定和可靠的服务访问方式。以下是Service的一些关键特性和工作原理：

Service的稳定性：由于Pod可能会因为故障、重启或扩容而获得新的IP地址，直接使用Pod的IP来访问服务是不可靠的。Service通过提供一个固定的虚拟IP（ClusterIP）作为访问入口，使得服务访问变得更加稳定。
Service的类型：Kubernetes支持不同类型的Service，包括ClusterIP、NodePort、LoadBalancer和ExternalName，每种类型适用于不同的访问场景：
- ClusterIP：为Service在集群内部提供一个固定的虚拟IP，只有集群内部的客户端可以访问此服务。
- NodePort ：在所有节点的特定端口上公开Service，使得外部可以通过<NodeIP>:<NodePort>访问服务。
- LoadBalancer：在NodePort的基础上，通过云服务商的负载均衡器对外提供服务，适用于公有云环境。
- ExternalName：将服务映射到外部服务的DNS名称，不通过kube-proxy进行代理。
Service的负载均衡：Service可以对关联的Pod进行轮询或随机的负载均衡，使得请求可以均匀地分发到各个Pod上。
Service的发现机制：Kubernetes中的Pod可以通过DNS或环境变量来发现Service。通过DNS，Pod可以通过Service的名称和命名空间来解析Service的ClusterIP。
Service和Pod的关系：Service通过标签选择器（label selector）与一组Pod关联。当Service创建后，kube-proxy或相关的网络插件会监控Pod的变化，并更新Service的后端列表（Endpoints。
Headless Service：一种特殊的Service，不分配ClusterIP，而是通过DNS返回Pod的IP列表，适用于需要直接访问每个Pod的场景，如StatefulSets。
Service的端口：Service可以定义一个或多个端口，将外部请求映射到Pod的特定端口上。端口分为Service端口（port）、Pod端口（targetPort）和NodePort（仅NodePort类型Service）

Service在很多情况下只是一个概念，真正起作用的其实是kube-proxy服务进程，每个Node节点上都运行着一个kube-proxy服务进程。当创建Service的时候会通过api-server向etcd写入创建的service的信息，而kube-proxy会基于监听的机制发现这种Service的变动，然后它会将最新的Service信息转换成对应的访问规则。

kube-proxy三种工作模式

1. Userspace 模式

工作原理：

kube-proxy 在用户空间中运行，为每个 Service 创建一个监听端口，将发向 ClusterIP 的请求通过 iptables 规则重定向到 kube-proxy 的监听端口，然后 kube-proxy 根据负载均衡算法选择一个后端 Pod，将流量转发到 Pod。

优点：

简单稳定：实现简单，适用于负载较低或要求不高的场景。
负载均衡算法灵活：支持不同的负载均衡算法，如轮询、随机等。
易于调试：由于运行在用户空间，问题较容易排查。

缺点：

性能较低：每个请求都需要从内核空间经过用户空间进行转发，导致性能开销大，尤其是在高流量环境下。
延迟较高：数据包需要在内核空间和用户空间之间来回拷贝，增加了延迟。
不能进行智能重试 ：无法像 iptables 和 ipvs 模式那样自动重试不可用的 Pod。

应用场景：

低负载环境：适用于流量较小的 Kubernetes 集群，或者不对性能要求极高的应用场景。
调试与开发：在开发和调试阶段使用，便于排查问题。

2. iptables 模式

工作原理：

kube-proxy 为每个 Service 后端的 Pod 创建对应的 iptables 规则，流量直接通过网络路由到相应的 Pod，而不经过 kube-proxy 进程本身。

优点：

性能较好 ：与 userspace 模式相比，避免了用户空间和内核空间之间的数据拷贝，提高了性能。
低延迟：直接修改内核中的路由规则，减少了处理过程中的开销，转发效率更高。
简单高效：不需要额外的代理进程，适合大规模集群。

缺点：

负载均衡策略简单：只能通过简单的轮询方式进行负载均衡，无法实现更复杂的负载均衡算法（如基于连接数或源 IP）。
重试机制缺失：如果选定的 Pod 不可用，流量会被丢弃，不会自动重试。
安全性问题：流量直接路由到 Pod，可能暴露给不受信任的网络，需要额外配置网络策略。

应用场景：

高性能需求的应用：对于需要较高性能且负载均衡需求较简单的应用非常适合，如微服务架构中的 HTTP 或 DNS 服务。
规模较大的集群 ：对于大规模集群，iptables 模式因其性能优势而被广泛使用。

3. ipvs 模式

工作原理：

kube-proxy 在内核空间使用 ipvs 进行负载均衡，监控 Pod 和 Service 的变化，并将相应的规则实时同步到 ipvs 中。

优点：

性能最佳 ：ipvs 在内核空间实现，避免了用户空间和内核空间的数据拷贝，提供极高的转发性能，尤其在高负载和大规模集群中表现优异。
丰富的负载均衡算法：支持多种负载均衡算法，包括轮询、最小连接、源 IP 哈希等，能够满足更多复杂的负载均衡需求。
会话保持：支持基于客户端 IP 或会话的会话保持，使得某些需要维持会话状态的应用（如 Web 应用）能够始终路由到同一 Pod。
健康检查：可以基于 Pod 的健康状态进行流量路由，只将流量发送到健康的 Pod 上，提升可用性。
SNAT 优化 ：优化源地址转换（SNAT），对 NodePort 或 LoadBalancer 类型的服务尤其有效。
直接路由：通过直接路由减少了网络地址转换（NAT）开销，进一步提高了性能。

缺点：

配置复杂 ：相较于 iptables，ipvs 模式的配置和维护稍微复杂。
内核依赖 ：需要内核支持 ipvs，如果内核版本过低或未开启 ipvs 支持，无法使用此模式。

应用场景：

高性能要求的集群：适用于大规模、需要高吞吐量和低延迟的 Kubernetes 集群。
复杂的负载均衡需求：适合需要多种负载均衡算法和会话保持机制的场景，例如大规模 Web 应用、数据库负载均衡等。
高可用性要求：支持健康检查和流量路由到健康 Pod，提高应用的可用性。

总结对比：

模式	性能	配置复杂度	支持的负载均衡算法	会话保持	健康检查	重试机制	应用场景
Userspace	较差	简单	简单（轮询等）	不支持	不支持	支持	低负载环境，开发调试阶段
iptables	较好	中等	简单（轮询）	不支持	不支持	不支持	高性能、简单需求、大规模集群
ipvs	最好	较复杂	多种（轮询、最小连接等）	支持	支持	支持	高性能、高可用、大规模集群