Istio Ambient Mesh so với Kiến trúc Sidecar: Chi phí bộ nhớ, Ztunnel & Bảo mật Zero-Trust

Istio, với tư cách là tiêu chuẩn thực tế cho service mesh trong Kubernetes, theo truyền thống đã dựa vào mô hình sidecar injection để mở rộng khả năng của nó cho các workload ứng dụng. Mặc dù hiệu quả, mô hình này lại gây ra chi phí vận hành và tài nguyên đáng kể. Istio Ambient Mesh đại diện cho một sự thay đổi kiến trúc cơ bản, nhằm giải quyết những thách thức này bằng cách tách biệt các mối quan tâm của Lớp 4 (L4) và Lớp 7 (L7) thành các thành phần riêng biệt, được tối ưu hóa. Hướng dẫn này cung cấp một so sánh kỹ thuật toàn diện, trình bày chi tiết các sắc thái kiến trúc, ý nghĩa hiệu suất và tư thế bảo mật của cả hai mô hình.

Kiến trúc Istio Sidecar: Mô hình truyền thống

Kiến trúc Istio sidecar truyền thống hoạt động bằng cách inject một container proxy Envoy vào mỗi pod ứng dụng trong mesh. Proxy Envoy này chặn tất cả lưu lượng mạng vào và ra cho container ứng dụng, áp dụng các chính sách được định nghĩa bởi control plane của Istio (Istiod).

Cách Sidecar hoạt động

1. Injection: Khi một pod được tạo trong một namespace đã bật mesh, mutating admission webhook của Istio chặn yêu cầu tạo pod. Nó sửa đổi manifest của pod để bao gồm một initContainer (cho cấu hình iptables) và một container envoy (proxy sidecar).
2. Traffic Interception: initContainer cấu hình các quy tắc iptables trong network namespace của pod. Các quy tắc này chuyển hướng tất cả lưu lượng TCP đến và đi từ container ứng dụng thông qua sidecar Envoy.
3. Policy Enforcement: Sidecar Envoy, được Istiod cấu hình liên tục, thực thi một loạt các chính sách:
   • mTLS: mTLS tự động cho tất cả giao tiếp giữa các dịch vụ.
   • Traffic Management: Các quy tắc định tuyến, thử lại, thời gian chờ, ngắt mạch, fault injection.
   • Authorization: Các chính sách kiểm soát truy cập dựa trên danh tính, nguồn và đích.
   • Telemetry: Thu thập các số liệu, nhật ký và dấu vết để quan sát.

Lợi ích của mô hình Sidecar

• Kiểm soát chi tiết: Các chính sách được áp dụng ở cấp độ pod riêng lẻ, cung cấp khả năng kiểm soát chi tiết đối với lưu lượng của từng workload.
• Cách ly: Mỗi sidecar hoạt động độc lập, cung cấp một mức độ cách ly cho việc thực thi chính sách và tiêu thụ tài nguyên.
• Bộ tính năng trưởng thành: Mô hình sidecar đã là nền tảng của Istio trong nhiều năm, dẫn đến một bộ tính năng mạnh mẽ và dễ hiểu.

Nhược điểm và thách thức vận hành

Mặc dù có những lợi ích, mô hình sidecar vẫn gây ra một số thách thức đáng kể:

1. Chi phí tài nguyên: Mỗi sidecar Envoy tiêu thụ tài nguyên CPU và bộ nhớ. Trong các cluster dày đặc với hàng trăm hoặc hàng nghìn pod, tổng chi phí này có thể rất lớn, dẫn đến tăng chi phí cơ sở hạ tầng và giảm dung lượng cluster cho các workload ứng dụng.
   • Một sidecar Envoy điển hình có thể tiêu thụ 50-100MB RAM và 0.05-0.1 lõi CPU, ngay cả khi không hoạt động.
2. Độ phức tạp vận hành:
   • Quản lý Injection: Quản lý việc injection sidecar, loại trừ và ghi đè cấu hình có thể phức tạp.
   • Nhận biết ứng dụng: Các ứng dụng phải được thiết kế để chịu được sự hiện diện của sidecar, đặc biệt trong các chuỗi khởi động và tắt máy.
