当前位置: 首页 > news >正文

Kubernetes相关的名词解释Service(15)

什么是Service?

在 Kubernetes 中,Service 是一种核心抽象资源,用于定义一组 Pod 的逻辑集合及其访问策略。它的主要目的是为应用程序提供稳定的网络端点(Endpoint),屏蔽 Pod 的动态性和生命周期变化(如扩缩容、重启或迁移),确保服务发现和负载均衡。

Service 的核心作用

  1. 服务发现
    Pod 是临时的、动态调度的,IP 地址可能随时变化。Service 通过固定的 ClusterIP(集群内虚拟 IP)或 DNS 名称,为客户端提供统一的访问入口,无需关心后端 Pod 的具体位置。

  2. 负载均衡
    将流量自动分发到一组健康的 Pod 上(通过 selector 匹配标签),避免单点故障。

  3. 解耦服务依赖
    客户端只需访问 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-servicedb-service)。

  • 通过 标签选择器(Selector) 关联不同的 Pod 组。

多个Service的示例场景

假设一个电商集群部署以下 Service:

Service 名称类型Selector 标签用途
frontend-svcClusterIPapp: frontend前端应用内部通信
order-svcNodePortapp: order订单服务外部访问
payment-svcClusterIPapp: payment支付服务内部通信
redis-svcHeadlessapp: redis无头服务,直接访问 Pod IP

这些 Service 可以:

  • 部署在 同一个 Namespace(如 default)。

  • 或分散在 不同 Namespace(如 team-a/frontend-svc 和 team-b/order-svc)。

底层数据流转

当创建一个 Service 时,各组件协作流程如下:

  1. 用户 通过 kubectl apply 提交 Service YAML 到 API Server。

  2. Service Controller 检测到新 Service,根据 Selector 查找匹配的 Pod,生成 Endpoints 对象。

  3. kube-proxy 监听到 Service/Endpoints 变化,更新本机 iptables/ipvs 规则。

  4. CoreDNS 新增 Service 的 DNS 记录。

  5. 流量访问

    • 集群内访问 my-svc:80 → DNS 解析为 ClusterIP → kube-proxy 按规则转发到后端 Pod。

相关文章:

  • 海事局发布《船舶智能监控系统技术指南(1.0)》,解读智驱力产品为何成为最佳选择!
  • Linux系统管理与编程13:基于CentOS7.x的LAMP环境部署
  • 高校如何通过打造数字人生态实训室,实现教学改革
  • Java 排序梳理 sort
  • 判断链表是否为环(Java版本自己用)
  • 远程服务器的mysql连接不上,问题出在哪里
  • 高尔夫球规则及打法·棒球1号位
  • aws服务(四)文件存储服务S3 介绍使用代码集成
  • 2024年TETCI SCI2区:增强差分进化麻雀搜索算法DSSADE,深度解析+性能实测
  • 安恒Web安全面试题
  • OpenCV第5课 图像的基本操作
  • 【LaTeX】图片大小调整和并排放置
  • 高品质性价比之王-特伦斯便携钢琴V10
  • Wasm Client SDK线上优化
  • word显示段落标记符(¶)而不是回车符
  • 【Linux内核设计与实现】第三章——进程管理01
  • 如何动态调整Python爬虫的Request请求延迟
  • 第 5 篇:初试牛刀 - 简单的预测方法
  • lmgrd web api调用
  • 《作用域大冒险:从闭包到内存泄漏的终极探索》
  • 私和人命:清代四川南部县谢相荣投河溺毙一案
  • 世界读书日丨上图东馆开启残疾人无障碍文化服务
  • 中国戏剧奖梅花奖终评启动在即,17场演出公益票将发售
  • 史蒂夫·麦奎因透露罹患前列腺癌,呼吁同胞莫受困于男性气概
  • 世界读书日|全城书香,上海“全民阅读”正在进行时
  • 重点并不在于设计更聪明的机器,而在于开发宇宙技术的多样性