1.简介

1.1 云原生介绍

1.1.1 云原生简介

• 2004年开始，Google已在内部大规模地使用容器技术。
• 2008年，Google将Cgroups合并进入了Linux内核。
• 2013年，Docker项目正式发布。
• 2014年，Kubernetes项目正式发布。https://kubernetes.io/
• 2015年，由Google、Redhat以及微软等大型云计算厂商以及一些开源公司牵头成立了CNCF（Cloud Native Computing Foundation）云原生计算基金会。
• 2017年，CNCF达到170个成员和14个基金项目。
• 2018年，CNCF成立三周年有了195个成员，19个基金会项目和11个孵化项目。

1.1.2 云原生定义

https://github.com/cncf/toc/blob/main/DEFINITION.md#中文版本

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

1.1.3 云原生技术栈

• 容器：以docker为代表的容器运行计算。
• 服务网格：比如Service Mesh等。
• 微服务：在微服务体系结构中，一个项目是由多个松耦合且可独立部署的较小组件或服务组成。
• 不可变基础设施：不可变技术设施开源理解为一个应用运行所需要的基本运行需求，不可变最基本的就是指运行服务的服务器在完成部署后，就不在进行更改，比如镜像等，
• 声明式API：描述应用程序的运行状态，并且由系统来决定如何来创建这个环境，例如声明一个pod，会有k8s执行创建并维持副本。

1.1.4 云原生特性

• 符合12因素应用，12要素应用程序是一种构建应用程序的方法。
• 面向微服务架构。
• 自服务敏捷架构。
• 基于API的协作。
• 抗脆弱性

1.1.5 12因素应用

1. 基准代码：一份基准代码，多份部署（用同一个代码库进行版本控制，并可进行多次部署）。
2. 依赖：显式地声明和隔离相互之间的依赖。
3. 配置：在环境中存储配置。
4. 后端服务：把后端服务当作一种附加资源。
5. 构建，发布，运行：对程序执行构建或打包，并严格分离构建和运行。
6. 进程：以一个或多个无状态进程运行应用。
7. 端口绑定：通过端口绑定提供服务。
8. 并发：通过进程模型进行扩展。
9. 易处理：快速地启动，优雅地终止，最大程度上保持健壮性。
10. 开发环境与线上环境等阶：尽可能的保持开发，预发布，线上环境相同。
11. 日志：将所有运行中进程和后端服务的输出流按照时间顺序统一收集存储和展示。
12. 管理进程：一次性管理进程（数据备份等）应该和正常的常驻进程使用同样的运行环境。

1.1.6 CNCF Landscape路线图

CNCF Landscape最重要的产出包括一个路线图和一个全景图。路线图（Trail Map）是CNCF对云原生用户使用开源项目以及云原生技术的推荐过程。在路线图的每个步骤中，用户都可以选择供应商支持的产品或自己动手使用开源项目。

CNCF Landscape路线图

整个路线图分成了十个步骤，每个步骤都是用户或平台开发者将云原生技术在实际环境中落地时，需要循序渐进思考和处理的问题：

1. 容器化。目前最流行的容器化技术是Docker，你可以将任意大小的应用程序和依赖项，甚至在模拟器上运行的一些程序，都进行容器化。随着时间的推移，你还可以对应用程序进行分割，并将未来的功能编写为微服务。

2. CI/CD（持续集成和持续发布）。创建CI/CD环境，从而使源代码上的任意修改，都能够自动通过容器进行编译、测试，并被部署到预生产甚至生产环境中。

3. 应用编排。Kubernetes是目前市场上应用编排领域被最广泛应用的工具，Helm Charts可以用来帮助应用开发和发布者用于升级Kubernetes上运行的应用。

4. 监控和分析。在这一步中，用户需要为平台选择监控、日志以及跟踪的相关工具，例如将Prometheus用于监控、Fluentd用于日志、Jaeger用于整个应用调用链的跟踪。

5. 服务代理、发现和治理。CoreDNS、Envoy和LInkerd可以分别用于服务发现和服务治理，提供服务的健康检查、请求路由、和负载均衡等功能。

6. 网络。Calico、Flannel以及Weave Net等软件用于提供更灵活的网络功能。

7. 分布式数据库和存储。分布式数据库可以提供更好的弹性和伸缩性能，但同时需要专业的容器存储予以支持。

8. 流和消息处理。当应用需要比JSON-REST这个模式更高的性能时，可以考虑使用gRPC或者NATS。gRPC是一个通用的RPC（远程调用）框架（类似各种框架中的RPC调用），NATS是一个发布/订阅和负载均衡的消息队列系统。

9. 容器镜像库和运行环境。Harbor是目前最受欢迎的容器镜像库，同时，你也可以选择使用不同的容器运行环境用于运行容器程序。

10. 软件发布。最后可以借助Notary等软件用于软件的安全发布。

1.1.7 CNCF Landscape全景图

https://landscape.cncf.io/

CNCF Landscape路线图从实践步骤上帮助用户梳理了整个云原生应用的最佳流程。然而整个实践过程中的每个环节，用户都需要了解有哪些具体的软件和产品选择，这就是CNCF Landscape全景图发挥作用的地方了。

CNCF Landscape全景图

这张全景图试图从云原生的层次结构，以及不同的功能组成上，让用户了解云原生体系的全貌，并帮助用户在不同组件层次去选择恰当的软件和工具进行支持。从总体来看，它将云原生生态分为以下几层：

Cloud

