深入理解 K8s Service – wiki基地

作者： /

深入理解 Kubernetes Service：构建微服务通信的基石

在云原生时代，应用程序被拆解成一系列独立的微服务，这些服务以 Pod 的形式运行在 Kubernetes 集群中。Pod 是 Kubernetes 中最小的可部署单元，但它具有短暂性和动态性：Pod 可能会因为各种原因（如扩缩容、节点故障、滚动更新）被创建、销毁、迁移，其 IP 地址也会随之变化。

这就带来了一个核心问题：如何让其他服务（无论是集群内部的服务还是外部用户）能够稳定、可靠地访问这些动态变化的 Pod 集合？直接使用 Pod 的 IP 地址显然是不可行的，因为它们随时可能失效。

Kubernetes Service 正是为了解决这个问题而诞生的。它提供了一个稳定不变的抽象层，隐藏了后端 Pod 的复杂性和动态性，为 Pod 集合提供了一个单一的、稳定的网络入口（通常是 IP 地址和端口）。本文将带您深入理解 Kubernetes Service 的方方面面，从其核心概念到内部工作原理，再到各种类型的 Service 以及最佳实践。

1. Service 的核心作用与设计理念

Service 在 Kubernetes 中扮演着“服务发现”和“负载均衡”的关键角色。它的核心设计理念是提供一个稳定的抽象：

  1. 稳定访问入口： Service 提供一个固定的 IP 地址和端口，外部或内部的客户端只需要知道这个 Service 的地址，就可以访问其背后的 Pod 集合，而无需关心 Pod 的具体 IP 地址变化。
  2. 负载均衡： Service 能够将接收到的流量分发到其关联的多个 Pod 上，实现简单的负载均衡功能。这提高了应用的可用性和扩展性。
  3. 服务发现： Kubernetes 的 DNS 服务（如 kube-dns 或 CoreDNS）会为每个 Service 创建一个 DNS 条目，使得集群内部的服务可以通过 Service 名称来互相访问，而无需硬编码 IP 地址。
  4. 解耦： Service 将客户端与运行服务的具体 Pod 解耦。这意味着您可以独立地对 Pod 进行扩缩容、更新或替换，而不会中断依赖该服务的客户端连接。

简单来说，Service 就是一组 Pod 的逻辑集合，以及访问这组 Pod 的策略。

2. Service 的关键组成要素

理解 Service 需要掌握几个核心概念：

  • Labels 和 Selectors： 这是将 Service 与 Pod 关联起来的“魔法”。在定义 Service 时，您会指定一个 selector 字段，它包含一组标签键值对。Service 会根据这些标签选择匹配的 Pod，将流量转发给它们。同时，您创建的 Pod（通常由 Deployment、StatefulSet 等控制器管理）必须带有与 Service 的 selector 相匹配的标签，才能被 Service 发现和关联。这种基于标签的选择机制是 Kubernetes 灵活性的体现。
  • Pods： Service 的后端目标，是实际运行应用程序实例的地方。Pod 具有动态的 IP 地址和生命周期。
  • Endpoints： 这是一个由 Kubernetes 自动创建和管理的资源对象。它代表了 Service selector 当前匹配到的所有健康的、Ready 状态的 Pod 的 IP 地址和端口列表。当 Pod 被创建、销毁或其状态改变时，Kubernetes 控制平面会动态地更新 Endpoints 对象。Service 转发流量的实际目标就是 Endpoints 列表中的地址。
  • Service Spec： Service 的定义文件（通常是 YAML）包含了描述 Service 行为的各种配置，如 selector、ports（定义 Service 监听的端口和目标 Pod 的端口）、type（Service 的类型，决定了如何暴露服务）、clusterIP（如果指定或由 K8s 分配）、externalTrafficPolicy 等。

3. Service 的工作机制：Kube-Proxy 的作用

Service 的稳定访问入口和负载均衡功能并非凭空实现，其核心在于每个 Kubernetes Node 上运行的一个组件：kube-proxy。

kube-proxy 监听 Kubernetes API Server， watch（监听）Service 和 Endpoints 对象的创建、更新和删除事件。当这些对象发生变化时，kube-proxy 会在所在的 Node 上更新相应的网络规则，以确保通过 Service IP/Port 的流量能够被正确地路由和负载均衡到后端的 Pod IP/Port。

