Cilium + Hubble 替换 Istio：服务网格的 eBPF 革命

Istio 很强大，但它的复杂性也是出了名的。每个 Pod 旁边都要注入一个 Envoy sidecar，资源开销不小，调试起来也很头疼。Cilium 用 eBPF 在内核层实现了同样的功能，不需要 sidecar。

为什么考虑替换 Istio

Istio 的主要痛点：

传统 Sidecar 模式：
  Pod A → Envoy Sidecar → 网络 → Envoy Sidecar → Pod B

每个请求经过 4 次用户态/内核态切换
每个 Pod 额外消耗 ~50MB 内存 + ~0.5 vCPU

在 1000 个 Pod 的集群中，Istio sidecar 本身就消耗了约 50GB 内存和 500 vCPU。

Cilium Service Mesh 的工作原理

eBPF 模式：
  Pod A → eBPF 程序（内核态）→ Pod B

请求在内核层直接处理，无需用户态代理
延迟降低 30-50%，资源消耗降低 80%+

Cilium 1.14+ 支持无 sidecar 的服务网格，通过 eBPF 实现：

  • mTLS 加密（基于 WireGuard 或 IPSec）
  • 流量管理（负载均衡、熔断）
  • 可观测性（通过 Hubble）
  • 网络策略

安装 Cilium（替换 kube-proxy）

# 使用 Helm 安装 Cilium，同时替换 kube-proxy
helm repo add cilium https://helm.cilium.io/

helm install cilium cilium/cilium \
  --namespace kube-system \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=<API_SERVER_IP> \
  --set k8sServicePort=6443 \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set encryption.enabled=true \
  --set encryption.type=wireguard

# 验证安装
cilium status --wait

启用服务网格功能

# 安装 Cilium CLI
CILIUM_CLI_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/cilium-cli/main/stable.txt)
curl -L --remote-name-all \
  https://github.com/cilium/cilium-cli/releases/download/${CILIUM_CLI_VERSION}/cilium-linux-amd64.tar.gz
tar xzf cilium-linux-amd64.tar.gz
mv cilium /usr/local/bin/

# 启用 Ingress Controller（替换 Istio Gateway）
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set ingressController.enabled=true \
  --set ingressController.loadbalancerMode=dedicated

Hubble：eBPF 驱动的可观测性

Hubble 是 Cilium 的可观测性组件，无需修改应用代码即可获得完整的网络流量视图：

# 安装 Hubble CLI
export HUBBLE_VERSION=$(curl -s https://raw.githubusercontent.com/cilium/hubble/master/stable.txt)
curl -L --remote-name-all \
  https://github.com/cilium/hubble/releases/download/$HUBBLE_VERSION/hubble-linux-amd64.tar.gz
tar xzf hubble-linux-amd64.tar.gz
mv hubble /usr/local/bin/

# 开启端口转发访问 Hubble
cilium hubble port-forward &

# 实时观察流量
hubble observe --namespace production --follow

# 查看服务间调用关系
hubble observe \
  --namespace production \
  --from-pod frontend \
  --to-pod backend \
  --protocol http

Hubble UI 提供可视化的服务依赖图：

# 访问 Hubble UI
cilium hubble ui
# 浏览器打开 http://localhost:12000

流量管理：CiliumEnvoyConfig

对于需要 L7 流量管理的场景，Cilium 支持通过 Envoy 配置实现（但不是 sidecar，而是节点级别的 Envoy）：

# 金丝雀发布：90% 流量到 v1，10% 到 v2
apiVersion: cilium.io/v2
kind: CiliumEnvoyConfig
metadata:
  name: canary-release
  namespace: production
spec:
  services:
  - name: api-service
    namespace: production
    listener: api-listener
  resources:
  - "@type": type.googleapis.com/envoy.config.listener.v3.Listener
    name: api-listener
    # ... Envoy 配置

更简单的方式是使用 Gateway API（Cilium 原生支持）：

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-canary
  namespace: production
spec:
  parentRefs:
  - name: cilium-gateway
  rules:
  - backendRefs:
    - name: api-v1
      port: 8080
      weight: 90
    - name: api-v2
      port: 8080
      weight: 10

网络策略：比 Istio 更强大

Cilium 的网络策略支持 L3/L4/L7，并且可以基于 DNS、FQDN 进行过滤：

# 只允许 frontend 访问 backend 的 /api 路径
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: backend-policy
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "^/api/.*"
        - method: "POST"
          path: "^/api/v1/.*"

---
# 限制外部访问：只允许访问特定域名
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: egress-policy
spec:
  endpointSelector:
    matchLabels:
      app: backend
  egress:
  - toFQDNs:
    - matchName: "api.github.com"
    - matchPattern: "*.amazonaws.com"
  - toEntities:
  - kube-apiserver

从 Istio 迁移的步骤

# 第一步：在现有集群安装 Cilium（与 Istio 共存）
# 先不替换 kube-proxy，逐步迁移

# 第二步：迁移网络策略
# Istio AuthorizationPolicy → CiliumNetworkPolicy
# 工具：istio2cilium（社区工具）
pip install istio2cilium
istio2cilium convert --input istio-policies/ --output cilium-policies/

# 第三步：迁移流量管理规则
# Istio VirtualService → Gateway API HTTPRoute
# Istio DestinationRule → CiliumEnvoyConfig

# 第四步：逐命名空间禁用 Istio sidecar 注入
kubectl label namespace production istio-injection=disabled

# 第五步：卸载 Istio
istioctl uninstall --purge

性能对比

在相同的测试场景（1000 RPS，P99 延迟）：

指标Istio (Envoy Sidecar)Cilium (eBPF)
P99 延迟~8ms~3ms
内存/Pod~50MB~0MB（无 sidecar）
CPU 开销~0.5 vCPU/Pod节点级别共享
启动时间+3-5s（sidecar 注入）无额外开销

什么时候还是选 Istio

Cilium 不是银弹，以下场景 Istio 仍有优势：

  • 需要复杂的 L7 流量管理（Retry、Timeout、Circuit Breaker 细粒度配置）
  • 已有大量 Istio 配置，迁移成本高
  • 需要跨集群服务网格（Istio 的多集群支持更成熟）
  • 团队对 Istio 已经很熟悉

对于新建集群，Cilium 是更好的起点：更简单、更高效、更易维护。

← 返回文章列表