加入收藏 | 设为首页 | 会员中心 | 我要投稿 应用网_阳江站长网 (https://www.0662zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 运营中心 > 建站资源 > 优化 > 正文

容器技术的发展与基本原理

发布时间:2020-11-30 04:11:54 所属栏目:优化 来源:51cto
导读:容器技术的发展背景 近些年来,容器技术迅速席卷全球,颠覆了应用的开发、交付和运行模式,在云计算、互联网等领域得到了广泛应用。其实,容器技术在约二十年前就出现了,但直到2013年Docker推出之后才遍地开花,其中有偶然因素,也有大环境造就的必然因素

Docker还提供了容器存储和网络映射到宿主机的功能,大部分由containerd实现。应用的数据可以被保存在容器的私有文件系统里面,这部分数据会随着容器一起被删除。对需要数据持久化的有状态应用来说,可用数据卷Volume的方式导入宿主机上的文件目录到容器中,对该目录的所有写操作都将被保存到宿主机的文件系统中。Docker可以把容器内的网络映射到宿主机的网络上,并且可以连接外部网络。

CRI和CRI-O

Kubernetes是当今主流的容器编排平台,为了适应不同场景的需求,Kubernetes需要有使用不同容器运行时的能力。为此,Kubernetes从1.5版本开始,在kubelet中增加了一个容器运行时接口CRI(Container Runtime Interface),需要接入Kubernetes的容器运行时必须实现CRI接口。由于kubelet的任务是管理本节点的工作负载,需要有镜像管理和运行容器的能力,因此只有高层容器运行时才适合接入CRI。CRI和容器运行时的关系如下图所示。

容器技术的发展与基本原理

CRI和容器运行时之间需要有个接口层,通常称之为shim(垫片),用以匹配相应的容器运行时。CRI接口由shim实现,定义如下,分为RuntimeService和ImageServiceManager(代码参见GitHub上kubernetes/cri-api的项目文件“pkg/apis/services.go”):

// RuntimeService接口必须由容器运行时实现 // 以下方法必须是线程安全的 type RuntimeService interface { RuntimeVersioner ContainerManager PodSandboxManager ContainerStatsManager  // UpdateRuntimeConfig更新运行时配置 UpdateRuntimeConfig(runtimeConfig *runtimeapi.RuntimeConfig) error  // Status返回运行时的状态 Status() (*runtimeapi.RuntimeStatus, error) }  // ImageManagerService接口必须由容器管理器实现 // 以下方法必须是线程安全的 type ImageManagerService interface { // ListImages列出现有镜像 ListImages(filter *runtimeapi.ImageFilter) ([]*runtimeapi.Image, error)  // ImageStatus返回镜像状态 ImageStatus(image *runtimeapi.ImageSpec) (*runtimeapi.Image, error)  // PullImage用认证配置拉取镜像 PullImage(image *runtimeapi.ImageSpec, auth *runtimeapi.AuthConfig, podSandboxConfig *runtimeapi.PodSandboxConfig) (string, error)  // RemoveImage删除镜像 RemoveImage(image *runtimeapi.ImageSpec) error  // ImageFsInfo返回存储镜像的文件系统信息 ImageFsInfo() ([]*runtimeapi.FilesystemUsage, error) }  

Docker运行时被普遍使用,它的CRI shim被称为dockershim,内置在Kubernetes的kubelet中,由Kubernetes项目组开发和维护。其他运行时则需要提供外置的shim。containerd从1.1版本开始内置了CRI plugin,不再需要外置shim来转发请求,因此效率更高。在安装Docker的最新版本时,会自动安装containerd,所以在一些系统中,Docker和Kubernetes可以同时使用containerd来运行容器,但是二者的镜像用了命名空间隔离,彼此是独立的,即镜像不可以共用。因为Docker和containerd常常同时存在,因此在不需要使用Docker的系统中只安装containerd即可。

containerd最早是为Docker设计的代码,包含一些用户相关的功能。相比之下,CRI-O是替代Docker或者containerd的高效且轻量级的容器运行时方案,是CRI的一个实现,能够运行符合OCI规范的容器,所以被称为CRI-O。CRI-O是原生为生产系统运行容器设计的,有个简单的命令行工具供测试用,但并不能进行容器管理。CRI-O支持OCI的容器镜像格式,可以从容器镜像仓库中下载镜像。CRI-O支持runC和Kata Containers这两种低层容器运行时。

 

(编辑:应用网_阳江站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!