Kubernetes Network Policy 与 Service Mesh 完全指南（Istio、Cilium、Calico 对比）

前言
Kubernetes Network Policy 基础
Network Policy 进阶：Egress、CIDR 与端口控制
Service Mesh 架构对比（Istio vs Cilium vs Calico）
- 架构选型标准
基于 Istio 构建 Service Mesh
基于 Cilium 的 eBPF Service Mesh
mTLS 与零信任网络
运维注意事项与排障
故障案例与恢复流程
性能基准与选型指南
结语
参考资料

Kubernetes Network Policy 与 Service Mesh 架构

前言

在 Kubernetes 集群中，Pod 之间的通信默认处于全部允许（allow-all）状态。也就是说，只要在同一个集群内，任何 Pod 都可以自由访问其他 Pod。在小规模的开发环境中这算不上什么问题，但如果是生产环境中运行着几十、几百个微服务的场景，这就会成为严重的安全威胁。

因为一旦攻击者攻陷了其中一个 Pod，就能在集群内向所有服务进行横向移动（lateral movement）。要防止这种情况，通过Network Policy实现网络分段，以及通过Service Mesh实现 mTLS 加密与零信任架构，都是必不可少的。

本文将从 Kubernetes Network Policy 的基础一直讲到进阶用法，并对比分析 Istio、Cilium、Calico 三种方案的 Service Mesh 架构。文中还包含实际运维中可能遇到的排障案例与性能基准测试，帮助你为自己的环境做出最合适的选择。

Kubernetes Network Policy 基础

什么是 Network Policy？

Network Policy 是 Kubernetes 原生资源，是在 Pod 层面控制入站（Ingress）与出站（Egress）流量的防火墙规则。它基于标签选择器工作，即使 Pod 重启或在节点之间迁移，也能应用一致的策略。

重要的前提条件：即使创建了 Network Policy 资源，如果没有实现它的 CNI 插件（Calico、Cilium、Antrea 等），策略也完全不会生效。默认的 kubenet 或 Flannel 并不支持 Network Policy。

Default Deny 策略

所有网络安全的起点都是Default Deny策略。先阻断全部流量，然后只显式放行必要的通信，采用白名单方式。

# default-deny-all.yaml
# 阻断命名空间内所有 Pod 的 Ingress/Egress 流量
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {} # 空选择器 = 命名空间内的所有 Pod
  policyTypes:
    - Ingress
    - Egress

这条策略生效后，production 命名空间中所有 Pod 的入站/出站流量都会被完全阻断。由于连 DNS 查询都无法进行，因此必须同时应用允许 DNS 的策略。

# allow-dns.yaml
# 允许访问 kube-dns(CoreDNS) 的策略
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53

放行 Pod 之间的特定通信

下面是在 Default Deny 状态下，允许前端访问后端 API 的示例。

# allow-frontend-to-backend.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

这条策略只允许带有 app: frontend 标签的 Pod 访问 app: backend-api Pod 的 TCP 8080 端口的入站流量。

Network Policy 进阶：Egress、CIDR 与端口控制

用 Egress 策略控制外部访问

当微服务需要访问外部 API 或数据库时，可以用 Egress 策略精细地限制放行对象。

# egress-external-api-and-db.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: backend-egress-policy
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
    - Egress
  egress:
    # 1. 允许访问同一命名空间的 Redis
    - to:
        - podSelector:
            matchLabels:
              app: redis
      ports:
        - protocol: TCP
          port: 6379
    # 2. 访问外部 PostgreSQL RDS（基于 CIDR）
    - to:
        - ipBlock:
            cidr: 10.100.0.0/16
      ports:
        - protocol: TCP
          port: 5432
    # 3. 允许访问外部 HTTPS API
    - to:
        - ipBlock:
            cidr: 0.0.0.0/0
            except:
              - 10.0.0.0/8
              - 172.16.0.0/12
              - 192.168.0.0/16
      ports:
        - protocol: TCP
          port: 443
    # 4. 允许 DNS
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53

控制命名空间之间的通信

在多租户环境中，命名空间之间的隔离是必需的。下面是只允许特定命名空间访问的模式。

# cross-namespace-policy.yaml
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-monitoring-access
  namespace: production
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
    - Ingress
  ingress:
    # 只允许 monitoring 命名空间的 Prometheus 抓取指标
    - from:
        - namespaceSelector:
            matchLabels:
              team: monitoring
          podSelector:
            matchLabels:
              app: prometheus
      ports:
        - protocol: TCP
          port: 9090

