kubernetes（K8s）学习笔记：第十期与第十一期核心知识点自测与详解

本自测解析针对 Kubernetes 系列第十期（集群资源与弹性（上篇）：监控与自动扩缩------Metrics Server + HPA）和第十一期（集群资源与弹性（下篇）：资源配额与限制------ResourceQuota + LimitRange）的核心内容。共 10 题，每题包含题目回顾、考查知识点、详细解答与分析，帮助读者巩固 Kubernetes 集群资源管理与自动扩缩容的核心技能。
文章索引：

kubernetes（K8s）学习笔记（第十期）：集群资源与弹性（上篇）：监控与自动扩缩------Metrics Server + HPA

kubernetes（K8s）学习笔记（第十一期）：集群资源与弹性（下篇）：资源配额与限制------ResourceQuota + LimitRange

更多自我检测系列欢迎浏览：每日知识点小问答

我的主页：AOwhisky，这里有更多运维系统性知识整理和其他有趣内容，欢迎与我一起探讨学习~

第十期：监控与自动扩缩（Metrics Server + HPA）（第 1-5 题）

题目一：Metrics Server 的作用与部署

题目：Metrics Server 在 Kubernetes 集群中的作用是什么？它与 Prometheus 这类监控系统有什么区别？部署 Metrics Server 后，可以使用哪个命令查看节点和 Pod 的资源使用情况？

考查知识点

Metrics Server 概述与作用 ------ 第十期 §1.1
Metrics Server vs 监控系统
kubectl top 命令

详细解答

Metrics Server 的作用：

从 Kubelet 的 /metrics/resource 端点采集节点和 Pod 的 CPU/内存使用指标
通过 Metrics API 将指标暴露给 Kubernetes API Server
为 Horizontal Pod Autoscaler（HPA）和 Vertical Pod Autoscaler（VPA）提供资源指标来源
为 kubectl top 命令提供数据支持

Metrics Server vs Prometheus：

对比项	Metrics Server	Prometheus
定位	核心指标管道，专为 HPA 设计	完整的监控告警体系
存储	仅缓存最新数据（内存）	持久化存储（TSDB）
查询能力	有限（仅当前值）	强大（PromQL，支持历史数据）
数据保留	不保留历史数据	可配置保留周期
适用场景	HPA 扩缩容、kubectl top	监控告警、趋势分析

重要说明 ：Metrics Server 不适用于非自动缩放目的。如需将指标转发到监控解决方案，应直接从 Kubelet 的 /metrics/resource 端点采集数据。

查看资源使用的命令：

bash 复制代码

# 查看节点资源使用
kubectl top node

# 查看 Pod 资源使用（指定命名空间）
kubectl top pod -n <namespace>

题目二：HPA 的扩容与缩容时间参数

题目：HPA 的扩容和缩容分别受哪些时间参数控制？请说明默认值和设计理念。如果希望加快扩容速度，应该调整哪个参数？

考查知识点

HPA 扩容与缩容时间参数 ------ 第十期 §2.2
设计理念

详细解答

HPA 时间参数：

参数	作用	默认值	所属组件
`--horizontal-pod-autoscaler-sync-period`	指标采样周期	15s	kube-controller-manager
`--horizontal-pod-autoscaler-initial-readiness-delay`	Pod 启动就绪等待时间	30s	kube-controller-manager
`--horizontal-pod-autoscaler-downscale-stabilization`	缩容稳定窗口期	5m	kube-controller-manager

扩容流程：

每 15 秒采集一次 CPU/内存指标
Pod 启动前 30 秒视为"启动中"，不参与 HPA 计算
扩容冷却时间：默认 45 秒（3 个采样周期）

缩容流程：

同样每 15 秒采样一次
需要指标持续低于阈值至少 5 分钟才会触发缩容
每次缩容后再次锁定 5 分钟

设计理念：

扩容要快：应对突发流量，快速增加副本
缩容要慢：避免流量抖动导致频繁扩缩，保护系统稳定性

加快扩容速度 ：调整 --horizontal-pod-autoscaler-sync-period 为更小值（如 5s），但需注意这会增加 API Server 和 Metrics Server 的负载。

题目三：HPA 基于 CPU 使用率的自动扩缩容实验

题目：请简述 HPA 基于 CPU 使用率自动扩缩容的实验步骤。HPA 的 TARGETS 列显示 <unknown> 通常是什么原因？如何解决？

