罗永浩|图文并茂!带你深度解析Kubernetes( 六 )


Kubernetes架构具备高可用:一方面Master节点高可用;另一方面所部署的业务也是高可用的 。 系统高可用的核心在于冗余部署 , 当某一个节点或程序出现异常时 , 其他节点或程序能分担或替换工作 。 Master节点高可用 , 主要由以下几个方面的设计实现:

  • Master由多台服务器构成 。
  • API Server多实例同时工作 , 负载均衡 。
  • etcd多节点 , 一主多从 。
  • controller-manager与scheduler抢主实现 。
Work Node节点由以下组件组成:
  • kubelet:负责Pod对应容器的创建、启停等任务 , 是部署在Node上的一个agent 。
  • kube-proxy:实现Service通信与负载均衡机制 。
  • 容器运行时(如Docker):负责本机的容器创建和管理 。
  • API Server中心枢纽
Kubernetes中API Server的核心功能是提供Kubernetes各类资源对象(如Pod、RC、Service等)的增、删、改、查及Watch等HTTP REST接口 , 成为集群内各个功能模块之间数据交互和通信的中心枢纽 , 是整个系统的数据总线和数据中心 。 除此之外 , 它还是集群管理的API入口 , 提供了完备的集群安全机制 。 API Server是由多实例同时工作 , 各个组件通过负载均衡连到具体的API Server实例上 。
如下所示 , 各组件与API Server通信时 , 采用List-Watch机制 , 通过API server获取etcd配置与状态信息 , 进而触发行为 。 以下图为例是kubectl创建一个deployment时 , 各个组件与API Server的流程交互 。
Api Server的作用:
  • 集群控制、访问的唯一入口 , 统一的认证、流量控制、鉴权等 。
  • ectd数据的缓存层 , 请求不会轻易穿透到etcd 。
  • 集群中各个模块的中心枢纽 , 各个模块之间解耦 。
  • 便于模块插件的扩展(其他模块List、Watch、Update ApiServer即可实现扩展功能) 。
(三)Kubernetes核心设计Kubernetes取的巨大的成功 , 与它良好的核心设计紧密相关 。 笔者认为Kubernetes有三大核心设计:
  • 编排抽象 。 容器平台核心点不在于创建和调度容器 , 而是在上层架构抽象出各种对象 , 便于去统一管理 。 Kubernetes创造性的抽象出了各个编排的关系 , 例如亲密关系(Pod对象)、访问关系(Service对象)等 。
  • 声明式API 。 声明式API是整个系统自动化的核心要点 , kubernetes提供了以声明式API的方式将抽象对外暴露 , 同时也便于了用户管理对象 。
  • 开放插件 。 支持系统资源插件化(比如计算、存储、网络);同时也支持用户自定义CRD和开发Operator 。
  • Pod对象
Kubernetes在对象抽象方面 , 核心创新在于Pod对象的设计 。 容器设计本身是一种“单进程”模型 。 该表述不是指容器里只能启动一个进程 , 而是指容器无法管理多个进程 。 只有容器内PID=1的进程生命周期才受到容器管理(该进程退出后 , 容器也会退出) , 其他进程都是PID=1的进程的子进程 。 根据容器设计模式 , 传统架构中多个紧密配合的业务进程(例如业务进程与日志收集进程 , 业务进程与业务网络代理进程)应该部署成多个容器 。 但这些容器之间存在亲密的关系 , 需要一起调度和直接共享某些资源(网络和存储) 。