新手学习K8s：Service 核心原理与全套实操实验手册

前言

本手册专为Kubernetes入门进阶学习者打造，完整覆盖Service核心底层原理、四大核心类型、流量转发机制、负载均衡策略及全套落地实操实验。所有实验基于通用K8s集群（1.24+版本兼容），步骤极简、可复现、可直接用于生产环境参考，同时适配面试核心考点与企业实战场景。

手册目标：读懂Service底层逻辑、熟练掌握各类Service部署、排查网络通信问题、理解K8s集群服务发现核心机制。

第一章 K8s Service 核心原理 1.1 Service 是什么？

K8s Pod 是临时、动态的资源，Pod 会因重启、扩容、缩容、节点故障等场景发生销毁重建，重建后Pod的IP地址会发生变化，无法作为稳定的服务访问入口。

Service 核心作用：为一组功能相同的Pod提供固定、稳定的统一访问入口，实现服务发现、流量负载均衡、后端Pod动态适配，屏蔽底层Pod的动态变化。

简单总结：Pod是真实业务载体，Service是Pod的统一代理和流量入口，解耦客户端与后端业务Pod。

1.2 Service 核心特性

• 固定IP与端口：Service创建后集群内IP（ClusterIP）永久不变，生命周期内不随Pod变动而改变

• 自动服务发现：通过标签选择器（selector）关联后端Pod，自动感知Pod增减、重建

• 内置负载均衡：集群内默认实现TCP/UDP四层负载均衡，自动分发流量到后端健康Pod

• 健康检查与故障剔除：自动剔除异常、未就绪的Pod，保证流量只转发到正常节点

Service功能由K8s三大核心组件联动实现：

1. kubeapiserver：接收Service资源创建请求，存储Service、Endpoint资源信息到etcd

1. kubecontrollermanager：持续监听Service与Pod资源，根据selector匹配Pod，自动更新Endpoint列表（后端Pod地址集合）

1. kubeproxy：运行在每个集群节点，监听Endpoint变化，实时刷新节点内核转发规则（iptables/ipvs），实现流量转发

Endpoint是Service的核心关联资源，每一个Service都会自动对应一个同名Endpoint资源。

Endpoint作用：存储当前Service关联的所有健康就绪的Pod IP+端口列表。

核心逻辑：

• 控制器通过Service的selector标签匹配Pod

• 筛选状态为Ready的Pod，将其IP、端口写入Endpoint

• Pod故障/重启/标签变更时，Endpoint列表自动更新

• kube-proxy根据Endpoint列表生成流量转发规则

结论：Service不直接绑定Pod，通过Endpoint间接关联Pod，实现动态解耦。

1.3.3 kube-proxy 三种工作模式

kube-proxy是Service流量转发的核心载体，支持三种模式，生产环境首选IPVS模式。

1、userspace 模式（废弃）

早期模式，流量先经过用户态kube-proxy进程转发，内核态与用户态频繁切换，性能极差，已被淘汰。

2、iptables 模式（默认基础模式）

通过Linux内核iptables规则实现流量转发，无需用户态中转，性能优于userspace。

缺点：规则数量庞大时匹配效率低，负载均衡算法简单（随机），大规模集群性能较差。

3、ipvs 模式（生产首选）

基于Linux内核IPVS模块实现四层负载均衡，支持多种负载均衡算法，规则检索效率极高，支持大规模集群。

支持算法：轮询、加权轮询、最小连接、哈希等，生产环境强制推荐。

1.4 Service 四大核心类型

类型

核心特点

访问范围

适用场景

ClusterIP（默认）

分配集群内部虚拟IP，仅集群内访问

集群内部Pod、节点访问

微服务内部互相调用（90%内网服务）

NodePort

暴露节点端口，集群所有节点开启统一端口

集群内外均可通过节点IP+端口访问

测试环境、临时对外暴露服务

LoadBalancer

依赖云厂商负载均衡器，分配公网IP

公网直接访问

云集群生产环境对外提供服务

ExternalName

无IP、无端口，仅域名转发

集群内访问外部域名

集群内服务调用外部第三方域名

1.5 Service 流量负载均衡策略

