云原生技术概述

云原生

　　云原生技术是一套体系或者说是一套方法论。

　　云原生（Cloud Native）的概念，由来自Pivotal的MattStine于2013年首次提出，被一直延续使用至今。

　　这个概念是Matt Stine根据其多年的架构和咨询经验总结出来的一个思想集合，并得到了社区的不断完善，内容非常多，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）和12要素（The Twelve-Factor App）等几大主题，不但包括根据业务能力对公司进行文化、组织架构的重组与建设，也包括方法论与原则，还有具体的操作工具。采用基于云原生的技术和管理方法，可以更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续的服务能力。

　　2018年CNCF重定义:云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。结合可靠的自动化手段，云原生技术可进行频繁并可预测的变更。

　　原文地址： https://www.pianshen.com/article/79641202896/

云原生设计理念

云原生系统的设计理念如下:

面向分布式设计（Distribution）：容器、微服务、API驱动的开发；
面向配置设计（Configuration）：一个镜像，多个环境配置；
面向韧性设计（Resistancy）：故障容忍和自愈；
面向弹性设计（Elasticity）：弹性扩展和对环境变化（负载）做出响应；
面向交付设计（Delivery）：自动拉起，缩短交付时间；
面向性能设计（Performance）：响应式，并发和资源高效利用；
面向自动化设计（Automation）：自动化的 DevOps；
面向诊断性设计（Diagnosability）：集群级别的日志、metric 和追踪；
面向安全性设计（Security）：安全端点、API Gateway、端到端加密；

图为其公布的Cloud Native Landscape，给出了云原生生态的参考体系。

云原生四要素

持续交付、DevOps、微服务、容器

持续交付
- 缩小开发者认知，灵活开发方向
微服务
- 内聚更强，更加敏捷
容器技术
- 使资源调度、微服务更容易
DevOps
- 以终为始，运维合一

　　云原生的DevOps、容器技术、持续交付、微服务都是云原生不可或缺的一部分，需要以全局地眼光看待问题，脱离任何一个元素，对于企业来说都是“管中窥豹”、“一叶障目”，只有加以整合才能见到云原生的全局风貌。

　　面对业态各异的业务上云以及碎片化的物联网解决方案部署，利用云原生思维和模式，构建基于云原生的物联网平台以及解决方案，势必将加速企业，甚至整个社会的数字化转型。

云原生应用的关键属性

打包为轻量级容器：云原生应用程序是打包为轻量级容器的独立自治服务的集合。与虚拟机不同，容器可以快速扩缩容。将扩展单元转移到容器，能够优化基础架构利用率。
使用最佳语言和框架开发：云原生应用程序的每项服务都是使用最适合该功能的语言和框架开发的。云原生应用程序是多语言的，服务会使用各种不同的语言、运行时和框架。例如，开发人员可以构建基于在Node.js中开发的WebSockets的实时流服务，同时选择Python和Flask来暴露API。开发微服务的细粒度方法使它们能够为特定任务选择最佳语言和框架。
设计为松耦合的微服务：属于同一应用程序的服务通过应用程序运行时来发现彼此。它们独立于其他服务而存在。正确集成时，弹性基础架构和应用程序架构可以高效地、以高性能来进行扩展。松耦合的服务让开发人员可以在处理每个服务时都能够独立于其他服务来工作。通过这种分离，开发人员可以专注于每项服务的核心功能，以提供细粒度的功能。这种方法可以实现整个应用程序的有效生命周期管理，因为每个服务都是独立维护的，并且拥有明确的所有权。
以API为中心进行交互和协作：云原生服务使用轻量级API，这些API基于REST、gRPC或NATS等协议。REST通常被用作通过HTTP公开API的最低公分母。为了提高性能，gRPC通常用于服务之间的内部通信。NATS具有发布-订阅功能，可在应用程序内实现异步通信。
在架构中将无状态和有状态服务清晰分离：持久耐用的服务通常遵循不同的模式，以确保更高的可用性和弹性。无状态服务和有状态服务是彼此独立存在的。存储会影响容器的使用。我们必须越来越多地在有状态、无状态、微存储环境（这一点有些人可能觉得有争议）等不同语境下考虑持久性这一因素。
与服务器和操作系统依赖关系隔离：云原生应用程序与任何特定操作系统或单个计算机没有关联。它们在更高的抽象级别上运行。唯一的例外是微服务需要某些功能，包括固态驱动器（SSD）和图形处理单元（GPU），这些功能可能由一部分机器专门提供。
部署在自服务的弹性云基础架构上：云原生应用程序部署在虚拟的、共享的和弹性的基础架构上。它们可以与底层基础架构保持一致，以动态增长和缩小——根据不同的负载来自我调节。
通过敏捷DevOps流程进行管理：云原生应用程序的每项服务都会经历一个独立的生命周期，通过敏捷的DevOps流程进行管理。多个持续集成／持续交付（CI / CD）流水线可以协同工作以部署和管理云原生应用程序。
自动化功能：云原生应用程序可以高度自动化。它们与Infrastructure as Code的概念相得益彰。企业需要一定程度的自动化来管理大型和复杂的应用程序。
定义的、策略驱动的资源分配：最后，云原生应用程序与通过一组策略定义的治理模型一致。它们遵循CPU和存储配额以及将资源分配给服务的网络策略等策略。例如，在企业方案中，中央IT可以定义策略来为每个部门分配资源。每个部门的开发人员和DevOps团队都拥有对其资源共享的完全访问权和所有权。

