容器相关
开展史概括
- 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。
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等，协助开发人员更快更好的构建出色的产品。
阿里云云原生全景图
|
