集群环境
| IP | Hostname | 用途 |
|---|---|---|
| 10.20.1.139 | k8s-master01 | Master节点 |
| 10.20.1.140 | k8s-node01 | Node节点 |
| 10.20.1.141 | k8s-node02 | Node节点 |
| 10.20.1.142 | k8s-node03 | Node节点 |
一、资源限制 - 概念
备注：CPU单位换算：100m CPU，100 milliCPU 和 0.1 CPU 都相同；精度不能超过 1m。1000m CPU = 1 CPU。
官方文档
- https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/
- https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/
Kubernetes 对资源的限制实际上是通过 cgroup 来控制的，cgroup 是容器的一组用来控制内核如何运行进程的相关属性集合。针对内存、CPU和各种设备都有对应的 cgroup。
默认情况下，Pod 运行没有 CPU 和内存的限额。这意味着系统中的任何 Pod 将能够像执行 Pod 所在节点机器一样，可以消耗足够多的 CPU 和内存。一般会针对某些应用的 Pod 资源进行资源限制，这个资源限制是通过 resources 的 requests【要分配的资源】和 limits【最大使用资源】来实现的。
二、资源限制 - 特性
- 调度器在调度时并不关注各类资源在当前时刻的实际使用量，而只关心节点上部署的所有 Pod 的资源申请量之和
- 在容器内看到的始终是节点的内存，而不是容器本身的内存
- 在容器内看到的始终是节点所有的 CPU 核，而不是仅仅只是容器可用的
三、资源限制 - HPA
1. 资源限制 - 案例解析
资源清单：resource-limited-pod.yaml
apiVersion: v1
kind: Pod
metadata:
name: resource-limited-pod
spec:
containers:
- name: my-container
image: nginx:1.29.0
# 定义容器的资源请求和限制，控制 CPU 和内存的使用
resources:
requests: # 定义容器的资源请求，即容器启动时需要的最小资源量
# 容器启动时需要的最小内存量
memory: "64Mi"
# 容器启动时需要的最小CPU量（250毫核， 0.25核心）
cpu: "250m"
limits: # 定义容器的资源限制，即容器可以使用的最大资源量
# 容器可以使用的最大内存量
memory: "128Mi"
# 容器可以使用的最大CPU量（500毫核， 0.5核心）
cpu: "500m"2. 资源限制 - 案例实操
2.1 部署 metrics.server
Metrics-Server 是集群核心监控数据的聚合器。通俗地说，它存储了集群中各节点的监控数据，并且提供了 API 以供分析和使用。
HPA 需要 Metrics Server 提供 CPU 指标, Pod 的扩缩容也都是基于指标的变化动态进行的。
部署 metrics.server
参考：015-K8S-Prometheus部署及监控告警 第十一段
**Github: ** https://github.com/kubernetes-sigs/metrics-server
metrics.server 部署资源清单：components.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: metrics-server
name: metrics-server
namespace: kube-system
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
k8s-app: metrics-server
rbac.authorization.k8s.io/aggregate-to-admin: "true"
rbac.authorization.k8s.io/aggregate-to-edit: "true"
rbac.authorization.k8s.io/aggregate-to-view: "true"
name: system:aggregated-metrics-reader
rules:
- apiGroups:
- metrics.k8s.io
resources:
- pods
- nodes
verbs:
- get
- list
- watch
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
k8s-app: metrics-server
name: system:metrics-server
rules:
- apiGroups:
- ""
resources:
- nodes/metrics
verbs:
- get
- apiGroups:
- ""
resources:
- pods
- nodes
verbs:
- get
- list
- watch
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
k8s-app: metrics-server
name: metrics-server-auth-reader
namespace: kube-system
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: metrics-server
name: metrics-server:system:auth-delegator
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:auth-delegator
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
labels:
k8s-app: metrics-server
name: system:metrics-server
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:metrics-server
subjects:
- kind: ServiceAccount
name: metrics-server
namespace: kube-system
apiVersion: v1
kind: Service
metadata:
labels:
k8s-app: metrics-server
name: metrics-server
namespace: kube-system
spec:
ports:
- name: https
port: 443
protocol: TCP
targetPort: https
selector:
k8s-app: metrics-server
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
k8s-app: metrics-server
name: metrics-server
namespace: kube-system
spec:
selector:
matchLabels:
k8s-app: metrics-server
strategy:
rollingUpdate:
maxUnavailable: 0
template:
metadata:
labels:
k8s-app: metrics-server
spec:
containers:
- args:
- --cert-dir=/tmp
- --secure-port=10250
- --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
- --kubelet-use-node-status-port
- --kubelet-insecure-tls # 跳过 Kubelet TLS 验证
- --metric-resolution=15s
image: registry.k8s.io/metrics-server/metrics-server:v0.7.0
imagePullPolicy: IfNotPresent
livenessProbe:
failureThreshold: 3
httpGet:
path: /livez
port: https
scheme: HTTPS
periodSeconds: 10
name: metrics-server
ports:
- containerPort: 10250
name: https
protocol: TCP
readinessProbe:
failureThreshold: 3
httpGet:
path: /readyz
port: https
scheme: HTTPS
initialDelaySeconds: 20
periodSeconds: 10
resources:
requests:
cpu: 100m
memory: 200Mi
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
runAsNonRoot: true
runAsUser: 1000
seccompProfile:
type: RuntimeDefault
volumeMounts:
- mountPath: /tmp
name: tmp-dir
nodeSelector:
kubernetes.io/os: linux
priorityClassName: system-cluster-critical
serviceAccountName: metrics-server
volumes:
- emptyDir: {}
name: tmp-dir
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
labels:
k8s-app: metrics-server
name: v1beta1.metrics.k8s.io
spec:
group: metrics.k8s.io
groupPriorityMinimum: 100
insecureSkipTLSVerify: true
service:
name: metrics-server
namespace: kube-system
version: v1beta1
versionPriority: 100执行资源清单
# 执行资源清单，部署 metrics-server
$ kubectl apply -f components.yaml
# 查看 metrics-server 运行状态，确保处于执行中
$ kubectl get pod -n kube-system -o wide -w | grep metrics-server
metrics-server-56cfc8b678-zvqpz 1/1 Running 2 (56s ago) 2m9s 171.20.85.237 k8s-node01 <none> <none>2.2 演示 hpa 自动扩缩容
2.2.1 部署 Deployment
资源清单：hpa-deploy-demo.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: hpa-deploy-demo
spec:
replicas: 1 # 默认副本数量为1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: my-container
image: nginx:1.29.0
resources: # 定义容器的资源请求和限制，控制 CPU 和内存的使用
requests:
memory: "100Mi"
cpu: "200m"
limits:
memory: "200Mi"
cpu: "400m"
apiVersion: v1
kind: Service
metadata:
name: hpa-deploy-demo
spec:
selector:
app: myapp
ports:
- protocol: TCP
port: 80
targetPort: 80执行资源清单
# 执行资源清单，部署 Deployment 和 Service
$ kubectl delete -f hpa-deploy-demo.yaml
deployment.apps "hpa-deploy-demo" deleted
service "hpa-deploy-demo" deleted
# 查看Pod，当前仅有一个 Pod 处于运行中，与资源清单中定义Pod副本数一致
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
hpa-deploy-demo-5587d8c7c4-k578h 1/1 Running 0 9s
# 查看Service，确定 Service IP
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
hpa-deploy-demo ClusterIP 10.109.153.144 <none> 80/TCP 16s2.2.2 部署 HPA
创建 HPA
# 创建一个或更新一个 HPA 资源，自动根据 CPU 使用率（目标值为 10%）调整 hpa-deploy-demo 这个 Deployment 的 Pod 副本数，副本数范围在 2 到 10 之间
$ kubectl autoscale deployment hpa-deploy-demo --cpu-percent=10 --min=2 --max=10
horizontalpodautoscaler.autoscaling/hpa-deploy-demo autoscaled
# 查看HPA，过一会 Deployment 副本数由 1 变成 2，表示 HPA生效了
$ kubectl get hpa hpa-deploy-demo
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hpa-deploy-demo Deployment/hpa-deploy-demo 0%/10% 2 10 2 3s测试自动扩缩容
# 多打开几个终端，连续访问 Service，观察 HPA 是否自动根据CPU负载，对 Deployment 进行了扩容
$ while true; do wget -q -O- http://10.109.153.144; done
# 观察HPA运行状态（随着访问量的增加 Pod 扩容，随着访问量减少 Pod 缩容）
$ kubectl get hpa -w
NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
hpa-deploy-demo Deployment/hpa-deploy-demo <unknown>/10% 2 10 0 3s
hpa-deploy-demo Deployment/hpa-deploy-demo 16%/10% 2 10 2 13s
hpa-deploy-demo Deployment/hpa-deploy-demo 17%/10% 2 10 4 28s
hpa-deploy-demo Deployment/hpa-deploy-demo 14%/10% 2 10 4 44s
hpa-deploy-demo Deployment/hpa-deploy-demo 11%/10% 2 10 4 59s
hpa-deploy-demo Deployment/hpa-deploy-demo 7%/10% 2 10 4 75s
hpa-deploy-demo Deployment/hpa-deploy-demo 0%/10% 2 10 4 90s
hpa-deploy-demo Deployment/hpa-deploy-demo 0%/10% 2 10 4 6m4s
hpa-deploy-demo Deployment/hpa-deploy-demo 0%/10% 2 10 3 6m20s
hpa-deploy-demo Deployment/hpa-deploy-demo 0%/10% 2 10 2 6m35s2.3 HPA资源清单
kubectl autoscale deployment hpa-deploy-demo --cpu-percent=10 --min=2 --max=10上面的HPA创建命令可以转换成资源清单如下：
horizontal-pod-autoscaler.yaml
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: hpa-deploy-demo
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: hpa-deploy-demo # 关联的Deployment名称
minReplicas: 2 # 最小副本数量
maxReplicas: 10 # 最大副本数量
metrics:
- type: Resource # 指标类型为资源指标
resource:
name: cpu # 资源指标名称为CPU
target:
type: Utilization # 指标类型为利用率
averageUtilization: 10 # 目标利用率为10%2.4 HPA 操作
# 查看 HPA
kubectl get hpa
# 指定 Deployment 查看 HPA，并动态监控
kubectl get hpa hpa-deploy-demo --watch
# 删除指定的 HPA
kubectl delete hpa hpa-deploy-demo四、服务质量等级（QoS）
1. 什么是 QoS
QoS（Quality of Service）即服务质量等级，是 Kubernetes 中作用于 Pod 的重要配置机制。当 Kubernetes 创建 Pod 时，会根据容器的资源配置自动为其分配相应的 QoS 等级，这直接影响 Pod 的调度优先级和资源回收策略。
2. QoS 等级分类
Kubernetes 中的 QoS 等级分为三种：
2.1 Guaranteed（保证级）- 优先级最高
特征：Pod 中的每个容器都必须同时设置 CPU 和内存的 limits 和 requests，且对应的值必须相等。
适用场景：关键业务应用，需要稳定的资源保证。
配置示例：
spec:
containers:
- name: my-container
image: nginx:1.29.0
resources: # 定义容器的资源请求和限制，控制 CPU 和内存的使用
requests:
memory: "100Mi"
cpu: "200m"
limits:
memory: "100Mi"
cpu: "200m"如果容器的资源 requests 没有显式设置，默认与 limits 相同
2.2 Burstable（突发级）- 优先级中等
特征：Pod 中至少有一个容器设置了内存或 CPU 的 requests 或 limits，但不满足 Guaranteed 等级的要求。
适用场景：一般业务应用，允许资源使用量在一定范围内波动。
配置示例：
spec:
containers:
- name: my-container
image: nginx:1.29.0
resources: # 定义容器的资源请求和限制，控制 CPU 和内存的使用
requests:
memory: "100Mi"
limits:
memory: "200Mi"2.3 BestEffort（尽力而为级）- 优先级最低
特征：Pod 中的所有容器都没有设置任何内存或 CPU 的 limits 和 requests。
适用场景：非关键应用，对资源要求不高，可以容忍被优先回收。
配置示例：
spec:
containers:
- name: my-container
image: nginx:1.29.0
resources: {}3. QoS 的作用机制
3.1 调度优先级
- Guaranteed：最高优先级，优先分配到资源充足的节点
- Burstable：中等优先级，在满足基本资源需求的前提下调度
- BestEffort：最低优先级，通常调度到剩余资源较多的节点
3.2 资源回收策略
当节点资源不足时，Kubernetes 会按照以下顺序回收 Pod：
- 首先回收 BestEffort 级别的 Pod
- 其次回收超出
requests资源使用量的 Burstable 级别 Pod - 最后回收 Guaranteed 级别的 Pod（仅在系统组件需要资源时）
4. 查看 Pod 的 QoS 等级
使用以下命令可以查看 Pod 的 QoS 等级：
kubectl get pod <pod-name> -o yaml | grep qosClass或者使用 describe 命令：
kubectl describe pod <pod-name> | grep QoS五、LimitRange
1. 概念
LimitRange 是一种用于限制容器资源使用的配置对象。它允许集群管理员定义资源的最小和最大限制，并确保容器在这些限制范围内使用资源。
通过使用 LimitRange，可以避免容器使用过多或过少的资源，保护集群免受资源耗尽和应用程序崩溃的影响。
默认情况下， Kubernetes 集群上的容器运行使用的计算资源没有限制。 使用 Kubernetes 资源配额， 管理员（也称为 集群操作者）可以在一个指定的命名空间内限制集群资源的使用与创建。 在命名空间中，一个 Pod 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 作为集群操作者或命名空间级的管理员，你可能也会担心如何确保一个 Pod 不会垄断命名空间内所有可用的资源。
LimitRange 是限制命名空间内可为每个适用的对象类别 （例如 Pod 或 PersistentVolumeClaim） 指定的资源分配量（限制和请求）的策略对象。
一个 LimitRange（限制范围） 对象提供的限制能够做到：
- 在一个命名空间中实施对每个 Pod 或 Container 最小和最大的资源使用量的限制。
- 在一个命名空间中实施对每个 PersistentVolumeClaim 能申请的最小和最大的存储空间大小的限制。
- 在一个命名空间中实施对一种资源的申请值和限制值的比值的控制。
- 设置一个命名空间中对计算资源的默认申请/限制值，并且自动的在运行时注入到多个 Container 中。
当某命名空间中有一个 LimitRange 对象时，将在该命名空间中实施 LimitRange 限制。
2. 案例
2.1 创建 LimitRange
资源清单：limit-range.yaml
apiVersion: v1
kind: LimitRange
metadata:
name: limit-range-demo # 限制范围的名称
namespace: default # 限制范围的命名空间
spec:
limits:
- type: Pod # 限制Pod的资源
max: # 定义了 Pod 中所有容器的资源请求（requests）和限制（limits）之和的最大值。
cpu: "1" # 该 Pod 使用的 CPU 总和不能超过 1 核。
memory: "1Gi" # 该 Pod 使用的内存总和不能超过 1GiB。
min: # 定义了 Pod 中所有容器的资源请求（requests）之和的最小值
cpu: "200m" # 该 Pod 至少需要请求（requests）200 milliCPU（即 0.2 核）
memory: "100Mi" # 该 Pod 至少需要请求（requests）100 Mebibyte 内存
- type: Container # 限制Container的资源
max: # 定义了单个容器可以设置的资源限制（limits）的最大值。
cpu: 500m # 任何容器定义的 limits.cpu 都不能超过 500m（0.5核）
memory: 1Gi # 任何容器定义的 limits.memory 都不能超过 500MiB
min: # 定义了单个容器可以设置的资源请求（requests）的最小值。
cpu: 100m # 任何容器定义的 requests.cpu 都不能低于 100m（0.1 核）
memory: 100Mi # 任何容器定义的 requests.memory 都不能低于 100MiB
defaultRequest: # 默认请求值，如果一个容器被创建时没有指定 requests.cpu 或 requests.memory，系统会自动为它设置这些默认值
cpu: 200m
memory: 500Mi
default: # 默认限制值，如果一个容器被创建时没有指定 limits.cpu 或 limits.memory，系统会自动为它设置这些默认值
cpu: 500m
memory: 500Mi
maxLimitRequestRatio: # 定义了容器的最大资源限制与请求的比例。
cpu: "2" # 容器的 limits.cpu / requests.cpu 的比值不能大于 2。例如，如果 requests.cpu 是 100m，那么 limits.cpu 最大只能设为 200m
memory: "4" # 容器的 limits.memory / requests.memory 的比值不能大于 4。例如，如果 requests.memory 是 100MiB，那么 limits.memory 最大只能设为 400MiB执行资源清单
# 执行资源清单，创建 LimitRange
$ kubectl apply -f limit-range.yaml
limitrange/limit-range-demo created
# 查看有哪些 LimitRange
$ kubectl get LimitRange
NAME CREATED AT
limit-range-demo 2025-09-11T12:50:58Z
# 查看详情
$ kubectl describe LimitRange limit-range-demo
Name: limit-range-demo
Namespace: default
Type Resource Min Max Default Request Default Limit Max Limit/Request Ratio
---- -------- --- --- --------------- ------------- -----------------------
Pod cpu 200m 1 - - -
Pod memory 100Mi 1Gi - - -
Container memory 100Mi 1Gi 500Mi 500Mi 4
Container cpu 100m 500m 200m 500m 22.2 创建 Pod
2.2.1 不符合 LimitRange 要求的 Pod
资源清单：error-limit-deploy.yaml
apiVersion: v1
kind: Pod
metadata:
name: error-limited-deploy
namespace: default
spec:
containers:
- name: my-container
image: nginx:1.29.0
# 最大内存与最小内存的比值不能超过 4，这里超过了，因此资源清单执行失败
resources:
requests: # 定义容器的资源请求，即容器启动时需要的最小资源量
memory: "100Mi"
cpu: "250m"
limits: # 定义容器的资源限制，即容器可以使用的最大资源量
memory: "500Mi"
cpu: "500m"执行资源清单
$ kubectl apply -f error-limit-deploy.yaml
Error from server (Forbidden): error when creating "error-limit-deploy.yaml": pods "error-limited-deploy" is forbidden: memory max limit to request ratio per Container is 4, but provided ratio is 5.000000最大内存与最小内存的比值不能超过 4，这里是5，超过了，因此 Pod 创建失败。
2.2.2 符合 LimitRange 要求的 Pod
资源清单：right-limit-deploy.yaml
apiVersion: v1
kind: Pod
metadata:
name: error-limited-deploy
namespace: default
spec:
containers:
- name: my-container
image: nginx:1.29.0
# 最大内存与最小内存的比值不能超过 4，这里超过了，因此资源清单执行失败
resources:
requests: # 定义容器的资源请求，即容器启动时需要的最小资源量
memory: "200Mi"
cpu: "200m"
limits: # 定义容器的资源限制，即容器可以使用的最大资源量
memory: "500Mi"
cpu: "400m"执行资源清单
$ kubectl apply -f right-limit-deploy.yaml
pod/error-limited-deploy created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
error-limited-deploy 1/1 Running 0 94s六、ResourceQuota
1. 概念
ResourceQuota 是一种用于限制命名空间内资源使用的对象。它允许集群管理员对命名空间中的资源使用进行配额管理，确保不同的团队或项目之间资源的公平分配和有效利用。
使用 ResourceQuota，可以限制命名空间中的CPU、内存和其他资源的总量，防止资源滥用和浪费。
资源配额，通过 ResourceQuota 对象来定义，对每个命名空间的资源消耗总量提供限制。 它可以限制命名空间中某种类型的对象的总数目上限，也可以限制命名空间中的 Pod 可以使用的计算资源的总上限。
资源配额的工作方式如下：
- 不同的团队可以在不同的命名空间下工作。这可以通过 RBAC 强制执行。
- 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。
- 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会跟踪集群的资源使用情况， 以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。
- 如果资源创建或者更新请求违反了配额约束，那么该请求会报错（HTTP 403 FORBIDDEN）， 并在消息中给出有可能违反的约束。
- 如果命名空间下的计算资源 （如 cpu 和 memory）的配额被启用， 则用户必须为这些资源设定请求值（request）和约束值（limit），否则配额系统将拒绝 Pod 的创建。 提示: 可使用 LimitRanger 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。
简而言之，ResourceQuota 配额就是用来设置一个命名空间最多能创建多少个对象，比如能创建多少svc，能创建多少pod/deploy。
2. 案例
2.1 创建 ResourceQuota
资源清单： resource-quota.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
name: my-resource-quota
namespace: test-quota
spec:
hard: # 强制性的资源上限
requests.cpu: "20" # 该命名空间中所有 Pod 的 spec.containers[].resources.requests.cpu 之和不能超过 20 个 CPU 核心
requests.memory: 100Gi # 该命名空间中所有 Pod 的 spec.containers[].resources.requests.memory 之和不能超过 100 Gibibyte
limits.cpu: "40" # 该命名空间中所有 Pod 的 spec.containers[].resources.limits.cpu 之和不能超过 40 个 CPU 核心
limits.memory: 200Gi # 该命名空间中所有 Pod 的 spec.containers[].resources.limits.memory 之和不能超过 200 Gibibyte
pods: "1" # 在该命名空间中最多只能创建 1 个 Pod
configmaps: "10" # 最多只能创建 10 个 ConfigMap
persistentvolumeclaims: "4" # 最多只能创建 4 个 PersistentVolumeClaim (PVC)
replicationcontrollers: "20" # 最多只能创建 20 个 ReplicationController（一种老的 Pod 控制器）
secrets: "10" # 最多只能创建 10 个 Secret
services: "10" # 最多只能创建 10 个 Service
services.loadbalancers: "2" # 在所有的 Service 中，类型为 LoadBalancer 的不能超过 2 个执行资源清单
# 创建名称空间
$ kubectl create ns test-quota
namespace/test-quota created
# 执行资源清单，创建 ResourceQuota
$ kubectl apply -f resource-quota.yaml
resourcequota/my-resource-quota created
# 查看 quota 配置详情
$ kubectl describe ResourceQuota -n test-quota
Name: my-resource-quota
Namespace: test-quota
Resource Used Hard
-------- ---- ----
configmaps 1 10
limits.cpu 0 40
limits.memory 0 200Gi
persistentvolumeclaims 0 4
pods 0 1
replicationcontrollers 0 20
requests.cpu 0 20
requests.memory 0 100Gi
secrets 0 10
services 0 10
services.loadbalancers 0 22.2 创建 Pod
资源清单：test-deploy.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: test-deploy
namespace: test-quota
spec:
replicas: 1 # 默认副本数量为1
selector:
matchLabels:
app: myapp
template:
metadata:
labels:
app: myapp
spec:
containers:
- name: my-container
image: nginx:1.29.0
resources: # 定义容器的资源请求和限制，控制 CPU 和内存的使用
requests:
memory: "100Mi"
cpu: "200m"
limits:
memory: "200Mi"
cpu: "400m"执行资源清单
# 执行资源清单创建 Pod
$ kubectl apply -f test-deploy.yaml
deployment.apps/test-deploy created
# 查看Pod，当前只有一个
$ kubectl get pods -n test-quota
NAME READY STATUS RESTARTS AGE
test-deploy-5587d8c7c4-mptk4 1/1 Running 0 12s
# 给 Pod 扩容，由于在 ResourceQuota 中限制只能有1个 Pod，因此扩容会失败
$ kubectl scale deployment test-deploy --replicas=3 -n test-quota
deployment.apps/test-deploy scaled
# 监控pod，发现一直只有一个副本
$ kubectl get pods -n test-quota -w
NAME READY STATUS RESTARTS AGE
test-deploy-5587d8c7c4-mptk4 1/1 Running 0 79s参考链接
https://jimmysong.io/book/kubernetes-handbook/cluster/qos/
https://www.cnblogs.com/renshengdezheli/p/17528247.html
转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 george_95@126.com