“云原生”应用价值

　　从CNCF的定义来看，采用基于云原生的技术和管理方法，将更好地把业务生于“云”或迁移到云平台，从而享受“云”的高效和持续服务能力。

1）快速迭代

　　利用云原生应用程序开发，意味着使用敏捷与可扩展的组件，如以Kubernetes为代表的容器来提供离散和可重用的功能，这些功能以良好描述的方式集成，甚至跨越多云等技术边界，这使得交付团队可以使用重复的自动化和编排来快速迭代。

2）自动部署

　　云原生方法远优于传统的面向虚拟化的业务流程，传统方法需要投入大量的精力来构建开发环境，以及软件交付过程中的其他不同环境。而云原生架构具备自动化和组合功能，并且依赖于可靠、经过验证和审核的已知良好流程的基础，交付十分敏捷，而不再需要人工干预重复执行。

3）独立高效

　　云原生带来了微服务化架构，一个微服务基本是一个能独立发布的应用服务，因此可以作为独立组件升级、灰度或复用等，对整个大应用的影响也较小，每个服务可以由专门的组织来单独完成，依赖方只要定好输入和输出口即可完全开发、甚至整个团队的组织架构也会更精简，因此沟通成本低、效率高。

容器技术

　　容器技术催生了云原生思潮，云原生生态推动了容器技术发展。从 2013 年 docker（container）技术诞生，到 2015 年 CNCF 这个云原生领域重量级联盟便成立，这不是历史的巧合而是历史的必然。作为云原生关键技术之一的容器，从 2013 年诞生以来一直是行业关注的焦点之一。

容器技术的演进

1979 年，Unix v7 系统支持 chroot，为应用构建一个独立的虚拟文件系统视图。
1999 年，FreeBSD 4.0 支持 jail，第一个商用化的 OS 虚拟化技术。
2004 年，Solaris 10 支持 Solaris Zone，第二个商用化的 OS 虚拟化技术。
2005 年，OpenVZ 发布，非常重要的 Linux OS 虚拟化技术先行者。
2004 年 ~ 2007 年，Google 内部大规模使用 Cgroups 等的 OS 虚拟化技术。
2006 年，Google 开源内部使用的 process container 技术，后续更名为 cgroup。
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....

容器技术的环境隔离

