← 返回文章列表
云原生网络核心概念指南：gRPC、Istio、CNI、Gateway API 全解
从序列化和反序列化讲起，深入理解 gRPC、CNI、Overlay 网络、Istio 服务网格、Gateway API 和 Istio API，帮你建立云原生网络知识体系
17 分钟阅读
字号
云原生网络核心概念指南
本文系统梳理云原生网络核心概念，从序列化和反序列化讲起，逐步深入 gRPC、CNI、Overlay、Istio、Gateway API 等关键技术，帮你建立完整的云原生网络知识体系。
一、序列化和反序列化
1.1 什么是序列化？
序列化：把内存中的对象"拍扁"成字节序列，便于存储或网络传输
反序列化：把字节序列"还原"成内存中的对象
类比：
序列化 = 搬家时把家具拆解、打包成箱子
反序列化 = 到新家把箱子拆开、把家具重新组装好1.2 为什么需要序列化？
| 场景 | 说明 |
|---|---|
| 网络传输 | 对象无法直接在网络中发送，必须转成字节 |
| 持久化存储 | 数据写入文件/数据库需要字节形式 |
| 跨进程通信 | 不同进程间传递对象必须序列化 |
1.3 常见序列化格式
JSON（文本格式，可读）
{"name": "Alice", "age": 25}优点：人类可读、跨语言友好；缺点：体积大、解析慢
Protocol Buffers（二进制）
0x0a 0x05 0x41 0x6c 0x69 0x63 0x65 0x10 0x19优点：体积小、速度快、类型安全；缺点：二进制不可读
1.4 序列化核心过程
内存中的对象
┌─────────────────┐
│ User对象 │
│ ├─ Name: "Alice"│
│ └─ Age: 25 │
└─────────────────┘
│
▼ 序列化 (Marshal)
┌─────────────────┐
│ []byte字节数组 │
│ [65 108 105...] │
└─────────────────┘
│
▼ 传输/存储
┌─────────────────┐
│ []byte字节数组 │
│ [65 108 105...] │
└─────────────────┘
│
▼ 反序列化 (Unmarshal)
┌─────────────────┐
│ User对象 │
│ ├─ Name: "Alice"│
│ └─ Age: 25 │
└─────────────────┘二、gRPC 详解
2.1 一句话概括
gRPC（Google Remote Procedure Call）是 Google 开源的高性能 RPC 框架，基于 HTTP/2 协议设计，主要用于服务间通信。
RPC（远程过程调用）让你像调用本地函数一样调用远程服务：
本地调用 远程调用
┌─────────────┐ ┌─────────────┐
│ Client │ │ Server │
│ │ │ │
│ 调用sayHi()│ ─────网络─────> │ 执行sayHi()│
│ 等待返回值 │ <────结果────── │ 返回结果 │
└─────────────┘ └─────────────┘2.2 为什么 gRPC 效率高？
Protocol Buffers vs JSON
JSON格式：
{"name": "Alice", "age": 25, "city": "Beijing"}
Protocol Buffers编码后（二进制）：
0x0a 0x05 0x41 0x6c 0x69 0x63 0x65 0x10 0x19 0x1a 0x07 0x42 0x65 0x69 0x6a 0x69 0x6e 0x67| 指标 | JSON | Protobuf |
|---|---|---|
| 序列化速度 | 较慢 | 快3-10倍 |
| 数据体积 | 大 | 小2-10倍 |
| 类型安全 | 弱 | 强 |
HTTP/2 多路复用
HTTP/1.1：必须等前一个响应返回才能发下一个请求（队头阻塞）
HTTP/2：
请求1 ────> 响应1 ────>
请求2 ────> 响应2 ────>
请求3 ────> 响应3 ────>
同一个TCP连接并行传输2.3 四种通信模式
简单 RPC（一元 RPC）
Client ──────> Server
<────── 响应服务端流式 RPC
Client ──────> Server
<──── 响应1
<──── 响应2
<──── 响应3客户端流式 RPC
Client ──────> 请求1
──────> 请求2
──────> 请求3
<────── 响应双向流式 RPC
Client <─────> Server
──────> 请求1 响应1 <─────
──────> 请求2 响应2 <─────2.4 .proto 文件示例
syntax = "proto3";
message UserRequest {
string name = 1;
int32 age = 2;
}
message UserResponse {
string message = 1;
bool success = 2;
}
service UserService {
rpc GetUser(UserRequest) returns (UserResponse);
rpc StreamUsers(stream UserRequest) returns (stream UserResponse);
}2.5 gRPC vs REST
| 特性 | gRPC | REST |
|---|---|---|
| 协议 | HTTP/2 | HTTP/1.1 |
| 数据格式 | Protocol Buffers | JSON |
| 传输效率 | 高 | 中 |
| 代码生成 | 原生支持 | 需Swagger |
| 浏览器支持 | 需grpc-web | 原生支持 |
| 流式通信 | 原生支持 | 需轮询/SSE |
三、CNI 详解
3.1 一句话概括
CNI（Container Network Interface）是 Kubernetes 中用于配置容器网络的标准接口规范。
3.2 为什么需要 CNI？
Pod 创建时需要网络通信，但容器的网络栈是独立的。CNI 就是解决这个问题的标准：Kubelet 通过 CNI 让网络插件来配置容器网络。
┌─────────────────────────────────────┐
│ Node（宿主机） │
│ ┌─────────────────────────────────┐│
│ │ Pod ││
│ │ ┌───────────────────────────┐ ││
│ │ │ Container │ ││
│ │ │ 网络命名空间独立 │ ││
│ │ └───────────────────────────┘ ││
│ └─────────────────────────────────┘│
└─────────────────────────────────────┘3.3 CNI 工作流程
Pod创建时：
1. Kubelet 等待容器网络命名空间创建完成
│
▼
2. Kubelet 调用 CNI 插件（通过 stdin 传递配置）
│
▼
3. CNI 插件执行网络配置：
├── 创建 veth pair（虚拟网线）
├── 分配 IP 地址
├── 设置路由
└── 配置 iptables 规则
│
▼
4. 返回配置结果给 Kubelet3.4 常见 CNI 插件
| 插件 | 特点 |
|---|---|
| bridge | 简单网桥，最基础 |
| Flannel | 简单 Overlay 网络 |
| Calico | 基于 BGP，功能够强，支持网络策略 |
| Cilium | 基于 eBPF，支持透明加密，L7 策略 |
| Weave Net | 自动发现，加密通信 |
3.5 CNI 配置文件示例
{
"cniVersion": "0.3.1",
"name": "mynet",
"type": "bridge",
"bridge": "cni0",
"isDefaultGateway": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/16",
"routes": [
{ "dst": "0.0.0.0/0" }
]
}
}四、Overlay 网络
4.1 一句话概括
Overlay 网络是在现有底层网络（Underlay）之上构建的虚拟网络。
┌─────────────────────────────────────────────────────┐
│ Overlay（虚拟网络） │
│ │
│ ┌─────────┐ ┌─────────┐ │
│ │ Pod A │◄───────►│ Pod B │ │
│ │ 10.0.0.2│ │ 10.0.0.3│ │
│ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────┘
│
│ 封装/解封装
▼
┌─────────────────────────────────────────────────────┐
│ Underlay（物理网络） │
│ Node 1 (192.168.1.10) ◄──────► Node 2 (192.168.1.20) │
└─────────────────────────────────────────────────────┘4.2 为什么需要 Overlay？
物理路由器不认识 Pod 的 IP（10.244.x.x），所以需要 Overlay 把 Pod IP 封装在物理网络可识别的 IP 包中传输。
4.3 VxLAN 封装原理
发送过程（封装）：
┌─────────────────────┐
│ 原始包 │
│ SRC: 10.0.0.2 │
│ DST: 10.244.1.2 │
└──────────┬──────────┘
▼ 封装
┌─────────────────────────┐
│ 外层头： │
│ SRC: 192.168.1.10 │ ← Node1 IP
│ DST: 192.168.1.20 │ ← Node2 IP
├─────────────────────────┤
│ 内层头（原始包）： │
│ SRC: 10.0.0.2 │
│ DST: 10.244.1.2 │
└─────────────────────────┘4.4 Overlay vs Underlay
| 维度 | Overlay | Underlay |
|---|---|---|
| 定义 | 虚拟网络 | 物理网络 |
| 依赖 | 基于底层网络 | 物理设备和布线 |
| 灵活性 | 高，可随意定义 | 低，需物理配置 |
| 性能 | 有开销（封装/解封装） | 无额外开销 |
| 举例 | VxLAN, Flannel | 物理交换机、路由器 |
4.5 Overlay 的优缺点
优点：
✓ 灵活性高：Pod IP 可随意定义，不受物理网络限制
✓ 隔离性好：不同集群/租户的网络可重叠
✓ 快速部署：新增节点无需修改物理网络配置
缺点：
✗ 性能开销：封装/解封装消耗 CPU
✗ 网络复杂度：调试困难（不可见底层）
✗ MTU 问题：额外头部可能导致分包五、Istio 详解
5.1 一句话概括
Istio 是一个开源的服务网格（Service Mesh）平台，用于连接、保护、控制和监控微服务。
5.2 为什么需要 Istio？
微服务架构中，每个服务都要自己实现连接、监控、安全等功能 → 代码耦合、重复劳动。
解决：把这些共性问题下沉到基础设施层 → Service Mesh
┌─────────────────────────────────────────────────┐
│ Service Mesh（服务网格） │
│ │
│ 服务间通信全部通过代理 │
│ 通信 + 安全 + 监控 + 控制 全部由网格管理 │
└─────────────────────────────────────────────────┘5.3 Istio 架构
┌──────────────────────────────────────────────────────┐
│ Control Plane │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ Pilot │ │ Citadel │ │ Galley │ │
│ │ (配置管理) │ │ (安全/证书) │ │ (配置验证) │ │
│ └────────────┘ └────────────┘ └────────────┘ │
└──────────────────────────────────────────────────────┘
│
▼ 配置下发
┌──────────────────────────────────────────────────────┐
│ Data Plane │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Pod A │ │ Pod B │ │ Pod C │ │
│ │┌───────┐│ │┌───────┐│ │┌───────┐│ │
│ ││Envoy ││ ││Envoy ││ ││Envoy ││ │
│ ││Sidecar││ ││Sidecar││ ││Sidecar││ │
│ │└───────┘│ │└───────┘│ │└───────┘│ │
│ └─────────┘ └─────────┘ └─────────┘ │
└──────────────────────────────────────────────────────┘5.4 核心组件
| 组件 | 作用 |
|---|---|
| Envoy | 轻量级代理，每个 Pod 边车运行，处理流量 |
| Pilot | 负责流量管理规则下发 |
| Citadel | 自动化证书颁发与管理（mTLS 加密） |
| Galley | 配置验证和分发 |
5.5 核心功能
流量管理：动态路由、负载均衡、熔断、重试、超时、流量镜像
安全：mTLS 双向认证、授权策略
可观测性：自动收集指标、日志、链路追踪
混沌工程：故障注入、熔断测试
六、Istio 部署模式
6.1 两种部署模式对比
| 维度 | Ambient Mode | Sidecar Mode |
|---|---|---|
| 成熟度 | 新（2023 GA） | 成熟 |
| 资源占用 | 低（节点共享） | 高（每 Pod 共占） |
| 侵入性 | 低（无需注入） | 高（需修改 Pod） |
| 升级影响 | 无（节点级） | 有（Pod 需重启） |
| 功能完整性 | 正在完善 | 完整 |
6.2 Ambient Mode 架构
┌─────────────────────────────────────────────────────┐
│ Node │
│ ┌──────────────────────────────────────────────┐ │
│ │ Istio Node Agent │ │
│ │ ┌────────────┐ ┌────────────────────┐ │ │
│ │ │ ztunnel │ │ waypoint-proxy │ │ │
│ │ │ (L4透明) │ │ (L7应用感知) │ │ │
│ │ └────────────┘ └────────────────────┘ │ │
│ └──────────────────────────────────────────────┘ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ Pod A │ │ Pod B │ │ Pod C │ │
│ │ 无Sidecar│ │ 无Sidecar│ │ 无Sidecar│ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────┘6.3 Sidecar Mode 架构
┌─────────────────────────────────────────────────────┐
│ Node │
│ ┌──────────────────────────────────────────────┐ │
│ │ Pod │ │
│ │ ┌─────────┐ ┌─────────────────────┐ │ │
│ │ │ App │ │ Envoy Sidecar │ │ │
│ │ │ │◄──────►│ (拦截所有流量) │ │ │
│ │ └─────────┘ └─────────────────────┘ │ │
│ └──────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘6.4 推荐选择
生产环境选择：
├── 新项目 / 追求简单
│ └── Ambient Mode（未来趋势）
│
├── 成熟项目 / 需要稳定
│ └── Sidecar Mode（当前主流）
│
└── 大规模集群 / 资源敏感
└── Ambient Mode（资源优势明显）七、Kubernetes Gateway API
7.1 一句话概括
Gateway API 是 Kubernetes 官方推荐的下一代 Ingress 标准，提供更强大的路由、安全和伸缩能力。
7.2 Ingress 的问题
Ingress 能力有限：各家厂商自己定义，用注解扩展，混乱不统一。想换 Ingress 实现？重写所有配置。
7.3 核心概念
Gateway API 有 4 个核心资源：
GatewayClass → 网关实现（如 Istio、Contour）
Gateway → 网关实例（监听端口、TLS 证书）
HTTPRoute → HTTP 路由规则
Service → 后端服务7.4 关系图
┌─────────────────────────────────────────────────────────────┐
│ GatewayClass │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Gateway │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ HTTPRoute A │ │ HTTPRoute B │ │ TLSRoute │ │ │
│ │ │ /api │ │ /web │ │ 443端口 │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │
│ └─────────┼────────────────┼────────────────┼───────────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Service A│ │Service B│ │Service C│ │
│ └─────────┘ └─────────┘ └─────────┘ │
└─────────────────────────────────────────────────────────────┘7.5 Gateway API vs Ingress
| 维度 | Ingress | Gateway API |
|---|---|---|
| 标准化程度 | 部分标准化 | 完全标准化 |
| 路由能力 | 基础 | 丰富（header/query/权重） |
| 流量分割 | 需注解 | 原生支持 |
| 角色分离 | 无 | 清晰分离 |
| 跨命名空间 | 不支持 | 支持 |
7.6 示例：HTTPRoute 路由规则
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
name: my-route
spec:
parentRefs:
- name: my-gateway
namespace: istio-system
hostnames:
- "app.example.com"
rules:
- matches:
- path:
type: PathPrefix
value: /api
- headers: # 按 header 路由
values:
version: v2
backendRefs:
- name: api-service
port: 8080
weight: 90
- name: api-service-v2
port: 8080
weight: 10 # 10% 流量到 v2八、Istio API
8.1 Istio API 是什么？
Istio 定义了一套自己的资源类型（CRD），用于配置服务网格：
Gateway API = Kubernetes 官方标准（通用）
Istio API = Istio 自己定义的 API（功能更丰富）
├── VirtualService → 路由规则
├── DestinationRule → 目标规则（负载均衡、熔断）
├── ServiceEntry → 外部服务注册
├── Gateway → Istio 版网关
└── AuthorizationPolicy → 授权策略8.2 核心资源
VirtualService（路由规则）
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: reviews
spec:
hosts:
- reviews
http:
- match:
- headers:
cookie:
regex: "^(.*?;)?(user=jason)(;.*)?$"
route:
- destination:
host: reviews
subset: v2
- route:
- destination:
host: reviews
subset: v1DestinationRule（目标规则）
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: reviews
spec:
host: reviews
trafficPolicy:
loadBalancer:
simple: ROUND_ROBIN
connectionPool:
tcp:
maxConnections: 100
outlierDetection:
consecutiveGatewayErrors: 5
interval: 30s
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v28.3 完整示例：配合使用
# 1. 网关：对外暴露
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: my-gateway
spec:
selector:
istio: ingressgateway
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*.example.com"
---
# 2. 目标规则：定义版本
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
name: my-app
spec:
host: my-app
subsets:
- name: v1
labels:
version: v1
- name: v2
labels:
version: v2
---
# 3. 路由规则：5% 流量到新版本
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: my-app
spec:
hosts:
- app.example.com
gateways:
- my-gateway
http:
- route:
- destination:
host: my-app
subset: v1
weight: 95
- destination:
host: my-app
subset: v2
weight: 58.4 Istio API vs Gateway API
| 功能 | Istio API | Gateway API |
|---|---|---|
| 路由 | VirtualService | HTTPRoute |
| 目标规则 | DestinationRule | 无 |
| 网关 | Gateway（Istio版） | Gateway（K8s标准） |
| 服务注册 | ServiceEntry | 无 |
| 成熟度 | 非常成熟 | 成熟（GA） |
| 厂商支持 | 仅 Istio | 多实现可替换 |
九、总结
知识图谱
┌─────────────────────────────────────────────────────────────────┐
│ 云原生网络知识体系 │
│ │
│ ┌───────────────┐ │
│ │ 序列化 │ ← 数据传输的基础 │
│ └───────┬───────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ gRPC │ ← 高性能 RPC 通信 │
│ └───────┬───────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ CNI │ ← 容器网络接口标准 │
│ └───────┬───────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Overlay │ ← 虚拟网络（VxLAN） │
│ └───────┬───────┘ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Istio │ ← 服务网格 │
│ └───────┬───────┘ │
│ ▼ │
│ ┌───────────────┐ ┌───────────────┐ │
│ │ Gateway API │ │ Istio API │ │
│ │ (K8s 标准) │ │ (Istio 专用) │ │
│ └───────────────┘ └───────────────┘ │
└─────────────────────────────────────────────────────────────────┘核心要点
1. 序列化 = 把对象转字节，传输后再转回来
2. gRPC = RPC + Protobuf + HTTP/2，高性能服务间通信
3. CNI = 容器网络接口标准，让 Pod 能联网
4. Overlay = 在物理网络上构建虚拟网络（VxLAN）
5. Istio = 服务网格，统一处理微服务横切关注点
6. Ambient Mode = Istio 未来方向，无 Sidecar
7. Gateway API = K8s 官方 Ingress 标准
8. Istio API = Istio 自己的配置格式，功能更丰富参考资料
分享