02.Kubernetes 学习笔记：Service 服务发现与负载均衡

三、Service 详解#

1. Service是什么，为什么需要它#

1.1 回顾Pod的问题#

在上一章，我们学会了创建Pod，并且让nginx通过数据库的IP地址（比如10.244.1.10）进行连接。但这里有个大问题：

Pod的IP是不稳定的！

想象一下这些场景：

Pod重启了，IP地址会变
Pod被调度到其他节点，IP地址会变
Pod被删除重建，IP地址还会变
Deployment管理多个Pod副本，每个Pod的IP都不一样

这就像你朋友搬家了，但没告诉你新地址。 你每次想找他，都得重新打听他住哪儿，这太麻烦了！

我们需要一个稳定的”门牌号”，无论Pod怎么变化，都能通过这个门牌号找到它。这就是Service的作用。

1.2 Service是什么#

Service（服务） 是Kubernetes中一个抽象概念，它定义了一组Pod的逻辑集合，以及访问这些Pod的策略。

用生活化的比喻来理解：

1
想象一个大型超市：
2

3
Pod = 收银员（可能会换班、休假、离职）
4
Service = 收银台的"2号窗口"标识
5

6
顾客（客户端）只需要认准"2号窗口"，
7
不用关心今天是哪个收银员在值班。
8
超市可以随意调整收银员，只要保证2号窗口有人服务就行。

Service的核心特点：

稳定的访问入口
- Service有一个固定的IP地址（ClusterIP）
- Service有一个固定的DNS名称（如：mysql-service）
- 无论后端Pod如何变化，Service的IP和名称都不变
负载均衡
- 如果有多个Pod副本，Service会自动分发流量
- 就像银行有多个窗口，叫号系统自动分配
服务发现
- 通过Service名称就能访问，无需记住IP
- 集群内的DNS自动解析Service名称

1.3 为什么需要Service#

问题1：Pod IP不稳定

1
没有Service的情况：
2
┌─────────────┐          ┌─────────────┐
3
│  Nginx Pod  │ -------> │  MySQL Pod  │
4
│             │  硬编码IP  │  10.244.1.10│
5
└─────────────┘          └─────────────┘
6
                              ↓ Pod重启
7
                         ┌─────────────┐
8
                         │  MySQL Pod  │
9
                         │  10.244.2.20│ <- 新IP，nginx连不上了！
10
                         └─────────────┘
11

12
有Service的情况：
13
┌─────────────┐          ┌──────────────┐          ┌─────────────┐
14
│  Nginx Pod  │ -------> │ MySQL Service│ -------> │  MySQL Pod  │
15
│             │  稳定域名  │ mysql-svc   │  自动追踪  │  任何IP都行  │
16
└─────────────┘          └──────────────┘          └─────────────┘

问题2：多副本负载均衡

1
没有Service：怎么知道有几个Pod？要手动配置负载均衡
2
┌──────────┐     ???
3
│  Client  │ --------> ┌──────────┐
4
└──────────┘           │  Pod 1   │
5
                       └──────────┘
6
                       ┌──────────┐
7
                       │  Pod 2   │
8
                       └──────────┘
9
                       ┌──────────┐
10
                       │  Pod 3   │
11
                       └──────────┘
12

13
有Service：自动负载均衡
14
┌──────────┐           ┌─────────────┐
15
│  Client  │ --------> │   Service   │ ----轮询----> ┌──────────┐
16
└──────────┘           │  自动分发流量 │               │  Pod 1   │
17
                       └─────────────┘    ┌─────────> ┌──────────┐
18
                                          │           │  Pod 2   │
19
                                          └─────────> └──────────┘
20
                                                      ┌──────────┐
21
                                                      │  Pod 3   │
22
                                                      └──────────┘

问题3：服务发现困难

1
传统方式：需要配置中心、注册中心（如Consul、Eureka）
2
┌──────────┐    1.注册    ┌─────────────┐
3
│  MySQL   │ -----------> │ 注册中心     │
4
└──────────┘              └─────────────┘
5
                               ↑ 2.查询
6
                          ┌──────────┐
7
                          │  Nginx   │
8
                          └──────────┘
9

10
K8s方式：Service + CoreDNS 自动搞定
11
┌──────────┐              ┌──────────┐
12
│  MySQL   │ <--自动发现-- │  Service │ <-- DNS解析 -- Nginx
13
└──────────┘              └──────────┘                 只需要知道服务名

1.4 Service的工作原理#

Service由三个核心组件协作实现：

Service对象本身
kube-proxy（网络代理）
CoreDNS（DNS服务）

完整的工作流程：

flowchart TD A["1. 用户创建Service kubectl apply -f service.yaml selector: app=mysql port: 3306"] --> B B["2. API Server处理 分配ClusterIP: 10.96.100.50 存储到etcd"] --> C C["3. Endpoint Controller 根据selector找到匹配Pod 创建Endpoints: 10.244.1.10:3306 10.244.2.20:3306"] --> D D["4. kube-proxy配置转发 监听Service和Endpoint变化 配置iptables/ipvs规则"] --> E E["5. CoreDNS注册域名 mysql-service → 10.96.100.50"] --> F F["6. 客户端访问 ① DNS解析 mysql-service ② 请求 10.96.100.50:3306 ③ kube-proxy拦截 ④ DNAT转换到Pod IP ⑤ 到达MySQL Pod"]

1.5 Service与关联组件详解#

1.5.1 kube-proxy：Service的实现者#

kube-proxy是什么？

kube-proxy是运行在每个Node上的网络代理组件，负责实现Service的网络转发功能。

kube-proxy的工作模式：

模式1：iptables模式（默认）

1
原理：使用Linux iptables规则实现流量转发
2

3
工作流程：
4
请求：curl http://10.96.100.50:3306
5
   ↓
6
iptables规则拦截（PREROUTING链）
7
   ↓
8
DNAT转换：10.96.100.50 -> 10.244.1.10（随机选择一个Pod）
9
   ↓
10
到达Pod
11

12
优点：
13
  ✓ 性能好，在内核层面工作
14
  ✓ 不需要额外模块
15

16
缺点：
17
  ✗ Service/Pod数量多时，iptables规则会爆炸式增长
18
  ✗ 规则匹配是线性的，性能下降
19
  ✗ 负载均衡算法单一（只有随机）

示例：查看iptables规则

1
# 查看Service相关的iptables规则
2
iptables -t nat -L | grep mysql-service
3

4
# 你会看到类似这样的规则：
5
# -A KUBE-SERVICES -d 10.96.100.50/32 -p tcp -m tcp --dport 3306 -j KUBE-SVC-XXXXX
6
# -A KUBE-SVC-XXXXX -m statistic --mode random --probability 0.5 -j KUBE-SEP-AAAA
7
# -A KUBE-SVC-XXXXX -j KUBE-SEP-BBBB
8
# -A KUBE-SEP-AAAA -p tcp -j DNAT --to-destination 10.244.1.10:3306
9
# -A KUBE-SEP-BBBB -p tcp -j DNAT --to-destination 10.244.2.20:3306

模式2：IPVS模式（推荐，生产环境必备）

1
原理：使用Linux IPVS（IP Virtual Server）内核模块
2

3
IPVS是什么？
4
  - Linux内核的四层负载均衡器
5
  - 专为高性能负载均衡设计
6
  - 比iptables快得多
7

8
工作流程：
9
请求：curl http://10.96.100.50:3306
10
   ↓
11
IPVS规则拦截（内核netfilter）
12
   ↓
13
根据负载均衡算法选择后端（可选rr、lc、dh等）
14
   ↓
15
DNAT转换：10.96.100.50 -> 10.244.1.10
16
   ↓
17
到达Pod
18

19
优点：
20
  ✓ 性能极高，使用hash表查找，O(1)复杂度
21
  ✓ 支持多种负载均衡算法：
22
    - rr（轮询）
23
    - lc（最少连接）
24
    - dh（目标地址hash）
25
    - sh（源地址hash）
26
    - sed（最短期望延迟）
27
    - nq（永不排队）
28
  ✓ 支持大规模集群（可处理数万Service）
29
  ✓ 更好的性能：连接调度更快
30

31
缺点：
32
  ✗ 需要加载内核模块
33
  ✗ 配置稍复杂（但在生产环境中这不是问题）

iptables vs IPVS 性能对比：

1
场景：1000个Service，每个Service有10个Pod
2

3
iptables模式：
4
  - 规则数量：10,000+条
5
  - 规则匹配：线性查找 O(n)
6
  - 流量转发延迟：随Service数量增加显著上升
7
  - 创建/删除Service：需要重建大量规则，耗时
8

9
IPVS模式：
10
  - 规则数量：1,000个虚拟服务 + 10,000个后端
11
  - 规则匹配：哈希查找 O(1)
12
  - 流量转发延迟：恒定，不受Service数量影响
13
  - 创建/删除Service：只操作对应条目，快速

DNAT是什么？

DNAT（Destination Network Address Translation，目标网络地址转换）

1
简单理解：把数据包的目标地址改掉
2

3
原始请求：
4
  源IP: 10.244.3.5 (nginx pod)
5
  目标IP: 10.96.100.50 (Service ClusterIP)
6
  目标端口: 3306
7

8
经过DNAT转换后：
9
  源IP: 10.244.3.5 (不变)
10
  目标IP: 10.244.1.10 (改成了Pod IP)
11
  目标端口: 3306 (不变)
12

13
这个转换对客户端是透明的，nginx pod不知道目标地址被改了。

完整的网络包流转：

1
┌──────────────────────────────────────────────────────────────┐
2
│  Nginx Pod (10.244.3.5)                                      │
3
│  执行：mysql_connect("mysql-service", ...)                  │
4
└──────────────────────────────────────────────────────────────┘
5
                  ↓ DNS解析
6
┌──────────────────────────────────────────────────────────────┐
7
│  CoreDNS                                                     │
8
│  mysql-service -> 10.96.100.50                              │
9
└──────────────────────────────────────────────────────────────┘
10
                  ↓ 发送TCP连接请求
11
┌──────────────────────────────────────────────────────────────┐
12
│  数据包（出站）                                               │
13
│  SRC: 10.244.3.5:随机端口                                    │
14
│  DST: 10.96.100.50:3306                                     │
15
└──────────────────────────────────────────────────────────────┘
16
                  ↓ 经过kube-proxy（iptables/IPVS）
17
┌──────────────────────────────────────────────────────────────┐
18
│  DNAT转换                                                    │
19
│  规则：10.96.100.50:3306 -> 10.244.1.10:3306 (Pod1)        │
20
└──────────────────────────────────────────────────────────────┘
21
                  ↓
22
┌──────────────────────────────────────────────────────────────┐
23
│  数据包（转换后）                                             │
24
│  SRC: 10.244.3.5:随机端口                                    │
25
│  DST: 10.244.1.10:3306  <- 已经改成Pod IP                   │
26
└──────────────────────────────────────────────────────────────┘
27
                  ↓ 路由到目标Node
28
┌──────────────────────────────────────────────────────────────┐
29
│  MySQL Pod (10.244.1.10)                                    │
30
│  接收连接，处理请求                                           │
31
└──────────────────────────────────────────────────────────────┘
32
                  ↓ 返回响应
33
┌──────────────────────────────────────────────────────────────┐
34
│  响应数据包                                                   │
35
│  SRC: 10.244.1.10:3306                                      │
36
│  DST: 10.244.3.5:随机端口                                    │
37
└──────────────────────────────────────────────────────────────┘
38
                  ↓ 经过kube-proxy（反向SNAT）
39
┌──────────────────────────────────────────────────────────────┐
40
│  SNAT转换（自动）                                             │
41
│  10.244.1.10:3306 -> 10.96.100.50:3306                      │
42
│  （让nginx以为是Service回复的）                               │
43
└──────────────────────────────────────────────────────────────┘
44
                  ↓
45
┌──────────────────────────────────────────────────────────────┐
46
│  Nginx Pod收到响应                                            │
47
│  看到的源地址：10.96.100.50:3306                             │
48
│  （完全不知道实际是10.244.1.10）                              │
49
└──────────────────────────────────────────────────────────────┘

1.5.2 CoreDNS：Service的服务发现#

CoreDNS是什么？

CoreDNS是Kubernetes集群的DNS服务器，负责为Service提供域名解析。

DNS记录格式：

1
完整格式：
2
<service-name>.<namespace>.svc.<cluster-domain>
3

4
示例：
5
mysql-service.default.svc.cluster.local
6

7
简写方式（同namespace内）：
8
mysql-service.default
9
mysql-service                    <- 最常用
10

11
跨namespace访问：
12
mysql-service.production

CoreDNS工作原理：

1
┌─────────────────────────────────────────────────────────────┐
2
│  1. Pod创建时，kubelet自动配置DNS                             │
3
│                                                             │
4
│  Pod内的 /etc/resolv.conf:                                  │
5
│  nameserver 10.96.0.10    <- CoreDNS的Service IP           │
6
│  search default.svc.cluster.local svc.cluster.local        │
7
│  options ndots:5                                            │
8
└─────────────────────────────────────────────────────────────┘
9
                        ↓
10
┌─────────────────────────────────────────────────────────────┐
11
│  2. 应用发起DNS查询                                           │
12
│  curl http://mysql-service:3306                            │
13
└─────────────────────────────────────────────────────────────┘
14
                        ↓
15
┌─────────────────────────────────────────────────────────────┐
16
│  3. DNS查询发送到CoreDNS (10.96.0.10)                       │
17
│  查询：mysql-service.default.svc.cluster.local 的A记录      │
18
└─────────────────────────────────────────────────────────────┘
19
                        ↓
20
┌─────────────────────────────────────────────────────────────┐
21
│  4. CoreDNS监听etcd，实时知道所有Service信息                  │
22
│  返回：10.96.100.50 (Service的ClusterIP)                    │
23
└─────────────────────────────────────────────────────────────┘
24
                        ↓
25
┌─────────────────────────────────────────────────────────────┐
26
│  5. 应用使用解析出的IP访问                                     │
27
│  curl http://10.96.100.50:3306                             │
28
└─────────────────────────────────────────────────────────────┘

查看CoreDNS：

1
# 查看CoreDNS Pod
2
kubectl get pods -n kube-system | grep coredns
3

4
# 查看CoreDNS配置
5
kubectl get configmap coredns -n kube-system -o yaml
6

7
# 测试DNS解析
8
kubectl run test-dns --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- nslookup mysql-service

1.6 Service如何关联到Pod：Label和Selector#

Label（标签）

Label是附加到K8s对象上的键值对，用于标识和分类资源。

1
# Pod定义中的Label
2
metadata:
3
  labels:
4
    app: mysql           # 应用名称
5
    version: "8.0"       # 版本
6
    env: production      # 环境

Selector（选择器）

Selector用于根据Label选择一组资源。

1
# Service定义中的Selector
2
spec:
3
  selector:
4
    app: mysql          # 选择所有 app=mysql 的Pod

完整的关联流程：

