2、Kubernetes架构解析：Master节点组件、Worker节点组件、Pod概念、网络模型
好，咱们进入第二章。这一章我打算把Kubernetes的骨架给你拆开看看。说白了，K8s就是一个分布式操作系统，管理着一大堆服务器。你得先搞清楚它由哪些零件组成，每个零件干什么活，才能用好它。
我个人习惯，学任何新技术，先看架构图，再看代码。K8s的架构其实不复杂，就两大块：控制平面（Master）和工作节点（Worker）。再加上一个核心概念Pod，以及一套网络模型。咱们一个一个来。
2.1 Master节点组件：集群的大脑
Master节点就是集群的“大脑”。它不跑你的业务应用，只负责调度、控制、决策。你想想看，一个公司里CEO不会亲自去搬砖，对吧？Master就是那个CEO。
Master节点上跑着几个关键组件，我列个表给你看：
| 组件名称 | 作用 | 我的经验 |
|---|---|---|
| kube-apiserver | 所有请求的入口，提供REST API | 这是K8s的“大门”，所有操作都得经过它 |
| kube-controller-manager | 运行各种控制器，确保集群状态符合预期 | 比如节点挂了，它负责拉起新Pod |
| kube-scheduler | 为新Pod分配最合适的节点 | 调度策略可以自定义，我踩过坑 |
| etcd | 分布式键值存储，保存所有集群数据 | 这是K8s的“数据库”，挂了就全完了 |
kube-apiserver 是唯一直接操作etcd的组件。其他组件想读写数据，都得通过API Server。嗯，这里要注意：API Server是无状态的，你可以横向扩展多个实例来扛压力。
etcd 是重中之重。我曾经在生产环境遇到过etcd磁盘IO打满，导致整个集群响应超时。那次事故让我养成了一个习惯：etcd一定要用SSD，并且定期做快照备份。
kube-scheduler 的调度策略很有意思。默认情况下，它会考虑节点资源、亲和性、污点等因素。我建议你了解一下“调度器扩展”机制，可以写自己的调度算法。
kube-controller-manager 里跑着十几个控制器。比如Node Controller、Replication Controller、Endpoint Controller等等。每个控制器都在后台循环检查，确保“当前状态”向“期望状态”靠拢。
2.2 Worker节点组件：真正干活的
Worker节点是真正跑你容器的地方。每个Worker节点上都有三个核心组件：
- kubelet：节点上的“代理人”，负责与Master通信
- kube-proxy：负责网络代理和负载均衡
- 容器运行时：比如Docker、containerd、CRI-O
kubelet 是节点上最重要的组件。它从API Server接收PodSpec，然后调用容器运行时创建、启动、监控容器。如果容器挂了，kubelet会尝试重启它。
我记得有一次排查问题，发现Pod一直处于CrashLoopBackOff状态。查了半天，原来是kubelet的日志轮转配置有问题，导致磁盘写满，kubelet自己先挂了。嗯，从那以后我每次部署集群，都会先检查kubelet的日志配置。
kube-proxy 负责实现Service的负载均衡。它有三种模式：
- userspace模式：老古董，性能差，别用
- iptables模式：默认模式，性能不错，但规则多了会慢
- IPVS模式：性能最好，适合大规模集群
我个人习惯，集群规模超过100个节点，就切到IPVS模式。iptables模式在规则数量超过1000条时，延迟会明显增加。
kubectl logs -n kube-system kube-proxy-xxxxx | grep "Using"，会看到类似 "Using iptables proxy" 的输出。
2.3 Pod概念：K8s的最小调度单元
Pod是Kubernetes里最核心的概念。说白了，Pod就是一组容器的集合，它们共享网络栈和存储卷。你想想看，为什么K8s不直接调度容器，而是搞了个Pod出来？
原因很简单：有些应用需要“亲密关系”。比如一个Web服务器和一个日志收集器，它们需要共享网络命名空间，通过localhost通信。如果分别调度成两个容器，网络隔离了，通信就麻烦了。
Pod的特点：
- 一个Pod里的容器共享同一个IP和端口空间
- 容器之间可以通过localhost互相访问
- Pod是临时性的，随时可能被销毁重建
- Pod的IP是不固定的，重启后会变
我在项目中遇到过一个问题：有个同事把数据库和Web应用放在同一个Pod里。结果数据库把内存吃光了，Web应用跟着一起挂。记住：Pod里的容器应该是一荣俱荣、一损俱损的关系。如果它们需要独立扩缩容，就应该拆成不同的Pod。
2.4 网络模型：扁平化IP网络
Kubernetes的网络模型，说白了就是“每个Pod都有一个真实IP，Pod之间可以直接通信，不需要NAT”。这个模型听起来简单，但实现起来有不少门道。
K8s网络模型有几个核心要求：
- 所有Pod可以直接通信，不需要NAT
- 所有节点可以直接与所有Pod通信，不需要NAT
- Pod看到的自己的IP，就是其他Pod看到的它的IP
为了实现这个模型，社区里出现了各种CNI插件：Flannel、Calico、Weave、Cilium等等。每个插件实现方式不同，但都遵循同一个标准。
我推荐你了解一下Calico。它基于BGP协议，性能好，支持网络策略。Flannel虽然简单，但功能有限，不适合生产环境。
为什么会这样？因为Flannel用的是overlay网络，封装和解封装会带来性能损耗。而Calico用纯三层路由，性能几乎和物理网络一样。
| CNI插件 | 实现方式 | 性能 | 适用场景 |
|---|---|---|---|
| Flannel | VXLAN overlay | 中等 | 测试环境、小规模集群 |
| Calico | BGP三层路由 | 高 | 生产环境、大规模集群 |
| Cilium | eBPF | 极高 | 对性能要求极高的场景 |
| Weave | fastdp/overlay | 中等 | 跨云混合部署 |
嗯，这里要注意：网络模型的选择会影响整个集群的性能和功能。我建议你一开始就用Calico，省得后面迁移麻烦。
好了，这一章的内容就这些。Master节点是大脑，Worker节点是手脚，Pod是最小调度单元，网络模型让一切互联互通。下一章咱们聊聊怎么用YAML文件描述这些资源，然后真正部署一个应用上去。