Network Policy 的局限

Kubernetes 内置的 Network Policy 只能做 L3/L4 层面（IP、端口、协议）的控制。以下需求靠内置的 Network Policy 无法满足：

基于 L7（HTTP 路径、方法、请求头）的过滤
mTLS 加密与服务身份认证
流量可观测性（Observability）与分布式追踪
高级流量管理（金丝雀发布、熔断、重试）
基于 FQDN（域名）的 Egress 控制

当需要这些高级能力时，Service Mesh 就登场了。

Service Mesh 架构对比（Istio vs Cilium vs Calico）

下面对三种主流方案的架构与功能进行对比。

项目	Istio（Ambient Mode）	Cilium Service Mesh	Calico（Enterprise）
数据平面	ztunnel(L4) + Waypoint Proxy(L7)	eBPF(L3/L4) + 每节点 Envoy(L7)	iptables/eBPF + Envoy(L7)
Sidecar	不需要（Ambient Mode）	不需要	可选
mTLS	自动（HBONE 协议）	WireGuard/IPsec	WireGuard 手动配置
L7 策略	AuthorizationPolicy	CiliumNetworkPolicy	GlobalNetworkPolicy
可观测性	Kiali、Jaeger、Prometheus	Hubble（内置）	Calico Enterprise UI
性能开销	中（经由 ztunnel）	低（内核层）	中
CPU 使用量	一般	少 30%（以 L4 为准）	一般
QPS 性能	高（低连接数时优秀）	高（高连接数时优秀）	一般
多集群	支持（East-West Gateway）	支持 Cluster Mesh	支持 Federation
学习曲线	高	中等	中等
社区	非常大（CNCF Graduated）	大（CNCF Graduated）	大（Tigera 主导）
Windows 节点	不支持	不支持	支持
最佳使用场景	大规模多集群、L7 精细控制	高性能 L4、基于 eBPF 的可观测	混合环境、企业合规要求

架构选型标准

只需要纯粹的 L3/L4 网络安全：Kubernetes 内置 Network Policy + Calico/Cilium CNI
L7 流量管理 + mTLS 是核心诉求：Istio Ambient Mode
高性能 + 内核层可观测性：Cilium Service Mesh
企业合规要求 + 混合环境：Calico Enterprise

基于 Istio 构建 Service Mesh

安装 Istio Ambient Mode

从 Istio 1.24 起，Ambient Mode 正式 GA。相比传统 Sidecar 方式，它把 CPU/内存开销降低了 90% 以上，同时依然提供 mTLS 与 L7 流量管理能力。

# 安装 istioctl
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.24.2 sh -
export PATH="$HOME/istio-1.24.2/bin:$PATH"

# 以 Ambient profile 安装
istioctl install --set profile=ambient --skip-confirmation

# 确认安装结果
kubectl get pods -n istio-system
# NAME                                   READY   STATUS    RESTARTS   AGE
# istiod-7b69f4b6c-xxxxx                 1/1     Running   0          60s
# ztunnel-xxxxx                          1/1     Running   0          60s
# istio-cni-node-xxxxx                   1/1     Running   0          60s

# 为命名空间启用 Ambient 模式
kubectl label namespace production istio.io/dataplane-mode=ambient

部署 Waypoint Proxy（用于 L7 策略）

如果只需要 L4 层面的 mTLS，仅靠 ztunnel 就足够了。若需要 L7 层面的精细流量控制，则要额外部署 Waypoint Proxy。

# 创建 Waypoint Proxy
istioctl waypoint apply --namespace production --name backend-waypoint

# 把 Waypoint 关联到指定 Service
kubectl label service backend-api \
  istio.io/use-waypoint=backend-waypoint \
  -n production

配置 Istio AuthorizationPolicy

Istio 的 L7 策略通过 AuthorizationPolicy 控制到 HTTP 方法、路径、请求头级别。

# istio-auth-policy.yaml
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: backend-api-policy
  namespace: production
spec:
  targetRefs:
    - kind: Service
      group: ''
      name: backend-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - 'cluster.local/ns/production/sa/frontend'
      to:
        - operation:
            methods: ['GET', 'POST']
            paths: ['/api/v1/*']
    - from:
        - source:
            principals:
              - 'cluster.local/ns/monitoring/sa/prometheus'
      to:
        - operation:
            methods: ['GET']
            paths: ['/metrics']

