K8S的设计理念

简介

K8S 成为事实上资源调度管理事实标准。有些人甚至认为K8S已经成为了云原生时代的资源容器调度的操作系统。这么牛叉的K8S，他是怎么设计的呢？

设计模块

K8S的设计大致分成三大部分：Client、Master、Worker

• Client： 属于用户触发请求的客户端，即Kubectl, 用户的各种触发的命令就是通过kuberctl统一封装后进行命令触发的
• Master：用于处理用户触发的请求，进行处理决策，
• Worker：命令真正的执行者，读取etcd的结果将数据最终执行
  -

Client

• Kubectl： 是k8s 的client，也是一般RD 最常用的操作方式之一，很多K8S的使用者主要就是通过kubectl跟K8S打交道。
• UI：Dashboard 也是一个独立服务，默认可以不需要，这个服务本身可以通过Kubectl部署在k8s上对外提供服务。
  

Master

• ApiServer：Master 通信的入口， Client 和 Worker 之前同行
• ETCD：Master中唯一的决策结果的存储
• Controller Manager：里面保存各种controller
  
• Scheduler：执行实例资源的选择调度决策， 选择出合适的Worker节点来运行服务的Pod，真正的部署操作由Kubelet来执行

Worker

• Kubelet：直接通过ApiServer的watch接口读取原始数据结果
• KubeProxy：网络请求通过Kubeproxy实现服务接口的转发，作为普通服务的命名管理
• Pod：将容器、网络和存储单元打包在一起，是服务独立的部署单元。核心思路是高内聚
• Container：原始服务容器，容器与pod 的对应关系是一个Pod中包含多个容器，多个容器之间的服务可以互相访问

核心理念

K8s 设计的核心理念最终概括为4大点： 声明式、显示接口、无入侵性 和 可移植性

• 声明式：对比指令式，需求任何功能通过yml文件来描述自己的需求，最终由k8s调度满足
• 显示接口：任何接口定义都属于显示定义，不存在私有接口，所以给业务CRD 自定义提供前提， 每个K8s 可以根据自己的需求和现有的功能实现自己的服务功能
• 无入侵性：该特点就是说任何服务部署只要提前打包好docker 的image ，是不需要再做任何代码改造，就可以完成部署。
• 可移植性：可移植性主要是强调对于有状态的服务，通过PersistentVolume 支持屏蔽底层的数据存储细节

总结

K8S 对于核心理念，其实是仁者见仁，不过目前大家基本上没有争议的一点为’声明式‘设计， 这个概念在笔者前面的文章中也有提到，其实一个优秀的设计里面可以让我们能学习到的设计理念还有有很多，比如说 接口设计是互补并且可以组合， 控制机制设计避免复杂状态机并且不要依赖无法监控的复杂状态。