Kubernetes 架构那些新手容易忽略但其实挺重要的点你得知道

很多新手在学习Kubernetes架构时,会把注意力集中在Master节点（现在叫控制平面）和Worker节点（现在叫数据平面）的基本组件上，比如API Server、etcd、Scheduler、Kubelet这些，这当然没错，但就像你学开车，先知道方向盘、油门、刹车是基础，但要开得好、不出事故，还得了解后视镜的盲区、轮胎在不同路况下的抓地力这些“细节”，Kubernetes也有一些类似的点，它们不总是在架构图的最中心，但对系统的稳定性和你的排障能力至关重要。

第一点，你得知道“静态Pod”的存在和它的特殊性。（来源：Kubernetes官方文档《静态Pod》）大多数Pod都是由控制平面的组件（比如Deployment）创建和管理的，但静态Pod是个例外，它是由特定节点上的kubelet直接管理的，并不通过API Server，你会在那些运行控制平面组件（如API Server、Scheduler本身）的节点上看到它们，因为这些核心组件就是以静态Pod的形式运行的，比如kube-apiserver-kind-control-plane这样的Pod，这意味着什么？如果你不小心删除了这个Pod，kubelet会立刻把它重新拉起来，因为它守护的是本地的Pod定义文件（通常在/etc/kubernetes/manifests目录下），你不能用普通的kubectl命令（比如kubectl edit）来直接修改它，必须去修改节点上那个对应的manifest文件，新手在排障时，如果发现某个Pod删了又自动重生，并且不在任何Deployment里，很可能就遇到了静态Pod，这时候去对应节点上找文件就对了。

第二点，容器网络接口（CNI）不是一个Kubernetes内部组件，而是一个“契约”和一套外部插件。（来源：Kubernetes官方文档《网络插件》）新手看架构图，知道Pod之间要能通信，但容易以为这是Kubernetes自带的功能，其实不然，Kubernetes只定义了网络模型（所有Pod都必须有IP、所有Pod必须能不经过NAT直接通信等），但具体实现，比如怎么分配IP、怎么配置路由规则，都交给了一个叫CNI的接口，你需要自己选择和安装CNI插件，比如Calico、Flannel、Weave Net等，这意味着，网络问题的排查思路完全不同，当出现网络不通时，你不能只盯着Kubernetes的Service或Endpoints看，很可能要登录到节点上，用ip route查看路由表，用iptables查看规则（如果插件用了iptables的话），或者用CNI插件自带的诊断命令（比如Calico的calicoctl），理解CNI的“外部性”，是你从Kubernetes新手迈向进阶的关键一步。

第三点，kube-proxy的工作模式不止一种，而不同模式对网络性能和有状态服务的影响很大。（来源：Kubernetes官方文档《Service》中的kube-proxy部分）大家都知道kube-proxy负责Service的负载均衡，但容易忽略它有不同的实现模式，最常见的两种是iptables模式和ipvs模式。iptables模式是早期默认的，它通过设置大量的iptables规则来转发流量，当你的Service数量非常多（比如几千个）时，这些规则链会变得极其冗长，导致网络延迟增加和更新规则时性能下降，而ipvs模式则利用了Linux内核的IPVS负载均衡技术，它用哈希表来管理后端，效率高很多，特别适用于大规模集群和有大量并发连接的服务，新手在规划集群时，如果知道未来服务数量会很多，就应该考虑在初始化集群时配置kube-proxy使用ipvs模式，而不是等到出了问题才去后悔。

第四点，资源请求（requests）和限制（limits）的设定，影响的远不止是资源分配，还直接关联到Pod的“服务质量等级（QoS）”。（来源：Kubernetes官方文档《配置Pod的服务质量》）你可能知道给Pod设置CPU和内存的requests和limits是为了公平和稳定，但可能没意识到，Kubernetes会根据你的设置给Pod打上一个内在的QoS标签：Guaranteed（保证）、Burstable（可压缩）、BestEffort（尽力而为），这个标签在系统资源（尤其是不可压缩的内存资源）不足时，是kubelet决定“杀”掉哪个Pod来释放资源的首要依据。BestEffort等级的Pod（没设任何requests和limits）会最先被杀死，其次是Burstable（设了requests但没设limits或limits大于requests），最后才是Guaranteed（requests和limits相等且不为空），新手如果不了解这一点，可能会疑惑为什么某个看似不重要的Pod在内存压力下活得好好的，而另一个“重要”的Pod却被杀掉了，其实根源就在于QoS等级，合理设置requests和limits，本质上是为你重要的Pod购买了一张“免死金牌”。

第五点，持久化存储的“预配”过程是异步的，失败可能发生在你看不见的地方。（来源：Kubernetes官方文档《持久化卷》中的动态预配部分）当你创建一个PVC（持久化卷声明）时，如果配置了StorageClass进行动态预配，Kubernetes会去调用相应的存储插件（如Ceph、NFS Client Provisioner等）来创建实际的存储空间，这个过程对于用户来说是“声明式”的，你下了单就以为万事大吉，但实际上，这个创建存储的后端操作是异步的，有可能你的PVC一直卡在Pending状态，但你用kubectl describe pvc查看事件，发现原因可能是后端存储系统满了、网络不通、或者权限错误，新手需要明白，PVC的成功绑定不仅取决于Kubernetes集群本身，还严重依赖于外部存储系统的健康状况，排查这类问题，要求你不仅懂Kubernetes，还要对你所使用的存储系统有基本的了解，或者至少能和存储管理员有效沟通。

理解静态Pod让你明白核心组件的管理方式；认清CNI的插件本质让你能正确诊断网络问题；了解kube-proxy的不同模式帮助你在规划阶段做出更优选择；吃透QoS机制让你能保障关键业务的稳定性；而意识到存储预配的异步性则让你对资源生命周期的把控更全面，这些点，都是在掌握了Kubernetes主干架构后，需要填充进去的血肉，能让你对集群的认知和掌控力提升一个档次。