这条策略只允许 frontend 服务账号对 /api/v1/ 路径发起 GET、POST 请求，只允许 Prometheus 对 /metrics 路径发起 GET 请求。其余所有请求都会被以 403 Forbidden 拒绝。

基于 Cilium 的 eBPF Service Mesh

安装 Cilium 并启用 Service Mesh

Cilium 利用 eBPF 在内核层处理网络。它不需要 Sidecar 代理即可处理 L4 流量，只有在需要 L7 处理时才使用每个节点共享的 Envoy 代理。

# 安装 Cilium CLI
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
GOOS=$(go env GOOS)
GOARCH=$(go env GOARCH)
curl -L --fail --remote-name-all \
  "https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-${GOOS}-${GOARCH}.tar.gz"
sudo tar xzvfC "cilium-${GOOS}-${GOARCH}.tar.gz" /usr/local/bin

# 用 Helm 安装 Cilium（启用 Service Mesh + Hubble）
helm repo add cilium https://helm.cilium.io/
helm repo update

helm install cilium cilium/cilium --version 1.17.0 \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set envoy.enabled=true \
  --set encryption.enabled=true \
  --set encryption.type=wireguard

# 确认安装结果
cilium status --wait
cilium connectivity test

用 CiliumNetworkPolicy 应用 L7 策略

Cilium 通过自有 CRD CiliumNetworkPolicy，支持 HTTP、gRPC、Kafka 等 L7 协议级别的精细策略。

# cilium-l7-policy.yaml
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-l7-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: 'GET'
                path: '/api/v1/products'
              - method: 'POST'
                path: '/api/v1/orders'
              - method: 'GET'
                path: '/healthz'
    - fromEndpoints:
        - matchLabels:
            app: prometheus
      toPorts:
        - ports:
            - port: '9090'
              protocol: TCP
          rules:
            http:
              - method: 'GET'
                path: '/metrics'

用 Hubble 做网络观测

Cilium 的 Hubble 基于 eBPF，可以实时监控所有网络流量。

# 安装 Hubble CLI 后进行观测
hubble observe --namespace production --follow

# 只过滤特定 Pod 的流量
hubble observe --namespace production \
  --to-label app=backend-api \
  --verdict DROPPED

# 观测 HTTP 请求（L7）
hubble observe --namespace production \
  --protocol http \
  --http-status 5xx

# 网络流量可视化（Hubble UI）
cilium hubble port-forward &
# 在浏览器中访问 http://localhost:12000

Hubble 的输出示例：

TIMESTAMP             SOURCE                  DESTINATION             TYPE      VERDICT   SUMMARY
Mar 14 10:23:01.123   production/frontend     production/backend-api  L7/HTTP   FORWARDED GET /api/v1/products => 200
Mar 14 10:23:01.456   production/attacker     production/backend-api  L7/HTTP   DROPPED   POST /api/v1/admin => Policy denied
Mar 14 10:23:02.789   production/backend-api  production/redis        L4/TCP    FORWARDED TCP 6379

mTLS 与零信任网络

什么是零信任？

零信任（Zero Trust）是一种“不信任任何东西，验证所有东西”的安全模型。它要求集群内部通信也必须加密，并在所有服务间调用中验证身份。由于仅靠 Network Policy 无法加密流量，因此需要提供 mTLS（mutual TLS）的 Service Mesh。

Istio Ambient Mode 的 mTLS

Istio Ambient Mode 使用HBONE（HTTP-Based Overlay Network Environment）协议，把所有流量自动进行 mTLS 加密。ztunnel 在节点层面管理证书，并为每个 Pod 签发唯一的、基于 SPIFFE 的工作负载 ID。

# istio-peer-auth.yaml
# STRICT 模式：拒绝非 mTLS 的明文流量
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT

设置为 STRICT 模式后，该命名空间内的所有服务只接受 mTLS 连接。来自网格之外服务的明文请求会被全部拒绝。

Cilium 基于 WireGuard 的加密

Cilium 使用内核自带的 WireGuard 自动加密节点之间的流量。与 Istio 的 mTLS 不同，它工作在内核层而非应用层，因此性能开销更小。

# 确认 WireGuard 加密状态
cilium encrypt status

# 输出示例：
# Encryption:  Wireguard
# Keys in use: 2
# Errors:      0
# Interfaces:  cilium_wg0

# 查看加密密钥列表
cilium encrypt get

WireGuard 与 mTLS 的差异：

WireGuard：节点之间的 L3 层加密，内核层处理，不为每个 Pod 分配单独身份
mTLS（Istio）：服务之间的 L7 层加密，基于 SPIFFE 的工作负载 ID，可做精细的授权策略

