【云原生】kubernetes中容器的資源限制

1 metrics-server

2 指定內存請求和限制

3 指定 CPU 請求和限制

資源限制

在k8s中對于容器資源限制主要分為以下兩類:

內存資源限制: 內存請求（request）和內存限制（limit）分配給一個容器。我們保障容器擁有它請求數量的內存，但不允許使用超過限制數量的內存。
- 官網參考地址: 為容器和 Pod 分配內存資源 | Kubernetes
CPU 資源限制: 為容器設置 CPU request（請求） 和 CPU limit（限制）。容器使用的 CPU 不能超過所配置的限制。如果系統有空閑的 CPU 時間，則可以保證給容器分配其所請求數量的 CPU 資源。
- 官網參考地址: 為容器和 Pods 分配 CPU 資源 | Kubernetes

請求 request memory cpu :可以使用的基礎資源 100M

限制 limit memory cpu :可以使用的最大資源 200M 超過最大資源之后容器會被 kill , OOM 錯誤

1 metrics-server

官網地址: GitHub - kubernetes-sigs/metrics-server: Scalable and efficient source of container resource metrics for Kubernetes built-in autoscaling pipelines.

Kubernetes Metrics Server (Kubernetes指標服務器)，它是一個可擴展的、高效的容器資源度量源。Metrics Server 用于監控每個 Node 和 Pod 的負載（用于Kubernetes內置自動擴縮管道）。Metrics Server 從Kubelets 收集資源指標，并通過 Metrics API 在Kubernetes apiserver中公開，供 Horizontal Pod Autoscaler 和 Vertical Pod Autoscaler 使用。Metrics API 也可以通過 kubectl top 訪問，使其更容易調試自動擴縮管道。

查看 metrics-server（或者其他資源指標 API metrics.k8s.io 服務提供者）是否正在運行，請鍵入以下命令：

kubectl get apiservices

如果資源指標 API 可用，則會輸出將包含一個對 metrics.k8s.io 的引用。

NAME
v1beta1.metrics.k8s.io

安裝 metrics-server

# components.yaml
apiVersion: v1
kind: ServiceAccount
metadata:labels:k8s-app: metrics-servername: metrics-servernamespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:labels:k8s-app: metrics-serverrbac.authorization.k8s.io/aggregate-to-admin: "true"rbac.authorization.k8s.io/aggregate-to-edit: "true"rbac.authorization.k8s.io/aggregate-to-view: "true"name: system:aggregated-metrics-reader
rules:- apiGroups:- metrics.k8s.ioresources:- pods- nodesverbs:- get- list- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:labels:k8s-app: metrics-servername: system:metrics-server
rules:- apiGroups:- ""resources:- nodes/metricsverbs:- get- apiGroups:- ""resources:- pods- nodesverbs:- get- list- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:labels:k8s-app: metrics-servername: metrics-server-auth-readernamespace: kube-system
roleRef:apiGroup: rbac.authorization.k8s.iokind: Rolename: extension-apiserver-authentication-reader
subjects:- kind: ServiceAccountname: metrics-servernamespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:labels:k8s-app: metrics-servername: metrics-server:system:auth-delegator
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: system:auth-delegator
subjects:- kind: ServiceAccountname: metrics-servernamespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:labels:k8s-app: metrics-servername: system:metrics-server
roleRef:apiGroup: rbac.authorization.k8s.iokind: ClusterRolename: system:metrics-server
subjects:- kind: ServiceAccountname: metrics-servernamespace: kube-system
---
apiVersion: v1
kind: Service
metadata:labels:k8s-app: metrics-servername: metrics-servernamespace: kube-system
spec:ports:- name: httpsport: 443protocol: TCPtargetPort: httpsselector:k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:labels:k8s-app: metrics-servername: metrics-servernamespace: kube-system
spec:selector:matchLabels:k8s-app: metrics-serverstrategy:rollingUpdate:maxUnavailable: 0template:metadata:labels:k8s-app: metrics-serverspec:containers:- args:- --cert-dir=/tmp- --secure-port=4443- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname- --kubelet-use-node-status-port- --metric-resolution=15s- --kubelet-insecure-tls #修改去掉證書驗證image: dyrnq/metrics-server:v0.6.2 #修改官方無法下載imagePullPolicy: IfNotPresentlivenessProbe:failureThreshold: 3httpGet:path: /livezport: httpsscheme: HTTPSperiodSeconds: 10name: metrics-serverports:- containerPort: 4443name: httpsprotocol: TCPreadinessProbe:failureThreshold: 3httpGet:path: /readyzport: httpsscheme: HTTPSinitialDelaySeconds: 20periodSeconds: 10resources:requests:cpu: 100mmemory: 200MisecurityContext:allowPrivilegeEscalation: falsereadOnlyRootFilesystem: truerunAsNonRoot: truerunAsUser: 1000volumeMounts:- mountPath: /tmpname: tmp-dirhostNetwork: true ?#必須指定這個才行nodeSelector:kubernetes.io/os: linuxpriorityClassName: system-cluster-criticalserviceAccountName: metrics-servervolumes:- emptyDir: {}name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:labels:k8s-app: metrics-servername: v1beta1.metrics.k8s.io
spec:group: metrics.k8s.iogroupPriorityMinimum: 100insecureSkipTLSVerify: trueservice:name: metrics-servernamespace: kube-systemversion: v1beta1versionPriority: 100

