Kiến Trúc Cloud Service Mesh — Managed Istio, Data Plane vs Control Plane

Vấn đề mà Service Mesh giải quyết

Trong microservices architecture, mỗi service cần xử lý một tập hợp cross-cutting concerns:

Bảo mật: Đảm bảo service A chỉ gọi được service B nếu được phép, và traffic được mã hóa
Reliability: Retry khi transient failure, circuit break khi downstream service chậm
Observability: Biết request đi qua những service nào, latency ở đâu cao
Traffic control: Canary deployment, A/B test, traffic mirroring

Cách tiếp cận ngây thơ là implement tất cả trong application code — nhưng đây là vấn đề vì:

Mỗi ngôn ngữ phải implement lại: Go có circuit breaker library, Java có Hystrix, Python có Tenacity — nhưng chúng không thể enforce cross-service policy từ một chỗ
Application code bị polluted: Business logic lẫn với infrastructure concerns
Không có single source of truth: Mỗi team configure retry policy khác nhau

Service mesh giải quyết bằng cách đặt một transparent proxy (Envoy) vào trong mỗi Pod. Application nghĩ nó đang nói chuyện trực tiếp với service khác, nhưng thực ra mọi traffic đều đi qua Envoy. Envoy xử lý mTLS, retry, circuit breaking, và emit telemetry — hoàn toàn transparent với application code.

Cloud Service Mesh là gì?

Cloud Service Mesh (CSM) là managed implementation của Istio trên GKE, do Google vận hành control plane. Thay vì tự cài Istio và maintain istiod, pilot, citadel — Google quản lý những component này, và bạn chỉ tương tác qua Istio API (VirtualService, DestinationRule, PeerAuthentication, etc.).

CSM được build trên cùng open-source Istio project, nhưng:

Control plane (Istiod) chạy trong GKE cluster, managed bởi GKE
Google handle upgrades, scaling, và HA của control plane
Tích hợp với Cloud Monitoring, Cloud Trace, Cloud Logging
CSM dashboard trong Google Cloud Console

Hai mode của CSM

1. In-cluster control plane (truyền thống)

┌─────────────────────────────────────┐
│            GKE Cluster               │
│  ┌──────────────────────────────┐   │
│  │    istio-system namespace     │   │
│  │    istiod (Deployment)        │   │
│  │    - Pilot (service discovery)│   │
│  │    - Citadel (cert issuance)  │   │
│  │    - Galley (config)          │   │
│  └──────────────────────────────┘   │
│                                      │
│  [App Pods with Envoy sidecars]      │
└─────────────────────────────────────┘

2. Managed control plane (CSM v2) Với Cloud Service Mesh phiên bản mới nhất, Google có thể host Istiod ngoài cluster (hosted control plane). Data plane vẫn là Envoy sidecars trong cluster, nhưng control plane được fully managed. Đây là hướng phát triển của CSM.

Cài đặt CSM trên GKE

bash

# Enable CSM trên GKE cluster mới
gcloud container clusters create my-cluster \
  --enable-managed-prometheus \
  --workload-pool=PROJECT_ID.svc.id.goog \
  --addons=HttpLoadBalancing,GcsFuseCsiDriver

# Enable CSM fleet feature
gcloud container fleet mesh enable --project=PROJECT_ID

# Register cluster vào fleet
gcloud container fleet memberships register my-cluster \
  --gke-cluster=LOCATION/my-cluster \
  --enable-workload-identity

# Enable automatic control plane management
gcloud container fleet mesh update \
  --management=automatic \
  --memberships=my-cluster \
  --project=PROJECT_ID \
  --location=global

Sau khi enable, CSM sẽ tự động:

Cài Istiod trong istio-system namespace
Configure MutatingWebhookConfiguration để inject Envoy sidecar
Setup certificate authority cho mTLS

Kiến trúc Data Plane: Envoy Proxy

Envoy là gì?

Envoy là high-performance C++ proxy, ban đầu được build tại Lyft và nay là CNCF graduated project. Đây là core của Istio data plane, nhưng cũng được dùng trong nhiều hệ thống khác (AWS App Mesh, Consul Connect, Contour Ingress).