kube-proxy 支持多种代理模式，它们实现 Service 转发的方式不同：

  • Userspace Mode (已废弃): 最早的模式。kube-proxy 会在用户空间监听 Service 端口，当收到连接时，选择一个 Endpoints 中的 Pod，然后在用户空间建立到该 Pod 的连接并将流量转发过去。这种模式效率较低，且依赖 kube-proxy 进程自身。
  • Iptables Mode (默认模式): 当前最常用的模式。kube-proxy 不再监听端口，而是利用 Linux 内核的 iptables 规则。它根据 Service 和 Endpoints 对象生成大量的 iptables NAT 规则。当流量到达 Service IP 时，iptables 规则会将目标地址 DNAT（目标网络地址转换）成一个随机选择的 Endpoints IP，然后转发到该 Pod。这种模式效率比 Userspace Mode 高得多，直接在内核空间进行转发。但是，对于大量 Service 或 Endpoints 的集群，生成的 iptables 规则数量可能非常庞大，管理和更新规则的开销会变大。
  • IPVS Mode (推荐模式): 更高性能的模式。kube-proxy 利用 Linux 的 IP Virtual Server (IPVS) 负载均衡功能。与 iptables 类似，它也在内核空间进行转发，但 IPVS 专门为负载均衡设计，使用哈希表查找规则，其性能在规则数量多时优于 iptables。IPVS 支持更多的负载均衡算法（如轮询、最少连接、源地址哈希等，尽管 kube-proxy 目前主要使用轮询或最少连接）。IPVS Mode 需要 Node 支持 IPVS 模块。

在 iptables 或 IPVS 模式下，kube-proxy 负责维护 Service IP 到 Endpoints IP 的映射规则，并将流量负载均衡地转发到健康的 Pod 上。客户端访问 Service 时，请求首先会被路由到 Service 的 Cluster IP（或 Node IP/Load Balancer IP），然后经过 Node 上的 iptables/IPVS 规则处理，最终到达目标 Pod。

4. Service 的类型 (ServiceTypes)

Kubernetes Service 有四种主要类型，决定了 Service 如何被暴露给外部（或内部）网络：

  1. ClusterIP (默认类型):

    • 作用： 在集群内部 IP 上暴露 Service。Service 只在集群内部可达。
    • 工作方式： Kubernetes 分配一个稳定不变的 Cluster IP 地址给 Service。集群内的 Pod 或其他 Service 可以通过这个 Cluster IP 和 Service 端口访问后端 Pods。流量通过 kube-proxy 的规则转发。
    • 使用场景： 这是最常见的 Service 类型，用于集群内部服务间的通信。例如，前端服务访问后端 API 服务，或应用程序服务访问数据库服务。
    • 访问方式： 只能从集群内部访问（通过 Cluster IP 或 Service Name）。

  2. NodePort:

    • 作用： 在集群中每个 Node 的相同端口上暴露 Service。选择一个静态端口（NodePort），集群外部可以通过 <NodeIP>:<NodePort> 来访问 Service。
    • 工作方式： ClusterIP Service 的扩展。Kubernetes 会为 Service 分配一个 Cluster IP，并且在每个 Node 上打开一个静态端口（NodePort，默认范围 30000-32767，可通过 kube-apiserver 配置）。所有发送到任意 Node IP 的该 NodePort 的流量都会被转发到 Service 的 Cluster IP，然后通过 kube-proxy 的规则进一步负载均衡到后端 Pods。
    • 使用场景： 一种简单的方式来暴露服务到集群外部，常用于开发、测试环境或需要物理机直接访问的场景。
    • 缺点：
      • 每个 Node 都会打开这个端口，增加了集群的攻击面。
      • NodePort 的范围有限，容易冲突。
      • 客户端需要知道所有 Node 的 IP 地址（尽管通常只需要一个）。
      • 如果 Node 故障或 IP 改变，访问路径也会受到影响。
    • 访问方式： <NodeIP>:<NodePort> 从集群外部或内部访问。

  3. LoadBalancer:

    • 作用： 使用云提供商的负载均衡器来暴露 Service。
    • 工作方式： NodePort Service 的扩展。Kubernetes 会在创建 NodePort Service 的基础上，请求底层云提供商（如 AWS、GCE、Azure、阿里云、腾讯云等）创建一个外部负载均衡器。这个负载均衡器会获得一个外部 IP 地址，并将流量转发到集群 Node 的 NodePort 上。最终，流量通过 kube-proxy 规则到达后端 Pods。
    • 使用场景： 生产环境中将服务暴露到公网或私有网络，提供高可用和可扩展的访问入口。
    • 特点： 外部 IP 由云提供商分配和管理，通常需要付费。不同云提供商实现的负载均衡器功能和配置可能有所不同（如是否支持会话保持、SSL 卸载等）。
    • 访问方式： <External-Load-Balancer-IP>:<Service-Port> 从外部访问。

  4. ExternalName:

    • 作用： 将 Service 映射到外部服务的 DNS 名称，而不是通过代理转发流量。
    • 工作方式： 这种 Service 没有 selector 和后端 Pods，也没有 Cluster IP。它通过 externalName 字段指定一个外部 DNS 名称。当集群内部的客户端通过 Service 名称访问该 Service 时，Kubernetes 的 DNS 服务会返回一个 CNAME 记录，指向 externalName 指定的外部 DNS 名称。客户端会直接连接到该外部地址，流量不经过 kube-proxy 代理。
    • 使用场景： 在集群内部需要以统一的方式引用外部服务（如外部数据库、第三方 API），而无需关心其 IP 地址或端口，只需知道其 DNS 名称。
    • 访问方式： 只能从集群内部通过 Service 名称访问，本质上是 DNS 重定向。

