← 回到筆記2025-05-18

What is service mesh

說明沒有 Service Mesh 時服務間存取控制的做法與限制、Service Mesh 的功能，以及 Istio 的四種 multi-cluster 架構。

發佈 ~6 分鐘 #K8s#networking

沒有使用 Service Mesh 時會遇到的問題

🧱 如果沒有使用 Service Mesh，服務之間的連線限制會怎麼做？

在傳統 Kubernetes 或 VM 架構中，控制誰可以連誰通常會透過以下方式：

  1. Kubernetes NetworkPolicy（L3/L4）

    • 可以寫 YAML 規則來控制 Pod 的入站/出站規則，例如：
      • 限制 namespace A 的 Pod 只能連到 namespace B 的某些服務
      • 限制某些 label 的 Pod 不可互相通訊
    kind: NetworkPolicy
spec:
  podSelector:
    matchLabels:
      app: frontend
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              team: backend

    📉 限制點：

    • 只能做到 L3/L4 層，無法針對「HTTP path」、「JWT 身份」這類高階條件做控制
    • 可觀測性與 debug 不容易（無 log、無 metrics）
    • 實務上很容易寫錯（或被忽略，導致預設全開）

  2. 應用程式內寫邏輯（例如用 Auth middleware）

    • 某些團隊會在程式碼中判斷 caller 的 IP、token、Header、X-Forwarded-For 等方式，決定是否接受連線

    📉 限制點：

    • 各語言框架實作不一致（Go/Node/Java 各自寫一套）
    • 需要開發者「主動意識到這件事」，實務上容易遺漏
    • 難以集中管理政策，更別說 audit 與 compliance

  3. API Gateway + IAM（僅限入站流量）

    • 在進入 cluster 前透過 API Gateway + RBAC 做驗證授權（常見於外部客戶端）

    📉 限制點：

    • 僅處理對外流量，對內部 microservice-to-microservice 無能為力

🔐 Service Mesh 如何改善這一切？

  1. 提供 mTLS + SPIFFE Identity

    • 每個服務都有獨立身份證（如 spiffe://cluster.local/ns/dev/sa/frontend）
    • Service Mesh 能根據這個身份，像 IAM 一樣制定訪問政策

  2. 使用高階策略語言（如 Istio 的 AuthorizationPolicy）

    apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
spec:
  selector:
    matchLabels:
      app: payment
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/default/sa/frontend"]

    代表：只有 frontend 這個 ServiceAccount 可以呼叫 payment service，其餘全部拒絕。

  3. 全部集中式管理、版本控制、可視覺化

    • 實作 declarative、版本化（GitOps）
    • 配合 Kiali、OPA、Audit logs，強化可觀測與合規需求
    • 可與 Prometheus 結合監控

🧠 為什麼「難以維護」？

問題原始作法為何難以維護
權限設定分散App 內部寫死、K8s NetworkPolicy、IAM 混用開發者需記得、維運者難以總覽
錯誤難以 debug沒有 log/tracing找不到哪裡擋住請求
設定錯誤易造成資安漏洞預設全開（K8s 預設允許所有連線）無預警被攻擊（橫向移動）
難以跨團隊標準化每個語言每個團隊搞一套測試困難、難以導入 SRE review

