第二大脑

主题

2026-08-24
616
2.3m

Kubernetes Service 与服务发现 ​

一句话机制 ​

Pod IP 是动态分配、不固定的，不能直接拿来访问。Service 把提供相同服务的 Pod 聚合起来，提供一个稳定统一的访问入口；Service 本身只是个概念，真正把虚拟入口转成真实转发规则的是每个 Node 上的 kube-proxy。

kube-proxy 三种工作模式 ​

模式机制特点
userspace为每个 Service 分配监听端口，kube-proxy 充当四层负载均衡器转发稳定但效率低（用户态/内核态来回切）
iptableskube-proxy 只写 iptables 规则，ClusterIP 直接重定向为 Pod IP高效，但 LB 策略不灵活
ipvs监控 Pod 变化、写 ipvs 规则转发效率更高，支持更多 LB 算法（推荐）

Service 五种类型 ​

类型用途
ClusterIP（默认）集群内虚拟 IP，仅集群内部可访问
NodePort把 Service 映射到每个 Node 的端口（30000–32767），供外部访问
LoadBalancer借助外部负载均衡设备分发（需云环境支持）
ExternalName把集群外部服务引入集群内使用
Headless（clusterIP=None）不分配 IP，Pod 解析 serviceName.namespace 直接得到 Pod IP

Endpoint：Service 与 Pod 的桥梁 ​

Endpoint 是存于 etcd 的资源对象，记录一个 Service 对应的所有 Pod IP。Service 与 Pod 的联系通过 Endpoint 实现——selector 决定代理哪些 Pod，Endpoints 记录它们的真实 IP。

不变量 ​

  1. Service 是「规则」，不是「进程」。真正起转发作用的是 kube-proxy（及其写下的 iptables/ipvs 规则），Service 只是声明式描述。
  2. 集群内解析 serviceName 得到的是 ClusterIP，不是 Pod IP；ClusterIP 是虚拟 IP，由规则重定向到真实 Pod。
  3. Pod 被摘流量 = readiness 探针失败 → 从 Endpoint 移除，这正是 [Kubernetes Pod与探针机制](./Kubernetes Pod与探针机制) 里 readiness 的落点。

常见误解 ​

  • ❌ 「Service 就是一个反向代理进程」——错。Service 没有实体进程，靠 kube-proxy 写的网络规则工作。
  • ❌ 「ClusterIP 能 ping 通」——错。它是虚拟 IP，只在规则表里存在，不绑定任何网卡。
  • ❌ 「NodePort 和 LoadBalancer 一回事」——错。NodePort 用 Node 自身端口，LoadBalancer 额外依赖集群外的负载均衡设备。
  • ❌ 「Service 直接知道 Pod」——错。中间隔着 Endpoint 对象，Service 通过它间接关联 Pod。

关联 ​

最近更新