Kubernetes：從基礎到高級

Module 8: Helm, Operators & GitOps

xdev.asia

🎯 課程目標

了解為什麼需要 Service Mesh，比較 2026 年的 3 種熱門實作（Cilium Sidecarless、Istio Ambient、Linkerd），並了解何時針對特定用例選擇什麼。

1. 為什麼需要Service Mesh？

微服務帶來了許多挑戰：

• 傳輸層安全協定：加密服務之間的流量，驗證身份
• 交通管理：金絲雀、熔斷、重試、超時
• 可觀察性：分散式跟踪，每個服務到服務的指標
• 負載平衡：L7負載平衡比kube-proxy更智能

Service Mesh 在基礎設施層級實現了這些功能——應用程式程式碼不需要更改。

2. Sidecar 與 Sidecarless 架構

傳統 Service Mesh（Istio sidecar 模式）將 Envoy 代理程式註入到每個 Pod 中：

Pod: [app container] + [Envoy sidecar proxy]
# Tất cả traffic đi qua Envoy → overhead về latency và resource
# Overhead: ~50MB memory/pod + ~2ms latency thêm

Sidecarless 方法（Cilium、Istio Ambient）：位於 Pod 外部、節點層級或核心層級的代理程式。

3.Cilium服務網格——Sidecarless eBPF

Cilium 實作服務網格 在核心級別使用 eBPF — Pod 中不需要 sidecar 代理。

優點:

• 與 Istio sidecar 相比，網路開銷減少 40-60%
• 最低延遲（核心空間處理）
• 無需注入sidecar→更簡單，更容易升級
• 與 Cilium CNI 的本機整合（網路 + 策略 + 網格的一個堆疊）
• 哈伯：L7可觀測性已集成

缺點:

• 功能比完整的 Istio 少（無故障注入、進階流量管理）
• 請求 Cilium 作為 CNI

# Enable Cilium Service Mesh
helm upgrade cilium cilium/cilium \
  --namespace kube-system \
  --reuse-values \
  --set ingressController.enabled=true \
  --set ingressController.loadbalancerMode=shared
mTLS: enable mutual authentication
kubectl annotate namespace production 

"service.cilium.io/global=true"
Verify mTLS với Hubble
hubble observe --namespace production --protocol tcp --verdict FORWARDED

4. Istio 環境模式 — 穩定 Istio 1.24+

Istio Ambient 模式（從 Istio 1.24+ 開始穩定）是一種不使用 sidecar 的替代方案。

大樓:

• z隧道：每節點 L4 代理、mTLS 處理和所有工作負載的基本路由
• 航點代理：每個工作負載 L7 代理，可選 — 僅在需要 L7 功能時部署

Node:
├── ztunnel (L4: mTLS, basic routing) ← tất cả workloads đi qua
│
Namespace "production":
├── app-a pod       → cần mTLS? → ztunnel handles it
├── app-b pod       → cần canary L7? → ztunnel + waypoint proxy
└── waypoint proxy  → L7: HTTP routing, header manipulation, metrics

# Cài Istio Ambient
istioctl install --set profile=ambient
Enable ambient cho namespace
kubectl label namespace production istio.io/dataplane-mode=ambient
Deploy waypoint cho L7 features
istioctl waypoint apply --namespace production --enroll-namespace
Verify
istioctl experimental waypoint status -n production

Istio Ambient 的優勢：與 Sidecar 模式相比，資源減少約 40%。需要時提供完整的 Istio 功能（路點）。與 Istio 生態系統相容。

5. Linkerd — Rust 微代理

使用Linkerd linkederd2-代理 用 Rust 編寫——最小、最快的服務與 sidecar 結合。

• Sidecar 但非常輕：〜10MB 內存/代理（與 Envoy 〜50MB 相比）
• Rust：記憶體安全、零成本抽象、超快
• 自動 mTLS 無需配置
• HTTP/1.1、HTTP/2、gRPC 支持
• 簡單的重試與超時
• 服務設定檔：每條路由的指標和重試

# Cài Linkerd
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
linkerd install --crds | kubectl apply -f -
linkerd install | kubectl apply -f -
Inject sidecar
kubectl annotate namespace production linkerd.io/inject=enabled
Verify
linkerd check
linkerd viz install | kubectl apply -f -
linkerd viz dashboard   # mở browser

Linkerd vs Cilium vs Istio：當您想要最輕、最簡單的邊車模型時，Linkerd 適合您。

6. 比較服務網格 2026

Feature              Cilium Mesh    Istio Ambient    Linkerd
───────────────────────────────────────────────────────────────
Architecture         Sidecarless    Sidecarless*     Sidecar (Rust)
Memory overhead/pod  ~0             ~0**             ~10MB
mTLS                 ✅            ✅               ✅
L7 traffic mgmt      Limited        ✅ (waypoint)    Limited
Circuit breaking     ❌            ✅               ❌
Fault injection      ❌            ✅               ❌
Observability        ✅ (Hubble)   ✅               ✅
Gateway API          ✅ Native     ✅               ✅
Multi-cluster        Limited        ✅               ✅ (linkerd-multicluster)
Complexity           Low            Medium           Low
CNCF status          Graduated      Graduated        Graduated
Best for             Cilium clusters,  Enterprise,    Lightweight,
                     new clusters  full feature set  resource-constrained

Ambient không inject sidecar vào application pods
** ztunnel là shared per-node, không per-pod

7. 使用 Istio 進行流量管理

# VirtualService: canary deployment
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: my-app
  namespace: production
spec:
  hosts:
  - my-app
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: my-app
        subset: canary
  - route:
    - destination:
        host: my-app
        subset: stable
      weight: 90
    - destination:
        host: my-app
        subset: canary
      weight: 10
---
# DestinationRule: define subsets
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: my-app
spec:
  host: my-app
  trafficPolicy:
    connectionPool:
      http:
        http2MaxRequests: 1000
    outlierDetection:
      consecutive5xxErrors: 5       # circuit breaking
      interval: 30s
      baseEjectionTime: 30s
  subsets:
  - name: stable
    labels:
      version: stable
  - name: canary
    labels:
      version: canary

8.什麼時候選擇什麼？

• Cilium 服務網格：使用了 Cilium CNI，想要 sidecarless，優先性能，mTLS 和基本流量管理就足夠了
• Istio 環境模式：企業，需要完整的 Istio 功能（熔斷、故障注入、進階流量），已經具備 Istio 專業知識
• 林克德：想要 sidecar 模型，但最輕、最簡單、資源受限的集群
• 不要使用服務網格：叢集小，服務少，NetworkPolicy有足夠的隔離性

總結

• 服務網格：mTLS、流量管理、基礎設施層級的可觀察性
• Cilium Sidecarless：核心級 eBPF，開銷最低，適合已經使用 Cilium 的集群
• Istio Ambient：L4 ztunnel + 可選的 L7 路點，功能最齊全
• Linkerd：Rust 微代理，sidecar 模型中最輕的
• 2026年趨勢：sidecarless是必由之路，但Istio sidecar仍在企業中使用