选择哪种 Service 类型取决于您的需求：是集群内部通信、简单的外部暴露，还是需要云提供商的高级负载均衡功能，或者是引用外部服务。

5. Service 发现：如何找到 Service？

正如前面提到的，Service 的一个重要功能是服务发现。集群内部的 Pod 如何找到并连接到其他 Service？

  • DNS (推荐): 这是最常用和推荐的方式。Kubernetes 集群通常运行一个集群 DNS 服务（如 CoreDNS）。当您创建一个 Service 时，DNS 服务会自动为其创建一个 DNS 记录。

    • 对于 ClusterIP、NodePort、LoadBalancer 类型的 Service，记录格式通常是 <service-name>.<namespace>.svc.cluster.local。例如，在一个名为 default 的 namespace 中有一个名为 my-backend 的 Service，其 DNS 名称就是 my-backend.default.svc.cluster.local。在同一个 namespace 中，Pod 可以直接通过 Service 名称 my-backend 访问。在不同 namespace 中，需要使用完整名称 my-backend.default。
    • 对于 Headless Service (见下文)，DNS 记录会返回所有后端 Pod 的 IP 地址列表。
      Pod 在启动时，其 /etc/resolv.conf 文件会被 Kubelet 配置，使其使用集群 DNS 作为其名称服务器，并设置适当的搜索路径，方便 Pod 通过 Service 名称进行查找。

  • 环境变量 (不推荐用于新应用): Kubelet 会在每个 Pod 启动时，为其注入当前 namespace 中所有 Service 的环境变量。例如，对于一个名为 REDIS-MASTER 的 Service，可能会注入 REDIS_MASTER_SERVICE_HOST 和 REDIS_MASTER_SERVICE_PORT 等环境变量。这种方式的问题在于，Pod 启动时注入的环境变量是当时 Service 的快照；如果在 Pod 运行期间 Service 发生变化（例如 IP 或端口改变，尽管 Service IP 不变但理论上有这种可能，或 Service 被删除重建），Pod 中的环境变量不会更新。因此，新的应用应优先使用 DNS 进行服务发现。

