642 lines
19 KiB
Markdown
642 lines
19 KiB
Markdown
---
|
||
tags: [k8s, service, networking, devops]
|
||
create time: 2026-07-07 15:48
|
||
---
|
||
|
||
# Kubernetes Service 与网络
|
||
|
||
## 概述
|
||
|
||
Kubernetes 中 Pod 的生命周期是短暂的——它们随时可能被销毁重建，每次重建都会获得新的 IP 地址。如果服务之间直接通过 Pod IP 通信，任何一次 Pod 重启都会导致调用方断连。**Service** 正是为了解决这个问题而生：它为一组动态变化的 Pod 提供一个稳定的访问入口（虚拟 IP），配合 DNS 和负载均衡，让服务发现变得透明且可靠。
|
||
|
||
## K8s 网络模型
|
||
|
||
Kubernetes 对集群网络有三个核心要求，任何 CNI（Container Network Interface）插件都必须满足：
|
||
|
||
| 原则 | 说明 |
|
||
|------|------|
|
||
| **Pod-to-Pod** | 集群内任意两个 Pod 可以直接通过 IP 通信，无需 NAT |
|
||
| **Pod-to-Service** | Pod 通过 Service 的虚拟 IP（ClusterIP）访问后端 Pod，由 kube-proxy 实现负载均衡 |
|
||
| **External-to-Service** | 集群外部流量可以通过 NodePort、LoadBalancer 或 Ingress 进入集群 |
|
||
|
||
### CNI 插件简介
|
||
|
||
CNI 插件负责为 Pod 分配 IP 地址并配置网络连通性。常见实现：
|
||
|
||
- **Calico**：基于 BGP 路由，支持 NetworkPolicy，性能优秀
|
||
- **Flannel**：简单轻量，使用 VXLAN overlay，适合小规模集群
|
||
- **Cilium**：基于 eBPF，高性能，支持 L7 网络策略
|
||
- **Weave Net**：自带加密，配置简单
|
||
|
||
> [!tip] 如何选择
|
||
> 小规模或学习环境用 Flannel 足够；生产环境推荐 Calico 或 Cilium，它们对 NetworkPolicy 的支持更完善。
|
||
|
||
## Service 详解
|
||
|
||
### ClusterIP
|
||
|
||
**默认类型**，为 Service 分配一个集群内部虚拟 IP，仅集群内可访问。
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Service
|
||
metadata:
|
||
name: my-app-svc
|
||
namespace: default
|
||
spec:
|
||
type: ClusterIP # 默认值，可省略
|
||
selector:
|
||
app: my-app
|
||
ports:
|
||
- protocol: TCP
|
||
port: 80 # Service 端口
|
||
targetPort: 8080 # Pod 端口
|
||
```
|
||
|
||
流量路径：`Client Pod → ClusterIP（虚拟 IP）→ kube-proxy → 后端 Pod:8080`
|
||
|
||
ClusterIP 是一个"虚拟 IP"——它不存在于任何网卡上，只存在于 iptables/IPVS 规则中。
|
||
|
||
### NodePort
|
||
|
||
在 ClusterIP 的基础上，在**每个节点**上开一个端口（默认范围 30000-32767），外部流量可通过 `<NodeIP>:<NodePort>` 访问。
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Service
|
||
metadata:
|
||
name: my-app-nodeport
|
||
spec:
|
||
type: NodePort
|
||
selector:
|
||
app: my-app
|
||
ports:
|
||
- protocol: TCP
|
||
port: 80 # Service 端口（集群内部访问）
|
||
targetPort: 8080 # Pod 端口
|
||
nodePort: 30080 # 节点端口（可选，不指定则自动分配）
|
||
```
|
||
|
||
> [!info] iptables 规则链路
|
||
> 当外部请求到达 `<NodeIP>:30080` 时，kube-proxy 在每个节点上创建的 iptables 规则会将流量 DNAT 到后端 Pod 的 IP:Port。这意味着即使请求落在没有运行目标 Pod 的节点上，流量也会被正确转发。
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[External Client] -->|NodeIP:30080| B[Node]
|
||
B -->|iptables DNAT| C[Pod on Node A]
|
||
B -->|iptables DNAT| D[Pod on Node B]
|
||
B -->|iptables DNAT| E[Pod on Node C]
|
||
```
|
||
|
||
### LoadBalancer
|
||
|
||
在 NodePort 的基础上，向云厂商申请一个外部负载均衡器（如 AWS ELB、GCP CLB），自动将外部流量分发到各节点的 NodePort。
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Service
|
||
metadata:
|
||
name: my-app-lb
|
||
annotations:
|
||
# 云厂商特定注解，例如 AWS：
|
||
service.beta.kubernetes.io/aws-load-balancer-type: nlb
|
||
spec:
|
||
type: LoadBalancer
|
||
selector:
|
||
app: my-app
|
||
ports:
|
||
- protocol: TCP
|
||
port: 80
|
||
targetPort: 8080
|
||
```
|
||
|
||
> [!warning] 继承关系
|
||
> `LoadBalancer` = `ClusterIP` + `NodePort` + 云厂商 LB。如果没有云厂商支持（如裸金属环境），LoadBalancer 类型的 Service 会一直停留在 `<pending>` 状态。此时可以考虑 MetalLB 作为替代方案。
|
||
|
||
### ExternalName
|
||
|
||
将 Service 映射到一个外部 DNS 名称（CNAME 记录），不涉及任何代理和负载均衡。
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Service
|
||
metadata:
|
||
name: external-db
|
||
namespace: default
|
||
spec:
|
||
type: ExternalName
|
||
externalName: db.example.com # 映射到外部域名
|
||
```
|
||
|
||
**适用场景**：
|
||
- 集群内应用需要访问外部数据库或 API
|
||
- 跨命名空间/跨集群服务映射
|
||
- 迁移过程中临时将内部 Service 指向外部服务
|
||
|
||
当 Pod 查询 `external-db.default.svc.cluster.local` 时，CoreDNS 会返回 `db.example.com` 的 CNAME 记录，Pod 再对 `db.example.com` 发起真正的 DNS 查询。
|
||
|
||
### Service 类型对比
|
||
|
||
| 类型 | ClusterIP | NodePort | LoadBalancer | ExternalName |
|
||
|------|-----------|----------|--------------|--------------|
|
||
| **默认** | 是 | 否 | 否 | 否 |
|
||
| **集群内访问** | 支持 | 支持 | 支持 | 通过 CNAME |
|
||
| **集群外访问** | 不支持 | 支持（NodeIP:Port） | 支持（外部 IP） | 不适用 |
|
||
| **端口范围** | 任意 | 30000-32767 | 任意（LB 端口） | 无端口 |
|
||
| **典型场景** | 内部微服务互调 | 开发测试暴露 | 生产环境对外服务 | 访问外部服务 |
|
||
| **云厂商依赖** | 无 | 无 | 需要 | 无 |
|
||
|
||
## Endpoints 与 EndpointSlices
|
||
|
||
### Endpoints
|
||
|
||
每个 Service 背后都有一个同名的 **Endpoints** 对象，记录了当前所有健康 Pod 的 IP:Port 列表。当 Pod 就绪（Readiness Probe 通过）时自动加入，Pod 删除时自动移除。
|
||
|
||
```bash
|
||
# 查看 Service 对应的 Endpoints
|
||
kubectl get endpoints my-app-svc
|
||
# NAME ENDPOINTS AGE
|
||
# my-app-svc 10.244.1.5:8080,10.244.2.8:8080 5m
|
||
```
|
||
|
||
### EndpointSlices
|
||
|
||
Kubernetes 1.21 引入 EndpointSlices 作为 Endpoints 的替代方案。
|
||
|
||
> [!info] 为什么需要 EndpointSlices？
|
||
> 在大规模集群中，一个 Service 可能关联成百上千个 Pod。Endpoints 对象会将所有 Pod IP 存储在单个对象中，导致：
|
||
> 1. **更新风暴**：任何一个 Pod 变化都要更新整个 Endpoints 对象
|
||
> 2. **内存压力**：kube-proxy 和所有节点的 kubelet 都要 watch 这个大对象
|
||
> 3. **API Server 压力**：每次更新都要全量推送
|
||
>
|
||
> EndpointSlices 将后端列表拆分成多个小切片（默认每个切片最多 100 个端点），增量更新，大幅降低开销。
|
||
|
||
```bash
|
||
# 查看 EndpointSlices
|
||
kubectl get endpointslices -l kubernetes.io/service-name=my-app-svc
|
||
```
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph Endpoints 旧方式
|
||
S1[Service] --> E1[Endpoints<br/>全部 Pod IP 在一个对象中]
|
||
end
|
||
subgraph EndpointSlices 新方式
|
||
S2[Service] --> ES1[EndpointSlice-0<br/>Pod 1-100]
|
||
S2 --> ES2[EndpointSlice-1<br/>Pod 101-200]
|
||
S2 --> ES3[EndpointSlice-2<br/>Pod 201-300]
|
||
end
|
||
```
|
||
|
||
## DNS 解析机制
|
||
|
||
### CoreDNS
|
||
|
||
Kubernetes 使用 **CoreDNS** 作为集群内置 DNS 服务（1.12 之前使用 kube-dns）。每个 Service 创建后，CoreDNS 会自动为其注册 DNS 记录。
|
||
|
||
### Service DNS 格式
|
||
|
||
| 资源类型 | DNS 格式 | 示例 |
|
||
|----------|----------|------|
|
||
| 普通 Service | `<svc>.<ns>.svc.cluster.local` | `my-app.default.svc.cluster.local` |
|
||
| Headless Service | `<svc>.<ns>.svc.cluster.local` → 解析到所有 Pod IP | 直接返回 Pod IP 列表 |
|
||
| Pod | `<pod-ip-dash>.<ns>.pod.cluster.local` | `10-244-1-5.default.pod.cluster.local` |
|
||
|
||
> [!tip] 同命名空间内可以省略后缀
|
||
> 在 `default` 命名空间内的 Pod 访问同命名空间的 Service，可以直接用 `my-app-svc`，无需写全限定域名。
|
||
|
||
### Headless Service
|
||
|
||
当 Service 的 `clusterIP` 设置为 `None` 时，它成为一个 **Headless Service**。此时 DNS 查询不会返回一个虚拟 IP，而是直接返回所有后端 Pod 的 IP 列表。
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Service
|
||
metadata:
|
||
name: my-app-headless
|
||
spec:
|
||
clusterIP: None # Headless
|
||
selector:
|
||
app: my-app
|
||
ports:
|
||
- port: 80
|
||
targetPort: 8080
|
||
```
|
||
|
||
**典型应用场景**：
|
||
- **StatefulSet**：有状态应用（如数据库集群）需要知道每个 Pod 的独立地址
|
||
- **自定义负载均衡**：客户端自己实现负载均衡逻辑
|
||
- **服务发现**：客户端需要获取所有后端地址
|
||
|
||
```bash
|
||
# 查询 Headless Service 的 DNS
|
||
nslookup my-app-headless.default.svc.cluster.local
|
||
# Name: my-app-headless.default.svc.cluster.local
|
||
# Address: 10.244.1.5
|
||
# Address: 10.244.2.8
|
||
# Address: 10.244.3.12
|
||
```
|
||
|
||
## kube-proxy 深入
|
||
|
||
kube-proxy 是运行在每个节点上的网络代理，负责实现 Service 的负载均衡。它有三种工作模式：
|
||
|
||
### iptables 模式（默认）
|
||
|
||
kube-proxy 监听 Service 和 Endpoints 的变化，在每个节点上维护 iptables 规则链。
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
A[请求到达 ClusterIP] --> B[KUBE-SERVICES 链]
|
||
B --> C{匹配 Service?}
|
||
C -->|是| D[KUBE-SVC-XXX 链]
|
||
D --> E[概率匹配 -m statistic --mode random]
|
||
E -->|概率 50%| F[KUBE-SEP-AAA 链 → Pod A]
|
||
E -->|概率 50%| G[KUBE-SEP-BBB 链 → Pod B]
|
||
C -->|否| H[REJECT]
|
||
```
|
||
|
||
**规则链路详解**：
|
||
1. `KUBE-SERVICES`：总入口，匹配目标 IP:Port 确定 Service
|
||
2. `KUBE-SVC-XXX`：Service 级别链，使用 `statistic` 模块做随机负载均衡
|
||
3. `KUBE-SEP-XXX`：Endpoint 级别链，执行 DNAT 将目标地址转换为 Pod IP:Port
|
||
|
||
> [!warning] iptables 模式的局限
|
||
> - 规则数量与 Service × Pod 数量成正比，大规模集群下规则链很长
|
||
> - 线性遍历匹配，时间复杂度 O(n)
|
||
> - 不支持连接追踪以外的负载均衡算法
|
||
|
||
### IPVS 模式
|
||
|
||
IPVS（IP Virtual Server）是 Linux 内核中的四层负载均衡器，性能远优于 iptables。
|
||
|
||
```yaml
|
||
# kube-proxy 配置启用 IPVS
|
||
apiVersion: kubeproxy.config.k8s.io/v1alpha1
|
||
kind: KubeProxyConfiguration
|
||
mode: "ipvs"
|
||
ipvs:
|
||
scheduler: "rr" # 负载均衡算法：rr / lc / sh / sed / nq
|
||
```
|
||
|
||
**支持的负载均衡算法**：
|
||
|
||
| 算法 | 全称 | 说明 |
|
||
|------|------|------|
|
||
| `rr` | Round Robin | 轮询（默认） |
|
||
| `lc` | Least Connections | 最少连接数 |
|
||
| `sh` | Source Hashing | 源地址哈希（会话保持） |
|
||
| `sed` | Shortest Expected Delay | 最短预期延迟 |
|
||
| `nq` | Never Queue | 永不排队 |
|
||
|
||
### iptables vs IPVS 对比
|
||
|
||
| 维度 | iptables | IPVS |
|
||
|------|----------|------|
|
||
| **性能** | 规则多时下降明显 | 哈希表查找，O(1) |
|
||
| **最大 Service 数** | 约 5000 开始明显退化 | 可支撑数万 |
|
||
| **负载均衡算法** | 仅随机 | rr / lc / sh / sed / nq |
|
||
| **连接保持** | 有限支持 | 原生支持 |
|
||
| **依赖** | iptables（用户态工具） | ipvs 内核模块 |
|
||
| **调试** | `iptables -L -n -t nat` | `ipvsadm -Ln` |
|
||
|
||
> [!tip] 生产建议
|
||
> 节点 Service 数超过 1000 时，强烈建议切换到 IPVS 模式。
|
||
|
||
## Ingress 基础
|
||
|
||
Service（NodePort/LoadBalancer）工作在四层（TCP/UDP），而 **Ingress** 工作在七层（HTTP/HTTPS），提供基于域名和路径的路由能力。
|
||
|
||
### Ingress Controller
|
||
|
||
Ingress 资源本身只是一份声明式配置，真正执行路由逻辑的是 **Ingress Controller**。常见的 Ingress Controller：
|
||
|
||
- **Nginx Ingress Controller**：最广泛使用，社区版 + F5 版
|
||
- **Traefik**：自动服务发现，配置简单
|
||
- **HAProxy**：高性能，企业级特性丰富
|
||
- **Istio Gateway**：Service Mesh 生态中的网关
|
||
|
||
### Path-based 路由
|
||
|
||
```yaml
|
||
apiVersion: networking.k8s.io/v1
|
||
kind: Ingress
|
||
metadata:
|
||
name: path-based-ingress
|
||
annotations:
|
||
nginx.ingress.kubernetes.io/rewrite-target: /
|
||
spec:
|
||
ingressClassName: nginx
|
||
rules:
|
||
- host: app.example.com
|
||
http:
|
||
paths:
|
||
- path: /api
|
||
pathType: Prefix
|
||
backend:
|
||
service:
|
||
name: api-svc
|
||
port:
|
||
number: 80
|
||
- path: /web
|
||
pathType: Prefix
|
||
backend:
|
||
service:
|
||
name: web-svc
|
||
port:
|
||
number: 80
|
||
```
|
||
|
||
### Host-based 路由
|
||
|
||
```yaml
|
||
apiVersion: networking.k8s.io/v1
|
||
kind: Ingress
|
||
metadata:
|
||
name: host-based-ingress
|
||
spec:
|
||
ingressClassName: nginx
|
||
rules:
|
||
- host: api.example.com
|
||
http:
|
||
paths:
|
||
- path: /
|
||
pathType: Prefix
|
||
backend:
|
||
service:
|
||
name: api-svc
|
||
port:
|
||
number: 80
|
||
- host: web.example.com
|
||
http:
|
||
paths:
|
||
- path: /
|
||
pathType: Prefix
|
||
backend:
|
||
service:
|
||
name: web-svc
|
||
port:
|
||
number: 80
|
||
```
|
||
|
||
### TLS 终止
|
||
|
||
```yaml
|
||
apiVersion: networking.k8s.io/v1
|
||
kind: Ingress
|
||
metadata:
|
||
name: tls-ingress
|
||
annotations:
|
||
nginx.ingress.kubernetes.io/ssl-redirect: "true"
|
||
spec:
|
||
ingressClassName: nginx
|
||
tls:
|
||
- hosts:
|
||
- app.example.com
|
||
secretName: app-tls-secret # 存放证书的 Secret
|
||
rules:
|
||
- host: app.example.com
|
||
http:
|
||
paths:
|
||
- path: /
|
||
pathType: Prefix
|
||
backend:
|
||
service:
|
||
name: my-app-svc
|
||
port:
|
||
number: 80
|
||
```
|
||
|
||
证书需要提前创建为 Kubernetes Secret：
|
||
|
||
```bash
|
||
kubectl create secret tls app-tls-secret \
|
||
--cert=tls.crt \
|
||
--key=tls.key
|
||
```
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[Client] -->|HTTPS| B[Ingress Controller<br/>TLS 终止]
|
||
B -->|HTTP| C[Service: my-app-svc]
|
||
C --> D[Pod A]
|
||
C --> E[Pod B]
|
||
```
|
||
|
||
## NetworkPolicy
|
||
|
||
默认情况下，Kubernetes 集群中所有 Pod 之间可以互相通信。**NetworkPolicy** 允许你定义精细的网络访问控制规则。
|
||
|
||
> [!warning] 前提条件
|
||
> NetworkPolicy 需要 CNI 插件支持。Flannel 不支持 NetworkPolicy，Calico 和 Cilium 支持。
|
||
|
||
### 默认全通策略
|
||
|
||
如果不创建任何 NetworkPolicy，所有流量都是放行的：
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
A[Pod A] -->|允许| B[Pod B]
|
||
B -->|允许| A
|
||
A -->|允许| C[Pod C]
|
||
C -->|允许| B
|
||
```
|
||
|
||
### 限制 Pod 间通信
|
||
|
||
**示例：只允许前端 Pod 访问后端 Pod 的 8080 端口**
|
||
|
||
```yaml
|
||
apiVersion: networking.k8s.io/v1
|
||
kind: NetworkPolicy
|
||
metadata:
|
||
name: backend-policy
|
||
namespace: default
|
||
spec:
|
||
podSelector:
|
||
matchLabels:
|
||
app: backend # 策略作用于 backend Pod
|
||
policyTypes:
|
||
- Ingress
|
||
ingress:
|
||
- from:
|
||
- podSelector:
|
||
matchLabels:
|
||
app: frontend # 只允许来自 frontend Pod
|
||
ports:
|
||
- protocol: TCP
|
||
port: 8080 # 只允许访问 8080 端口
|
||
```
|
||
|
||
**示例：限制出站流量，只允许访问指定 DNS**
|
||
|
||
```yaml
|
||
apiVersion: networking.k8s.io/v1
|
||
kind: NetworkPolicy
|
||
metadata:
|
||
name: restrict-egress
|
||
namespace: default
|
||
spec:
|
||
podSelector:
|
||
matchLabels:
|
||
app: my-app
|
||
policyTypes:
|
||
- Egress
|
||
egress:
|
||
- to:
|
||
- namespaceSelector:
|
||
matchLabels:
|
||
name: kube-system # 允许访问 kube-system 命名空间
|
||
ports:
|
||
- protocol: UDP
|
||
port: 53 # 允许 DNS 查询
|
||
- to:
|
||
- ipBlock:
|
||
cidr: 10.0.0.0/8 # 允许访问内网
|
||
ports:
|
||
- protocol: TCP
|
||
port: 443
|
||
```
|
||
|
||
> [!info] 策略叠加规则
|
||
> - 一旦某个 Pod 被任何 NetworkPolicy 选中，未被策略明确允许的流量将被**拒绝**
|
||
> - 多个 NetworkPolicy 取**并集**（任一策略允许即放行）
|
||
> - 只定义 `policyTypes: [Ingress]` 不影响出站，反之亦然
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph 策略生效后
|
||
A[frontend Pod] -->|允许: TCP 8080| B[backend Pod]
|
||
C[other Pod] -->|拒绝| B
|
||
B -->|未定义 Egress 策略<br/>默认放行| D[任意目标]
|
||
end
|
||
```
|
||
|
||
## 常见陷阱与最佳实践
|
||
|
||
### Service 无法访问排查清单
|
||
|
||
当 Service 访问不通时，按以下顺序排查：
|
||
|
||
1. **确认 Pod 运行正常**
|
||
```bash
|
||
kubectl get pods -l app=my-app -o wide
|
||
kubectl logs <pod-name>
|
||
kubectl describe pod <pod-name>
|
||
```
|
||
|
||
2. **确认 Endpoints 已注册**
|
||
```bash
|
||
kubectl get endpoints my-app-svc
|
||
# 如果 ENDPOINTS 为 <none>，说明没有健康的 Pod 匹配 selector
|
||
```
|
||
|
||
3. **确认 selector 匹配**
|
||
```bash
|
||
# 对比 Service selector 和 Pod labels
|
||
kubectl get svc my-app-svc -o jsonpath='{.spec.selector}'
|
||
kubectl get pods --show-labels
|
||
```
|
||
|
||
4. **确认端口正确**
|
||
```bash
|
||
# 检查 targetPort 是否与 Pod 实际监听端口一致
|
||
kubectl get svc my-app-svc -o yaml | grep -A5 ports
|
||
kubectl exec <pod-name> -- ss -tlnp
|
||
```
|
||
|
||
5. **确认 DNS 解析**
|
||
```bash
|
||
kubectl run test --rm -it --image=busybox -- nslookup my-app-svc
|
||
```
|
||
|
||
6. **确认网络策略未阻断**
|
||
```bash
|
||
kubectl get networkpolicy -n <namespace>
|
||
```
|
||
|
||
7. **确认 kube-proxy 正常**
|
||
```bash
|
||
kubectl get pods -n kube-system -l k8s-app=kube-proxy
|
||
# 检查 iptables 规则是否存在
|
||
iptables -t nat -L KUBE-SERVICES | grep my-app-svc
|
||
```
|
||
|
||
### Session Affinity
|
||
|
||
默认情况下 Service 使用轮询负载均衡。如果需要会话保持（同一客户端始终访问同一 Pod），可以启用 Session Affinity：
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Service
|
||
metadata:
|
||
name: sticky-svc
|
||
spec:
|
||
selector:
|
||
app: my-app
|
||
sessionAffinity: ClientIP # 基于客户端 IP 保持会话
|
||
sessionAffinityConfig:
|
||
clientIP:
|
||
timeoutSeconds: 1800 # 会话超时时间（默认 10800 秒）
|
||
ports:
|
||
- port: 80
|
||
targetPort: 8080
|
||
```
|
||
|
||
> [!warning] Session Affinity 注意事项
|
||
> - 在 iptables 模式下，基于源 IP 的会话保持可能在 NAT 环境下失效
|
||
> - IPVS 模式支持更精细的会话保持（`sh` 算法）
|
||
> - 对于 HTTP 应用，更推荐使用 Cookie-based Affinity（在 Ingress 层实现）
|
||
|
||
### External Traffic Policy
|
||
|
||
控制外部流量如何路由到 Pod，只对 NodePort 和 LoadBalancer 类型 Service 生效：
|
||
|
||
```yaml
|
||
apiVersion: v1
|
||
kind: Service
|
||
metadata:
|
||
name: my-app-svc
|
||
spec:
|
||
type: LoadBalancer
|
||
externalTrafficPolicy: Local # 或 Cluster（默认）
|
||
selector:
|
||
app: my-app
|
||
ports:
|
||
- port: 80
|
||
targetPort: 8080
|
||
```
|
||
|
||
| 策略 | 行为 | 优点 | 缺点 |
|
||
|------|------|------|------|
|
||
| **Cluster（默认）** | 流量可能被转发到其他节点上的 Pod | 负载均衡更均匀 | 多一跳转发，丢失源 IP |
|
||
| **Local** | 流量只转发到本节点上的 Pod | 保留源 IP，减少转发延迟 | Pod 分布不均时负载不均衡 |
|
||
|
||
```mermaid
|
||
flowchart TB
|
||
subgraph "externalTrafficPolicy: Cluster"
|
||
A1[Client] -->|请求| B1[Node 1]
|
||
B1 -->|可能转发| C1[Node 2 的 Pod]
|
||
B1 -->|本地| D1[Node 1 的 Pod]
|
||
end
|
||
subgraph "externalTrafficPolicy: Local"
|
||
A2[Client] -->|请求| B2[Node 1]
|
||
B2 -->|仅本地| D2[Node 1 的 Pod]
|
||
B2 -.->|不转发| C2[Node 2 的 Pod]
|
||
end
|
||
```
|
||
|
||
### 其他最佳实践
|
||
|
||
- **使用命名空间隔离 Service**：避免命名冲突，便于权限管理
|
||
- **合理设置 readinessProbe**：Pod 未就绪时不会被加入 Endpoints，避免流量打到未准备好的实例
|
||
- **避免使用 ExternalName 映射到集群内部 Service**：可能导致 DNS 解析循环
|
||
- **大规模集群启用 EndpointSlices**：减少 API Server 和 kube-proxy 的压力
|
||
- **生产环境使用 IPVS 模式**：在 Service 数量较多时性能显著优于 iptables
|
||
- **为关键 Service 配置 PodDisruptionBudget**：确保滚动更新和节点维护时服务可用性
|
||
|
||
## 延伸阅读
|
||
|
||
- [[k8s-01-overview]] — Kubernetes 基础概念总览
|
||
- [[k8s-04-deployment-and-replicaset]] — Deployment 与 ReplicaSet 详解
|