Kubernetes Service 与网络代理

Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理

引言

在 Kubernetes 中，Pod 是最小的调度单元，但 Pod 的 IP 是临时的，一旦重建，IP 就会发生变化。这就带来了一个致命问题：如果前端应用需要访问后端服务，该如何在 IP 不断变化的情况下找到后端？

为了解决这个问题，Kubernetes 引入了 Service（服务） 概念，为一组提供相同功能的 Pod 提供一个统一、固定的访问入口。而底层负责将 Service 的流量真正转发到 Pod 的，则是 kube-proxy 这个核心网络代理组件。

本文将带你从 VS Code 的高效开发环境配置开始，深入拆解 Service 的核心原理、服务发现机制、多种服务类型，并深入内核剖析 kube-proxy 的 iptables 与 IPVS 工作模式。

### 文章目录

[Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[引言](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[@ $toc$ ](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[一、工欲善其事：VS Code 配置 K8s 开发环境](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[1.1 安装核心扩展](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[1.2 配置本地环境](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[1.3 智能编写 YAML](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[二、Service 核心概念与基本管理](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[2.1 为什么需要 Service？（痛点剖析）](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[2.2 创建与验证 Service](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[三、Service 的三种服务发现机制](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[3.1 通过 IP 访问](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[3.2 通过环境变量访问](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[3.3 通过 DNS 访问（推荐）](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[四、Service 的四种类型与特殊模式](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[4.1 ClusterIP（默认）](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[4.2 NodePort](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[4.3 LoadBalancer](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[4.4 ExternalName](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[4.5 Headless 无头服务](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[五、进阶实战：会话保持与金丝雀发布](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[5.1 会话保持 (Session Affinity)](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[5.2 金丝雀发布 (Canary Deployment)](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[六、底层探秘：kube-proxy 网络代理](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[6.1 工作模式对比](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[6.2 切换 IPVS 模式](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[6.3 IPVS 模式深度解析](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)
[6.4 iptables 模式深度解析](#文章目录 Kubernetes Service 与网络代理深度实战：从服务发现到 kube-proxy 原理引言 @[toc] 一、工欲善其事：VS Code 配置 K8s 开发环境 1.1 安装核心扩展 1.2 配置本地环境 1.3 智能编写 YAML 二、Service 核心概念与基本管理 2.1 为什么需要 Service？（痛点剖析） 2.2 创建与验证 Service 三、Service 的三种服务发现机制 3.1 通过 IP 访问 3.2 通过环境变量访问 3.3 通过 DNS 访问（推荐）四、Service 的四种类型与特殊模式 4.1 ClusterIP（默认） 4.2 NodePort 4.3 LoadBalancer 4.4 ExternalName 4.5 Headless 无头服务五、进阶实战：会话保持与金丝雀发布 5.1 会话保持 (Session Affinity) 5.2 金丝雀发布 (Canary Deployment) 六、底层探秘：kube-proxy 网络代理 6.1 工作模式对比 6.2 切换 IPVS 模式 6.3 IPVS 模式深度解析 6.4 iptables 模式深度解析)

一、工欲善其事：VS Code 配置 K8s 开发环境

在编写 K8s 资源时，纯靠手写 YAML 极易出错，利用 VS Code 的智能提示可以大幅提升效率。

1.1 安装核心扩展

你需要安装以下两个扩展：

YAML by Red Hat：提供通用的 YAML 语法校验、格式化、悬停文档。
Kubernetes by Microsoft ：提供 K8s 专属的工作台，它会自动依赖并安装 YAML 扩展。它支持集群资源树视图、实时日志、端口转发，并能从集群缓存 CRD 的 Schema 以实现补全。

1.2 配置本地环境

下载对应系统的 kubectl.exe，放入 $HOME\.kube\ 目录并加入环境变量 PATH。
将集群的凭据文件 config 放入 $HOME\.kube\config。

【 1：验证连接】

在 VS Code 的 Kubernetes 面板中，你就能看到集群的节点和资源，也可以在终端执行 kubectl get nodes 验证。

1.3 智能编写 YAML

【 2：快速生成 Deployment 资源模板】

在新建的 .yaml 文件中输入字母 deploy，VS Code 会自动联想，选择 Kubernetes Deployment 即可生成标准模板。在需要补全的关键字右侧加个冒号（如 imagePullPolicy:），按下空格，就会弹出 Always、IfNotPresent、Never 的选项。写完直接右键 Apply 即可创建资源。

二、Service 核心概念与基本管理

2.1 为什么需要 Service？（痛点剖析）

Pod 是临时资源。如果使用 Deployment 管理多个 Pod，Pod 的 IP 随时会变。且如果直接暴露 Pod 的 IP 给外部，会面临两个致命问题：

【 3：直接暴露裸 Pod 的痛点】

bash 复制代码

# 1. 创建 Pod
kubectl run web --image=httpd --image-pull-policy=IfNotPresent
kubectl get pod -o wide
# 输出：web 1/1 Running 0 10s 10.224.51.149 worker31

痛点 1 ：客户端如果直接用 10.224.51.149 访问，这个 IP 只是集群内部的虚拟 IP（如 Calico 分配），集群外部节点根本无法直接访问。
痛点 2 ：如果使用 hostPort 将 Pod 端口映射到宿主机，一旦 Deployment 起了 4 个副本，而宿主机只有 2 台，就会因为端口冲突导致 Pod 创建失败（Pending）。

【 4：hostPort 冲突导致 Pending】

yaml 复制代码

# 在 Deployment 的 YAML 中加入 hostPort: 8080
ports:
- containerPort: 80
  hostPort: 8080

bash 复制代码

kubectl apply -f deploy-web.yml
kubectl get pod
# 看到 2 个 Running，2 个 Pending
kubectl describe pod web-79fc679949-2tr7x
# 报错：2 node(s) didn't have free ports for the requested pod ports.

Service 的作用：为一组 Pod 提供一个固定的 ClusterIP 和 DNS 名称，并自动维护与后端 Pod 的映射关系，实现负载均衡。

2.2 创建与验证 Service

【 5：通过命令行创建 ClusterIP 类型的 Service】

bash 复制代码

# 先创建 3 个副本的 Deployment
kubectl create deployment web --image=httpd --replicas=3

# 创建 Service，将 Service 的 8080 端口转发到 Pod 的 80 端口
kubectl create service clusterip web --tcp=8080:80

# 查看 Service 的详细信息（重点关注 Endpoints 是否绑定了真实的 Pod IP）
kubectl describe service web
# IP: 10.103.19.150
# Endpoints: 10.224.193.67:80, 10.224.193.68:80, 10.224.41.131:80

【 6：验证负载均衡并观察标签的动态匹配】

bash 复制代码

# 给每个 Pod 的主页写入自己的名字
for pod in $(kubectl get pods -o name | awk -F/ '{print $2}'); do 
    kubectl exec -it $pod -- bash -c "echo $pod > htdocs/index.html"
done

# 循环访问 60 次，统计结果
for i in {1..60}; do curl -s 10.103.19.150:8080; done | sort | uniq -c
# 输出结果会显示 3 个 Pod 各被访问了大约 20 次，证明 Service 负载均衡生效。

# 动态添加一个相同标签的 Pod
kubectl run web-standalone --image=httpd -l app=web
for i in {1..60}; do curl -s 10.103.19.150:8080; done | sort | uniq -c
# 此时结果会变成 4 个 Pod 均分流量，说明 Service 的 Endpoints 会自动发现同标签的 Pod。

【 7：Deployment 与 Service 的标签解耦】

可以给 Pod 打上多个标签（如 app1=web1, app2=web2）。Deployment 使用 app1=web1 来管理 Pod，而 Service 可以使用 app2=web2 来选择 Pod，两者解耦，互不干扰。

bash 复制代码

kubectl expose deployment web --port=8080 --target-port=80 --selector=app2=web2

【 8：为什么 Service IP 无法 Ping 通？】

Service IP 是虚拟的，kube-proxy 底层只针对 TCP/UDP 等四层协议做了 iptables 规则映射，没有为 ICMP 协议做映射 ，因此 ping Service IP 会不通，但 curl 特定的端口是可以通的。

三、Service 的三种服务发现机制

集群内的 Pod 如何访问 Service？主要有三种方式。

3.1 通过 IP 访问

最简单粗暴的方式，直接使用 Service 的 ClusterIP。

【 9：WordPress 通过 IP 连接 MySQL】

bash 复制代码

# 创建 MySQL 并暴露为 Service，获取 ClusterIP 为 10.111.69.45
# 创建 WordPress 时，直接指定数据库地址
kubectl run wordpress --image=wordpress \
--env=WORDPRESS_DB_HOST=10.111.69.45

缺点：一旦 MySQL 的 Service 重建导致 IP 改变，WordPress 就连不上了。

3.2 通过环境变量访问

Pod 创建时，K8s 会将其所在 namespace 中已存在的 Service 信息注入到环境变量中。

【 10：验证环境变量注入】

bash 复制代码

kubectl run test --rm -it --image=busybox sh
# 在容器内执行：
env | grep MYSQL
# 输出：MYSQL_SERVICE_HOST=10.111.69.45

注意：环境变量方式要求 Service 必须在 Pod 创建之前存在。且 Service 和 Pod 必须在同一个 namespace 下。

3.3 通过 DNS 访问（推荐）

K8s 默认部署了 CoreDNS 组件，自动为 Service 添加 DNS 记录。格式为：<service-name>.<namespace-name>.svc.cluster.local。

【 11：同命名空间直接使用短域名】

bash 复制代码

kubectl run busybox --rm -it --image=busybox sh
# 在同一个 namespace 下，直接 wget 服务名即可
wget wordpress:80

【 12：跨命名空间使用全域名】

bash 复制代码

# 假设 wordpress 在 default 命名空间，而测试 Pod 在 session 命名空间
kubectl run busybox -n session --rm -it --image=busybox sh
# 在容器内执行：
wget wordpress.default.svc.cluster.local:80

四、Service 的四种类型与特殊模式

4.1 ClusterIP（默认）

只能在集群内部访问。ClusterIP 从预留的 IP 池中分配，也允许手动指定（需合法且在 service-cluster-ip-range 范围内）。

4.2 NodePort

在每个物理节点上开放一个相同的端口（范围 30000-32767），外部可通过 节点IP:NodePort 访问。

【 13：创建 NodePort 服务并验证】

bash 复制代码

kubectl expose deployment web --type NodePort --port=8080 --target-port=80
kubectl get svc web
# 输出：web NodePort 10.110.40.0 <none> 8080:31917/TCP

# 外部客户端访问任意节点的 31917 端口均可通
curl http://10.1.8.30:31917
curl http://10.1.8.31:31917

【 14：固定 NodePort 端口】

在 YAML 中显式指定 nodePort: 30080，避免随机分配。

【 15：底层 iptables 规则分析】

kube-proxy 会在节点增加一条 KUBE-NODEPORTS 链的规则，随后流量流入 KUBE-SVC 链，被负载均衡到各个 Pod 的 KUBE-SEP 链：

bash 复制代码

iptables-save | grep 31917
# 规则：-A KUBE-NODEPORTS -p tcp --dport 31917 -j KUBE-SVC-WE5D4GWSX3MMPCHH

4.3 LoadBalancer

Kubernetes 本身不实现 LoadBalancer，需要借助第三方工具（如 MetalLB）。

【 16：通过 MetalLB 实现 LoadBalancer】

部署 MetalLB 并配置 IP 池（如 10.1.8.40-10.1.8.80）。
创建 Service，type: LoadBalancer。
查看 Service，EXTERNAL-IP 会分配到一个真实的物理网段 IP（如 10.1.8.40）。
客户端直接访问 http://10.1.8.40:80 即可访问。
原理：MetalLB 通过 ARP 宣告该 IP 归属于集群某节点，流量到达节点后，依然由 kube-proxy 完成最终转发。

4.4 ExternalName

将集群内的服务映射到外部域名（CNAME）。

【 17：映射到外部网站】

yaml 复制代码

apiVersion: v1
kind: Service
metadata:
  name: www
spec:
  type: ExternalName
  externalName: www.xianyu.cloud

集群内 Pod 访问 www，DNS 会返回 www.xianyu.cloud，流量直接在 DNS 层面重定向，不经过 kube-proxy 代理。

4.5 Headless 无头服务

当 ClusterIP 设置为 None 时，K8s 不会分配 IP，kube-proxy 也不处理。DNS 会直接返回后端所有 Pod 的 IP（A 记录），适合有状态服务（如数据库集群）。

【 18：利用 dig 查询 Headless Service】

bash 复制代码

# 创建 Headless Service
apiVersion: v1
kind: Service
metadata:
  name: mysql-headless
spec:
  clusterIP: None
  selector:
    app: mysql
  ports:
  - port: 3306

# 用 busybox 解析该域名
kubectl run busybox --rm -it --image=busybox sh
nslookup mysql-headless
# 输出会直接列出所有后端 MySQL Pod 的 IP，而不是返回一个虚拟 IP。

五、进阶实战：会话保持与金丝雀发布

5.1 会话保持 (Session Affinity)

默认情况下，Service 会随机轮询。如果需要确保某个客户端始终访问同一个 Pod，可以开启基于客户端 IP 的会话保持。

【 19：开启会话保持并对比验证】

bash 复制代码

# 1. 默认轮询测试，20次请求落在 2 个 Pod 上
for i in {1..20}; do curl -s 10.111.90.183; done | sort | uniq -c
# 输出：10 web-5gbx2, 10 web-b8f7l

# 2. 开启会话保持
kubectl patch svc web -p '{"spec":{"sessionAffinity":"ClientIP"}}'

# 3. 再次测试
for i in {1..20}; do curl -s 10.111.90.183; done | sort | uniq -c
# 输出：20 web-5gbx2 （源 IP 相同的请求，全都打到了同一个 Pod）

5.2 金丝雀发布 (Canary Deployment)

利用标签匹配和副本数比例，在一个 Service 下同时挂载新旧两个版本的 Pod，实现流量灰度。

【 20：逐步调整副本数实现灰度】

创建旧版本 Deployment web-28，replicas: 10，标签为 track: stable。
创建 Service，Selector 选择 app: web, tier: frontend（不限制 track）。
创建新版本 Deployment web-29，replicas: 1，标签为 track: canary。
此时 11 个 Pod 都在 Service 的后端，新版本大概接收约 9% 的流量。
观察新版本稳定后，逐步调整副本数：

bash 复制代码

kubectl scale deployment web-28 --replicas 8
kubectl scale deployment web-29 --replicas 2
# 此时新版本接收约 20% 的流量，持续观察无误后，最终可以将旧版本缩容至 0。

六、底层探秘：kube-proxy 网络代理

kube-proxy 是 K8s 网络的核心，负责将 Service 的流量转发到 Endpoints。

6.1 工作模式对比

Userspace ：用户态转发，性能极低，K8s 1.25+ 已彻底移除。
iptables：默认模式，依赖内核 Netfilter。服务数量超过 1000 时，规则链膨胀，性能显著下降。
IPVS：推荐模式，基于内核哈希表，性能极高，支持十万级服务。

6.2 切换 IPVS 模式

【 21：将 kube-proxy 切换为 IPVS】

bash 复制代码

# 1. 修改 ConfigMap
kubectl edit configmap -n kube-system kube-proxy
# 将 mode: "" 改为 mode: "ipvs"

# 2. 重启 DaemonSet
kubectl rollout restart daemonset -n kube-system kube-proxy

# 3. 查看日志验证
kubectl logs -n kube-system <kube-proxy-pod-name> | grep Using
# 输出 "Using ipvs Proxier" 即成功

6.3 IPVS 模式深度解析

【 22：查看 IPVS 虚拟服务与调度算法】

bash 复制代码

ipvsadm -Lnt 10.103.143.120:80
# 输出：显示虚拟服务器 IP，以及轮询（rr）策略和挂载的后端 Pod Real Server
# TCP  10.103.143.120:80 rr
#   -> 10.224.19.38:80  Masq 1 0 0

# 修改调度算法为加权轮询 (wrr)
kubectl edit configmap kube-proxy -n kube-system
# 找到 scheduler: "wrr"

rr：轮询
wrr：加权轮询（权重与 Pod 的 resources.requests.cpu/memory 成正比）

6.4 iptables 模式深度解析

iptables 模式通过串联多条自定义链来完成 DNAT 转换，逻辑极其复杂。

【 23：追踪 iptables 随机分流规则】

bash 复制代码

iptables-save | grep KUBE-SVC-7D76YWGERGEPC4GC
# 看到如下规则：
-A KUBE-SVC-7D76YWGERGEPC4GC -m statistic --mode random --probability 0.33333333349 -j KUBE-SEP-HYZM2VM7RCC7M2HX
-A KUBE-SVC-7D76YWGERGEPC4GC -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-CHPZVFCOFL4YLCYM
-A KUBE-SVC-7D76YWGERGEPC4GC -j KUBE-SEP-HM7RLUR2RXSQ3D6F

原理剖析 ：这就是为什么 Service 能实现负载均衡的底层秘密。iptables 对目标端口为 80 的流量，先以 1/3 的概率跳转到 Pod A（KUBE-SEP 链），剩下未匹配的流量再以 1/2（即总概率 1/3）跳转到 Pod B，最后剩下的无条件跳转到 Pod C。

【 24：追踪最终 DNAT 动作】

bash 复制代码

iptables-save | grep KUBE-SEP-HYZM2VM7RCC7M2HX
# 输出：-A KUBE-SEP-HYZM2VM7RCC7M2HX -p tcp -j DNAT --to-destination 10.224.113.164:80

在这里，目标 IP 被真正改写成了 Pod 的 IP。