容器简史

  随着容器技术越来越火，那么了解容器是必要，下面简述一下容器的发展历史。

1979年—Unix V7

  在1979年Unix V7引入了chroot系统调用，为每个进程提供一个独立的磁盘空间，将一个进程及其子进程的根目录改变到文件系统中的新位置，让这些进程只能访问到该目录。这个被隔离出来的新环境被叫做 Chroot Jail。这标志着进程隔离的开始，隔离每个进程的文件访问权限。

不过chroot只是进行了进程的文件访问权限，隔离的并不全面，没有进程网络、domain等信息的隔离

2000年—FreeBSD Jails

  在2000年，FreeBSD操作系统正式发布FreeBSD jails隔离环境，实现了进程的沙箱化。提供了文件系统、用户、网络等隔离功能。

  这种沙箱的实现，依靠的是操作系统级别的隔离与限制能力而非硬件虚拟化技术。FreeBSD Jails允许管理员将FreeBSD计算机系统划分为几个独立的、较小的系统，称为“ jails”，并能够为每个系统和配置分配IP地址，可以对软件的安装和配置进行定制。

2001年—LinuxVServer

  与FreeBSD Jails一样，Linux VServer也是一种类似上述Jails机制，可以对计算机系统上的资源（文件系统，网络地址，内存）进行分区。每个所划分的分区叫做一个安全上下文（security context），在其中的虚拟系统叫做虚拟私有服务器（virtualprivate server，VPS）。该操作系统虚拟化于2001年推出，通过修补Linux内核来实现，测试性补丁目前仍然可用，但最后一个稳定的修补程序于2006年发布。

2004年—Solaris容器

  2004年Oracle发布了Oracle Solaris Containers，由系统资源控制和通过 zones 提供的边界分离（boundary separation）所组合而成的。zones 是一个单一操作系统实例中的完全隔离的虚拟服务器。

2005年——Open VZ（Open Virtuzzo）

  Linux操作系统级虚拟化技术，它通过Linux内核补丁形式进行虚拟化、隔离、资源管理和状态检查。每个 OpenVZ 容器都有一套隔离的文件系统、用户及用户组、进程树、网络、设备和 IPC 对象。

操作系统级虚拟化有一些限制，因为容器共享相同的体系结构和内核版本，当客户需要不同于主机的内核版本的情况下这种缺点就会显现出来。

2006年—Process Containers

  Google在2006年推出Process Containers，用于计算和隔离一系列流程的资源使用（CPU、内存、磁盘I / O、网络）。一年后，为了避免和 Linux 内核上下文中的“容器”一词混淆而改名为 ControlGroups简称Cgroups，并最终合并到Linux内核2.6.24中。

2008年—LXC

  Linux容器（LXC）是第一个、最完整的Linux容器管理器的实现方案。2008年时候，通过将 Cgroups 的资源管理能力和 Linux Namespace 的视图隔离能力组合在一起，LXC完整的容器技术出现在了 Linux 内核当中，并且可以在单个Linux内核上运行而无需任何补丁。

LXC 存在于 liblxc库中，提供了各种编程语言的 API 实现，包括 Python3、Python2、Lua、Go、Ruby 和 Haskell。现在 LXC project 是由 Canonical 公司赞助并托管的。

2011年—Warden

  Warden是由CloudFoundry在2011年成立，这是一个管理隔离，短暂存在和被资源控制的环境的API。可以为任何系统提供隔离运行环境。Warden以后台保护程序运行，而且能够提供用于容器管理的API。它开发了一个CS（客户端-服务端）模型来管理跨多个主机的容器集群，并且Warden提供用于管理cgroup，名称空间和进程生命周期的相关服务。

在其第一个版本中，Warden使用了LXC，之后替换为他们自己的实现方案。不像 LXC，Warden 并不紧密耦合到 Linux 上，

2013年—LMCTFY

  LMCTFY 是2013年Google容器技术的开源版本开始，提供Linux应用程序容器，旨在提供性能可保证的、高资源利用率的、资源共享的、可超售的、接近零消耗的容器。

  在2015年，Google开始向由Docker发起的Libcontainer贡献LMCTFY核心概念之后，LMCTFY在2015年主动停止部署，Libcontainer现在是Open Container Foundation（开放容器基金会）的一部分。