• 默认策略（Cluster模式）：流量均匀分发到所有就绪后端Pod，集群内跨节点调度，无会话保持，会丢失客户端真实源IP

• Local模式：流量只转发到当前节点上的后端Pod，保留源IP，减少跨节点网络开销，适合高性能、需要溯源客户端IP的业务场景

• K8s集群版本：1.24+（单节点/多节点均可，minikube、k3s、自建集群、云厂商ACK/EKS通用）

• 集群网络正常，kube-proxy组件正常运行，无报错重启

• 本地客户端可正常执行kubectl命令，拥有足够的资源创建、查询、修改权限

执行以下命令校验集群状态，提前规避实验异常，确保后续实操顺利进行：

# 查看集群节点状态，确保所有节点Ready
kubectl get nodes

 # 查看kube-proxy组件运行状态，确保全部Pod正常运行
kubectl get pods -n kube-system | grep kube-proxy

 # 查看kube-proxy工作模式，确认当前转发模式
kubectl logs -n kube-system $(kubectl get pods -n kube-system | grep kube-proxy | head -n1 | awk '{print $1}') | grep mode

所有Service实验统一使用Nginx测试Pod，提前创建固定部署，作为所有Service的后端服务载体，无需重复创建。

创建资源文件：nginx-deploy.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
  labels:
    app: nginx-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx-service
  template:
    metadata:
      labels:
        app: nginx-service
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

执行部署命令并验证Pod运行状态：

# 应用部署资源
kubectl apply -f nginx-deploy.yaml


 # 查看Pod运行状态，确保全部处于Running就绪状态
kubectl get pods -o wide

实验目标：掌握默认ClusterIP服务创建、内网访问、Endpoint关联机制、四层负载均衡效果，理解核心内网服务通信原理。

1、创建ClusterIP Service

创建资源文件：service-clusterip.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-clusterip
spec:
  type: ClusterIP
  selector:
    app: nginx-service # 匹配上述Nginx Pod标签，关联后端业务Pod
  ports:
  - port: 80        # Service集群内统一访问端口
    targetPort: 80  # 后端Pod容器监听端口

# 应用Service资源
kubectl apply -f service-clusterip.yaml

 # 查看Service基础信息，获取固定ClusterIP
kubectl get svc

 # 查看Service详细配置、标签匹配规则、端点绑定状态
kubectl describe svc nginx-clusterip

# 查看自动生成的Endpoint，验证是否绑定3个就绪Pod IP
kubectl get endpoints nginx-clusterip


 # 详细查看端点地址、就绪状态，确认关联正常
kubectl describe endpoints nginx-clusterip

启动临时busybox测试Pod，循环访问Service ClusterIP，验证负载均衡轮询效果：

# 启动临时测试Pod，自动销毁退出
kubectl run test-box --image=busybox:latest --rm -it -- sh


 # 循环访问Service集群IP，观察流量分发到不同Pod
while true; do wget -q -O- 【ClusterIP】; echo ""; sleep 1; done

• ClusterIP为集群内网专属服务，外网无法直接连通访问，安全性更高

• 默认实现轮询负载均衡，流量均匀分发到后端所有就绪Nginx Pod

• 手动删除任意一个Pod，控制器会自动重建Pod，Endpoint自动剔除故障节点、更新健康节点，业务流量不中断

实验目标：掌握NodePort端口映射规则、集群节点外网访问方式、自定义端口范围，理解NodePort与ClusterIP的层级关系。

1、创建NodePort Service

创建资源文件：service-nodeport.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-nodeport
spec:
  type: NodePort
  selector:
    app: nginx-service
  ports:
  - port: 80
    targetPort: 80
    nodePort: 30080 # 自定义节点对外端口，固定范围30000-32767

# 部署NodePort服务
kubectl apply -f service-nodeport.yaml


 # 查看服务端口、IP信息
kubectl get svc nginx-nodeport

通过任意集群节点IP+30080端口即可访问服务，单节点故障不影响整体访问：

# 集群节点本地访问测试
curl 127.0.0.1:30080


 # 外网机器通过节点公网IP访问服务
curl 【节点公网IP】:30080

• 集群所有节点会统一监听配置的NodePort端口，任意节点均可转发流量，具备节点容错能力