3. Độ phức tạp nâng cấp: Nâng cấp Istio thường yêu cầu khởi động lại tất cả các pod ứng dụng để cập nhật proxy sidecar của chúng. Điều này có thể dẫn đến gián đoạn dịch vụ và yêu cầu các chiến lược triển khai cẩn thận.
4. Hiệu suất mạng: Mặc dù nhìn chung hiệu quả, bước nhảy bổ sung thông qua sidecar có thể gây ra một lượng nhỏ độ trễ.
5. Gỡ lỗi: Gỡ lỗi các vấn đề mạng trở nên phức tạp hơn khi lưu lượng đi qua một lớp proxy bổ sung.

Ví dụ về Pod Sidecar

Quan sát một pod với một sidecar đã được inject. Lưu ý container istio-proxy.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: helloworld-v1
  labels:
    app: helloworld
    version: v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: helloworld
      version: v1
  template:
    metadata:
      labels:
        app: helloworld
        version: v1
    spec:
      containers:
      - name: helloworld
        image: docker.io/istio/examples-helloworld-v1
        resources:
          requests:
            cpu: "100m"
            memory: "128Mi"
          limits:
            cpu: "200m"
            memory: "256Mi"

Sau khi triển khai trong một namespace đã bật Istio, việc kiểm tra pod sẽ tiết lộ sidecar đã được inject:

kubectl get pod helloworld-v1-xxxxxxxxx-yyyyy -o yaml

Đoạn đầu ra:

...
spec:
  containers:
  - name: helloworld
    image: docker.io/istio/examples-helloworld-v1
    # ... application container details ...
  - name: istio-proxy
    image: docker.io/istio/proxyv2:1.20.0 # Example Istio version
    args:
    - proxy
    - sidecar
    - --domain
    - $(POD_NAMESPACE).svc.cluster.local
    - --configPath
    - /etc/istio/proxy
    - --binaryPath
    - /usr/local/bin/envoy
    # ... other Envoy configuration ...
    resources:
      requests:
        cpu: 10m
        memory: 128Mi # Example resource request for sidecar
      limits:
        cpu: 2
        memory: 1Gi
    # ...
  initContainers:
  - name: istio-init
    image: docker.io/istio/proxyv2:1.20.0
    args:
    - istio-iptables
    - -p
    - "15001"
    - -z
    - "15006"
    - -u
    - "1337"
    - -m
    - REDIRECT
    - -i
    - '*'
    - -x
    - ""
    - -b
    - '*'
    - -d
    - "15090,15021,15020"
    # ...

Đầu ra này cho thấy rõ ràng container istio-proxy và initContainer istio-init, xác nhận việc injection sidecar.

Kiến trúc Istio Ambient Mesh: Một sự thay đổi mô hình

Istio Ambient Mesh giới thiệu một cách tiếp cận không sidecar, thay đổi cơ bản cách các khả năng của service mesh được cung cấp. Nó đạt được điều này bằng cách tách biệt các chức năng L4 và L7 thành hai lớp riêng biệt, tùy chọn: ztunnel cấp độ node và waypoint proxies cấp độ namespace/service account. Kiến trúc này nhằm mục đích cung cấp bảo mật L4 phổ biến và thực thi chính sách L7 tùy chọn với chi phí giảm đáng kể.

Kiến trúc hai lớp

1. Ztunnel: Proxy L4 cấp độ Node

ztunnel là một proxy nhẹ, hiệu suất cao được triển khai dưới dạng DaemonSet trên mỗi node trong cluster Kubernetes. Trách nhiệm chính của nó là thiết lập và quản lý các kết nối an toàn, được mã hóa mTLS cho tất cả lưu lượng L4 trong mesh.

• Chức năng:

  • L4 mTLS: ztunnel chặn tất cả lưu lượng TCP đến và đi từ các pod ứng dụng trên node của nó và tự động nâng cấp nó lên mTLS. Điều này cung cấp một lớp bảo mật zero-trust cơ bản cho tất cả các giao tiếp mà không yêu cầu thay đổi ứng dụng hoặc injection sidecar.
  • Identity: Nó xử lý danh tính workload, đảm bảo rằng tất cả các kết nối mTLS được thiết lập giữa các danh tính đã được xác minh.
  • Authorization: Các chính sách ủy quyền L4 cơ bản có thể được thực thi bởi ztunnel.
  • Giao thức HBONE: ztunnel sử dụng giao thức HTTP-Based Overlay Network Environment (HBONE). HBONE đóng gói các luồng TCP qua HTTP/2, cho phép ztunnel ghép kênh nhiều kết nối mTLS qua một kết nối HTTP/2 duy nhất, liên tục giữa ztunnels trên các node khác nhau. Điều này làm giảm chi phí kết nối và cải thiện hiệu quả.
  • Traffic Interception: Tương tự như sidecar, ztunnel sử dụng iptables (hoặc eBPF trong các phiên bản tương lai) để chuyển hướng lưu lượng từ các pod trên node của nó thông qua chính nó.

