概述

官方文档:https://kubernetes.io/zh-cn/docs/concepts/policy/limit-range/

在 Kubernetes(K8s)中,LimitRange 是一种用于约束命名空间(Namespace)内资源配额的资源对象,主要作用是为 Pod 和容器设置资源使用的限制范围(如 CPU、内存等)。它可以定义资源的最小值、最大值、默认值以及比例限制,确保容器在合理的资源范围内运行,避免因资源分配不合理导致的集群性能问题或服务不稳定。

作用

  • 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
  • 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
  • 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
  • 设置一个命名空间中对计算资源的默认申请/限制值,并且自动的在运行时注入到多个 Container 中。
  • 在一个命名空间中,若某一个Pod或Container未设置最小和最大的资源使用量,可以为其设置默认值

配置示例

apiVersion: v1
kind: LimitRange
metadata:
name: comprehensive-limit
namespace: dev-team # 限制的namespace
spec:
limits:
# 容器级别限制
- type: Container
# 请求的最小cpu和内存限制,对应request的设置
min:
cpu: "100m"
memory: "256Mi"
# 请求的最大cpu和内存限制,对应的limits的设置
max:
cpu: "2"
memory: "4Gi"
# 默认的request设置,如果Container没有设置request,则默认使用这个值
defaultRequest:
cpu: "500m"
memory: "1Gi"
# 默认的limits设置,如果Container没有设置limit,则默认使用这个值
default:
cpu: "1"
memory: "2Gi"
# 控制request和limits设置的比例,如果request.cpu设置为1,那么limits.cpu不能超过2,
# memory同理
maxLimitRequestRatio:
cpu: "2"
memory: "1.5" # Pod级别限制
- type: Pod
max:
cpu: "4" # 整个Pod的CPU总和不得超过4核
memory: "8Gi" # 整个Pod的内存总和不得超过8GB # PVC限制
- type: PersistentVolumeClaim
min:
storage: "1Gi"
max:
storage: "20Gi"

实战案例

创建LimitRange

先创建一个namespace

[root@master ~]# kubectl create namespace sit-team
namespace/sit-team created
[root@master ~]# kubectl get ns sit-team
NAME STATUS AGE
sit-team Active 8s

创建LimitRange,namespace需要选中上一步创建的名称空间

# 定义LimitRange
[root@master ~/limits]# cat sit-limits.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: sit-team-limits
# 限制的namespace
namespace: sit-team
spec:
limits:
# 容器级别限制
- type: Container
# 请求的最小cpu和内存限制,对应request的设置
min:
cpu: "100m"
memory: "256Mi"
# 请求的最大cpu和内存限制,对应的limits的设置
max:
cpu: "1"
memory: "1Gi"
# 默认的request设置,如果Container没有设置request,则默认使用这个值
defaultRequest:
cpu: "500m"
memory: "500Mi"
# 默认的limits设置,如果Container没有设置limit,则默认使用这个值
default:
cpu: "1"
memory: "1Gi"
# 控制request和limits设置的比例,如果request.cpu设置为1,那么limits.cpu不能超过2,
# memory同理
maxLimitRequestRatio:
cpu: "2.5"
memory: "2.5" # Pod级别限制
- type: Pod
max:
# 整个Pod的CPU总和不得超过4核
cpu: "4"
# 整个Pod的内存总和不得超过8GB
memory: "8Gi" # PVC限制
- type: PersistentVolumeClaim
# 最小的存储容量
min:
storage: "1Gi"
# 最大的存储容量
max:
storage: "20Gi" # 创建limits
[root@master ~/limits]# kubectl apply -f sit-limits.yaml
limitrange/sit-team-limits created

查看LimitRange

[root@master ~/limits]# kubectl get limits -n sit-team
NAME CREATED AT
sit-team-limits 2025-05-26T03:12:30Z # 查看详情
[root@master ~/limits]# kubectl describe limits sit-team-limits -n sit-team
Name: sit-team-limits
Namespace: sit-team
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Container memory 256Mi 1Gi 500Mi 1Gi 1500m
Container cpu 100m 1 500m 1 2
Pod memory - 8Gi - - -
Pod cpu - 4 - - -
PersistentVolumeClaim storage 1Gi 20Gi - - -

创建Pod验证LimitRange

创建一个Pod,不设置request和limits

[root@master ~/limits]# cat pod-1.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
namespace: sit-team
spec:
containers:
- name: nginx-container-1
image: nginx:latest
[root@master ~/limits]# kubectl apply -f pod-1.yaml
pod/nginx-pod created # 查看一下详细信息,发现对应的limits和requests和我们配置limitRange的默认值一样
[root@master ~/limits]# kubectl describe po nginx-pod -n sit-team | grep -A 2 -Ei 'limits|requests'
Limits:
cpu: 1
memory: 1Gi
Requests:
cpu: 500m
memory: 500Mi

创建一个Pod,将limits和requests设置超出limitRange的范围,看看会发生什么

[root@master ~/limits]# cat pod-2.yaml
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod-1
namespace: sit-team
spec:
containers:
- name: nginx-container
image: nginx:latest
resources:
limits:
cpu: "2"
memory: "2Gi"
requests:
cpu: "1"
memory: "1Gi" # 创建Pod,发现创建Pod失败了
[root@master ~/limits]# kubectl apply -f pod-2.yaml
Error from server (Forbidden): error when creating "pod-2.yaml": pods "nginx-pod-1" is forbidden: [maximum cpu usage per Container is 1, but limit is 2, maximum memory usage per Container is 1Gi, but limit is 2Gi]

LimitRange使用注意事项

  • 一个命名空间中理论上可以存在多个LimitRange,但是当有多个LimitRange时,以哪一个为基准是不确定的。所以我们在一个命名空间中创建一个LimitRange即可

  • LimitRange是做的准入检查,在LimitRange创建之前已存在的Pod或容器不受影响

  • LimitRange通常和ResourceQuota结合起来使用

