云其它

关注公众号 jb51net

关闭
首页 > 网站技巧 > 服务器 > 云和虚拟化 > 云其它 > Kubernetes中的service

Kubernetes中的service使用及说明

作者：火星MARK

Kubernetes Service通过固定IP和端口实现Pod的负载均衡和服务发现,解决动态IP问题,支持ClusterIP、NodePort、LoadBalancer等五种类型,适用于集群内通信、对外暴露及访问外部服务,结合Endpoints和负载均衡策略确保服务稳定性

在 Kubernetes（K8s）生态中，Service 是核心资源之一，其核心作用是解决 Pod 的动态性问题 —— 通过为一组功能相同的 Pod 提供一个固定的访问入口（IP 和端口），实现对 Pod 的负载均衡和服务发现，屏蔽 Pod 频繁创建、销毁、IP 变化带来的访问波动。

一、Service 的核心价值：为何需要 Service？

Pod 是 K8s 中最小的部署单元，但存在天然的 “不稳定性”：

Service 正是为解决这些问题而生，其核心价值可概括为三点：

  1. 固定访问入口：Service 创建后会分配一个集群内固定的虚拟 IP（ClusterIP） 和端口，客户端只需访问该 IP:Port，无需关注后端 Pod 的具体 IP；
  2. Pod 负载均衡：Service 会自动将请求分发到后端健康的 Pod 上（默认轮询策略），实现流量分摊；
  3. 服务发现：结合 K8s 的 DNS 组件（如 CoreDNS），Service 可通过 “服务名” 被集群内其他 Pod 访问（如 http://<service-name>.<namespace>.svc.cluster.local），无需硬编码 IP。

二、Service 的工作原理：流量如何流转？

Service 的实现依赖 kube-proxy（每个节点上运行的网络代理组件）和 iptables/IPVS（Linux 内核的流量转发机制），核心流程如下：

  1. Service 创建：用户通过 YAML/CLI 创建 Service 后，K8s 控制器会为其分配 ClusterIP（仅集群内可见），并关联后端 Pod（通过 selector 匹配 Pod 标签）；
  2. kube-proxy 同步规则：每个节点的 kube-proxy 会监听 K8s API，实时同步 Service 和 Pod 的信息，并在节点内核中配置 iptables/IPVS 规则；
  3. 流量转发：当客户端（如集群内其他 Pod）访问 Service 的 ClusterIP:Port 时，请求会被节点内核的 iptables/IPVS 规则拦截，转发到后端任意一个健康的 Pod 的 IP:Port；
  4. 健康检查：Service 依赖 Pod 的 就绪探针（Readiness Probe） 判断 Pod 是否可用 —— 若 Pod 未通过就绪探针，会被从 Service 的后端列表中移除，不再接收流量。

三、Service 的核心组成：YAML 配置解析

Service 的配置通过 YAML 文件定义，核心字段如下（以最常见的 ClusterIP 类型为例）：

apiVersion: v1  # Service 属于 v1 版本 API
kind: Service   # 资源类型为 Service
metadata:
  name: my-service  # Service 名称（集群内 DNS 解析的核心标识）
  namespace: default  # 所属命名空间（默认 default，不同命名空间的 Service 需加命名空间访问）
spec:
  type: ClusterIP  # Service 类型（核心字段，决定访问范围）
  selector:        # 标签选择器：匹配后端 Pod 的标签（关键！Service 仅转发匹配 Pod 的流量）
    app: my-app    # 假设后端 Pod 有标签 app=my-app
  ports:           # 端口映射规则（可配置多个 port）
  - name: http     # 端口名称（可选，用于区分多个端口）
    port: 80       # Service 对外暴露的端口（客户端访问的端口）
    targetPort: 8080  # 后端 Pod 实际提供服务的端口（需与 Pod 容器的端口一致）
    protocol: TCP  # 协议（默认 TCP，支持 UDP、SCTP）
  sessionAffinity: None  # 会话亲和性（默认 None，可选 ClientIP：同一客户端请求转发到同一 Pod）

关键字段说明：