Envoy Architecture bên trong Pod

Mỗi Pod trong mesh có hai containers:

Application container: App của bạn
Envoy sidecar (istio-proxy): Proxy xử lý all network traffic

┌─────────────────────────────────────────────────────────┐
│                      Pod                                  │
│                                                           │
│  ┌──────────────┐         ┌──────────────────────────┐  │
│  │  Application  │         │      istio-proxy          │  │
│  │  Container    │◄───────►│      (Envoy)              │  │
│  │               │ loopback│                            │  │
│  │  Port: 8080   │         │  Inbound: 15006           │  │
│  └──────────────┘         │  Outbound: 15001           │  │
│                            │  Admin: 15000              │  │
│                            │  Prometheus: 15090         │  │
│  ┌──────────────┐         │  Health: 15021             │  │
│  │  istio-init   │         │  Tunnel: 15008             │  │
│  │  (init ctr)   │         └──────────────────────────┘  │
│  │  iptables rules│                                       │
│  └──────────────┘                                        │
└─────────────────────────────────────────────────────────┘

Các ports Envoy lắng nghe:

15001: Outbound traffic (từ app đi ra ngoài)
15006: Inbound traffic (traffic đến app từ ngoài vào)
15000: Envoy admin interface (debug, stats)
15090: Prometheus metrics scraping
15021: Health check endpoint
15008: HBONE (HTTP CONNECT-based overlay network, dùng với ambient mesh)

Envoy Listener và Filter Chain

Envoy hoạt động theo mô hình Listener → Filter Chain → Cluster → Endpoint:

Inbound Connection
       │
       ▼
  ┌─────────┐
  │ Listener │  Port 15006 lắng nghe tất cả inbound traffic
  │  15006   │
  └────┬─────┘
       │
       ▼
  ┌──────────────┐
  │ Filter Chain │  Match dựa trên port, protocol, SNI
  │   Matching   │
  └────┬─────────┘
       │
       ▼
  ┌──────────────────────────────────────────────────┐
  │             Network Filters                       │
  │  - tcp_proxy hoặc http_connection_manager        │
  │  - istio_authn (mTLS verification)              │
  │  - envoy.filters.network.rbac (authorization)   │
  └────┬─────────────────────────────────────────────┘
       │
       ▼
  ┌──────────────────────────────────────────────────┐
  │             HTTP Filters (nếu HTTP)               │
  │  - router (route matching)                       │
  │  - fault (fault injection)                      │
  │  - retry                                        │
  │  - cors                                         │
  └────┬─────────────────────────────────────────────┘
       │
       ▼
  ┌─────────┐
  │ Cluster  │  Upstream service definition
  │          │  (load balancing, circuit breaking)
  └────┬─────┘
       │
       ▼
  ┌──────────┐
  │ Endpoints │  Actual IP:port của service instances
  └──────────┘

Kiến trúc Control Plane: Istiod

Istiod là gì?

Istiod là monolithic control plane của Istio kể từ Istio 1.5+. Trước đó, control plane gồm các microservices riêng: Pilot, Citadel, Galley, Mixer. Việc hợp nhất vào Istiod giúp:

Đơn giản hóa deployment
Giảm latency giữa các components
Dễ debug hơn

Ba chức năng chính của Istiod

1. Pilot — Service Discovery và Traffic Management

Pilot subscribe vào Kubernetes API Server để nhận updates về:

Services, Endpoints, EndpointSlices → service discovery
Istio CRDs: VirtualService, DestinationRule, Gateway, ServiceEntry → traffic rules

Sau đó convert thành Envoy xDS config và push xuống tất cả Envoy proxies.

K8s API Server
    │
    │ Watch (Services, Endpoints, Istio CRDs)
    ▼
  Pilot
    │
    │ xDS push (CDS, EDS, LDS, RDS, SDS)
    ▼
Envoy Proxies (trong mọi Pod)

2. Citadel — Certificate Authority

Citadel (nay integrated vào Istiod) là Certificate Authority trong mesh:

