k8s Service 介绍与入门 – wiki基地

作者： /

拥抱微服务：深入理解 Kubernetes Service 的核心奥秘

在现代软件架构中，微服务已成为主流。一个复杂的应用被拆分成多个小型、独立的、可部署的服务单元，各自运行在自己的进程中，并通过网络进行通信。这种架构带来了灵活性、可伸缩性和技术栈多样性等优势，但也引入了新的挑战：服务发现、负载均衡以及如何为这些动态变化的后端提供一个稳定一致的访问入口。

在 Kubernetes 这个强大的容器编排平台中，Pod 是最小的部署单元，它封装了一个或多个紧密相关的容器。然而，Pod 并不是永久性的资源。由于自动化伸缩、滚动更新、节点故障等原因，Pod 会频繁地被创建、销毁、替换，其 IP 地址也是动态分配且不稳定的。试想一下，如果一个前端 Pod 需要调用一个后端服务 Pod，它不能直接硬编码后端 Pod 的 IP 地址，因为这个 IP 随时可能失效。即使硬编码一组 IP，也无法实现负载均衡，并且当后端 Pod 数量变化时，前端也无法感知。这正是 Kubernetes Service 诞生的根本原因。

一、 Service 登场：解决 Pod 的“身份危机”

Kubernetes Service，直译为“服务”，是 Kubernetes 中一个核心的抽象层。它定义了访问一组 Pod 的逻辑策略。你可以将 Service 理解为一个稳定且抽象的入口，它隐藏了后端 Pod 集合的复杂性和动态性，为客户端（无论是集群内的其他 Pod 还是外部用户）提供一个固定、可靠的访问点。

核心理念： Service 通过标签选择器 (Label Selector) 来识别其背后的目标 Pod 集合。一旦 Service 定义了其选择器，它就会持续监控集群中匹配这些标签的 Pod。当客户端通过 Service 的稳定 IP 和端口访问时，Service 会负责将请求转发到其背后健康的、匹配选择器的 Pod 中的一个。这个转发过程通常包含了负载均衡的功能。

为什么需要 Service？

  1. Pod 的动态性与不稳定 IP： 如前所述，Pod 的 IP 地址不是固定的，生命周期短暂。直接访问 Pod IP 是不可靠的。
  2. 服务发现： 客户端无需知道后端 Pod 的具体 IP 地址列表，只需要知道 Service 的名称和端口即可。Kubernetes 提供了基于 DNS 的服务发现机制，使得客户端可以通过 Service 名称来找到它。
  3. 负载均衡： Service 可以将到其稳定 IP 的请求分发到多个后端 Pod 上，实现简单的轮询或其他负载均衡策略（取决于 kube-proxy 的实现模式）。
  4. 解耦： Service 将客户端与后端 Pod 集（Deployment, StatefulSet 等）的实际部署细节解耦。后端的 Pod 可以随时扩缩容、升级或替换，而客户端通过 Service 访问的接口保持不变。
  5. 网络策略： Service 可以与网络策略 (NetworkPolicy) 结合，实现更细粒度的网络访问控制。

简而言之，Service 是 Kubernetes 世界中连接“前端”（客户端）和“后端”（一组 Pod）的桥梁，它提供了一个高可用、可伸缩且易于发现的访问层。

二、 Service 的工作原理：标签、端点与 kube-proxy