1
┌─────────────────────────────────────────────────────────────┐
2
│  1. 定义Pod，打上标签                                         │
3
│                                                             │
4
│  apiVersion: v1                                             │
5
│  kind: Pod                                                  │
6
│  metadata:                                                  │
7
│    name: mysql-pod-1                                        │
8
│    labels:                                                  │
9
│      app: mysql         <- 标签1                            │
10
│      version: "8.0"     <- 标签2                            │
11
└─────────────────────────────────────────────────────────────┘
12
                        ↓
13
┌─────────────────────────────────────────────────────────────┐
14
│  2. 定义Service，使用Selector                                │
15
│                                                             │
16
│  apiVersion: v1                                             │
17
│  kind: Service                                              │
18
│  metadata:                                                  │
19
│    name: mysql-service                                      │
20
│  spec:                                                      │
21
│    selector:                                                │
22
│      app: mysql         <- 选择器：匹配 app=mysql 的Pod      │
23
│    ports:                                                   │
24
│    - port: 3306                                             │
25
└─────────────────────────────────────────────────────────────┘
26
                        ↓
27
┌─────────────────────────────────────────────────────────────┐
28
│  3. Endpoint Controller自动匹配                              │
29
│                                                             │
30
│  查找所有 app=mysql 的Pod：                                  │
31
│    - mysql-pod-1  (10.244.1.10)  ✓ 匹配                    │
32
│    - mysql-pod-2  (10.244.2.20)  ✓ 匹配                    │
33
│    - nginx-pod    (10.244.3.5)   ✗ 不匹配（标签不同）        │
34
│                                                             │
35
│  创建Endpoint对象：                                          │
36
│  mysql-service:                                             │
37
│    - 10.244.1.10:3306                                       │
38
│    - 10.244.2.20:3306                                       │
39
└─────────────────────────────────────────────────────────────┘
40
                        ↓
41
┌─────────────────────────────────────────────────────────────┐
42
│  4. Pod动态变化，自动更新                                     │
43
│                                                             │
44
│  新增Pod：mysql-pod-3 (标签: app=mysql)                     │
45
│    → Endpoint自动添加：10.244.1.30:3306                     │
46
│                                                             │
47
│  Pod删除：mysql-pod-1                                       │
48
│    → Endpoint自动移除：10.244.1.10:3306                     │
49
│                                                             │
50
│  Pod未就绪（Readiness探针失败）：                            │
51
│    → Endpoint临时移除，不再转发流量                          │
52
└─────────────────────────────────────────────────────────────┘

Selector的匹配规则：

1
# 1. 精确匹配（AND关系）
2
selector:
3
  app: mysql
4
  version: "8.0"
5
# 选择：app=mysql 且 version=8.0 的Pod
6

7
# 2. 集合匹配（Service不支持，Deployment支持）
8
selector:
9
  matchLabels:
10
    app: mysql
11
  matchExpressions:
12
  - key: version
13
    operator: In
14
    values: ["8.0", "8.1"]
15
# 选择：app=mysql 且 version in (8.0, 8.1)

查看Label和Endpoint：

1
# 查看Pod的标签
2
kubectl get pods --show-labels
3

4
# 根据标签过滤Pod
5
kubectl get pods -l app=mysql
6

7
# 查看Service的Endpoint
8
kubectl get endpoints mysql-service
9

10
# 详细信息
11
kubectl describe endpoints mysql-service

为什么使用Label/Selector而不是直接指定Pod名称？

1
直接指定Pod名称的问题：
2
  ✗ Pod名称会变（重建后名称不同）
3
  ✗ 无法动态添加新Pod
4
  ✗ 无法实现自动扩缩容
5
  ✗ 管理困难（要手动维护列表）
6

7
Label/Selector的优势：
8
  ✓ 松耦合：Service不关心具体哪个Pod
9
  ✓ 动态：新Pod自动加入，旧Pod自动移除
10
  ✓ 灵活：可以根据不同维度选择（环境、版本等）
11
  ✓ 符合K8s声明式理念

2. Service的类型详解#

Kubernetes提供了五种Service类型，每种类型适用于不同的访问场景。

2.1 ClusterIP：集群内部访问（默认类型）#

什么是ClusterIP？

ClusterIP是Service的默认类型，K8s会为Service分配一个集群内部的虚拟IP地址，这个IP只能在集群内部访问。

典型使用场景：

1
场景：前端应用访问后端数据库
2

3
┌────────────────── K8s Cluster ──────────────────┐
4
│                                                 │
5
│  ┌──────────┐    ClusterIP    ┌──────────┐    │
6
│  │  Nginx   │ -------------->  │  MySQL   │    │
7
│  │  Pod     │  mysql-service  │  Pods    │    │
8
│  └──────────┘   10.96.100.50  └──────────┘    │
9
│                                                 │
10
│  特点：只能集群内部访问，外部无法直接访问         │
11
└─────────────────────────────────────────────────┘

YAML示例：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: mysql-service
5
spec:
6
  type: ClusterIP          # 可以省略，默认就是ClusterIP
7
  selector:
8
    app: mysql             # 选择标签为app=mysql的Pod
9
  ports:
10
  - port: 3306             # Service对外暴露的端口
11
    targetPort: 3306       # Pod容器的端口
12
    protocol: TCP

重要字段解释：

字段	说明	示例
port	Service暴露的端口（客户端访问这个端口）	3306
targetPort	Pod容器监听的端口（流量转发到这个端口）	3306
protocol	协议类型	TCP/UDP

port 和 targetPort 的区别：

1
示例场景：Service port=80, targetPort=8080
2

3
客户端请求：curl http://my-service:80
4
              ↓
5
          Service接收（port: 80）
6
              ↓
7
          kube-proxy转发
8
              ↓
9
     到达Pod容器（targetPort: 8080）
10

11
好处：
12
  - Service对外统一使用标准端口（如80）
13
  - 容器内部可以用任意端口（如8080）
14
  - 便于端口标准化管理

查看ClusterIP：

1
# 创建Service
2
kubectl apply -f mysql-service.yaml
3

4
# 查看Service列表
5
kubectl get svc
6
# NAME            TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
7
# mysql-service   ClusterIP   10.96.100.50    <none>        3306/TCP   1m
8

9
# 查看详细信息
10
kubectl describe svc mysql-service
11

12
# 查看Endpoint（后端Pod列表）
13
kubectl get endpoints mysql-service

2.2 NodePort：通过节点端口暴露服务#

什么是NodePort？

NodePort在ClusterIP的基础上，会在每个Node节点上开放一个固定端口（范围：30000-32767），外部可以通过<任意NodeIP>:<NodePort>访问服务。

工作原理：

1
外部访问流程：
2

3
外部用户
4
  ↓ 访问：http://192.168.100.21:30080
5
┌──────────────────── K8s Cluster ────────────────────┐
6
│                                                     │
7
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────┐│
8
│  │  Node1      │  │  Node2      │  │  Node3      ││
9
│  │ :30080 ←────┼──│ :30080      │  │ :30080      ││
10
│  └─────────────┘  └─────────────┘  └─────────────┘│
11
│         │                                           │
12
│         └────────→ kube-proxy转发                  │
13
│                          ↓                         │
14
│                  ┌──────────────┐                  │
15
│                  │  Service     │                  │
16
│                  │  ClusterIP   │                  │
17
│                  └──────────────┘                  │
18
│                          ↓                         │
19
│              ┌───────────┼───────────┐             │
20
│              ↓           ↓           ↓             │
21
│         ┌────────┐  ┌────────┐  ┌────────┐       │
22
│         │ Pod1   │  │ Pod2   │  │ Pod3   │       │
23
│         └────────┘  └────────┘  └────────┘       │
24
│                                                     │
25
└─────────────────────────────────────────────────────┘
26

27
特点：
28
  1. 可以通过任意Node的IP访问
29
  2. 即使Pod不在该Node上也能访问
30
  3. 自动创建ClusterIP

YAML示例：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-nodeport
5
spec:
6
  type: NodePort
7
  selector:
8
    app: nginx
9
  ports:
10
  - port: 80               # ClusterIP端口
11
    targetPort: 80         # Pod端口
12
    nodePort: 30080        # Node端口（可选，不指定则自动分配）
13
    protocol: TCP

三种访问方式：

1
# 方式1：集群内通过ClusterIP访问
2
curl http://10.96.100.60:80
3

4
# 方式2：集群内通过Service名称访问
5
curl http://nginx-nodeport:80
6

7
# 方式3：集群外通过NodePort访问（任意Node IP都可以）
8
curl http://192.168.100.21:30080
9
curl http://192.168.100.22:30080
10
curl http://192.168.100.20:30080

NodePort端口范围：

1
# 默认范围：30000-32767
2
# 可以在kube-apiserver启动参数中修改：
3
# --service-node-port-range=30000-32767

使用场景与限制：

1
✓ 适用场景：
2
  - 开发/测试环境快速暴露服务
3
  - 小规模应用
4
  - 临时访问需求
5

6
✗ 不适用场景：
7
  - 生产环境（端口不好记，不优雅）
8
  - 大量服务（端口容易冲突）
9
  - 需要域名和HTTPS（要额外配置）
10

11
生产环境建议：
12
  使用LoadBalancer或Ingress

2.3 LoadBalancer：云平台负载均衡器#

什么是LoadBalancer？

LoadBalancer是在NodePort基础上，自动创建云平台的外部负载均衡器，提供统一的外部访问入口。

本质理解：

1
LoadBalancer = ClusterIP + NodePort + 云平台LB
2

3
创建流程：
4
1. 自动创建ClusterIP
5
2. 自动创建NodePort
6
3. 调用云平台API创建外部负载均衡器
7
4. 外部LB指向所有Node的NodePort

工作原理（云平台环境）：

1
┌─────────────────────────────────────────────────┐
2
│  外部用户                                         │
3
└─────────────────────────────────────────────────┘
4
                    │
5
                    │ http://lb-12345.elb.amazonaws.com
6
                    ↓
7
┌─────────────────────────────────────────────────┐
8
│  云平台负载均衡器 (AWS ELB/阿里云SLB/腾讯云CLB)      │
9
│  外部IP: 1.2.3.4                                 │
10
└─────────────────────────────────────────────────┘
11
                    │
12
       ┌────────────┼────────────┐
13
       │            │            │
14
       ↓ :30080     ↓ :30080     ↓ :30080
15
  ┌─────────┐  ┌─────────┐  ┌─────────┐
16
  │ Node1   │  │ Node2   │  │ Node3   │
17
  └─────────┘  └─────────┘  └─────────┘
18
       │            │            │
19
       └────────────┼────────────┘
20
                    ↓
21
            ┌──────────────┐
22
            │  Service     │
23
            │  ClusterIP   │
24
            └──────────────┘
25
                    ↓
26
        ┌───────────┼───────────┐
27
        ↓           ↓           ↓
28
   ┌────────┐  ┌────────┐  ┌────────┐
29
   │ Pod1   │  │ Pod2   │  │ Pod3   │
30
   └────────┘  └────────┘  └────────┘

YAML示例：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-lb
5
spec:
6
  type: LoadBalancer
7
  selector:
8
    app: nginx
9
  ports:
10
  - port: 80
11
    targetPort: 80

查看LoadBalancer：

1
kubectl apply -f nginx-lb.yaml
2

3
kubectl get svc nginx-lb
4
# NAME       TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
5
# nginx-lb   LoadBalancer   10.96.100.80   1.2.3.4          80:30123/TCP   2m
6
#                                          ↑ 云平台分配的外部IP
7

8
# 外部访问
9
curl http://1.2.3.4

云平台 vs 裸金属（本地集群）：

1
云平台（AWS、阿里云、Azure、GCP等）：
2
  ┌────────────────────────────────────────┐
3
  │ 1. 创建LoadBalancer Service            │
4
  │ 2. Cloud Controller Manager检测到      │
5
  │ 3. 调用云平台API创建LB                  │
6
  │ 4. 云平台返回外部IP                     │
7
  │ 5. K8s更新Service的EXTERNAL-IP字段      │
8
  └────────────────────────────────────────┘
9
  ✓ 完全自动化
10
  ✓ 有真实外部IP
11
  ✓ 云平台管理，高可用
12
  ✗ 需要付费
13

14
裸金属/本地集群：
15
  ┌────────────────────────────────────────┐
16
  │ 1. 创建LoadBalancer Service            │
17
  │ 2. 没有Cloud Controller Manager        │
18
  │ 3. 无法调用云平台API                    │
19
  │ 4. EXTERNAL-IP一直显示<pending>        │
20
  │ 5. LoadBalancer功能无法使用             │
21
  └────────────────────────────────────────┘
22
  ✗ 无外部LB
23
  ✗ 功能不可用
24
  ✓ 解决方案：MetalLB

MetalLB：裸金属环境的LoadBalancer实现

MetalLB是什么？

MetalLB是一个为裸金属Kubernetes集群提供LoadBalancer实现的开源项目，让本地集群也能使用LoadBalancer类型的Service。

MetalLB工作原理：

1
┌─────────────────────────────────────────────────┐
2
│  1. 创建LoadBalancer Service                    │
3
└─────────────────────────────────────────────────┘
4
                    ↓
5
┌─────────────────────────────────────────────────┐
6
│  2. MetalLB Controller监听                      │
7
│     - 从IP池分配一个外部IP                       │
8
│     - 更新Service的EXTERNAL-IP字段               │
9
└─────────────────────────────────────────────────┘
10
                    ↓
11
┌─────────────────────────────────────────────────┐
12
│  3. MetalLB Speaker（DaemonSet，每个Node运行）   │
13
│     - Layer 2模式：通过ARP响应宣告IP             │
14
│     - BGP模式：通过BGP协议宣告路由                │
15
└─────────────────────────────────────────────────┘

MetalLB配置示例：

1
# IP地址池
2
apiVersion: metallb.io/v1beta1
3
kind: IPAddressPool
4
metadata:
5
  name: first-pool
6
  namespace: metallb-system
7
spec:
8
  addresses:
9
  - 192.168.100.100-192.168.100.150    # IP范围
10

11
---
12
# Layer 2模式配置
13
apiVersion: metallb.io/v1beta1
14
kind: L2Advertisement
15
metadata:
16
  name: l2-adv
17
  namespace: metallb-system
18
spec:
19
  ipAddressPools:
20
  - first-pool

MetalLB两种模式对比：

特性	Layer 2模式	BGP模式
原理	ARP欺骗，让Node声称拥有该IP	通过BGP协议宣告路由
配置难度	简单，无需额外设备	需要支持BGP的路由器
单点问题	有（一个Node响应，故障时切换）	无（ECMP真正的负载均衡）
性能	受限于单Node带宽	更高，多Node分担
适用场景	小规模集群、简单网络	大规模集群、企业网络
故障切换	~10秒	秒级

Layer 2模式示例：

1
IP池：192.168.100.100-192.168.100.110
2

3
创建第1个LoadBalancer Service：
4
  → MetalLB分配：192.168.100.100
5
  → Node1的Speaker响应该IP的ARP请求
6
  → 外部访问192.168.100.100流量全部进入Node1
7
  → Node1的kube-proxy转发到Pod
8

9
优点：简单，无需额外配置
10
缺点：单Node处理所有流量，有单点瓶颈

