K8s之Service、Endpoints、Pod三者关系

Service,Endpoints与Pod之间的关系与管理,
最新推荐文章于 2025-03-06 11:14:48 发布
原创 最新推荐文章于 2025-03-06 11:14:48 发布 · 614 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes #容器 #云原生

本文探讨了Service（服务）与Endpoints（端点）、Pod（容器）之间的关系，强调Service配置selector的重要性，以及自动关联内部Pod和服务与手动维护外部服务的区别。

上篇文章我们了解到Service是一个规则的集合，今天我们来看看这Service、Endpoints、Pod三者的关系

 对应实验环境我们可以看到Endpoints其实就是后端pod的IP地址，因为本机实验环境只有一个node节点，故pod的reolicas=1，只有1个Endpoints，实际上在生产环境中，EndPoints应该是一组 提供同类型服务的Pod 的端点合，在图中的Endpoints就是：10.1.20.100,10.1.20.101,20.1.20.102

 

注意：Service配置selector，endpoint controller才会自动创建对应的endpoint对象；否则，不会生成endpoint对象

自动关联体系内的pod服务

手动维护体系外的外部服务 

持续集成部署-k8s-服务发现-Service：Service、Endpoint、Pod之间的关系与原理
种一棵树最好的时间是十年前，其次是现在。
10-22 1577
Service、Endpoint 和 Pod 之间是一种非常紧密的关系，它们协同工作来实现 Kubernetes 中的服务发现和负载均衡功能。Service 提供了一个统一的逻辑入口，Endpoint 包含了具体的 Pod 的 IP 地址和端口信息，Pod 是服务提供者的最基本单位。这些组件之间的协同工作，使得 Kubernetes 用户更加方便地部署、管理和访问自己的应用程序。
【Kubernetes知识点】 解读 Service 和 EndpointSlice 之间的关系
StevenZeng学堂
09-30 1888
❤️ 摘要：在 Kubernetes 中，Service 和 EndpointSlice 是实现负载均衡和服务发现的重要组件。 EndpointSlice让Service更好地处理大量后端，并允许集群有效地更新其健康后端列表。本文将深入探讨它们之间的关系，并设计实验来验证这一关系。
带你深入学习k8s--(三) pod 管理
好久没说梦想的博客
04-25 1278
Pod是可以创建和管理Kubernetes计算的最小可部署单元，一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。 一个pod类似一个豌豆英，包含一个或多个容器 (通常是docker) ，多个容器间共享IPC、Network和UTC namespace。
K8s 中 Service、Endpoints、Pod 之间的关系
小单的博客专栏
12-22 8566
概念 Kubernetes 中的 Service，它定义了一组Pods的逻辑集合和一个用于访问它们的策略。一个 Service 的目标 Pod 集合通常是由Label Selector 来决定的。 Endpoints 是一组实际服务的端点集合。一个 Endpoint 是一个可被访问的服务端点，即一个状态为 running 的 pod 的可访问端点。一般 Pod 都不是一个独立存在，所以一组 Pod 的端点合在一起称为 EndPoints。只有被 Service Selector 匹配选中并且状态为 Run
K8s: Service对象以及与Pod之间的通信关系
Wang的专栏
04-20 2042
在用这种方式创建的时候，先把之前创建的 Service 删除。1 ）配置 Deployment 对象用来维护 Pod。这样就会创建2个pod, 之后，创建 Service。上面等价于通过 yaml 文件创建 Service。现在创建 svc-my-nginx.yaml 文件。新建 dep-my-nginx.yaml。可以看到，多了一个 deploment。2.2 基于yaml文件来处理。2 ） 定义 Service。通过 label 来查看。2 ）创建 Service。创建 Service。
k8s service endpoint
qq_36054969的博客
07-04 922
k8s service endpoint
k8s的service和endpoint
jjt_zaj的博客
01-11 7832
service： 在k8s中，pod之间是通信是一般通过service名称完成的 endpoint: pod和service之间的关联关系，是通过endpoint实现的。Endpoint Endpoints表示了一个Service对应的所有Pod副本的访问地址，而Endpoints Controller负责生成和维护所有Endpoints对象的控制器。它负责监听Service和对应的Pod副本的变化。 对于pod，endpoint是集群自动创建的，用于将service和pod关联起来；而对于外部服务（部署
自动化运维之k8s——Kubernetes集群部署、pod、service微服务、kubernetes网络通信
Zhaohui_Zhang的博客
03-02 8934
一、Kubernetes简介 1、Kubernetes简介 在Docker 作为高级容器引擎快速发展的同时，在Google内部，容器技术已经应用了很多年，Borg系统运行管理着成千上万的容器应用。 Kubernetes项目来源于Borg，可以说是集结了Borg设计思想的精华，并且吸收了Borg系统中的经验和教训。 Kubernetes对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。 Kubernetes的好处： (1)隐藏资源管理和错误处理，用户仅需要关
K8S—Pod详解
qq_64441401的博客
02-23 3252
Pod是kubernetes中最小的资源管理组件，Pod也是最小化运行容器化应用的资源对象。一个Pod代表着集群中运行的一个进程。kubernetes中其他大多数组件都是围绕着Pod来进行支撑和扩展Pod功能的，例如，用于管理Pod运行的StatefulSet和Deployment等控制器对象，用于暴露Pod应用的Service和Ingress对象，为Pod提供存储的PersistentVolume存储资源对象等。
Kubernetes组件_KubeProxy_Service找到Pod与DNS解析Service/Pod
毛毛的专栏
07-08 1710
KubeProxy_Service找到Pod与DNS服务发现
Kubernetes—Service、RC(deployment)与Pod之间的关系
weixin_44295677的博客
09-19 2264
Kubernetes—Service、RC(deployment)与Pod之间的关系
k8s-Service和endpoint
qinxue722的博客
08-01 1853
Service的IP保持不变(Headless Servcie除外，下⾯会单独讲)，保证了访问接⼝的稳定性，屏蔽了Pod的IP地址变化带来的影响，进⽽实现解耦合。1）master上的kube-apiserver会处理service的创建，以及Service与通过label匹配与Pod绑定⽽产⽣的endpoints对象，并将这些元数据内容存储到etcd中。其中绿⾊的代表从外向内的访问模式；endpoint是k8s集群中的⼀个资源对象，存储在etcd中，⽤来记录⼀个service对应的所有pod的访问地址；
k8s--serviec，endpoint,ingress和pod
IT艺术家-rookie的博客
09-15 1881
service,endpoints,ingress
k8s中的pod内几个容器之间的关系是什么
Johnny_Li的博客
03-03 6049
pod可以想象成一个篮子，而容器则是篮子里的鸡蛋，他们之间的关系主要变现为以下几点： 1、一个pod里的容器能有多少资源也取决于这个篮子的大小。 2、label也是贴在篮子上的。 3、IP分配给篮子而不是容器，篮子里面的所有容器共享这个IP。(pod是IP等网络资源的分配的基本单位，这个IP及其对应的network namespace是由pod里的容器共享的；) 4、哪怕只有一个鸡蛋(容器)，K...
Kubernetes Service与Endpoints深度解析
qq_36880175的博客
03-06 800
机制动态关联后端Pod集合，提供稳定的虚拟IP和DNS名称，主要解决动态Pod环境下的服务访问问题。Service是Kubernetes实现服务发现的核心抽象层
【云原生】k8s核心概念—Pod & Controller & Service & Serect & ConfigMap介绍——20230213
我是小bā吖的博客
02-13 1908
Pod & Controller & Service介绍，secret&configmap使用
Service & Endpoint
喝醉酒的小白
07-21 2375
Service的核心作用就是为Pod提供稳定的网络连接。除此之外，还提供负载均衡和从集群外部访问Pod的途径。Service对外提供固定的IP、DNS名称和端口，并确保这些信息在Service的整个生命周期中是不变的。Service对内则使用Label来将流量均衡转发至应用的各个（通常是动态变化的）Pod中。...............
【运维知识大神篇】运维界的超神器Kubernetes教程12（Endpoints资源+service详解四种类型+详解Pod调度的五种方式+Job控制器完成一次性任务+CronJob周期性完成任务）
吾日三省吾身，想出类拔萃，要把知识学牢，学全，学深，学广。
03-11 1460
本篇文章继续给大家介绍Kubernetes的内容，还是依旧的有难度，高难度意味着高工资嘛，这个没啥，还是希望大家继续努力，攻克K8s！本篇文章内容包括Endpoints资源、service详解四种类型，玩转Pod调度的五种方式，有污点、污点容忍、节点选择器、亲和性、DaemonSet控制器，Job控制器完成一次性任务和CronJob控制器周期性完成任务。
K8s服务service
踏上征程
12-20 1800
用于定义一组Pod的访问方式。在Kubernetes集群中，Pods可以动态地启动和停止，它们可能在不同的节点上以不同的IP地址运行。服务提供了一个固定的虚拟IP地址和与之关联的DNS名称，这使得无论Pod在集群中的位置如何，其他服务或外部用户都可以通过该虚拟IP地址或DNS名称访问这组Pod。通俗一点就是：实现对外服务的统一入口防止pod失联，定义一组pod的访问策略服务发现、负载均衡。
k8s中，service通过什么关联后端pod
最新发布
09-16
<think> 嗯，用户这次问的是Kubernetes中Service关联后端Pod的方式。之前用户提问过动态调整Pod副本数的组件（HPA），现在转向了服务发现机制，说明ta正在系统学习Kubernetes的网络部分。 从引用内容看，用户已经掌握了基础概念：标签选择器是核心关联机制[^1][^2]，Service提供稳定IP[^3]，且能应对Pod变化[^4]。但引用[5]提到标签管理的痛点很有意思——用户可能在实际运维中遇到过控制器重建导致服务中断的情况，这暗示ta需要生产环境的最佳实践。 需要重点强调三个层次： 1. 基础机制：必须讲清楚Label Selector如何工作，包括Deployment的matchLabel配置如何关联到Pod的metadata.labels。可以画个逻辑图：Service -> Selector -> Pod Labels 2. 高级场景：针对用户引用[5]的痛点，要解释Workload资源关联这种替代方案的必要性。比如StatefulSet控制器删除后重建时，如果用标签选择器可能因标签变化失效，但直接绑定控制器名就更健壮 3. 运维细节：补充用户没问但实际重要的点，比如kube-proxy如何维护iptables/ipvs规则，Headless Service的特殊处理等 用户提供的引用都很准确，特别是引用[4]强调的"三个固定特性"（IP/DNS/端口）和负载均衡能力，这些都要融入回答。不过引用[5]提到的Rancher标签管理问题属于特定平台实现，解释时需要区分通用机制和平台特性。 最后生成的问题要引导用户深入：Endpoint对象是很多初学者忽略的关键组件，而ExternalName和Headless Service是进阶重点。考虑在回答中埋个伏笔："当Service关联的Pod全部不可用时..."这种场景可能会引发用户对探针机制的追问。 </think> 在 Kubernetes 中，**Service 关联后端 Pod 的核心机制是通过标签选择器（Label Selector）实现的**，具体流程如下： ### 一、核心关联机制：标签选择器 1. **Pod 标签定义** 创建 Pod 时需在 `metadata.labels` 中声明标识标签（如 `app: web-server`）： ```yaml apiVersion: v1 kind: Pod metadata: name: web-pod labels: app: web-server # 关键标签 env: production ``` 2. **Service 标签选择器配置** Service 的 `spec.selector` 字段指定目标 Pod 的标签条件： ```yaml apiVersion: v1 kind: Service metadata: name: web-service spec: selector: app: web-server # 匹配含此标签的 Pod ports: - protocol: TCP port: 80 targetPort: 8080 ``` 3. **关联关系建立** Kubernetes 持续监控集群中的 Pod，**自动将满足标签条件的 Pod 加入 Service 后端**。例如： - 若新建 Pod 含 `app: web-server` 标签 → 自动加入 `web-service` 后端 - 若删除符合标签的 Pod → 自动从 Service 后端移除[^1][^2] ### 二、Service 的关键特性 | 特性 | 说明 | |---------------------|----------------------------------------------------------------------| | **稳定访问端点** | Service 分配固定 Cluster IP 和 DNS 名称（如 `web-service.default.svc.cluster.local`），客户端无需感知 Pod IP 变化[^3][^4] | | **负载均衡** | 流量自动分发到后端所有匹配的 Pod（默认轮询策略）[^4] | | **动态维护** | Pod 扩缩容/重启时，Service 自动更新关联的 Pod 列表[^1] | | **解耦设计** | Service 与 Pod 生命周期分离，支持灰度发布等场景[^2] | ### 三、高级关联模式 1. **直接关联控制器（推荐）** 通过绑定 Deployment/StatefulSet 等控制器名称，避免标签意外变更导致服务中断[^5]： ```yaml spec: workload: apiVersion: apps/v1 kind: Deployment name: web-deploy # 直接关联控制器而非标签 ``` 2. **Headless Service** 当不需要负载均衡时，设置 `clusterIP: None`，返回所有后端 Pod IP（适用于 StatefulSet）： ```yaml spec: clusterIP: None selector: app: stateful-app ``` 3. **Endpoint 对象** Service 自动创建同名的 Endpoint 对象，存储所有匹配 Pod 的 IP:Port 列表： ```bash kubectl get endpoints web-service NAME ENDPOINTS web-service 10.244.1.2:8080,10.244.2.5:8080 # 实时更新的后端列表 ``` ### 四、流量转发流程示例 ``` 客户端请求 → Service IP (10.96.123.45) ↓ kube-proxy 根据 iptables/ipvs 规则 ↓ 负载均衡到后端 Pod (如 10.244.1.2:8080) ``` > 💡 **最佳实践**： > - 优先使用控制器关联替代标签选择器，提升稳定性[^5] > - 结合 `readinessProbe` 确保流量仅转发到就绪的 Pod > - 通过 `sessionAffinity: ClientIP` 实现会话保持
评论 1
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值