建设银行投资网站,wordpress 主题更新,注册资金大小对公司有何影响,wordpress网页内容该篇文章介绍的主要是编排以及容器技术的发展史(了解即可)#xff0c;如果想单纯学习docker命令操作可直接略过#xff01;#xff01;#xff01;
容器技术发展史
Jail 时代
容器不是一个新概念或者新技术#xff0c;很早就有了#xff0c;只是近几年遇到了云计算如果想单纯学习docker命令操作可直接略过
容器技术发展史
Jail 时代
容器不是一个新概念或者新技术很早就有了只是近几年遇到了云计算整个技术被彻底引爆了。
1979 年 贝尔实验室发明 chroot
chroot 系统调用是在 1979 年开发第 7 版 Unix 期间引入的。贝尔实验室在 Unix V7 的开发过程中发现当一个系统软件编译和安装完成后整个测试环境的变量就会发生改变下一次测试需要重新配置环境信息。 设计者们思考能否隔离出来一个独立的环境来构建和搭建测试环境所以发明了chroot可以把一个进程的文件系统隔离起来。 chroot 系统调用可以将进程及其子进程的根目录更改为文件系统中的新位置。隔离以后该进程无法访问到外面的文件因此这个被隔离出来的新环境像监狱一样被命名为 Chroot Jail 监狱。后续测试只需要把测试信息放到 Jail 中就可以完成测试了。 这一进步是进程隔离的开始为每个进程隔离文件访问。所以 chroot 可以认为是容器技术的鼻祖。
2000 年 FreeBSD 4.0 发行 FreeBSD Jail
2000 年当时一家小型共享环境托管提供商提出了 FreeBSD Jail以实现其服务与其客户服务之间的明确分离以实现安全性和易于管理。每个 Jail 都是一个在主机上运行的虚拟环境有自己的文件、进程、用户和超级用户帐户,能够为每个系统分配一个IP 地址。 FreeBSD Jail 不仅仅有 chroot 的文件系统隔离并且扩充了独立的进程和网络空间。
2001 年 Linux VServer 发行
与 FreeBSD Jails 一样Linux VServer 是一种监狱机制可以对计算机系统上的资源文件系统、网络地址、内存进行分区。
2004 年 Solaris Containers 发行
2004 年 Solaris Containers 的第一个公开测试版发布结合系统资源控制和区域进行隔离并添加了快照和克隆能力。 这个时期的进程隔离技术大多以 Jail 模式为核心基本实现了进程相关资源的隔离操作没有更大的应用场景发展有限。
云时代
2006 年Google 101 计划提出云的概念对当前的主流开发模式产生深远的影响。 也许以后我们会更多考虑如果出现比现在多 1000 倍, 10000 倍的数据量的时候我们该如何处理?要想让”云”发挥潜能与此相关的编程和操作就应该与使用互联网一样简单。随后亚马逊、IBM 等行业巨头也陆续宣布各自的“云”计划宣告“云”技术时代的来临。 云计算需要处理海量数据、超高并发、快速扩展等问题此时不仅仅需要隔离还需要能够对资源进行控制和调配。
2006 年 google 推出 Process Containers
Process Containers由 Google 于 2006 年推出旨在限制、统计和隔离一组进程的资源使用CPU、内存、磁盘 I/O、网络。一年后它更名为“Control Groups (cgroups)”并最终合并到 Linux 内核 2.6.24。
2008 年 LXC 推出
LXCLinux 容器是 Linux 容器管理器的第一个、最完整的实现。它是在 2008 年使用 cgroups 和 Linux 命名空间实现的它可以在单个 Linux 内核上运行不需要任何补丁。 同年谷歌推出 GAEGoogle App Engine首次把开发平台当做一种服务来提供采用云计算技术跨越多个服务器和数据中心来虚拟化应用程序。 同时 Google 在 GAE 中使用了 Borg Kubernetes 的前身来对容器进行编排和调度。 LXC 和 Borg 其实就相当于最早的 docker 和 k8s.
2011 年 CloudFoundry 推出 Warden
2011 年启动了 Warden早期使用 LXC后来替换为自己的实现,直接对 Cgroups 以及 Linux Namespace 操作。开发了一个客户端-服务器模型来管理跨多个主机的容器集合并且可以管理 cgroups、命名空间和进程生命周期。
2013 年 LMCTFY 启动
Let Me Contain That For You (LMCTFY) 于 2013 年作为 Google 容器堆栈的开源版本启动提供 Linux 应用程序容器。应用程序可以“容器感知”创建和管理它们自己的子容器。在谷歌开始和 docker 合作后续转向了 docker 公司的 libcontainerLMCTFY 的于 2015 年停止。
2013 年 Docker 推出到风靡全球
Docker 最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目后来该公司改名为Docker。Docker 在初期与 Warden 类似使用的也是 LXC之后才开始采用自己开发的 libcontainer 来替代 LXC它是将应用程序及其依赖打包到几乎可以在任何服务器上运行的容器的工具。与其他只做容器的项目不同的是Docker 引入了一整套管理容器的生态系统这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等等。 Docker 为提供了一整套的解决方案不仅解决了容器化问题而且解决了分发问题很快被各大厂商选择变成了云基础设施厂商围绕 Docker 也开始了生态建设。
云原生时代
Google Docker 竞争
2013 年 CoreOS 发布和 Docker 由合作终止
技术革命带来新的市场机遇CoreOS 也是其中的一员在容器生态圈中贴有标签 专为容器设计的操作系统 CoreOS。作为互补CoreOSDocker 曾经也是容器部署的灵魂伴侣。CoreOS 为 Docker 的推广和源码社区都做出了巨大的贡献。 Docker 生态扩张与最开始是“一个简单的基础单元”不同Docker 也在通过开发或收购逐步完善容器云平台的各种组件准备打造自己的生态圈而这与 CoreOS 的布局有直接竞争关系。
2014 年 6 月 Google 发布开源的容器编排引擎 KubernetesK8S
容器只是解决了容器化分发问题但是一个软件的网络问题、负载均衡问题、监控、部署、更新、镜像管理、发布等很多问题并没有有效的解决。 Google 内部调度系统 Borg 已经拥有 10 多年的使用容器经验在 2014 年 6 月推出了开源的 K8S,可以支持对容器的编排和管理完成生态的闭环。 同年 7 月微软、Red Hat、IBM、Docker、CoreOS、 Mesosphere 和 Saltstack 等公司相继加入 K8S。之后的一年内VMware、HP、Intel 等公司也陆续加入。
2014 年 12 月 CoreOS 发布开源容器引擎 Rocket(rkt)
2014 年底CoreOS 正式发布了 CoreOS 的开源容器引擎 Rocket简称 rkt和Docker 正式分开发展。Google 于 2015 年 4 月领投 CoreOS 1200 万美元而CoreOS 也发布了 Tectonic成为首个支持企业版本 kubernetes 的公司。从此容器江湖分为两大阵营Google 派系和 Docker 派系。
2015 年 Docker 推出容器集群编排组件 Swarm
在 Docker 1.12 及更高版本中Swarm 模式与 Docker 引擎集成,为 Docker 容器提供原生集群管理功能。 两大派系的竞争愈演愈烈行业标准的诉求越来越强烈。
2015 年 6 月 Docker 成立 OCI
Docker 公司在容器运行因为高速迭代导致变更频繁影响较大。 2015 年 6 月 22 日由 Docker 公司牵头CoreOS、Google、RedHat 等公司共同宣布Docker 公司将 Libcontainer 捐出并改名为 RunC 项目交由一个完全中立的基金会管理然后以 RunC 为依据大家共同制定一套容器和镜像的标准和规范。 RUNC 的本质就是可以不通过 Docker Damon 直接运行容器。 规范就是 OCI旨在“制定并维护容器镜像格式和容器运行时的正式规范OCI Specifications”。其核心产出是 OCI Runtime Spec容器运行时规范、OCI Image Spec镜像格式规范、OCI Distribution Spec镜像分发规范。所以 OCI 组织解决的是容器的构建、分发和运行问题。 社区们期望通过标准来约束 Docker 公司的话语权不过 Docker 公司并没有积极推动OCI 的发展而且 OCI 也无法影响 Docker 的地位因为 Docker 已经是事实的容器标准。 Google 和 RedHat 等公司将方向调转到容器上面的平台层。
2015 年 7 月 Google 带头成立 CNCF
Google 联合 Linux 基金会成立 CNCF Cloud Native Computing Foundation云原生计算基金会。旨在构建云原生基础设施。K8S 是第一个纳入进来的项目像后续有名的监控设施 Prometheus配置设施 ETCD 都加入进来。CNCF 组织解决的是应用管理及容器编排问题。和 OCI 共同制定了一系列行业事实标准。
k8s 成为云原生事实标准
2016 年 发布 CRI 标准
Google 就和红帽主导了 CRI 标准用于 k8s 和特定的容器运行时解耦。CRI(Container Runtime Interface 容器运行时接口)本质上就是 k8s 定义的一组与容器运行时进行交互的接口所以只要实现了这套接口的容器运行时都可以对接 k8s。 但是这个适合 Docker 还是事实标准并 CRI 并没有话语权但是又必须支持 Docker所以就有了 dockershim,dockershim 的本质其实就是 k8s 对接 docker 的一个 CRI 的实现。
2016 年 Docker 捐献 containerd
containerd 作为运行时标准Docker 从 Docker Engine 种剥离出来捐献给 CNCF.这个时候 Google 为了将 containerd 加入到 cri 标准中又开发了 cri-containerd用来完成 k8s 和容器之间的交互。
2016 年 CRI-O 发布
CRI-O 可以让开发者直接从 Kubernetes 来运行容器这意味着 Kubernetes 可以不依赖于传统的容器引擎比如 Docker也能够管理容器化工作负载。容器此时也回归到自己的位置如何更好的封装云原生的程序。 在 2016 年Docker 公司宣布了一个震惊全部人的计划放弃现有的 Swarm 项目将容器编排和集群管理功能所有内置到 Docker 项目中。 而 Kubernetes 的应对策略则是反其道而行之开始在整个社区推动“民主化”架构从API 到容器运行时的每一层Kubernetes 项目都为开发者暴露出了能够扩展的插件机制鼓励用户经过代码的方式介入到 Kubernetes 项目的每个阶段。 在进入 2017 年之后更多的厂商愿意把宝压在 K8S 上投入到 K8S 相关生态的建设中来。这两年包括阿里云、腾讯、百度等中国科技企业也陆续加入 CNCF全面拥抱容器技术与云原生。 Swarm 的失败后, 社区版 Docker 项目改名为 moby将 Docker 引流到 Docker 的企业版上去螳臂挡车。
2017 年 containerd 确定作为标准 CRI
2017 年各大厂商都开始拥抱 Kubernetes亚马逊 AWSMicrosoft AzureVMware有的甚至抛弃了自家的产品。 亚马逊网络服务AWS于八月份以白金会员最高级别加入了 CNCF。 VMware 都作为 CNCF 的白金会员注册. Docker Inc.ocker 企业版框架中添加了本地 Kubernetes 支持。Docker 自己的 Swarm 技术也借鉴了 k8s 的技术进一步发展。 Kubernetes 已成了容器编排领域的绝对标准 Docker 已成容器事实的标准。
编排与容器的技术演进之路
核心问题容器哪些技术过时了
DockerClient
此时 K8s 只是编排领域的一个选择而 Docker 此时一家独大所以 K8s 的客户端只是作为 Docker 的客户端来调用 Docker 引擎来完成服务。
RUNCShim
OCI 催生 runc剥离 Docker Engine 的一家独大的情况确保各个厂商都可以搭建自己的容器平台。CRI 标准确立了但是 Docker 并没有接入该标准。此时催生了临时技术shim.
CRI-Containerd
containerd 被捐献出来谷歌开发 cri-containerd 接入 CRI 标准。 CRI-O
k8s 已经成为事实的编排标准促使容器回归云原生本质。
Containerd
containerd 实现 CRI成为 CRI 的事实标准 实际生产的集群采用的什么运行时组件 以腾讯的 TKE腾讯商用 K8S 产品)为例支持选择 containerd 和 docker 两种模式的选择。 如何选择呢
Containerd 调用链更短组件更少更稳定占用节点资源更少。建议选择Containerd。以下情况还是要用 docker • 使用 docker build/push/save/load 等命令。 • 调用 docker API • 需要 docker compose 或 docker swarm。
