【k8s容器资源限制: https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits

一、k8s容器资源限制

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

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

资源类型:

  • CPU :单位是核心数
  • 内存 :单位是字节。

1.1 内存限制

【内存限制官方文档: https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-memory-resource/

内存单位:

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

mkdir limit cd limit

1)准备镜像

镜像需要:progrium/stress # 专用于增加负载的测试镜像
# 此镜像需要200Mi的内存
将镜像保存在Harbor仓库:zy.westos.org/library/stress:latest

2)创建pod,设置内存基本需求为50Mi,限额100Mi,发现调度后不能Running,处于 OOMKilled 状态,被杀死后一直重启,循环。

# pod.yml 
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
  • 如果容器超过其内存限制,则会被终止。如果可重新启动,则与所有其他类型的运行时故障一样,kubelet 将重新启动它。
  • 如果一个容器超过其内存请求,那么当节点内存不足时,它的 Pod 可能被逐出。

3)查询详细信息

kubectl describe pod memory-demo

4)删除pod,修改文件的内存限额为300Mi,执行pod.yml,容器可以Running

1.2 cpu限制

【cpu限制官方文档:https://kubernetes.io/zh/docs/tasks/configure-pod-container/assign-cpu-resource/

一个容器申请0.5个CPU,就相当于申请1个CPU的一半,你也可以加个后缀,m 表示千分之一的概念。比如说100m的CPU,100豪的CPU和0.1个CPU都是一样的。

1)创建pod(设置cpu需求为5,限额为10)本机cpu数为2,发现容器一直处于Pending状态

# pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: stress
    args:
    - -c
    - "2"
    resources:
      limits:
        cpu: "10"
      requests:
        cpu: "5"

在这里插入图片描述
每个 Container 可能被允许也可能不被允许使用超过其 CPU 约束的处理时间。 但是,容器不会由于 CPU 使用率过高而被杀死。

2)查看详细信息显示是因cpu不足的调度问题:default-scheduler,最后删除pod

kubectl describe pod cpu-demo

3)将cpu需求改为2,仍执行失败

4)将cpu需求改为1,容器Running

二、资源限制 LimitRange

【LimitRange官方文档:https://kubernetes.io/zh/docs/concepts/policy/limit-range/#%E5%90%AF%E7%94%A8-limitrange

【命名空间设置cpu和内存的限制官方文档:https://kubernetes.io/zh/docs/tasks/administer-cluster/manage-resources/

LimitRange:对单个容器进行限制

2.1 namespace的资源限制

LimitRange 在 namespace 中施加的最小和最大内存限制只有在创建和更新 Pod 时才会被应用。改变 LimitRange 不会对之前创建的 Pod 造成影响。

创建LinitRange对象,限制范围如下:

  • 设置最大内存为1G,最小内存为100M
  • 最大cpu为1,最小cpu为0.1
  • 设置cpu的默认需求0.1,限额0.5
  • 设置内存的默认需求256Mi,限额512Mi
# ns.yml 
apiVersion: v1
kind: LimitRange
metadata:
  name: limitrange-memory
spec:
  limits:
  - default:
      cpu: 0.5
      memory: 512Mi
    defaultRequest:
      cpu: 0.1
      memory: 256Mi
    max:
      cpu: 1
      memory: 1Gi
    min:
      cpu: 0.1
      memory: 100Mi
    type: Container

2.2 创建 pod 测试限制

测试1: 创建无需求的pod,可以Running

# pod.yml 
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: nginx

2)查看pod信息,发现受ns的资源限制

kubectl describe pod cpu-demo

3)删除pod
在这里插入图片描述

测试2: 创建有cpu需求及限额的pod,cpu限额超出了ns的cpu最大约束:1

1)创建失败

# pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: nginx
    resources:
      limits:
        cpu: "2"
      requests:
        cpu: "0.1"

测试3: 对于内存只设置了限额为512Mi,发现系统自动为其设置了内存需求为512Mi,等于限额

# pod.yml
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: nginx
    resources:
      limits:
        cpu: "1"
        memory: "512Mi"
      requests:
        cpu: "0.1"

2)查看信息,发现kubernetes为其自动设置了内存需求,值等于内存限额

kubectl describe pod cpu-demo

三、资源配额 ResourceQuota

【资源配额官方文档:https://kubernetes.io/zh/docs/concepts/policy/resource-quotas/

资源配额,通过 ResourceQuota 对象来定义,对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限,也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。

  • 可以用 ResourceQuota 限制命名空间中所有容器的内存请求总量。 同样你也可以限制内存限制总量、CPU 请求总量、CPU 限制总量。
  • 对所有容器进行限制

