Kubernetes 简介
从业务视角理解 Kubernetes 解决了什么问题。
Kubernetes 是容器编排平台，它解决的是“如何稳定、可重复地运行服务”的问题，而不是帮你写业务代码。
它解决什么
- 调度：把 Pod 放到合适的节点
- 自愈：容器挂了自动拉起
- 伸缩：根据负载扩缩容
- 服务发现：为动态 Pod 提供稳定入口
它不解决什么
- 业务性能瓶颈
- 数据库设计
- 代码质量问题
适用场景
- 多服务、多环境、频繁发布
- 需要标准化部署与回滚
- 追求一致的可观测与运维方式
一句话心智模型
Kubernetes 就是“声明式 + 控制器”的自动化运维系统。
你真正会用上的那套思路
如果你刚开始上手 Kubernetes，先别急着背“控制平面/控制回路/对象模型”这些词。你更可能遇到的第一件事是：
服务发上去了，Pod 看起来在跑，但就是访问不到。
这个时候最省时间的做法不是猜，而是先把证据拿到手。一般我会先跑这几条：
kubectl get nodes
kubectl get pods -A
kubectl get events -A --sort-by=.lastTimestamp
kubectl describe pod -n <ns> <pod>
然后你会发现很多“玄学问题”，其实都是很朴素的配置没对上。
比如“Pod 在跑但没流量”，很常见的原因是 Service 的 selector 和 Pod 的 labels 没对齐，endpoints 直接为空。你不用猜，直接看：
kubectl get svc -n <ns>
kubectl get endpoints -n <ns> <svc> -o wide
再比如 CrashLoopBackOff，绝大多数时候就是配置/依赖/权限出了问题：Secret 没挂上、路径写错、容器里没权限写目录、或者探针把自己打死。这个时候 describe 和 logs --previous 往往比你自己“凭经验改参数”更靠谱。
你慢慢会感受到 Kubernetes 的核心机制：你在 YAML 里写“我想要什么”，控制器负责把现实往那个方向推。apply 改的是“意图”，不是“动作”。所以排障最有效的切入点也不是“我刚才执行了什么”，而是“这个对象的 spec 写的是啥、现在实际变成啥”。
如果你想最快把这套东西练出来，建议做个小实验：建一个 namespace，丢一个简单应用进去，然后故意改错一个 label 或端口，再用 events/describe/logs 把它找回来。两三次之后你会发现自己不怎么需要“背概念”了。
最后补几句上生产前很有用的常识：Namespace 更像文件夹，不等于安全隔离；YAML 一定要进版本管理；labels/selector 尽量从一开始就统一；requests/limits 别长期空着；发布前想清楚回滚怎么做（回到哪个版本、怎么 apply 回去）。