• Mô hình triển khai: ztunnel chạy dưới dạng DaemonSet, nghĩa là một instance trên mỗi node. Chi phí tài nguyên của nó được phân bổ cho tất cả các pod trên node đó.

• Lợi ích:

  • Bảo mật L4 phổ biến: Tất cả lưu lượng trong mesh đều được mTLS theo mặc định, cung cấp một nền tảng bảo mật mạnh mẽ mà không có chi phí trên mỗi pod.
  • Giảm dấu chân tài nguyên: Loại bỏ nhu cầu về sidecar trong mỗi pod, giảm đáng kể chi phí bộ nhớ và CPU trên mỗi workload ứng dụng.
  • Đơn giản hóa vận hành: Nâng cấp ztunnel là cấp độ node, không phải cấp độ pod, đơn giản hóa việc nâng cấp mesh và tránh khởi động lại ứng dụng.
  • Tính minh bạch của ứng dụng: Các ứng dụng hoàn toàn không biết về sự hiện diện của ztunnel.

2. Waypoint Proxies: Proxy L7 cấp độ Namespace

Waypoint proxies là các proxy Envoy chuyên dụng được triển khai chỉ khi cần thực thi chính sách L7 cho các workload hoặc namespace cụ thể. Chúng không được inject vào các pod ứng dụng mà đóng vai trò là trung gian cho lưu lượng yêu cầu các tính năng L7 nâng cao.

• Chức năng:

  • Thực thi chính sách L7: Waypoint proxies xử lý các chính sách L7 nâng cao như định tuyến lưu lượng (ví dụ: triển khai canary, thử nghiệm A/B), thử lại HTTP, thời gian chờ, ngắt mạch, fault injection và ủy quyền L7.
  • Telemetry: Thu thập các số liệu, nhật ký và dấu vết L7 chi tiết.
  • Triển khai: Một waypoint proxy thường được triển khai cho mỗi service account hoặc mỗi namespace. Nó là một Kubernetes Deployment hoặc StatefulSet tiêu chuẩn.

• Luồng lưu lượng với Waypoint Proxies:

  1. Một pod ứng dụng gửi lưu lượng đến một đích.
  2. ztunnel của node nguồn chặn lưu lượng, thiết lập kết nối mTLS HBONE đến ztunnel của node đích.
  3. Nếu workload đích yêu cầu các chính sách L7 (tức là đã cấu hình một waypoint proxy), ztunnel đích sẽ chuyển tiếp lưu lượng đến waypoint proxy.
  4. Waypoint proxy áp dụng các chính sách L7 và sau đó chuyển tiếp lưu lượng đến pod ứng dụng đích thực tế.
  5. Pod ứng dụng đích nhận lưu lượng, không biết về waypoint proxy.

• Lợi ích:

  • L7 tùy chọn: Các khả năng L7 chỉ được bật khi cần, tránh chi phí không cần thiết cho các dịch vụ đơn giản.
  • Cách ly: Waypoint proxies có thể được mở rộng và quản lý độc lập với các workload ứng dụng.
  • Phân tách rõ ràng các mối quan tâm: Trách nhiệm L4 và L7 được phân tách rõ ràng.

Sơ đồ luồng lưu lượng Ambient Mesh (Khái niệm)

Ví dụ về thành phần Ambient Mesh

Ztunnel DaemonSet:

kubectl get daemonset -n istio-system ztunnel

Đoạn đầu ra:

NAME      DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   NODE SELECTOR   AGE
ztunnel   3         3         3       3            3           <none>          2d

Điều này cho thấy ztunnel đang chạy trên 3 node trong namespace istio-system.

Triển khai Waypoint Proxy:

Đầu tiên, định nghĩa một tài nguyên Gateway thuộc loại waypoint cho một service account hoặc namespace cụ thể.

# waypoint-proxy.yaml
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
metadata:
  name: default-waypoint
  namespace: default
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

Triển khai điều này tạo ra một waypoint proxy cho service account default trong namespace default:

kubectl apply -f waypoint-proxy.yaml

Sau đó, bạn có thể quan sát triển khai đã tạo:

kubectl get deployment -n default istio-waypoint-default-waypoint

Đoạn đầu ra:

NAME                           READY   UP-TO-DATE   AVAILABLE   AGE
istio-waypoint-default-waypoint   1/1     1            1           5m

