kubernetes基于内存的hpa自动扩容核心依赖hpa与metrics server，通过计算pod内存请求（requests）的平均利用率（实际使用量/requests）触发扩缩容；需部署metrics server、配置autoscaling/v2 api及memory指标，并确保deployment声明memory requests。
Kubernetes 实现基于内存的水平自动扩容，核心依赖 Horizontal Pod Autoscaler（HPA）配合 Metrics Server。它不是直接“看内存总量”，而是依据 Pod 的 内存利用率百分比（即实际使用内存 / Pod 的 memory request）来触发扩缩容决策。
确保指标数据可获取
HPA 无法凭空获取内存数据，必须有指标服务支撑：
- 集群中必须部署并正常运行 Metrics Server（非默认组件，需手动安装）；
- 验证方式：执行
kubectl top pods，能列出各 Pod 的 MEMORY% 即表示就绪； - 若命令报错或无数据，HPA 将因缺少指标而处于
Waiting for metrics状态，无法工作。
配置支持内存指标的 HPA 对象
从 Kubernetes 1.10+ 开始，autoscaling/v2 或更高版本 API 支持多指标，包括内存。需显式声明 target.memoryUtilizationPercentage：
Kubernetes Security Posture Scorecard
下载
评估 Kubernetes 集群安全态势，覆盖 RBAC、工作负载安全、网络策略、基础设施即代码（IaC）、运行时监控和密钥管理等 30 项控制项……
- 使用
v2或v2beta2API 版本（v1仅支持 CPU）； - 在
spec.metrics中添加 type: Resource、resource.name: memory 的条目； - 设置
target.type: Utilization和target.averageUtilization（例如 75），代表所有 Pod 内存请求的平均使用率阈值； - 注意：该值是“利用率”，不是绝对内存值（如 512Mi），也不等于 memory limit。
理解内存利用率的计算逻辑
HPA 计算的是每个 Pod 的 内存请求（request）占比，而非限制（limit）或实际用量本身：
- 公式为：
Pod 当前内存使用量（1分钟滑动平均） ÷ 该 Pod 的 memory request； - 例如：Pod request=512Mi，当前使用 384Mi → 利用率 = 75%；
- 所有就绪 Pod 的该比率取算术平均值，与 HPA 中设定的
averageUtilization比较； - 若平均值持续超过阈值，HPA 就会按比例增加副本数（期望副本数 = ceil(当前副本数 × 当前平均利用率 ÷ 目标利用率)）。
避免常见配置陷阱
内存 HPA 容易因基础配置不当而失效：
-
Deployment 必须设置 memory request：若 Pod 没有声明
resources.requests.memory，利用率无法计算，HPA 会跳过该 Pod 或报错； - 不要只设 limit 不设 request：memory request 是利用率分母，缺失即无基准；
-
缩容有冷却期：默认缩容稳定窗口为 300 秒（5 分钟），防止抖动；可通过
behavior.scaleDown.stabilizationWindowSeconds调整； - 避免过度敏感：设太低的阈值（如 30%）可能导致频繁扩缩，建议从 60–80% 起步，结合业务压测调优。
