Kubernetes相关的名词解释Service(15)
什么是Service?
在 Kubernetes 中,Service 是一种核心抽象资源,用于定义一组 Pod 的逻辑集合及其访问策略。它的主要目的是为应用程序提供稳定的网络端点(Endpoint),屏蔽 Pod 的动态性和生命周期变化(如扩缩容、重启或迁移),确保服务发现和负载均衡。
Service 的核心作用
-
服务发现
Pod 是临时的、动态调度的,IP 地址可能随时变化。Service 通过固定的 ClusterIP(集群内虚拟 IP)或 DNS 名称,为客户端提供统一的访问入口,无需关心后端 Pod 的具体位置。 -
负载均衡
将流量自动分发到一组健康的 Pod 上(通过selector
匹配标签),避免单点故障。 -
解耦服务依赖
客户端只需访问 Service,无需直接感知 Pod 的变化。
Service 的类型
Kubernetes 支持多种 Service 类型,适应不同场景:
类型 | 作用范围 | 典型用途 |
---|---|---|
ClusterIP | 集群内部(默认) | 内部服务通信,如微服务间调用 |
NodePort | 暴露到节点端口 | 开发测试或通过节点 IP 访问服务 |
LoadBalancer | 云提供商负载均衡器 | 公有云环境暴露服务到外网(如 AWS ELB) |
ExternalName | 外部服务别名 | 将服务映射到集群外部的 DNS(如数据库) |
Service 与 Pod的关系
一个 Service 可以关联多个 Pod,这些 Pod 通常通过 标签(Label) 被 Service 的 selector 选中,无论这些 Pod 分布在哪个 Node 上。
例如:一个名为 web-service 的 Service 可以关联运行在 NodeA、NodeB、NodeC 上的所有带有 app: web 标签的 Pod。
Service 与 Node 的关系
一个 Node 上可以运行多个 Pod,这些 Pod 可能属于 不同的 Service。
例如:NodeA 上可能同时运行:
属于 web-service 的 Pod(标签 app: web)
属于 db-service 的 Pod(标签 app: db)
Service 的 Pod 必然跨 Node(如果集群有多个 Node),这是 Kubernetes 设计的高可用特性:Service 的后端 Pod 会被自动分布在多个 Node 上(除非显式限制),避免单点故障。
总的来看Service与pod和node的关系如下表:
场景 | 是否可能 | 说明 |
---|---|---|
一个 Service 包含多个 Pod 在同一个 Node 上 | ✅ | 常见于测试环境或小规模集群 |
一个 Service 包含跨多个 Node 的 Pod | ✅ | 生产环境常态,保证高可用 |
一个 Node 运行多个属于同一 Service 的 Pod | ✅ | 需显式配置(如多副本 Deployment) |
一个 Node 运行多个属于不同 Service 的 Pod | ✅ | 默认场景,无冲突 |
示例拓扑:
假设一个 3 Node 集群运行以下资源:
-
ServiceA
-
selector: app=frontend
-
关联 Pod:
Pod1
(Node1)、Pod2
(Node2)、Pod3
(Node3)
-
-
ServiceB
-
selector: app=backend
-
关联 Pod:
Pod4
(Node1)、Pod5
(Node2)
-
此时:
-
Node1 上运行:
Pod1
(ServiceA)、Pod4
(ServiceB) -
ServiceA 的 Pod 跨所有 3 个 Node
Service 与Kubernetes 中内置组件、接口和控制器的关系
Kubernetes 中 Service 作为核心抽象资源,其生命周期、功能实现和运维管理依赖于多个内置组件、接口和控制器。
Kubernetes 通过 控制平面组件(API Server、Controller Manager)、数据平面代理(kube-proxy)、扩展接口(DNS、CNI)协同管理 Service,使其成为集群内服务发现与负载均衡的核心枢纽。对于复杂场景,可通过 Operator 或服务网格进一步扩展能力。
一个集群可以有多个service吗?
一个 Kubernetes 集群中可以存在多个 Service,这是 Kubernetes 设计中的基本特性,也是实际场景中的常见需求。
-
每个 Service 是独立的逻辑资源,可以同时存在多个 Service,彼此互不干扰。
-
典型场景:
-
一个微服务架构中,每个后端组件(如前端、订单服务、支付服务)都有自己的 Service。
-
同一应用的不同环境(如开发、测试、生产)可能通过不同 Namespace 隔离,每个 Namespace 内可部署同名 Service。
-
Kubernetes 集群中运行多个 Service 是标准实践,无论是微服务架构还是多租户场景,都依赖 Service 的隔离和复用能力。通过 Namespace、标签选择器和合理的端口规划,可以轻松管理数百甚至数千个 Service。
多 Service 的共存方式
方式 1:通过 Namespace 隔离
-
不同 Namespace 中的 Service 可以同名(如
dev/nginx-svc
和prod/nginx-svc
)。 -
访问时需指定 Namespace(DNS 格式:
<service-name>.<namespace>.svc.cluster.local
)。
方式 2:同一 Namespace 内多 Service
-
直接定义多个不同名称的 Service(如
web-service
、db-service
)。 -
通过 标签选择器(Selector) 关联不同的 Pod 组。
多个Service的示例场景
假设一个电商集群部署以下 Service:
Service 名称 | 类型 | Selector 标签 | 用途 |
---|---|---|---|
frontend-svc | ClusterIP | app: frontend | 前端应用内部通信 |
order-svc | NodePort | app: order | 订单服务外部访问 |
payment-svc | ClusterIP | app: payment | 支付服务内部通信 |
redis-svc | Headless | app: redis | 无头服务,直接访问 Pod IP |
这些 Service 可以:
-
部署在 同一个 Namespace(如
default
)。 -
或分散在 不同 Namespace(如
team-a/frontend-svc
和team-b/order-svc
)。
底层数据流转
当创建一个 Service 时,各组件协作流程如下:
-
用户 通过
kubectl apply
提交 Service YAML 到 API Server。 -
Service Controller 检测到新 Service,根据 Selector 查找匹配的 Pod,生成 Endpoints 对象。
-
kube-proxy 监听到 Service/Endpoints 变化,更新本机 iptables/ipvs 规则。
-
CoreDNS 新增 Service 的 DNS 记录。
-
流量访问:
-
集群内访问
my-svc:80
→ DNS 解析为 ClusterIP → kube-proxy 按规则转发到后端 Pod。
-