2.4 ExternalName：DNS CNAME映射#

什么是ExternalName？

ExternalName是一种特殊的Service，它不选择Pod，而是返回一个DNS CNAME记录，将服务名映射到外部域名。

使用场景：

1
场景1：访问外部服务
2
  应用需要访问外部数据库：db.external.com
3
  → 创建ExternalName Service指向该域名
4
  → 应用代码使用Service名称
5
  → 便于将来迁移到集群内部（只需修改Service定义）
6

7
场景2：服务迁移过渡期
8
  旧服务在集群外：old-service.external.com
9
  → 先用ExternalName指向外部
10
  → 逐步迁移到K8s内部
11
  → 完成后改为ClusterIP类型
12
  → 应用代码无需修改
13

14
场景3：跨集群服务引用
15
  集群A需要访问集群B的服务
16
  → 在集群A创建ExternalName指向集群B

DNS解析对比：

1
普通Service：
2
┌─────────────────────────────────────┐
3
│  nslookup nginx-service             │
4
│  返回：10.96.100.50 (ClusterIP)     │
5
└─────────────────────────────────────┘
6

7
ExternalName Service：
8
┌─────────────────────────────────────┐
9
│  nslookup nginx-external            │
10
│  返回：                              │
11
│    CNAME db.external.com            │
12
└─────────────────────────────────────┘

YAML示例：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-external
5
spec:
6
  type: ExternalName
7
  externalName: mysql.external-domain.com
8
  # 注意：没有selector，没有ports

测试：

1
# 创建Service
2
kubectl apply -f nginx-external.yaml
3

4
# 查看（没有ClusterIP）
5
kubectl get svc nginx-external
6
# NAME          TYPE           CLUSTER-IP   EXTERNAL-IP                  PORT(S)   AGE
7
# nginx-external   ExternalName   <none>       mysql.external-domain.com    <none>    1m
8

9
# DNS解析测试
10
kubectl run test --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- nslookup nginx-external
11
# Server:    10.96.0.10
12
# Name:      nginx-external.default.svc.cluster.local
13
# Address 1: mysql.external-domain.com
14
#            ↑ 返回CNAME，不是IP

特点总结：

1
优点：
2
  ✓ 便于服务迁移（外部→内部）
3
  ✓ 应用代码使用统一的Service名称
4
  ✓ 符合K8s服务发现模式
5

6
缺点：
7
  ✗ 不支持端口映射
8
  ✗ 不提供负载均衡
9
  ✗ 依赖外部DNS解析
10
  ✗ 不经过kube-proxy
11

12
注意：ExternalName不创建Endpoint，纯DNS层面映射

2.5 Headless Service：无头服务#

什么是Headless Service？

Headless Service是一种特殊的ClusterIP Service，通过设置clusterIP: None，使DNS直接返回Pod IP列表，而不是Service IP。

为什么需要Headless Service？

1
普通Service的限制：
2
  - DNS只返回Service的ClusterIP
3
  - 客户端无法获知后端Pod列表
4
  - 无法直接连接特定Pod
5
  - 必须通过Service代理
6

7
某些应用的需求：
8
  ✓ StatefulSet需要稳定的网络标识
9
  ✓ 数据库主从复制（需要直连特定实例）
10
  ✓ 分布式系统（节点互相发现）
11
  ✓ 客户端自己做负载均衡

DNS解析对比：

1
普通Service：
2
┌─────────────────────────────────────┐
3
│  nslookup nginx-service             │
4
│  返回：10.96.100.50 (ClusterIP)     │
5
└─────────────────────────────────────┘
6

7
Headless Service：
8
┌─────────────────────────────────────┐
9
│  nslookup nginx-headless            │
10
│  返回：                              │
11
│    10.244.1.10  (Pod1)              │
12
│    10.244.2.20  (Pod2)              │
13
│    10.244.3.30  (Pod3)              │
14
└─────────────────────────────────────┘

YAML示例：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: nginx-headless
5
spec:
6
  clusterIP: None          # 关键：设置为None
7
  selector:
8
    app: nginx
9
  ports:
10
  - port: 80
11
    targetPort: 80

StatefulSet + Headless Service：

1
# Headless Service
2
apiVersion: v1
3
kind: Service
4
metadata:
5
  name: web-headless
6
spec:
7
  clusterIP: None
8
  selector:
9
    app: web
10
  ports:
11
  - port: 80
12

13
---
14
# StatefulSet
15
apiVersion: apps/v1
16
kind: StatefulSet
17
metadata:
18
  name: web
19
spec:
20
  serviceName: web-headless    # 关联Headless Service
21
  replicas: 3
22
  selector:
23
    matchLabels:
24
      app: web
25
  template:
26
    metadata:
27
      labels:
28
        app: web
29
    spec:
30
      containers:
31
      - name: nginx
32
        image: nginx:1.20
33
        ports:
34
        - containerPort: 80

DNS命名规则：

1
StatefulSet Pod的DNS格式：
2
<pod-name>.<service-name>.<namespace>.svc.cluster.local
3

4
示例：
5
  web-0.web-headless.default.svc.cluster.local
6
  web-1.web-headless.default.svc.cluster.local
7
  web-2.web-headless.default.svc.cluster.local
8

9
特点：
10
  ✓ 每个Pod有固定的DNS名称
11
  ✓ Pod重建后DNS名称不变
12
  ✓ 可以直接访问特定Pod
13
  ✓ 适合有状态应用

测试：

1
# 创建资源
2
kubectl apply -f web-headless.yaml
3

4
# DNS测试
5
kubectl run test --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- \
6
  nslookup web-headless
7

8
kubectl run test --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- \
9
  nslookup web-0.web-headless
10

11
# 访问特定Pod
12
kubectl run test --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- \
13
  nslookup web-0.web-headless
14
# Address 1: 10.244.1.10

典型使用场景：

1
1. 有状态应用（StatefulSet）
2
   - MySQL主从集群
3
   - MongoDB副本集
4
   - Redis Cluster
5
   - Kafka集群
6

7
2. 分布式系统
8
   - Elasticsearch（节点互相发现）
9
   - ZooKeeper（选举和数据同步）
10
   - Etcd集群
11

12
3. 客户端负载均衡
13
   - 应用自己选择Pod（如读写分离）
14
   - 根据数据分片选择特定Pod

2.6 Service类型总结对比#

类型	ClusterIP	NodePort	LoadBalancer	ExternalName	Headless
ClusterIP	✓	✓	✓	✗	None
访问范围	集群内部	集群内+NodePort	集群内+外部LB	转发外部	集群内部
外部访问	✗	✓	✓	✗	✗
DNS解析	Service IP	Service IP	Service IP	CNAME	Pod IP列表
负载均衡	✓	✓	✓	✗	✗
使用场景	内部服务	开发测试	生产环境	外部服务	有状态应用
依赖	无	无	云平台/MetalLB	外部DNS	无

选择建议：

1
内部服务通信：ClusterIP（默认）
2
快速暴露服务（测试）：NodePort
3
生产环境对外暴露：LoadBalancer（云平台）或 Ingress
4
访问外部服务：ExternalName
5
有状态应用：Headless + StatefulSet

3. Service实战操作#

3.1 将kube-proxy切换到IPVS模式#

在所有节点安装IPVS模块(若未安装)：

1
# 在master、node1、node2上执行
2

3
# 加载IPVS内核模块
4
modprobe -- ip_vs
5
modprobe -- ip_vs_rr
6
modprobe -- ip_vs_wrr
7
modprobe -- ip_vs_sh
8
modprobe -- nf_conntrack
9

10
# 验证
11
lsmod | grep -e ip_vs -e nf_conntrack
12

13
# 设置开机自动加载
14
cat > /etc/modules-load.d/ipvs.conf <<EOF
15
ip_vs
16
ip_vs_rr
17
ip_vs_wrr
18
ip_vs_sh
19
nf_conntrack
20
EOF
21

22
# 安装ipvsadm工具
23
yum install -y ipvsadm ipset

修改kube-proxy配置：

1
# 编辑ConfigMap
2
kubectl edit configmap kube-proxy -n kube-system
3

4
# 找到mode字段，修改为：
5
mode: "ipvs"
6
ipvs:
7
  scheduler: "rr"  # 轮询算法

重启kube-proxy：

1
# 删除所有kube-proxy Pod，让其自动重建
2
kubectl delete pod -n kube-system -l k8s-app=kube-proxy
3

4
# 查看状态
5
kubectl get pods -n kube-system | grep kube-proxy

验证IPVS模式：

1
# 在集群机器上查看IPVS规则
2
ipvsadm -Ln
3

4
# 查看kube-proxy日志
5
kubectl logs -n kube-system <kube-proxy-pod-name> | grep -i ipvs

3.2 实验准备:改造nginx镜像支持通过Service名称访问数据库#

为什么要这样做?

在生产环境中,我们绝不应该在应用中硬编码数据库的IP地址。原因很简单:

Pod的IP是动态变化的,Pod重启后IP会改变

使用Service名称可以实现服务发现,K8s的DNS会自动解析

这是云原生应用的最佳实践

步骤1:创建支持环境变量配置的PHP应用(在harbor机器)

1
cd /root/k8s-demo/nginx
2

3
# 创建新版本的index.php
4
cat > index.php <<'EOF'
5
<?php
6
header('Content-Type: text/plain; charset=utf-8');
7

8
// 从环境变量读取配置(生产最佳实践)
9
$db_host = getenv('DB_HOST') ?: 'localhost';
10
$db_user = getenv('DB_USER') ?: 'root';
11
$db_pass = getenv('DB_PASS') ?: '';
12
$db_name = getenv('DB_NAME') ?: 'testdb';
13

14
echo "=== Nginx-PHP Container Info ==="."\\n";
15
echo "nginx v2"\\n";
16
echo "Hostname: " . gethostname() . "\\n";
17
echo "Server IP: " . $_SERVER['SERVER_ADDR'] . "\\n";
18
echo "\\n";
19
echo "=== Database Configuration ==="."\\n";
20
echo "DB Host: $db_host\\n";
21
echo "DB User: $db_user\\n";
22
echo "DB Name: $db_name\\n";
23
echo "\\n";
24
echo "=== Database Connection Test ==="."\\n";
25

26
// 尝试连接数据库
27
$conn = @new mysqli($db_host, $db_user, $db_pass, $db_name);
28
if ($conn->connect_error) {
29
    echo "Connection FAILED: " . $conn->connect_error . "\\n";
30
} else {
31
    echo "Database connected successfully!\\n";
32
    echo "MySQL Version: " . $conn->server_info . "\\n";
33
    $conn->close();
34
}
35
?>
36
EOF

这段代码做了什么?

getenv('DB_HOST'):从环境变量读取数据库地址,这样我们就可以传入Service名称
使用@符号抑制连接错误,改为友好提示
输出清晰的信息,方便调试

步骤2:构建并推送新镜像

1
# 构建镜像(使用之前的Dockerfile)
2
docker build -t reg.westos.org/library/nginx-php:v2 .
3

4
# 推送到私有仓库
5
docker push reg.westos.org/library/nginx-php:v2
6

7
# 验证镜像已推送
8
docker images | grep nginx-php

3.3 实验:使用Pod演示各类Service#

实验目标:

理解 ClusterIP、NodePort、LoadBalancer、Headless 四种Service类型的区别

掌握通过Service名称实现服务发现的方法

学会使用环境变量配置应用

实验架构:

1
┌─────────────────────────────────────────────────────┐
2
│                 Service Types                       │
3
│                                                     │
4
│  Nginx Pods  ──→  MySQL Pod                         │
5
│  (通过Service名称访问数据库)                         │
6
│                                                     │
7
│  ClusterIP    : 集群内部访问                        │
8
│  NodePort     : 暴露到节点端口                      │
9
│  LoadBalancer : 云平台负载均衡(可选)                │
10
│  Headless     : DNS直接解析到Pod IP                 │
11
└─────────────────────────────────────────────────────┘

实验1 Service - 集群内部访问数据库#

这是什么?

ClusterIP是默认的Service类型
为Service分配一个集群内部的虚拟IP(只能在集群内访问)
所有访问这个IP的流量会被负载均衡到后端Pod

使用场景:

数据库、缓存等后端服务
微服务之间的内部调用

步骤1:创建MySQL Pod

1
cd /root/k8s-yaml
2

3
# 创建MySQL Pod配置文件
4
cat > mysql-pod.yaml <<EOF
5
apiVersion: v1
6
kind: Pod
7
metadata:
8
  name: mysql-pod
9
  labels:
10
  # 重要!Service通过这个标签找到Pod
11
    app: mysql
12
    tier: backend
13
spec:
14
  containers:
15
  - name: mysql
16
    image: reg.westos.org/library/mysql:8.0
17
    ports:
18
    - containerPort: 3306
19
      name: mysql
20
    env:
21
    - name: MYSQL_ROOT_PASSWORD
22
      value: "Westos123"
23
    - name: MYSQL_DATABASE
24
      value: "testdb"
25
    # 健康检查
26
    livenessProbe:
27
      tcpSocket:
28
        port: 3306
29
      initialDelaySeconds: 30
30
      periodSeconds: 10
31
    readinessProbe:
32
      exec:
33
        command:
34
        - sh
35
        - -c
36
        - "mysqladmin ping -u root -p\${MYSQL_ROOT_PASSWORD}"
37
      initialDelaySeconds: 10
38
      periodSeconds: 5
39
EOF
40

41
# 创建Pod
42
kubectl apply -f mysql-pod.yaml
43

44
# 查看Pod状态(等待Running)
45
kubectl get pods -l app=mysql
46
kubectl get pods mysql-pod -o wide

参数详解:

labels: app: mysql:给Pod打标签,Service会通过selector选择这个标签
containerPort: 3306:声明容器监听的端口
livenessProbe:存活探针,检测MySQL进程是否存在
readinessProbe:就绪探针,检测MySQL是否可以接受连接

步骤2:创建ClusterIP Service

1
# 创建Service配置文件
2
cat > mysql-service.yaml <<EOF
3
apiVersion: v1
4
kind: Service
5
metadata:
6
  name: mysql-service
7
spec:
8
  type: ClusterIP
9
  selector:
10
    app: mysql
11
  ports:
12
  - port: 3306
13
    targetPort: 3306
14
    protocol: TCP
15
    name: mysql
16
EOF
17

18
# 创建Service
19
kubectl apply -f mysql-service.yaml
20

21
# 查看Service详细信息
22
kubectl get svc mysql-service
23
kubectl describe svc mysql-service
24

25
# 查看Endpoints(Service会自动发现后端Pod)
26
kubectl get endpoints mysql-service

参数详解:

selector: app: mysql:通过标签选择器,Service自动发现匹配的Pod
port: 3306对外暴露的端口(别人访问Service用这个端口)
targetPort: 3306实际监听的端口(流量转发到Pod的这个端口)
Endpoints自动创建,记录所有匹配Pod的IP和端口

为什么会自动关联?

1
1. Pod有标签:app=mysql
2
2. Service有选择器:selector: app=mysql
3
3. K8s自动匹配:Service发现所有带app=mysql标签的Pod
4
4. 创建Endpoints:记录Pod的IP:Port列表
5
5. 配置负载均衡:kube-proxy配置iptables/ipvs规则

