Kubernetes: Hiểu về resources.requests, resources.limits và cgroup Linux
Giới thiệu
Kubernetes đã trở thành một công cụ không thể thiếu trong việc quản lý container trong môi trường sản xuất. Một trong những khía cạnh quan trọng của Kubernetes là khả năng quản lý tài nguyên cho các Pod thông qua các trường resources.requests và resources.limits. Trong bài viết này, chúng ta sẽ tìm hiểu cách mà các tham số này hoạt động và cách cgroups trong Linux hỗ trợ việc quản lý tài nguyên hiệu quả.
Mục lục
- Cgroups trong Linux
- Thư mục
/sys/fs/cgroup/ - CPU và Memory trong cgroups, cgroups v1 vs v2
- Tại sao giới hạn CPU trong Kubernetes có thể không tốt?
- Linux CFS và cpu.weight
- So sánh cpu.weight và nice của process
- Tóm tắt về cgroups Linux
- Tài nguyên Pod Kubernetes và cgroups Linux
- Đơn vị CPU trong Kubernetes và chia sẻ CPU trong cgroup
- Kiểm tra tài nguyên Pod Kubernetes trong cgroup
- Cgroup kubepods.slice trong Kubernetes
- Kubernetes, cpu.weight và cgroups v2
- Các lớp chất lượng dịch vụ của Kubernetes
Cgroups trong Linux
Cgroups (Control Groups) là một trong hai cơ chế chính của kernel Linux cho phép quản lý và kiểm soát tài nguyên của các tiến trình:
- Linux namespaces: tạo không gian riêng biệt cho các tiến trình.
- Cgroups: cơ chế kiểm soát tài nguyên như bộ nhớ, CPU, mạng và I/O đĩa mà các tiến trình có thể sử dụng.
Cgroups cho phép chúng ta nhóm các tiến trình lại với nhau, và áp dụng các giới hạn tài nguyên cho cả nhóm mà không phân biệt giữa cha và con. Điều này có nghĩa là nếu một nhóm cha bị giới hạn ở 512 MB, tổng tài nguyên của nó và các tiến trình con không thể vượt quá 512 MB.
Thư mục /sys/fs/cgroup/
Tất cả các cgroups được định nghĩa trong thư mục /sys/fs/cgroup/, nơi mà chúng ta có thể thấy cấu trúc cây của các nhóm tiến trình. Ví dụ:
$ tree /sys/fs/cgroup/ -d -L 2
/sys/fs/cgroup/
├── dev-hugepages.mount
├── dev-mqueue.mount
├── init.scope
└── system.sliceChúng ta có thể thấy rằng các tiến trình được nhóm lại theo loại, ví dụ như system.slice cho tất cả các dịch vụ systemd và user.slice cho các tiến trình của người dùng.
CPU và Memory trong cgroups, cgroups v1 vs v2
Trong cgroups, chúng ta có thể xác định bao nhiêu CPU và Memory mà các tiến trình trong nhóm có thể sử dụng. Ví dụ, cho người dùng có ID 1000, chúng ta có thể kiểm tra các thông số sau:
$ cat /sys/fs/cgroup/user.slice/user-1000.slice/cpu.max
max 100000
$ cat /sys/fs/cgroup/user.slice/user-1000.slice/memory.max
max- cpu.max: giới hạn thời gian CPU mà nhóm tiến trình có thể sử dụng trong một khoảng thời gian nhất định.
- memory.max: giới hạn bộ nhớ mà nhóm có thể sử dụng mà không bị OOM Killer tắt.
Cgroups v2 đã thay thế một số tham số của cgroups v1 để đơn giản hóa và cải thiện khả năng quản lý tài nguyên.
Tại sao giới hạn CPU trong Kubernetes có thể không tốt?
Việc đặt giới hạn CPU trong Kubernetes có thể gây ra tình trạng throttling, nghĩa là ngay cả khi có CPU trống, nếu nhóm tiến trình đã sử dụng hết thời gian được cấp trong khoảng thời gian hiện tại, các tiến trình sẽ bị đình chỉ cho đến khi hết khoảng thời gian đó. Điều này có thể làm giảm hiệu suất của ứng dụng.
Linux CFS và cpu.weight
Khi không có giới hạn được đặt, Linux CFS (Completely Fair Scheduler) sẽ phân phối thời gian CPU cho các nhóm tiến trình dựa trên cpu.weight. Giá trị này xác định độ ưu tiên của nhóm khi có nhiều nhóm cạnh tranh sử dụng CPU. Mặc định, giá trị cpu.weight là 100, với khoảng từ 1 đến 10,000.
So sánh cpu.weight và nice của process
Trong khi cpu.weight được thiết lập ở cấp độ cgroup, nice lại được thiết lập cho từng tiến trình cụ thể. Giá trị nice càng thấp, tiến trình càng có nhiều thời gian CPU. Ngược lại, cpu.weight xác định nhóm nào được ưu tiên hơn khi tranh giành CPU.
Tóm tắt về cgroups Linux
Mỗi cgroup xác định:
cpu.max: thời gian CPU mà nhóm có thể sử dụng trong mỗi khoảng thời gian.memory.max: giới hạn bộ nhớ mà nhóm có thể sử dụng.cpu.weight: xác định mức độ ưu tiên của nhóm tiến trình khi CPU đang bị tải.
Tài nguyên Pod Kubernetes và cgroups Linux
Khi chúng ta đặt spec.containers.resources trong Deployment hoặc Pod, kubelet sẽ lấy các giá trị từ PodSpec và truyền chúng đến Container Runtime Interface (CRI). CRI sẽ chuyển đổi chúng thành một đặc tả container trong định dạng JSON, trong đó xác định các giá trị thích hợp cho cgroup của container.
Đơn vị CPU trong Kubernetes và chia sẻ CPU trong cgroup
Trong các manifest Kubernetes, chúng ta xác định tài nguyên CPU bằng các đơn vị CPU: 1 đơn vị = 1 core CPU. Một millicpu là 1/1000 của một core CPU. Một đơn vị CPU trong Kubernetes tương đương với 1024 CPU shares trong cgroup tương ứng.
Kiểm tra tài nguyên Pod Kubernetes trong cgroup
Chúng ta có thể tạo một Pod thử nghiệm như sau:
yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-test
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
cpu: "1"
memory: "1Gi"
limits:
cpu: "1"
memory: "1Gi"Sau khi tạo Pod, chúng ta có thể kiểm tra các thông số tài nguyên trong cgroup của nó.
Cgroup kubepods.slice trong Kubernetes
Tất cả các tham số cho Pods của Kubernetes được thiết lập trong thư mục /sys/fs/cgroup/kubepods.slice/. Chúng ta có thể tìm thấy các thông số như cpu.max, memory.max, và cpu.weight.
Kubernetes, cpu.weight và cgroups v2
Khi kiểm tra giá trị cpu.weight, chúng ta thấy rằng giá trị này được tính toán dựa vào số lượng CPU shares được xác định trong Kubernetes. Điều này giúp cgroups v2 quản lý tài nguyên hiệu quả hơn.
Các lớp chất lượng dịch vụ của Kubernetes
Trong thư mục /sys/fs/cgroup/kubepods.slice/, chúng ta có thể thấy các lớp chất lượng dịch vụ như BestEffort, Burstable, và Guaranteed. Mỗi lớp này có cách quản lý tài nguyên khác nhau, phụ thuộc vào cách mà chúng ta đã cấu hình các giới hạn và yêu cầu tài nguyên.
Kết luận
Việc hiểu rõ về resources.requests, resources.limits, và cách mà cgroups hoạt động trong Linux là rất quan trọng đối với việc tối ưu hóa hiệu suất ứng dụng trong Kubernetes. Hãy chắc chắn rằng bạn đã áp dụng các thực tiễn tốt nhất trong việc quản lý tài nguyên để đảm bảo rằng ứng dụng của bạn hoạt động hiệu quả.
Câu hỏi thường gặp (FAQ)
resources.requestsvàresources.limitslà gì?resources.requestsxác định tài nguyên tối thiểu mà Pod cần, trong khiresources.limitsxác định tài nguyên tối đa mà Pod có thể sử dụng.
- Tại sao việc đặt giới hạn CPU không phải lúc nào cũng tốt?
- Việc này có thể dẫn đến tình trạng throttling, làm giảm hiệu suất của ứng dụng.
Liên kết hữu ích
- Cgroups — Deep Dive into Resource Management in Kubernetes
- Making Sense of Kubernetes CPU Requests And Limits