学习ResourceQuota可以阅读这篇文章:K8s进阶之多租户场景下的资源配额(ResourceQuota)

K8s进阶之LimitRange的更多相关文章

  1. kubernetes 故障排除、处理、预防

    kubernetes 故障排除.处理.预防 故障排除顺序和思路 第一步: 我们可以通过查看节点是否正常,一是保证 K8S API Server 是正常的,二是可以查看节点集群网络中是否存在节点异常.如 ...

  2. Kubernetes容器编排探索与实践v1.22.1-上半部分

    概述 **本人博客网站 **IT小神 www.itxiaoshen.com Kubernetes官网地址 https://kubernetes.io Kubernetes GitHub源码地址 htt ...

  3. 云原生时代之Kubernetes容器编排初步探索及部署、使用实战-v1.22

    概述 **本人博客网站 **IT小神 www.itxiaoshen.com Kubernetes官网地址 https://kubernetes.io Kubernetes GitHub源码地址 htt ...

  4. kubernetes进阶(六)k8s平滑升级

    当我们遇到K8S有漏洞的时候,或者为了满足需求,有时候可能会需要升级或者降级版本, 为了减少对业务的影响,尽量选择在业务低谷的时候来升级: 首先准备好文件:我这里选择的是内网文件服务器上下载的,请自行 ...

  5. k8s核心资源之namespace与pod污点容忍度生命周期进阶篇(四)

    目录 1.命名空间namespace 1.1 什么是命名空间? 1.2 namespace应用场景 1.3 namespacs常用指令 1.4 namespace资源限额 2.标签 2.1 什么是标签 ...

  6. K8s 资源范围管理对象 LimitRange

    默认情况下如果创建一个 Pod 没有设置 Limits 和 Requests 对其加以限制,那么这个 Pod 可能能够使用 Kubernetes 集群中全部资源, 但是每创建 Pod 资源时都加上这个 ...

  7. k8s 的pod进阶

    容器探测的具体实现方法:三种探针类型 ExecAction.TCPSocketAction.HTTPGetAction lifecycle <Object> Actions that th ...

  8. 【云计算】Docker云平台—Docker进阶

    Docker云平台系列共三讲,此为第二讲:Docker进阶 参考资料: 五个Docker监控工具的对比:http://www.open-open.com/lib/view/open1433897177 ...

  9. k8s中yaml文常见语法

    在k8s中,所有的配置都是 json格式的.但为了读写方便,通常将这些配置写成yaml 格式,其运行的时候,还是会靠yaml引擎将其转化为json,apiserver 也仅接受json的数据类型. y ...

  10. 关于PHP架构师进阶的一些思考

    相信大家都有感觉,就是当程序员写业务写了几年后,就会有想进阶的想法,技术方面当然就是架构师了,然后具体从哪些方面丰富自己才能个达到目的呢?大部分人可能会很迷茫,当然也包括我, 最近和很多大牛交流了一些 ...

随机推荐

  1. SpringBoot集成WebServlet出现自定义单servlet请求失败的问题

    一.导言 SpringBoot的真正核心是快速整合以及自动装配,所以在spring家族中springBoot不仅整合了Spring的IOC容器还兼容了WebServlet容器:这使得springBoo ...

  2. docker Get "https://registry-1.docker.io/v2/": x509: certificate is valid for

    前言 docker 在进行 build 时,报错:Get "https://registry-1.docker.io/v2/": x509: certificate is vali ...

  3. go krotos proto编译引用外部包 was not found or had errors

    前言 kratos protos 生成 pb.go 文件时,会出现引用其他 proto 文件报错 was not found or had errors,因找不到此文件而无法编译. 解决 首先我们先了 ...

  4. CAS架构与原理简介

    1. 会话与Cookie HTTP是无状态协议,客户端与服务端之间的每次通信都是独立的,而会话机制可以让服务端鉴别每次通讯过程中的客户端是否是同一个,从而保证业务的关联性. Session是服务器使用 ...

  5. 什么是swagger,一篇带你入门

    一.前言 在前后端分离开发的过程中,前端和后端需要进行api对接进行交互,就需要一个api规范文档,方便前后端的交互,但api文档不能根据代码的变化发生实时动态的改变,这样后端修改了接口,前端不能及时 ...

  6. 卸载和重装docker的方式

    查看已安装的版本 yum list installed|grep docker 卸载 [root@localhost ~]# yum -y remove containerd.io.x86_64 [r ...

  7. BUUCTF---Cipher1(playfair)

    playfair Playfair密码原理以及该题解题步骤 Playfair密码(Playfair cipher 或 Playfair square)一种替换密码,1854年由查尔斯·惠斯通(Char ...

  8. Ubuntu下RabbitVCS的安装和简单使用

    最近需要在Ubuntu下玩一段时间,但是没找类似TortoiseSVN的熟悉点的Subversion工具,无意间发现了RabbitVCS,操作上非常nice,留爪. 下载 RabbitVCS Rabb ...

  9. FireDAC开发DataSnap应用系统【1】-快储功能

    FireDAC是吧DataSnap服务器当成API来调用,而dbExpress使用IAppServer接口. 关键点: 1.客户端调用API要回传数据,那么FireDAC把数据已Stream的格式传递 ...

  10. 使用MCP C# SDK开发MCP Server + Client

    大家好,我是Edison. 近日被MCP刷屏了,刚好看到张队发了一篇文章提到MCP的官方C# SDK发布了预览版,于是手痒痒尝了一下鲜,写了一个DEMO分享给大家. MCP是什么鬼? MCP,全称是& ...