容器相关

发展史概括

1979年，Unix v7系统支持chroot，为应用构建一个独立的虚拟文件系统视图。
1999年，FreeBSD 4.0支持jail，第一个商用化的OS虚拟化技术。
2004年，Solaris 10支持Solaris Zone，第二个商用化的OS虚拟化技术。
2005年，OpenVZ发布，非常重要的Linux OS虚拟化技术先行者。
2006年，Google开源内部使用的process container，后续更名为cgroup。
2004年 ~ 2007年，Google 内部大规模使用 Cgroups 等的OS虚拟化技术。
2008年，Cgroups 进入了 Linux 内核主线。
2008年，LXC（Linux Container）项目具备了Linux容器的雏型。
2011年，CloudFoundry开发Warden系统，一个完整的容器管理系统雏型。
2013年，Google通过Let Me Contain That For You (LMCTFY) 开源内部容器系统。
2013年，Docker项目正式发布，让Linux容器技术逐步席卷天下。
2014年，Kubernetes项目正式发布，容器技术开始和编排系统起头并进。
2015年，由Google，Redhat、Microsoft及一些大型云厂商共同创立了CNCF，云原生浪潮启动。
2016年-2017年，容器生态开始模块化、规范化。CNCF接受Containerd、rkt项目，OCI发布1.0，CRI/CNI得到广泛支持。
2017年-2018年，容器服务商业化。AWS ECS，Google EKS，Alibaba ACK/ASK/ECI，华为CCI，Oracle Container Engine for Kubernetes；VMware，Redhat和Rancher开始提供基于Kubernetes的商业服务产品。
2017年-2019年，容器引擎技术飞速发展，新技术不断涌现。2017年底Kata Containers社区成立，2018年5月Google开源gVisor代码，2018年11月AWS开源firecracker，阿里云发布安全沙箱1.0。
2020年-202x年，容器引擎技术升级，Kata Containers开始2.0架构，阿里云发布沙箱容器2.0…

隔离思路

衍生容器规范

OCI Runtime Spec：容器运行时规范，旨在指定容器的配置、执行环境和生命周期。容器的配置文件指定命名为 config.json，并包含了容器的一系列配置信息。定义执行环境是为了确保在容器内运行的应用程序与运行时具备一致的环境，以及为容器的生命周期管理定义了标准的公共操作。 
OCI Image Spec：镜像格式规范，由 4 块内容组成：清单（manifest）、镜像索引（image index）、配置（configuration）和文件系统层（filesystem layers）。清单描述了镜像的元数据。镜像索引是可选的，指向不同平台的 manifest 文件，相当于整个镜像的入口，从这个文件可以获取整个镜像依赖的所有文件信息。配置保存了文件系统的层级信息，以及容器运行时需要的一些信息。文件系统层描述了如何以 layer 的方式叠加成一个完整的文件系统，以及如何用 layer 去表示对文件作出的改动。 
OCI Distribution Spec：镜像分发规范，定义了一套 API 协议用来促进和标准化内容的分发。
CRI：Container Runtime Interface，容器运行时接口，是容器编排系统和容器引擎之间交互的接口。 
CNI：Container Network Interface，容器网络接口，由一组用于配置 Linux 容器的网络接口的规范和库组成，同时还包含了一些插件。仅关心容器创建时的网络分配，和当容器被删除时释放网络资源。接口只有四个方法：添加网络、删除网络、添加网络列表、删除网络列表。 
CSI：Container Storage Interface，容器存储接口，是容器编排系统与容器存储系统之间交互的接口。 Shimv2：这是用来对接基于虚拟机的容器（如 Kata）的接口规范。
这些规范确立之后，基于这些标准规范的具体实现不断涌现，呈现出一片百花齐放的景象。Docker 也为了适应 OCI 标准规范而剥离出来了两个标准化的组件，一个叫 runc，一个叫 containerd。下面再来了解下这两个组件。

容器运行流程

1.下载镜像

2.解压镜像到文件系统包中

3.从解压的文件系统包上运行容器

老版交付和容器交付

服务相关

Iaas pass saas

它们有什么区别呢？
IBM 的软件架构师 Albert Barron 曾经使用披萨作为比喻，解释这个问题。David Ng 进一步引申，让它变得更准确易懂。
请设想你是一个餐饮业者，打算做披萨生意。
你可以从头到尾，自己生产披萨，但是这样比较麻烦，需要准备的东西多，因此你决定外包一部分工作，采用他人的服务。你有三个方案。
（1）方案一：IaaS
他人提供厨房、炉子、煤气，你使用这些基础设施，来烤你的披萨。
（2）方案二：PaaS
除了基础设施，他人还提供披萨饼皮。
你只要把自己的配料洒在饼皮上，让他帮你烤出来就行了。也就是说，你要做的就是设计披萨的味道（海鲜披萨或者鸡肉披萨），他人提供平台服务，让你把自己的设计实现。
（3）方案三：SaaS
他人直接做好了披萨，不用你的介入，到手的就是一个成品。你要做的就是把它卖出去，最多再包装一下，印上你自己的 Logo。

Iaas->pass->saas

Ipaas apaas

iPaaS则趋向于IaaS和PaaS之间

Ø由于企业堆叠的各种SaaS软件，用着不同的主机和数据库，怎么将这些软件集成起来？这就需要一种技术，也就是iPaaS。

Ø解决企业里各个软件造成的壁垒问题，减轻IT任务量——ipaas

Ø以打通为中心，集成和管理现有平台。

aPaaS趋向于PaaS和SaaS之间

Ø怎么才能提供一种框架，让业务人员不需要学代码就能自己设计出一个管理软件呢？这种模式就是apaas，从应用和数据层面入手，设计搭建工具与逻辑，实现零代码开发。

Ø满足企业追求的灵活但要性价比高的软件开发，降低开发门槛——apaas

Serverless（BaaS、FaaS）

什么是Serverless架构呢？

按照CNCF对Serverless计算的定义，Serverless架构应该是采用FaaS（函数即服务）和BaaS（后端服务）服务来解决问题的一种设计,是一种包含但不仅限于的关系。

BaaS（Backend as a Service，后端即服务）是指我们不再编写和/或管理所有服务端组件 例如：人脸识别，消息发送等。

FaaS（Function as Service，也即函数即服务）例如：aws Lambda（serverless架构） 

云原生初识

定义

要素

微服务：微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。

容器化：容器化为微服务提供实施保障，起到应用隔离作用。

DevOps：开发和运维合体，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

服务网格：服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。Service Mesh组件。

云原生发展阶段概括

CNCF全景图

CNCF，全称Cloud Native Computing Foundation（云原生计算基金会），口号是 坚持和整合开源技术来编排容器作为微服务架构的一部分 ，其作为致力于云原生应用推广和普及的一支重要力量，不论您是云原生应用的开发者、管理者还是研究人员都有必要了解。

CNCF作为一个厂商中立的基金会，致力于Github上的快速成长的开源技术的推广，如Kubernetes、Prometheus、Envoy等，帮助开发人员更快更好的构建出色的产品。

阿里云云原生全景图