Cấp certificates SPIFFE/SVID cho mỗi service
Certificates dựa trên Kubernetes ServiceAccount identity
Auto-rotate certificates trước khi expire
Implements Kubernetes CertificateSigningRequest workflow

Kubelet (CSI driver) hoặc Envoy (SDS)
    │
    │ CSR (Certificate Signing Request)
    │ với identity: spiffe://cluster.local/ns/NS/sa/SA
    ▼
  Citadel (trong Istiod)
    │
    │ Signed certificate (SVID)
    │ Validity: 24h (default), rotated tại 50% lifetime
    ▼
Envoy proxy (sử dụng trong mTLS handshake)

3. Galley — Config Validation và Distribution

Galley xử lý:

Validate Istio CRDs khi được create/update
MCP (Mesh Configuration Protocol) để distribute config
Config analysis và cảnh báo misconfigurations

Istiod HA và Scaling

yaml

# CSM tự manage, nhưng nếu self-hosted:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istiod
  namespace: istio-system
spec:
  replicas: 3  # HA với 3 replicas
  selector:
    matchLabels:
      app: istiod
  template:
    spec:
      containers:
      - name: discovery
        image: gcr.io/istio-release/pilot:1.20.0
        resources:
          requests:
            cpu: 500m
            memory: 2Gi
          limits:
            cpu: 4
            memory: 8Gi
        env:
        - name: PILOT_ENABLE_WORKLOAD_ENTRY_AUTOREGISTRATION
          value: "true"
        - name: PILOT_DEBOUNCE_AFTER
          value: 100ms  # Batch config updates
        - name: PILOT_DEBOUNCE_MAX
          value: 10s

Scaling guidelines cho Istiod:

1 Istiod replica handle ~1000 connected Envoy proxies comfortably
Tăng resources khi có nhiều VirtualService/DestinationRule phức tạp
Memory chủ yếu bị consume bởi xDS push cache

CSM vs Self-Managed Istio

So sánh chi tiết

Tiêu chí	Cloud Service Mesh	Self-managed Istio
Control plane ops	Google managed	Tự manage (upgrade, HA, scaling)
Tích hợp GCP	Native (Cloud Monitoring, Trace)	Cần config thủ công
Versioning	Tied to GKE version	Tự chọn Istio version
Customization	Limited (MeshConfig)	Full access
Debugging	CSM Dashboard, gcloud CLI	istioctl, Kiali
Cost	Theo GKE pricing	Compute cost cho control plane pods
Ambient mesh	Preview support	Manual installation
Upgrade toil	Minimal	Significant (test trước khi upgrade)

Khi nào chọn CSM?

Chọn CSM khi:

Team không có Istio expertise sâu
Muốn integration với Cloud Monitoring/Trace/Logging native
GKE-only deployment
Không cần customize Istio internals

Chọn self-managed Istio khi:

Multi-cloud deployment (Anthos on-prem, AWS, Azure)
Cần Istio version mới nhất trước GKE support
Custom Envoy filter/plugin
Cần kiểm soát hoàn toàn control plane

GKE Integration Model

CSM và GKE Fleet

CSM tích hợp với GKE Fleet cho multi-cluster scenarios:

bash

# Enable mesh cho entire fleet
gcloud container fleet mesh update \
  --management=automatic \
  --memberships=cluster-1,cluster-2,cluster-3 \
  --project=PROJECT_ID

Với Fleet, CSM có thể:

Share service discovery across clusters
Federate trust (cross-cluster mTLS)
Centralize traffic management policies

MeshConfig — Global Mesh Settings

