Kubernetes Service 通过 label selector 动态匹配 Pod 并自动同步至 Endpoints，再由 kube-proxy（IPVS/iptables 模式）实现四层负载均衡；支持 ClusterIP、NodePort、LoadBalancer 和 ExternalName 四种类型，适配不同访问场景。
Service 如何关联后端 Pod
Service 通过 label selector 动态匹配 Pod。只要 Pod 拥有与 Service 中 selector 完全一致的标签，就会被自动加入其 Endpoints 列表。这个过程无需人工干预，Pod 新建、销毁或重启时，Endpoints 会实时同步更新。
- 创建 Deployment 时定义 Pod 标签（如
app: nginx） - Service 的
spec.selector设置相同标签 - Kubernetes 自动发现并生成对应的 Endpoints 对象
- 运行
kubectl get endpoints <service-name>可查看当前活跃的 Pod IP 列表
四种 Service 类型对应不同发布场景
选择哪种类型，取决于服务要暴露给谁、在什么网络环境下：
- ClusterIP：默认类型，仅集群内部可访问。适合微服务间调用，例如前端 Pod 访问后端 API Pod
- NodePort：在每个节点的固定端口（默认 30000–32767）开放服务。外部用户可通过任意节点 IP + NodePort 访问，适合测试环境或私有云
- LoadBalancer：依赖云厂商提供外部负载均衡器（如 AWS ELB、阿里云 SLB），自动分配公网 IP。适用于生产环境对外发布
-
ExternalName：不指向集群内 Pod，而是返回 CNAME 记录，将请求重定向到集群外域名（如
api.example.com）
负载均衡实际由 kube-proxy 驱动
Service 的虚拟 IP（ClusterIP）不能直接响应网络包，它只是一个抽象地址。真正处理流量的是运行在每个节点上的 kube-proxy 组件，它监听 Service 和 Endpoints 变化，并将规则写入内核：
Kubernetes Skills
下载
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- IPVS 模式（推荐）：v1.8+ 默认启用（需内核支持），基于 netfilter 的高效哈希表，支持 rr、lc、dh、sh 等多种调度算法，吞吐高、连接跟踪开销小
- iptables 模式：早期主流，规则链长、大规模 Service 下性能下降明显，已逐步被 IPVS 替代
- userspace 模式：v1.1 引入，现已弃用，性能差且不支持连接保持
可通过 kubectl get configmap -n kube-system kube-proxy -o yaml 查看当前使用的代理模式。
让服务更可靠：配合探针和会话保持
单纯暴露端口还不够，真实业务需要健康检查和连接稳定性：
- 在 Pod 模板中配置
livenessProbe和readinessProbe，确保只将健康 Pod 加入 Endpoints - Service 支持
sessionAffinity: ClientIP，实现基于源 IP 的会话保持，适合有状态轻量级场景（如登录态缓存） - 若需更精细控制（如 cookie 保持、路径路由），应配合 Ingress 使用，Service 本身只做四层转发