6. 高级话题与相关概念

  • Headless Service (无头 Service):
    • 通过设置 service.spec.clusterIP: None 创建。
    • 它不像普通 Service 那样拥有一个稳定的 Cluster IP。
    • Kubernetes DNS 对于 Headless Service 的处理方式有所不同：它不会创建指向 Service IP 的 A 记录，而是为 Service 创建一个 A 记录，该记录直接返回其所有健康的、Ready 状态的后端 Pod 的 IP 地址列表。
    • 使用场景：
      • 需要客户端直接连接到 Pod 的情况，例如 StatefulSets 管理的有状态应用（每个副本需要知道彼此的 IP）。
      • 需要自定义服务发现机制（例如，Consul 或 ZooKeeper）来管理 Pod 地址，Headless Service 提供了 Pod IP 列表作为这些机制的基础。
      • 用于某些特定的网络应用模式，如点对点通信。
  • EndpointSlices (Endpoint 切片):
    • Kubernetes 1.17+ 版本引入的更高效处理大量 Endpoints 的机制。
    • 传统的 Endpoints 对象会将一个 Service 的所有 Endpoints (Pod IP:Port 列表) 存储在一个单一的对象中。对于具有成百上千个 Pod 的 Service，这个 Endpoints 对象会变得非常庞大，给 API Server、etcd 和 kube-proxy 带来压力。
    • EndpointSlices 将一个 Service 的 Endpoints 列表分割成多个更小的 EndpointSlice 对象，每个对象包含有限数量的 Endpoints（通常默认为 100）。
    • kube-proxy (尤其是 IPVS 模式) 和其他消费者可以更有效地处理这些更小的对象，降低了 watch 和更新的开销，提高了 API Server 和 etcd 的性能，并减少了 kube-proxy 在更新规则时的延迟。
    • 对于大多数用户而言，这是一个后端优化，感知不强，但对于大规模集群非常重要。
  • Session Affinity (会话亲和性):
    • 通过设置 service.spec.sessionAffinity: ClientIP 可以启用。
    • 启用后，来自同一个客户端 IP 的所有请求都会被路由到同一个后端 Pod。
    • 默认的会话亲和性是基于客户端 IP 地址的，持续时间可以通过 service.spec.sessionAffinityConfig.clientIP.timeoutSeconds 配置。
    • 需要注意：如果多个客户端共享同一个出口 IP（例如，通过 NAT），它们可能会被路由到同一个 Pod。这可能不适用于所有场景。
  • External Traffic Policy (service.spec.externalTrafficPolicy):
    • 主要用于 NodePort 和 LoadBalancer 类型的 Service，控制外部流量到达 Node 后如何转发到后端 Pods。
    • Cluster (默认): 流量会通过 kube-proxy 负载均衡到集群中所有 Node 上的 Service 后端 Pods。这可能导致额外的网络跳跃（如果流量到达的 Node 上没有该 Service 的后端 Pod），但可以确保负载均衡更均匀。
    • Local: 流量只会被转发到当前 Node 上运行的 Service 后端 Pods。如果流量到达的 Node 上没有健康的后端 Pod，流量会被丢弃。这保留了客户端源 IP 地址（kube-proxy 不进行两次 NAT），对于需要源 IP 的场景很有用，但也可能导致负载不均（如果流量只集中在部分 Node）。
  • Ingress 和 Gateway API:
    • 这些是比 Service 更高层次的抽象，用于管理外部对集群内 Service 的访问，特别是 HTTP/HTTPS 流量。
    • Ingress 或 Gateway 通常作为边缘路由器，接收外部请求，然后根据规则（如主机名、路径）将请求路由到指定的 ClusterIP Service。
    • 它们提供了更丰富的功能，如基于名称的虚拟主机、TLS 终止、路径路由、身份认证等，通常需要部署 Ingress Controller (如 Nginx Ingress, Traefik, Envoy) 或 Gateway Controller 来实现。Service 仍然是 Ingress/Gateway 的最终目标。

7. 创建和管理 Service

创建 Service 通常通过 YAML 文件定义，然后使用 kubectl apply -f <service-yaml-file> 命令应用。

一个简单的 ClusterIP Service 示例：

yaml
apiVersion: v1
kind: Service
metadata:
name: my-app-service
namespace: default # 命名空间
spec:
selector:
app: my-app # 选择带有 app=my-app 标签的 Pod
ports:
- protocol: TCP
port: 80 # Service 监听的端口
targetPort: 8080 # 后端 Pod 容器监听的端口
type: ClusterIP # Service 类型

这个 Service 会找到所有在 default 命名空间中带有 app: my-app 标签的 Pod，并在集群内部为其分配一个 Cluster IP，监听 80 端口，将流量转发到这些 Pod 的 8080 端口。

您可以使用 kubectl get service <service-name> 查看 Service 信息，kubectl describe service <service-name> 查看详细信息，包括其 Cluster IP 和 Endpoints。