考查知识点

HPA 基于 CPU 实验 ------ 第十期 §2.3
常见问题排查

详细解答

实验步骤：

创建 Deployment ：kubectl create deployment web --image=nginx
为 Pod 设置资源限制 ：在 Deployment 中添加 resources.limits.cpu: 100m
创建 HPA ：kubectl autoscale deployment web --max=5 --min=2 --cpu-percent=80
创建 Service ：kubectl expose deployment web --port=80 --target-port=80
施加 CPU 压力 ：使用 ab -n 300000 -c 100 http://<service-ip>/
观察扩容 ：kubectl get hpa -w 和 kubectl get pods -w
停止压力：观察缩容（约 5 分钟后）

TARGETS 显示 <unknown> 的原因：

Pod 未设置 resources.limits.cpu（HPA 无法计算使用率百分比）
Metrics Server 未部署或未正常工作
Pod 刚启动，指标尚未采集

解决方法：

为 Pod 配置 resources.limits.cpu
确认 Metrics Server 正常运行
等待 1-2 个采集周期后重试

验证命令：

bash 复制代码

# 查看 HPA 状态
kubectl get hpa

# 查看 HPA 详情（含事件）
kubectl describe hpa web

# 查看 Pod 资源使用
kubectl top pods

题目四：HPA 基于内存使用率的自动扩缩容实验

题目：HPA 基于内存使用率扩缩容与基于 CPU 扩缩容有何不同？如何模拟内存压力？为什么内存扩缩容比 CPU 扩缩容更复杂？

考查知识点

HPA 基于内存实验 ------ 第十期 §2.4
内存压力模拟

详细解答

主要不同点：

对比项	CPU 扩缩	内存扩缩
压力模拟	高并发请求（ab 工具）	下载大文件（占用内存响应）
HPA target 类型	`averageUtilization`	`averageUtilization`
触发条件	CPU 使用率超过阈值	内存使用率超过阈值
是否可压缩	CPU 是可压缩资源	内存是不可压缩资源

模拟内存压力的方法：

在 Worker 节点创建大文件：dd if=/dev/zero of=/www/big.img bs=1M count=200
在 Deployment 中挂载该文件到 Nginx 的 HTML 目录
使用 ab -n 300000 -c 100 http://<service-ip>/big.img 下载大文件
每次下载会占用 Pod 内存（响应体占用内存）

YAML 示例（挂载大文件）：

yaml 复制代码

volumes:
- name: big-file
  hostPath:
    path: /www
containers:
- name: nginx
  volumeMounts:
  - name: big-file
    mountPath: /usr/share/nginx/html
  resources:
    limits:
      memory: 200Mi

为什么内存扩缩更复杂：

内存是不可压缩资源，超出 limit 会导致 Pod 被 OOMKilled
内存使用率波动较大，频繁扩缩可能影响稳定性
内存回收比 CPU 慢，缩容需要更谨慎

题目五：HPA vs VPA 对比

题目：HPA（Horizontal Pod Autoscaler）和 VPA（Vertical Pod Autoscaler）的区别是什么？为什么两者不能同时开启？

考查知识点

HPA vs VPA 对比 ------ 第十期 §2.5
冲突原因

详细解答

对比项	HPA（水平扩缩容）	VPA（垂直扩缩容）
扩缩方式	增加/减少 Pod 数量	调整 CPU/内存 request/limit
是否重启 Pod	❌ 不重启	✅ 一般需要重启
适合负载	流量波动大	资源配置不合理
生效速度	快（秒级）	慢（需要重启）
稳定性	高	中
生产使用	非常普遍	较少
支持资源	CPU、内存、自定义	CPU、内存

为什么不能同时开启：

两者对同一个 Deployment 的副本数或资源限制存在冲突
HPA 决定 Pod 数量，VPA 决定 Pod 资源大小
如果同时开启，HPA 可能因为 VPA 调整了资源限制而重新计算副本数，VPA 又根据新的副本数调整资源，形成循环
Kubernetes 官方不推荐同时使用，建议二选一

最佳实践：

流量波动大的无状态服务 → HPA
资源配置不合理的服务 → VPA（需评估重启影响）
典型组合：HPA + 合理的 request/limit 设置

第十一期：资源配额与限制（ResourceQuota + LimitRange）（第 6-10 题）