理解 Service 的内部机制，有助于更好地利用和调试它。Service 的工作主要依赖于以下几个核心组件和概念：

  1. 标签选择器 (Label Selector): 这是 Service 识别后端 Pod 的“眼睛”。Service 的定义中必须包含一个 selector 字段，指定一组标签键值对。Service Controller（Kubernetes 控制平面的一部分）会不断查找集群中拥有所有这些标签的 Pod，并将它们关联到这个 Service。
    例如：一个 Service 定义 selector: app: my-app, tier: backend，它就会自动关联所有标签同时包含 app=my-app 和 tier=backend 的 Pod。

  2. Endpoints (端点): Service Controller 发现匹配标签选择器的 Pod 后，会创建一个同名的 Endpoint 对象。这个 Endpoint 对象本质上是一个列表，包含了所有与该 Service 关联的 Pod 的 IP 地址和端口号。Endpoint 对象是 Service 的“骨架”，它记录了 Service 后面实际可用的网络地址。Service 本身并没有网络接口，它依赖 Endpoints 对象来知道请求应该被转发到哪里。

  3. kube-proxy: 这是 Kubernetes 集群中运行在每个节点上的网络代理程序。它的核心任务是监听 Kubernetes API Server，获取 Service 和 Endpoint 对象的实时变化。基于这些信息，kube-proxy 会配置节点上的网络规则（通常使用 iptables 或 IPVS）来拦截发送到 Service ClusterIP 或 NodePort 的流量，并将这些流量转发到 Endpoint 对象中列出的某个 Pod IP 和端口上。

    • iptables 模式 (默认且历史悠久): kube-proxy 会在节点的 iptables 中创建大量的规则链。当流量到达 Service 的 ClusterIP/Port 时，iptables 规则会将其重定向到 Endpoint List 中的一个随机 Pod IP/Port。这种模式在 Endpoint 数量巨大时，iptables 规则链会非常庞大，可能影响性能。
    • IPVS 模式 (更现代，推荐): kube-proxy 使用 Linux 内核的 IP Virtual Server (IPVS) 功能。IPVS 专门用于高性能的负载均衡，它在内核态工作，查找转发规则的效率比 iptables 高得多，尤其适用于 Service 拥有大量后端 Pod 的场景。IPVS 支持更多负载均衡算法（如轮询、最小连接、哈希等），尽管默认通常还是使用轮询。

    无论是 iptables 还是 IPVS，kube-proxy 都确保了流向 Service IP 的流量能够被正确地转发到后端的 Pod 上，并实现了基本的负载均衡。

总结工作流程：

  1. 你定义并创建 Service 对象，其中包含一个标签选择器。
  2. Service Controller 监听 Pod 的变化，找到匹配选择器的 Pod。
  3. Service Controller 创建/更新与 Service 同名的 Endpoint 对象，记录匹配 Pod 的 IP 和端口。
  4. kube-proxy 运行在每个节点上，监听 Service 和 Endpoint 对象的变化。
  5. kube-proxy 根据 Service 和 Endpoint 信息，配置节点的网络转发规则 (iptables 或 IPVS)。
  6. 当客户端（集群内或外）访问 Service 的稳定 IP/Port 时，流量被节点的网络规则拦截。
  7. 网络规则根据 Endpoint 列表和负载均衡策略，将流量转发到 Service 后面的某个 Pod IP/Port。

一个例外：Headless Service

并非所有 Service 都需要分配一个稳定的 ClusterIP 并进行负载均衡。有时候，客户端（尤其是StatefulSet中的Pod）需要发现并直接连接到 Service 后面的所有 Pod，而不是通过一个统一的入口。对于这种情况，Kubernetes 提供了 Headless Service。

Headless Service 的定义与普通 Service 类似，但其 spec.clusterIP 字段被设置为 None。这意味着 Kubernetes 不会为它分配一个 ClusterIP，kube-proxy 也不会为它配置负载均衡规则。

对于 Headless Service，DNS 返回的不是 Service IP，而是后端所有匹配选择器的 Pod 的 IP 地址列表。客户端可以通过 DNS 查询获取这些 Pod IP，然后直接与它们建立连接。这对于有状态应用（如数据库集群）中需要对每个 Pod 进行精细控制和发现的场景非常有用。

三、 Service 的类型：对外暴露 Pod 的不同方式