步骤3:测试Service的DNS解析

1
# 测试DNS解析(Service名称 → IP)
2
kubectl run test-dns --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- \
3
  nslookup mysql-service
4

5
# 预期输出:
6
# Server:    10.96.0.10
7
# Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
8
#
9
# Name:      mysql-service
10
# Address 1: 10.96.100.10 mysql-service.default.svc.cluster.local
11

12
# 测试完整域名
13
kubectl run test-dns --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- \
14
  nslookup mysql-service.default.svc.cluster.local

DNS解析规则:

在K8s集群中,Service有多种DNS名称形式:

1
短名称(同namespace):  mysql-service
2
带namespace :          mysql-service.default
3
完整域名(FQDN):        mysql-service.default.svc.cluster.local

步骤4:测试数据库连接

1
# 使用MySQL客户端测试连接
2
kubectl run mysql-client --image=reg.westos.org/library/mysql:8.0 --rm -it --restart=Never -- \
3
  mysql -h mysql-service -uroot -pWestos123 -e "SELECT version();"
4

5
# 预期输出:
6
# +-----------+
7
# | version() |
8
# +-----------+
9
# | 8.0.x     |
10
# +-----------+

组合运用:这个实验展示了什么?

✅ Pod通过标签和Service关联
✅ Service提供稳定的访问入口(名称和IP不变)
✅ DNS自动解析Service名称到ClusterIP
✅ 后端Pod可以动态变化,Service自动更新Endpoints

实验2 Service - 通过Service名称访问数据库#

这是什么?

NodePort在ClusterIP的基础上,额外在每个Node上开放一个端口(30000-32767)
可以通过<NodeIP>:<NodePort>从集群外部访问Service
流量路径:外部 → NodePort → Service → Pod

使用场景:

开发测试环境快速暴露服务
没有LoadBalancer的环境

步骤1:创建Nginx Pod(通过Service名称连接MySQL)

1
# 创建配置文件
2
cat > nginx-pod-1.yaml <<EOF
3
apiVersion: v1
4
kind: Pod
5
metadata:
6
  name: nginx-pod-1
7
  labels:
8
    app: nginx
9
    version: v2
10
spec:
11
  containers:
12
  - name: nginx-php
13
    image: reg.westos.org/library/nginx-php:v2
14
    ports:
15
    - containerPort: 80
16
    env:
17
    # 关键!使用Service名称而不是IP
18
    - name: DB_HOST
19
      value: "mysql-service"    # ← 这里使用Service名称!
20
    - name: DB_USER
21
      value: "root"
22
    - name: DB_PASS
23
      value: "Westos123"
24
    - name: DB_NAME
25
      value: "testdb"
26
    # 健康检查
27
    readinessProbe:
28
      httpGet:
29
        path: /
30
        port: 80
31
      initialDelaySeconds: 5
32
      periodSeconds: 3
33
EOF
34

35
# 应用配置
36
kubectl apply -f nginx-pod-1.yaml
37

38
# 查看Pod状态
39
kubectl get pods nginx-pod-1 -o wide
40

41
# 查看Pod日志(检查是否有错误)
42
kubectl logs nginx-pod-1

重点理解:环境变量的作用

1
env:
2
- name: DB_HOST
3
  value: "mysql-service"   # PHP代码中 getenv('DB_HOST') 会读到这个值

这样配置后:

PHP应用启动时,环境变量 DB_HOST = “mysql-service”
代码执行 new mysqli($db_host, ...) 时,会连接到 “mysql-service”
K8s的DNS把 “mysql-service” 解析为Service的ClusterIP
Service把流量转发到MySQL Pod

步骤2:创建更多Nginx Pod(模拟多副本)

1
# 创建第2个Pod
2
cat > nginx-pod-2.yaml <<EOF
3
apiVersion: v1
4
kind: Pod
5
metadata:
6
  name: nginx-pod-2
7
  labels:
8
    app: nginx
9
    version: v2
10
spec:
11
  containers:
12
  - name: nginx-php
13
    image: reg.westos.org/library/nginx-php:v2
14
    ports:
15
    - containerPort: 80
16
    env:
17
    - name: DB_HOST
18
      value: "mysql-service"
19
    - name: DB_USER
20
      value: "root"
21
    - name: DB_PASS
22
      value: "Westos123"
23
    - name: DB_NAME
24
      value: "testdb"
25
EOF
26

27
# 创建第3个Pod
28
cat > nginx-pod-3.yaml <<EOF
29
apiVersion: v1
30
kind: Pod
31
metadata:
32
  name: nginx-pod-3
33
  labels:
34
    app: nginx
35
    version: v2
36
spec:
37
  containers:
38
  - name: nginx-php
39
    image: reg.westos.org/library/nginx-php:v2
40
    ports:
41
    - containerPort: 80
42
    env:
43
    - name: DB_HOST
44
      value: "mysql-service"
45
    - name: DB_USER
46
      value: "root"
47
    - name: DB_PASS
48
      value: "Westos123"
49
    - name: DB_NAME
50
      value: "testdb"
51
EOF
52

53
# 应用配置
54
kubectl apply -f nginx-pod-2.yaml
55
kubectl apply -f nginx-pod-3.yaml
56

57
# 查看所有Nginx Pod
58
kubectl get pods -l app=nginx -o wide

步骤3:创建NodePort Service

1
# 创建配置文件
2
cat > nginx-nodeport.yaml <<EOF
3
apiVersion: v1
4
kind: Service
5
metadata:
6
  name: nginx-nodeport
7
spec:
8
  type: NodePort           # 指定为NodePort类型
9
  selector:
10
    app: nginx             # 选择所有app=nginx的Pod
11
  ports:
12
  - port: 80               # Service端口
13
    targetPort: 80         # Pod端口
14
    nodePort: 30080        # Node端口(30000-32767)
15
    protocol: TCP
16
    name: http
17
EOF
18

19
# 应用配置
20
kubectl apply -f nginx-nodeport.yaml
21

22
# 查看Service
23
kubectl get svc nginx-nodeport
24
# 输出示例:
25
# NAME             TYPE       CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGE
26
# nginx-nodeport   NodePort   10.96.200.100   <none>        80:30080/TCP   10s
27

28
# 查看Endpoints(应该看到3个Pod)
29
kubectl get endpoints nginx-nodeport

参数详解:

type: NodePort:在ClusterIP基础上,额外暴露NodePort
nodePort: 30080:指定Node端口(不指定则自动分配30000-32767范围内的端口)
port: 80的端口
targetPort: 80的端口

访问路径理解:

1
外部客户端
2
   ↓
3
192.168.100.21:30080 (Node1的30080端口)
4
   ↓
5
iptables/ipvs规则
6
   ↓
7
nginx-nodeport Service (ClusterIP: 10.96.200.100:80)
8
   ↓
9
负载均衡到其中一个Pod
10
   ↓
11
nginx-pod-1 (10.244.1.10:80)
12
nginx-pod-2 (10.244.2.20:80)
13
nginx-pod-3 (10.244.1.30:80)

步骤4:测试访问和负载均衡

1
# 从集群外部访问(可以使用任意Node的IP)
2
curl http://192.168.100.21:30080
3
curl http://192.168.100.22:30080
4
curl http://192.168.100.20:30080
5

6
# 多次访问,观察负载均衡效果(Hostname会变化)
7
for i in {1..6}; do
8
  echo "=== Request $i ==="
9
  curl -s http://192.168.100.21:30080 | grep "Hostname:"
10
  echo ""
11
done
12

13
# 预期输出:
14
# === Request 1 ===
15
# Hostname: nginx-pod-1
16
# === Request 2 ===
17
# Hostname: nginx-pod-3
18
# === Request 3 ===
19
# Hostname: nginx-pod-2
20
# ...

观察数据库连接:

1
# 查看完整输出
2
curl http://192.168.100.21:30080
3

4
# 预期输出:
5
# === Nginx-PHP Container Info ===
6
# Hostname: nginx-pod-1
7
# Server IP: 10.244.1.10
8
#
9
# === Database Configuration ===
10
# DB Host: mysql-service
11
# DB User: root
12
# DB Name: testdb
13
#
14
# === Database Connection Test ===
15
# Database connected successfully!
16
# MySQL Version: 8.0.x

实验验证:

✅ 外部可以通过NodePort访问服务
✅ 流量自动负载均衡到3个Nginx Pod
✅ Nginx Pod通过Service名称成功访问MySQL
✅ 即使MySQL Pod重启IP变化,连接依然正常

步骤5:验证Service名称的优势

1
# 查看MySQL Pod当前IP
2
kubectl get pod mysql-pod -o wide
3
# 假设IP是: 10.244.1.5
4

5
# 删除并重建MySQL Pod(模拟Pod重启)
6
kubectl delete pod mysql-pod
7
kubectl apply -f mysql-pod.yaml
8

9
# 等待Pod就绪
10
kubectl get pods mysql-pod -o wide
11
# 新IP可能是: 10.244.2.15 (IP已改变!)
12

13
# 再次访问Nginx,数据库连接依然正常!
14
curl http://192.168.100.21:30080
15

16
# 原因:Nginx使用的是"mysql-service"名称,不是IP
17
# Service会自动更新Endpoints指向新Pod
18
kubectl get endpoints mysql-service

关键点理解:

1
如果硬编码IP:
2
  Nginx → 10.244.1.5 (旧IP) → 连接失败 ❌
3

4
使用Service名称:
5
  Nginx → mysql-service → DNS解析 → Service ClusterIP → 10.244.2.15 (新IP) → 连接成功 ✅

实验3 Service - 云平台负载均衡器#

这是什么?

LoadBalancer在NodePort基础上,进一步创建云平台的负载均衡器
分配一个外部可访问的IP地址
适用于公有云环境(AWS ELB、Azure LB、GCP LB等)

使用场景:

生产环境对外提供服务
需要固定的外部IP和更好的负载均衡

注意: 本地环境或私有云默认不支持LoadBalancer,可以使用MetalLB实现。

创建LoadBalancer Service:

1
cat > nginx-loadbalancer.yaml <<EOF
2
apiVersion: v1
3
kind: Service
4
metadata:
5
  name: nginx-loadbalancer
6
spec:
7
  type: LoadBalancer      # 指定为LoadBalancer类型
8
  selector:
9
    app: nginx
10
  ports:
11
  - port: 80
12
    targetPort: 80
13
    protocol: TCP
14
    name: http
15
EOF
16

17
# 应用配置
18
kubectl apply -f nginx-loadbalancer.yaml
19

20
# 查看Service
21
kubectl get svc nginx-loadbalancer
22

23
# 在云平台上,EXTERNAL-IP会显示分配的公网IP
24
# NAME                   TYPE           CLUSTER-IP      EXTERNAL-IP     PORT(S)        AGE
25
# nginx-loadbalancer     LoadBalancer   10.96.200.200   1.2.3.4         80:31234/TCP   1m
26

27
# 本地环境会显示<pending>,因为没有云平台负载均衡器

访问方式:

1
# 云平台环境:通过EXTERNAL-IP访问
2
curl http://<EXTERNAL-IP>
3

4
# 本地环境:仍然可以通过NodePort访问
5
curl http://192.168.100.21:31234

LoadBalancer vs NodePort vs ClusterIP:

1
LoadBalancer = ClusterIP + NodePort + 云平台LB
2
   ↓
3
外部LB (1.2.3.4:80) → NodePort (任意Node:31234) → Service (ClusterIP) → Pod

实验4 Service - DNS直接解析到Pod IP#

这是什么?

Headless Service不分配ClusterIP(clusterIP: None)
DNS直接返回所有后端Pod的IP列表,而不是Service IP
客户端可以直接连接到Pod,实现客户端负载均衡

使用场景:

有状态应用(StatefulSet)需要访问特定Pod
客户端需要知道所有Pod的IP(如数据库主从、Redis集群)
自定义负载均衡策略

步骤1:创建测试用的Web Pod

1
# 创建3个测试Pod
2
cat > web-pods.yaml <<EOF
3
apiVersion: v1
4
kind: Pod
5
metadata:
6
  name: web-pod-1
7
  labels:
8
    app: web
9
    role: backend
10
spec:
11
  containers:
12
  - name: nginx
13
    image: nginx:1.20
14
    ports:
15
    - containerPort: 80
16
---
17
apiVersion: v1
18
kind: Pod
19
metadata:
20
  name: web-pod-2
21
  labels:
22
    app: web
23
    role: backend
24
spec:
25
  containers:
26
  - name: nginx
27
    image: nginx:1.20
28
    ports:
29
    - containerPort: 80
30
---
31
apiVersion: v1
32
kind: Pod
33
metadata:
34
  name: web-pod-3
35
  labels:
36
    app: web
37
    role: backend
38
spec:
39
  containers:
40
  - name: nginx
41
    image: nginx:1.20
42
    ports:
43
    - containerPort: 80
44
EOF
45

46
# 应用配置
47
kubectl apply -f web-pods.yaml
48

49
# 查看Pod及其IP
50
kubectl get pods -l app=web -o wide

步骤2:创建Headless Service

1
cat > web-headless.yaml <<EOF
2
apiVersion: v1
3
kind: Service
4
metadata:
5
  name: web-headless
6
spec:
7
  clusterIP: None    # 关键!设置为None表示Headless
8
  selector:
9
    app: web
10
  ports:
11
  - port: 80
12
    targetPort: 80
13
EOF
14

15
# 应用配置
16
kubectl apply -f web-headless.yaml
17

18
# 查看Service(注意CLUSTER-IP是None)
19
kubectl get svc web-headless
20
# NAME           TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
21
# web-headless   ClusterIP   None         <none>        80/TCP    5s

步骤3:测试DNS解析

1
# DNS解析(返回所有Pod的IP,而不是Service IP)
2
kubectl run test-dns --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- \
3
  nslookup web-headless
4

5
# 预期输出:
6
# Server:    10.96.0.10
7
# Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
8
#
9
# Name:      web-headless
10
# Address 1: 10.244.1.20 web-pod-1.web-headless.default.svc.cluster.local
11
# Address 2: 10.244.2.30 web-pod-2.web-headless.default.svc.cluster.local
12
# Address 3: 10.244.1.40 web-pod-3.web-headless.default.svc.cluster.local

Headless vs 普通Service的DNS对比:

1
普通ClusterIP Service:
2
  nslookup mysql-service
3
  → 返回: 10.96.100.10 (Service的ClusterIP)
4

5
Headless Service:
6
  nslookup web-headless
7
  → 返回: 10.244.1.20, 10.244.2.30, 10.244.1.40 (所有Pod的IP)

步骤4:直接访问特定Pod(StatefulSet场景)

1
# Headless Service常与StatefulSet配合使用
2
# 每个Pod有固定的DNS名称: <pod-name>.<service-name>
3

4
# 示例:假设我们有StatefulSet创建的Pod
5
# web-0, web-1, web-2
6
# 可以通过以下DNS直接访问:
7
# web-0.web-headless.default.svc.cluster.local
8
# web-1.web-headless.default.svc.cluster.local
9
# web-2.web-headless.default.svc.cluster.local
10

