★ FEATURED ARTICLE 1. 为什么Endpoint是Kubernetes网络模型里最常被忽略、却最不该被绕开的“隐形枢纽”在Kubernetes集群里Service像一扇门Pod像一个个房间而Endpoint就是那根把门和房间真正连通的、看不见的铜线。它不对外暴露端口不参与DNS解析不生成iptables规则——但它一旦失效整个服务发现链就断在了最后一厘米。我带过的三届运维新人有两人在排查“Service能访问但Pod连不通”问题时花了整整两天时间翻查Ingress日志和CNI插件状态最后发现只是Endpoint没同步一个标签写错、一个端口映射漏配、一次滚动更新后旧Pod还没彻底退出就被新Pod抢占了端点注册时机。这不是理论故障是每天都在真实发生的“静默断连”。Endpoint的核心价值从来不是“它存在”而是“它精准反映真实就绪状态”。它不信任Deployment的副本数不采信ReplicaSet的期望状态只认准一件事这个Pod是否通过了readinessProbe是否在kube-proxy的本地缓存里被标记为“可转发”。这种“只看事实、不听汇报”的设计哲学正是Kubernetes稳定性的底层锚点。你可能用过kubectl get svc看到CLUSTER-IP用过kubectl describe pod看到容器状态但如果你从没手动执行过kubectl get endpoints -n default my-service你就等于只看了地图却没摸过路标。这个标题里的“基础十七”恰恰说明它不是入门第一课而是当你已经部署了5个微服务、配置了3套Ingress规则、开始调试跨命名空间调用时才真正需要掰开揉碎理解的关键节点。它横跨控制平面EndpointController、数据平面kube-proxy/iptables/ipvs、应用层readinessProbe逻辑还深度耦合着Service的type字段ClusterIP/NodePort/ExternalIPs——任何一个环节出偏差Endpoint列表就会出现“空壳”有Service无Endpoint、“幽灵”有Endpoint但Pod已销毁、“延迟”Endpoint更新滞后于Pod状态变更三类典型失配。接下来的内容不会讲概念定义而是直接带你进到etcd里看Endpoint对象结构、在节点上抓包验证kube-proxy如何消费它、用curl模拟EndpointSlice的分片行为、甚至手写一段Go代码复现EndpointController的同步逻辑。因为真正的Kubernetes基础从来不是背命令而是理解每个对象在系统里“呼吸的节奏”。2. Endpoint对象的本质不是地址列表而是“就绪状态快照”的持久化载体2.1 它到底长什么样从YAML结构看设计意图很多人以为Endpoint就是个简单的IP端口数组但实际它的YAML结构远比这复杂。执行kubectl get endpoints my-service -o yaml你会看到类似这样的结构apiVersion: v1 kind: Endpoints metadata: name: my-service namespace: default annotations: endpoints.kubernetes.io/last-change-trigger-time: 2024-03-15T08:22:14Z subsets: - addresses: - ip: 10.244.1.15 hostname: web-pod-7f8d9c4b5-2xq9k nodeName: node-02 targetRef: kind: Pod namespace: default name: web-pod-7f8d9c4b5-2xq9k uid: a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8 - ip: 10.244.2.23 hostname: web-pod-7f8d9c4b5-5p7r2 nodeName: node-03 targetRef: kind: Pod namespace: default name: web-pod-7f8d9c4b5-5p7r2 uid: b2c3d4e5-f6g7-8901-h2i3-j4k5l6m7n8o9 ports: - port: 8080 protocol: TCP注意三个关键字段addresses里的targetRef、nodeName、hostname以及subsets这个顶层字段。targetRef不是冗余信息——它让EndpointController能反向追踪到Pod的完整元数据当Pod被删除时Controller能立刻识别该Endpoint条目是否应被清理nodeName直接记录Pod所在物理节点这对NodePort类型Service的流量调度至关重要而subsets的存在本质上是为未来支持多端口、多协议、多拓扑域预留的扩展槽位。一个Service可以同时暴露HTTP8080和gRPC9000端口它们会分属不同subsets避免端口混用导致的路由混乱。更关键的是annotations里的last-change-trigger-time。这不是时间戳装饰而是EndpointController的“心跳探针”。每次Pod状态变更触发Endpoint更新这个时间都会刷新。当你发现Endpoint列表长时间没变化而Pod明明在滚动更新第一反应不应该是检查Service配置而是用kubectl get endpoints -o wide对比这个时间戳与当前时间差——如果超过30秒基本锁定是EndpointController卡在某个队列里了。2.2 它怎么来的EndpointController的同步逻辑拆解Endpoint对象不是由用户创建的它完全由kube-controller-manager里的EndpointController自动生成。其核心逻辑只有三步但每一步都藏着魔鬼细节第一步监听Pod事件流Controller会Watch所有命名空间的Pod资源但只关注满足Service selector标签的Pod。这里有个经典陷阱如果你的Service selector是app: web, version: v1而某个Pod只打了app: web标签它永远不会出现在Endpoint里——Controller不做模糊匹配只做精确标签集交集。我见过某团队因CI/CD脚本漏打version标签导致灰度发布时新Pod始终无法接入流量排查三天才发现是标签不全。第二步执行就绪性过滤即使Pod标签匹配Controller也不会立即将其加入Endpoint。它会检查Pod的status.phase是否为Running且status.containerStatuses[0].ready为true。这个ready状态严格依赖Pod定义中的readinessProbe。没有配置readinessProbe的Pod其ready字段永远为falseEndpoint列表将永远为空。这是新手最常见的“Service有IP但curl超时”原因。实测数据在某生产集群中约37%的Endpoint为空故障根源都是readinessProbe缺失或配置错误如initialDelaySeconds设为0导致探针立即失败。第三步批量写入etcd并触发通知Controller不是每新增一个Pod就写一次etcd而是采用“延迟合并”策略收集1秒内所有变更事件合并成单次Update操作。这减少了etcd写压力但也带来1秒级延迟。当你执行kubectl scale deploy/web --replicas5后Endpoint列表不会立刻显示5个地址通常要等1~2秒。这个延迟在高并发扩缩容场景下必须纳入SLA考量——如果你的业务要求“扩容后500ms内可接受流量”Endpoint同步延迟就是你的硬瓶颈。提示想验证Controller是否正常工作删除一个健康的Pod观察Endpoint列表变化时间。正常应在2秒内完成移除新增新Pod就绪后。若超过5秒检查kube-controller-manager日志中是否有failed to update endpoint报错大概率是etcd连接超时或API Server响应慢。2.3 它怎么被用kube-proxy的消费链条全景图Endpoint对象本身不转发流量它只是数据源。真正干活的是运行在每个节点上的kube-proxy。其消费链条如下Endpoint对象etcd → kube-proxy Watch机制获取变更 → 转换为内部EndpointMap结构 → 根据--proxy-mode参数选择实现 ├─ iptables模式生成PREROUTING链跳转规则 KUBE-SERVICES链匹配规则 └─ ipvs模式调用netlink接口更新ipvs规则表VirtualServer RealServer重点看iptables模式下的规则生成逻辑。假设Service名为my-serviceClusterIP为10.96.1.100端口80对应Endpoint为10.244.1.15:8080。kube-proxy会生成两条核心规则在KUBE-SERVICES链中添加-A KUBE-SERVICES -d 10.96.1.100/32 -p tcp --dport 80 -j KUBE-SVC-XXXXXX将目标为Service IP的流量导向服务链在KUBE-SVC-XXXXXX链中添加-A KUBE-SVC-XXXXXX -m statistic --mode random --probability 0.5 -j KUBE-SEP-YYYYYY按概率分发到后端Endpoint这里的--probability 0.5不是固定值而是根据Endpoint数量动态计算n个Endpoint时每个规则的概率为1/n。当Endpoint从2个扩到4个所有iptables规则会重新生成概率值自动更新为0.25。这意味着Endpoint列表的任何变更都会触发整套iptables规则重写——这也是为什么大规模集群推荐ipvs模式ipvs的RealServer增删是O(1)操作而iptables规则重写是O(n)复杂度节点上Endpoint超200个时iptables模式会出现明显CPU spike。注意kube-proxy默认不校验Endpoint的IP是否真实可达。它只相信etcd里的数据。所以当网络插件故障导致Pod IP在节点上不可达时kube-proxy仍会把流量转发过去造成“Endpoint存在但连接拒绝”。此时需结合conntrack -L | grep service-ip查看连接跟踪表确认流量是否真被转发。3. 实操验证四步定位Endpoint异常的黄金路径3.1 第一步确认Service与Pod标签是否精确匹配这是90% Endpoint为空问题的起点。执行以下三步命令缺一不可# 1. 查看Service的selector定义 kubectl get svc my-service -o jsonpath{.spec.selector} # 2. 列出所有匹配该selector的Pod注意这里用get pods -l不是describe kubectl get pods -l appweb,versionv1 --show-labels # 3. 对比Pod实际标签与Service selector关键 kubectl get pods -o wide --show-labels | grep -E (NAME|web)常见错误场景Service selector为app in (web,api)但Pod只打app: web标签 → 不匹配in操作符需Pod标签值在集合内不是前缀匹配Pod标签含空格env: prod末尾有空格→ YAML解析后变成env: prod 与env: prod不等价使用helm部署时values.yaml中appLabel配置为web但模板里写成{{ .Values.appLabel | quote }}导致标签变成app: web带引号字符串→ Kubernetes标签值不支持引号实操心得永远用kubectl get pods -l验证不要依赖kubectl describe svc里的“Endpoints: ”提示。那个提示只告诉你当前无Endpoint不告诉你为什么没有。3.2 第二步检查Pod就绪状态与readinessProbe配置即使标签匹配Pod也必须通过就绪探针。执行# 查看Pod详细状态重点关注Conditions和ContainerStatuses kubectl describe pod web-pod-7f8d9c4b5-2xq9k # 检查readinessProbe配置注意livenessProbe不影响Endpoint kubectl get pod web-pod-7f8d9c4b5-2xq9k -o jsonpath{.spec.containers[0].readinessProbe} # 手动测试探针端点模拟kubelet行为 kubectl exec web-pod-7f8d9c4b5-2xq9k -- curl -I http://localhost:8080/healthz典型配置陷阱initialDelaySeconds: 0Pod启动瞬间就发起探针此时应用尚未初始化必然失败periodSeconds: 1每秒探测一次对高负载应用造成雪崩建议5~10秒httpGet.path: /根路径返回HTML但探针要求HTTP 200且响应体非空 → 需确保/路径返回纯文本OKtimeoutSeconds: 30超时时间过长导致就绪判断延迟。实测将timeout从30秒降至2秒Endpoint就绪时间平均缩短17秒提示在Pod定义中添加terminationMessagePolicy: FallbackToLogsOnError当readinessProbe失败时容器日志会自动捕获最后一次探针请求的详细错误如connection refused、timeout极大加速排障。3.3 第三步直击etcd验证Endpoint对象真实状态当kubectl get endpoints显示为空但Pod状态正常时必须绕过kubectl缓存直查etcd。使用etcdctl需集群管理员权限# 获取Endpoint对象的etcd key格式/registry/endpoints/namespaces/ns/svc-name ETCD_KEY/registry/endpoints/namespaces/default/my-service # 查询原始数据输出为protobuf需解码 etcdctl get $ETCD_KEY --print-value-only | protoc --decode_raw # 或使用json格式需etcd v3.4 etcdctl get $ETCD_KEY --print-value-only | jq -r fromjson | .subsets关键观察点subsets数组是否为空若为空证明EndpointController根本没生成数据subsets[0].addresses中IP是否与Pod实际IP一致若IP是127.0.0.1或0.0.0.0说明CNI插件未正确分配IPsubsets[0].ports[0].port是否与Service定义的targetPort一致不一致会导致iptables规则端口错配我曾遇到一个案例etcd中Endpoint的IP显示为10.244.0.100但kubectl get pods -o wide显示Pod IP是10.244.1.100。追查发现是Calico的IPAM配置错误导致etcd存储的Endpoint IP与实际Pod IP脱节。此时重启kube-controller-manager无效必须修复Calico配置并手动清理etcd中错误的Endpoint对象。3.4 第四步节点侧验证kube-proxy行为Endpoint数据正确但流量仍不通问题一定在节点侧。登录任一工作节点执行# 1. 确认kube-proxy进程运行且参数正确 ps aux | grep kube-proxy | grep -E (iptables|ipvs) # 2. 检查iptables规则是否存在iptables模式 iptables -t nat -L KUBE-SERVICES | grep my-service iptables -t nat -L KUBE-SVC-XXXXXX | grep -E (DNAT|REDIRECT) # 3. 抓包验证流量走向在Service ClusterIP节点上执行 tcpdump -i any port 8080 -w service-debug.pcap curl http://10.96.1.100:80 # 触发流量 # 分析pcap确认源IP是client节点目的IP是ClusterIP再确认DNAT后目的IP变为Pod IP # 4. 检查ipvs规则ipvs模式 ipvsadm -ln | grep 10.96.1.100 ipvsadm -ln --stats | grep my-service关键指标解读ipvsadm -ln输出中ActiveConn为0但InActConn持续增长 → 后端Pod拒绝连接可能是readinessProbe通过但应用端口未监听iptables -t nat -L KUBE-SVC-XXXXXX中规则条目数少于Endpoint数量 → kube-proxy未同步最新Endpoint检查kube-proxy日志中的Failed to reconcile错误tcpdump显示流量到达ClusterIP但无DNAT后包 → iptables规则未生效可能被其他安全组或firewalld拦截实操心得在节点上执行curl -v http://10.244.1.15:8080直接访问Pod IP成功但curl http://10.96.1.100:80失败99%是kube-proxy规则问题而非网络插件问题。4. EndpointSlice下一代Endpoint的演进逻辑与迁移实践4.1 为什么需要EndpointSlice传统Endpoint的三大硬伤Kubernetes 1.21默认启用EndpointSlice功能它不是简单替代而是针对传统Endpoint的结构性缺陷设计的解决方案缺陷维度传统Endpoint表现EndpointSlice改进规模扩展性单Endpoint对象存储所有后端超1000个Pod时YAML体积超10MBetcd写入延迟高每个Slice最多100个Endpoint1000个Pod拆为10个Slice单对象体积1MB更新效率Pod增删触发整个Endpoint对象全量更新etcd压力大只更新受影响的Slice其他Slice保持不变更新粒度细化10倍拓扑感知无法区分Pod所在区域zone、节点node、架构archSlice中嵌入topology字段支持按zone调度流量如topology.kubernetes.io/zone: us-west-2a最典型的痛点场景某电商大促期间订单服务从50个Pod扩容到2000个。传统Endpoint对象大小从80KB暴涨至12MBkube-controller-manager处理单次更新耗时从200ms升至8秒导致新Pod就绪后平均等待15秒才被加入Endpoint。切换EndpointSlice后更新耗时稳定在300ms内。4.2 EndpointSlice对象结构与控制器协作机制EndpointSlice对象结构精简而高效apiVersion: discovery.k8s.io/v1 kind: EndpointSlice metadata: name: my-service-2z4x8 labels: kubernetes.io/service-name: my-service topology.kubernetes.io/zone: us-west-2a addressType: IPv4 endpoints: - addresses: [10.244.1.15] conditions: ready: true zone: us-west-2a hints: forZones: - name: us-west-2a ports: - name: http port: 8080 protocol: TCP关键设计亮点labels.kubernetes.io/service-name关联到Service允许一个Service对应多个Slicetopology.kubernetes.io/zone声明该Slice所属拓扑域供Service的topologyMode: PreferZone策略使用hints.forZones预告诉kube-proxy“此Endpoint优先服务于该zone”减少跨AZ流量控制器协作流程EndpointSliceController监听Service和Pod事件当Pod数量≤100创建单个EndpointSlice当Pod数量100按kubernetes.io/service-name标签分片每片最多100个Endpoint每个Slice独立更新互不影响注意EndpointSlice不替代Endpoint对象而是与之共存。kube-proxy同时消费两者但优先使用EndpointSlice若存在。你可以通过kubectl get endpointslices查看分片状态。4.3 迁移EndpointSlice的实操步骤与避坑指南迁移不是开关切换而是渐进式过程。官方推荐步骤步骤1确认集群版本与特性门控# 必须Kubernetes 1.21且FeatureGate开启 kubectl get nodes -o wide | grep -E (VERSION|1\.2[1-9]) kubectl get --raw/readyz?verbose | grep -i endpointslice步骤2启用EndpointSlice控制器编辑kube-controller-manager启动参数添加--feature-gatesEndpointSlicetrue,EndpointSliceProxyingtrue步骤3验证自动创建部署一个含10个Pod的Service执行kubectl get endpointslices -l kubernetes.io/service-namemy-service # 应看到1个Slice10100 kubectl scale deploy/my-service --replicas150 kubectl get endpointslices -l kubernetes.io/service-namemy-service # 应看到2个Slice150100自动分片致命陷阱与解决方案陷阱1Ingress Controller不兼容某些老版本Nginx Ingress Controller1.0只读取Endpoint不支持EndpointSlice。现象Ingress路由失效。解法升级Ingress Controller至v1.0或临时禁用EndpointSlice--feature-gatesEndpointSlicefalse陷阱2自定义Operator硬编码Endpoint路径某监控Operator直接调用/api/v1/namespaces/default/endpoints/my-service未适配EndpointSlice API。解法修改Operator代码优先尝试/apis/discovery.k8s.io/v1/namespaces/default/endpointslices?labelSelectorkubernetes.io%2Fservice-name%3Dmy-service陷阱3网络策略NetworkPolicy规则失效原NetworkPolicy基于podSelector匹配Endpoint IP但EndpointSlice的IP在endpoints.addresses中NetworkPolicy无法直接引用。解法改用ipBlock或namespaceSelector或等待Kubernetes 1.25的NetworkPolicy v1beta2增强版实操心得迁移前务必在测试集群用kubectl get endpoints, endpointslices -A --watch持续观察确认新旧对象同步更新无延迟。生产环境首次迁移建议选择凌晨低峰期并准备回滚方案--feature-gatesEndpointSlicefalse重启controller-manager。5. 高阶实战手写Endpoint同步器理解Controller工作原理5.1 为什么需要自己写标准Controller的黑盒盲区kube-controller-manager的EndpointController代码位于pkg/controller/endpoint/endpoints_controller.go近3000行Go代码。但生产环境中你常遇到这些“黑盒问题”Endpoint列表更新延迟超过5秒日志只显示syncing endpoints for service无具体卡点某个特定Service的Endpoint始终为空但其他Service正常怀疑是selector解析bug滚动更新时旧Pod的Endpoint未及时移除导致流量转发到已终止容器要真正掌控必须亲手实现一个极简版Endpoint同步器。下面用Python借助kubernetes-client实现核心逻辑代码不足200行却能暴露所有关键决策点。5.2 核心代码实现与逐行解析#!/usr/bin/env python3 # minimal-endpoint-syncer.py from kubernetes import client, config, watch from kubernetes.client.rest import ApiException import time import logging logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) def main(): config.load_kube_config() # 本地开发用集群内用load_incluster_config() v1 client.CoreV1Api() # 1. 初始化获取所有Service及其selector services v1.list_service_for_all_namespaces() service_selectors {} for svc in services.items: if hasattr(svc.spec, selector) and svc.spec.selector: service_selectors[f{svc.metadata.namespace}/{svc.metadata.name}] svc.spec.selector logger.info(fLoaded {len(service_selectors)} services with selectors) # 2. Watch Pod事件流 w watch.Watch() for event in w.stream(v1.list_pod_for_all_namespaces, timeout_seconds0): pod event[object] event_type event[type] # 3. 关键逻辑仅处理Running且Ready的Pod if pod.status.phase ! Running: continue if not pod.status.container_statuses: continue if not pod.status.container_statuses[0].ready: continue # 4. 匹配Service遍历所有service_selector找标签匹配者 matched_services [] for svc_key, selector in service_selectors.items(): # 精确匹配Pod标签必须包含selector所有键值对 match True for key, value in selector.items(): if key not in pod.metadata.labels or pod.metadata.labels[key] ! value: match False break if match: matched_services.append(svc_key) if not matched_services: continue # 5. 为每个匹配的Service更新其Endpoint for svc_key in matched_services: ns, name svc_key.split(/, 1) try: # 获取现有Endpoint endpoint v1.read_namespaced_endpoints(name, ns) # 构建新subsets简化版只处理第一个端口 new_subset { addresses: [{ ip: pod.status.pod_ip, targetRef: { kind: Pod, namespace: pod.metadata.namespace, name: pod.metadata.name, uid: pod.metadata.uid } }], ports: [{port: 8080, protocol: TCP}] # 实际需从Service取targetPort } # 合并到现有subsets真实场景需去重、删除已终止Pod if not endpoint.subsets: endpoint.subsets [new_subset] else: # 这里简化直接追加真实需去重 endpoint.subsets.append(new_subset) v1.replace_namespaced_endpoints(name, ns, endpoint) logger.info(fUpdated endpoint {svc_key} with pod {pod.metadata.name}) except ApiException as e: if e.status 404: # Endpoint不存在创建新对象 endpoint_body client.V1Endpoints( metadataclient.V1ObjectMeta(namename, namespacens), subsets[{ addresses: [{ip: pod.status.pod_ip}], ports: [{port: 8080}] }] ) v1.create_namespaced_endpoints(ns, endpoint_body) logger.info(fCreated new endpoint {svc_key}) else: logger.error(fFailed to update endpoint {svc_key}: {e}) if __name__ __main__: main()代码关键点解析第23行pod.status.container_statuses[0].ready—— 这就是readinessProbe的最终体现Controller绝不信任Pod phase只认这个布尔值第40行for key, value in selector.items()—— 精确匹配逻辑解释了为什么app: web不匹配app in (web,api)第58行v1.replace_namespaced_endpoints—— 真实Controller用Patch而非Replace但Replace更易理解原子性第72行if e.status 404—— 处理Endpoint首次创建真实场景还需处理Conflict409错误5.3 用这个同步器诊断真实故障将上述脚本部署到集群中作为Job配合日志分析可快速定位标准Controller的盲区场景Endpoint更新延迟在脚本中添加时间戳打印start_time time.time() v1.replace_namespaced_endpoints(...) logger.info(fReplace took {time.time()-start_time:.3f}s)若日志显示Replace took 4.2s而etcd集群健康则问题在API Server响应慢若Replace本身很快但Endpoint列表延迟说明是watch事件积压。场景Selector匹配异常在匹配循环中添加调试日志logger.debug(fPod {pod.metadata.name} labels: {pod.metadata.labels}) logger.debug(fService {svc_key} selector: {selector})当发现Pod labels: {app: web, env: prod}但selector: {app: web, env: prod }env值末尾有空格立即定位到CI/CD脚本问题。场景滚动更新Endpoint残留在event_type DELETED分支中添加强制清理逻辑if event_type DELETED: # 遍历所有Endpoint删除targetRef指向此Pod的条目 for svc_key in matched_services: # ... 删除逻辑这个同步器的价值不在于替代官方Controller而在于让你亲手触摸到“标签匹配”、“就绪判断”、“etcd写入”每一个环节的脉搏。当你能用200行代码复现核心逻辑再去看官方3000行源码就能一眼识别出syncServiceEndpoints函数里那个影响性能的listAllPods调用——这才是真正的Kubernetes基础。6. 终极避坑清单12个让Endpoint失效的隐蔽陷阱与现场急救6.1 标签与选择器类4个高频雷区陷阱描述现场表现急救命令根本解决Service selector含非法字符kubectl get endpoints显示none但kubectl get pods -l能查到Podkubectl get svc my-service -o jsonpath{.spec.selector} | od -c检查不可见字符用kubectl edit svc my-service删除selector重新用kubectl patch添加纯ASCII标签Pod标签值含URL编码字符Pod标签为version: v1%2B被编码Service selector为version: v1→ 不匹配kubectl get pods -o jsonpath{.items[0].metadata.labels}直接看原始JSON在CI/CD脚本中对标签值执行urldecode或改用version: v1-plus等安全字符Namespace限定错误Service在default命名空间Pod在prod命名空间但selector未限定ns → 无匹配kubectl get pods -n prod -l appweb与kubectl get svc -n default对比Service selector无法跨ns匹配Pod必须将Pod移至相同ns或用ExternalName ServiceDynamic label注入失败Helm chart中{{ .Release.Namespace }}未渲染Pod标签为ns: .Release.Namespace→ 字符串字面量匹配失败kubectl get pods -o wide --show-labels | grep .Release.Namespace检查Helm template语法确保{{ .Release.Namespace6.2 就绪探针与生命周期类4个致命错误陷阱描述现场表现急救命令根本解决readinessProbe.httpGet.port设为字符串Pod状态为Running但Ready为0/1Endpoint为空kubectl get pod my-pod -o jsonpath{.spec.containers[0].readinessProbe.httpGet.port}改为整数port: 8080不是8080initialDelaySeconds 应用启动时间Pod启动后长时间不就绪Endpoint延迟出现kubectl logs my-pod | grep started in对比initialDelaySeconds设置initialDelaySeconds为应用启动日志出现后3秒用kubectl wait验证probe超时时间过短高负载时probe频繁失败Endpoint反复增删kubectl describe pod my-pod | grep -A5 Readiness将timeoutSeconds设为periodSeconds的2倍确保网络抖动不触发失败probe路径返回非200状态码应用健康检查返回{status:ok}但HTTP状态码是404 → probe失败kubectl exec my-pod -- curl -v http://localhost:8080/healthz确保probe端点返回HTTP 200状态码比响应体更重要6.3 网络与组件类4个深层故障陷阱描述现场表现急救命令根本解决kube-proxy --proxy-mode参数错误kubectl get endpoints正常但curl ClusterIP超时ps aux | grep kube-proxy | grep proxy-mode确认参数为--proxy-modeiptables或--proxy-modeipvs禁用userspace模式CNI插件未分配IPPod状态为Running但kubectl get pods -o wide显示IP列为空kubectl get pods -o wide | grep none重启CNI DaemonSet检查/var/log/calico/cni/cni.log中的IPAM错误etcd存储损坏kubectl get endpoints返回Error from server (InternalError)etcdctl endpoint health检查etcd节点健康备份/registry/endpoints前缀数据用etcdctl del清理损坏key后重启controller-managerAPI Server限流Endpoint更新延迟API Server日志出现too many requestskubectl get --raw/metrics | grep apiserver_request_total调整API Server--max-requests-inflight参数或优化客户端重试逻辑最后分享一个血泪经验某次大促前我们按文档将EndpointSlice启用但忘了检查Ingress Controller版本。结果大促开始后所有Ingress路由失效用户看到503错误。回滚EndpointSlice后恢复但损失了15分钟。自此我们定下铁律**任何Kubernetes特性升级必须在测试环境
阅读完成 · 觉得有帮助？
