Triển khai Prometheus và Grafana trên Proxmox để giám sát hệ thống Edge
Bước đầu tiên là thiết lập stack giám sát tập trung trên máy chủ Proxmox (Master Node) để thu thập métr từ toàn bộ cluster K3s, bao gồm cả các node Jetson. Chúng ta sẽ sử dụng Helm để triển khai Prometheus và Grafana một cách nhanh chóng và chuẩn hóa.
Việc này giúp bạn có cái nhìn tổng quan về tài nguyên CPU, RAM, GPU và trạng thái của các container AI mà không cần truy cập trực tiếp vào từng thiết bị biên.
Đầu tiên, hãy thêm repository Helm cho Prometheus Community và Prometheus Adapter.
helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
helm repo update
Kết quả: Output hiển thị thông báo repository đã được thêm và update thành công, không có lỗi.
Tiếp theo, tạo một file giá trị tùy chỉnh để cấu hình Prometheus thu thập dữ liệu từ node Jetson (thường là kiến trúc ARM64) và expose port ra ngoài.
cat > /root/prometheus-values.yaml
Kết quả: File `prometheus-values.yaml` được tạo thành công trong thư mục `/root`.
Cài đặt Prometheus vào namespace `monitoring`.
kubectl create namespace monitoring
helm install prometheus prometheus-community/kube-prometheus-stack -n monitoring -f /root/prometheus-values.yaml
Kết quả: Helm thông báo `STATUS: deployed` và danh sách các resource đã tạo (StatefulSet, Service, etc.).
Tiếp theo, triển khai Grafana để trực quan hóa dữ liệu. Chúng ta cần expose service Grafana qua NodePort hoặc Ingress để truy cập từ browser.
helm install grafana grafana/grafana -n monitoring --set service.type=NodePort --set service.nodePort=30000 --set adminPassword=AdminEdge2024
Kết quả: Grafana được deploy, bạn có thể truy cập tại `http://:30000` với tài khoản `admin` và mật khẩu `AdminEdge2024`.
Để verify, truy cập Grafana, vào menu "Configuration" -> "Data Sources", bạn sẽ thấy nguồn dữ liệu Prometheus đã được tự động kết nối và trạng thái là "Health: OK".
Cấu hình Fluent Bit để tập trung logs từ Jetson
Trong môi trường Edge, log file phân tán trên các node Jetson gây khó khăn cho việc debug. Chúng ta sẽ sử dụng Fluent Bit (nhẹ hơn Fluentd) làm sidecar hoặc daemonset để thu thập log và đẩy về Elasticsearch hoặc lưu trữ tập trung trên Proxmox.
Fluent Bit có kích thước nhỏ, tiêu thụ ít tài nguyên, phù hợp với Jetson Nano/Orin.
Đầu tiên, tạo namespace `logging` và file cấu hình `fluentbit-values.yaml` để định cấu hình plugin đầu vào (Tail) và đầu ra (Forward hoặc HTTP).
cat > /root/fluentbit-values.yaml
Kết quả: File cấu hình `fluentbit-values.yaml` được tạo, đã cấu hình cụ thể cho kiến trúc ARM64 và chỉ định host nhận log.
Cài đặt Fluent Bit vào cluster K3s.
helm install fluent-bit fluent/fluent-bit -n logging -f /root/fluentbit-values.yaml
Kết quả: DaemonSet của Fluent Bit chạy trên tất cả các node (bao gồm Jetson), mỗi pod sẽ thu thập log từ container trên node đó.
Để verify, hãy tạo một pod test đơn giản trên node Jetson và in log ra file, sau đó kiểm tra trên máy chủ Proxmox (nơi chạy Fluent Bit hoặc Log Collector) xem log đã đến chưa.
kubectl run test-log --image=alpine --restart=Never --rm -it -- /bin/sh -c "while true; do echo 'Test log from Jetson at $(date)'; sleep 2; done"
# Trên Proxmox (nếu dùng forward plugin):
tcpdump -i any -n port 24224 -s 0 -w /tmp/fluent.pcap
Kết quả: Bạn thấy các gói tin TCP được gửi đến port 24224 trên Proxmox chứa nội dung "Test log from Jetson".
Cấu hình chứng chỉ mTLS cho giao tiếp trong cluster
Bảo mật giao tiếp giữa các thành phần trong K3s (API Server, Etcd, Kubelet) và giữa các service là bắt buộc trong Edge AI để ngăn chặn tấn công Man-in-the-Middle (MitM). Mặc định K3s đã tạo chứng chỉ, nhưng chúng ta sẽ cấu hình lại để sử dụng mTLS (Mutual TLS) chặt chẽ hơn cho các service quan trọng.
Chúng ta sẽ sử dụng `cert-manager` để tự động hóa việc cấp phát và gia hạn chứng chỉ, đảm bảo không có downtime.
Đầu tiên, cài đặt cert-manager vào cluster. Lưu ý sử dụng version tương thích với K3s.
kubectl create namespace cert-manager
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.2/cert-manager.yaml
kubectl wait --for=condition=available deployment --all -n cert-manager --timeout=5m
Kết quả: cert-manager được deploy và pod trạng thái `Available`.
Tạo ClusterIssuer để sử dụng CA nội bộ của K3s (Self-Signed) hoặc kết nối với CA bên ngoài. Ở đây ta dùng CA nội bộ để đơn giản hóa cho môi trường Edge offline.
cat > /root/selfsigned-clusterissuer.yaml
Kết quả: Hai ClusterIssuer được tạo, một để tạo CA gốc, một để cấp phát chứng chỉ dựa trên CA đó.
Tạo Secret chứa CA gốc (nếu chưa có) hoặc sử dụng CA mặc định của K3s. Ở đây ta giả định K3s đã có CA, ta sẽ tạo Certificate cho API Server để enforce mTLS.
cat > /root/api-server-cert.yaml
Kết quả: Certificate được tạo, cert-manager sẽ tự động tạo Secret `api-server-mtls-cert` chứa `tls.crt` và `tls.key`.
Để enforce mTLS, bạn cần cập nhật config của K3s (file `config.yaml` trong `/etc/rancher/k3s/`) để chỉ định đường dẫn đến certificate này cho API Server và Kubelet, sau đó restart service K3s.
cat >> /etc/rancher/k3s/config.yaml
Kết quả: K3s restart, khi test kết nối từ bên ngoài vào API Server, nếu không có chứng chỉ client hợp lệ sẽ bị từ chối (401/403).
Verify bằng cách thử curl vào API Server với và không có client certificate.
curl -v --cacert /etc/rancher/k3s/server-ca.pem --cert /root/api-server-mtls-cert --key /root/api-server-mtls-key https://192.168.1.10:6443/healthz
# Nếu thiếu --cert/--key:
curl -v https://192.168.1.10:6443/healthz
Kết quả: Lệnh đầu tiên trả về `200 OK`, lệnh thứ hai trả về lỗi `401 Unauthorized` hoặc lỗi handshake TLS.
Áp dụng Policy (OPA Gatekeeper) để hạn chế container không an toàn
Trong môi trường Edge, việc chạy container với quyền root hoặc mount volume nhạy cảm là rủi ro lớn. Chúng ta sẽ sử dụng OPA Gatekeeper để áp dụng các policy bắt buộc, ngăn chặn việc deploy các workload không tuân thủ tiêu chuẩn bảo mật.
Gatekeeper sẽ chặn request tạo Pod nếu vi phạm policy đã định nghĩa.
Triển khai OPA Gatekeeper vào cluster K3s. Lưu ý Gatekeeper cần quyền RBAC cao.
helm repo add gatekeeper https://open-policy-agent.github.io/gatekeeper/charts
helm repo update
helm install gatekeeper gatekeeper/gatekeeper-crds -n gatekeeper-system --create-namespace
helm install gatekeeper gatekeeper/gatekeeper -n gatekeeper-system --set installCRDs=false
Kết quả: Gatekeeper Controller và CRDs được deploy, pod trạng thái `Running`.
Định nghĩa ConstraintTemplate (mẫu policy) để kiểm tra container không được chạy với quyền root.
cat > /root/forbid-root.yaml
Kết quả: ConstraintTemplate `k8sforbidroot` được tạo thành công.
Định nghĩa Constraint (policy cụ thể) để áp dụng mẫu trên cho toàn bộ cluster.
cat > /root/forbid-root-constraint.yaml
Kết quả: Constraint `deny-root-containers` được áp dụng, Gatekeeper bắt đầu kiểm tra mọi request tạo Pod.
Để verify, hãy thử tạo một Pod chạy với quyền root. Gatekeeper sẽ chặn yêu cầu này.
cat > /root/test-root-pod.yaml
Kết quả: Lệnh trả về lỗi: `error: admission webhook "validation.gatekeeper.sh" denied the request: Running as root is forbidden in this Edge cluster.`.
Ngược lại, nếu tạo Pod không có `runAsRoot: true` (hoặc `runAsNonRoot: true`), Pod sẽ được tạo thành công.
cat > /root/test-safe-pod.yaml
Kết quả: Pod được tạo thành công, trạng thái `Running`.
Điều hướng series:
Mục lục: Series: Series: Xây dựng nền tảng Edge AI với NVIDIA Jetson, Kubernetes K3s và hệ thống quản lý thiết bị biên trên hạ tầng Proxmox
« Phần 7: Tối ưu hóa hiệu năng và cân bằng tải cho Edge AI
Phần 9: Xử lý sự cố, backup và các mẹo nâng cao »