前言
為了防止容器調度到資源不足的節點上，可以為容器指定資源最少要求量，
為了防止容器無節制的使用 CPU、記憶體 等資源，可以為容器指定資源最大允許使用量，
更新歷史
- 20200714 - 初稿 - 左程立
- 原文地址 - https://blog.zuolinux.com/2020/07/14/container-resources-request-limit.html
資源請求和資源約束
可以為容器指定資源請求量和資源約束量，
資源一般指 CPU、記憶體，
資源請求量，指容器要求節點分配的最小容量，如果該節點可用容量小于容器要求的請求量，容器將被調度到其他合適節點，
資源約束量，指容器要求節點限制其使用的最大容量，如果容器記憶體使用量超過內容約束量，容器將被殺掉，如果指定了重啟策略，容器殺掉后將被重啟，
涉及的引數
約束量
spec.containers[].resources.limits.cpu
spec.containers[].resources.limits.memory
spec.containers[].resources.limits.hugepages-<size>
請求量
spec.containers[].resources.requests.cpu
spec.containers[].resources.requests.memory
spec.containers[].resources.requests.hugepages-<size>
示例
apiVersion: v1
kind: Pod
metadata:
name: frontend
spec:
containers:
- name: app
image: images.my-company.example/app:v4
env:
- name: MYSQL_ROOT_PASSWORD
value: "password"
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
- name: log-aggregator
image: images.my-company.example/log-aggregator:v6
resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
資源單位
K8S 中的一個 cpu 等于云平臺上的 1 個 vCPU/核或裸機 Intel 處理器上的 1 個超執行緒，
spec.containers[].resources.requests.cpu 為 0.5 的容器肯定能夠獲得請求 1 CPU 的容器的一半 CPU 資源，運算式 0.1 等價于運算式 100m， 可以看作 “100 millicpu”，具有小數點（如 0.1）的請求由 API 轉換為 100m；最大精度是 1m，
優先考慮使用 100m 的形式，
記憶體可以使用E、P、T、G、M、K，也可以使用對應的 2 的冪數：Ei、Pi、Ti、Gi、Mi、Ki，
Pod 的資源請求和約束
Pod 的請求量等于內部所有容器的請求量之和，
Pod 的約束量等于內部所有容器的約束量之和，
帶資源請求的 Pod 如何調度
調度程式確保所調度的 Pod 的資源請求量小于節點的容量，
即，調度程式將查找到資源可用量充足的，可用量大于請求量的節點來放置 Pod，
帶資源約束的 Pod 如何運行
記憶體資源約束
如果容器超過其記憶體最大限制，則可能會被終止，如果容器可重新啟動，kubelet 將重新啟動容器，
如果一個容器記憶體使用量超過其記憶體請求值，那么當節點記憶體不足時，容器所處的 Pod 可能被逐出，
CPU 資源約束
每個容器可能被允許也可能不被允許使用超過其 CPU 約束的處理時間， 但是，容器不會由于 CPU 使用率過高而被殺死，
spec.containers[].resources.limits.cpu 先被轉換為 millicore 值，再乘以 100，其結果就是每 100 毫秒內容器可以使用的 CPU 時間總量，在此期間（100ms），容器所使用的 CPU 時間不會超過它被分配的時間，
默認的配額（quota）周期為 100 毫秒， CPU配額的最小精度為 1 毫秒，
如何獲知集群資源使用情況，需要通過 metrics-server 來獲取，
metrics-server
查看是否已安裝 metrics-server，以下說明沒安裝
# kubectl top node
Error from server (NotFound): the server could not find the requested resource (get services http:heapster:)
# kubectl get pods,svc,deployments -n kube-system | grep metrics-server
#
開始安裝 metrics-server
git clone https://github.com/kubernetes-incubator/metrics-server
cd metrics-server/
git checkout release-0.3
修改 metrics-server/deploy/1.8+/metrics-server-deployment.yaml
containers:
- name: metrics-server
#image: k8s.gcr.io/metrics-server/metrics-server:v0.3.6
image: registry.aliyuncs.com/google_containers/metrics-server-amd64:v0.3.6
imagePullPolicy: IfNotPresent
args:
- --cert-dir=/tmp
- --secure-port=4443
- --metric-resolution=30s
- --kubelet-preferred-address-types=InternalIP,Hostname,InternalDNS,ExternalDNS,ExternalIP
- --kubelet-insecure-tls
引數說明
--metric-resolution=30s：從 kubelet 采集資料的周期；
--kubelet-preferred-address-types：優先使用 InternalIP 來訪問 kubelet，這樣可以避免節點名稱沒有 DNS 決議記錄時，通過節點名稱呼叫節點 kubelet API 失敗的情況（未配置時默認的情況）；
--kubelet-insecure-tls：kubelet 的10250埠使用的是https協議，連接需要驗證tls證書，--kubelet-insecure-tls不驗證客戶端證書
安裝
kubectl apply -f deploy/1.8+/
再次查看，需要多等一會兒，確保采集到資料，
[root@master01 ~]# kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes"
{"kind":"NodeMetricsList","apiVersion":"metrics.k8s.io/v1beta1","metadata":{"selfLink":"/apis/metrics.k8s.io/v1beta1/nodes"},"items":[]}
[root@master01 1.8+]# kubectl top nodes
NAME CPU(cores) CPU% MEMORY(bytes) MEMORY%
master01 163m 4% 2093Mi 56%
master02 147m 3% 1638Mi 44%
master03 151m 3% 1609Mi 43%
work01 141m 3% 1084Mi 29%
work02 150m 3% 1097Mi 29%
work03 138m 3% 1471Mi 39%
[root@master01 1.8+]# kubectl top pod
NAME CPU(cores) MEMORY(bytes)
mysql-0 15m 202Mi
mysql-1 14m 191Mi
mysql-2 13m 182Mi
nfs-client-provisioner-7db698bbc9-8ph55 2m 8Mi
已經可以看到資源使用情況，
實踐記憶體限額
創建一個測驗用命名空間
# kubectl create namespace mem-example
namespace/mem-example created
創建一個最大限額 100M，但最少需要 250M 的容器
# cat memory-request-limit-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: memory-demo-2
namespace: mem-example
spec:
containers:
- name: memory-demo-2-ctr
image: polinux/stress
resources:
requests:
memory: "50Mi"
limits:
memory: "100Mi"
command: ["stress"]
args: ["--vm", "1", "--vm-bytes", "250M", "--vm-hang", "1"]
# kubectl apply -f memory-request-limit-2.yaml
pod/memory-demo-2 created
查看發現創建失敗
# kubectl get pod -n mem-example
NAME READY STATUS RESTARTS AGE
memory-demo-2 0/1 CrashLoopBackOff 3 88s
查看原因
# kubectl get pod -n mem-example -o go-template='{{range.status.containerStatuses}}{{"Container Name: "}}{{.name}}{{"\r\nLastState: "}}{{.lastState}}{{end}}' memory-demo-2
Container Name: memory-demo-2-ctr
LastState: map[terminated:map[containerID:docker://aaf41e exitCode:1 reason:OOMKilled ]]
其中有 reason:OOMKilled，說明超過了記憶體最大限額，導致了 OOM 然后被殺掉，
結束語
通過 resources.requests 和 resources.limits，可以對資源進行最少容量要求和最大容量限制，確保容器可以運行在資源充足的節點上，同時也不會由于自身占用了過多資源而影響節點上其他容器，
聯系我
微信公眾號：zuolinux_com
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/78505.html
標籤：其他