旅游网站建设问题,百度域名多少钱,个人备案网站做淘宝客可以用吗,程序员网站需要多少钱开头语
写在前面#xff1a;如有问题#xff0c;以你为准#xff0c;
目前24年应届生#xff0c;各位大佬轻喷#xff0c;部分资料与图片来自网络
内容较长#xff0c;页面右上角目录方便跳转
简介
当多个用户或团队共享具有固定节点数目的集群时#xff0c;人们会…
开头语
写在前面如有问题以你为准
目前24年应届生各位大佬轻喷部分资料与图片来自网络
内容较长页面右上角目录方便跳转
简介
当多个用户或团队共享具有固定节点数目的集群时人们会担心 有人使用超过其基于公平原则所分配到的资源量 。资源配额是帮助管理员解决这一问题的工具。 资源配额通过 ResourceQuota 对象来定义对每个命名空间的资源消耗总量提供限制。 它可以 限制 命名空间中 某种类型的对象的总数目上限也可以限制命令空间中的 Pod 可以使用的计算资源的总上限。 资源配额的工作方式如下 不同的团队可以在不同的命名空间下工作目前这是非约束性的在未来的版本中可能会通过 ACL (Access Control List 访问控制列表) 来实现强制性约束。集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象当用户在命名空间下创建资源如 Pod、Service 等时Kubernetes 的配额系统会跟踪集群的资源使用情况以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。如果资源创建或者更新请求违反了配额约束那么该请求会报错HTTP 403 FORBIDDEN 并在消息中给出有可能违反的约束。如果命名空间下的计算资源 如 cpu 和 memory的配额被启用则用户必须为 这些资源设定请求值request和约束值limit否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。
ResourceQuota 是一个准入控制插件默认已启用
kubectl exec kube-apiserver-master -n kube-system -- kube-apiserver -h | grep enable-admission-plugins | grep ResourceQuota 括号内是默认启用 yaml 介绍
官方文档
资源配额 | Kubernetes
apiVersion: v1kind: ResourceQuotametadata:name: storagenamespace: default # 限制 default 名称空间spec:hard: # 是每种指定资源所强制实施的硬性限制集合pods: 3 # 限制 Pod 的数量requests.cpu: 1 # 限制 pod cpu 数量requests.memory: 1Gi # 限制 内存使用量requests.storage: 10G # 限制 存储使用量used: # 是当前命名空间中所观察到的资源总用量
RQ对pod的影响
如果对某个命名空间做出了限制会导致在这个命名空间下创建的pod其配置里面就要对自身做出限制不然会创建不了导致报错
主要是满足 requests 的请求这是请求资源的最低值
requests 和 limit 区别 在调度的时候 requests 比较重要这可以帮助 Kubernetes 调度器决定在哪个节点上运行 Pod
在运行的时候 limits 比较重要, 这有助于确保容器不会无限制地使用资源。 当设置 limits 而没有设置 requests 时Kubernetes 默认令 requests 等于 limits
requests资源请求 定义了对应容器需要的最小资源量
requests定义了一个容器所需的最低资源量。它表示容器在正常运行时所需的资源最小值。Kubernetes调度器使用这个值来决定将容器调度到哪个节点上以确保节点上的资源能够满足容器的请求。如果节点上的资源不足以满足 requests则容器可能不会被调度到该节点。requests 对于水平伸缩Horizontal Pod Autoscaling也非常重要因为它帮助系统自动决定何时需要扩展Pod的数量。 imits资源限制定义了这个容器最大可以消耗的资源上限
limits 定义了容器能够使用的资源的上限。它表示容器在运行时不应该使用的资源量。如果容器尝试使用超过 limits 定义的资源量Kubernetes将限制容器的资源使用并可能终止容器。limits 对于防止容器占用过多的系统资源以至于影响其他容器或节点非常重要。它可以确保一个容器不会耗尽整个节点的资源从而维护整个集群的可靠性和稳定性
1对于 CPU如果 pod 中服务使用 CPU 超过设置的limitspod 不会被 kill 掉但会被限制。如果没有设置 limits pod 可以使用全部空闲的 CPU 资源。
2对于内存当一个 pod 使用内存超过了设置的limitspod 中 container 的进程会被 kernel 因 OOM kill 掉。当 container 因为 OOM 被 kill 掉时系统倾向于在其原所在的机器上重启该 container 或本机或其他重新创建一个 pod 0 requests Node Allocatable, requests limits Infinity k8s 中负载问题
1. 经常在 K8s 集群种部署负载的时候不设置 CPU requests 或将 CPU requests 设置得过低这样“看上去”就可以在每个节点上容纳更多 Pod 。在业务比较繁忙的时候节点的 CPU 全负荷运行。业务延迟明显增加有时甚至机器会莫名其妙地进入 CPU 软死锁等“假死”状态
2. 类似地部署负载的时候不设置内存 requests 或者内存 requests 设置得过低这时会发现有些 Pod 会不断地失败重启。而不断重启的这些 Pod 通常跑的是 Java 业务应用但是这些 Java 应用本地调试运行地时候明明都是正常的。
3.在 K8s 集群中集群负载并不是完全均匀地在节点间分配的通常内存不均匀分配的情况较为突出集群中某些节点的内存使用率明显高于其他节点。 K8s 作为一个众所周知的云原生分布式容器编排系统一个所谓的事实上标准其调度器不是应该保证资源的均匀分配吗 1CPU 属于可压缩资源其中 CPU 资源的分配和管理是 Linux 内核借助于完全公平调度算法 CFS 和 Cgroup 机制共同完成的
简单地讲如果 pod 中服务使用 CPU 超过设置的 CPU limits pod 的 CPU 资源会被限流 throttled 。对于没有设置limit的 pod 一旦节点的空闲 CPU 资源耗尽之前分配的 CPU 资源会逐渐减少。不管是上面的哪种情况最终的结果都是 Pod 已经越来越无法承载外部更多的请求表现为应用延时增加响应变慢对应上面1的情形
2内存属于不可压缩资源 Pod 之间是无法共享的完全独占的这也就意味着资源一旦耗尽或者不足分配新的资源一定是会失败的。有的 Pod 内部进程在初始化启动时会提前开辟出一段内存空间。比如 JVM 虚拟机在启动的时候会申请一段内存空间。如果内存
requests 指定的数值小于 JVM 虚拟机向系统申请的内存导致内存申请失败 oom-kill 从而 Pod 出现不断地失败重启。这种情形对应于上面的情形 2
3另一方面 K8s 内置的调度算法不仅仅涉及到“最小资源分配节点”还会把其他诸如 Pod 亲和性等因素考虑在内。并且 k8s 调度基于的是资源的 requests 数值而之所以往往观察到的是内存分布不够均衡是因为对于应用来说相比于其他资源内存一般是更紧缺的一类资源这种情形对应于上面的情形 3 比如当出现新的 Pod 进行调度时调度程序会根据其当时对 Kubernetes 集群的资源描述做出最佳调度决定。但是 Kubernetes 集群是非常动态的由于整个集群范围内的变化比如一个节点为了维护我们先执行了驱逐操作这个节点上的所有 Pod 会被驱逐到其他节点去但是当我们维护完成后之前的 Pod 并不会自动回到该节点上来因为 Pod 一旦被绑定了节点是不会触发重新调度的 计算资源配额
参数 资源名称 描述 limits.cpu 所有非终止状态的 Pod其 CPU 限额总量不能超过该值。 limits.memory 所有非终止状态的 Pod其内存限额总量不能超过该值。 requests.cpu 所有非终止状态的 Pod其 CPU 需求总量不能超过该值。 requests.memory 所有非终止状态的 Pod其内存需求总量不能超过该值。 hugepages- 对于所有非终止状态的 Pod针对指定尺寸的巨页请求总数不能超过此值。 cpu 与 requests.cpu 相同。 memory 与 requests.memory 相同。
yaml 示例
apiVersion: v1kind: ResourceQuotametadata:name: mem-cpunamespace: default # 限制 default 名称空间spec:hard:requests.cpu: 1requests.memory: 1Gilimits.cpu: 2limits.memory: 2Gi requests这是您为 Pod 请求的资源数量即 Pod 的最小资源需求。它用于告诉 Kubernetes 集群为您的 Pod 分配多少资源。如果您设置了 requestsKubernetes 集群将确保为 Pod 预留这些资源。这是在调度 Pod 到节点时的关键指标它确保了节点上有足够的资源可供 Pod 使用。如果节点上没有足够的资源来满足 requestsPod 可能无法被调度。 limits这是您为 Pod 设置的资源上限即 Pod 的资源使用的最大限制。它用于限制 Pod 的资源使用以防止它占用过多的资源并影响其他 Pod。如果您设置了 limitsKubernetes 集群将确保 Pod 的资源使用不会超过这些限制。如果 Pod 尝试使用超出 limits 设置的资源量它可能会被终止或受到限制。 总结一下requests 是资源的保底需求确保 Pod 有足够的资源可供使用并在调度时起作用。limits 是资源的上限用于限制 Pod 的资源使用以确保它不会超过限制。
扩展资源
除上述资源外在 Kubernetes 1.10 版本中还添加了对 扩展资源 的支持。由于扩展资源不可超量分配因此没有必要在配额中为同一扩展资源同时指定 requests 和 limits。 对于扩展资源而言目前仅允许使用前缀为 requests. 的配额项。以 GPU 拓展资源为例如果资源名称为 nvidia.com/gpu并且要将命名空间中请求的 GPU 资源总数限制为 4则可以如下定义配额 requests.nvidia.com/gpu: 4 实操
apiVersion: v1kind: Podmetadata:creationTimestamp: nulllabels:run: webname: webnamespace: testspec:containers:- image: nginx:1.17.1name: webresources:requests:cpu: 0.5memory: 256Milimits:cpu: 1memory: 512Mistatus: {}
[rootmaster cks]# kubectl create -f RQ-cpu-mem.yamlresourcequota/mem-cpu created[rootmaster cks]# kubectl get quota -n testNAME AGE REQUEST LIMITmem-cpu 13m requests.cpu: 0/1, requests.memory: 0/512Mi limits.cpu: 0/2, limits.memory: 0/1Gi[rootmaster cks]# kubectl run -n test web --imagenginx:1.17.1Error from server (Forbidden): pods web is forbidden: failed quota: mem-cpu: must specify limits.cpu for: web; limits.memory for: web; requests.cpu for: web; requests.memory for: webkubectl run -n test web --imagenginx:1.17.1 --dry-runclient -oyaml pod.yaml [rootmaster cks]# kubectl apply -f pod.yamlpod/web created[rootmaster cks]# kubectl get quota -n testNAME AGE REQUEST LIMITmem-cpu 26m requests.cpu: 500m/1, requests.memory: 256Mi/512Mi limits.cpu: 1/2, limits.memory: 512Mi/1Gi[rootmaster cks]# kubectl apply -f pod.yamlpod/web2 created[rootmaster cks]# kubectl get quota -n testNAME AGE REQUEST LIMITmem-cpu 26m requests.cpu: 1/1, requests.memory: 512Mi/512Mi limits.cpu: 2/2, limits.memory: 1Gi/1Gi[rootmaster cks]# kubectl get pod -n testNAME READY STATUS RESTARTS AGEweb 1/1 Running 0 58sweb2 1/1 Running 0 24s
存储资源配额
用户可以对给定命名空间下的 存储资源 总量进行限制。此外还可以根据相关的存储类Storage Class来限制存储资源的消耗 资源名称 描述 requests.storage 所有 PVC存储资源的需求总量不能超过该值。 persistentvolumeclaims 在该命名空间中所允许的 PVC 总量。 .storageclass.storage.k8s.io/requests.storage 在所有与 相关的持久卷申领中存储请求的总和不能超过该值。 .storageclass.storage.k8s.io/persistentvolumeclaims 在与 storage-class-name 相关的所有持久卷申领中命名空间中可以存在的持久卷申领总数。 例如如果一个操作人员针对 gold 存储类型与 bronze 存储类型设置配额 操作人员可以定义如下配额 gold.storageclass.storage.k8s.io/requests.storage: 500Gi bronze.storageclass.storage.k8s.io/requests.storage: 100Gi 在 Kubernetes 1.8 版本中本地临时存储的配额支持已经是 Alpha 功能 资源名称 描述 requests.ephemeral-storage 在命名空间的所有 Pod 中本地临时存储请求的总和不能超过此值。 limits.ephemeral-storage 在命名空间的所有 Pod 中本地临时存储限制值的总和不能超过此值。 ephemeral-storage 与 requests.ephemeral-storage相同。
注意如果所使用的是 CRI 容器运行时容器日志会被计入临时存储配额。 这可能会导致存储配额耗尽的 Pods 被意外地驱逐出节点。 参考日志架构 了解详细信息。
yaml 示例
apiVersion: v1kind: ResourceQuotametadata:name: storagenamespace: default # 限制 default 名称空间spec:hard:requests.storage: 10G
实操
apiVersion: v1kind: ResourceQuotametadata:name: storagenamespace: testspec:hard:requests.storage: 10G
[rootmaster cks]# kubectl apply -f RQ-storage.yamlresourcequota/storage created[rootmaster cks]# kubectl get quota -n testNAME AGE REQUEST LIMITmem-cpu 51m requests.cpu: 0/1, requests.memory: 0/512Mi limits.cpu: 0/2, limits.memory: 0/1Gistorage 31s requests.storage: 0/10G
apiVersion: v1kind: PersistentVolumeClaimmetadata:name: pvcnamespace: testspec:accessModes: # 访客模式- ReadWriteManyresources: # 请求空间requests:storage: 5Gi
[
rootmaster cks]# kubectl apply -f RQ-pvc.yamlpersistentvolumeclaim/pvc-rq created[rootmaster cks]# kubectl get pvc -n testNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-rq Pending 10s# pending 代表没匹配大小一样的pv[rootmaster cks]# kubectl get quota -n testNAME AGE REQUEST LIMITmem-cpu 56m requests.cpu: 0/1, requests.memory: 0/512Mi limits.cpu: 0/2, limits.memory: 0/1Gistorage 5m28s requests.storage: 5Gi/10G[rootmaster cks]# kubectl apply -f RQ-pvc.yamlError from server (Forbidden): error when creating RQ-pvc.yaml: persistentvolumeclaims pvc-rq-2 is forbidden: exceeded quota: storage, requested: requests.storage5Gi, used: requests.storage5Gi, limited: requests.storage10G# 因为重新创建会导致存储使用 10G ,k8s 认为会超过限制# 改成 4G 即可创建成功[rootmaster cks]# kubectl apply -f RQ-pvc.yamlpersistentvolumeclaim/pvc-rq-2 unchanged[rootmaster cks]# kubectl get pvc -n testNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEpvc-rq Pending 5m14spvc-rq-2 Pending 94s[rootmaster cks]# kubectl get quota -n testNAME AGE REQUEST LIMITmem-cpu 58m requests.cpu: 0/1, requests.memory: 0/512Mi limits.cpu: 0/2, limits.memory: 0/1Gistorage 7m40s requests.storage: 9Gi/10G
对象数量配额
你可以使用以下语法对所有标准的、命名空间域的资源类型进行配额设置 count/resource.group 用于非核心core组的资源。 count/resource 用于核心组的资源。 这是用户可能希望利用对象计数配额来管理的一组资源示例。 count/persistentvolumeclaimscount/servicescount/secretscount/configmapscount/replicationcontrollerscount/deployments.appscount/replicasets.appscount/statefulsets.appscount/jobs.batchcount/cronjobs.batch 相同语法也可用于自定义资源。 例如要对 example.com API 组中的自定义资源
widgets 设置配额请使用 count/widgets.example.com。 当使用 count/* 资源配额时如果对象存在于服务器存储中则会根据配额管理资源。 这些类型的配额有助于防止存储资源耗尽。例如用户可能想根据服务器的存储能力来对服务器中 Secret 的数量进行配额限制。 集群中存在过多的 Secret 实际上会导致服务器和控制器无法启动。 用户可以选择对 Job 进行配额管理以防止配置不当的 CronJob 在某命名空间中创建太多 Job 而导致集群拒绝服务。 对有限的一组资源上实施一般性的对象数量配额也是可能的。 此外还可以进一步按资源的类型设置其配额。 资源名称 描述 configmaps 在该命名空间中允许存在的 ConfigMap 总数上限。 persistentvolumeclaims 在该命名空间中允许存在的 PVC的总数上限。 pods 在该命名空间中允许存在的非终止状态的 Pod 总数上限。Pod 终止状态等价于 Pod 的 .status.phase in (Failed,Succeeded)为真。 replicationcontrollers 在该命名空间中允许存在的ReplicationController 总数上限。 resourcequotas 在该命名空间中允许存在的 ResourceQuota 总数上限。 services 在该命名空间中允许存在的 Service 总数上限。 services.loadbalancers 在该命名空间中允许存在的 LoadBalancer 类型的 Service 总数上限。 services.nodeports 在该命名空间中允许存在的 NodePort 类型的 Service 总数上限。 secrets 在该命名空间中允许存在的 Secret 总数上限。
例如pods 配额统计某个命名空间中所创建的、非终止状态的 Pod 个数并确保其不超过某上限值。 用户可能希望在某命名空间中设置 pods 配额以避免有用户创建很多小的 Pod 从而耗尽集群所能提供的 Pod IP 地址。
yaml 示例
apiVersion: v1kind: ResourceQuotametadata:name: pods-rqnamespace: default # 限制 default 名称空间spec:hard:pods: 3 # 限制 Pod 的数量count/deployments.apps:3 # 限制 deployment 的数量count/services:3 # 限制 services 的数量
注意已经创建的资源不会计入其中
实操
apiVersion: v1kind: ResourceQuotametadata:name: object-rqnamespace: test # 限制 default 名称空间spec:hard:pods: 3 # 限制 Pod 的数量 [rootmaster cks]# kubectl apply -f RQ-object.yamlresourcequota/object-rq created[rootmaster cks]# kubectl get quota -n testNAME AGE REQUEST LIMITmem-cpu 63m requests.cpu: 0/1, requests.memory: 0/512Mi limits.cpu: 0/2, limits.memory: 0/1Giobject-rq 6s pods: 0/3storage 12m requests.storage: 0/10G
---apiVersion: apps/v1 # 版本号kind: Deployment # 类型metadata: # 元数据name: rq-deployment # deployment的名称namespace: test # 命名类型spec: # 详细描述replicas: 2 # 副本数量selector: # 选择器通过它指定该控制器可以管理哪些PodmatchLabels: # Labels匹配规则app: nginx-podtemplate: # 模块 当副本数据不足的时候会根据下面的模板创建Pod副本metadata:labels:app: nginx-podspec:containers:- name: nginx # 容器名称image: nginx:1.17.1 # 容器需要的镜像地址ports:- containerPort: 80 # 容器所监听的端口resources:requests:cpu: 0.5memory: 256Milimits:cpu: 1memory: 512Mi
[rootmaster cks]# kubectl apply -f RQ-deploy.yamldeployment.apps/rq-deployment created[rootmaster cks]# kubectl get deploy -n testNAME READY UP-TO-DATE AVAILABLE AGErq-deployment 2/2 2 2 6s[rootmaster cks]# vim RQ-deploy.yaml[rootmaster cks]# kubectl get pod -n testNAME READY STATUS RESTARTS AGErq-deployment-69f7bd5dd9-gcrdc 1/1 Running 0 46srq-deployment-69f7bd5dd9-h48bw 1/1 Running 0 46s[rootmaster cks]# kubectl get quota -n testNAME AGE REQUEST LIMITmem-cpu 68m requests.cpu: 1/1, requests.memory: 512Mi/512Mi limits.cpu: 2/2, limits.memory: 1Gi/1Giobject-rq 5m15s pods: 2/3storage 18m requests.storage: 0/10G# 因为 mem-cpu 的限制所有只设置2个副本 基于优先级类PriorityClass来设置资源配额 Pod 可以创建为特定的优先级。 通过使用配额规约中的 scopeSelector 字段用户可以根据 Pod 的优先级控制其系统资源消耗。 仅当配额规范中的 scopeSelector 字段选择到某 Pod 时配额机制才会匹配和计量 Pod 的资源消耗。 如果配额对象通过 scopeSelector 字段设置其作用域为优先级类则配额对象只能 跟踪以下资源 pods cpu memory ephemeral-storage limits.cpu limits.memory limits.ephemeral-storage requests.cpu requests.memory requests.ephemeral-storage
yaml 示例
示例创建一个配额对象并将其与具有特定优先级的 Pod 进行匹配
# 集群中的 Pod 可取三个优先级类之一即 low、medium、high# 为每个优先级创建一个配额对象apiVersion: v1kind: Listitems:- apiVersion: v1kind: ResourceQuotametadata:name: pods-highspec:hard:cpu: 1000memory: 200Gipods: 10scopeSelector:matchExpressions:- operator : InscopeName: PriorityClassvalues: [high]- apiVersion: v1kind: ResourceQuotametadata:name: pods-mediumspec:hard:cpu: 10memory: 20Gipods: 10scopeSelector:matchExpressions:- operator : InscopeName: PriorityClassvalues: [medium]- apiVersion: v1kind: ResourceQuotametadata:name: pods-lowspec:hard:cpu: 5memory: 10Gipods: 10scopeSelector:matchExpressions:- operator : InscopeName: PriorityClassvalues: [low]apiVersion: v1kind: Podmetadata:name: high-priorityspec:containers:- name: high-priorityimage: ubuntucommand: [/bin/sh]args: [-c, while true; do echo hello; sleep 10;done]resources:requests:memory: 10Gicpu: 500mlimits:memory: 10Gicpu: 500mpriorityClassName: high # priorityClassName 指的是什么就优先使用这个优先级的配额约束。 LimitRange限制范围
默认情况下 Kubernetes 集群上的容器运行使用的计算资源没有限制。 使用资源配额集群管理员可以以名字空间为单位限制其资源的使用与创建。 在命名空间中一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 有人担心一个 Pod 或 Container 会垄断所有可用的资源。 LimitRange 是在命名空间内限制资源分配给多个 Pod 或 Container的策略对象例如资源额度 ResourceQuotas 设置为 requests.cpu 为 1 requests.memory 为 1Gi 但是有人的 Pod 直接设置为 requests.cpu 为 1requests.memory 为 1Gi那么其他人就不能再创建 Pod 了所以需要使用 LimitRange 对资源配额设置区间最小和最大。 一个 LimitRange限制范围 对象提供的限制能够做到 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。设置一个命名空间中对计算资源的默认申请/限制值并且自动的在运行时注入到多个 Container 中。
其中 max 对应 limits
其中 mini 对应 request
示例
为命名空间配置 CPU 最小和最大约束
apiVersion: v1kind: LimitRangemetadata:name: cpu-min-max-demo-lrnamespace: default # 限制 default 命名空间spec:limits:- max: # 对应limits的最大值cpu: 800mmemory: 1Gimin: # 对应request的最小值cpu: 200mmemory: 200Mitype: Container# Pod 中的容器的 cpu 的范围是 200m~800m# Pod 中的容器的 memory 的范围是 200mi~1Gi
配置命名空间的最小和最大内存约束
apiVersion: v1kind: LimitRangemetadata:name: mem-min-max-demo-lrnamespace: default # 限制 default 命名空间 spec:limits:- max:memory: 1Gimin:memory: 500Mi # Pod 中的容器的 memory 的范围是 500Mi~1Gitype: Container 为命名空间配置默认的内存请求和限制
apiVersion: v1kind: LimitRangemetadata:name: mem-limit-rangenamespace: default # 限制 default 命名空间 spec:limits:- default:memory: 512MidefaultRequest:memory: 256Mi # 为命名空间配置默认的内存请求和限制type: Container
限制存储消耗
apiVersion: v1kind: LimitRangemetadata:name: storagelimitsspec:limits:- type: PersistentVolumeClaimmax:storage: 2Gimin:storage: 1Gi apiVersion: v1kind: ResourceQuotametadata:name: storagequotaspec:hard:persistentvolumeclaims: 5 # 限制 PVC 数目和累计存储容量requests.storage: 5Gi
默认的 CPU 请求和限制
当您创建一个新的 Pod 并没有显式指定资源请求时Kubernetes会使用
Default Request作为默认值。这可以帮助 Kubernetes 调度器决定在哪个节点上运行 Pod
如果您没有显式指定资源限制Kubernetes会使用Default Limit作为默认值。这有助于确保容器不会无限制地使用资源
apiVersion: v1kind: LimitRangemetadata:name: cpu-limit-rangenamespace: default # 限制 default 命名空间 spec:limits:- default: # 可以与 max 一起设置cpu: 1defaultRequest:cpu: 500m # 声明了一个默认的 CPU 请求和一个默认的 CPU 限制type: Container 实操
apiVersion: v1kind: LimitRangemetadata:name: cpu-min-max-demo-lrnamespace: test # 限制 default 命名空间spec:limits:- max: # 对应limits的最大值cpu: 800mmemory: 1Gimin: # 对应request的最小值cpu: 200mmemory: 200Mitype: Container# Pod 中的容器的 cpu 的范围是 200m~800m# Pod 中的容器的 memory 的范围是 200mi~1Gi
其中 Default 参考的是 min 和 max 因为没有对 default 单独设置
[rootmaster cks]# kubectl get limits -n testNAME CREATED ATcpu-min-max-demo-lr 2023-11-06T11:42:17Z[rootmaster cks]# kubectl describe limits -n testName: cpu-min-max-demo-lrNamespace: testType Resource Min Max Default Request Default Limit Max Limit/Request Ratio---- -------- --- --- --------------- ------------- -----------------------Container cpu 200m 800m 800m 800m -Container memory 200Mi 1Gi 1Gi 1Gi -
