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，提高应用的可用性。

总结对比：