K8s pod优先级和 HPA水平扩缩容

一、Pod 优先级：谁更重要，谁先"上车"

优先级就是重要程度：数字越大，Pod 越重要。
有什么用：资源紧张时，重要的 Pod 能"挤掉"不重要的 Pod，保证自己能运行。
怎么用 ：先创建 PriorityClass（定义优先级名字和数值），然后在 Pod 里指定用哪个优先级。

1. 两种"抢资源"的方式

非抢占（Never）：高优先级 Pod 不会强行赶走低优先级 Pod，只能等着低优先级的自己退出或资源释放。像排队一样，前面不走了你就等着。
抢占（PreemptLowerPriority）：高优先级 Pod 没位置时，会直接踢掉一些低优先级的 Pod，腾出资源让自己运行。这就是"我比你重要，你让开"。

文档里例子：先跑一个普通 Pod，再跑高优先级 Pod，普通 Pod 直接被删了（抢占生效）；低优先级的 Pod 只能挂着等待。

抢占的内部流程（简单化）：

调度失败 → 放到"失败队列" → 模拟抢占，找谁可以被踢 → 更新抢占者信息 → 重新尝试调度 → 同时真正去删那些低优先级的 Pod。

二、节点优先级：挑个好"座位"

不是只看 Pod 谁重要，节点（服务器）本身也可以有优先级，让调度器优先选好节点。

1. 四种节点优先级类型

静态优先级：手动给节点打分，分高的优先被选。
- 例如：新硬件节点打 100 分，旧节点打 50 分。
亲和性优先级：Pod 指定"我喜欢某个标签的节点"，并且给不同节点设置不同权重，权重高的优先。
- 例如：应用希望跑在 zone-a，并且特别想跑在 node-1 上（权重 80），那 node-1 就会被优先考虑。
服务质量（QoS）优先级：根据 Pod 对资源的要求程度自动分等级。
- Guaranteed（最高级） ：CPU/内存的 requests = limits，资源完全固定，最稳定，几乎不会被杀。
- Burstable（中等） ：有 requests 但 limits 更高或没设，能临时多用资源，但资源紧张时可能会被杀。
- BestEffort（最低级） ：没有任何 requests/limits，能抢多少算多少，但资源不足时第一个被杀。
实际用 OOM 分数来实现：分数越高，越容易被杀。Guaranteed 分数很低（-998），BestEffort 分数很高（1000）。
插件优先级：写代码自定义调度逻辑，比如只让安全加固的节点获得高优先级。

三、一句话总结

Pod 优先级：数值大的 Pod 更重要，能选择是否抢占低优先级 Pod 的资源。
节点优先级：可以手动打分、靠亲和性、靠 QoS 等级、甚至写插件来决定调度器优先用哪个节点。
QoS 等级：资源配得越严格（requests = limits）越稳定，配得越松或没配，越容易被牺牲。

最终记住：Pod 优先级定谁"插队"，节点优先级定谁"受欢迎"，QoS 定谁"容易被牺牲"。

一句话总结

HPA 就是给 Kubernetes 里的工作负载（比如 Deployment）装了一个"自动挡"：它能根据业务忙不忙，自动增加或减少 Pod 的个数。忙了就多开几个 Pod 分担压力，闲了就关掉几个省钱。

1. 为什么要用 HPA？

以前：流量高峰来了，你要手动去改 Pod 数量，等流量下来了再手动改回去，很麻烦，而且反应慢。
用 HPA：设置好规则（比如 CPU 使用率超过 50% 就扩容），它就会自动帮你加机器（Pod），不用人盯着。

2. HPA 怎么知道"忙不忙"？

它需要监控数据，比如每个 Pod 的 CPU 使用率、内存，或者你自己定义的指标（比如每秒请求数 QPS）。
这些数据通过 Metrics Server （基础指标）或 自定义监控（如 Prometheus） 提供。
HPA 定期（比如每 15 秒）问一下这些系统："现在 Pod 们忙不忙？"，然后跟目标值比较，算出需要几个 Pod。

3. 怎么算目标 Pod 数量？

核心公式（大概意思）：

text
复制代码
```
期望副本数 = 当前副本数 × (当前指标值 ÷ 目标指标值)
```
比如设置目标 CPU 使用率是 50%，现在平均使用率是 100%，那就要把 Pod 数量翻倍（100% ÷ 50% = 2 倍）。
算出来可能不是整数，向上取整，比如 3.2 就变成 4 个 Pod。

4. 扩缩容的"脾气"：快速扩容，谨慎缩容

扩容要快：一旦忙起来，立马加 Pod，防止系统崩掉。
缩容要慢 ：避免流量稍微一降就关掉 Pod，过几秒又忙起来再开，来回折腾。所以缩容通常会等几分钟，确认确实不忙了才慢慢减少 Pod。

5. 可以设置哪些指标？

Resource：CPU、内存等系统资源（最常用）。
Pods：Pod 自己暴露的指标，比如 QPS。
Object：其他 Kubernetes 对象（比如 Ingress）提供的指标。
External：来自外部系统（比如消息队列长度）的指标。

6. 怎么控制扩缩容的速度？

从 Kubernetes 1.18 开始，可以精细控制：
- 每多少秒最多增加几个 Pod 或百分之多少。
- 缩容的等待窗口（比如过去 5 分钟的副本推荐里取最大值，避免波动）。
- 甚至可以禁止缩容，只扩容。

7. 有什么限制？

需要设置最小副本数 和最大副本数，防止无限扩容把集群资源耗光。
早期版本缩容不能到 0（现在某些情况可以，但依赖额外机制）。
HPA 控制器是单线程处理所有 HPA 对象，太多的话会有延迟。

举个实际例子（最简单的 CPU 扩容）：

假设你有一个 Web 服务，设置了：

最小 1 个 Pod，最大 10 个 Pod。
目标 CPU 平均使用率 50%。

现在：

流量来了，Pod CPU 涨到 80% → 80%÷50%=1.6 倍 → 当前 1 个 Pod，期望 1.6≈2 个 → 扩容到 2 个。
如果流量继续涨，2 个 Pod 的 CPU 还是 80% → 期望变成 2×1.6≈4 个 → 扩容到 4 个。
流量降下来，Pod CPU 降到 30% → 30%÷50%=0.6 倍 → 期望 4×0.6≈3 个，但缩容要等几分钟才执行。

总结成一句话人话：

HPA 就是一个自动调节 Pod 数量的开关，你告诉它"忙到什么程度加人，闲到什么程度减人"，它就会自己动手，省时省钱又省心。

K8s pod优先级 和 HPA水平扩缩容