在生产环境中，也有团队采用双重安全策略：先用 Cilium WireGuard 做节点间加密，再叠加 Istio mTLS 实现工作负载级别的身份认证。

运维注意事项与排障

1. 注意 Network Policy 的叠加方式

Network Policy 以并集（additive）方式工作。当多条策略作用于同一个 Pod 时，放行规则会被合并。存在冲突的策略时，并不是拒绝规则优先，而是只要有任意一条放行，流量就会通过。

# 确认作用于特定 Pod 的所有 Network Policy
kubectl get networkpolicy -n production -o wide

# 确认 Pod 标签（验证策略选择器是否匹配）
kubectl get pods -n production --show-labels

# 使用 Calico 时确认策略匹配情况
calicoctl get networkpolicy -n production -o yaml

2. 未安装 CNI 插件时 Network Policy 被忽略

这是最常见的失误。即使创建了 Network Policy 资源，只要没有实现它的 CNI 插件，策略就完全不会生效。

# 确认 CNI 插件
kubectl get pods -n kube-system | grep -E 'calico|cilium|antrea'

# 验证 Network Policy 是否真的生效的测试
# 1. 应用 Default Deny
kubectl apply -f default-deny-all.yaml

# 2. 通信测试（被阻断才是正常）
kubectl exec -n production deploy/frontend -- \
  curl -s --connect-timeout 3 http://backend-api:8080/healthz
# 出现超时就说明策略已经正确生效

3. DNS 解析失败

应用 Default Deny 策略后如果漏掉了 DNS 放行，所有服务发现都会中断。

# 诊断 DNS 问题
kubectl exec -n production deploy/frontend -- nslookup backend-api
# ;; connection timed out; no servers could be reached

# 确认 CoreDNS Pod
kubectl get pods -n kube-system -l k8s-app=kube-dns

# 应用 DNS 策略后重新测试
kubectl apply -f allow-dns.yaml
kubectl exec -n production deploy/frontend -- nslookup backend-api
# Server:    10.96.0.10
# Name:      backend-api.production.svc.cluster.local

4. 应对 Istio ztunnel 故障

ztunnel 以每节点 DaemonSet 的形式运行，一旦发生故障，该节点上所有 Ambient Mesh 流量都会中断。

# 确认 ztunnel 状态
kubectl get pods -n istio-system -l app=ztunnel

# 确认 ztunnel 日志（诊断证书问题）
kubectl logs -n istio-system -l app=ztunnel --tail=50

# 重启 ztunnel
kubectl rollout restart daemonset/ztunnel -n istio-system

# 确认与 Istiod 的 xDS 连接状态
istioctl proxy-status

5. Cilium eBPF map 容量超限

在大规模集群中，Cilium eBPF map 的默认大小可能不够用。

# 确认 eBPF map 使用量
cilium bpf ct list global | wc -l
cilium bpf policy get --all

# 增大 map 大小（修改 Helm values）
# bpf.ctGlobalTCPMax: 524288  （比默认值更大）
# bpf.ctGlobalAnyMax: 262144
# bpf.policyMapMax: 65536

# 应用变更
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set bpf.ctGlobalTCPMax=524288

故障案例与恢复流程

案例 1：错误的 Egress 策略导致全站服务中断

状况：运维团队为了加强安全应用了 Default Deny Egress，却漏掉了 DNS 放行策略，导致所有服务之间的通信中断。

症状：所有 Pod 通过服务名访问都失败。直接指定 IP 时则可以通信。

恢复流程：

# 1. 立即确认问题
kubectl get networkpolicy -n production

# 2. 紧急应用 DNS 放行策略
kubectl apply -f - <<'POLICY'
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: emergency-allow-dns
  namespace: production
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
      ports:
        - protocol: UDP
          port: 53
        - protocol: TCP
          port: 53
POLICY

# 3. 确认服务已恢复
kubectl exec -n production deploy/frontend -- nslookup backend-api

教训：Default Deny 策略必须与 DNS 放行策略一起应用。变更策略前一定要在预发环境测试，并准备好回滚方案。

案例 2：Istio 升级过程中的 mTLS 不匹配

状况：在 Istio 版本升级过程中，旧版本 Sidecar 与新版本 ztunnel 之间的 mTLS 握手失败。

症状：部分服务之间出现 503 错误以及“upstream connect error”消息。

恢复流程：

