一、为什么需要进行资源分配和限制?

生产中可能存在如下几个核心问题：

• 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"