K8S工作节点的演变：由Docker到CRI-O
随着K8S的崛起，OCI的推出，容器和云架构逐渐发展完善，一个纯开源的、社区的，完美的和高效的容器生态体系正在形成和在各个企业生产环境中使用。而生态体系中最重要的一环就是其Node，工作节点的演变，本文我们我说说K8S工作节点的演变和OCI标准下生态体系。
工作节点的演化
我们回顾一下K8S体系架构的发展，其中工作节点的运行时容器的已经发了重大的变化和调优，有以Docker为主导的容器发展成了有OCI标准的的CRI-O工具链形式。
docker主导
该阶段主要以简单的kubelet体系结构作为工作节点代理开始，作为工作节点代理通过api-server从主节点接收来管理的命令。Kubelet使用Docker运行时来启动Docker容器(包括从注册表中拉镜像)。
CRI(容器运行时接口)
容器运行时接口(CRI)规范是在K8s 1.5中引入的。CRI规范还包括协议缓冲区，gRPC API和库。通过在kubelet中运行的gRPC客户端和在CRI Shim中运行的gRPC服务器。该规范给K8S架构体系带来抽象层，并充当了适配器。这允许以更简单的方式运行各种容器运行时。
这些功能分为2个层次：
- 高级别功能：镜像管理，传输，镜像解压缩和API，发送命令来运行容器，网络，存储(例如：rkt，docker，LXC等)。
- 低级别功能： 运行容器。
这些功能可以拆分独立出各个部分来，各个部分可以选用各种开源组件，并搭配成更合理更高效的组合。
OCI、CRI-O 和工具链生态
OCI(开放容器倡议)提出了明确的容器运行时和镜像规范，该规范有助于实现多平台支持(Linux，Windows，VM等)。Runc是OCI的默认实现，它是容器运行时的底层。代的容器运行时基于该分层体系结构，其中Kubelet通过CRI-gRPC与容器运行时进行通信，而容器运行时通过OCI运行容器。CRI有多种实现，例如Docker shim，CRI-O，containerD。
podman
无守护程序容器引擎，用于开发管理和运行OCI容器，在一定程度上可以取代Docker CLI语言，可以docker命令大多数命令(RUN，PUSH，PULL等)，甚至可以将其直接作为docker别名使用即可。
buildah
buuildah帮助构建OCI镜像的工具。用户不必关注象镜像的组成，也不用编写复杂的Dockerfile。相反，可以一次只构建一层镜像，对其进行测试，然后回滚(如果需要)，知道满意，然后提交它到注册表。
skopeo
完整的容器管理CLI工具。skopeo功能之一就是可以直接在远程注册表中无需下载或者解压，就可以检查镜像。skopeo目前已经发展成为用于远程注册表的功能完善的镜像管理工具，包括对镜像进行签名，在注册表之间复制并保持远程注册表同步。这大大加快了容器构建，管理和部署管道速度。
CRI-O
CRI-O提供了可在OCI标准下一致的运行时和kubelet集成方式，提供一个kubelet容器运行时的接口：
- 支持更多镜像的格式包括docker镜像格式;
- 支持更多的方式来下载和验证镜像包;
- 容器镜像管理(管理image的层，文件系统);
- 容器进程的生命周期管理;
- CRI所需求的监控和日志;
- CRI需求的资源隔离;
OpenShift
OpenShift包括整个生态链工具的。红帽去年发布的Red Hat OpenShift 4.x系统，其容器运行时默认为CRI-O。可以使用CoreOS构建不可变的基础架构，并在该基础架构上运行OpenShift4.x。CRI-O以CoreOS为基础是好处显而易见的，最更重要的一点是CRI-O由k8s社区控制，完全开源，非常精简，直接实现k8s容器运行时接口。