8. 最佳实践和注意事项

  • 清晰的标签策略： 使用有意义且一致的标签是 Service 正确关联 Pod 的基础。
  • 选择合适的 Service 类型： 默认使用 ClusterIP。只有在确实需要从外部直接访问时，才考虑 NodePort 或 LoadBalancer。对于生产环境的外部访问，LoadBalancer 通常是首选。
  • 利用 DNS 进行服务发现： 在应用代码中，通过 Service 名称 (<service-name>.<namespace>) 或简称 (<service-name> 在同命名空间内) 来访问其他服务，而不是硬编码 IP 地址。
  • 配置 Readiness 探测： Pod 的 Readiness 探测非常重要。只有处于 Ready 状态的 Pod 才会出现在 Service 的 Endpoints 列表中，从而接收流量。这确保了 Service 只将流量转发到健康的、能够响应请求的 Pod。
  • 考虑 External Traffic Policy： 根据是否需要保留客户端源 IP 或确保负载均衡的均匀性，为 NodePort/LoadBalancer Service 配置合适的 externalTrafficPolicy。
  • Headless Service 的特殊性： 理解 Headless Service 没有 Cluster IP 且 DNS 行为不同，只在需要直接访问 Pod 或自定义服务发现时使用。
  • 资源限制： 对于大规模集群，考虑 IPVS 模式的 kube-proxy 和 EndpointSlices，以提高 Service 性能和可伸缩性。

9. 常见问题与故障排除

  • Service 没有关联到任何 Pods：
    • 检查 Service 的 selector 是否与 Pod 的 labels 完全匹配。标签是区分大小写且必须完全一致的。
    • 检查 Pod 是否正在运行并且处于 Ready 状态 (kubectl get pods -l app=my-app)。如果 Pod 没有 Ready，检查其日志和事件，确保 Readiness 探测正常工作。
    • 使用 kubectl describe service <service-name> 查看 Service 的详细信息，特别是 Endpoints 字段，看是否有 Pod IP 列表。
  • 无法通过 ClusterIP 访问 Service：
    • 确认客户端 Pod 与 Service 在同一个集群内部。
    • 检查客户端 Pod 是否能解析 Service 的 DNS 名称 (ping <service-name>)。如果不能，检查集群 DNS 服务是否正常工作。
    • 检查 kube-proxy 在 Node 上的状态和日志，确保它没有错误。
    • 检查 Node 上的 iptables/IPVS 规则是否正确生成（高级排查）。
    • 检查是否存在 Network Policy 阻止了客户端 Pod 到 Service 或后端 Pod 的流量。
  • 无法通过 NodePort/LoadBalancer 访问 Service：
    • 检查 Service 的 type 是否正确设置为 NodePort 或 LoadBalancer。
    • 对于 NodePort，确认您使用的是正确的 <NodeIP>:<NodePort> 组合，并且 Node 上的防火墙没有阻止该端口。NodePort 的范围通常是 30000-32767。
    • 对于 LoadBalancer，检查云提供商控制台，确认负载均衡器已成功创建并分配了外部 IP。检查负载均衡器的安全组/防火墙规则是否允许入站流量。检查负载均衡器的后端健康检查是否正常。
    • 检查 Service 的 externalTrafficPolicy 设置，特别是 Local 模式下，流量可能只转发到特定 Node。
  • 会话亲和性不工作：
    • 确认 Service 的 sessionAffinity 已设置为 ClientIP。
    • 理解 ClientIP affinity 是基于客户端的源 IP。如果流量经过多层代理或 NAT，源 IP 可能会丢失或不是最终用户的真实 IP。
    • 如果客户端 Pod 数量少于 Service 后端 Pod 数量，某些 Pod 可能永远接收不到流量。

10. 总结

Kubernetes Service 是构建稳定、可扩展微服务架构不可或缺的核心组件。它通过提供一个稳定不变的抽象层，成功地隐藏了后端 Pod 的动态性，实现了服务的发现和负载均衡。

通过深入理解 Service 的核心概念（Labels, Selectors, Endpoints）、内部工作原理（kube-proxy, iptables/IPVS, EndpointSlices）以及不同 Service 类型的适用场景，您可以更有效地设计、部署和管理您的应用程序在 Kubernetes 中的通信方式。无论是简单的内部服务调用，还是复杂的外部流量接入，Service 都提供了一套灵活且强大的解决方案，为云原生应用的可靠运行奠定了坚实的基础。掌握 Service，就是掌握了 Kubernetes 网络通信的命脉。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部