资源配额的工作方式如下:

  • 不同的团队可以在不同的命名空间下工作,目前这是非约束性的,在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。
  • 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
  • 当用户在命名空间下创建资源(如 Pod、Service 等)时,Kubernetes 的配额系统会 跟踪集群的资源使用情况,以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
  • 如果资源创建或者更新请求违反了配额约束,那么该请求会报错(HTTP 403 FORBIDDEN), 并在消息中给出有可能违反的约束。
  • 如果命名空间下的计算资源 (如 cpumemory)的配额被启用,则用户必须为 这些资源设定请求值(request)和约束值(limit),否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。

在集群容量小于各命名空间配额总和的情况下,可能存在资源竞争。资源竞争时,Kubernetes 系统会遵循先到先得的原则。

不管是资源竞争还是配额的修改,都不会影响已经创建的资源使用对象。

资源名称描述
limits.cpu所有非终止状态的 Pod,其 CPU 限额总量不能超过该值。
limits.memory所有非终止状态的 Pod,其内存限额总量不能超过该值。
requests.cpu所有非终止状态的 Pod,其 CPU 需求总量不能超过该值。
requests.memory所有非终止状态的 Pod,其内存需求总量不能超过该值。
hugepages - < size> 对于所有非终止状态的 Pod,针对指定尺寸的巨页请求总数不能超过此值。
cpu与 requests.cpu 相同。
memory与 requests.memory 相同

3.1 namespace 的资源配额

【为命名空间配置内存和 CPU 配额:https://kubernetes.io/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/

1)创建 ResourceQuota,设置了如下要求:

  • 每个容器必须有内存请求和限制,以及 CPU 请求和限制。
  • 所有容器的内存请求总和不能超过 1 GiB。
  • 所有容器的内存限制总和不能超过 2 GiB。
  • 所有容器的 CPU 请求总和不能超过 1 cpu。
  • 所有容器的 CPU 限制总和不能超过 2 cpu。
# quota.yml 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: mem-cpu-demo
spec:
  hard:
    requests.cpu: "1"
    requests.memory: 1Gi
    limits.cpu: "2"
    limits.memory: 2Gi

2)创建无请求和无限制的pod失败,

# pod.yml 
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: nginx

3)创建LimitRange或者在文件中加上需求和限制,pod可以运行(ns.yml为namespace资源限制的文件)

4)查看 ResourceQuota 的详情:输出结果显示了配额以及有多少配额已经被使用

5)在创建此命名空间下的其他pod时,计算内存及cpu是否超过剩余的配额,这里不再演示。

3.2 pod 的配额

1)创建 ResourceQuota,限制可以在namespace中运行的Pod数量

# quota.yml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: pod-demo
spec:
  hard:
    pods: "2"

2)创建一个pod时

apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo
spec:
  containers:
  - name: cpu-demo
    image: nginx

3)增加到3个pod,但是由于配额的限制,只有两个 Pod 能被成功创建,第三个创建失败

metadata:
  name: cpu-demo-1
spec:
  containers:
  - name: cpu-demo
    image: nginx
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo-2
spec:
  containers:
  - name: cpu-demo
    image: nginx
apiVersion: v1
kind: Pod
metadata:
  name: cpu-demo-3
spec:
  containers:
  - name: cpu-demo
    image: nginx

4)查看 ResourceQuota 的详情,pod限制数量被使用完
在这里插入图片描述