11
# 测试(虽然我们用的是普通Pod,但原理相同)
12
kubectl run test --image=reg.westos.org/library/busybox:1.30.1 --rm -it --restart=Never -- \
13
  wget -qO- web-pod-1.web-headless

实验总结:

✅ Headless Service不分配ClusterIP
✅ DNS返回所有Pod的IP列表
✅ 适合客户端自己选择要连接的Pod
✅ StatefulSet中每个Pod有固定的DNS名称

清理实验资源:

1
# 清理Nginx Pod和Service
2
kubectl delete pod nginx-pod-1 nginx-pod-2 nginx-pod-3
3
kubectl delete svc nginx-nodeport nginx-loadbalancer
4

5
# 清理Web Pod和Service
6
kubectl delete pod web-pod-1 web-pod-2 web-pod-3
7
kubectl delete svc web-headless
8

9
# 保留MySQL Pod和Service供后续实验使用
10
# kubectl delete pod mysql-pod
11
# kubectl delete svc mysql-service

3.4 Service实验总结与最佳实践#

四种Service类型对比:

特性	ClusterIP	NodePort	LoadBalancer	Headless
ClusterIP	✓	✓	✓	None
访问范围	集群内部	集群内+NodePort	集群内+外部LB	集群内部
外部访问	✗	✓	✓	✗
DNS解析	Service IP	Service IP	Service IP	Pod IP列表
负载均衡	✓	✓	✓	✗(客户端)
使用场景	内部服务	开发测试	生产环境	有状态应用
依赖	无	无	云平台	无

生产最佳实践:

服务发现 - 永远使用Service名称

1
# ✅ 正确
2
env:
3
- name: DB_HOST
4
  value: "mysql-service"
5

6
# ❌ 错误
7
env:
8
- name: DB_HOST
9
  value: "10.244.1.5"  # 硬编码IP会在Pod重启后失效

内部服务使用ClusterIP

1
# 数据库、缓存等后端服务不需要对外暴露
2
apiVersion: v1
3
kind: Service
4
metadata:
5
  name: mysql-service
6
spec:
7
  type: ClusterIP  # 或省略,默认就是ClusterIP
8
  selector:
9
    app: mysql

外部访问优先使用Ingress

1
生产环境推荐:
2
外部 → Ingress Controller → Service (ClusterIP) → Pod
3

4
而不是:
5
外部 → NodePort → Pod

环境变量vs ConfigMap

1
# 简单配置:直接使用env
2
env:
3
- name: DB_HOST
4
  value: "mysql-service"
5

6
# 复杂配置:使用ConfigMap
7
envFrom:
8
- configMapRef:
9
    name: app-config

健康检查必不可少

1
# 确保Pod健康才加入Endpoints
2
readinessProbe:
3
  httpGet:
4
    path: /health
5
    port: 80
6
  initialDelaySeconds: 5
7
  periodSeconds: 3

实验收获:

通过本次实验,我们学会了:

✅ 创建和管理四种类型的Service
✅ 使用标签选择器关联Pod和Service
✅ 通过Service名称实现服务发现
✅ 使用环境变量配置应用
✅ 理解K8s的DNS机制
✅ 掌握生产环境的最佳实践

下一步,我们将学习Deployment,用更高级的方式管理Pod副本!

4.总结#

Service核心价值：

稳定的访问入口
- 提供固定的ClusterIP和DNS名称
- Pod IP变化对应用透明
服务发现
- 通过DNS自动解析Service名称
- 无需配置中心
负载均衡
- 自动在多个Pod之间分发流量
- 支持多种算法（IPVS模式）
配置解耦
- 应用使用Service名称，不关心具体IP
- 便于实现蓝绿部署、灰度发布

生产环境建议：

1
✓ 使用IPVS模式（高性能）
2
✓ 所有内部服务使用ClusterIP
3
✓ 配置使用ConfigMap管理
4
✓ 应用通过Service名称访问其他服务
5
✓ 外部访问使用Ingress（而非NodePort）
6
✓ 有状态应用使用Headless Service + StatefulSet

四、Ingress：K8s的7层网关#

1. Ingress是什么？为什么需要它？#

1.1 Service暴露服务的局限性#

在前面的章节中，我们学习了如何使用Service暴露服务。但在生产环境中，Service有一些明显的局限性：

NodePort的问题：

1
场景：你有10个微服务需要对外暴露
2

3
使用NodePort：
4
┌─────────────────────────────────────────────────┐
5
│  用户需要记住10个不同的端口：                      │
6
│  - 用户服务：http://k8s.example.com:30001       │
7
│  - 订单服务：http://k8s.example.com:30002       │
8
│  - 商品服务：http://k8s.example.com:30003       │
9
│  - 支付服务：http://k8s.example.com:30004       │
10
│  ... 还有6个                                     │
11
└─────────────────────────────────────────────────┘
12

13
问题：
14
  ✗ 端口难记，用户体验差
15
  ✗ 不支持域名访问
16
  ✗ 无法使用标准HTTP/HTTPS端口（80/443）
17
  ✗ 无法实现基于域名/路径的路由
18
  ✗ 无法统一管理SSL证书
19
  ✗ 端口数量有限（30000-32767）

LoadBalancer的问题：

1
场景：你有10个微服务需要对外暴露
2

3
使用LoadBalancer：
4
┌─────────────────────────────────────────────────┐
5
│  需要创建10个LoadBalancer（云平台）：              │
6
│  - 用户服务：LB1 (IP: 1.2.3.4)                  │
7
│  - 订单服务：LB2 (IP: 1.2.3.5)                  │
8
│  - 商品服务：LB3 (IP: 1.2.3.6)                  │
9
│  ... 还有7个                                     │
10
└─────────────────────────────────────────────────┘
11

12
问题：
13
  ✗ 每个LoadBalancer都要收费（按小时/按流量）
14
  ✗ 10个服务 = 10个LB = 成本高昂
15
  ✗ 需要10个公网IP（IP资源浪费）
16
  ✗ 管理复杂（10个LB需要分别配置）
17
  ✗ 无法实现智能路由（域名、路径、Header）

理想的解决方案：

1
用户期望的访问方式：
2

3
- 用户服务：http://user.example.com
4
- 订单服务：http://order.example.com
5
- 商品服务：http://api.example.com/products
6
- 支付服务：http://api.example.com/payment
7

8
特点：
9
  ✓ 使用标准端口（80/443）
10
  ✓ 使用友好的域名
11
  ✓ 支持路径路由
12
  ✓ 统一管理SSL证书
13
  ✓ 只需要1个公网IP
14
  ✓ 统一入口，便于管理

这就是Ingress的价值所在！

1.2 Ingress是什么？#

用生活场景来理解：

1
想象一个大型购物中心：
2

3
没有Ingress（使用NodePort/LoadBalancer）：
4
┌────────────────────────────────────────────┐
5
│  每个商铺都有自己独立的大门：                │
6
│  - 星巴克：从东门进，上3楼，右转           │
7
│  - 优衣库：从西门进，下地下1层             │
8
│  - 电影院：从北门进，坐电梯到5楼           │
9
│                                            │
10
│  顾客：我只是想买杯咖啡，为什么这么复杂？   │
11
└────────────────────────────────────────────┘
12

13
有了Ingress（统一入口）：
14
┌────────────────────────────────────────────┐
15
│  购物中心只有1个主入口：                    │
16
│  顾客进门后，看指示牌：                     │
17
│    → 要喝咖啡？往左走，3楼星巴克            │
18
│    → 要买衣服？往右走，地下1层优衣库        │
19
│    → 要看电影？坐电梯，5楼电影院            │
20
│                                            │
21
│  Ingress = 购物中心的"智能指示牌"           │
22
└────────────────────────────────────────────┘

技术定义：

1
Ingress是什么？
2

3
Ingress是Kubernetes的API对象，用于管理外部访问集群内服务的规则。
4

5
核心特点：
6
1. 7层（HTTP/HTTPS）流量管理
7
2. 基于域名、路径、Header等进行智能路由
8
3. 统一的外部访问入口
9
4. 支持SSL/TLS终止
10
5. 支持负载均衡、重定向、重写等高级功能
11

12
类比：
13
  Service = 4层负载均衡（IP + Port）
14
  Ingress = 7层负载均衡（域名 + 路径 + Header）

1.3 Ingress的组成部分#

Ingress不是一个单独的组件，它由两部分组成：

1. Ingress资源（配置规则）

1
# 这是一个Ingress资源的示例
2
apiVersion: networking.k8s.io/v1
3
kind: Ingress
4
metadata:
5
  name: my-ingress
6
spec:
7
  rules:
8
  - host: www.example.com        # 域名
9
    http:
10
      paths:
11
      - path: /api               # 路径
12
        pathType: Prefix
13
        backend:
14
          service:
15
            name: api-service    # 指向的Service
16
            port:
17
              number: 80

Ingress资源只是配置规则，本身不处理流量！

2. Ingress Controller（流量处理器）

1
Ingress Controller是什么？
2

3
Ingress Controller是一个实际运行的Pod，它：
4
1. 监听Kubernetes API，读取Ingress资源
5
2. 根据Ingress规则配置反向代理（如Nginx）
6
3. 接收外部流量，按规则转发到对应Service
7

8
常见的Ingress Controller：
9
  - Nginx Ingress Controller（最流行）
10
  - Traefik
11
  - HAProxy
12
  - Kong
13
  - Istio Gateway
14
  - 云平台的Ingress（如AWS ALB、Azure Application Gateway）
15

16
类比：
17
  Ingress资源 = 交通规则（规则定义）
18
  Ingress Controller = 交警（执行规则）

1.4 Ingress工作原理#

完整的流量转发流程：

1
外部用户访问：http://www.example.com/api/users
2

3
步骤1：DNS解析
4
┌─────────────────────────────────────────┐
5
│  用户浏览器                              │
6
│  输入：www.example.com                  │
7
│    ↓                                    │
8
│  DNS解析：www.example.com → 1.2.3.4    │
9
│  （Ingress Controller的外部IP）         │
10
└─────────────────────────────────────────┘
11
                ↓
12
步骤2：到达Ingress Controller
13
┌─────────────────────────────────────────┐
14
│  Ingress Controller Pod                 │
15
│  （运行Nginx/Traefik等反向代理）         │
16
│                                         │
17
│  接收请求：                              │
18
│    Host: www.example.com               │
19
│    Path: /api/users                    │
20
└─────────────────────────────────────────┘
21
                ↓
22
步骤3：匹配Ingress规则
23
┌─────────────────────────────────────────┐
24
│  Ingress Controller查找规则：            │
25
│                                         │
26
│  ✓ 找到匹配的Ingress：                  │
27
│    - host: www.example.com             │
28
│    - path: /api                        │
29
│    - backend: api-service:80           │
30
└─────────────────────────────────────────┘
31
                ↓
32
步骤4：转发到Service
33
┌─────────────────────────────────────────┐
34
│  Ingress Controller转发请求到：          │
35
│  http://api-service:80/api/users       │
36
│  （Service的ClusterIP）                 │
37
└─────────────────────────────────────────┘
38
                ↓
39
步骤5：Service负载均衡到Pod
40
┌─────────────────────────────────────────┐
41
│  Service (ClusterIP)                    │
42
│  通过kube-proxy/IPVS负载均衡：          │
43
│    → Pod1: 10.244.1.10:8080            │
44
│    → Pod2: 10.244.2.20:8080            │
45
│    → Pod3: 10.244.3.30:8080            │
46
└─────────────────────────────────────────┘
47
                ↓
48
步骤6：Pod处理请求并返回响应
49
┌─────────────────────────────────────────┐
50
│  Pod响应 → Service → Ingress Controller │
51
│          → 用户浏览器                    │
52
└─────────────────────────────────────────┘

用流程图表示：

1
外部用户
2
   ↓ (1) HTTP请求：www.example.com/api
3
┌──────────────────────────────┐
4
│  Ingress Controller Pod      │
5
│  (Nginx/Traefik等)           │
6
│  外部IP: 1.2.3.4             │
7
└──────────────────────────────┘
8
   ↓ (2) 根据Ingress规则路由
9
┌──────────────────────────────┐
10
│  Service (ClusterIP)         │
11
│  api-service: 10.96.100.50   │
12
└──────────────────────────────┘
13
   ↓ (3) 负载均衡
14
┌─────────┐  ┌─────────┐  ┌─────────┐
15
│  Pod1   │  │  Pod2   │  │  Pod3   │
16
└─────────┘  └─────────┘  └─────────┘

1.5 Ingress与Service的关系#

Ingress和Service是配合使用的，不是替代关系！

1
架构层次：
2

3
外部用户
4
   ↓
5
Ingress（7层路由）
6
   ↓
7
Service（4层负载均衡）
8
   ↓
9
Pod（应用容器）
10

11
职责分工：
12

13
Ingress的职责：
14
  ✓ 接收外部HTTP/HTTPS流量
15
  ✓ 基于域名、路径、Header路由
16
  ✓ SSL/TLS终止
17
  ✓ 重写、重定向
18
  ✓ 统一访问入口
19

20
Service的职责：
21
  ✓ 为Pod提供稳定的ClusterIP
22
  ✓ 在Pod之间进行负载均衡
23
  ✓ 服务发现（DNS）
24
  ✓ 健康检查

为什么不能跳过Service，Ingress直接转发到Pod？

1
技术上可以，但不推荐：
2

3
问题1：Pod IP不稳定
4
  - Pod重启/扩缩容时IP会变化
5
  - Ingress需要频繁更新配置
6

7
问题2：失去Service的负载均衡能力
8
  - Service的健康检查
9
  - Service的会话保持
10
  - Service的故障转移
11

12
问题3：违背Kubernetes设计理念
13
  - Service是Pod的抽象层
14
  - 所有访问Pod的流量都应该经过Service
15

16
最佳实践：
17
  Ingress → Service → Pod
18
  这是标准的三层架构

1.6 Ingress vs Service对比#

特性	Service (NodePort/LB)	Ingress
OSI层	4层（TCP/UDP）	7层（HTTP/HTTPS）
路由能力	IP + 端口	域名 + 路径 + Header
成本	每个服务1个LB（贵）	多个服务共享1个入口（省钱）
端口	需要不同端口	统一80/443端口
SSL	每个Service单独配置	统一管理证书
域名	不支持	原生支持
高级功能	无	重写、重定向、金丝雀等
使用场景	内部服务、简单暴露	生产环境外部访问

典型架构对比：

1
传统方式（Service LoadBalancer）：
2
┌─────────────────────────────────────────┐
3
│  用户服务：LB1 (1.2.3.4:80) → Service1  │
4
│  订单服务：LB2 (1.2.3.5:80) → Service2  │
5
│  商品服务：LB3 (1.2.3.6:80) → Service3  │
6
│                                         │
7
│  成本：3个LoadBalancer                  │
8
│  IP：3个公网IP                          │
9
│  管理：分散配置                          │
10
└─────────────────────────────────────────┘
11

