ref="/tag/2020/" style="color:#E3A3CF;font-weight:bold;">Kubernetes架构原理详解
想象一下，你家楼下有家快餐店，每天要处理上百个订单。厨房、服务员、收银台各司其职，配合默契才能不乱套。Kubernetes（简称K8s）就像这个快餐店的“总调度”，只不过它管的不是人，而是成百上千个运行在服务器上的应用容器。
控制平面：大脑中枢
Kubernetes的大脑叫控制平面（Control Plane），通常运行在主节点（Master Node）上。它负责整个集群的决策和管理。比如什么时候启动新服务，某个容器挂了要不要重启，资源不够了怎么分配。
控制平面包含几个关键组件。API Server是唯一入口，所有操作都得通过它。你可以把它看作餐厅的点餐系统，服务员不能直接进厨房翻锅铲，必须把订单传给系统，再由系统通知厨师。
etcd是个高可用的键值数据库，保存集群的所有状态信息，像菜单、订单记录、库存情况。Controller Manager负责维持期望状态，比如你希望运行3个咖啡制作容器，它就会一直盯着，少一个就补上。
Scheduler则像个智能排班员，决定新来的任务该交给哪个节点执行。它会看各个节点的CPU、内存剩余多少，避免把重活全压在一台机器上。
工作节点：干活的主力
真正跑应用的是工作节点（Worker Node）。每个节点上都有几个核心组件。Kubelet是节点上的“工头”，接收控制平面的指令，确保容器按要求运行。它定期汇报“我这儿有两个容器在跑，状态正常”。
Kube Proxy负责网络通信，相当于餐厅里的传菜通道。它确保顾客点的餐能准确送到对应桌号，不同服务之间也能互相调用。比如订单系统要查库存，请求得顺利到达仓储服务。
容器运行时（如Docker或containerd）就是厨房里的灶台，真正用来运行容器。Pod是Kubernetes最小的部署单位，可以理解为一个打包好的“套餐”。一个Pod里可能有一个主容器，外加一个日志收集的小容器，它们共享网络和存储空间。
举个实际例子
假设你在公司上线了一个电商网站，前端、后端、数据库分别打包成容器。你写个YAML文件声明：前端需要3个实例，后端2个，数据库1个。把这个文件交给Kubernetes，它就会自动安排这些Pod分布在不同的节点上运行。
某天下午流量暴增，前端Pod响应变慢。Kubernetes的自动扩缩容机制发现CPU使用率超过80%，立刻根据规则把前端实例从3个扩展到6个。等到晚高峰过去，又自动缩回去，省下服务器开销。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80这段配置描述了一个Nginx服务，要求维持3个副本。Kubernetes会持续监控，哪怕手动删掉一个Pod，它也会立即重建，保证数量不变。
服务发现也是Kubernetes的拿手好戏。你不需要记住每个容器的IP地址，只要通过Service定义一个稳定的访问入口，内部请求自动负载均衡。就像餐厅不管换了几任厨师，顾客只要报桌号就能上菜。
命名空间（Namespace）则像餐厅的不同区域，比如堂食区、外卖区、员工休息区。开发、测试、生产环境可以隔离开，互不影响。
这种架构让运维变得轻松。更新版本时，可以设置滚动更新策略，先停一个旧实例，启动一个新实例，逐步替换。万一新版本有问题，还能快速回滚到之前的状态。