Cài đặt Istio trong chế độ Demo phù hợp với tài nguyên Edge
Trên môi trường Edge, tài nguyên CPU và RAM thường bị giới hạn nghiêm trọng so với Cloud. Chúng ta sẽ sử dụng chế độ demo của Istio. Chế độ này giảm thiểu overhead của các component như Istiod bằng cách chạy chúng trong một pod duy nhất, giảm thiểu số lượng container chạy song song.
Tại sao cần làm điều này: Để đảm bảo hệ thống KubeEdge của bạn không bị quá tải khi khởi động các component Service Mesh, đồng thời vẫn giữ được đầy đủ tính năng cơ bản như traffic routing và security.
Kết quả mong đợi: Istio Core components (Pilot, Ingress, Egress, CNI) sẽ được triển khai trong namespace istio-system với trạng thái Running.
Trước tiên, hãy tải xuống binary istioctl phiên bản mới nhất tương thích với Kubernetes của bạn. Sau đó, cài đặt Istio với profile demo.
curl -L https://istio.io/downloadIstio | sh -
export PATH=$PWD/istio-1.20.0/bin:$PATH
istioctl install --set profile=demo -y
Verify kết quả: Kiểm tra trạng thái của các pod trong namespace istio-system. Tất cả phải ở trạng thái Running và Ready.
kubectl get pods -n istio-system
Cấu hình Sidecar Proxy (Envoy) tự động injection cho workload AI
Trong môi trường Edge AI, các workload (model inference, data processing) cần được bảo vệ và giám sát. Chúng ta sẽ kích hoạt tính năng Sidecar Injection để Envoy proxy tự động được inject vào mỗi pod trong namespace đích.
Tại sao cần làm điều này: Envoy proxy đóng vai trò là gateway mạng cho từng container, xử lý traffic vào/ra, thực thi chính sách bảo mật và thu thập metrics mà không cần can thiệp vào code ứng dụng.
Kết quả mong đợi: Khi bạn deploy một Deployment mới trong namespace ai-workloads, pod sẽ tự động chứa thêm container istio-proxy.
Tạo namespace riêng cho các workload AI và gắn nhãn (label) istio-injection vào namespace này. Label này kích hoạt cơ chế Mutation của Kubernetes để thêm Envoy vào pod spec.
kubectl create namespace ai-workloads
kubectl label namespace ai-workloads istio-injection=enabled
Verify kết quả: Deploy một ứng dụng mẫu đơn giản (ví dụ: sleep pod) và kiểm tra số lượng container trong pod đó. Bạn phải thấy container istio-proxy xuất hiện.
kubectl run sleep --image=docker.io/library/sleep:latest -n ai-workloads
kubectl get pods -n ai-workloads -o jsonpath='{.items[0].spec.containers[*].name}'
Triển khai mTLS để mã hóa giao tiếp giữa các microservice
Để đảm bảo tính bảo mật tuyệt đối cho dữ liệu AI khi di chuyển giữa các microservice (ví dụ: từ Data Ingestion sang Inference Engine), chúng ta sẽ bật mutual TLS (mTLS). Điều này yêu cầu cả client và server phải xác thực lẫn nhau bằng chứng số (certificate) trước khi thiết lập kết nối.
Tại sao cần làm điều này: Ngăn chặn các cuộc tấn công nghe lén (eavesdropping) và man-in-the-middle (MITM) trong mạng nội bộ của cụm Edge, đặc biệt quan trọng khi dữ liệu AI nhạy cảm.
Kết quả mong đợi: Tất cả traffic HTTP/HTTPS giữa các pod trong cluster sẽ được mã hóa bằng TLS. Nếu một client không có chứng chỉ hợp lệ, kết nối sẽ bị từ chối.
Tạo tài nguyên PeerAuthentication ở mức namespace ai-workloads với chế độ STRICT. Đây là chính sách mặc định yêu cầu mTLS cho tất cả traffic trong namespace.
cat
Verify kết quả: Sử dụng istioctl để kiểm tra cấu hình mTLS hiện hành và xác nhận trạng thái kết nối giữa các service là MUTUAL.
istioctl analyze -n ai-workloads
istioctl proxy-config status -n ai-workloads
Cấu hình Policy và PeerAuthentication cho bảo mật nội bộ
Đôi khi, một số microservice cũ hoặc phần cứng đặc biệt (legacy devices) trong Edge có thể chưa hỗ trợ mTLS. Chúng ta cần cấu hình chính sách linh hoạt để cho phép chúng giao tiếp theo phương thức không bảo mật (PERMISSIVE) hoặc chỉ định rõ ràng cho từng service cụ thể.
Tại sao cần làm điều này: Để cân bằng giữa bảo mật cao và khả năng tương thích (compatibility), cho phép hệ thống hoạt động ngay cả khi có các thành phần chưa chuẩn bị sẵn sàng cho mTLS.
Kết quả mong đợi: Traffic đến service đích (ví dụ: legacy-api) sẽ được chấp nhận cả HTTP (không mã hóa) và HTTPS (mTLS), trong khi các service khác vẫn bắt buộc mTLS.
Tạo một PeerAuthentication cụ thể áp dụng cho một service riêng biệt (selector) với chế độ PERMISSIVE. Điều này ghi đè chính sách mặc định STRICT của namespace cho service đó.
cat
Verify kết quả: Sử dụng lệnh istioctl để kiểm tra cấu hình mTLS áp dụng cho service legacy-api và xác nhận nó là PERMISSIVE.
istioctl analyze -n ai-workloads
kubectl get peerauthentication -n ai-workloads -o yaml
Điều hướng series:
Mục lục: Series: Xây dựng hệ thống Service Mesh an toàn cho Edge AI với KubeEdge và eBPF
« Phần 2: Triển khai nền tảng KubeEdge và thiết lập kết nối Cloud-Edge
Phần 4: Tích hợp eBPF với Cilium để tối ưu hiệu năng mạng và bảo mật »