12
Ingress方式：
13
┌─────────────────────────────────────────┐
14
│  Ingress (1.2.3.4:80/443)               │
15
│    ├─ user.example.com → Service1       │
16
│    ├─ order.example.com → Service2      │
17
│    └─ api.example.com/products → Svc3  │
18
│                                         │
19
│  成本：1个LoadBalancer（或免费方案）     │
20
│  IP：1个公网IP                          │
21
│  管理：统一配置                          │
22
└─────────────────────────────────────────┘

1.7 Ingress的本质#

Ingress Controller的本质是什么？

1
Ingress Controller = Nginx/Traefik + 自动配置器
2

3
以Nginx Ingress Controller为例：
4

5
传统Nginx配置（手动编写）：
6
┌──────────────────────────────────────┐
7
│  server {                            │
8
│    listen 80;                        │
9
│    server_name www.example.com;      │
10
│    location /api {                   │
11
│      proxy_pass http://backend:8080; │
12
│    }                                 │
13
│  }                                   │
14
└──────────────────────────────────────┘
15

16
Ingress Controller的魔法：
17
┌──────────────────────────────────────┐
18
│  1. 监听Kubernetes API                │
19
│  2. 读取Ingress资源                   │
20
│  3. 自动生成Nginx配置文件              │
21
│  4. 重载Nginx（无需手动操作）          │
22
│  5. 持续监听，配置变化自动更新          │
23
└──────────────────────────────────────┘
24

25
你只需要：
26
  - 创建Ingress YAML
27
  - kubectl apply -f ingress.yaml
28
  - 剩下的交给Ingress Controller！

Ingress Controller做了什么？

1
┌─────────────────────────────────────────────┐
2
│  Ingress Controller的工作流程：              │
3
│                                             │
4
│  1. 启动时：                                │
5
│     - 创建Nginx/Traefik容器                │
6
│     - 监听Kubernetes API                   │
7
│                                             │
8
│  2. 发现Ingress资源时：                     │
9
│     - 读取Ingress规则                      │
10
│     - 转换为Nginx配置                      │
11
│     - 更新Nginx配置文件                    │
12
│     - 执行nginx -s reload                  │
13
│                                             │
14
│  3. Ingress变化时：                         │
15
│     - 检测到变化（增/删/改）                │
16
│     - 重新生成配置                         │
17
│     - 热更新（不中断现有连接）              │
18
│                                             │
19
│  4. 处理流量时：                            │
20
│     - 接收HTTP/HTTPS请求                   │
21
│     - 匹配Ingress规则                      │
22
│     - 转发到对应Service                    │
23
│     - 返回响应给客户端                     │
24
└─────────────────────────────────────────────┘

小结#

Ingress解决了什么问题？

1
1. 统一外部访问入口
2
   - 一个公网IP服务所有应用
3
   - 节省成本（云平台LoadBalancer）
4

5
2. 基于7层的智能路由
6
   - 域名路由：user.example.com → 用户服务
7
   - 路径路由：/api/orders → 订单服务
8
   - Header路由：移动端 → 移动服务
9

10
3. 简化管理
11
   - 统一管理SSL证书
12
   - 统一配置访问策略
13
   - 声明式配置（YAML）
14

15
4. 企业级功能
16
   - 金丝雀发布
17
   - 灰度发布
18
   - A/B测试
19
   - 流量分割

下一步： 我们将详细学习Ingress能实现哪些功能，以及不同的部署方式。

2. Ingress功能详解#

2.1 基础功能：基于域名的路由#

功能说明： 根据不同的域名，将流量转发到不同的Service。

使用场景：

1
场景：一个公司有多个子系统
2
- 用户系统：user.example.com
3
- 订单系统：order.example.com
4
- 商品系统：product.example.com
5

6
传统方式：需要3个LoadBalancer（贵！）
7
Ingress方式：1个Ingress搞定（省钱！）

配置示例：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: multi-domain-ingress
5
spec:
6
  rules:
7
  # 规则1：用户系统
8
  - host: user.example.com
9
    http:
10
      paths:
11
      - path: /
12
        pathType: Prefix
13
        backend:
14
          service:
15
            name: user-service
16
            port:
17
              number: 80
18

19
  # 规则2：订单系统
20
  - host: order.example.com
21
    http:
22
      paths:
23
      - path: /
24
        pathType: Prefix
25
        backend:
26
          service:
27
            name: order-service
28
            port:
29
              number: 80
30

31
  # 规则3：商品系统
32
  - host: product.example.com
33
    http:
34
      paths:
35
      - path: /
36
        pathType: Prefix
37
        backend:
38
          service:
39
            name: product-service
40
            port:
41
              number: 80

路由流程：

1
用户访问：user.example.com
2
  ↓
3
Ingress检测Host头：user.example.com
4
  ↓
5
匹配规则1 → 转发到user-service
6
  ↓
7
user-service → user-pod
8

9
用户访问：order.example.com
10
  ↓
11
Ingress检测Host头：order.example.com
12
  ↓
13
匹配规则2 → 转发到order-service
14
  ↓
15
order-service → order-pod

2.2 基于路径的路由#

功能说明： 根据URL路径，将流量转发到不同的Service。

使用场景：

1
场景：一个统一的API网关
2
- /api/users → 用户服务
3
- /api/orders → 订单服务
4
- /api/products → 商品服务
5
- /static → 静态文件服务
6

7
优势：
8
  ✓ 统一域名（如api.example.com）
9
  ✓ 路径清晰，符合RESTful规范
10
  ✓ 便于API管理和版本控制

配置示例：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: path-based-ingress
5
spec:
6
  rules:
7
  - host: api.example.com
8
    http:
9
      paths:
10
      # 用户API
11
      - path: /api/users
12
        pathType: Prefix
13
        backend:
14
          service:
15
            name: user-service
16
            port:
17
              number: 8080
18

19
      # 订单API
20
      - path: /api/orders
21
        pathType: Prefix
22
        backend:
23
          service:
24
            name: order-service
25
            port:
26
              number: 8080
27

28
      # 商品API
29
      - path: /api/products
30
        pathType: Prefix
31
        backend:
32
          service:
33
            name: product-service
34
            port:
35
              number: 8080
36

37
      # 静态文件
38
      - path: /static
39
        pathType: Prefix
40
        backend:
41
          service:
42
            name: static-service
43
            port:
44
              number: 80

pathType详解：

pathType	匹配规则	示例
Prefix	前缀匹配	`/api` 匹配 `/api/users`、`/api/orders`
Exact	精确匹配	`/api` 只匹配 `/api`，不匹配 `/api/users`
ImplementationSpecific	由Ingress Controller决定	取决于具体实现

匹配示例：

1
配置：path: /api, pathType: Prefix
2

3
✓ 匹配：
4
  - /api
5
  - /api/
6
  - /api/users
7
  - /api/users/123
8

9
✗ 不匹配：
10
  - /apis
11
  - /v1/api
12

13
配置：path: /api, pathType: Exact
14

15
✓ 匹配：
16
  - /api
17

18
✗ 不匹配：
19
  - /api/
20
  - /api/users

2.3 HTTPS和SSL/TLS终止#

功能说明： Ingress可以在边缘终止SSL/TLS，后端Service使用HTTP通信。

使用场景：

1
场景：需要HTTPS加密访问
2

3
传统方式：
4
  - 每个Service配置SSL证书
5
  - 证书管理分散
6
  - 证书更新复杂
7

8
Ingress方式：
9
  - 证书统一配置在Ingress
10
  - 证书集中管理
11
  - 后端Service无需关心SSL

工作原理：

1
外部用户
2
  ↓ HTTPS (443端口，加密)
3
Ingress Controller
4
  ↓ HTTP (80端口，明文)
5
Service
6
  ↓
7
Pod
8

9
SSL终止发生在Ingress Controller层

配置示例：

1
apiVersion: v1
2
kind: Secret
3
metadata:
4
  name: example-tls
5
type: kubernetes.io/tls
6
data:
7
  tls.crt: LS0tLS1CRUdJTi... # Base64编码的证书
8
  tls.key: LS0tLS1CRUdJTi... # Base64编码的私钥
9

10
---
11
apiVersion: networking.k8s.io/v1
12
kind: Ingress
13
metadata:
14
  name: https-ingress
15
spec:
16
  tls:
17
  - hosts:
18
    - www.example.com
19
    - api.example.com
20
    secretName: example-tls    # 引用证书Secret
21
  rules:
22
  - host: www.example.com
23
    http:
24
      paths:
25
      - path: /
26
        pathType: Prefix
27
        backend:
28
          service:
29
            name: web-service
30
            port:
31
              number: 80

创建TLS Secret：

1
# 方式1：从证书文件创建
2
kubectl create secret tls example-tls \
3
  --cert=path/to/tls.crt \
4
  --key=path/to/tls.key
5

6
# 方式2：使用Let's Encrypt自动生成（需要cert-manager）
7
# 后面实操环节会演示

HTTPS重定向（HTTP自动跳转HTTPS）：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: https-redirect-ingress
5
  annotations:
6
    nginx.ingress.kubernetes.io/ssl-redirect: "true"    # 自动重定向
7
    nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
8
spec:
9
  tls:
10
  - hosts:
11
    - www.example.com
12
    secretName: example-tls
13
  rules:
14
  - host: www.example.com
15
    http:
16
      paths:
17
      - path: /
18
        pathType: Prefix
19
        backend:
20
          service:
21
            name: web-service
22
            port:
23
              number: 80

2.4 URL重写和重定向#

功能说明： 修改请求路径或重定向到其他URL。

使用场景1：路径重写

1
场景：前端路径和后端路径不一致
2

3
用户访问：http://api.example.com/v1/users
4
后端期望：http://api.example.com/users
5

6
需要去掉 /v1 前缀

路径重写配置：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: rewrite-ingress
5
  annotations:
6
    nginx.ingress.kubernetes.io/rewrite-target: /$2
7
spec:
8
  rules:
9
  - host: api.example.com
10
    http:
11
      paths:
12
      - path: /v1(/|$)(.*)
13
        pathType: ImplementationSpecific
14
        backend:
15
          service:
16
            name: api-service
17
            port:
18
              number: 80

路径重写示例：

1
用户请求：/v1/users/123
2
  ↓ 匹配正则：/v1(/|$)(.*)
3
  ↓ $2 = users/123
4
  ↓ rewrite-target: /$2
5
转发到后端：/users/123
6

7
用户请求：/v1/orders
8
  ↓
9
转发到后端：/orders

使用场景2：永久重定向

1
场景：域名迁移或统一入口
2

3
旧域名：old.example.com
4
新域名：new.example.com
5

6
需要将旧域名访问自动跳转到新域名

重定向配置：

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: redirect-ingress
5
  annotations:
6
    nginx.ingress.kubernetes.io/permanent-redirect: https://new.example.com
7
spec:
8
  rules:
9
  - host: old.example.com
10
    http:
11
      paths:
12
      - path: /
13
        pathType: Prefix
14
        backend:
15
          service:
16
            name: dummy-service   # 实际不会访问
17
            port:
18
              number: 80

2.5 金丝雀发布（Canary Deployment）#

功能说明： 将一小部分流量导向新版本，验证稳定后再全量发布。

使用场景：

1
场景：发布新版本应用v2，但不确定是否稳定
2

3
传统方式：直接全量发布 → 出问题影响所有用户
4
金丝雀方式：先导5%流量到v2 → 稳定后逐步增加 → 最终100%
5

6
类比：煤矿工人带金丝雀下井，金丝雀对有毒气体敏感
7
     如果金丝雀死了，说明环境有问题
8

9
金丝雀发布：新版本就是"金丝雀"
10
     先让少量用户体验新版本
11
     如果出问题，影响范围小

金丝雀发布策略：

1
1. 基于流量比例
2
   - 10%流量 → v2版本
3
   - 90%流量 → v1版本
4

5
2. 基于Header
6
   - 如果Header包含 canary=true → v2版本
7
   - 否则 → v1版本
8
   （内部测试人员使用）
9

10
3. 基于Cookie
11
   - 如果Cookie包含 user_type=vip → v2版本
12
   - 否则 → v1版本
13
   （VIP用户先体验）

配置示例1：基于权重的金丝雀

1
# 主Ingress（稳定版本v1）
2
apiVersion: networking.k8s.io/v1
3
kind: Ingress
4
metadata:
5
  name: app-ingress
6
spec:
7
  rules:
8
  - host: www.example.com
9
    http:
10
      paths:
11
      - path: /
12
        pathType: Prefix
13
        backend:
14
          service:
15
            name: app-v1        # 稳定版本
16
            port:
17
              number: 80
18

19
---
20
# 金丝雀Ingress（新版本v2）
21
apiVersion: networking.k8s.io/v1
22
kind: Ingress
23
metadata:
24
  name: app-canary
25
  annotations:
26
    nginx.ingress.kubernetes.io/canary: "true"
27
    nginx.ingress.kubernetes.io/canary-weight: "10"    # 10%流量
28
spec:
29
  rules:
30
  - host: www.example.com
31
    http:
32
      paths:
33
      - path: /
34
        pathType: Prefix
35
        backend:
36
          service:
37
            name: app-v2        # 新版本
38
            port:
39
              number: 80

流量分配：

1
100个请求：
2
  → 90个请求到app-v1（稳定版本）
3
  → 10个请求到app-v2（金丝雀版本）
4

5
观察v2稳定后，逐步调整权重：
6
  canary-weight: 10 → 30 → 50 → 80 → 100
7

8
最终v2完全替代v1：
9
  删除主Ingress，金丝雀Ingress改为主Ingress

配置示例2：基于Header的金丝雀

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: app-canary-header
5
  annotations:
6
    nginx.ingress.kubernetes.io/canary: "true"
7
    nginx.ingress.kubernetes.io/canary-by-header: "canary"
8
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
9
spec:
10
  rules:
11
  - host: www.example.com
12
    http:
13
      paths:
14
      - path: /
15
        pathType: Prefix
16
        backend:
17
          service:
18
            name: app-v2
19
            port:
20
              number: 80

测试：

1
# 普通用户访问（到v1）
2
curl http://www.example.com
3

4
# 测试人员访问（到v2）
5
curl -H "canary: true" http://www.example.com

2.6 A/B测试#

功能说明： 根据用户特征，将流量导向不同版本，比较效果。

使用场景：

1
场景：测试新UI设计是否提升转化率
2

3
A版本：原有UI
4
B版本：新UI设计
5

6
策略：
7
  - 50%用户看A版本
8
  - 50%用户看B版本
9

10
收集数据：
11
  - A版本转化率：5%
12
  - B版本转化率：8%
13

14
结论：B版本更好，全量上线B版本

A/B测试 vs 金丝雀发布：

1
金丝雀发布：
2
  - 目标：验证稳定性
3
  - 逐步增加流量
4
  - 出问题立即回滚
5

6
A/B测试：
7
  - 目标：比较效果
8
  - 流量比例固定
9
  - 收集数据分析

配置示例：基于Cookie的A/B测试

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: app-ab-test
5
  annotations:
6
    nginx.ingress.kubernetes.io/canary: "true"
7
    nginx.ingress.kubernetes.io/canary-by-cookie: "ab_test"