Kubernetes Service 定义了四种主要的 type，它们决定了 Service 如何被集群内部或外部的网络访问。理解这些类型是入门 Kubernetes 网络访问的关键。

  1. ClusterIP (默认类型):

    • 功能： 为 Service 分配一个集群内部的稳定 IP 地址 (ClusterIP)。
    • 访问范围： 只能在 Kubernetes 集群内部通过 Service 的 ClusterIP 和端口访问。
    • 工作原理： kube-proxy 配置网络规则，将发往 ClusterIP:Port 的流量转发到后端 Pod 的 IP:targetPort。ClusterIP 只能在集群内部路由。
    • 用例： 集群内部服务之间的通信（例如，前端 Pod 访问后端 API Pod，或者后端 API Pod 访问数据库 Pod）。这是最常用的 Service 类型。
    • 示例:
      yaml
      apiVersion: v1
      kind: Service
      metadata:
      name: my-internal-service
      spec:
      selector:
      app: my-app
      tier: backend
      ports:
      - protocol: TCP
      port: 80 # Service端口
      targetPort: 8080 # Pod端口
      type: ClusterIP # 可以省略，因为是默认值
      这个 Service 在集群内部会被分配一个 IP（例如 10.96.0.10）。集群内的其他 Pod 可以通过 my-internal-service.default.svc.cluster.local (或简称 my-internal-service) 这个域名或其 ClusterIP 的 80 端口访问，流量会被转发到标签为 app=my-app, tier=backend 的 Pod 的 8080 端口。

  2. NodePort:

    • 功能： 在每个参与 Service 的节点上暴露一个静态端口 (NodePort)。
    • 访问范围： 可以通过集群中任何一个节点的 IP 地址和这个静态 NodePort 访问 Service。流量会被路由到 Service，然后转发到后端 Pod。
    • 工作原理： 在 ClusterIP 的基础上，kube-proxy 还会为每个节点配置额外的网络规则，将发往 NodeIP:NodePort 的流量重定向到 Service 的 ClusterIP:Port。通常，NodePort 的范围是 30000-32767（可配置）。
    • 用例： 简单地将一个服务暴露给集群外部访问，例如用于演示、测试或作为更复杂的外部访问方式（如 LoadBalancer 或 Ingress）的底层机制。
    • 局限性：
      • 端口范围有限，容易冲突。
      • 依赖于节点本身的 IP 地址，如果节点 IP 变化或节点宕机，访问会受影响。
      • 对于生产环境来说，通常不推荐直接使用 NodePort 提供外部访问，因为它缺乏高级的负载均衡、SSL 终止、基于路径的路由等功能。
    • 示例:
      yaml
      apiVersion: v1
      kind: Service
      metadata:
      name: my-nodeport-service
      spec:
      selector:
      app: my-web-app
      ports:
      - protocol: TCP
      port: 80 # Service端口
      targetPort: 80 # Pod端口
      nodePort: 30080 # 在每个节点上暴露的端口 (可选，不指定则自动分配)
      type: NodePort
      创建这个 Service 后，假设你的集群有两个节点，IP 分别是 192.168.1.10 和 192.168.1.11。你可以通过 192.168.1.10:30080 或 192.168.1.11:30080 访问这个服务，流量会被转发到标签为 app=my-web-app 的 Pod 的 80 端口。

  3. LoadBalancer:

    • 功能： 在 NodePort 的基础上，请求底层云服务提供商（如 AWS, GCE, Azure, 阿里云, 腾讯云等）创建一个外部负载均衡器。这个负载均衡器拥有一个外部可访问的 IP 地址。
    • 访问范围： 可以通过云服务商提供的外部负载均衡器的 IP 地址访问 Service。
    • 工作原理： Service Controller 检测到 type: LoadBalancer 后，会调用云服务商的 API 来创建相应的外部负载均衡资源。这个负载均衡器会自动将流量分发到集群节点的 NodePort 上，然后 NodePort 再将流量转发到 Service 的 ClusterIP，最后由 kube-proxy 转发到后端 Pod。
    • 用例： 在云环境中将服务直接暴露给外部互联网访问。这是在云上将应用对外发布的最标准方式之一。
    • 局限性： 严重依赖于特定的云提供商，并且通常会产生额外的费用。在本地或其他非云环境中，LoadBalancer 类型可能无法正常工作，除非有特定的负载均衡器插件或实现（如 MetalLB）。
    • 示例:
      yaml
      apiVersion: v1
      kind: Service
      metadata:
      name: my-loadbalancer-service
      spec:
      selector:
      app: my-internet-app
      ports:
      - protocol: TCP
      port: 80 # Service端口
      targetPort: 80 # Pod端口
      type: LoadBalancer
      创建后，Kubernetes 会与云提供商通信，分配一个外部 IP 地址给这个 Service。用户可以通过这个外部 IP 访问服务。kubectl get svc my-loadbalancer-service 命令会显示分配的 EXTERNAL-IP 地址。

  4. ExternalName:

    • 功能： 不为 Service 分配 ClusterIP，也不设置代理或负载均衡。它只返回一个外部 DNS 地址作为别名。
    • 访问范围： 重定向到指定的外部 DNS 名称。
    • 工作原理： 当客户端查询 ExternalName 类型的 Service 的 DNS 名称时，Kubernetes DNS (CoreDNS 或 kube-dns) 返回的是 Service 定义中 externalName 字段指定的值，而不是 ClusterIP 或 Pod IP 列表。客户端收到这个 CNAME 记录后，会向这个外部 DNS 名称发起连接。
    • 用例： 将集群内部对某个 Service 名称的请求重定向到集群外部的某个服务（例如，一个外部数据库、一个第三方 API）。这提供了一种在不修改应用代码的情况下，将流量从集群内导向外部资源的方法。
    • 局限性： 它不是一个代理或负载均衡器，只是一个 DNS CNAME 记录。
    • 示例:
      yaml
      apiVersion: v1
      kind: Service
      metadata:
      name: my-external-db
      spec:
      type: ExternalName
      externalName: mysql.example.com # 外部数据库的域名
      # selector 和 ports 字段被忽略，因为没有后端 Pod
      集群内的 Pod 如果尝试通过 my-external-db 访问服务，DNS 会解析到 mysql.example.com，然后客户端会直接连接到 mysql.example.com。

