Kiểm tra logs của Cluster Autoscaler và Metric Server
Đầu tiên, hãy xác minh xem các component quan trọng đang hoạt động bình thường hay không. Lỗi auto-scaling thường bắt nguồn từ việc Metric Server không gửi được dữ liệu hoặc Autoscaler không nhận được sự kiện.
Sử dụng lệnh kubectl để xem logs của Metric Server. Component này thường nằm trong namespace kube-system.
kubectl logs -n kube-system -l app=metrics-server --tail=50
Kết quả mong đợi: Bạn thấy các dòng log ghi nhận việc scrape metrics thành công từ các node, không có lỗi connection refused hoặc context deadline exceeded. Nếu thấy lỗi https://10.x.x.x:10250, hãy kiểm tra firewall hoặc certificate của kubelet.
Tiếp theo, kiểm tra logs của Cluster Autoscaler. Deployment này thường nằm trong namespace kube-system với tên cluster-autoscaler.
kubectl logs -n kube-system deployment/cluster-autoscaler --tail=100
Kết quả mong đợi: Logs hiển thị các dòng như Scaling up, Scaling down, hoặc No nodes need scaling. Nếu thấy Provisioning request failed hoặc Failed to get metrics, hãy ghi lại mã lỗi cụ thể để xử lý ở phần sau.
Để kiểm tra trạng thái health của Metric Server, hãy xem output của lệnh describe trên pod của nó.
kubectl get pods -n kube-system -l app=metrics-server -o jsonpath='{.items[*].metadata.name}' | xargs -I {} kubectl describe pod -n kube-system {} | grep -A 5 "Last State"
Kết quả mong đợi: Trạng thái Last State là Terminated với Exit Code là 0, hoặc Running ổn định. Nếu thấy Exit Code khác 0 lặp đi lặp lại, Metric Server đang crash loop.
Xử lý lỗi khi Proxmox không tạo được node mới
Khi Cluster Autoscaler phát hiện tải cao và gửi yêu cầu đến Proxmox API nhưng máy ảo không được tạo ra, nguyên nhân thường nằm ở cấu hình secret, template máy ảo, hoặc quyền hạn API token.
Bước 1: Kiểm tra Secret chứa thông tin kết nối Proxmox. Autoscaler cần secret này để xác thực.
kubectl get secret promox-api-creds -n kube-system -o yaml
Kết quả mong đợi: Bạn thấy các trường username và api-token-value đã được mã hóa base64. Đảm bảo giá trị api-token-value khớp với token bạn đã tạo trên giao diện Proxmox (Format: root@pam!your-token-id).
Bước 2: Kiểm tra cấu hình Template máy ảo (Cloud-Init) trên Proxmox. Nếu template bị lỗi hoặc thiếu driver network, VM mới sẽ không boot lên được.
Trên terminal Proxmox, kiểm tra trạng thái của template VM (giả sử ID là 100).
qm status 100
Kết quả mong đợi: Trạng thái là running. Nếu template đang stopped hoặc crashed, Autoscaler không thể clone nó. Hãy khởi động lại template bằng lệnh qm start 100.
Bước 3: Kiểm tra quyền hạn của API Token trên Proxmox. Token cần có quyền VMAdmin để tạo và xóa máy ảo.
Trên giao diện Proxmox (hoặc CLI), kiểm tra role của token.
pvesh get /access/tokens/root@pam!your-token-id
Kết quả mong đợi: Trong output, trường privileges phải chứa quyền VM.Audit, VM.Allocate, VM.Config.*, và VM.Power. Nếu thiếu quyền VM.Allocate, Autoscaler sẽ bị từ chối khi gửi lệnh tạo VM.
Bước 4: Nếu vẫn lỗi, hãy kiểm tra log của Proxmox để xem lỗi cụ thể tại thời điểm Autoscaler gọi API.
grep -i "cluster-autoscaler\|autoscaler" /var/log/syslog | tail -n 20
Kết quả mong đợi: Bạn thấy các dòng log ghi nhận yêu cầu từ IP của node K3s. Nếu có dòng Permission denied, quay lại bước 3. Nếu có dòng Cloud-Init failed, hãy kiểm tra cấu hình Cloud-Init của template (file /etc/default/cloud-init).
Để verify kết quả sửa lỗi, tạo một ứng dụng dummy để kích hoạt scaling và quan sát log Proxmox.
stress --cpu 4 --timeout 600 & sleep 10; kubectl get nodes -o wide
Kết quả mong đợi: Sau khoảng 1-2 phút, bạn thấy thêm một node mới trong danh sách kubectl get nodes với trạng thái Ready.
Khắc phục vấn đề HPA không phản ứng với tải
Horizontal Pod Autoscaler (HPA) không tự động tăng số lượng pod (Replicas) dù CPU/RAM đã cao. Đây thường là lỗi cấu hình threshold hoặc Metric Server không cung cấp dữ liệu.
Bước 1: Kiểm tra trạng thái hiện tại của HPA để xem metric đang báo giá trị gì.
kubectl describe hpa -n
Kết quả mong đợi: Trong phần Current CPU utilization, giá trị phải lớn hơn threshold bạn đã set (ví dụ 80%). Nếu hiển thị unknown hoặc 0%, Metric Server không lấy được số liệu.
Bước 2: Kiểm tra xem Pod có được label đúng để HPA nhận diện không.
kubectl get pods -l app= -n -o wide
Kết quả mong đợi: Các pod phải có label app khớp với selector trong HPA. Nếu selector sai, HPA sẽ không tìm thấy pod nào để scale.
Bước 3: Kiểm tra Resource Request/Limit. HPA chỉ hoạt động nếu Pod có định nghĩa resources.requests cho CPU.
kubectl get deployment -n -o yaml | grep -A 3 resources
Kết quả mong đợi: Bạn thấy định nghĩa rõ ràng như cpu: 100m hoặc cpu: 1. Nếu thiếu requests, HPA không thể tính toán % sử dụng CPU và sẽ không scale.
Bước 4: Cập nhật Deployment để thêm resource requests nếu bị thiếu.
Sửa file /home/admin/manifests/app-deployment.yaml (ví dụ).
cat > /home/admin/manifests/app-deployment.yaml
Kết quả mong đợi: File được tạo thành công. Sau đó áp dụng lại với lệnh kubectl apply -f /home/admin/manifests/app-deployment.yaml.
Bước 5: Kiểm tra lại Metric Server có đang gửi data cho HPA không bằng cách xem events của HPA.
kubectl get events -n --field-selector involvedObject.kind=HorizontalPodAutoscaler --sort-by='.lastTimestamp'
Kết quả mong đợi: Bạn thấy các sự kiện Scaling up hoặc Scaling down với lý do cpu utilization. Nếu thấy Unable to get metrics, hãy quay lại phần kiểm tra Metric Server ở đầu bài.
Để verify kết quả cuối cùng, tạo tải giả và quan sát số lượng pod tăng lên.
for i in {1..50}; do curl http:///health & done; sleep 60; kubectl get hpa -n ; kubectl get pods -n
Kết quả mong đợi: Số lượng REPLICAS trong HPA tăng lên (ví dụ từ 1 lên 3) và số lượng pod trong namespace cũng tăng tương ứng sau khi CPU đạt ngưỡng.
Điều hướng series:
Mục lục: Series: Xây dựng hạ tầng Kubernetes tự động (Auto-Scaling) với K3s và Helm trên Proxmox
« Phần 8: Tối ưu hóa hiệu năng và chi phí cho cụm Auto-Scaling
Phần 10: Nâng cao: Bảo mật và Backup cho hạ tầng Auto-Scaling »