Blog
Thoughts on engineering, design, and building great products.
In-place Pod Resize
Suốt series, đổi tài nguyên một container nghĩa là tạo lại pod. In-place pod resize phá giả định đó: chỉnh CPU/memory của một pod đang chạy mà không restart, qua subresource resize. Bài này resize một pod thật rồi soi cgroup v2 trên node đổi theo tại chỗ với restartCount vẫn 0 — đối trọng 'không gián đoạn' cho phần scale dọc của Bài 40 — và chạm vào hai ràng buộc: không đổi được QoS, và vì sao memory cần resizePolicy riêng.
Node Allocatable: tài nguyên thật pod được dùng
Bài 22 nhìn requests/limits từ phía pod. Bài này lật sang phía node: một máy 2 vCPU không cho pod xài trọn 2 vCPU đó. Kubernetes cắt bớt phần cho daemon hệ thống, cho daemon Kubernetes, và một khoản đệm chống hết RAM — phần còn lại mới là Allocatable, thứ scheduler thực sự đem chia. Bài này đào công thức Allocatable, đọc Capacity vs Allocatable trên node thật, rồi tự tay thêm reservation và xem Allocatable tụt đúng từng Ki.
Requests, limits, QoS và Downward API
Khai requests và limits cho container không chỉ là chuyện đặt con số. requests dẫn đường cho scheduler, limits là hàng rào kernel cưỡng chế — CPU bị bóp, bộ nhớ vượt là OOM kill. Từ bộ số đó Kubernetes xếp pod vào ba lớp QoS quyết định ai bị giết trước khi node cạn RAM. Bài này test thật cả ba lớp QoS, một cú OOMKilled, và Downward API để pod tự đọc thông tin về chính nó.
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.