四、 创建和管理 Service 入门

创建 Service 通常通过 YAML 文件定义其规格，然后使用 kubectl apply -f <yaml-file> 命令提交到 Kubernetes 集群。

让我们以一个简单的 ClusterIP 类型的 Service 为例：

假设你有一个 Deployment，创建了一组带有 app: nginx 标签的 Pod，并且这些 Pod 在 80 端口提供服务。

1. 后端 Deployment (供参考，Service 需要的只是其 Pod 的标签):

“`yaml

nginx-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx # Service 将选择这个标签
template:
metadata:
labels:
app: nginx # Pod 的标签
spec:
containers:
– name: nginx
image: nginx:latest
ports:
– containerPort: 80 # Pod 内部暴露的端口
``
应用此 Deployment:kubectl apply -f nginx-deployment.yaml`

2. ClusterIP Service:

“`yaml

nginx-clusterip-service.yaml

apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
selector:
app: nginx # Service 将查找标签为 app=nginx 的 Pod
ports:
– protocol: TCP
port: 80 # Service 自身监听的端口 (集群内部访问 Service 时使用)
targetPort: 80 # 转发到后端 Pod 的端口 (这里的 80 对应上面 Pod 定义的 containerPort)
type: ClusterIP # 明确指定类型，或者不指定使用默认值
“`

应用此 Service: kubectl apply -f nginx-clusterip-service.yaml

查看 Service 状态:

bash
kubectl get service nginx-service
输出可能类似：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-service ClusterIP 10.105.10.201 <none> 80/TCP 1m
这里 CLUSTER-IP 就是 Service 在集群内部的稳定 IP。集群内的其他 Pod 可以通过这个 IP 或 Service 名称 nginx-service 访问。

查看 Service 关联的 Endpoints:

bash
kubectl get endpoints nginx-service
输出可能类似：
NAME ENDPOINTS AGE
nginx-service 10.1.0.5:80,10.1.0.6:80,10.1.0.7:80 1m
这列出了当前 Service 关联的所有后端 Pod 的 IP 地址和端口。kube-proxy 就是利用这个列表来转发流量的。

查看 Service 详情:

bash
kubectl describe service nginx-service
这个命令会提供更多信息，包括标签选择器、端点列表、事件等，对于调试非常有用。

3. NodePort Service 示例:

在上面的 nginx-clusterip-service.yaml 基础上，修改 type 为 NodePort：

“`yaml

nginx-nodeport-service.yaml

apiVersion: v1
kind: Service
metadata:
name: nginx-nodeport-service
spec:
selector:
app: nginx
ports:
– protocol: TCP
port: 80
targetPort: 80
nodePort: 30088 # 指定或让 K8s 自动分配一个 30000-32767 的端口
type: NodePort
``
应用此 Service:kubectl apply -f nginx-nodeport-service.yaml`

查看 NodePort Service 状态:

bash
kubectl get service nginx-nodeport-service
输出可能类似：
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
nginx-nodeport-service NodePort 10.105.20.301 <none> 80:30088/TCP 30s
注意 PORT(S) 字段显示了 80:30088/TCP，这表示 Service 内部端口是 80，它通过 NodePort 30088 暴露在每个节点上。现在你可以通过集群中任何一个节点的 IP 地址加上端口 30088 来访问你的 Nginx 服务。

删除 Service:

bash
kubectl delete service nginx-service
kubectl delete service nginx-nodeport-service