8
    nginx.ingress.kubernetes.io/canary-by-cookie-value: "version_b"
9
spec:
10
  rules:
11
  - host: www.example.com
12
    http:
13
      paths:
14
      - path: /
15
        pathType: Prefix
16
        backend:
17
          service:
18
            name: app-version-b
19
            port:
20
              number: 80

测试：

1
# 用户A（看到A版本）
2
curl http://www.example.com
3

4
# 用户B（看到B版本）
5
curl --cookie "ab_test=version_b" http://www.example.com

2.7 其他高级功能#

1. 速率限制（Rate Limiting）

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: rate-limit-ingress
5
  annotations:
6
    nginx.ingress.kubernetes.io/limit-rps: "10"         # 每秒10个请求
7
    nginx.ingress.kubernetes.io/limit-connections: "5"  # 最多5个并发连接
8
spec:
9
  rules:
10
  - host: api.example.com
11
    http:
12
      paths:
13
      - path: /
14
        pathType: Prefix
15
        backend:
16
          service:
17
            name: api-service
18
            port:
19
              number: 80

2. IP白名单/黑名单

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: whitelist-ingress
5
  annotations:
6
    nginx.ingress.kubernetes.io/whitelist-source-range: "10.0.0.0/8,192.168.1.0/24"
7
spec:
8
  rules:
9
  - host: admin.example.com
10
    http:
11
      paths:
12
      - path: /
13
        pathType: Prefix
14
        backend:
15
          service:
16
            name: admin-service
17
            port:
18
              number: 80

3. 基本认证（Basic Auth）

1
# 创建密码文件
2
htpasswd -c auth admin
3
# 输入密码
4

5
# 创建Secret
6
kubectl create secret generic basic-auth --from-file=auth

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: auth-ingress
5
  annotations:
6
    nginx.ingress.kubernetes.io/auth-type: basic
7
    nginx.ingress.kubernetes.io/auth-secret: basic-auth
8
    nginx.ingress.kubernetes.io/auth-realm: "Authentication Required"
9
spec:
10
  rules:
11
  - host: admin.example.com
12
    http:
13
      paths:
14
      - path: /
15
        pathType: Prefix
16
        backend:
17
          service:
18
            name: admin-service
19
            port:
20
              number: 80

4. 跨域配置（CORS）

1
apiVersion: networking.k8s.io/v1
2
kind: Ingress
3
metadata:
4
  name: cors-ingress
5
  annotations:
6
    nginx.ingress.kubernetes.io/enable-cors: "true"
7
    nginx.ingress.kubernetes.io/cors-allow-origin: "https://frontend.example.com"
8
    nginx.ingress.kubernetes.io/cors-allow-methods: "GET, POST, PUT, DELETE"
9
spec:
10
  rules:
11
  - host: api.example.com
12
    http:
13
      paths:
14
      - path: /
15
        pathType: Prefix
16
        backend:
17
          service:
18
            name: api-service
19
            port:
20
              number: 80

2.8 Ingress Controller部署方式#

Ingress Controller有多种部署方式，适用于不同的环境和需求。

部署方式1：LoadBalancer + Deployment#

适用场景： 云平台环境（AWS、阿里云、腾讯云等）

架构图：

1
外部用户
2
   ↓
3
云平台LoadBalancer (公网IP: 1.2.3.4)
4
   ↓
5
Ingress Controller Service (LoadBalancer类型)
6
   ↓
7
Ingress Controller Pods (Deployment, 2-3副本)
8
   ↓
9
应用Service
10
   ↓
11
应用Pods

特点：

1
优点：
2
  ✓ 高可用（多副本 + LB自动分发流量）
3
  ✓ 自动故障转移
4
  ✓ 云平台管理LoadBalancer
5
  ✓ 简单易用
6

7
缺点：
8
  ✗ 云平台LoadBalancer收费
9
  ✗ 依赖云平台
10
  ✗ 不适用于裸金属环境

部署示例：

1
# Ingress Controller Deployment
2
apiVersion: apps/v1
3
kind: Deployment
4
metadata:
5
  name: nginx-ingress-controller
6
  namespace: ingress-nginx
7
spec:
8
  replicas: 2                    # 多副本高可用
9
  selector:
10
    matchLabels:
11
      app: nginx-ingress
12
  template:
13
    metadata:
14
      labels:
15
        app: nginx-ingress
16
    spec:
17
      containers:
18
      - name: nginx-ingress-controller
19
        image: k8s.gcr.io/ingress-nginx/controller:v1.0.0
20
        args:
21
        - /nginx-ingress-controller
22
        - --configmap=$(POD_NAMESPACE)/nginx-configuration
23

24
---
25
# LoadBalancer Service
26
apiVersion: v1
27
kind: Service
28
metadata:
29
  name: ingress-nginx
30
  namespace: ingress-nginx
31
spec:
32
  type: LoadBalancer              # 云平台自动创建LB
33
  ports:
34
  - name: http
35
    port: 80
36
    targetPort: 80
37
  - name: https
38
    port: 443
39
    targetPort: 443
40
  selector:
41
    app: nginx-ingress

部署方式2：DaemonSet + hostNetwork#

适用场景： 裸金属环境（本地机房、私有云）

架构图：

1
外部用户
2
   ↓
3
物理机/虚拟机 (直接访问Node IP)
4
   ↓
5
Ingress Controller Pod (每个Node运行一个)
6
   ↓ hostNetwork模式（使用Node的网络栈）
7
Node的80/443端口
8
   ↓
9
应用Service
10
   ↓
11
应用Pods

特点：

1
优点：
2
  ✓ 无需LoadBalancer（省钱）
3
  ✓ 直接使用Node的80/443端口
4
  ✓ 性能好（无额外网络层）
5
  ✓ 适用于裸金属环境
6

7
缺点：
8
  ✗ 每个Node只能运行一个Ingress Pod
9
  ✗ Node的80/443端口被占用
10
  ✗ 需要外部负载均衡器（如Nginx/HAProxy）分发到各Node

部署示例：

1
apiVersion: apps/v1
2
kind: DaemonSet
3
metadata:
4
  name: nginx-ingress-controller
5
  namespace: ingress-nginx
6
spec:
7
  selector:
8
    matchLabels:
9
      app: nginx-ingress
10
  template:
11
    metadata:
12
      labels:
13
        app: nginx-ingress
14
    spec:
15
      hostNetwork: true           # 关键：使用Node网络
16
      dnsPolicy: ClusterFirstWithHostNet
17
      containers:
18
      - name: nginx-ingress-controller
19
        image: k8s.gcr.io/ingress-nginx/controller:v1.0.0
20
        args:
21
        - /nginx-ingress-controller
22
        ports:
23
        - name: http
24
          containerPort: 80
25
          hostPort: 80            # 绑定Node的80端口
26
        - name: https
27
          containerPort: 443
28
          hostPort: 443           # 绑定Node的443端口
29
      nodeSelector:
30
        ingress: "true"           # 只在特定Node运行

标记Node运行Ingress：

1
# 给Node打标签
2
kubectl label node node1 ingress=true
3
kubectl label node node2 ingress=true
4

5
# 验证
6
kubectl get nodes --show-labels | grep ingress

外部负载均衡配置（Nginx示例）：

1
# 在外部Nginx上配置
2
upstream k8s_ingress {
3
    server 192.168.100.21:80;    # node1
4
    server 192.168.100.22:80;    # node2
5
}
6

7
server {
8
    listen 80;
9
    server_name *.example.com;
10

11
    location / {
12
        proxy_pass http://k8s_ingress;
13
        proxy_set_header Host $host;
14
        proxy_set_header X-Real-IP $remote_addr;
15
    }
16
}

部署方式3：NodePort + Deployment#

适用场景： 测试环境、小规模集群

架构图：

1
外部用户
2
   ↓
3
任意Node IP:NodePort (如192.168.100.21:30080)
4
   ↓
5
Ingress Controller Service (NodePort类型)
6
   ↓
7
Ingress Controller Pods
8
   ↓
9
应用Service
10
   ↓
11
应用Pods

特点：

1
优点：
2
  ✓ 无需LoadBalancer
3
  ✓ 简单易用
4
  ✓ 适合测试环境
5

6
缺点：
7
  ✗ 端口不是标准80/443
8
  ✗ 需要记住NodePort
9
  ✗ 不适合生产环境

部署示例：

1
apiVersion: v1
2
kind: Service
3
metadata:
4
  name: ingress-nginx
5
  namespace: ingress-nginx
6
spec:
7
  type: NodePort
8
  ports:
9
  - name: http
10
    port: 80
11
    targetPort: 80
12
    nodePort: 30080         # 外部访问Node:30080
13
  - name: https
14
    port: 443
15
    targetPort: 443
16
    nodePort: 30443
17
  selector:
18
    app: nginx-ingress

三种部署方式对比#

特性	LoadBalancer+Deployment	DaemonSet+hostNetwork	NodePort+Deployment
适用环境	云平台	裸金属/私有云	测试环境
外部访问	LB公网IP:80/443	Node IP:80/443	Node IP:30080
成本	需要付费LB	免费（需外部LB）	免费
高可用	云平台LB自动实现	需外部LB	无（单点）
端口	标准80/443	标准80/443	非标准端口
生产推荐	✓	✓	✗

生产环境推荐：

1
云平台：LoadBalancer + Deployment
2
  - AWS EKS、阿里云ACK、腾讯云TKE等
3
  - 自动创建ELB/SLB/CLB
4
  - 高可用、易管理
5

6
裸金属/私有云：DaemonSet + hostNetwork
7
  - 自建机房、私有云
8
  - 配合外部Nginx/HAProxy/Keepalived
9
  - 成本低、性能好
10

11
混合方案：DaemonSet + hostNetwork + MetalLB
12
  - 裸金属环境
13
  - 使用MetalLB提供LoadBalancer能力
14
  - 结合两种方案的优点

小结#

Ingress功能总结：

1
基础功能：
2
  ✓ 基于域名路由
3
  ✓ 基于路径路由
4
  ✓ HTTPS/SSL终止
5

6
高级功能：
7
  ✓ URL重写/重定向
8
  ✓ 金丝雀发布
9
  ✓ A/B测试
10
  ✓ 速率限制
11
  ✓ IP白名单
12
  ✓ 认证授权
13
  ✓ CORS跨域
14

15
部署方式：
16
  ✓ LoadBalancer + Deployment（云平台）
17
  ✓ DaemonSet + hostNetwork（裸金属）
18
  ✓ NodePort + Deployment（测试）

下一步： 我们将通过实际操作，部署Ingress Controller并演示各种功能。

3. Ingress实战操作#

3.1 部署Nginx Ingress Controller（DaemonSet模式）#

步骤1：标记运行Ingress的Node

1
kubectl label node node1 ingress=true
2
kubectl label node node2 ingress=true

步骤2：下载并修改部署文件

1
# 下载官方部署文件
2
wget https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.8.1/deploy/static/provider/baremetal/deploy.yaml
3

4
# 关键修改：
5
# 1. Deployment改为DaemonSet
6
# 2. 添加 hostNetwork: true
7
# 3. 添加 dnsPolicy: ClusterFirstWithHostNet
8
# 4. 添加 nodeSelector: ingress: "true"
9
# 5. 镜像改为国内源（可选）

步骤3：部署

1
kubectl apply -f deploy.yaml
2
kubectl get pods -n ingress-nginx -o wide

3.2 实验1：基于域名路由#

给containerd配置代理：

在此之前，为了方便我们下面使用docker官方的镜像，由于国内无法直接拉取官方镜像，我们需要给节点的containerd配置代理，设置我们的私有仓库reg.westos.org不走代理。

1
#在每个k8s节点上运行，换成你的代理地址
2
mkdir -p /etc/systemd/system/containerd.service.d
3
cat <<EOF > /etc/systemd/system/containerd.service.d/proxy.conf
4
[Service]
5
Environment="HTTP_PROXY=http://192.168.10.141:7897"
6
Environment="HTTPS_PROXY=http://192.168.10.141:7897"
7
Environment="NO_PROXY=localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.svc,.cluster.local,reg.westos.org"
8
EOF
9
sudo systemctl daemon-reload
10
sudo systemctl restart containerd

步骤1：创建两个应用Pod：

1
# 创建nginx应用Pod（2个副本）
2
cat > nginx-app-pods.yaml <<EOF
3
apiVersion: v1
4
kind: Pod
5
metadata:
6
  name: nginx-app-1
7
  labels:
8
    app: nginx-app
9
spec:
10
  containers:
11
  - name: nginx
12
    image: nginx:1.20
13
    ports:
14
    - containerPort: 80
15
---
16
apiVersion: v1
17
kind: Pod
18
metadata:
19
  name: nginx-app-2
20
  labels:
21
    app: nginx-app
22
spec:
23
  containers:
24
  - name: nginx
25
    image: nginx:1.20
26
    ports:
27
    - containerPort: 80
28
EOF
29

30
kubectl apply -f nginx-app-pods.yaml
31

32
# 创建httpd应用Pod（2个副本）
33
cat > httpd-app-pods.yaml <<EOF
34
apiVersion: v1
35
kind: Pod
36
metadata:
37
  name: httpd-app-1
38
  labels:
39
    app: httpd-app
40
spec:
41
  containers:
42
  - name: httpd
43
    image: httpd:2.4
44
    ports:
45
    - containerPort: 80
46
---
47
apiVersion: v1
48
kind: Pod
49
metadata:
50
  name: httpd-app-2
51
  labels:
52
    app: httpd-app
53
spec:
54
  containers:
55
  - name: httpd
56
    image: httpd:2.4
57
    ports:
58
    - containerPort: 80
59
EOF
60

61
kubectl apply -f httpd-app-pods.yaml
62

63
# 等待Pod就绪
64
kubectl get pods -l app=nginx-app
65
kubectl get pods -l app=httpd-app

步骤2：创建Service：

1
# 创建nginx-service
2
cat > nginx-service.yaml <<EOF
3
apiVersion: v1
4
kind: Service
5
metadata:
6
  name: nginx-service
7
spec:
8
  selector:
9
    app: nginx-app
10
  ports:
11
  - port: 80
12
    targetPort: 80
13
EOF
14

15
kubectl apply -f nginx-service.yaml
16

17
# 创建httpd-service
18
cat > httpd-service.yaml <<EOF
19
apiVersion: v1
20
kind: Service
21
metadata:
22
  name: httpd-service
23
spec:
24
  selector:
25
    app: httpd-app
26
  ports:
27
  - port: 80
28
    targetPort: 80
29
EOF
30

31
kubectl apply -f httpd-service.yaml
32

33
# 查看Service和Endpoints
34
kubectl get svc
35
kubectl get endpoints
36

37
# 创建基于域名的Ingress
38
cat > domain-ingress.yaml <<EOF
39
apiVersion: networking.k8s.io/v1
40
kind: Ingress
41
metadata:
42
  name: domain-ingress
43
spec:
44
  ingressClassName: nginx
45
  rules:
46
  - host: nginx.example.com
47
    http:
48
      paths:
49
      - path: /
50
        pathType: Prefix
51
        backend:
52
          service:
53
            name: nginx-service