题目六：ResourceQuota 与 LimitRange 的区别

题目：ResourceQuota 和 LimitRange 在 Kubernetes 资源管理中的角色分别是什么？两者如何协同工作？请用"总量"和"个体"的比喻解释。

考查知识点

ResourceQuota vs LimitRange ------ 第十一期 §3.2
两者关系

详细解答

对比项	ResourceQuota	LimitRange
作用范围	命名空间级别（资源总量）	单个资源级别（容器/Pod/PVC）
控制内容	资源用量的上限	资源请求的默认值、最小值和最大值
主要目的	防止命名空间超用	防止单个容器超用或未指定资源
是否强制	✅ 强制（超限则拒绝）	✅ 强制（不符合 min/max 则拒绝）

"总量"和"个体"比喻：

ResourceQuota 就像 "整栋楼的用水用电额度"------每个单元（命名空间）的总用水量（总 CPU/内存）不能超过某个限额。
LimitRange 就像 "每户人家的水龙头规格"------每家（每个容器）的水龙头不能太小（min）也不能太大（max），如果租户自己没装水龙头，管理员会给他一个标准的（default）。

两者协同工作：

LimitRange 确保每个 Pod 都有合理的 request/limit（避免用户忘记设置）
ResourceQuota 限制命名空间的总资源使用量（防止单个命名空间耗尽集群资源）
两者配合，实现"个体有规范，总量有上限"的资源管理体系

题目七：ResourceQuota 的配额类型与实验

题目：ResourceQuota 可以限制哪两类资源？请举例说明。如果命名空间设置了计算资源配额（如 requests.cpu），Pod 创建时必须满足什么条件？

考查知识点

ResourceQuota 配额类型 ------ 第十一期 §1.2
计算资源配额实验 ------ 第十一期 §1.4

详细解答

两类资源：

类型	说明	示例
对象数量	限制 Kubernetes 资源的数量	`pods: "2"`、`services: "3"`、`secrets: "5"`
计算资源	限制物理或虚拟资源容量	`requests.cpu: 1000m`、`limits.memory: 2048Mi`

创建 ResourceQuota 示例：

bash 复制代码

# 对象数量配额
kubectl create quota myquota --hard=pods=2,services=3,secrets=5

# 计算资源配额（YAML）
apiVersion: v1
kind: ResourceQuota
metadata:
  name: myquota
spec:
  hard:
    requests.cpu: 1000m
    requests.memory: 2048Mi
    limits.cpu: 2000m
    limits.memory: 4096Mi

计算资源配额的限制：

如果命名空间设置了 requests.cpu 或 requests.memory 配额，Pod 必须显式指定对应的 resources.requests 和 resources.limits
否则，配额系统会拒绝 Pod 创建，报错：must specify limits.cpu for: <container>

验证实验：

bash 复制代码

# 创建配额
kubectl apply -f resourcequota.yaml

# 创建未指定资源的 Pod（被拒绝）
kubectl run web --image=nginx
Error from server (Forbidden): pods "web" is forbidden: failed quota: myquota: must specify limits.cpu for: web; limits.memory for: web; requests.cpu for: web; requests.memory for: web

题目八：LimitRange 的配置字段与约束关系

题目：LimitRange 的 default、defaultRequest、max、min 四个字段分别表示什么？它们之间必须满足什么大小关系？如果 Pod 只指定了 limits.cpu=600m，LimitRange 会如何填充 requests 值？

考查知识点

LimitRange 配置 ------ 第十一期 §2.2
字段约束关系

详细解答

四个字段的含义：

字段	说明
`default`	容器未指定 `limits` 时的默认值（上限）
`defaultRequest`	容器未指定 `requests` 时的默认值
`max`	容器可使用的资源最大值
`min`	容器可使用的资源最小值

必须满足的大小关系：

text 复制代码

min <= defaultRequest <= default <= max

只指定 limits 时的行为：

requests 值会自动设置为与 limits 相同的值
而不是使用 defaultRequest
前提是 min <= limits <= max

示例：LimitRange 配置

yaml 复制代码

apiVersion: v1
kind: LimitRange
metadata:
  name: mylimit
spec:
  limits:
  - type: Container
    max:
      cpu: 1
      memory: 1Gi
    min:
      cpu: 100m
      memory: 128Mi
    default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi

