控制器模式：永不疲倦的纠偏狂
先说清楚。Kubernetes的核心不是Pod，不是Service，是控制器。对吧？你每敲一个kubectl apply，背后就有一堆控制器开始发狂似地工作。它们的信条：实际状态必须等于期望状态。 原理简单得让人想哭：一个死循环，反复对比，不一致就调。但这个循环——Reconcile Loop——的实现简直精妙。它不用for {}轮询，那样集群早崩了。它有一套完整的电文系统：Informer + WorkQueue。Informer监听API Server的事件变化，通过List-Watch机制拿到增量，然后倒进一个叫DeltaFIFO的队列。有个叫Reflector的组件负责填充。接着，Worker从WorkQueue取出处理，调用Reconcile，完事。
调度器的博弈：为什么它能快速锁定最优节点？
落地三宗罪：别让这些细节毁了你的集群
第一罪：CPU节流——你以为限了CPU？你限的是心跳。 Linux CFS调度器配合cgroup的CPU bandwidth control，给容器加了个limit，比如cpulimit=0.5。你以为它最多占半核？天真。CFS会在每个调度周期（cfs_period_us，默认100ms）里给容器配额（cfs_quota_us，默认等于period * limit）。如果容器用光了配额，不管系统空闲与否，它得等下一个周期。这就是节流！ 我们线上一个Go服务，limit设为400m，并发一上来，CPU使用瞬间超过配额，被节流。响应时间P99从12ms飙到450ms，用户骂娘。后来我们直接去掉limit，改成Guaranteed QoS，搞定。但注意：Nodepool资源规划必须跟上，否则节点被打爆别怪我。 第二罪：CNI误选——网络就是水，容器就是鱼。水不行，鱼会死。 我们前年用Flannel vxlan搭集群，图简单。跑了一年后，微服务暴增，内部RPC调用频繁。一次压测，Pod间TCP吞吐从物理机线速10Gbps衰减到3.2Gbps，延迟增加200%。原因是vxlan的额外封包拆包开销和CPU消耗。切到Calico BGP后，损耗降到2%。但Calico也坑：我们配置过BGP Route Reflector，手滑把mesh弄成full mesh，路由表炸了。教训：CNI选型不只看性能，还要看运维复杂度和你的网络拓扑。
