大白话说K8s Service 发现：再也不用记 Pod 的 IP 了！

最近在复习K8s 的时候Service 发现这个概念一开始真的给我绕晕了后来琢磨透了才发现这玩意儿简直是 K8s 里的 “通讯录”太好懂了今天就用大白话说出我的理解欢迎大佬批评指正一、先搞懂为啥需要 Service 发现咱们先想个生活里的例子你就秒懂了。假设你开了一家奶茶店店里有 3 个奶茶师傅对应 K8s 里的 3 个后端 Pod专门给客人前端 Pod做奶茶。每个师傅都有自己的工位号Pod 的 IP 地址而且这个工位号不是固定的师傅请假、调岗、离职工位号就会变甚至店里扩店还会新增师傅、新工位号。客人来买奶茶总不能每次都挨个问 “今天哪个师傅在工位工位号是多少” 吧客人记不住也太麻烦了这就是 K8s 里最头疼的问题Pod 是 “临时工”IP 说变就变。前端 Pod 要调用后端服务总不能每次都手动查后端 Pod 的 IP 吧这时候Service 就登场了Service 就相当于奶茶店的统一前台电话固定的 Service IP客人只需要记住这个前台电话打过去就行不用管哪个师傅接、师傅在哪个工位。前台会自动把电话转接到空闲的师傅那里师傅换工位、新增 / 离职前台都能实时同步客人完全没感知。而Service 发现就是让前端 Pod 能自动找到这个 “前台电话”不用手动记、手动配的整个机制二、Service 发现到底是干啥的用一句话说Service 发现就是 K8s 帮你自动找到服务、稳定访问服务的一套机制彻底解决 Pod IP 不固定的问题。咱们拆解一下核心角色后端 Pod干活的服务实例IP 随时可能变比如 Pod 重启、扩容、缩容。Service给后端 Pod 做 “代理” 的固定入口有一个永远不变的 Cluster IP相当于服务的 “固定名片”。kube-proxy每个节点上都跑的小管家负责维护 Service 和后端 Pod 的映射关系把访问 Service 的流量转发到健康的后端 Pod 上。API ServerK8s 的总控中心kube-proxy 会从这里实时获取 Service 和 Pod 的状态变化保证映射关系永远是最新的。整个流程就像奶茶店的运作客人前端 Pod要喝奶茶只需要打前台电话访问 Service IP。前台kube-proxy收到请求会根据最新的师傅名单后端 Pod 列表把电话转接到一个空闲的师傅Pod那里。哪怕师傅换了工位Pod IP 变了、来了新师傅Pod 扩容前台都会实时更新名单客人完全不用管。三、两种常见代理模式iptables 和 IPVS到底啥区别kube-proxy 有两种主流的工作模式咱们也用大白话讲明白1. iptables 模式默认模式适合中小集群就相当于奶茶店前台是人工登记 手动转电话每次有师傅换工位、新增 / 离职前台都要手动更新名单然后给每个师傅的工位加一条 “转电话” 的规则。优点简单、不用额外配置小集群里完全够用。缺点集群大了比如上百个服务、上千个 Pod规则会越来越多转电话的速度就变慢了延迟变高。2. IPVS 模式高性能模式适合大集群就相当于奶茶店前台装了智能电话交换机用哈希表存师傅名单更新速度极快转电话直接走内核延迟极低。优点性能拉满支持更高的流量吞吐量大集群、高并发场景首选。缺点需要额外配置小集群用有点 “杀鸡用牛刀”。简单总结小集群用 iptables大集群用 IPVS核心都是帮你把流量转发到正确的 Pod 上。四、亲手实操一遍彻底搞懂咱们用一个简单的例子亲手跑一遍 Service 发现的流程你就彻底明白了。步骤 1先搞 3 个后端 Pod奶茶师傅咱们用 nginx 镜像跑 3 个副本的 Deployment相当于 3 个奶茶师傅都开放 80 端口师傅的服务端口。完整 yaml 文件如下apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment-servicetest labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80执行命令创建 Deploymentcat deployment-service.yml EOF apiVersion: apps/v1 kind: Deployment metadata: name: nginx-deployment-servicetest labels: app: nginx spec: replicas: 3 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent ports: - containerPort: 80 EOF kubectl create -f deployment-service.yml执行完之后我们就有了 3 个运行 nginx 的 Pod每个 Pod 都有自己的 IP但我们完全不用记步骤 2给 Pod 创建 Service奶茶店前台用kubectl expose命令给这 3 个 Pod 创建一个 Service相当于给奶茶店装个前台电话kubectl expose deployment nginx-deployment-servicetest \ --port9000 --namemyservice --target-port80 --typeNodePort咱们解释一下参数--port9000Service 的端口前台电话的分机号--namemyserviceService 的名字--target-port80后端 Pod 的端口师傅的服务端口对应 nginx 的 80--typeNodePort把 Service 暴露到节点上方便我们外部测试步骤 3查看 Service 和端点验证发现机制执行命令查看 Service 和端点kubectl get service,endpoints输出结果大概长这样NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.96.0.1 none 443/TCP 15d service/myservice NodePort 10.110.19.123 none 9000:32420/TCP 7s NAME ENDPOINTS AGE endpoints/kubernetes 192.168.30.130:6443 15d endpoints/myservice 172.16.245.19:80,172.16.245.20:80,172.16.93.216:80 7s你看service/myservice有一个固定的 Cluster IP10.110.19.123这就是我们的 “前台电话”永远不变endpoints/myservice里的 3 个 IP就是 3 个后端 Pod 的 IPkube-proxy 会自动维护这个列表Pod 变了这里就会自动更新。步骤 4测试访问验证 Service 生效我们用 NodePort 的端口32420访问节点 IP就能访问到 nginx 服务了curl http://192.168.30.130:32420会返回 nginx 的欢迎页面!DOCTYPE html html head titleWelcome to nginx!/title style body { width: 35em; margin: 0 auto; font-family: Tahoma, Verdana, Arial, sans-serif; } /style /head body h1Welcome to nginx!/h1 pIf you see this page, the nginx web server is successfully installed and working. Further configuration is required./p pFor online documentation and support please refer to a hrefhttp://nginx.org/nginx.org/a.br/ Commercial support is available at a hrefhttp://nginx.com/nginx.com/a./p pemThank you for using nginx./em/p /body /html完美我们全程没记任何一个 Pod 的 IP只需要访问 Service 的入口就能稳定访问到后端服务这就是 Service 发现的威力五、总结一下Service 发现的核心就是用一个固定的 Service 入口屏蔽后端 Pod 的动态变化让服务调用变得简单、稳定。再用一句话总结Pod 是临时工IP 说变就变Service 是固定前台帮你对接所有临时工kube-proxy 是前台管家实时维护名单保证流量不迷路。希望这篇大白话讲解能帮你彻底搞懂 K8s Service 发现如果有疑问欢迎在评论区留言交流