k8s 学习笔记 - LimitRange 限制范围

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: k8s 学习笔记 - LimitRange 限制范围

前情提要

  • 在当前工作经验中,从未限制过 namespace 的资源,这次的实施工作中,使用的是第三方定制的 k8s集群,在 namespace 被创建时,因为 yaml 文件没有配置 limitsrequests 两个参数,当 yaml 文件被 apply 后,自动对 pod 配置了 LimitRange 中定义limitsrequests,结果资源不够使用,导致容器启动过程中出现 OOMKilled 报错
  • 后续在 yaml 中加上 limitsrequests 依然有报错,导致控制器无法创建 pod,原因是 LimitRange 中的 limits.maxLimitRequestRatio 配置,对于 limitsrequests 的比例有限制

开始复盘

下面两个是 k8s 官方文档

借用一下官方文档

什么是限制范围

  • LimitRange 是限制 namespace(命名空间)内可为每个适用的对象类别 (例如 PodPersistentVolumeClaim)指定的资源分配量(limitsrequests)的策略对象
  • 一个 LimitRange(限制范围)对象提供的限制能够做到:
  • 在一个 namespace(命名空间)中实施对每个 PodContainer 最小和最大的资源使用量的限制。
  • 在一个 namespace(命名空间)中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
  • 在一个 namespace(命名空间)中实施对一种资源的requests(申请值)limits(限制值)的比值的控制。
  • 设置一个 namespace(命名空间)中对计算资源的默认 requests(申请值) / limits(限制值),并且自动的在运行时注入到多个 Container 中。
  • 当某namespace(命名空间)中有一个 LimitRange 对象时,将在该namespace(命名空间)中实施 LimitRange 限制
  • LimitRange 的名称必须是合法的 DNS 子域名
资源限制和请求的约束
  1. 管理员在一个namespace(命名空间)内创建一个 LimitRange 对象。
  2. 用户在此namespace(命名空间)内创建(或尝试创建) PodPersistentVolumeClaim 等对象。
  3. 首先,LimitRanger 准入控制器对所有没有设置计算资源需求的所有 Pod(及其容器)设置默认请求值与限制值。
  4. 其次,LimitRange 跟踪其使用量以保证没有超出命名空间中存在的任意 LimitRange 所定义的最小、最大资源使用量以及使用量比值。
  5. 若尝试创建或更新的对象(PodPersistentVolumeClaim)违反了 LimitRange 的约束, 向 API 服务器的请求会失败,并返回 HTTP 状态码 403 Forbidden 以及描述哪一项约束被违反的消息。
  6. 若你在namespace(命名空间)中添加 LimitRange 启用了对 cpumemory 等计算相关资源的限制, 你必须指定这些值的请求使用量与限制使用量。否则,系统将会拒绝创建 Pod
  7. LimitRange 的验证仅在 Pod 准入阶段进行,不对正在运行的 Pod 进行验证。 如果你添加或修改 LimitRangenamespace(命名空间)中已存在的 Pod 将继续不变。
  1. 如果命名空间中存在两个或更多 LimitRange 对象,应用哪个默认值是不确定的

实践出真知

  • 这里图省事,就直接拿 k8s 自带的 default 这个 namespace 来做演示

这里图省事,就直接部署 pod ,没有使用任何控制器(deploymentstatefulsetdaemonset 这一类)

  • 如果是控制器启动的,以下创建 pod 失败的场景,通过 kubectl get pod 命令会查看不到 pod 被创建的,使用 kubectl describe <控制器名称> 命令能查看到同理的报错
  • 以下的示例都是拿 cpu 做演示,内存是同理的
场景1

pod 配置的 requests 超出了 LimitRange 配置的 limits

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default: # 此处定义默认限制值(limits)
      cpu: 500m
    defaultRequest: # 此处定义默认请求值(requests)
      cpu: 500m
    type: Container
EOF

可以通过 kubectl get limitrange 命令查看是否创建成功

创建一个 pod 来验证

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox:1.28.3
    command:
      - sleep
      - "36000"
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        cpu: 700m
  restartPolicy: Always
EOF

这个时候就会有报错出现 The Pod "busybox" is invalid: spec.containers[0].resources.requests: Invalid value: "700m": must be less than or equal to cpu limit

  • 只需要把 cpu: 700m 调小一点,低于 limitrange 里面配置的 default 就可以重新运行 pod 了
场景2

继续使用场景1limitrange ,但是创建的 pod 同时配置了 limitsrequests ,并且均超过 limitrange 里面配置的资源限制

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-resource-limits-requests
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox:1.28.3
    command:
      - sleep
      - "36000"
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        cpu: 700m
      requests:
        cpu: 700m
  restartPolicy: Always
EOF

此时,pod 是可以被创建的

场景3

继续使用场景1limitrange ,但是创建的 pod 没有配置 limitsrequests

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-no-resource-set
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox:1.28.3
    command:
      - sleep
      - "36000"
    imagePullPolicy: IfNotPresent
  restartPolicy: Always
EOF

pod 是肯定可以创建的,并且会自动给 pod 赋值 limitsrequests

kubectl get pod busybox-no-resource-set -o yaml | grep 'resources' -A 4

可以看出来,limitsrequests 都是 limitrange 内配置的 500m

    resources:
      limits:
        cpu: 500m
      requests:
        cpu: 500m
场景4

继续使用场景1limitrange ,但是创建的 pod 只配置了 limits ,并且比 limitrange 里面的值要高

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-just-limits
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox:1.28.3
    command:
      - sleep
      - "36000"
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        cpu: 700m
  restartPolicy: Always
EOF

pod 可以被成功创建,且 requests 被赋值和 limits 的值一致