Pod 只指定 limits.cpu=600m：

requests.cpu 自动设置为 600m（与 limits 相同）
而不是 200m（defaultRequest）
该值满足 100m <= 600m <= 1 ✅

题目九：LimitRange 对未指定资源的 Pod 的影响

题目：如果命名空间配置了 LimitRange，但 Pod 既未指定 requests 也未指定 limits，LimitRange 会如何处理？如果 Pod 只指定了 requests 而未指定 limits，limits 会使用什么值？

考查知识点

LimitRange 实验 ------ 第十一期 §2.3、§2.5
默认值填充逻辑

详细解答

情况一：Pod 既未指定 requests 也未指定 limits：

使用 defaultRequest 作为 requests
使用 default 作为 limits
Pod 的资源配置会被自动填充为默认值

示例：

yaml 复制代码

# Pod（未指定 resources）
spec:
  containers:
  - name: nginx
    image: nginx

# 实际创建的 Pod 资源
resources:
  requests:
    cpu: 200m
    memory: 256Mi
  limits:
    cpu: 500m
    memory: 512Mi

情况二：Pod 只指定 requests 而未指定 limits：

limits 使用 default 值
requests 使用指定的值（但必须满足 min <= requests <= max，且 requests <= limits）

示例：

yaml 复制代码

# Pod（只指定 requests）
resources:
  requests:
    cpu: 400m
    memory: 400Mi

# 实际创建的 Pod 资源
resources:
  requests:
    cpu: 400m
    memory: 400Mi
  limits:
    cpu: 500m      # 来自 default
    memory: 512Mi  # 来自 default

关键规则：

default 和 defaultRequest 只在资源未指定时起作用
如果指定了部分资源，未指定的部分才会使用默认值
min 和 max 始终生效，无论资源是否指定

题目十：生产环境配额与限制最佳实践

题目：在生产环境中，应该先配置 ResourceQuota 还是先配置 LimitRange？为什么？如果命名空间已配置 ResourceQuota 但未配置 LimitRange，用户创建 Pod 时可能遇到什么问题？

考查知识点

生产环境最佳实践 ------ 第十一期 §3.7
配额与限制协同

详细解答

配置顺序 ：先配置 LimitRange，再配置 ResourceQuota

原因：

LimitRange 确保所有 Pod 都有默认的 request/limit，避免 Pod 因未指定资源而被 ResourceQuota 拒绝
如果先配置 ResourceQuota，用户创建 Pod 时可能因未指定 resources 而报错，影响用户体验
LimitRange 的默认值可以作为 ResourceQuota 规划的参考

未配置 LimitRange 时的问题：

如果命名空间有 ResourceQuota（含计算资源配额），但未配置 LimitRange
用户创建 Pod 时必须手动为每个容器指定 resources.requests 和 resources.limits
如果用户忘记指定，Pod 会被拒绝，报错 must specify limits.cpu 等
这增加了用户的使用门槛，降低了自助化程度

生产环境推荐实践：

实践	说明
先配 LimitRange，再配 ResourceQuota	确保所有 Pod 有默认资源值，避免创建失败
设置合理的默认值	根据应用典型规格设置 default 和 defaultRequest
设置 min 和 max 防止异常	防止单个容器超用或过度预留资源
定期审查配额使用率	使用 `kubectl describe quota` 检查配额使用情况
为不同 Namespace 设置不同配额	根据团队/环境需求定制配额

附：知识点对应总表

题号	主要考查知识点（对应笔记章节）
1	第十期 §1 Metrics Server 作用与部署
2	第十期 §2.2 HPA 时间参数
3	第十期 §2.3 HPA 基于 CPU 实验
4	第十期 §2.4 HPA 基于内存实验
5	第十期 §2.5 HPA vs VPA
6	第十一期 §3.2 ResourceQuota vs LimitRange
7	第十一期 §1.2 ResourceQuota 配额类型
8	第十一期 §2.2 LimitRange 配置字段
9	第十一期 §2.3、§2.5 LimitRange 默认值填充
10	第十一期 §3.7 生产环境最佳实践

学习建议：对于答错的题目，请回看第十期或第十一期对应章节，并动手在集群环境中执行相关命令。资源监控与配额管理是 Kubernetes 集群运维的核心能力，建议通过实际操作加深理解。
--- Compiled and Authored by Whisky --- July 5 th, 2026