Appearance
Kubernetes
这里主要整理 Kubernetes 这条线。先不用急着背对象名，把它为什么会出现、到底在解决什么问题想清楚更重要：
- 为什么有了
Docker之后还需要Kubernetes Kubernetes到底解决什么问题- 为什么它要用
Pod、Deployment、Service这些对象来描述系统 - 它是怎么把调度、服务发现、扩缩容、发布和自愈串起来的
- 工程里哪些能力适合交给 K8s，哪些问题又不只是 K8s 自己能解决
Kubernetes 直接看成：一个面向容器集群的编排和调度平台，用来持续维持应用在集群中的目标状态。
这里的 编排，不要只理解成“把容器启动起来”。更贴近项目现场的说法是：很多容器分散在很多机器上，应该怎么部署、怎么互相访问、挂了怎么恢复、流量怎么进去、发布怎么做、资源怎么分配。
1. 为什么有了 Docker 还不够
Docker 更偏：
- 把应用打包成镜像
- 在单机上运行容器
- 解决环境一致性和交付问题
但当服务越来越多，只靠手工管理容器，很快会遇到这些问题：
- 多台机器上的容器怎么统一部署
- 某个实例挂了谁来拉起
- 服务扩容后别人怎么找到它
- 发布时怎么滚动替换，而不是全部一起重启
- 资源怎么分配才不会相互抢占
这就是 Kubernetes 出现的原因。
2. Kubernetes 最核心的价值是什么
可以压缩成一句话：把“容器怎么在集群里持续稳定运行”这件事做成标准化、自动化、声明式的一套机制。
这里的 声明式 可以理解成：你主要描述想要的目标状态，而不是亲手一步一步去执行所有操作。
例如：
- 我希望这个服务始终有 3 个副本
- 我希望外部可以通过一个稳定入口访问它
- 我希望发布时逐步替换实例
Kubernetes 会持续把实际状态往目标状态拉回去。
3. Kubernetes 里最核心的几个对象
3.1 Pod
Pod 是 Kubernetes 最小部署单元。
可以看成：一组共享网络和部分存储上下文、并且生命周期绑定在一起的容器。
它不等于“只是套了个壳的容器”。Kubernetes 用 Pod 作为最小调度单位，是为了表达哪些容器应该作为一个整体被部署和管理。
3.2 Deployment
Deployment 可以理解成 负责管理无状态应用副本数、滚动更新和回滚的一层控制器。
它解决的是：
- 应该跑几个副本
- 实例挂了要不要补齐
- 发布时怎么平滑替换
3.3 Service
Service 可以理解成 为一组动态变化的 Pod 提供稳定访问入口和服务发现能力。
它解决的是 Pod 会变，IP 会变，但调用方不应该跟着这些变化一起变。
3.4 Ingress
Ingress 可以理解成 把集群外部的 HTTP/HTTPS 流量按域名和路径规则引入到集群内部服务。
它常和反向代理、网关入口、域名路由一起出现。
3.5 ConfigMap 和 Secret
它们都用于管理配置。
区别抓住这一层就够了：
ConfigMap：普通配置Secret：敏感配置
4. Kubernetes 真正强的不是“能跑容器”，而是这些能力能协同工作
单看某个对象，可能会觉得没什么特别，但真正重要的是它们如何一起工作：
Deployment管 Pod 副本和发布Service给 Pod 提供稳定入口Ingress把外部流量引进来- 调度器决定 Pod 落到哪台节点
- 控制器持续对比实际状态和目标状态
这样一套机制组合起来，才构成了 Kubernetes 的真正价值。
5. Kubernetes 更适合什么，不适合什么
更适合
- 容器化应用集群部署
- 微服务和多服务协作
- 标准化发布流程
- 自动扩缩容和自愈
- 多环境统一治理
不适合简单理解成
- “比 Docker 更高级的单机工具”
- “只要上了 K8s 就天然高可用”
- “上了 K8s 就不需要关心监控、日志和网络”
Kubernetes 很强，但它不是自动帮你把所有架构问题都解决掉。
6. 当前目录下的专题
推荐阅读顺序：
- 看这篇总览，建立 Kubernetes 整体定位
- 再看“核心对象与控制器”，理解 Pod、Deployment 这些抽象为什么存在
- 再看“Service、Ingress 与网络访问”，理解服务怎么互相找、流量怎么进来
- 再看“配置、存储与有状态服务”，理解有状态场景为什么更复杂
- 最后看“调度、扩缩容与发布实践”，把这些能力串到工程场景里
7. 常见误区
7.1 误区一：把 Kubernetes 理解成“会自动帮你运维一切”
它能自动化很多事，但前提是：
- 对象建模合理
- 资源设置合理
- 监控、日志、告警链路到位
- 应用本身具备基本可运维性
7.2 误区二：只会背对象名，不理解对象协作关系
真正重要的不是单个对象定义，而是：一个请求、一个服务、一次发布，在这套对象体系里是怎么流转的。
7.3 误区三：把自动扩缩容和高可用混为一谈
扩缩容 关注的是资源弹性，高可用 关注的是故障时服务还能不能继续可用。
两者相关，但不是一回事。
8. 一句话总结
Kubernetes 最值得先建立的认知，不是“对象清单”，而是它为什么会成为容器集群的操作系统，以及它怎么把部署、流量、配置、扩缩容和发布串成一套稳定的运行体系。