kubernetes|图文并茂！带你深度解析Kubernetes( 五 ) docker|操作系统|Google

scheduler 。集群的调度器，它负责在Kubernetes集群中为Pod资源对象找到合适节点并使其在该节点上运行。

etcd 。用于存储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的进程的子进程。根据容器设计模式，传统架构中多个紧密配合的业务进程（例如业务进程与日志收集进程，业务进程与业务网络代理进程）应该部署成多个容器。但这些容器之间存在亲密的关系，需要一起调度和直接共享某些资源（网络和存储）。
Kubernetes抽象出一个Pod对象，是一组（一个或多个）容器，这些容器共享存储、网络等，这些容器是相对紧密的耦合在一起的。 Pod是Kubernetes内创建和管理的最小可调度单元，调度过程是按Pod整体所需资源一起进行调度的。 Pod本身只是逻辑上的概念，在容器管理这层并不认识Pod对象。
Pod的实现需要使用一个中间容器（Infra容器），在这个Pod中， Infra容器永远是第一个被创建的容器，用户定义的其他容器通过Join Network Namespace的方式与Infra容器关联在一起。抽象一个中间容器的原因在于各个业务容器是对等的，其启动没有严格的先后顺序，需借助中间容器实现共享网络和存储的目的。