进程隔离。OS 以进程作为 Task 运行过程的抽象，进程拥有独立的地址空间和执行上下文，本质上 OS 对进程进行了 CPU 和内存虚拟化。但是进程之间还共享了文件系统、网络协议栈、IPC 通信空间等多种资源，进程之间因为资源争抢导致的干扰很严重。这个层级的隔离适合在不同的主机上运行单个用户的不同程序，由用户通过系统管理手段来保证资源分配与安全防护等问题。
OS 虚拟化。OS 隔离，也就是大家常说的操作系统虚拟化（OS virtualization），是进程隔离的升华版。进程隔离是为每个进程实现了单独的地址空间及 CPU 上下文，OS 隔离则是利用操作系统分身术为每一组进程实例构造出一个独立的 OS 环境，以进一步虚拟化文件系统、网络协议栈、IPC 通信空间、进程 ID、用户 ID 等 OS 资源。OS 隔离需要解决三个核心问题：独立视图、访问控制及安全防护。Chroot、Linux namespace 机制为进程组实现独立视图，cgroup 对进程组进行访问控制，而 Capabilities、Apparmor、seccomp 等机制则实现安全防护。当然，OS 是一个非常复杂、动态变化的系统，OS 分身术虽然让进程组感觉有了独立的 OS，但是真实实现还是一个 OS 实例，所以整体防护能力还是堪忧。
硬件虚拟化。OS 虚拟化是实现 OS 内核的分身术，而硬件虚拟化则是实现硬件设备的分身术。硬件虚拟化技术的出现，让同一个物理服务器上能够同时运行多个操作系统，每个操作系统都认为自己在管理一台完整的服务器。不同操作系统之间是严格隔离的，Guest 操作系统对硬件的访问都是受 VMM 或 CPU 的严格监管的。硬件虚拟化既有很好的安全性，也有很好的隔离性，缺点就是引入的硬件虚拟化层导致了额外的性能开销。
硬件分区。这个是传统小型机体系采用的资源分隔技术，就是从硬件或固件层彻底把一台大型服务器分隔为多个硬件单元，从而获得最高等级的安全性和隔离性。但是小型机作为一个逐步没落的技术路线，其不足之处还是显而易见的：资源分隔粒度不灵活、系统成本偏高、系统可扩展性受限。
语言运行时隔离。对于 Java、nodejs 等需要 language runtime 的 managed language，我们还有一个选项，就是在 language runtime 里实现隔离。针对函数计算等云原生服务，理论上在语言运行时实现隔离机制是最优路径。但是这条路线目前实现上还有不少现实的制约，所以目前多数函数计算还是采用的容器 / VM 技术来实现的隔离。

Docker容器技术

docker的组成

Docker Client 客户端
Docker daemon 守护进程
Docker Image 镜像
Docker Container 容器
Docker Registry 仓库

客户端和守护进程：

Docker是C/S（客户端client-服务器server）架构模式。
docker通过客户端连接守护进程，通过命令向守护进程发出请求，守护进程通过一系列的操作返回结果。
docker客户端可以连接本地或者远程的守护进程。
docker客户端和服务器通过socket或RESTful API进行通

docker对比虚拟机

	docker	VM
启动速度	秒级	分钟
运行性能	接近原生	百分之 95
磁盘占用	MB	GB
数量	成百上千	约十几台
隔离能力	进程级别	系统级别
操作系统	只支持 Linux	几乎所有
封装程度	只打包项目代码和依赖关系	完整操作系统

容器 runtime

　　runtime 是容器真正运行的地方，runtime 需要跟操作系统 kernel 紧密协作，为容器提供环境。

　　runtime 主要定义以下规范，并以 json 格式保存在 /run/docker/runtime-runc/moby/容器ID/state.json 文件中。此文件回根据容器的状态实时更新。

版本信息
- 存放OCI标准的具体版本号
容器ID
- 通常是一个哈希值，可以在所有 state.json 文件中提取出容器ID对容器进行批量操作（关闭，删除等。），此文件在容器关闭后会被删除，容器启动后会自动生成。
PID
- 在容器运行的首个进程在宿主机上的进程信号，将宿主机的那个进程设置为容器的守护进程。
容器文件目录
- 存放容器 rootfs 及响应配置的目录，外部程序只需读取state.json就可以定位到宿主机上的容器文件目录。
容器创建
- 创建包括文件系统， namespaces， cgroups ，用户权限在哪的各项内容。
容器进程的启动
- 运行容器启动进程，该文件在 /run/containerd/io.containerd.runtime.v1.linux/moby/容器ID/config.json
容器生命周期
- 容器进程可以被外部程序关停，runtime规范定义了对容器操作信号的捕捉，并做相应资源回收的处理，避免僵尸进程的出现