Service Mesh 的功能

  1. 通訊安全：mTLS（Mutual TLS）
    • 🔒 為服務之間的通訊自動加密，並驗證彼此身份（雙向憑證驗證）。
    • ✅ 自動化程度高：大多數 mesh 實作會自動為每個 service 配發憑證。
    • ✅ 無需改程式碼，開啟 mTLS 即生效。
    • 額外定義規則：可以開啟全域 mTLS，或細部定義（例如某 namespace 必須用 mTLS）
      • 選擇性設定，非必要也可全自動化。
  2. 細部流量治理（L7 Routing）
    • 🎯 允許你針對 header、path、流量百分比等條件，決定流量去向。
    • 用於：
      • Canary rollout（新版本灰度部署）
      • A/B Testing
      • 基於 tenant 做路由（multi-tenancy）
    • 額外定義規則：routing 規則（如 Istio 的 VirtualService 與 DestinationRule）是 Service Mesh 最核心的治理功能之一。
  3. 故障處理（Resilience）
    • 🔁 Retry / Timeout
    • 🔌 Circuit Breaker（防止下游服務崩潰傳染）
    • 🧪 Fault Injection（模擬錯誤）
    • 額外定義規則：例如設定重試次數、超時時間。
      • 好處是所有語言都統一在 sidecar 設定中，不需每個開發者個別實作。
  4. 可觀測性（Observability）
    • 📈 Metrics：請求次數、錯誤率、延遲（例如 Prometheus + Grafana）
    • 🔍 Distributed Tracing：完整的跨服務請求路徑（如 Jaeger）
    • 🧠 Topology Map：像 Kiali 顯示誰呼叫誰
    • 幾乎不需額外設定規則。只要安裝完成並抓 metrics/tracing endpoint 就有資料。
  5. 存取控制（Zero Trust / Policy Control）
    • 🛡️ 例如「A 只能呼叫 B」、「只能 GET /api/user」、「只有特定 JWT 才能呼叫」
    • 基於身份（SPIFFE ID）、JWT Claims、IP、ServiceAccount 等做授權
    • 額外定義規則：如 AuthorizationPolicy
      • 類似防火牆 + RBAC 的概念
      • 常用語言：Istio 的 AuthorizationPolicy、Cilium 的 CiliumNetworkPolicy
  6. In-Cluster Gateway / API Gateway 整合
    • 🌐 作為叢集對外的流量入口（Ingress Gateway）
    • 搭配流量分流、認證、速率限制等功能
    • 額外定義規則：
      • 需撰寫 Gateway 配置（如 Istio 的 Gateway + VirtualService）
      • 可與 cert-manager 整合 TLS、與外部身份系統整合 OAuth2/JWT
  7. 多叢集 / 多網域支援（Advanced）
    • 跨 cluster service discovery
    • 跨 region/zone 負載分攤
    • 多租戶隔離（multi-tenancy）
    • 額外定義規則：中高階功能，需要配合 DNS、CA、Mesh Expansion 等設定。
🔧 補充：Service Mesh 的「規則」本質是什麼？

這些「規則」通常是以 **Kubernetes CRDs（CustomResourceDefinitions）**的形式存在，例如：

# 定義某服務的 HTTP routing 規則
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews-route
spec:
  hosts:
    - reviews
  http:
    - match:
        - headers:
            user:
              exact: "tester"
      route:
        - destination:
            host: reviews-v2
    - route:
        - destination:
            host: reviews-v1

或：

# 限制某些服務只能被特定身份呼叫
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: reviews-authz
spec:
  selector:
    matchLabels:
      app: reviews
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/default/sa/frontend"]

🧠 總結：哪些需要你寫規則，哪些是開箱即用？

功能預設自動化需要定義規則
mTLS 加密✅❌（可選細節定義）
Metrics / Tracing✅❌（整合即可）
Routing（A/B/Canary）❌✅
Retry / Timeout❌✅
訪問控制❌✅
Ingress Gateway❌✅
多叢集功能❌✅

Istio on Multi-Clusters

四種 Multi-Cluster 架構模式