五、 Service 的高级配置与注意事项

  • targetPort vs port vs nodePort:

    • targetPort: Pod 内部容器真正监听的端口。Service 将流量转发到这个端口。
    • port: Service 自身在 ClusterIP 上监听的端口。集群内部客户端通过 <Service Name>:<port> 或 <ClusterIP>:<port> 访问。
    • nodePort: 当 type: NodePort 时，Kubernetes 在每个节点上打开的静态端口。外部客户端通过 <NodeIP>:<nodePort> 访问。

  • 命名端口 (Named Ports): 可以在 Pod 定义中给容器端口指定名称（例如 name: http）。在 Service 定义中引用 targetPort 时，可以使用这个名称代替数字端口号。这提高了可读性，特别是当一个 Pod 暴露多个端口时。

  • Session Affinity (会话亲和性): 默认情况下，Service 使用轮询进行负载均衡。你可以通过设置 service.spec.sessionAffinity: ClientIP 来启用基于客户端 IP 的会话亲和性，这意味着来自同一个客户端 IP 的所有请求都会被路由到同一个后端 Pod，直到该 Pod 终止或 Service 被删除。这对于需要维护用户会话状态的应用（如购物车）很有用。

  • publishNotReadyAddresses: 默认情况下，Service 只会将流量发送到 Ready 状态的 Pod。如果设置 service.spec.publishNotReadyAddresses: true，Service 关联的 Endpoint 对象会包含所有匹配选择器的 Pod 的地址，包括处于 NotReady 状态的 Pod。这通常用于 Headless Service，允许客户端发现并直接访问所有 Pod（包括那些可能正在启动或处于非健康状态的 Pod），适用于某些复杂的初始化或协调场景。

  • Service 与 DNS: Kubernetes 集群通常运行一个 DNS 服务（CoreDNS 或 kube-dns）。默认情况下，每个 Service 都会在集群 DNS 中注册一个 DNS A 记录，格式通常是 <service-name>.<namespace>.svc.cluster.local。在同一个命名空间内的 Pod 可以直接通过 <service-name> 访问；在不同命名空间可以通过 <service-name>.<namespace> 访问。Headless Service 的 DNS 行为有所不同，它返回的是 Pod IP 列表。

  • Pod Readiness Probes (就绪探针): Service 依赖于 Pod 的 Ready 状态来决定是否将流量转发给它。因此，为 Pod 配置正确的就绪探针 (Readiness Probe) 至关重要。如果 Pod 的就绪探针失败，它将被视为 NotReady，Service 将停止向其发送流量，从而确保 Service 总是将请求路由到健康的后端。

  • Ingress: 虽然 LoadBalancer 类型 Service 可以将服务暴露到外部，但它通常为每个服务分配一个独立的外部 IP，成本较高，且缺乏高级路由功能。在生产环境中，更常见的方式是使用 Ingress。Ingress 是一个 API 对象，它定义了从外部如何路由到集群内部 Services 的规则集合。Ingress Controller（如 Nginx Ingress, Traefik 等）根据这些规则实现反向代理和负载均衡，通常只需要一个外部 IP 即可为多个 Service 提供外部访问，并支持基于路径、域名的路由、SSL 终止等功能。Ingress 通常被认为是 Service 的“补充”，用于更复杂的外部访问场景。

六、 总结：Service 在 Kubernetes 网络中的地位

Kubernetes Service 是其网络模型的基石之一。它成功地解决了容器化应用中后端 Pod 动态性带来的挑战，通过一个稳定抽象层为客户端提供了可靠的服务发现、负载均衡和访问入口。

  • ClusterIP 用于集群内部服务间通信，是默认且最常用的类型。
  • NodePort 提供了一种简单的、基于节点 IP 的外部访问方式，适用于演示和测试。
  • LoadBalancer 集成了云服务商的外部负载均衡能力，是云上将服务对外发布的主要方式。
  • ExternalName 用于将内部流量重定向到外部 DNS 地址。
  • Headless Service 在不需要 ClusterIP 和负载均衡时使用，常用于有状态应用的服务发现。

理解 Service 的不同类型、工作原理（特别是与 Endpoints 和 kube-proxy 的关系）以及如何通过标签选择器关联 Pod，是掌握 Kubernetes 网络不可或缺的一部分。配合 Readiness Probe 确保后端健康，利用 Ingress 实现更复杂的外部访问，Service 共同构成了 Kubernetes 强大而灵活的网络体系，使得构建和管理大规模微服务应用成为可能。

通过本文的详细介绍与入门指导，相信你对 Kubernetes Service 已经有了较为全面的认识，并能够开始在你的 Kubernetes 环境中有效地使用和管理 Service，为你的应用提供稳定可靠的网络访问。

发表评论

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

滚动至顶部