Blog
Thoughts on engineering, design, and building great products.
Leader Election, Addon và Node Autoscaling
Cụm chạy ba control plane, nhưng controller-manager và scheduler thì chỉ một bản được hoạt động tại một thời điểm — nếu cả ba cùng làm, chúng giẫm chân nhau. Bài này xem cơ chế giữ điều đó: leader election qua Lease, và chứng minh failover thật bằng cách hạ leader xuống rồi xem một controller khác giành quyền. Rồi khép Part XIII bằng hai mảnh vận hành còn lại — cách cụm tự dựng quản addon, và node autoscaling tự thêm bớt máy theo tải.
Vertical Pod Autoscaler và resource manager
HPA thêm pod khi tải lên. VPA làm điều ngược: giữ nguyên số pod nhưng chỉnh đúng lượng CPU/RAM mỗi pod cần — hết cảnh đặt request bừa rồi lãng phí hoặc thiếu. Bài này cài VPA (add-on, như Metrics Server), cho nó quan sát một workload thật rồi đưa khuyến nghị, và sang phía node: CPU Manager static policy ghim hẳn lõi CPU cho pod Guaranteed — test thật, thấy pod được cấp đúng một CPU độc quyền.
Metrics Server và HorizontalPodAutoscaler
Part VIII đổi hướng: thay vì giết pod khi quá tải, ta thêm pod. Nhưng muốn autoscale theo CPU thì cluster phải biết pod đang dùng bao nhiêu CPU — mà cụm tự dựng của ta chưa có ai đo. Bài này cài add-on đầu tiên, Metrics Server, vấp đúng một cái bẫy KTHW (control plane không nói chuyện được với pod) rồi sửa nó, rồi dựng HPA và đốt CPU thật để xem nó tự nhân pod từ 1 lên 4.
Resource Requests/Limits và Autoscaling (HPA)
Mỗi pod cần nói rõ nó muốn bao nhiêu CPU/RAM — đó là cách scheduler đặt pod đúng chỗ và cluster không sập vì một pod ngốn hết tài nguyên. Khai báo xong, HorizontalPodAutoscaler tự tăng/giảm số bản sao theo tải. Bài này tạo tải thật và xem HPA scale từ 1 lên nhiều pod.