kubernetes架构
Master 控制节点
master是集群的控制节点，每个集群都至少要有一个Master管理和控制集群。所有执行的命令都在Master上运行。Master要独立部署在一台服务器上（为了解决单点故障，至少需要三台）
Master节点运行了三个重要进程：
（1）kube-apiserver 提供Restful风格的接口，是kubernetes所有资源的增、删、改、查操作的唯一入口，也是控制集群的唯一入口 （2）kube-controller-manager 负责容器的编排，所有资源对象的自动化控制中心 （3）kube-scheduler 负责资源调度
还有一个分布式键值数据库etcd，用于保存所有资源对象的数据。集群的持久化数据由kube-apiserver处理后保存在etcd中
Node 计算节点
在kubernetes集群中，Master节点会分配Docker容器到Node节点。当Node节点宕机时，Master节点会将故障Node节点的工作转移到其他健康节点。
（1）kubelet Node节点上的核心组件，管理本机运行容器的生命周期，例如：负责Pod对应容器的创建、启停、Pod挂载数据卷、下载secret、获取容器和节点状态等工作。
- kubelet与Docker容器交互，交互时所依赖的接口为CRI（Container Runtime Interface）。这个接口隔离了各个容器引擎之间的差异。通过OCI与Linux系统交互，CRI把创建容器请求翻译为Linux系统调用
- kubelet 还通过 gRPC 协议同一个叫作 Device Plugin 的插件进行交互。这个插件，是 Kubernetes 项目用来管理 GPU 等宿主机物理设备的主要组件
- kubelet通过CNI（Container Networking Interface）和 CSI（Container Storage Interface）实现调用网络插件和存储插件为容器配置网络和持久化存储
（2）kube-proxy 实现kubernetes Service的通信和负载均衡（四层）
（3）Docker-Engine 负责容器的创建和管理工作
OCI
Open Container Initiative（开放容器计划），是由多家公司共同成立的项目，并由linux基金会进行管理，致力于container runtime的标准的制定和runc的开发等工作。
所谓container runtime，主要负责的是容器的生命周期的管理。oci的runtime spec标准中对于容器的状态描述，以及对于容器的创建、删除、查看等操作进行了定义。
runc
是对于OCI标准的一个参考实现，是一个可以用于创建和运行容器的CLI(command-line interface)工具。runc直接与容器所依赖的cgroup/linux kernel等进行交互，负责为容器配置cgroup/namespace等启动容器所需的环境，创建启动容器的相关进程。
为了兼容oci标准，docker也做了架构调整。将容器运行时相关的程序从docker daemon剥离出来，形成了containerd。Containerd向docker提供运行容器的API，二者通过grpc进行交互。containerd最后会通过runc来实际运行容器。
kubernetes与容器
kubernetes在初期版本里，就对多个容器引擎做了兼容，因此可以使用docker、rkt对容器进行管理。以docker为例，kubelet中会启动一个docker manager，通过直接调用docker的api进行容器的创建等操作。
在k8s 1.5版本之后，kubernetes推出了自己的运行时接口api--CRI(container runtime interface)。cri接口的推出，隔离了各个容器引擎之间的差异，而通过统一的接口与各个容器引擎之间进行互动。
与oci不同，cri与kubernetes的概念更加贴合，并紧密绑定。cri不仅定义了容器的生命周期的管理，还引入了k8s中pod的概念，并定义了管理pod的生命周期。在kubernetes中，pod是由一组进行了资源限制的，在隔离环境中的容器组成。而这个隔离环境，称之为PodSandbox。在cri开始之初，主要是支持docker和rkt两种。其中kubelet是通过cri接口，调用docker-shim，并进一步调用docker api实现的。
如上文所述，docker独立出来了containerd。kubernetes也顺应潮流，孵化了cri-containerd项目，用以将containerd接入到cri的标准中。
为了进一步与oci进行兼容，kubernetes还孵化了cri-o，成为了架设在cri和oci之间的一座桥梁。通过这种方式，可以方便更多符合oci标准的容器运行时，接入kubernetes进行集成使用。可以预见到，通过cri-o，kubernetes在使用的兼容性和广泛性上将会得到进一步加强。
