1. Đóng gói mô hình AI thành container chuẩn cho Edge
Bước đầu tiên là đóng gói mô hình TensorFlow hoặc PyTorch vào Docker image nhẹ, tối ưu cho môi trường Edge có tài nguyên hạn chế.
Tại sao: Image nhỏ giúp giảm thời gian pull và lưu trữ, đồng thời giảm bề mặt tấn công (attack surface) bằng cách loại bỏ các package không cần thiết.
Kết quả mong đợi: Một Docker image có thể chạy và trả về dự đoán AI ngay lập tức khi khởi động container.
Chuẩn bị thư mục làm việc và file Dockerfile tối ưu sử dụng base image Python slim.
mkdir -p ai-workload/src
cd ai-workload
cat > Dockerfile
Kết quả: File Dockerfile đã được tạo với cấu hình tối ưu cho inference.
Xây dựng image Docker và gắn tag phù hợp với registry nội bộ hoặc cloud registry.
docker build -t my-registry.io/edge-ai/inference-model:v1.0 .
docker push my-registry.io/edge-ai/inference-model:v1.0
Kết quả: Image đã được đẩy lên registry và sẵn sàng cho KubeEdge pull về node Edge.
Verify: Kiểm tra kích thước image và chạy thử local để đảm bảo port 8501 lắng nghe request.
docker images | grep inference-model
docker run -d --name test-ai -p 8501:8501 my-registry.io/edge-ai/inference-model:v1.0
curl http://localhost:8501/v1/models/inference-model:predict
Kết quả: Docker trả về kích thước image (dưới 2GB là tốt) và curl trả về JSON chứa kết quả dự đoán.
2. Cấu hình Ingress Gateway để định tuyến request từ IoT
Thiết lập Ingress Gateway của Istio để chấp nhận lưu lượng từ các thiết bị IoT và định tuyến đến service AI đã triển khai.
Tại sao: IoT devices thường gửi request qua HTTP/HTTPS hoặc gRPC. Ingress Gateway đóng vai trò cổng vào, áp dụng TLS termination và định tuyến dựa trên host/path.
Kết quả mong đợi: Request từ IoT devices được chuyển hướng an toàn đến Pod AI trong namespace edge-ai.
Tạo file định nghĩa Ingress Gateway cho traffic AI. Cấu hình lắng nghe port 80 (HTTP) và 443 (HTTPS) với TLS.
cat > /etc/kubeedge/ingress-ai-gateway.yaml
Kết quả: Istio tạo resource Gateway và cập nhật configmap cho Envoy proxy tại node Edge.
Tạo VirtualService để định tuyến request cụ thể từ host AI đến service backend (deployment AI).
cat > /etc/kubeedge/virtual-service-ai.yaml
Kết quả: Lưu lượng đến path /predict hoặc /health sẽ được chuyển về service inference-model-service.
Verify: Kiểm tra logs của Envoy proxy để xác nhận request được định tuyến đúng và gửi test request qua gateway.
kubectl logs -l istio=ingressgateway -n istio-system | grep "my-edge-ai.local"
curl -H "Host: ai.my-edge-ai.local" http:///predict -d '{"instances": []}'
Kết quả: Logs Envoy hiện thông báo route match thành công và curl trả về kết quả từ model AI.
3. Áp dụng Resource Quota và Limit Range cho container AI
Thiết lập giới hạn tài nguyên (CPU/RAM) và tổng hạn ngạch (Quota) cho namespace chứa workload AI để tránh tình trạng một container chiếm hết tài nguyên node Edge.
Tại sao: Node Edge thường có RAM/CPU thấp (ví dụ: Raspberry Pi 4 hoặc Jetson Nano). Không giới hạn tài nguyên sẽ gây treo hệ thống khi model AI chạy quá tải.
Kết quả mong đợi: Kubernetes từ chối deploy Pod nếu yêu cầu tài nguyên vượt quá Limit, và namespace không thể tiêu thụ vượt quá Quota.
Tạo ResourceQuota cho namespace 'edge-ai' giới hạn tổng số Pod và tổng tài nguyên CPU/RAM của cả namespace.
cat > /etc/kubeedge/resource-quota-ai.yaml
Kết quả: Namespace edge-ai bị giới hạn tối đa 5 pods, tổng 4 core CPU request và 8Gi RAM limit.
Tạo LimitRange để đặt giá trị mặc định (default) và giới hạn tối đa (max) cho từng container AI. Điều này đảm bảo ngay cả khi user không khai báo requests/limits, container vẫn có giới hạn an toàn.
cat > /etc/kubeedge/limit-range-ai.yaml
Kết quả: Mọi Pod AI mới tạo sẽ tự động có default request 100m CPU và 256Mi RAM, không thể vượt quá 2 CPU và 4Gi RAM.
Verify: Thử deploy một Pod với yêu cầu tài nguyên vượt quá giới hạn để xem Kubernetes từ chối (Error FailedScheduling hoặc ValidationError).
cat > /tmp/test-oversized-pod.yaml
Kết quả: Command trả về lỗi "exceeded quota" hoặc "exceeded max" chứng tỏ bảo vệ tài nguyên hoạt động.
4. Thiết lập chính sách truy cập (RBAC) cho service AI trong K8s
Cấu hình Role-Based Access Control (RBAC) để chỉ cho phép Service Account cụ thể tương tác với service AI, ngăn chặn truy cập trái phép từ các namespace khác.
Tại sao: Trong môi trường Edge, nhiều service chia sẻ cùng cluster. RBAC đảm bảo chỉ service được ủy quyền mới gọi API của model AI, giảm rủi ro data leak hoặc injection.
Kết quả mong đợi: Service Account được phép gọi service AI, các Service Account khác bị từ chối truy cập (403 Forbidden).
Tạo ServiceAccount dành riêng cho các client IoT hoặc microservice khác cần gọi API AI.
kubectl create serviceaccount ai-consumer -n edge-ai
Kết quả: ServiceAccount 'ai-consumer' được tạo trong namespace edge-ai.
Tạo Role cấp quyền 'get', 'list', 'watch' cho resource 'services' và 'endpoints' liên quan đến service AI. Đây là quyền tối thiểu để service khác phát hiện và gọi service AI.
cat > /etc/kubeedge/rbac-ai-role.yaml
Kết quả: Role 'ai-reader-role' được tạo với các quyền đọc cần thiết.
Gán Role vừa tạo cho ServiceAccount 'ai-consumer' thông qua RoleBinding.
cat > /etc/kubeedge/rbac-ai-binding.yaml
Kết quả: ServiceAccount 'ai-consumer' hiện có quyền truy cập các resource AI trong namespace edge-ai.
Verify: Kiểm tra quyền truy cập bằng cách giả lập request từ ServiceAccount khác không có quyền, và so sánh với ServiceAccount đã được cấp quyền.
kubectl auth can-i get services inference-model-service -n edge-ai --as=system:serviceaccount:edge-ai:ai-consumer
kubectl auth can-i delete deployments inference-model-service -n edge-ai --as=system:serviceaccount:edge-ai:ai-consumer
Kết quả: Command đầu tiên trả về 'yes', command thứ hai trả về 'no' (vì Role chỉ cấp quyền get/list, không cấp delete).
Đ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 4: Tích hợp eBPF với Cilium để tối ưu hiệu năng mạng và bảo mật
Phần 6: Giám sát, phân tích và Troubleshooting hệ thống Edge AI »