Kubernetes服务发现面试题：标准回答与原理跳转
本页只保留面试标准回答、追问边界和精确原理入口。完整对象链、Demo和生产Runbook见Kubernetes服务发现主线。
高频问题
| 问题 | 标准回答 | 原理页 |
|---|---|---|
| Kubernetes怎样实现服务发现 | Service提供稳定名称和端口；EndpointSlice Controller根据selector、Pod地址和Ready生成后端；CoreDNS负责解析；kube-proxy或eBPF把新连接映射到Endpoint。 | 对象链、请求流程 |
| Service和EndpointSlice区别 | Service是稳定身份和选择规则；EndpointSlice是动态后端地址、端口和条件快照。Slice不转发网络包。 | 正确模型 |
| ClusterIP是真实监听IP吗 | 通常不是普通网卡地址，也没有每个Service一个进程listen。iptables、IPVS或eBPF匹配VIP和端口并映射到Pod。 | 请求流程 |
| kube-proxy一定转发每个包吗 | 不能这样说。iptables/IPVS主要由内核规则和Conntrack完成；部分集群由eBPF替代。排查先识别真实数据面。 | 数据面对比 |
| EndpointSlice为什么替代Endpoints | 单一Endpoints在大规模后端下对象大、更新成本高；EndpointSlice分片保存端点并支持更多条件、拓扑和双栈信息。 | EndpointSlice |
| ready、serving、terminating区别 | ready表示是否接普通新流量；serving表达是否仍在服务；terminating表示Pod正在终止。具体处理受版本和实现影响。 | Endpoint条件 |
| Pod Running为什么不能接流量 | Running不证明Spring初始化、配置、线程池和关键资源可用。应由startup保护启动，再由readiness决定接流。 | 启动传播 |
| Readiness失败后流量立刻消失吗 | 不会。Pod Condition、EndpointSlice和各Node数据面异步传播，已有TCP、HTTP/2或gRPC连接也可能继续存在。 | 条件传播、终止 |
| Service按请求轮询Pod吗 | 通常是四层连接级选择。连接建立时选Endpoint，Conntrack和连接复用让多个HTTP请求继续到同一Pod。 | 连接级负载 |
| gRPC扩容后为何不均衡 | 少量HTTP/2 Channel多路复用大量RPC；旧Channel不会因Endpoint增加自动迁移。要治理Resolver、子连接和连接生命周期。 | gRPC倾斜 |
| Headless Service是什么 | clusterIP: None，没有普通ClusterIP转发，DNS返回端点，客户端负责刷新、选择、重试和连接管理。 | Headless |
| Headless下线后为何仍访问旧Pod | JVM、OS、DNS、应用Resolver和连接池可能缓存旧地址，已有连接也不会自动断开。 | Headless、DNS |
| CoreDNS返回ClusterIP后Pod变化要改DNS吗 | 普通ClusterIP DNS返回稳定VIP，Pod变化由EndpointSlice和数据面收敛；Headless返回端点，缓存直接影响收敛。 | DNS |
| ndots为何可能导致DNS变慢 | 点数低于ndots时Resolver可能拼接多个search domain尝试，外部域名也会多次查询。 | DNS |
| Service与Nacos/Dubbo区别 | ClusterIP由平台数据面选Pod；Nacos/Dubbo通常由客户端维护实例并选择；Headless交给客户端；Mesh交给代理。 | 方案对比 |
| Spring Cloud LoadBalancer和Service能同时用吗 | 可以，但要明确边界。双层选择和多层重试会增加不确定性，应明确地址、选择层、Deadline和重试预算。 | Spring Cloud接入 |
| Pod怎样优雅摘流 | Readiness和EndpointSlice先传播摘流，应用停止接新业务并完成有界在途请求，客户端关闭旧连接，在宽限期内退出；写操作仍需幂等。 | 终止时间线 |
| Pod删除后为何还有请求 | 数据面未同步、旧长连接、Ingress/Mesh/LB缓存、Headless旧地址或直接PodIP都可能造成。 | 终止边界、Runbook |
| DNS成功但请求超时怎么查 | 核对Service端口、全部EndpointSlice、Pod监听、直连Pod、同/跨Node、数据面、NetworkPolicy和Conntrack。 | 取证、Runbook |
| SessionAffinity能保存登录吗 | 不能。ClientIP受NAT、网络变化和Pod下线影响；登录应使用Token或共享存储。 | 会话亲和 |
| Java 8/Boot 2与Java 17+/Boot 3发现原理不同吗 | Kubernetes对象链不变；差异在Spring依赖矩阵、Jakarta迁移、Actuator、Observation和客户端兼容性，两条基线要分别验证。 | 双基线 |
场景题：滚动发布出现1%失败
先按版本、Pod、Node、调用方和连接类型拆分错误，再对齐DeletionTimestamp、Pod Ready、EndpointSlice条件、节点同步、SIGTERM和连接关闭时间线。Kubernetes摘流是异步传播，已有Keep-Alive、HTTP/2和gRPC连接不会自动迁移，因此还要检查Ingress、Mesh和客户端Drain。配置上使用startup/readiness、优雅关闭和足够宽限期；业务上保证新旧接口与Schema兼容，写请求使用幂等键和结果查询。
原理入口：启动传播、终止流程、滚动发布Runbook。
场景题：扩容后短暂有效，随后又倾斜
扩容只增加可选Endpoint，不迁移已有连接。少量HTTP/2或gRPC Channel可能继续固定旧Pod，新Pod只承接新连接；若数据库、锁或第三方已饱和，短暂提升后仍会回落。应同时看Endpoint快照、每Pod连接数、每连接请求数、P99和下游资源，而不只看Pod数。
若指MQ消费者，应回到消息堆积与Lag分布分析分区上限、热点分区、慢消息、下游瓶颈和重试风暴。
项目回答模板
我们以Service提供稳定身份，EndpointSlice保存Ready后端，CoreDNS负责解析，节点数据面完成新连接到Pod的映射。应用用startup保护慢启动、readiness控制接流，并实现SIGTERM优雅关闭。我们明确HTTP连接池和gRPC Channel是连接级负载，扩容时观察每Pod连接数。故障按DNS、Service、全部EndpointSlice、Pod、Node数据面和应用逐层取证。Java 8/Boot 2存量和Java 17+/Boot 3新服务使用各自兼容的Spring Cloud发行列，但Kubernetes对象链一致。
本章小结
高质量回答必须同时提到稳定身份、动态后端、DNS、数据面、连接复用和异步传播。只说“Service根据label负载到Pod”无法解释滚动发布失败、长连接倾斜和摘流残留。