• NodePort底层依然依赖ClusterIP+Endpoint实现负载均衡，是内网服务的外网延伸

• 不手动指定nodePort时，K8s会自动在30000-32767区间随机分配端口

实验说明：该类型仅**云厂商K8s集群（阿里云ACK、腾讯云EKS、AWS EKS）**支持，裸金属、本地自建集群无法使用，需依赖云厂商LB插件。

1、创建LoadBalancer Service

创建资源文件：service-loadbalancer.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx-lb
spec:
  type: LoadBalancer
  selector:
    app: nginx-service
  ports:
  - port: 80
    targetPort: 80

# 部署云负载均衡服务
kubectl apply -f service-loadbalancer.yaml


 # 查看服务状态，等待公网IP分配
kubectl get svc nginx-lb

等待1-3分钟，服务STATUS字段显示公网IP后，可直接通过公网IP+端口访问服务。

3、实验结论

LoadBalancer 是 NodePort 的生产级增强版，可自动对接云厂商负载均衡组件，分配独立固定公网IP，支持公网流量管控、高可用容错、流量监控等能力，是云原生集群对外提供生产服务的首选方案。

实验四：ExternalName 域名转发实验

实验目标：实现集群内服务通过固定Service域名访问外部第三方域名，统一管理外部依赖地址，规避硬编码问题。

1、创建ExternalName Service

创建资源文件：service-externalname.yaml

apiVersion: v1
kind: Service
metadata:
  name: external-demo
spec:
  type: ExternalName
  externalName: www.baidu.com # 需转发的外部公共域名

# 部署域名转发服务
kubectl apply -f service-externalname.yaml

 # 进入临时测试Pod
kubectl run test-box --image=busybox:latest --rm -it -- sh

 # 通过Service内置域名解析访问外部百度域名
ping external-demo.default.svc.cluster.local
curl external-demo.default.svc.cluster.local

• 无ClusterIP、无监听端口、无Endpoint关联资源，仅为DNS解析规则

• 仅实现DNS域名CNAME转发，纯域名解析能力，无流量转发、负载均衡功能

• 适合统一管理集群内所有外部依赖服务地址，后续修改外部域名仅需更新Service配置，无需修改业务代码

实验目标：掌握两种流量策略的核心差异、适用场景，解决生产源IP丢失、跨节点流量开销问题。

1、修改Service流量策略

Cluster模式（默认模式，支持跨节点转发）：

spec:
  externalTrafficPolicy: Cluster

Local模式（仅本节点转发，保留客户端源IP）：

spec:
  externalTrafficPolicy: Local

• Cluster模式：流量可跨节点分发到集群内所有就绪Pod，负载均衡更均衡，但会丢失客户端真实源IP，适合通用业务场景

• Local模式：流量仅转发至当前节点的就绪Pod，不跨节点传输，保留客户端真实源IP，网络开销更低，适合高性能、需要IP溯源、安全校验的业务场景

遇到Service访问超时、无法连通、流量异常等问题，严格按照以下顺序排查，快速定位故障根源：

1. 检查Pod状态：确保所有后端Pod处于Ready就绪状态，无频繁重启、镜像拉取失败、资源不足等异常

1. 检查标签匹配：核对Service的selector标签与后端Pod标签完全一致，标签不匹配会导致无法关联Pod

1. 检查Endpoint资源：Endpoint无地址、地址不全，说明标签不匹配或Pod未就绪，是最常见故障点

1. 检查kubeproxy组件：确认所有节点kube-proxy Pod正常运行，无报错、无崩溃，转发规则刷新正常

1. 检查端口配置：核对Service port、targetPort、nodePort配置无误，端口未冲突、未超出范围

1. 检查网络策略：确认集群NetworkPolicy未拦截服务访问流量，节点防火墙端口未封禁

# 查看所有Service资源
kubectl get svc -A

 # 查看Service详细配置与事件
kubectl describe svc 【service名称】

 # 查看Endpoint详细绑定地址
kubectl get endpoints 【service名称】 -o wide

 # 实时监控Service、Pod状态变化
watch kubectl get pods,svc,endpoints

 # 重启kube-proxy刷新转发规则（故障修复常用）
kubectl rollout restart daemonset kube-proxy -n kube-system