1. Xác định và chuẩn bị yêu cầu phần cứng nền tảng
Chúng ta cần một máy chủ vật lý hoặc máy ảo có cấu hình đủ mạnh để chạy Kubernetes host, Hypervisor cho Kata Containers và runtime sandbox cho gVisor cùng lúc.
Yêu cầu tối thiểu để đảm bảo hiệu năng cho AI workloads trong sandbox kép là 8 vCPU (bắt buộc hỗ trợ virtualization), 16GB RAM và 100GB SSD NVMe.
Đầu tiên, kiểm tra xem CPU của server có hỗ trợ kỹ thuật virtualization (Intel VT-x hay AMD-V) hay không. Đây là điều kiện tiên quyết để Kata Containers hoạt động.
grep -E --color 'vmx|svm' /proc/cpuinfo
Kết quả mong đợi: Phải xuất hiện dòng chứa từ "vmx" (đối với Intel) hoặc "svm" (đối với AMD). Nếu không có, bạn cần kích năng năng này trong BIOS/UEFI trước khi tiếp tục.
1.2. Kích năng năng Kernel Modules cho Virtualization
Để Kata Containers và gVisor hoạt động ổn định, chúng ta cần đảm bảo các module kernel liên quan đến KVM và network namespaces đã được load.
sudo modprobe kvm_intel && sudo modprobe kvm && sudo modprobe br_netfilter
Kết quả mong đợi: Không có lỗi báo về. Các module này sẽ cho phép container ảo hóa chạy trực tiếp trên phần cứng và quản lý mạng nội bộ.
Để kiểm tra các module đã được load thành công, sử dụng lệnh lsmod.
lsmod | grep -E 'kvm|br_netfilter'
Kết quả mong đợi: Xuất hiện danh sách các module kvm_intel, kvm và br_netfilter trong đầu ra.
2. Triển khai Kubernetes Cluster và công cụ CLI
Chúng ta sẽ sử dụng kubeadm để dựng một Kubernetes cluster đơn node (control-plane) để làm môi trường sandbox. Đây là cách tiếp cận nhanh nhất để test kiến trúc mà không cần cluster lớn.
Trước khi cài đặt, cần disable swap vì Kubernetes mặc định không hỗ trợ swap để đảm bảo tính nhất quán của scheduler và performance.
sudo swapoff -a && sudo sed -i '/ swap / s/^\(.*\)$/\1#/' /etc/fstab
Kết quả mong đợi: Swap bị tắt ngay lập tức và dòng cấu hình swap trong file fstab bị comment lại.
2.2. Cài đặt container runtime và Kubernetes components
Chúng ta cần cài đặt containerd (runtime mặc định cho K8s hiện đại), kubectl, kubeadm và kubelet. Phiên bản được khuyến nghị cho series này là v1.29.x để tương thích tốt với các tính năng sandbox mới.
sudo apt-get update && sudo apt-get install -y apt-transport-https ca-certificates curl gpg
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y containerd kubectl kubeadm kubelet
Kết quả mong đợi: Quá trình cài đặt hoàn tất không lỗi, các package được thêm vào hệ thống.
2.3. Cấu hình Containerd cho Kubernetes
Containerd mặc định cần được cấu hình để sử dụng plugin cri (Container Runtime Interface) để Kubernetes có thể giao tiếp. Chúng ta sẽ tạo file cấu hình này thủ công để đảm bảo chính xác.
sudo mkdir -p /etc/containerd
containerd config default | sudo tee /etc/containerd/config.toml
Bây giờ, chỉnh sửa file cấu hình vừa tạo. Chúng ta cần thay đổi dòng "SystemdCgroup = false" thành "SystemdCgroup = true" để Kubernetes sử dụng cgroup v2, giúp quản lý tài nguyên cho AI workloads chính xác hơn.
sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
Sau khi sửa, restart containerd để áp dụng thay đổi.
sudo systemctl restart containerd
Kết quả mong đợi: Service containerd chạy lại thành công, không báo lỗi.
2.4. Khởi tạo Kubernetes Control Plane
Giờ chúng ta sẽ khởi tạo cluster. Chúng ta sẽ bỏ qua Pod Network (flannel/calico) trong bước này để tập trung vào việc setup runtime sandbox, sẽ cấu hình network riêng trong phần sau.
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --ignore-preflight-errors=Swap
Kết quả mong đợi: Xuất hiện thông báo "Your Kubernetes control-plane has initialized successfully!" và một đoạn mã join node (dù chúng ta chỉ dùng 1 node).
2.5. Cài đặt Kubectl cho user hiện tại
Để kubectl có thể điều khiển cluster mà không cần sudo, chúng ta cần copy config từ root sang home directory của user.
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Kết quả mong đợi: File config được tạo trong thư mục home, quyền sở hữu thuộc về user hiện tại.
2.6. Cài đặt Kustomize
Kustomize là công cụ quản lý cấu hình Kubernetes tiêu chuẩn, giúp chúng ta overlay các config cho Kata và gVisor mà không cần duplicate file YAML.
curl -s "https://raw.githubusercontent.com/kubernetes-sigs/kustomize/master/hack/install_kustomize.sh" | sudo bash
Verify kết quả bằng cách chạy lệnh kustomize version.
kustomize version
Kết quả mong đợi: Xuất hiện phiên bản kustomize (ví dụ: v5.0.0).
3. Lập kế hoạch kiến trúc tích hợp
Trước khi cài đặt Kata Containers hay gVisor, chúng ta cần định nghĩa rõ ràng về kiến trúc luồng dữ liệu và cách các component giao tiếp. Kiến trúc này sẽ bao gồm một Policy Engine nằm giữa API Server và Runtime.
3.1. Thiết kế luồng xử lý yêu cầu Pod
Khi một developer submit một Pod yêu cầu chạy AI model, luồng đi sẽ như sau: API Server nhận request -> Policy Engine (OPA/Gatekeeper) đánh giá -> Nếu an toàn, Kubernetes chọn Runtime (Kata hoặc gVisor) -> Pod chạy trong sandbox.
Chúng ta sẽ phân loại workload thành 3 mức độ tin cậy:
- Trusted Workloads: Code nội bộ, đã audit -> Chạy trên container runtime mặc định (containerd).
- Semi-Trusted Workloads: Code từ nguồn bên thứ 3, thư viện AI phổ biến -> Chạy trên gVisor (Isolation mức độ cao, overhead thấp).
- Untrusted Workloads: Code từ nguồn không rõ, môi trường testing độc hại -> Chạy trên Kata Containers (Isolation mức độ tối đa, dùng VM real).
3.2. Cấu trúc thư mục dự án
Tạo cấu trúc thư mục để chứa các manifest Kubernetes cho từng phần của kiến trúc. Đây sẽ là nơi chúng ta viết file YAML cho Kata, gVisor và Policy trong các phần sau.
mkdir -p ~/secure-ai-sandbox/{kata-containers,gvisor,policy-engine,common}
cd ~/secure-ai-sandbox
Kết quả mong đợi: Thư mục được tạo thành công với cấu trúc rõ ràng.
3.3. Xác định Label Selector cho Runtime Class
Trong Kubernetes, chúng ta sử dụng "RuntimeClass" để chỉ định runtime cho Pod. Chúng ta sẽ chuẩn bị sẵn các label selector để Policy Engine sau này có thể gắn vào Pod dựa trên nhãn (label) của workload.
Tạo file định nghĩa kế hoạch cho RuntimeClass trong thư mục common.
cat
Kết quả mong đợi: File plan.md được tạo với nội dung chi tiết về chiến lược phân bổ runtime.
3.4. Chuẩn bị Network Policy cơ bản
Mặc dù chưa cài đặt CNI (Container Network Interface) phức tạp, chúng ta cần chuẩn bị tư duy về Network Policy. Sandbox AI thường cần truy cập GPU hoặc external API, nhưng cần chặn traffic nội bộ giữa các Pod không tin cậy.
Tạo file mẫu network policy sẽ được dùng để hạn chế traffic giữa các sandbox untrusted.
cat
Kết quả mong đợi: File YAML template được tạo, sẵn sàng để áp dụng khi cluster đã có CNI.
3.5. Verify môi trường Kubernetes
Đảm bảo Kubernetes cluster đã sẵn sàng để nhận các workload trước khi chuyển sang phần 2.
kubectl get nodes
Kết quả mong đợi: Node control-plane có trạng thái "Ready".
kubectl get pods -n kube-system
Kết quả mong đợi: Các pod hệ thống (coredns, kube-proxy, etc.) đang ở trạng thái "Running" hoặc "ContainerCreating" (do chưa có CNI).
Điều hướng series:
Mục lục: Series: Xây dựng nền tảng Secure AI Sandbox với Kata Containers, gVisor và Policy Engine
Phần 2: Triển khai Kata Containers cho workload AI yêu cầu bảo mật cao »