你是否还在把K8S当成一个黑盒子来用？
每次Pod启动失败、服务访问不通就只会重启重启再重启？
投入三分钟去读完这篇文章，我要来手把手分毫不差地拆解K8S内部六大具代表性的核心组件的运作逻辑，以便让你下次碰到问题能够精准地直击病灶之处。
大脑中枢API Server
所有操作请求全都势必得经由这里，而API Server乃是整个集群的总闸门。
我于某电商公司承担运维工作期间，曾碰到集群忽然没法响应，最终确定正是API Server负载过重致使请求堆积。
它是依据RESTful API展开设计的，你所运用的kubectl命令，从根本上来说，便是在朝着它发送HTTP请求呢。
每天处理数万次请求是常态，高峰期甚至能达到每秒上千次。
最要紧的是，它身为集群里唯一跟etcd直接进行通信的组件，确保了数据的一致性。
数据存储etcd
etcd是一个具备高可用性的键值数据库，它存储着集群的全部配置以及状态信息。
就在去年双十一进行大促之前的时候，我们对etcd节点故障展开了模拟，结果发现哪怕是有一个节点出现了宕机的情况，然而集群却依旧能够正常地去提供服务。
它采用Raft一致性算法，确保数据在多个节点间强一致。
在生产环境里，我们针对etcd专门配置了SSD硬盘，这是因为它的读写延迟与整个集群的响应速度有着直接的关联。
所有Pod的调度结果、服务发现信息都安全保存在这里。
调度器Scheduler
调度器负责为新创建的Pod寻找最合适的Node。
我于一回压测期间留意到，调度器进行决策之际，绝非单纯依据剩余内存的大小来判定，而是全面综合权衡CPU使用率、节点亲和性、污点容忍度等二十多个要素来施行决策。
比如说，对于存有一个AI训练任务，该任务所需的是GPU资源，在此情形下，调度器会凭借特定机制，自主性地挑选出那些已被标记为gpu=true的节点。
它每秒能够完成数量达到上百个的Pod此调度计算，以此来确保资源利用率达成最大化状态。
控制器管理器Controller Manager
控制器管理器内部运行着数十个自动化控制器。
最典型的例子是副本控制器，它能实时监控Pod数量。
往前数一周的时候，我们遭遇到了一种怪异的状况，被删除掉的Pod，在过了一阵子之后，又自行冒了出来，经过一番仔细追查之后，发现原来是Deployment所设置的副本数量为3，控制器持续不断地对状态进行纠正。
节点控制器，每隔十秒就去检查一次Node的健康状况，可以这么说，一旦察觉到节点失联的时长超过了五分钟，便会将上面的Pod标记为Unknown，并且触发重新调度。
节点代理kubelet
kubelet是部署在每个Node上的执行者。
它每隔二十秒便会朝着API Server汇报一回节点状态，其中涵盖了CPU使用率，内存剩余量，以及磁盘空间等等。
我曾经于故障排查之际，去查看kubelet日志，结果发现，它把每一回容器启动的全过程都给详细记录下来了。
它运用容器运行时的特定命令，自拉取镜像起始，直至创建网络命名空间，其中的每一个步骤，皆存在着可供追寻的踪迹。
要是Pod出现异常退出的情况，kubelet会去尝试进行重启，在超过三次重启失败之后才会进行上报。
网络代理kube-proxy
kube-proxy实现了Service的负载均衡功能。
处于公有云环境之中，我们将其调整成为了ipvs模式，相较于原本的iptables模式，并发处理能力实现了三倍的提升。
它对API Server的服务变化进行实时监听，一旦有新的Service被创建出来，便马上在节点上对转发规则进行配置。
在实际进行测试期间，ipvs模式，每一秒钟能够处理数量达到上万条的新建连接，延迟处于毫秒这个级别上。
它还承担着节点port的访问控制这一职责，以此来保证外部流量能够精确无误地抵达目标Pod。
组件协同工作流
这些组件并非独自运行，而是藉由API Server达成精密协作。
列举一个真实的案例，即身为你去执行kubectl run以此来创建3个Nginx Pod，起初命令抵达API Server，历经身份验证以及权限检查之后写入etcd。
有调度器，它监听到了新建Pod事件，接着对当前集群的50个节点的资源予以分析，随后从中选择出三个最优目标，最后将那些绑定的信息写回到etcd里。
kubelet，在这三个节点处，监听到自身被分配了任务，紧接着，马上调用Docker，去拉取1.2版本的Nginx镜像。
整个过程在5秒内完成，而你只看到最终结果。
网络插件CNI
CNI插件解决了跨节点容器通信难题。
我们用于生产环境的Calico，基于BGP协议，在数千台服务器之间直接进行路由，从而绕过了overlay网络所存在的性能损耗。
它支持网络策略，可以精确控制哪些Pod能互相访问。
曾有一回，存在要对前端Pod直接连接数据库加以限制的情况，仅仅只需要去定义NetworkPolicy资源，如此一来，Calico便会自动把iptables规则下发至所有的节点。
每个节点之上，路由表条目数量能够达到上万条次之多，然而，其转发延迟一直以来都被控制在微秒级别的范畴之内。
存储插件CSI
CSI插件让容器能够使用持久化存储。
我们运用Rook Ceph构建了分布式存储系统，以此为MySQL容器供应PV。
CSI插件在Pod调度时自动完成存储卷的挂载和格式化。
测试数据显示，从创建PVC到Pod成功挂载，平均耗时3秒。
其具备快照以及扩容功能，曾有一回数据库空间匮乏，我们径直对PVC容量声明予以修改，CSI插件自行达成底层存储卷的扩充，整个过程业务毫无察觉。
服务网格扩展
集群流量入口是Ingress Controller，它承载着全部外部访问。
我们运用Nginx Ingress Controller，每日应对超出五亿次的HTTP请求。
它具备基于域名的路由支持能力，能够将api.example.com这一域名，转发至后端的API服务，还能把web.example.com这个域名，指向前端的应用。
SSL证书管理同样是它所具备的强项，能够自动续签Let‘s Encrypt证书，如此便避免了人工维护时证书过期这种状况的出现。
这些组件共同构成了完整的K8S生态体系。
你平时遇到K8S故障时，是从哪个组件开始排查的？
若你拥有实战经验，不妨在评论那里分享，为使许多同事都能看到这篇干货，麻烦点个赞，如此一来，下次集群出现问题之时，大家便可一道迅速定位了。
Comments NOTHING