54
            port:
55
              number: 80
56
  - host: httpd.example.com
57
    http:
58
      paths:
59
      - path: /
60
        pathType: Prefix
61
        backend:
62
          service:
63
            name: httpd-service
64
            port:
65
              number: 80
66
EOF
67

68
kubectl apply -f domain-ingress.yaml
69

70
# 配置hosts（测试机器）
71
echo "192.168.100.21 nginx.example.com httpd.example.com" >> /etc/hosts
72

73
# 测试
74
curl http://nginx.example.com
75
curl http://httpd.example.com
76

77
# 清理
78
kubectl delete ingress domain-ingress
79
kubectl delete svc nginx-service httpd-service
80
kubectl delete pod nginx-app-1 nginx-app-2 httpd-app-1 httpd-app-2

3.3 实验2：基于路径路由 + URL重写#

前提：使用实验1创建的Pod和Service，如果已清理则需要重新创建

1
# 创建基于路径的Ingress
2
cat > path-rewrite-ingress.yaml <<EOF
3
apiVersion: networking.k8s.io/v1
4
kind: Ingress
5
metadata:
6
  name: path-rewrite
7
  annotations:
8
    nginx.ingress.kubernetes.io/rewrite-target: /\$2
9
spec:
10
  ingressClassName: nginx
11
  rules:
12
  - host: api.example.com
13
    http:
14
      paths:
15
      - path: /nginx(/|$)(.*)
16
        pathType: ImplementationSpecific
17
        backend:
18
          service:
19
            name: nginx-service
20
            port:
21
              number: 80
22
      - path: /httpd(/|$)(.*)
23
        pathType: ImplementationSpecific
24
        backend:
25
          service:
26
            name: httpd-service
27
            port:
28
              number: 80
29
EOF
30

31
kubectl apply -f path-rewrite-ingress.yaml
32

33
# 配置hosts（测试机器）
34
echo "192.168.100.21 api.example.com" >> /etc/hosts
35

36
# 测试
37
curl http://api.example.com/nginx   # 转发到nginx-service/
38
curl http://api.example.com/httpd   # 转发到httpd-service/
39

40
# 清理
41
kubectl delete ingress path-rewrite

3.4 实验3：HTTPS配置#

前提：使用实验1创建的nginx-service，如果已清理则需要重新创建

1
# 生成自签名证书
2
openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
3
  -keyout tls.key -out tls.crt \
4
  -subj "/CN=secure.example.com"
5

6
# 创建TLS Secret
7
kubectl create secret tls example-tls --cert=tls.crt --key=tls.key
8

9
# 创建HTTPS Ingress
10
cat > https-ingress.yaml <<EOF
11
apiVersion: networking.k8s.io/v1
12
kind: Ingress
13
metadata:
14
  name: https-ingress
15
  annotations:
16
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
17
spec:
18
  ingressClassName: nginx
19
  tls:
20
  - hosts:
21
    - secure.example.com
22
    secretName: example-tls
23
  rules:
24
  - host: secure.example.com
25
    http:
26
      paths:
27
      - path: /
28
        pathType: Prefix
29
        backend:
30
          service:
31
            name: nginx-service
32
            port:
33
              number: 80
34
EOF
35

36
kubectl apply -f https-ingress.yaml
37

38
# 配置hosts（测试机器）
39
echo "192.168.100.21 secure.example.com" >> /etc/hosts
40

41
# 测试
42
curl -k https://secure.example.com        # HTTPS访问
43
curl -I http://secure.example.com         # HTTP自动跳转
44

45
# 清理
46
kubectl delete ingress https-ingress
47
kubectl delete secret example-tls

3.5 实验4：金丝雀发布#

步骤1：创建v1版本Pod（3个副本，红色页面）：

1
cat > app-v1-pods.yaml <<EOF
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: app-v1-1
6
  labels:
7
    app: myapp
8
    version: v1
9
spec:
10
  containers:
11
  - name: app
12
    image: nginx:1.20
13
    command: ["/bin/sh", "-c"]
14
    args:
15
    - echo '<h1 style="color:red">Version 1</h1>' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'
16
    ports:
17
    - containerPort: 80
18
---
19
apiVersion: v1
20
kind: Pod
21
metadata:
22
  name: app-v1-2
23
  labels:
24
    app: myapp
25
    version: v1
26
spec:
27
  containers:
28
  - name: app
29
    image: nginx:1.20
30
    command: ["/bin/sh", "-c"]
31
    args:
32
    - echo '<h1 style="color:red">Version 1</h1>' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'
33
    ports:
34
    - containerPort: 80
35
---
36
apiVersion: v1
37
kind: Pod
38
metadata:
39
  name: app-v1-3
40
  labels:
41
    app: myapp
42
    version: v1
43
spec:
44
  containers:
45
  - name: app
46
    image: nginx:1.20
47
    command: ["/bin/sh", "-c"]
48
    args:
49
    - echo '<h1 style="color:red">Version 1</h1>' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'
50
    ports:
51
    - containerPort: 80
52
EOF
53

54
kubectl apply -f app-v1-pods.yaml
55

56
# 创建v1 Service
57
cat > app-v1-service.yaml <<EOF
58
apiVersion: v1
59
kind: Service
60
metadata:
61
  name: app-v1-service
62
spec:
63
  selector:
64
    app: myapp
65
    version: v1
66
  ports:
67
  - port: 80
68
EOF
69

70
kubectl apply -f app-v1-service.yaml

步骤2：创建v2版本Pod（3个副本，绿色页面）：

1
cat > app-v2-pods.yaml <<EOF
2
apiVersion: v1
3
kind: Pod
4
metadata:
5
  name: app-v2-1
6
  labels:
7
    app: myapp
8
    version: v2
9
spec:
10
  containers:
11
  - name: app
12
    image: nginx:1.20
13
    command: ["/bin/sh", "-c"]
14
    args:
15
    - echo '<h1 style="color:green">Version 2 - Canary</h1>' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'
16
    ports:
17
    - containerPort: 80
18
---
19
apiVersion: v1
20
kind: Pod
21
metadata:
22
  name: app-v2-2
23
  labels:
24
    app: myapp
25
    version: v2
26
spec:
27
  containers:
28
  - name: app
29
    image: nginx:1.20
30
    command: ["/bin/sh", "-c"]
31
    args:
32
    - echo '<h1 style="color:green">Version 2 - Canary</h1>' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'
33
    ports:
34
    - containerPort: 80
35
---
36
apiVersion: v1
37
kind: Pod
38
metadata:
39
  name: app-v2-3
40
  labels:
41
    app: myapp
42
    version: v2
43
spec:
44
  containers:
45
  - name: app
46
    image: nginx:1.20
47
    command: ["/bin/sh", "-c"]
48
    args:
49
    - echo '<h1 style="color:green">Version 2 - Canary</h1>' > /usr/share/nginx/html/index.html && nginx -g 'daemon off;'
50
    ports:
51
    - containerPort: 80
52
EOF
53

54
kubectl apply -f app-v2-pods.yaml
55

56
# 创建v2 Service
57
cat > app-v2-service.yaml <<EOF
58
apiVersion: v1
59
kind: Service
60
metadata:
61
  name: app-v2-service
62
spec:
63
  selector:
64
    app: myapp
65
    version: v2
66
  ports:
67
  - port: 80
68
EOF
69

70
kubectl apply -f app-v2-service.yaml
71

72
# 等待所有Pod就绪
73
kubectl get pods -l app=myapp

创建主Ingress和金丝雀Ingress：

1
# 主Ingress（v1）
2
cat > canary-main.yaml <<EOF
3
apiVersion: networking.k8s.io/v1
4
kind: Ingress
5
metadata:
6
  name: app-main
7
spec:
8
  ingressClassName: nginx
9
  rules:
10
  - host: app.example.com
11
    http:
12
      paths:
13
      - path: /
14
        pathType: Prefix
15
        backend:
16
          service:
17
            name: app-v1-service
18
            port:
19
              number: 80
20
EOF
21

22
# 金丝雀Ingress（v2，10%流量）
23
cat > canary-test.yaml <<EOF
24
apiVersion: networking.k8s.io/v1
25
kind: Ingress
26
metadata:
27
  name: app-canary
28
  annotations:
29
    nginx.ingress.kubernetes.io/canary: "true"
30
    nginx.ingress.kubernetes.io/canary-weight: "10"
31
spec:
32
  ingressClassName: nginx
33
  rules:
34
  - host: app.example.com
35
    http:
36
      paths:
37
      - path: /
38
        pathType: Prefix
39
        backend:
40
          service:
41
            name: app-v2-service
42
            port:
43
              number: 80
44
EOF
45

46
kubectl apply -f canary-main.yaml
47
kubectl apply -f canary-test.yaml
48

49
# 配置hosts（测试机器）
50
echo "192.168.100.21 app.example.com" >> /etc/hosts
51

52
# 测试流量分配（10%流向v2）
53
for i in {1..100}; do curl -s http://app.example.com | grep -o "Version [0-9]"; done | sort | uniq -c
54
# 输出：约90个Version 1，约10个Version 2
55

56
# 逐步增加权重（可选）
57
kubectl patch ingress app-canary -p '{"metadata":{"annotations":{"nginx.ingress.kubernetes.io/canary-weight":"30"}}}'
58
kubectl patch ingress app-canary -p '{"metadata":{"annotations":{"nginx.ingress.kubernetes.io/canary-weight":"50"}}}'
59

60
# 清理
61
kubectl delete ingress app-main app-canary
62
kubectl delete svc app-v1-service app-v2-service
63
kubectl delete pod app-v1-1 app-v1-2 app-v1-3 app-v2-1 app-v2-2 app-v2-3

前提：使用实验4创建的Pod和Service，如果已清理则需要重新创建

1
# 创建基于Header的金丝雀Ingress
2
cat > canary-header.yaml <<EOF
3
apiVersion: networking.k8s.io/v1
4
kind: Ingress
5
metadata:
6
  name: app-canary-header
7
  annotations:
8
    nginx.ingress.kubernetes.io/canary: "true"
9
    nginx.ingress.kubernetes.io/canary-by-header: "X-Canary"
10
    nginx.ingress.kubernetes.io/canary-by-header-value: "true"
11
spec:
12
  ingressClassName: nginx
13
  rules:
14
  - host: app.example.com
15
    http:
16
      paths:
17
      - path: /
18
        pathType: Prefix
19
        backend:
20
          service:
21
            name: app-v2-service
22
            port:
23
              number: 80
24
EOF
25

26
kubectl apply -f canary-header.yaml
27

28
# 测试
29
curl http://app.example.com                       # 普通用户 -> v1（红色）
30
curl -H "X-Canary: true" http://app.example.com   # 测试人员 -> v2（绿色）
31

32
# 清理
33
kubectl delete ingress app-canary-header

3.7 其他高级功能示例#

速率限制：

1
metadata:
2
  annotations:
3
    nginx.ingress.kubernetes.io/limit-rps: "5"

IP白名单：

1
metadata:
2
  annotations:
3
    nginx.ingress.kubernetes.io/whitelist-source-range: "192.168.100.0/24"

基本认证：

1
htpasswd -c auth admin
2
kubectl create secret generic basic-auth --from-file=auth

1
metadata:
2
  annotations:
3
    nginx.ingress.kubernetes.io/auth-type: basic
4
    nginx.ingress.kubernetes.io/auth-secret: basic-auth

3.8 常用管理命令#

1
# 查看Ingress
2
kubectl get ingress
3
kubectl describe ingress <name>
4

5
# 查看Ingress Controller日志
6
kubectl logs -n ingress-nginx <pod-name> -f
7

8
# 查看生成的Nginx配置
9
kubectl exec -n ingress-nginx <pod-name> -- cat /etc/nginx/nginx.conf
10

11
# 调试
12
curl -v -H "Host: example.com" http://192.168.100.21

4. 总结#

Ingress核心价值：

统一入口 - 一个IP服务多个应用，节省成本
7层路由 - 基于域名、路径、Header智能路由
SSL集中管理 - 统一证书配置，简化管理
企业级功能 - 金丝雀、A/B测试、限流、认证

生产环境建议：

1
✓ 裸金属：DaemonSet + hostNetwork + 外部LB
2
✓ 云平台：LoadBalancer + Deployment
3
✓ 配置资源限制和监控
4
✓ 使用cert-manager自动管理证书
5
✓ 配置备份和灾难恢复计划

Ingress vs Service对比：

特性	Service	Ingress
OSI层	4层	7层
路由	IP+端口	域名+路径
成本	每服务1个LB	多服务共享1个入口
功能	负载均衡	路由+SSL+金丝雀等
场景	内部通信	外部访问

Simple Blog

三、Service 详解#

1. Service是什么，为什么需要它#

1.1 回顾Pod的问题#

1.2 Service是什么#

1.3 为什么需要Service#

1.4 Service的工作原理#

1.5 Service与关联组件详解#

1.5.1 kube-proxy：Service的实现者#

1.5.2 CoreDNS：Service的服务发现#

1.6 Service如何关联到Pod：Label和Selector#

2. Service的类型详解#

2.1 ClusterIP：集群内部访问（默认类型）#

2.2 NodePort：通过节点端口暴露服务#

2.3 LoadBalancer：云平台负载均衡器#

2.4 ExternalName：DNS CNAME映射#

2.5 Headless Service：无头服务#

2.6 Service类型总结对比#

3. Service实战操作#

3.1 将kube-proxy切换到IPVS模式#

3.2 实验准备:改造nginx镜像支持通过Service名称访问数据库#

3.3 实验:使用Pod演示各类Service#

实验1 Service - 集群内部访问数据库#

实验2 Service - 通过Service名称访问数据库#

实验3 Service - 云平台负载均衡器#

实验4 Service - DNS直接解析到Pod IP#

3.4 Service实验总结与最佳实践#

4.总结#

四、Ingress：K8s的7层网关#

1. Ingress是什么？为什么需要它？#

1.1 Service暴露服务的局限性#

1.2 Ingress是什么？#

1.3 Ingress的组成部分#

1.4 Ingress工作原理#

1.5 Ingress与Service的关系#

1.6 Ingress vs Service对比#

1.7 Ingress的本质#

小结#

2. Ingress功能详解#

2.1 基础功能：基于域名的路由#

2.2 基于路径的路由#

2.3 HTTPS和SSL/TLS终止#

2.4 URL重写和重定向#

2.5 金丝雀发布（Canary Deployment）#

2.6 A/B测试#

2.7 其他高级功能#

2.8 Ingress Controller部署方式#

部署方式1：LoadBalancer + Deployment#

部署方式2：DaemonSet + hostNetwork#

部署方式3：NodePort + Deployment#

三种部署方式对比#

小结#

3. Ingress实战操作#

3.1 部署Nginx Ingress Controller（DaemonSet模式）#

3.2 实验1：基于域名路由#

3.3 实验2：基于路径路由 + URL重写#

3.4 实验3：HTTPS配置#

3.5 实验4：金丝雀发布#

3.6 实验5：基于Header的金丝雀（内部测试）#

3.7 其他高级功能示例#

3.8 常用管理命令#

4. 总结#