# 1. 把 mTLS 模式临时改为 PERMISSIVE（明文和 mTLS 都允许）
kubectl apply -f - <<'POLICY'
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: permissive-during-upgrade
  namespace: production
spec:
  mtls:
    mode: PERMISSIVE
POLICY

# 2. 重启所有工作负载以应用最新代理
kubectl rollout restart deployment -n production

# 3. 所有 Pod 都替换为新版本后恢复 STRICT
kubectl rollout status deployment -n production --timeout=300s
kubectl apply -f - <<'POLICY'
apiVersion: security.istio.io/v1
kind: PeerAuthentication
metadata:
  name: strict-mtls
  namespace: production
spec:
  mtls:
    mode: STRICT
POLICY

案例 3：Cilium Agent 重启导致瞬时流量丢弃

状况：在更新 Cilium DaemonSet 的过程中，节点上的 eBPF 程序被短暂卸载，导致该节点上 Pod 之间的通信中断了数秒。

恢复与预防：

# 采用 Rolling Update 策略逐个节点更新
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set upgradeCompatibility=1.16 \
  --set rollOutCiliumPods=true

# 确认 PodDisruptionBudget
kubectl get pdb -n kube-system

# 监控更新进度
kubectl rollout status daemonset/cilium -n kube-system --timeout=600s

性能基准与选型指南

实测基准结果（2025 年）

下面汇总近期在大规模企业环境中的对比测试结果。

指标	Network Policy Only	Istio Ambient	Cilium Service Mesh
P99 延迟（ms）	1.2	3.8	2.1
QPS（请求/秒）	45,000	38,000	42,000
QPS per Core	-	2,178	1,815
CPU 开销	基准	+15%	+8%
内存开销	基准	+120MB/节点	+80MB/节点
低连接数性能	-	优秀	一般
高连接数性能	-	一般	优秀

注意：Istio 的 QPS per Core 较高，是因为该数值包含了 L7 处理能力；而 Cilium 的 CPU 测量中未计入内核内 WireGuard 加密的开销，这一点需要纳入考量。

选型指南流程图

是否只需要 L3/L4 网络隔离？
- 是：Kubernetes Network Policy + Calico 或 Cilium CNI 就足够
- 否：进入第 2 步
是否需要 L7 流量管理（金丝雀、重试、熔断）？
- 是：Istio Ambient Mode 或 Cilium + Envoy
- 否：进入第 3 步
基于 mTLS 的零信任是否为硬性要求？
- 是：Istio Ambient Mode（基于 SPIFFE 的工作负载 ID）
- 否：用 Cilium WireGuard 做节点间加密
是否优先考虑高性能 + 内核层可观测性？
- 是：Cilium Service Mesh + Hubble
- 否：Istio（L7 功能更丰富）
是否混用 Windows 节点或属于混合环境？
- 是：Calico Enterprise
- 否：Istio 或 Cilium

按运维规模给出的建议

小规模集群（10 个节点以下）：Cilium CNI + 基础 Network Policy。引入 Service Mesh 的收益不足以抵消其开销。
中等规模集群（10~100 个节点）：Cilium Service Mesh 或 Istio Ambient，按 L7 需求来选。
大规模集群（100 个节点以上）：Istio Ambient Mode，多集群支持成熟、生态丰富、稳定性好。
混合云/多云：Calico Enterprise 或 Cilium Cluster Mesh。

结语

Kubernetes 网络安全不只是应用 Network Policy 那么简单，还需要一套契合应用特性与安全要求的整体策略。

核心要点：

Network Policy 是基础中的基础：请务必从 Default Deny 开始，采用只放行必要通信的白名单方式。不要忘记 DNS 放行策略。
Service Mesh 要在需要时才引入：请在确实需要 mTLS、L7 策略、高级流量管理的时点再引入。不必要的复杂度反而会加重运维负担。
Istio 与 Cilium 之间是权衡取舍：Istio 的 L7 功能与生态更丰富，Cilium 的强项是内核层性能与可观测性。请结合需求来选择。
循序渐进是关键：从 Default Deny 策略开始，充分验证 Network Policy 之后，再按需要追加 Service Mesh，这样的分阶段推进最为稳妥。
自动化与测试：策略变更一定要通过 CI/CD 流水线先在预发环境验证，并始终备好回滚方案。

网络安全不是设置一次就一劳永逸的事情。随着服务的演进，策略也需要持续复查和更新。建议每季度做一次策略审计，并利用 Hubble 或 Kiali 这类观测工具，基于真实流量模式来优化策略。