yaml

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
spec:
  meshConfig:
    # Default proxy settings
    defaultConfig:
      concurrency: 2  # Envoy worker threads
      proxyMetadata:
        BOOTSTRAP_XDS_AGENT: "true"
    
    # Distributed tracing
    enableTracing: true
    defaultProviders:
      tracing:
      - name: stackdriver
    
    # Access logging
    accessLogFile: /dev/stdout
    accessLogFormat: |
      [%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%"
      %RESPONSE_CODE% %GRPC_STATUS% %RESPONSE_FLAGS%
      %BYTES_RECEIVED% %BYTES_SENT% %DURATION%
      "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%"
      "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%"
      "%UPSTREAM_HOST%"
    
    # mTLS mode
    meshMTLS:
      minProtocolVersion: TLSV1_3
    
    # Outbound traffic policy
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY  # Block traffic to unknown services

Namespace-Level Control

yaml

# Enable sidecar injection cho namespace
kubectl label namespace my-app istio-injection=enabled

# Disable cho specific namespace
kubectl label namespace monitoring istio-injection=disabled

# Revision-based injection (khi upgrade)
kubectl label namespace my-app istio.io/rev=asm-1-20

Lifecycle của một Request trong CSM

Theo dõi một HTTP request từ Service A đến Service B:

1. Service A gọi http://service-b:8080/api/v1/users
   │
   │ (iptables REDIRECT: traffic từ app → envoy outbound port 15001)
   ▼
2. Envoy A (outbound listener 15001)
   - Nhận request từ Service A app
   - Lookup route: service-b.namespace.svc.cluster.local
   - Apply VirtualService rules (retry, timeout, header manipulation)
   - Select endpoint từ EDS (load balance)
   - Establish mTLS connection đến Envoy B
   │
   │ mTLS tunnel (SVID certificates, TLS 1.3)
   ▼
3. Envoy B (inbound listener 15006)
   - Terminate mTLS, verify peer certificate
   - Verify AuthorizationPolicy (là Service A được phép gọi không?)
   - Apply rate limiting, fault injection nếu configured
   - Forward đến Service B app (127.0.0.1:8080)
   │
   │ (iptables REDIRECT: traffic từ envoy inbound → app port 8080)
   ▼
4. Service B app xử lý request
   │
   │ Response theo chiều ngược lại
   ▼
5. Telemetry emit:
   - Envoy A: request metrics, access log
   - Envoy B: request metrics, access log
   - Trace context propagated via B3/W3C headers

Kết luận và Key Takeaways

CSM = managed Istio: Bạn vẫn dùng Istio API, Google manage control plane
Istiod là monolith: Pilot + Citadel + Galley hợp nhất, đơn giản hơn trước
Envoy là data plane: Mọi traffic đều qua Envoy, application không thay đổi
xDS là giao tiếp: Istiod push config xuống Envoy qua xDS gRPC streaming
Identity-based security: mTLS dựa trên SPIFFE/SVID (ServiceAccount identity), không phải IP

Kiến Trúc Cloud Service Mesh — Managed Istio, Data Plane vs Control Plane ​

Vấn đề mà Service Mesh giải quyết ​

Cloud Service Mesh là gì? ​

Hai mode của CSM ​

Cài đặt CSM trên GKE ​

Kiến trúc Data Plane: Envoy Proxy ​

Envoy là gì? ​

Envoy Architecture bên trong Pod ​

Envoy Listener và Filter Chain ​

Kiến trúc Control Plane: Istiod ​

Istiod là gì? ​

Ba chức năng chính của Istiod ​

Istiod HA và Scaling ​

CSM vs Self-Managed Istio ​

So sánh chi tiết ​

Khi nào chọn CSM? ​

GKE Integration Model ​

CSM và GKE Fleet ​

MeshConfig — Global Mesh Settings ​

Namespace-Level Control ​

Lifecycle của một Request trong CSM ​

Kết luận và Key Takeaways ​

References ​

Kiến Trúc Cloud Service Mesh — Managed Istio, Data Plane vs Control Plane

Vấn đề mà Service Mesh giải quyết

Cloud Service Mesh là gì?

Hai mode của CSM

Cài đặt CSM trên GKE

Kiến trúc Data Plane: Envoy Proxy

Envoy là gì?

Envoy Architecture bên trong Pod

Envoy Listener và Filter Chain

Kiến trúc Control Plane: Istiod

Istiod là gì?

Ba chức năng chính của Istiod

Istiod HA và Scaling

CSM vs Self-Managed Istio

So sánh chi tiết

Khi nào chọn CSM?

GKE Integration Model

CSM và GKE Fleet

MeshConfig — Global Mesh Settings

Namespace-Level Control

Lifecycle của một Request trong CSM

Kết luận và Key Takeaways

References