$ kubectl appply -f components.yaml

2 指定內存請求和限制

官網: 為容器和 Pod 分配內存資源 | Kubernetes

為容器指定內存請求，請在容器資源清單中包含 resources：requests 字段。同理，要指定內存限制，請包含 resources：limits。

# nginx-memory-demo.yaml
#內存資源的基本單位是字節（byte）。你可以使用這些后綴之一，將內存表示為 純整數或定點整數：E、P、T、G、M、K、Ei、Pi、Ti、Gi、Mi、Ki。 例如，下面是一些近似相同的值：128974848, 129e6, 129M, 123Mi

apiVersion: v1
kind: Pod
metadata:name: nginx-memory-demo
spec:containers:- name: nginx-memory-demoimage: nginx:1.19resources:requests:memory: "100Mi" limits:memory: "200Mi"

查看容器內存使用情況

$ kubectl get pod nginx-memory-demo --output=yaml

查看容器正在使用內存情況

$ kubectl top pod nginx-memory-demo

內存請求和限制的目的

通過為集群中運行的容器配置內存請求和限制，你可以有效利用集群節點上可用的內存資源。通過將 Pod 的內存請求保持在較低水平，你可以更好地安排 Pod 調度。通過讓內存限制大于內存請求，你可以完成兩件事：
- Pod 可以進行一些突發活動，從而更好的利用可用內存。
- Pod 在突發活動期間，可使用的內存被限制為合理的數量。
沒有指定內存限制

如果你沒有為一個容器指定內存限制，則自動遵循以下情況之一：
- 容器可無限制地使用內存。容器可以使用其所在節點所有的可用內存，進而可能導致該節點調用 OOM Killer。此外，如果發生 OOM Kill，沒有資源限制的容器將被殺掉的可行性更大。
- 運行的容器所在命名空間有默認的內存限制，那么該容器會被自動分配默認限制。

3 指定 CPU 請求和限制

官網: 為容器和 Pods 分配 CPU 資源 | Kubernetes

為容器指定 CPU 請求，請在容器資源清單中包含 resources: requests 字段。要指定 CPU 限制，請包含 resources:limits。

# nginx-cpu-demo.yaml
#CPU 資源以 CPU 單位度量。小數值是可以使用的。一個請求 0.5 CPU 的容器保證會獲得請求 1 個 CPU 的容器的 CPU 的一半。 你可以使用后綴 m 表示毫。例如 100m CPU、100 milliCPU 和 0.1 CPU 都相同。 CPU 請求只能使用絕對數量，而不是相對數量。0.1 在單核、雙核或 48 核計算機上的 CPU 數量值是一樣的。

apiVersion: v1
kind: Pod
metadata:name: nginx-cpu-demo
spec:containers:- name: nginx-cpu-demoimage: nginx:1.19resources:limits:cpu: "1"requests:cpu: "0.5"

顯示 pod 詳細信息

$ kubectl get pod nginx-cpu-demo --output=yaml

顯示 pod 運行指標

$ kubectl top pod nginx-cpu-demo

CPU 請求和限制的初衷

通過配置你的集群中運行的容器的 CPU 請求和限制，你可以有效利用集群上可用的 CPU 資源。通過將 Pod CPU 請求保持在較低水平，可以使 Pod 更有機會被調度。通過使 CPU 限制大于 CPU 請求，你可以完成兩件事：
- Pod 可能會有突發性的活動，它可以利用碰巧可用的 CPU 資源。
- Pod 在突發負載期間可以使用的 CPU 資源數量仍被限制為合理的數量。
如果不指定 CPU 限制

如果你沒有為容器指定 CPU 限制，則會發生以下情況之一：
- 容器在可以使用的 CPU 資源上沒有上限。因而可以使用所在節點上所有的可用 CPU 資源。
- 容器在具有默認 CPU 限制的名字空間中運行，系統會自動為容器設置默認限制。
如果你設置了 CPU 限制但未設置 CPU 請求