2013年—Docker

  随着2013年Docker的出现，容器开始迅速普及。它最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目，后来该公司改名为 Docker。Docker的增长并非偶然，它引入了一整套管理容器的生态系统，包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等。
  跟Warden一样，Docker开始阶段使用的也是LXC，后来用自己的库libcontainer进行替换。Docker 推动实现了一个叫做 Docker Swarm 的容器集群管理方案。

docker之所以会爆发式火爆是因为加入了镜像功能，并且封装了镜像仓库使得镜像分发更加方便

2014年—Rocket

  Rocket 是由 CoreOS 所启动的项目，非常类似于 Docker，但是修复了一些 Docker 中发现的问题。CoreOS 初衷是旨在提供一个比 Docker 更严格的安全性和产品需求。更重要的是，它是在一个更加开放的标准 AppContainer 规范上实现的。在 Rocket 之外，CoreOS也开发了其它几个可以用于 Docker 和 Kubernetes的容器相关的产品，如：CoreOS 操作系统、etcd 和flannel。

2016年—Windows Containers

  2015 年，微软在 Windows Server 上为基于 Windows 的应用添加了容器支持，称之为 Windows Containers。它与 Windows Server 2016 一同发布，Docker 可以原生地在 Windows 上运行 Docker 容器，而不需要启动一个虚拟机来运行 Docker。

Windows 上早期运行 Docker 需要使用 Linux 虚拟机

2017年—容器工具日趋成熟

  在2017年以前，市场上已经有上百种工具用来管理容器，这些类型的工具已经存在多年了，但2017年是其中许多工具脱颖而出的一年。例如Kubernetes，自2016年被纳入Cloud Native Computing Foundation（CNCF）以来，VMWare，Azure，AWS甚至Docker都宣布在其基础架构之上提供相关支持。

  随着容器市场的发展和增长，一些工具已经开始定义容器的某些功能。Ceph和REX-Ray为容器存储设定了标准，在CI / CD中，Jenkins完全改变了构建和部署应用程序的方式。

  随着2017年，CoreOS和Docker联合提议将rkt和containerd作为新项目纳入CNCF，这标志容器生态系统初步形成，容器项目之间协作更加丰富。

  从 Docker 最初宣布将剥离其核心运行时到2017年捐赠给 CNCF 协会，“containerd”项目在过去两年经历了显著的增长和进步。Docker 捐赠的主要目的是通过提供一个核心容器运行时来促进容器生态系统的进一步创新，容器系统供应商和编排项目(如 Kubernetes、Swarm 等)可以利用这个核心容器运行时。“containerd”的一个重要设计原则是可以对 Kubernetes 提供一流的支持，但又不完全依赖于 Kubernetes，这也为许多容器的用例如 developer desktop、CI/CD、单节点部署、edge 和物联网打开了新的大门。

2018年—越来越规范

  容器化成为现代软件基础架构的基础，而Kubernetes被用于大多数企业容器项目。在2018年，GitHub上的Kubernetes项目有1500多个贡献者，是最重要的开源社区之一，拥有27000多颗星。

  Kubernetes的广泛采用推动了诸如AWS云供应商提供托管的Kubernetes服务。此外，VMWare，RedHat和Rancher等领先的软件供应商也开始提供基于Kubernetes的管理平台。