kubectl get pod busybox-just-limits -o yaml | grep 'resources' -A 4
    resources:
      limits:
        cpu: 700m
      requests:
        cpu: 700m
场景5
  • 这里图省事,就拿内存来做示例了
  • limitrange 配置了 maxLimitRequestRatio,创建的 podlimits/requests 的值不等于 1
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: LimitRange
metadata:
  name: cpu-resource-constraint
spec:
  limits:
  - default: # 此处定义默认限制值(limits)
      memory: 256Mi
    defaultRequest: # 此处定义默认请求值(requests)
      memory: 256Mi
    maxLimitRequestRatio: # 此处定义 limits/requests 的值必须等于 1
      memory: 1
    type: Container
EOF

创建一个 pod 来验证

cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Pod
metadata:
  name: busybox-ratio-ne-one
  namespace: default
spec:
  containers:
  - name: busybox
    image: busybox:1.28.3
    command:
      - sleep
      - "36000"
    imagePullPolicy: IfNotPresent
    resources:
      limits:
        memory: 700Mi
      requests:
        memory: 70Mi
  restartPolicy: Always
EOF

这个 pod 是无法被创建的,会返回 Error from server (Forbidden): error when creating "STDIN": pods "busybox-ratio-ne-one" is forbidden: memory max limit to request ratio per Container is 1, but provided ratio is 10.000000 这样的报错

这个 10.000000 就是 700/70=10 得来的

只需要把 limits 和 requests 的值改成一样的,就可以成功启动 pod 了

学习总结

  • namespace 配置了 limitrange ,并且 pod 创建时没有指明 limits 或/和 requests 时,pod 被创建后由 limitrang 的配置来指明 podlimits 或/和 requests
  • namespace 配置了 limitrange ,并且 pod 创建时的 requests 超出了 limitrange 配置的 limits 时,会有报错 must be less than or equal to xxx limit

namespace 配置了 limitrange 以及 maxLimitRequestRatio ,并且 pod 创建时的 limits/requests 值大于 maxLimitRequestRatio 配置的值,会有报错 is forbidden: xxx max limit to request ratio per Container is xxx, but provided ratio is xxx

关于 limitsrequestsmaxLimitRequestRatio 的取值,主要是围绕 cpumemroy 的单位来的

  • 在 k8s 中,cpu的单位为m1000m=1核
  • 0.1m 将向上取整为 1m
  • 在 k8s 中,memory 的单位为 k | M | G | T | P | E 或者 Ki | Mi | Gi | Ti | Pi | Ei
  • 区别在于换算不同,一个是1:1000,另一个是1:1024
  • 1m 表示 1000k
  • 1Mi 表示 1024k
  • 程序员眼中的整数,必须是 1024
  • 最后,大家也可以去验证,当 memory 这里写 1.5 的时候,pod 创建完,再去 get -o yaml,就会发现 1.5 变成了 1500m
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
6月前
|
Kubernetes Docker 容器
Kubernetes学习笔记-Part.06 Docker安装
Part.01 Kubernets与docker Part.02 Docker版本 Part.03 Kubernetes原理 Part.04 资源规划 Part.05 基础环境准备 Part.06 Docker安装 Part.07 Harbor搭建 Part.08 K8s环境安装 Part.09 K8s集群构建 Part.10 容器回退
67 1
|
3月前
|
Prometheus Kubernetes 网络协议
k8s学习笔记之CoreDNS
k8s学习笔记之CoreDNS
|
3月前
|
存储 Kubernetes 数据安全/隐私保护
k8s学习笔记之ConfigMap和Secret
k8s学习笔记之ConfigMap和Secret
|
3月前
|
Kubernetes jenkins 持续交付
jenkins学习笔记之二十一:k8s部署jenkins及动态slave
jenkins学习笔记之二十一:k8s部署jenkins及动态slave
|
3月前
|
存储 运维 Kubernetes
k8s学习笔记之StorageClass+NFS
k8s学习笔记之StorageClass+NFS
|
6月前
|
Kubernetes 调度 Docker
Ubantu docker学习笔记(十一)k8s基本操作
Ubantu docker学习笔记(十一)k8s基本操作
|
6月前
|
Kubernetes Linux Docker
Kubernetes学习笔记-Part.09 K8s集群构建
Part.01 Kubernets与docker Part.02 Docker版本 Part.03 Kubernetes原理 Part.04 资源规划 Part.05 基础环境准备 Part.06 Docker安装 Part.07 Harbor搭建 Part.08 K8s环境安装 Part.09 K8s集群构建 Part.10 容器回退
809 2
Kubernetes学习笔记-Part.09 K8s集群构建
|
6月前
|
存储 Kubernetes 负载均衡
k8s学习-思维导图与学习笔记
k8s学习-思维导图与学习笔记
259 1
|
6月前
|
Kubernetes Docker 容器
Kubernetes学习笔记-Part.08 安装k8s环境
Part.01 Kubernets与docker Part.02 Docker版本 Part.03 Kubernetes原理 Part.04 资源规划 Part.05 基础环境准备 Part.06 Docker安装 Part.07 Harbor搭建 Part.08 K8s环境安装 Part.09 K8s集群构建 Part.10 容器回退
104 2
|
6月前
|
Kubernetes Linux 开发工具
Kubernetes学习笔记-Part.05 基础环境准备
Part.01 Kubernets与docker Part.02 Docker版本 Part.03 Kubernetes原理 Part.04 资源规划 Part.05 基础环境准备 Part.06 Docker安装 Part.07 Harbor搭建 Part.08 K8s环境安装 Part.09 K8s集群构建 Part.10 容器回退
75 1