一、为什么需要进行资源分配和限制?¶
生产中可能存在如下几个核心问题：
- 1）服务部署过量分配资源导致资源浪费
- 2）资源设置过大的limit导致机器故障
- 3）服务下线未及时清理导致过多垃圾数据
- 4）多租户、多环境资源相互争抢
- 5）配置问题导致集群资源(Pod和rs)激增
1.1 服务部署过量分配资源导致资源浪费¶
避免资源浪费（解决过量分配问题）
-
问题：服务部署时过量分配 CPU/内存，导致资源闲置，其他应用无法利用。
-
K8s 方案：
-
资源请求（Requests）：定义 Pod 所需的最小资源量，调度器根据节点剩余资源分配。
-
资源限制（Limits）：限制 Pod 最大可用资源，避免单 Pod 过度占用。
-
示例：
yaml
containers:
- name: nginx
resources:
requests:
cpu: "100m" # 最小需要 0.1 核
memory: "128Mi"
limits:
cpu: "500m" # 最多使用 0.5 核
memory: "512Mi"
1.2 资源设置过大的limit导致机器故障¶
防止节点故障（解决 Limit 设置过大问题）
-
问题：Limit 设置过高，导致节点资源耗尽（如 OOM Kill），引发宕机。
-
K8s 方案：
-
硬性限制（Hard Limits）：通过
limits强制约束资源使用，避免节点过载。 -
资源监控与驱逐：节点资源压力大时，Kubelet 按优先级驱逐 Pod。
-
示例：
yaml
# 查看节点资源使用
kubectl top node
1.3 服务下线未及时清理导致过多垃圾数据¶
清理垃圾数据（解决服务下线残留问题）
-
问题：下线服务残留未清理的 Pod、ConfigMap、PVC 等，占用资源。
-
K8s 方案：
-
垃圾回收（Garbage Collection）：自动清理无主资源（如孤儿 Pod、未引用卷）。
-
TTL 控制器：为临时资源设置生存时间，超时自动删除。
-
示例：
yaml
# 设置 Job 的 TTL
apiVersion: batch/v1
kind: Job
metadata:
name: cleanup-job
spec:
ttlSecondsAfterFinished: 3600 # 完成后 1 小时自动删除
1.4 多租户、多环境资源相互争抢¶
保障多租户公平性（解决资源争抢问题）
-
问题：多租户/多环境共享集群时，资源竞争导致服务质量下降。
-
K8s 方案：
-
资源配额（Resource Quotas）：限制命名空间的资源总量。
-
优先级与抢占（Priority & Preemption）：高优先级 Pod 可抢占低优先级 Pod 的资源。
-
示例：
yaml
# 定义命名空间资源配额
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-a-quota
spec:
hard:
requests.cpu: "10"
requests.memory: 20Gi
pods: "50"
1.5 配置问题导致集群资源(Pod和rs)激增¶
控制资源激增（解决配置错误导致的资源爆炸）
-
问题：错误配置（如 HPA 参数错误）导致 Pod/RS 数量激增，压垮集群。
-
K8s 方案：
-
Horizontal Pod Autoscaler (HPA)：基于指标（CPU/内存）自动伸缩 Pod 数量，设置最小/最大副本数。
-
Limit Ranges：限制单个命名空间中 Pod 的资源范围。
-
示例：
yaml
# 定义 LimitRange
apiVersion: v1
kind: LimitRange
metadata:
name: pod-limits
spec:
limits:
- type: Container
max:
cpu: "2"
memory: "4Gi"