文章目录一、k8s容器资源限制1.1 内存限制1.2 cpu限制二、资源限制 LimitRange2.1 namespace的资源限制2.2 创建 pod 测试限制三、资源配额 ResourceQuota3.1 namespace 的资源配额3.2 pod 的配额【k8s容器资源限制:https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/#requests-and-limits】一、k8s容器
k8s容器资源限制一、基础知识(1)、资源限制(2)、资源类型二、内存限制三、cpu限制四、namespace设置资源限制(1)、设置namespace资源限制(2)、为namespace设置资源配额(3)、为namespace配置Pod配额 一、基础知识 (1)、资源限制K8s中定义Pod中运行容器有两个维度的限制资源需求:即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。如: Pod运行至少需要2G内存,1核CPU 资源限额:即运行Pod期间,可能内存使用量会增加,那最多能使用多少
超出容器内存限制 只要节点有足够的内存资源,那容器就可以使用超过其申请的内存,但是不允许容器使用超过限制资源。如果容器分配了超过限制内存,这个容器将会被优先结束。如果容器持续使用超过限制内存, 这个容器就会被终结。如果一个结束的容器允许重启,kubelet就会重启他,但是会出现其他类型的运行错误。 本实验,我们创建一个Pod尝试分配超过限制内存,下面的这个Pod的配置文档,它申请5...
Kubernetes 作为当下最流行的的容器集群管理平台,需要统筹集群整体的资源使用情况,将合适的资源分配给pod容器使用,既要保证充分利用资源,提高资源利用率,又要保证重要容器在运行周期内能够分配到足够的资源稳定运行。 配置容器资源限制 对于一个pod来说,资源最基础的2个的指标就是:CPU内存Kubernetes提供了个采用requests和li...
kubernetes提供了两种资源限制的方式:ResourceQuotaLimitRange。 其中ResourceQuota 是针对namespace做的资源限制,而LimitRange是针对namespace中的每个组件做的资源限制,如pod等。 对namespace中容器、pod等使用总和限制 ResourceQuota 对namespace中容器、pod等使用单独限制LimitRange 二。ResourceQuota 这里我们先说ResourceQu Kubernetes采用request和limit两种限制类型来对资源进行分配。 request(资源需求):即运行Pod的节点必须满足运行Pod的最基本需求才能运行Pod。 limit(资源限额):即运行Pod期间,可能内存使用量会增加,那最多能使用多少内存,这就是资源限额。 资源类型: CPU 的单位是核心数,内存的单位是字节。 一个容器申请0.5个CPU,就相当于申请1个CPU的一半,你也可以加个后缀m 表示千分之一的概念。比如说100
文章目录1. k8s容器资源限制2. 内存资源限制实例3. cpu资源限制4. namespace设置资源限制5. namespace中pod的配额6. namespace的创建、使用和删除7. 清除资源限制和配额 1. k8s容器资源限制 k8s采用request和limit两种限制类型来对资源进行分配 request(资源需求):即运行pod的节点必须满足运行pod的最基本需求才能运行pod。 limit(资源限制):即运行pod期间,可能内存使用量会增加,那最多能使用多少内存,这就是资源限额。
前面我们对K8s的基本组件与概念有了个大致的印象,并且基于K8s实现了一个初步的CI/CD流程,但对里面涉及的各个对象(如Namespace, Pod, Deployment, Service, Ingress, PVC等)及各对象的管理可能还缺乏深入的理解与实践,接下来的文章就让我们一起深入K8s的各组件内部来一探究竟吧。下图是基于个人的理解梳理的一个K8s结构图,示例了各个组件(只包含了主要组件)如何协同。 后续几篇文章围绕该图涉及组件进行整理介绍,本文主要探究Namespace及与Namespace
资源配额 ResourceQuota 当多个团队、多个用户共享使用K8s集群时,会出现不均匀资源使用,默认情况下先到先得,这时可以通过ResourceQuota来对命名空间资源使用总量做限制,从而解决这个问题。 使用流程:k8s管理员为每个命名空间创建一个或多个ResourceQuota对象,定义资源使用总量,K8s会跟踪命名空间资源使用情况,当超过定义的资源配额会返回拒绝。 ResourceQuota功能是一个准入控制插件,默认已经启用。 还可以基于存储类来控制PVC请求的总量。 计算资源
所以新手使用celery很仔细的建立文件夹名字、文件夹层级、python文件名字, 所以网上的celery博客教程虽然很多,但是并不能学会使用,因为要运行起来需要以下6个方面都掌握好,博客文字很难表达清楚或者没有写全面以下6个方面。 celery消费任务不执行或者报错NotRegistered,与很多方面有关系,如果要别人排错,至少要发以下6方面的截图, 1) 整个项目目录结构,celery的目录结构和任务函数位置,有很大影响 2) @task入参 ,用户有没有主动设置装饰器的入参 name,设置了和没设置有很大不同,建议主动设置这个名字对函数名字和所处位置依赖减小 3) celery的配置,task_queues(在3.xx叫 CELERY_QUEUES )和task_routes (在3.xx叫 task_routes) 4) celery的配置 include (在3.xx叫 CELERY_INCLUDE)或者 imports (3.xx CELERY_IMPORTS) 或者 app.autodiscover_tasks的入参 5) cmd命令行启动参数 --queues= 的值 6) 用户在启动cmd命令行时候,用户所在的文件夹。 在不规范的文件夹路径下,使用celery难度很高,一般教程都没教。 [项目文件夹目录格式不规范下的celery使用演示](https://github.com/ydf0509/celery_demo) 此国产分布式函数调度框架 https://function-scheduling-distributed-framework.readthedocs.io/zh_CN/latest/index.html , 从用法调用难度,用户所需代码量,超高并发性能,qps控频精确程度,支持的中间件类型,任务控制方式,稳定程度等19个方面全方位超过celery,任何方面都是有过之而无不及 。
快速安装pyinstaller将python程序打包exe教程、自定义图标打包 sdsnzy_9: 每一步都一样吗? Linux基础测试题(1) Deep Learning小舟: 很不错的博文,学到了,谢谢分享! 【Linux39-10】Kubernetes存储之持久卷(pv)及持久卷声明(pvc)、nfs持久化存储 不吃西红柿丶: 大佬写得很棒,忍不住夸一下呢~