2019年—历史变革

  2019年是容器发生历史性变革的一年，在这一年发生了很多历史性变革事件，包括容器生态变化、产业资本并购、新技术解决方案出现等等。

  在这一年新的运行时引擎开始替代docker运行引擎，其最具代表性新引擎就是CNCF的Containerd和CRI-O（一个用于Kubernetes的轻量级运行时）。CRI-O可以让用户直接从 Kubernetes 运行容器，而不需要任何不必要的代码或工具。只要容器符合 OCI 标准，CRI-O 就可以运行它。

  在2019年，产业方面也发送了巨大变化，Docker Enterprise卖给了Mirantis（一家专注于OpenStack、Kubernetes的云计算公司）。同时，也可以看到虽然rkt已经正式成为CNCF一部分但是其普及率正在逐步下降。此外，VMware先后收购了Heptio和Pivotal Software（包括PAS和PKS），此举可以更好帮助企业客户建立并运行基于Kubernetes的容器化架构。其中 Heptio公司是由两位曾在2014年帮助谷歌联合建立Kubernetes项目的主力（当时的项目负责人共有三名）共同建立，创始人及其团队都将一同加盟VMware公司。如此清晰的创始人背景，可能意味着VMware有意在Kubernetes领域发动全面冲击，甚至预示VMware已经把Kubernetes视为企业业务运营的根本性基石之一

  2019年容器技术领域也出现了新的变革，FaaS或Serverless（‘函数’或者‘无服务器’）已经成为一种新的抽象趋势。其允许开发人员更轻松地运行并部署代码片段，且这些代码片段将能够快速实现规模伸缩以响应事件需求。例如，企业只要使用由Google与Pivotal、IBM、红帽和SAP等企业共同开发的跨云Serverless管理平台Knative，就能在支持Kubernetes的云平台上自由的迁移工作负载，无论是跨私有云或是公有云及各种混合云架构都没问题。

  2019也出现了基于Kubernetes -混合云解决方案，如IBM CloudPaks，谷歌Anthos，AWS Outposts，和Azure Arc。这些云平台模糊了云环境与本地环境之间的传统界限，可以更方便管理本地和供应商云服务。

  Kubernetes 现在已经成为了构建容器化平台体系的默认抽象方案，上诉这些新功能的出现也代表着Kubernetes下一步演进方向，诸如Anthos，Arc和Outposts之类超抽象。在超抽象中，计算资源从管理层解耦，类似于Kubernetes的工作方式，它将工作负载从管理层解耦。

2020年—容器安全急需解决

  容器作为一种轻量级的虚拟化技术，使用方便，操作便捷，大大提高了开发人员的工作效率，得到了业内的广泛使用。但与此同时，容器安全事故频发，包括不安全的镜像源、容器入侵事件、运行环境的安全问题等等。

不安全的镜像源

  开发者通常会在Docker 官方的Docker Hub仓库下载镜像，这些镜像一部分来源于开发镜像内相应软件的官方组织，还有大量镜像来自第三方组织甚至个人。在从这些镜像仓库中获取镜像的同时，也带来了潜在的安全风险。例如，下载镜像内软件本身是否就包含漏洞，下载的镜像是否被恶意的植入后门，镜像在传输过程中是否被篡改。

容器入侵事件

  由docker本身的架构与机制可能产生的问题，这一攻击场景主要产生在黑客已经控制了宿主机上的一些容器（或者通过在公有云上建立容器的方式获得这个条件），然后对宿主机或其他容器发起攻击来产生影响。

运行环境的安全

  除了docker 本身存在的问题以外，docker的运行环境存在的问题同样会给docker的使用带来风险。

  由于容器是介于基础设施和平台之间的虚拟化技术，因此面向基础设施虚拟化的传统云安全解决方案无法完全解决前述安全问题。如以容器为支撑技术构建DevOps环境，就需要设计涵盖从容器镜像的创建到投产上线的整个生命周期的容器安全方案。

  目前，市场上涌现了一批容器安全产品安全厂商，如Neuvector、Twistlock、StackRox、Aqua等等。从容器安全产品的技术方案上来看，目前大部分的容器安全厂商均使用了平行容器的方式对宿主机上的容器进行安全防护，而青藤云安全则采取了基于宿主机Agent的方式。

  平行容器技术方案：利用容器的隔离性和良好的资源控制能力，在容器的宿主机中启动一个容器，该容器通过挂载宿主机的所有文件系统，而后在容器内部对这些文件系统进行实时监控和处理响应，以实现对容器进行防护的作用。

  基于宿主机Agent的技术方案：即基于青藤Agent的主机防护能力，监控宿主机上容器相关的文件、进程、系统调用等等信息，增加其Agent中对于容器的清点、监控、防护能力，以实现一个Agent，实现宿主机安全、容器安全两种防护的效果。

借鉴地址