文章目录1. 前言2. 基础说明2.1 什么是 EndpointSlice2.2 废弃旧版 Endpoints2.3 查看 EndpointSlice 资源2.4 分片容量配置2.6 端点状态2.7 拓扑信息3. 进阶说明3.1 资源管理机制3.1.1 默认资源管理主体3.1.2 多控制器共存机制3.1.3 管理方隔离标签3.2 资源归属关系3.3 分片分配与填充逻辑3.3.1 分片拆分规则3.3.2 控制器填充分片执行流程3.3.3 核心设计权衡3.3.4 分片规整时机3.4 端点去重规则1. 前言在Kubernetes流量转发体系中Service只负责对外提供固定访问入口真正存储后端 Pod 真实 IP、端口、健康状态的资源是端点资源。在新版K8s中EndpointSlice已全面替代传统Endpoints成为集群后端端点管理的核心资源是kube-proxy流量转发、负载均衡的核心数据来源。2. 基础说明2.1 什么是 EndpointSliceEndpointSlice是Kubernetesv1.21正式稳定的API资源专门用于管理Service关联的后端端点列表核心存储数据为「Pod真实IP 业务端口 健康状态」。kube-proxy读取EndpointSlice作为集群内部流量路由的唯一可信数据源。精准区分核心职责Service管统一访问入口EndpointSlice管后端真实地址清单kube-proxy所有的负载均衡规则、流量转发逻辑全部依赖EndpointSlice同步的后端端点数据生成。2.2 废弃旧版 Endpoints在EndpointSlice出现之前K8s依靠Endpoints资源存储后端端点但原生Endpoints存在三大硬伤无法适配大规模集群生产场景不支持双栈网络无法同时兼容IPv4、IPv6双栈集群部署无法适配新一代云原生网络架构能力扩展性极差不支持流量分布权重、应用协议标识、端点拓扑、健康状态细分等现代化流量治理特性单对象容量瓶颈严重单个Endpoints对象存储的端点数量上限极低端点超过 1000 个会被直接截断导致大量后端Pod无法接入负载均衡业务流量异常、部分实例无法承接请求。为解决以上问题K8s推出分片式端点管理机制EndpointSlice采用动态分片存储策略默认每100个端点自动生成一个全新的EndpointSlice资源。无论后端Pod数量多少都不会出现端点截断、数据丢失问题完美支撑超大规模集群业务扩容。2.3 查看 EndpointSlice 资源集群控制平面会自动为配置了标签选择器的Service创建EndpointSlice其中包含所有匹配Service标签的Pod地址信息。EndpointSlice会按照IP协议族、传输协议、端口、Service名称进行分组存放端点。我们可以通过简单实验直观看到EndpointSlice分片存储效果以及它如何绑定Service与后端Pod。基于之前 Kubernetes 系列【16】服务ClusterIP 核心原理与演示案例查看集群EndpointSlice资源kubectl get endpointslices输出示例NAMEADDRESSTYPEPORTSENDPOINTSAGEnginx-svc-zdr4zIPv48010.84.42.203,10.99.87.177,10.84.42.2004h7m输出字段说明NAMEEndpointSlice资源名称由Service名称 随机后缀组成一个Service可对应多条分片EndpointSliceADDRESSTYPE地址类型支持IPv4/IPv6天然兼容双栈集群仅支持单协议族一个资源只能存放IPv4或IPv6地址若Service同时支持双栈IPv4IPv6控制器会生成至少两份独立EndpointSlice分别存放两种协议地址。PORTS后端容器监听端口与Service端口配置对应ENDPOINTS后端就绪Pod的真实IP地址清单当端点数量超过100个自动拆分生成多条独立EndpointSliceAGE资源创建时长。 对比提示旧资源Endpoints一个Service只能对应单个对象大量端点容易截断EndpointSlice采用分片机制多个对象共同承载后端列表无数量上限。查看EndpointSlice详细信息kubectl describe endpointslices nginx-svc-zdr4z输出示例Name: nginx-svc-zdr4z Namespace: default Labels: endpointslice.kubernetes.io/managed-byendpointslice-controller.k8s.io kubernetes.io/service-namenginx-svc Annotations: endpoints.kubernetes.io/last-change-trigger-time:2026-07-14T03:25:22Z AddressType: IPv4 Ports: Name Port Protocol ---- ---- -------- http-web80TCP Endpoints: - Addresses:10.84.42.203 Conditions: Ready:trueHostname:unsetTargetRef: Pod/nginx-web-55ff4cbb5c-sbjl8 NodeName: iz2ze60mcbemirrld91q6sz Zone:unset- Addresses:10.99.87.177 Conditions: Ready:trueHostname:unsetTargetRef: Pod/nginx-web-55ff4cbb5c-4pwpn NodeName: iz2ze60mcbemirrld91q6rz Zone:unset- Addresses:10.84.42.200 Conditions: Ready:trueHostname:unsetTargetRef: Pod/nginx-web-55ff4cbb5c-rl647 NodeName: iz2ze60mcbemirrld91q6sz Zone:unsetEvents:none核心观察点Endpoints列出所有后端Pod真实IP 端口Conditions标记Pod是否就绪Ports展示端口协议支持appProtocol自定义协议识别。2.4 分片容量配置默认每个EndpointSlice最多存放100个端点可通过kube-controller-manager启动参数 –max-endpoints-per-slice修改上限为1000。2.6 端点状态EndpointSlice内置三类端点状态Conditions字段供代理组件读取判断流量转发策略serving服务中代表当前端点可正常处理业务流量Pod场景下等价于Pod就绪状态Ready。terminating终止中标记该Pod已收到删除指令、正在销毁容器尚未退出。流量代理默认不会转发流量至终止中端点若所有端点均处于终止状态则会少量转发保障滚动更新期间业务无流量丢失。ready就绪等价于「serving且未终止」若Service开启publishNotReadyAddresses:true未就绪端点该状态也会为true。2.7 拓扑信息每个端点可携带节点、可用区拓扑元数据字段如下nodeName端点所在节点名称zone端点所属可用区3. 进阶说明3.1 资源管理机制EndpointSlice是 Kubernetes 替代传统Endpoints的大规模集群端点分片管理资源具备分片、扩容、多租户、多控制器隔离能力是现代kube-proxy流量转发的核心数据源。3.1.1 默认资源管理主体集群默认由控制平面内置端点分片控制器endpointslice-controller全权托管自动监听集群Service、Pod、Node资源变更自动完成EndpointSlice的创建、更新、删除、分片规整保证Service后端端点集合实时、精准、一致。3.1.2 多控制器共存机制EndpointSlice支持多控制器并行管理适配服务网格、自定义网关、自研负载均衡等拓展场景Istio、APISIX、Ingress-Nginx、自定义代理组件可独立维护专属分片不同控制器互不抢占、互不覆盖实现流量数据源隔离原生kube-proxy可根据标签精准识别、消费对应分片。3.1.3 管理方隔离标签K8s通过专属标签严格区分资源归属控制器避免多组件冲突覆盖标签键endpointslice.kubernetes.io/managed-by系统默认分片值为endpointslice-controller.k8s.io由集群控制器管理第三方组件必须配置唯一自定义标识如istio.io、kpng.io防止资源互相覆盖、错乱同步。3.2 资源归属关系所有EndpointSlice资源强归属某一个Service不存在无归属、多归属分片保证流量拓扑清晰。属主关联机制通过OwnerReference资源属主字段绑定父级Service删除 Service 时所有关联EndpointSlice级联自动回收杜绝僵尸资源。系统自动为所有分片注入固定标签标签kubernetes.io/service-name: ${svc-name}作用可通过标签一次性筛选当前 Service 全部分片用于排查端点、同步、故障定位。3.3 分片分配与填充逻辑EndpointSlice控制器拥有固定的分片拆分、复用、扩容策略是大规模集群性能优化的关键。3.3.1 分片拆分规则一个分片内所有端点必须共用同一组端口规则若Service使用命名端口不同Pod同名端口实际端口号不一致会强制拆分新分片端口集合不同的端点绝不混装在同一个EndpointSlice中保证kube-proxy转发规则正确性。3.3.2 控制器填充分片执行流程遍历当前Service所有已存在EndpointSlice清理失效、已删除、状态异常的端点更新发生变更的端点IP、状态、拓扑信息优先复用现有分片向空闲位置填充新增端点现有分片容量不足时新建分片而非强行填满旧分片。3.3.3 核心设计权衡官方分片策略遵循优先降低集群更新开销不追求分片利用率最大化。设计原因集群所有节点的kube-proxy都会监听全部EndpointSlice变更每次分片更新都会触发全集群节点规则重同步频繁合并、填满分片会产生海量全局更新导致控制面、节点 CPU 暴涨牺牲分片饱满度换取极低的集群广播更新压力。3.3.4 分片规整时机在Deployment滚动更新、扩缩容重建场景下旧Pod批量销毁、新Pod批量重建控制器自动整体重新规整分片自动填补历史碎片空位最终实现分片高利用率。3.4 端点去重规则由于分片变更同步存在时间差同一个端点可能同时存在于多个EndpointSlice。客户端强制规范读取Service后端列表时必须遍历该Service全部EndpointSlice汇总并去重所有端点。kube-proxy内部EndpointSliceCache提供标准聚合去重实现。