ports.port vs targetPort：

四、Service 的 5 种核心类型

Service 的 type 字段决定了其访问范围和暴露方式，K8s 支持 5 种常见类型，适用于不同场景：

类型核心特点适用场景
ClusterIP仅集群内可见的虚拟 IP，无法从集群外访问集群内服务间通信（如后端 API 给前端提供服务）
NodePort在每个节点上开放一个静态端口，通过 节点IP:NodePort 访问 Service开发 / 测试环境：快速从集群外访问服务
LoadBalancer借助云厂商 LB（如 AWS ELB、阿里云 SLB），自动分配公网 IP，转发流量到 NodePort生产环境：公网暴露服务（需云厂商支持）
ExternalName不关联 Pod，直接将 Service 映射到集群外的域名（如 xxx.com）访问集群外服务（如数据库、第三方 API）
Headless无 ClusterIP，通过 DNS 直接返回后端 Pod 的 IP 列表（不做负载均衡）需自行处理负载均衡或需直接访问 Pod 的场景

各类型详解与配置示例

1. ClusterIP（默认类型）

2. NodePort

配置示例：

spec:
  type: NodePort
  ports:
  - port: 80        # Service 内部端口
    targetPort: 8080 # Pod 端口
    nodePort: 30080  # 手动指定 NodePort（可选，不指定则自动分配）

3. LoadBalancer

配置示例：

spec:
  type: LoadBalancer
  ports:
  - port: 80
    targetPort: 8080
  loadBalancerIP: 1.2.3.4  # 可选，指定云 LB 的静态公网 IP（需云厂商支持）

4. ExternalName

配置示例（访问集群外的 MySQL 服务）：

spec:
  type: ExternalName
  externalName: db.example.com  # 集群外服务的域名
  ports:
  - port: 3306  # 外部服务的端口

5. Headless Service（无头服务）

spec:
  type: ClusterIP  # 关键：将 clusterIP 设为 None，即 Headless
  clusterIP: None
  selector:
    app: my-app
  ports:
  - port: 80
    targetPort: 8080

适用场景：

五、Service 与 Endpoints 的关系

Endpoints 是 K8s 中的另一个核心资源，用于存储 Service 后端的 “实际访问地址”（IP:Port 列表）。两者的关系是：

手动关联 Endpoints 示例（访问集群外服务）

创建无 selector 的 Service：

apiVersion: v1
kind: Service
metadata:
  name: external-service
spec:
  ports:
  - port: 80
    targetPort: 80

手动创建同名 Endpoints，关联集群外服务的 IP:Port：

apiVersion: v1
kind: Endpoints
metadata:
  name: external-service  # 必须与 Service 同名，才能关联
subsets:
- addresses:
  - ip: 192.168.1.100  # 集群外服务的 IP
  ports:
  - port: 80            # 集群外服务的端口

集群内 Pod 访问 external-service.default.svc.cluster.local:80，流量会转发到 192.168.1.100:80。

六、Service 的负载均衡策略

Service 的负载均衡由 kube-proxy 实现，kube-proxy 支持两种模式（通过 --proxy-mode 配置），对应不同的负载均衡策略：

1. iptables 模式（默认）

优缺点：

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

负载均衡策略：支持多种策略（可通过 Service 的 externalTrafficPolicy 或 internalTrafficPolicy 配置）：

优缺点：

七、Service 的常见问题与最佳实践

1. 常见问题

Service 访问不通？

NodePort 端口冲突？

2. 最佳实践

八、总结

Service 是 K8s 中连接 “动态 Pod” 与 “稳定访问” 的核心桥梁，其核心能力是固定入口、负载均衡、服务发现。

在实际使用中，需根据场景选择合适的 Service 类型（如集群内用 ClusterIP、公网暴露用 LoadBalancer、访问外部服务用 ExternalName），并结合 Endpoints、iptables/IPVS 等组件理解流量转发逻辑，确保服务的稳定访问。

以上为个人经验，希望能给大家一个参考，也希望大家多多支持脚本之家。

您可能感兴趣的文章:
阅读全文