Tổng quan
Kubernetes hỗ trợ tính năng Request (yêu cầu) và Limit (giới hạn) để quản lý tài nguyên CPU và bộ nhớ cho các pod và container chạy trong Cluster.
Thiết lập đúng Request (yêu cầu) và Limit (giới hạn) trên các pod giúp tránh xung đột tài nguyên và đảm bảo lập lịch hiệu quả cho các Pod chạy trong Cluster của bạn. Việc các pod tiêu thụ đột ngội, bất ngờ là một trong những thách thức lớn mà quản trị viên Kubernetes phải đối mặt, và cấu hình sai hoặc sự gia tăng tải đột ngột dịch vụ có thể dẫn đến việc tiêu thụ CPU hoặc bộ nhớ quá mức. Điều này thường gây ra những hậu quả không mong muốn cho các pod “láng giềng” chạy trên cùng Worker Node, hoặc việc Pod dịch vụ bị hệ điều hành can thiệp “killer” (OOM) để kết thúc các pod.
Bài viết này tập trung vào hai thiết lập quan trọng trong Kubernetes: CPU và Memory. Thiết lập giới hạn cho container có thể tiêu thụ và các best practices cho việc xác định tài nguyên cần thiết cho Container.
Cách cấu hình
Cách cấu hình trên deployment với thông số Request và Limit cho Pod với cả CPU và Memory
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:latest
resources:
requests:
memory: "256Mi" # Request 256 megabytes of memory
cpu: "500m" # Request 500m CPU core
limits:
memory: "512Mi" # Limit memory usage to 512 megabytes
cpu: "1000m" # Limit CPU usage to 100m CPU core
Thực hiện
kubectl apply -f sample.yaml
kubectl describe deployment.apps/my-deployment
Trong ví dụ, chúng ta xác định Deployment có tên là “my-deployment” 2 replicas (bản sao).
- Bên Template của pod, chúng ta chỉ định Image và tên của container.
- Tại phần resources, chúng ta thiết lập Request CPU và Memory bằng các trường requests và limits
Hình ảnh mô tả
Lưu ý:
- Pod nginx sẽ bị OOM kill nếu tài nguyên sử dụng vượt quá 512 megabytes of memory
- Pod sẽ bị CPU throttle nếu thời gian sử dụng CPU vượt quá 1000m
Về Kubernetes Requests
Kubernetes sẽ xác định yêu cầu (requests) là tài nguyên tối thiếu và đảm bảo cấp đủ tài nguyên đó cho pod / container có thể sử dụng.
Khi lập lịch Pod vào các Worker node, kube-scheduler sẽ kiểm tra CPU, Memory Request của Pod và tìm các Worker node có thể bảo đảm số lượng tài nguyên cho Pod.
resources:
requests:
memory: "256Mi" # Request 256 megabytes of memory
cpu: "500m" # Request 500m CPU core
Về Kubernetes Limits
Kubernetes sẽ xác định số lượng tài nguyên tối đa (limits) mà Pod / Container có thể sử dụng.
Điều đó bảo đảm Pod / Container không thể sử dụng vượt quá lượng tài nguyên đã chỉ định
limits:
memory: "512Mi" # Limit memory usage to 512 megabytes
cpu: "1000m" # Limit CPU usage to 100m CPU core
Về tham số CPU
CPU có thể co dãn để đáp ứng nhu câu của Pod, ví dụ khi Pod A sử dụng quá nhiều tài nguyên, các Pod B, C cùng Worker node có thể sẽ phải chờ để được xử lý, việc chờ xử lý có thể gây giật, lag, chễ khi xử lý request từ người dùng
1 core CPU sẽ được qui đổi thành millicores (m), ví du CPU có 2 core, tức sẽ có 2000m computing processing time
Về tham số Memory
Tham số Memory không thể co dãn, điều này dẫn tới nếu Pod / Container / Process sử dụng nhiều hơn số Limit Memory được cấp, tiến trình sẽ bị killed Memory được tính dựa trên bytes
Các giá trị có thể sử dụng “E, P, T, G, M, k”, đại diện cho Exabyte, Petabyte, Terabyte, Gigabyte, Megabyte, kilobyte,(e.g., 500M, 4G) Lưu ý:
- Nếu sử dụng “M” for memory (Đại diện cho Megabyte)
- Nếu sử dụng “m” for memory (Đại diện cho Millibytes)
Ví dụ minh họa
Ví dụ: Cluster có 2 Worker cấu hình 4 CPU, 8 GB Ram, Cluster sẽ qui đổi lượng tài nguyên thành:
- Worker Node 01: 4000m CPU và 8096 MB Memory
- Worker Node 02: 4000m CPU và 8096 MB Memory
- Khi chúng ta tạo các 01 Pod có tham số Request 1000m CPU, 2 GB Memory thì Worker Node 01 sẽ trừ số lượng tài nguyên có thể cấp phát là: 3000m CPU và 6144 MB Memory
- Khi có thêm Pod được Schedule lên Worker thì lượng tài nguyên trên Worker node sẽ giảm xuống
- Khi không còn đủ tài nguyên trên Worker node thì các Pod sẽ bị trạng thái Pending và khi đó chúng tả phải bổ sung thêm Worker Node vào Cluster
Đơn giản, nó sẽ thiết lập mức tối thiểu của tài nguyên mà container cần tiêu thụ.
Khi một Pod được lên lịch, kube-scheduler sẽ kiểm tra các yêu cầu Kubernetes để gán nó cho một Node cụ thể có thể đảm bảo ít nhất mức yêu cầu đó cho tất cả các container trong Pod. Nếu lượng tài nguyên được yêu cầu cao hơn so với tài nguyên có sẵn, Pod sẽ không được lên lịch và sẽ ở trạng thái Pending.
Best practices áp dụng cho K8S
1. Đối với các ứng dụng quan trọng, không sử dụng tham số CPU Limits
Việc set tham số CPU Limit sẽ dẫn tới khi dịch vụ quá tải, dịch vụ sẽ gặp hiện tượng nghẽn, việc xác định nghẽn sẽ đỏi hỏi phải giám sát sâu ứng dụng và rất khó nhận diện.
2. Đối với các ứng dụng quan trọng, luôn set tham số Memory Requests bằng Memory Limits và nhóm trên cùng 1 tập Worker Node
Việc set tham số Memory Requests = Memory Limits sẽ bảo đảm Pod luôn có đủ tài nguyên chạy trên Worker Node mà không phải tranh chấp với các Pod khác tại cùng Worker Node. Việc này cũng sẽ hạn chế tối đa việc 1 Pod dịch vụ A bất thường gây ảnh hướng tới các Pod B và C cùng node
Tham khảo
https://sysdig.com/blog/kubernetes-limits-requests/
https://loft.sh/blog/how-to-set-up-kubernetes-requests-and-limits/
https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
https://home.robusta.dev/blog/kubernetes-memory-limit
Lời kết
Tới đây đã kết thúc bài viết, về các tham số OOM, Throttling, hoặc Autoscale dựa trên lượng tài nguyên của Worker, mình sẽ viết trong seri sắp tới.
Cám ơn các bạn đã quan tâm.
Trân trọng.
Leave a Reply