图中最底层是Cloud（公有云，包括AWS、Google、Azure、Ali、Baidu、Tencent等）以及Kubernetes认证的服务提供商（主要是私有云，包括谐云、灵雀云、博云、才云、DaoCloud、Rancher等提供商）。

Provisioning

有了物理机或虚拟机后，在运行容器化服务之前，需要为容器准备标准化的基础环境，这就是Provisioning这一层的作用。在Provisioning这一层中，分为以下几个功能组成模块：

l Automation & Configuration：用于自动化部署和配置容器运行平台和环境，代表工具和厂商包括Ansible、Chef、Puppet、VMware、OpenStack。

l 容器镜像库：容器镜像库是整个CNCF云原生中的核心部件之一，因为基于容器的运行环境中，所有的应用都需要借助容器镜像库来进行安装和部署。容器镜像库又分为公有和私有，公有的容器镜像库包括docker官方的registry，AWS的Elastic Container Registry，Google的Container Registry等。在私有镜像库中，VMware中国团队主导的Harbor得到了广泛的应用，大量的容器平台目前都基于Harbor构建其镜像仓库。

l Security & Compliance：Notary和TUF（The Upgrade Framework）是这个领域两个主要的项目，其中TUF是一个开源的安全标准，Notary是其中一个实现。Notary软件除了确保软件的出处外，它还能保证在未经容器镜像提供者批准的情况下，不会在镜像供应链的任何地方修改镜像内的内容，从而确保从开发到运营的过程中，安全都被无缝统一地嵌入到整个工作流中。

l Key Management：主要用于在整个容器平台中进行秘钥管理。

Runtime：

Runtime这一层可以理解为容器的整个运行环境，是云原生中最核心的部分，它包括了计算、存储、网络三大块：

l Container Runtime：Docker是最广为人知的容器运行环境，但生产环境下也有一些其他的容器环境在运行。Containerd是满足OCI规范的核心容器运行时，从设计上就是为了嵌入大型系统的。它由Docker Inc公司启动，并且在2017年3月份捐赠给了CNCF。此外，CoreOS的RKT是一个用于在Linux上运行应用程序容器的CLI，也可以作为安全、可组合和基于标准的容器虚拟化运行环境。

l Cloud-Native Storage：起初，容器为无状态的运行单元，容器最上一层文件系统无法保存其在运行时写入的文件或数据，容器重建或重启后，这些写入的数据将丢失。但随着数据库、消息队列等中间件逐步在容器环境中得到应用，如今用户对容器持久化存储的理解和需求也更加深入和迫切。本文稍后还将对容器存储做更深入的分析。

l Cloud-Native Network：网络历来是虚拟化技术中最灵活多变的部分，目前，大多数客户使用的主要包括Calico、Flannel、Open vSwitch等方案。

Orchestration Management：

这一层主要负责容器平台的编排和调度，包括服务的发现和治理，远程调用，服务代理，微服务治理等组件，包括：

l Scheduling & Orchestration：在这个领域，Kubernetes是当仁不让的头号玩家，目前基于Kubernetes的容器生态得到了迅速发展。其它的编排工具包括Mesos、Docker Swarm等。

l Coordination & Service Discovery：分布式计算中很重要的一点就是各个服务之间的协同以及服务发现（或节点发现的问题），从老牌的Zookeeper到近年来在很多互联网厂商和应用中流行的Consul（Docker Swarm默认使用），都可以用于分布式服务的发现和配置，Kubernetes默认使用的则是CoreOS旗下的Etcd。

l Remote Procedure Call：微服务间进行通信，通常有两种方式，其一为HTTP REST-JSON的方式，另一种为RPC 方式，相比起来RPC方式效率更高。常用的包括 Google 开源的 GRPC 、apache 旗下的 thrift 框架、Netflix 开源的自带负载均衡的 ribbon 和 avra 数据序列化框架。

l Service Proxy、API网关以及微服务治理：这几个部分都用于对容器平台中运行的诸多API服务进行管理、路由、监控以及弹性伸缩的功能。

App Definition and Development

这一层就是容器平台上运行的具体应用和工具了，可以理解为容器平台的应用商店。根据应用的不同作用的使用场景，可以大致分为以下几种类型：数据库（例如MySQL、MariaDB、mongoDB、PostgreSQL、Cassandra、TiDB等）、流处理和消息队列（例如Spark、Storm、RocketMQ、Kafka、RabbitMQ等）、应用和镜像制作（用于将应用封装成标准镜像，使应用能在标准的容器平台上运行，例如Helm、Docker Composer、Packer等）、CI/CD（最常见的Jenkins、Atlassian公司开发的Bamboo等）。

Platform

从横向上看，整个云原生还包括众多的经过认证的平台供应商。

Observability and Analysis

这个部分包含了大量用于对平台进行监控（Prometheus、Nagios、Grafana、Zabbix等）、日志（Fluentd、ElasticSearch、Logstash）、以及追踪（Jaeger）的工具。

因此，CNCF Landscape全景图中包含了CNCF社区成熟或使用范围较广、具有最佳实践的产品和方案供用户在实际应用中选择。

1.1.8 云原生项目分类

https://www.cncf.io/projects/

https://github.com/cncf/toc/blob/main/process/project_proposals.md

CNCF 下的项目分为四个层次。

• Sandbox 沙盒：尚未在技术前沿的生产中广泛测试的 Experminatl 项目
• Incubating 孵化：由少数用户成功用于生产的项目，拥有健康的贡献者池
• Graduated 已毕业：项目被认为是稳定的、被广泛采用的、生产就绪的，吸引了成千上万的贡献者
• Archived 已归档：已达到其生命周期结束且已变为非活动状态的项目。