Linux Kubernetes 容器资源限制 namespace

最新推荐文章于 2023-09-06 16:20:46 发布

阿然A

最新推荐文章于 2023-09-06 16:20:46 发布

阅读量445

点赞数

本文链接：https://blog.csdn.net/weixin_45029822/article/details/108147072

版权

本文详细介绍了如何在 Kubernetes 中对容器设置资源限制，包括 CPU 和内存的 request 和 limit，以及如何为 Namespace 设置资源限制、资源配额和 Pod 配额。通过实例展示了设置不同限制后对 Pod 运行的影响，强调了限制和配额对于集群资源管理的重要性。

摘要由CSDN通过智能技术生成

一、容器资源限制

Kubernetes采用request和limit两种限制类型来对资源进行分配。

request(资源需求)：即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。
limit(资源限额)：即运行Pod期间，可能内存使用量会增加，那最多能使用多少内存，这就是资源限额。

资源类型:

CPU 的单位是核心数，内存的单位是字节。
一个容器申请0.5个CPU，就相当于申请1个CPU的一半，你也可以加个后缀m表示千分之一的概念。比如说100m的CPU，100豪的CPU和0.1个CPU都是一样的。

内存单位：

K、M、G、T、P、E 	        #通常是以1000为换算标准的。
Ki、Mi、Gi、Ti、Pi、Ei        #通常是以1024为换算标准的

 
 
 
 
 
 
  1
  2

1.内存限制示例：

[root@server1 ~]# mkdir limit
[root@server1 ~]# cd limit
[root@server1 limit]# vim pod.yaml 
[root@server1 limit]# cat pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: memory-demo
spec:
  containers:
  - name: memory-demo
    image: stress
    args:
    - --vm
    - "1"
    - --vm-bytes
    - 200M
    resources:
      requests:
        memory: 50Mi
      limits:
        memory: 100Mi

 
 
 
 
 
 
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  17
  18
  19
  20
  21
  22

上述部署文件表示容器最小需要50Mi的内存，但是最多使用100Mi的内存，该容器的镜像使用stress消耗200Mi的内存，我们运行这个pod来查看状态：

[root@server1 limit]# kubectl apply -f pod.yaml 
pod/memory-demo created
[root@server1 limit]# kubectl get pod -o wide
NAME                                      READY   STATUS      RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
memory-demo                               0/1     OOMKilled   0          33s   10.244.1.109   server2   <none>           <none>
nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running     0          27m   10.244.2.98    server3   <none>           <none>
[root@server1 limit]# kubectl get pod -o wide
NAME                                      READY   STATUS             RESTARTS   AGE   IP             NODE      NOMINATED NODE   READINESS GATES
memory-demo                               0/1     CrashLoopBackOff   2          51s   10.244.1.109   server2   <none>           <none>
nfs-client-provisioner-6b66ddf664-2qf7m   1/1     Running            0          28m   10.244.2.98    server3   <none>           <none>

 
 
 
 
 
 
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10

在这里插入图片描述
可以看出容器的状态为OOMKilled，之后变为CrashLoopBackOff，说明如果容器超过其内存限制，则会被终止。如果可重新启动，则与所有其他类型的运行时故障一样，kubelet 将重新启动它。

如果一个容器超过其内存请求，那么当节点内存不足时，它的 Pod 可能被逐出。

实验后删除：

[root@server1 limit]# kubectl delete -f pod.yaml 
pod "memory-demo" deleted

 
 
 
 
 
 
  1
  2

而当我们将容器的资源限制提升到300Mi后该pod可以正常运行：
在这里插入图片描述

2.CPU限制示例

[root@server1 limit]# vim pod1.yaml 
[root@server1 limit]# cat pod1.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: stress
    resources