⚠️ 建議可以用 ArgoCD ApplicationSet 對多個 Cluster 同時部署

  1. Multi-Primary（多主控／多控制面）
    • 特點：每個 Kubernetes cluster 都部署自己獨立的 Istio 控制面（istiod），並共用同一組根 CA 與 trust bundle，使各 cluster 之間能互相信任。
    • 網路要求：所有 cluster 必須位於同一網路（pod 網路可直接互通），或透過 east-west gateway 建立平坦網路。
    • 優點：
      • 高可用：若某一 cluster 的控制面故障，不影響其他 cluster。
      • 自治性強：各 cluster 可依需求調整各自控制面。
    • 缺點：多套控制面需要額外資源，設定較複雜。istio.io
  2. Primary-Remote（主從控制面）
    • 特點：在一個 “Primary” cluster 部署完整的 Istio 控制面，其它 “Remote” cluster 只安裝 data plane（Envoy sidecar 與 Istio CNI），並通過 remote secret 與 Primary cluster 的控制面溝通。
    • 網路要求：Primary 與 Remote 必須在同一網路內可直通，或透過 Gateway 配置 east-west 流量。
    • 優點：
      • 簡化管理：只需維護一套控制面。
      • 資源節省：Remote cluster 不需跑 istiod。
    • 缺點：Primary 成為單點故障；Remote cluster 對 Primary network 可達性有依賴。istio.io
  3. Multi-Primary on Different Networks（跨網路多主控）
    • 特點：延伸「Multi-Primary」模式至跨網路情境。
    • 實作：
      1. 為每個 cluster 部署 istiod。
      2. 在各 cluster 部署 east-west gateway，並配置跨網路路由與 TLS。
      3. 共享 CA 與 ServiceEntry 讓服務能跨網路發現。
    • 適用場景：各 cluster 位於不同 VPC、不同雲區域，需透過防火牆或 VPN 互連。
    • 重點差異：比單一網路多主控多了 Gateway 與額外網路設定。istio.io
  4. Primary-Remote on Different Networks（跨網路主從控制面）
    • 特點：結合「Primary-Remote」＋「不同網路」兩者：
      • Primary cluster 跑控制面與 east-west gateway。
      • Remote cluster 跑 Envoy sidecar + east-west gateway。
    • 網路配置：需要在 Primary 與 Remote 間開通 gateway 端口、設定負載平衡／DNS。
    • 優點 & 缺點：同 Primary-Remote，但多了跨網路的複雜度與 Gateway 管理。istio.io
模式控制面部署網路要求典型場景
1. Multi-Primary（多主控）每個 cluster 各有一套 istiod同一平坦網路，或透過 east-west gateway需要高可用、自治升級
2. Primary-Remote（主從控制面）只有 1 套 Primary istiod，Remote 只裝 data plane同一平坦網路，或 gateway 直通想簡化控制面管理、節省資源
3. Multi-Primary (Multi-Network)每個 cluster 各有一套 istiod跨 VPC/區域 ，須配置 east-west gateways跨雲、跨 region，多網路環境下要維持自治與互通
4. Primary-Remote (Multi-Network)1 套 Primary istiod + 各 Remote 的 data plane跨網路時需 gateway + 負載平衡／DNS結合資源節省與跨網路佈署，仍承受 Primary 單點依賴

為何需要 Multi-Primary 架構？

  1. 高可用性、故障隔離：每個 cluster 自治運行自己的 istiod，某 cluster 控制面故障不影響整體 mesh。
  2. 分階段升級、自治性強：可針對單一 cluster 滾動重啟或升級，不用同時停擺所有 cluster。
  3. 低延遲的跨 cluster 呼叫：Pod-to-Pod 直通；不必經過 gateway 再回到 Primary，延遲更低、流量路徑更簡潔。
  4. 網路拓撲彈性：不論在同網路或跨 VPC，只要配置 east-west gateways，即可讓各 cluster 互信並發現服務。
  5. 真正的跨 cluster 服務發現與路由：本地 istiod 同步遠端 endpoints，開發者不需修改程式碼即可呼叫跨 cluster 服務；也可做全局 fail-over／金絲雀部署。
  6. 共享信任域與一致安全政策：共用根 CA，所有 cluster 的 mTLS 身份相同；AuthorizationPolicy、PeerAuthentication 在任何 cluster 都能共用。
  7. 統一政策下發與可觀測性：一套 CRD 定義可透過 GitOps 同步到所有 cluster；Prometheus/Grafana 也可一次聚合多 cluster 指標與 tracing。
← 回到筆記