Appearance
调度、扩缩容与发布实践
这篇笔记聚焦 Kubernetes 真正体现“集群操作系统”价值的一条主线：
- Pod 为什么会被调度到某台节点
- 扩缩容到底在扩什么、缩什么
- 滚动发布和回滚解决什么问题
- 自愈和高可用到底有什么关系
1. 调度到底是什么
调度 可以理解成 Kubernetes 决定某个 Pod 应该运行在哪一台节点上的过程。
它解决的是：
- 哪台机器有足够资源
- 哪些约束必须满足
- 哪些节点更适合承载这个 Pod
所以调度不是随机分配，而是：在资源、规则和策略之间做综合决策。
2. 调度器通常会考虑什么
常见考虑因素包括：
- CPU 和内存资源
- 节点标签
- 亲和性与反亲和性
- 污点与容忍
- 资源请求与限制
2.1 requests 和 limits 是什么
requests 可以理解成 调度时，Pod 至少需要多少资源。
limits 可以理解成 Pod 最多能使用多少资源。
它们解决的是：
- 调度器如何做资源预估
- Pod 之间如何避免无序抢资源
3. 亲和性、反亲和性、污点和容忍怎么理解
3.1 亲和性
亲和性 可以理解成 某类 Pod 更倾向于被调度到满足某些条件的节点或靠近某些 Pod 的位置。
3.2 反亲和性
反亲和性 可以理解成 某类 Pod 不希望和另一类 Pod 挤在一起。
这常用于：
- 副本分散部署
- 提高可用性
3.3 污点和容忍
污点 可以理解成 节点主动声明：不是谁都能来。
容忍 可以理解成 某个 Pod 表示：这个限制我能接受。
这套机制常用于：
- 特殊节点隔离
- 系统组件专用节点
- GPU 或高性能节点隔离
4. 自愈到底在愈什么
自愈 可以理解成 当实例、Pod 或节点发生异常时，系统尽量自动把服务拉回目标状态。
常见表现包括：
- 容器挂了自动重启
- Pod 异常自动重建
- 副本数不足自动补齐
- 节点异常后重新调度
它不是“永不出故障”，而是：故障发生后，尽量自动恢复。
5. 扩缩容到底在扩什么
很多人会把扩缩容理解成“服务器变多”。
在 Kubernetes 里，更常见的直接含义是：某个工作负载的 Pod 副本数发生变化。
5.1 手动扩缩容
最直接的方式，就是调整副本数。
例如：
- 从 3 个副本扩到 6 个
- 从 6 个副本缩到 2 个
5.2 自动扩缩容
自动扩缩容 常见会和 HPA 联系在一起。
HPA 是 Horizontal Pod Autoscaler，可以理解成：
根据指标动态调整 Pod 副本数的自动扩缩容机制。
它解决的是：
- 高峰期自动扩容
- 低峰期自动缩容
- 在性能和成本之间做平衡
6. 滚动发布为什么重要
如果每次发布都把所有实例一起停掉再启动，风险会很大。
滚动发布 可以理解成 逐步替换旧版本实例，而不是一次性全量替换。
它解决的是：
- 发布期间服务中断风险
- 全量替换导致的问题放大
- 发现问题后难以及时止损
7. 回滚又是在解决什么
回滚 可以理解成 当新版本发布出问题时，把系统恢复到之前稳定版本。
它的价值在于：
- 缩短故障恢复时间
- 降低发布事故影响面
- 让发布策略更可控
8. 一个典型的扩缩容与发布片段
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo-app
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1
maxUnavailable: 1这段配置可以这样理解：
- 默认保持 3 个副本
- 发布时采用滚动更新
- 最多额外多起 1 个新实例
- 同时最多允许 1 个旧实例不可用
这里的 maxSurge 和 maxUnavailable，本质上是在控制：
发布过程中，容量和风险应该怎么平衡。
9. 工程上最常见的几个误区
9.1 误区一：扩缩容就是高可用
不是。
扩缩容更关注弹性，高可用更关注故障时服务能否继续稳定提供能力。
9.2 误区二：有自愈就不需要监控
自愈只能处理一部分问题。
如果没有监控、日志、告警，你甚至不知道系统刚刚发生过什么。
9.3 误区三：副本多了就一定更稳
如果应用本身有状态耦合、配置错误或共享依赖瓶颈，单纯加副本并不能自动解决问题。
10. 一句话总结
调度、扩缩容与发布实践这条主线，本质上是在解决：
工作负载如何合理落到节点上，如何根据负载变化保持弹性，如何在不中断服务的前提下演进版本，以及故障后如何尽量自动恢复。