Triển khai này chạy proxy Envoy sẽ xử lý các chính sách L7 cho các workload được liên kết với service account default trong namespace default.

Chi phí bộ nhớ và đánh giá hiệu suất

Động lực chính cho Ambient Mesh là giảm chi phí tài nguyên. Mức tiêu thụ tài nguyên trên mỗi pod của mô hình sidecar tăng tuyến tính với số lượng pod, nhanh chóng trở thành nút thắt cổ chai trong các cluster lớn. Ambient Mesh thay đổi đáng kể phương trình này.

Chi phí bộ nhớ

• Mô hình Sidecar: Mỗi sidecar Envoy thường tiêu thụ 50-100 MiB RAM (không hoạt động) và có thể tăng cao hơn khi tải. Đối với một cluster có 1000 pod, điều này tương đương với 50-100 GiB RAM chỉ dành cho sidecar.
• Ambient Mesh:
  • Ztunnel: Một instance ztunnel tiêu thụ khoảng 100-200 MiB RAM trên mỗi node. Chi phí này được phân bổ cho tất cả các pod trên node đó. Nếu một node chứa 50 pod, chi phí trên mỗi pod cho bảo mật L4 giảm xuống còn 2-4 MiB.
  • Waypoint Proxy: Một waypoint proxy, khi được triển khai, tiêu thụ tài nguyên tương tự như một sidecar đơn lẻ (ví dụ: 50-100 MiB RAM). Tuy nhiên, chúng chỉ được triển khai khi cần các chính sách L7 và có thể phục vụ nhiều workload hoặc toàn bộ namespace, tiếp tục phân bổ chi phí của chúng.

Ví dụ về tiết kiệm bộ nhớ: Xem xét một node với 20 pod ứng dụng.

• Sidecar: 20 pod * 75 MiB/sidecar = 1500 MiB (1.5 GiB)
• Ambient: 1 ztunnel (150 MiB) + 1 waypoint (75 MiB, nếu cần L7 cho tất cả) = 225 MiB.
  • Điều này thể hiện mức tiết kiệm hơn 1.2 GiB RAM trên mỗi node trong kịch bản này. Trong một cluster có nhiều node, điều này tương đương với hàng trăm gigabyte bộ nhớ được thu hồi cho các workload ứng dụng.

Sử dụng CPU

• Mô hình Sidecar: Mỗi sidecar tiêu thụ chu kỳ CPU để chặn lưu lượng, đàm phán mTLS, đánh giá chính sách và telemetry. Một sidecar không hoạt động có thể tiêu thụ 0.05-0.1 lõi CPU.
• Ambient Mesh:
  • Ztunnel: ztunnel được tối ưu hóa cao cho xử lý L4. Nó có thể tiêu thụ 0.1-0.2 lõi CPU trên mỗi node, một lần nữa được phân bổ.
  • Waypoint Proxy: Tương tự như sidecar, một waypoint proxy có thể tiêu thụ 0.05-0.1 lõi CPU khi hoạt động, nhưng chỉ cho lưu lượng đã bật L7.

Tổng dấu chân CPU nhìn chung thấp hơn trong Ambient Mesh, đặc biệt đối với các workload chỉ yêu cầu bảo mật L4.

Tác động độ trễ

• Mô hình Sidecar: Lưu lượng đi qua hai proxy Envoy (sidecar nguồn, sidecar đích) cho mTLS và các chính sách L7. Mỗi bước nhảy thêm một lượng nhỏ độ trễ, thường là 0.5-1.5 ms trên mỗi yêu cầu cho một đường dẫn L7 đầy đủ.
• Ambient Mesh:
  • Chỉ L4: Lưu lượng đi qua ztunnel nguồn và ztunnel đích. Giao thức HBONE hiệu quả. Chi phí độ trễ thường là 0.2-0.8 ms.
  • Đã bật L7: Lưu lượng đi qua ztunnel nguồn, ztunnel đích và sau đó là waypoint proxy. Điều này thêm một bước nhảy bổ sung so với chỉ L4, nhưng đường dẫn tổng thể thường tương đương hoặc tốt hơn một chút so với sidecar do hiệu quả của ztunnel và tính chất chuyên dụng của waypoint proxies. Chi phí độ trễ thường là 0.6-1.2 ms.

Bảng so sánh toàn diện: Sidecar so với Ambient Mesh

| Tính năng / Số liệu | Kiến trúc Istio Sidecar | Kiến trúc Istio Ambient Mesh