一、IPVS规则特性与ClusterIP模式选型
- 每个K8s节点的IPVS规则仅会被当前节点的客户端访问，其他节点的客户端访问自身所在节点的IPVS规则，因此单节点IPVS规则规模不会超过300条（受单节点最大Pod数量限制），性能影响可忽略。
- 对比多种Service模式后，ClusterIP模式兼具性能充足、端口灵活性高的优势，是集群内部服务访问的首选方案。
二、实验前置操作
- 清理之前创建的Deployment资源
- 清理之前创建的Service资源
三、Service默认规则说明
- 通过
kubectl create service命令创建的Service，默认selector规则为匹配app=<service名称>的标签；若修改Service名称，默认selector会同步更新。 - 自定义YAML编写Service时，可自由配置selector规则。
四、实验资源编写
4.1 Deployment资源（my-deploy.yaml）
- 基础配置：apiVersion为apps/v1，kind为Deployment，命名空间为default，副本数为3
- selector配置：matchLabels为
app: my-app，需与Pod模板的标签为子集关系，且与Service同命名空间 - Pod模板配置：
- 标签为
app: my-app，与selector匹配 - 容器配置：名称为my-app-container，镜像为my-app:v1.0，镜像拉取策略为IfNotPresent（本地存在则不拉取），定义名为http、端口为80的容器端口（仅作为Service引用别名，无实际业务意义）
- 标签为
- 可复用Pod生命周期特性：在Pod模板的
spec.containers层级下，可添加就绪探测（readinessProbe）等配置，示例就绪探测配置：
readinessProbe:
httpGet:
path: /index.html
port: 80
initialDelaySeconds: 3
periodSeconds: 5- 就绪探测逻辑：检测80端口的
/index.html页面，初始延迟3秒后每5秒探测一次 - 若就绪探测失败，Pod状态为NotReady，不会进入Service的endpoints列表，无法被负载均衡
- 就绪探测逻辑：检测80端口的
4.2 Service资源（my-svc.yaml）
- 基础配置：apiVersion为v1，kind为Service，命名空间为default
- 类型配置：type为ClusterIP（默认不指定type时自动为ClusterIP）
- selector配置：匹配
app: my-app标签，关联对应Deployment的Pod - 端口配置：定义名为http的端口，集群访问端口为80，后端Pod targetPort为80
五、资源创建与验证
- 1. 创建Deployment资源：执行kubectl apply -f my-deploy.yaml创建Deployment，初始3个Pod均为NotReady状态（因镜像中无/index.html文件，就绪探测失败）
- 2. 创建Service资源：执行kubectl apply -f my-svc.yaml创建Service，验证信息：
- 自动分配ClusterIP（如10.15.50.122）
- 类型为ClusterIP，集群端口为80
- endpoints为空（无符合要求的Ready Pod）
- 3. 触发就绪探测通过： - 进入Pod内部：
kubectl exec -it <pod名称> -- /bin/bash - 进入Nginx默认静态资源目录
/usr/local/nginx/html/ - 执行
echo "test" > index.html创建探测所需文件，退出Pod - 验证Pod状态变为Ready，Service的endpoints自动添加该Pod的IP与端口
- 4. 验证全量就绪：为剩余2个Pod重复执行上述操作，验证3个Pod全部Ready，endpoints包含3个后端Pod；查看IPVS规则，80端口的真实服务器数量为3，负载均衡算法为轮询
六、Service两种访问方式
6.1 直接访问ClusterIP
- 执行
kubectl get svc获取Service的ClusterIP，直接访问即可，默认采用轮询策略负载均衡到后端Pod
6.2 通过DNS域名访问
- 域名格式：
<service名称>.<命名空间>.svc.<集群域名>，默认集群域名为cluster.local，末尾的点可省略 - 示例：my-clusterip.default.svc.cluster.local
- 集群内部Pod默认DNS指向CoreDNS插件，无需额外配置即可解析该域名
- 验证方式：进入Pod内部执行
wget my-clusterip.default.svc.cluster.local，可正常获取服务响应 - 两种方式优缺点：
- ClusterIP：访问简单，无需拼接长域名，但Service未创建时无法提前知晓IP地址
- DNS域名：可提前预知访问地址，无需等待Service创建即可在Pod中配置访问逻辑，但域名拼接较长
七、internalTrafficPolicy配置与验证（k8s 1.26+ 稳定特性）
- 该参数用于配置Service的流量路由策略，可选值为Cluster（默认）和Local
7.1 Cluster模式（默认）
- 流量会路由到所有命名空间下符合selector的Ready Pod，无论Pod分布在哪个节点
- 任意节点访问Service均可正常获得响应，负载均衡覆盖所有后端Pod
7.2 Local模式
- 流量仅会路由到访问请求所在节点的Ready Pod；若当前节点无符合要求的Pod，流量会被直接丢弃（采用jump策略，无任何响应）
- 验证：将Service的internalTrafficPolicy修改为Local后：
- 在运行有后端Pod的节点访问Service，可正常获得响应，仅路由到当前节点的Pod
- 在无后端Pod运行的节点访问Service，请求被丢弃，无响应
- 补充说明：本次视频补录了之前录播的口误内容，演示环境为3主1从高可用集群，学员本地2主环境不影响实验操作
AI 总结
本视频为K8s Service章节的第二部分实操内容，首先结合IPVS规则的单节点访问特性讲解了ClusterIP模式的选型依据，随后通过完整的实验演示了Deployment、Service资源的创建流程，验证了就绪探测对Service endpoints的影响，对比了Service的ClusterIP和DNS域名两种访问方式的适用场景，最后实操演示了k8s 1.26版本引入的stable特性internalTrafficPolicy的Cluster和Local两种策略的差异，补全了之前录播的口误问题，帮助学员深入理解ClusterIP类型Service的核心原理与使用方法。