docker 容器镜像

Image Layer（镜像层）

　　镜像可以看成是由多个镜像层叠加起来的一个文件系统（通过UnionFS与AUFS文件联合系统实现），镜像层也可以简单理解为一个基本的镜像，而每个镜像层之间通过指针的形式进行叠加。

　　根据上图，镜像层的主要组成部分包括镜像层 ID、镜像层指针「指向父层」、元数据「 Layer Metadata，包含了 Docker 构建和运行的信息和父层的层次信息」。只读层和读写层「Top Layer」的组成部分基本一致，同时读写层可以转换成只读层「通过docker commit 操作实现」。

　　元数据（metadata）就是关于这个层的额外信息，它不仅能够让Docker获取运行和构建时的信息，还包括父层的层次信息。需要注意，只读层和读写层都包含元数据。

　　每一层都包括了一个指向父层的指针。如果一个层没有这个指针，说明它处于最底层。

　　Metadata Location:
　　在docker主机中镜像层（image layer）的元数据被保存在名为”json”的文件中，比如说：

/var/lib/docker/graph/e809f156dc985.../json             ##e809f156dc985...就是这层的id

　　一个容器的元数据好像是被分成了很多文件，但或多或少能够在/var/lib/docker/containers/<id>目录下找到，<id>就是一个可读层的id。这个目录下的文件大多是运行时的数据，比如说网络，日志等等。

Image（镜像，只读层的集合）

　　镜像是一堆只读层的统一视角，除了最底层没有指向外，每一层都指向它的父层。统一文件系统（ Union File System）技术能够将不同的层整合成一个文件系统，为这些层提供了一个统一的视角，这样就隐藏了多层的存在。在用户的角度看来，只存在一个文件系统。镜像每一层都是不可写的，都是只读层。

　　我们可以看到镜像包含多个只读层，它们重叠在一起。除了最下面一层，其它层都会有一个指针指向下一层。这些层是Docker内部的实现细节，并且能够在docker主机的文件系统上访问到。统一文件系统（union file system，升级版为AUFS）技术能够将不同的层整合成一个文件系统，为这些层提供了一个统一的视角，这样就隐藏了多层的存在，在用户的角度看来，只存在一个文件系统。我们可以在图片的右边看到这个视角的形式。
　　你可以在你的主机文件系统上找到有关这些层的文件。需要注意的是，在一个运行中的容器内部，这些层是不可见的。在我的主机上，我发现它们存在于/var/lib/docker/aufs目录下。

sudo tree -L 1 /var/lib/docker/
/var/lib/docker/
├── aufs
├── containers
├── graph
├── init
├── linkgraph.db
├── repositories-aufs
├── tmp
├── trust
└── volumes
7 directories, 2 files

docker 仓库

　　仓库（Repository）是集中存放镜像的地方。

　　Image registry： docker 官方提供的私有仓库部署工具。

　　Docker hub： docker 官方的公共仓库，已经保存大量常用镜像。

　　Harbor： vmware 提供的自带web界面认证功能的仓库，目前由很多公司使用。

容器编排工具

容器编排工具概念
- 当容器数量达到一定规模，就需要编排工具去管理，就是容器生命周期管理工具。容器编排工具提供调度和管理集群的技术，提供用于基于容器应用可扩展性的基本机制。这些工具使用容器服务，并编排他们以决定容器之间如何进行交互。
容器编排工具的核心价值
- 准备和部署容器
- 容器的高可用和负载均衡
- 应用规模的自动扩缩容
- 底层硬件故障，能够把容器迁移到其他节点上，用户无感知。
- 容器资源分配
- 容器的注册与自动发现
- 容器和宿主机的健康检查
- 容器配置和存储管理
容器编排工具种类
- Docker Swarm：docker自己的容器编排工具。
- Apache Mesos and Marathon：Mesos是一个数据中心的资源统一管控的工具，本身没有编排容器的功能，需要和Marathon结合使用。
- Kubernetes： google领导开发的容器编排引擎，内部项目为Borg。