K8s学习----Service

Chihiro1002

809人浏览 · 2025-10-07 10:30:00

Chihiro1002 · 2025-10-07 10:30:00 发布

在 Kubernetes 生态中，Service 是实现 Pod 网络访问与服务发现的核心资源。由于 Pod 作为 Kubernetes 最小调度单元，其生命周期动态变化且 IP 地址不固定，Service 通过抽象层解决了 “动态 Pod 如何被稳定访问” 的核心问题，确保集群内外部流量能可靠路由到目标 Pod。

一、Service 的核心定位与价值

Service 本质是 Kubernetes 集群内的 “网络访问入口”，通过标签选择器（Label Selector） 与一组具有相同功能的 Pod 关联，实现以下核心价值：

固定访问入口：为动态变化的 Pod 提供稳定的 ClusterIP（集群内部访问）或 NodePort/LoadBalancer（外部访问），避免 Pod 重建、调度导致的 IP 变更问题。
负载均衡：自动将请求分发到关联的多个 Pod，支持默认随机负载均衡策略，保障服务高可用。
服务发现：结合集群 DNS（如 CoreDNS），允许 Pod 通过 Service 名称访问服务，无需手动维护 Pod IP 列表。
解耦部署与访问：Deployment 负责 Pod 的创建与扩缩容，Service 负责流量路由，二者独立运维，降低架构复杂度。

二、Service 的核心类型与适用场景

介绍 3 种核心 Service 类型，每种类型对应不同的网络访问场景，其关键差异体现在 “访问范围” 与 “网络配置” 上：

1. ClusterIP：集群内部专用访问

定义：默认 Service 类型，仅在集群内部暴露服务，分配一个集群内唯一的虚拟 IP（ClusterIP），仅集群内 Pod 可通过该 IP 访问服务。
核心特点：
- 无外部网络暴露能力，保障内部服务安全性；
- 自动通过标签选择器关联 Pod，支持负载均衡；
- 需通过 kubectl exec 进入集群内 Pod 或借助 port-forward 本地转发才能外部访问。

实践示例：

yaml

apiVersion: v1
kind: Service
metadata:
  name: my-clusterip-service
spec:
  selector:  # 关联标签为 app: nginx 的 Pod
    app: nginx
  ports:
  - protocol: TCP
    port: 8000  # Service 暴露端口
    targetPort: 80  # Pod 实际监听端口
  type: ClusterIP  # 显式指定类型（默认可省略）

验证方式：在集群内 Pod 中执行 curl http://my-clusterip-service:8000，可访问到关联的 Nginx Pod 服务。

2. NodePort：集群外部基础访问

定义：在 ClusterIP 基础上，为集群内每个节点暴露一个静态端口（NodePort，默认范围 30000 - 32767），外部可通过 “节点 IP: NodePort” 访问服务。
核心特点：
- 本质是在每个节点上配置 iptables 规则，将 NodePort 端口的流量转发到 ClusterIP；
- 无需额外负载均衡组件，适合测试或小规模外部访问场景；
- 需确保外部客户端能访问到节点 IP（如节点有公网 IP 或处于同一局域网）。

实践示例：

yaml

apiVersion: v1
kind: Service
metadata:
  name: my-nodeport-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 8000  # Service 内部端口
    targetPort: 80  # Pod 端口
    nodePort: 31788  # 显式指定 NodePort（需在 30000-32767 范围内）
  type: NodePort

验证方式：外部客户端执行 curl http://<节点 IP>:31788（如 curl http://192.168.30.131:31788），可访问到 Nginx 服务。

3. Headless：无固定 IP 的服务发现

定义：特殊 Service 类型，不分配 ClusterIP，而是直接返回关联 Pod 的 IP 列表（通过 DNS 解析），需客户端自行处理负载均衡。
核心场景：
- 需直接访问 Pod 实例的场景（如 StatefulSet 有状态服务，需固定 Pod 网络标识）；
- 客户端需自定义负载均衡策略（如基于会话粘性的访问）。

实践示例：

yaml

apiVersion: v1
kind: Service
metadata:
  name: my-headless-service
spec:
  selector:
    app: nginx
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  clusterIP: None  # 关键配置，标识为 Headless Service

验证方式：在集群内 Pod 中执行 nslookup my-headless-service，DNS 会返回所有关联 Pod 的 IP 地址（如 172.16.245.19、172.16.245.20）。

三、Service 与 Ingress 的配合：HTTP/HTTPS 路由优化

Service 仅能实现 “端口级” 流量转发，而 Ingress 作为 Kubernetes ingress - nginx 控制器的资源，可基于域名、路径实现 “HTTP/HTTPS 级” 的精细化路由，二者配合可简化外部访问架构：

1.Ingress 作用：

基于域名路由（如 www.test.com 路由到 A 服务，api.test.com 路由到 B 服务）；
基于路径路由（如 www.test.com/api 路由到 API 服务，www.test.com/web 路由到 Web 服务）；
统一管理 SSL 证书，实现 HTTPS 终结。

2.实践示例

yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  ingressClassName: nginx  # 关联 ingress-nginx 控制器
  rules:
  - host: www.testingress.com  # 自定义域名
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: ingressservice  # 关联后端 Service
            port:
              number: 80

3.验证：

本地 hosts 文件添加 192.168.30.131 www.testingress.com，执行 curl http://www.testingress.com，Ingress 会将流量转发到关联的 Service 及后端 Pod。

四、Service 核心原理：iptables 与 IPVS

Kubernetes 通过节点上的 kube-proxy 组件实现 Service 流量转发，支持两种模式：

1.iptables 模式（默认）：

kube-proxy 监听 Service 和 Endpoints 变化，动态更新节点的 iptables 规则；
流量转发流程：外部流量 → 节点 NodePort/LoadBalancer IP → iptables 规则 → ClusterIP → Endpoints 中的 Pod IP；
特点：轻量、依赖 Linux 内核 netfilter，适合中小规模集群。

2.IPVS 模式（推荐大规模集群）：

基于 Linux IPVS 内核模块，以哈希表存储 Service 与 Pod 映射关系，转发效率更高；
支持更多负载均衡策略（如轮询、加权轮询、最少连接）；
启用方式：需在 kube-proxy 配置中指定 --proxy-mode=ipvs。

总结

Service 作为 Kubernetes 网络层的核心组件，通过 “抽象固定入口 + 动态 Pod 关联 + 负载均衡” 解决了容器化应用的访问难题。在实际应用中，需根据访问场景选择合适的 Service 类型：

集群内部访问：优先使用 ClusterIP；

小规模外部测试：使用 NodePort；

有状态服务或自定义负载均衡：使用 Headless；

HTTP/HTTPS 多域名 / 路径路由：搭配 Ingress 实现精细化管理。