云原生架构（04）-CNCF

01 引言

学习参考资料：《企业级云原生架构：技术、服务与实践）》

云原生计算基金会（Cloud Native Computing Foundation, CNCF）。

CNCF 由 Google于 2015 年 7 月发起成立，隶属于 Linux 基金会。

• 其目标愿景是“致力于使云原生计算具有普遍性和可持续性，维护和集成云原生开源技术，围绕一系列高质量项目建立社区，支持容器化编排的微服务架构应用”。
• 其职责范围是促进云原生标准制定，促进生态系统的发展和演变，管理项目，推进云原生社区发展。

02 CNCF生态蓝图

CNCF 把目前所涉及的云原生相关的产品、技术和生态分为 8 个主要的领域及方向，具体如下。

2.1 云基础设施（cloud)

按云的部署位置可以分为公有云和专有云（私有云）：

• 公有云：指云基础设施部署在互联网上，用户可以通过互联网渠道直接获取云厂商提供的云产品服务（IaaS、PaaS、SaaS）。这样大大降低用户使用云产品的门槛，同时节省用户自建 IDC 机房的初期一次性投入，即开即用，按需付费。
• 专有云（私有云）:指用户在自己的 IDC 机房，采用云的技术及产品搭建自己专属的云平台环境。专有云平台除了可以使用商业云厂商提供的云底座，还可以使用开源的虚拟化技术搭建，如 VMware、OpenStack、ZStack、CloudStack 等。建设专有云的成本很高，但是出于数据安全以及自主可控的考虑，一些用户会选择专有云。

2.2 环境部署（provisioning)

有了物理机和虚拟机，在运行容器服务之前，我们还需要为容器准备标准化的基础环境，如：自动化部署工具、容器镜像工具、安全工具等，以支持基础设施的运维自动化。

IaaS 层提供了硬件网络基础，环境部署提供了软件工具底座，二者共同支撑了容器运行平台的地基。

2.3 运行时（runtime)

运行时是容器核心的云原生技术，为容器运行提供虚拟化隔离的运行支撑环境，包括虚拟化的计算资源、虚拟化的存储资源、虚拟化的网络环境。

云原生计算：Linux Container (LXC） 容器是一种内核轻量级的操作系统层虚拟化技术，通过 Linux 的 Namespace 和 Cgroup两大机制来实现资源的隔离和限制管理，它为应用软件及其依赖组件提供了一个资源独立的运行环境。2016 年 4 月推出了第一个开放容器标准，标准主要包括运行时标准（runtime）和镜像标准（image）。

标准的推出有助于为成长中的市场带来稳定性，让企业能放心采用容器技术，用户在打包、部署应用程序后，可以自由选择不同的容器运行时标准。同时，镜像打包、建立、认证、部署、命名也都能按照统一的规范来进行。

---

云原生存储：容器从一出现就非常契合微服务中无状态服务的设计理念，因此初期甚至给一些人留下了容器只适合无状态服务的印象，但是随着容器技术的成熟和用户理念的变化，容器目前已经全面进入有状态服务领域。因为容器的生命周期很短的特点，所以容器的状态（存储的数据）必须独立于容器的生命周期，也正因如此，容器的存储变得非常重要。

---

云原生网络：绝大部分云厂商为用户提供了虚拟专有云服务（Virtual Private Cloud, VPC），便于用户构建云环境下可定制的虚拟网络方案。网络最重要的功能是提供不同计算资源的连通，随着虚拟化和容器技术的发展，传统的网络方案已经无法满足云计算快速增长、不断变化的网络需求。

例如:Docker 安装时会自动在宿主机上创建 3 个网络模式：主机（host）模式、桥接（bridge）模式、容器（container）模式。

---

编排和管理（orchestration&management)：当在生产环境中使用容器时，单台主机上的容器已经不能满足需求，因而需要管理多主机容器集群，也就需要有一个工具能够提供资源管理、容器调度和服务发现等功能，保证多主机容器能够正常工作。可以说，对于云原生系统，容器编排调度才是核心。Kubernetes 是世界上最受欢迎的容器编排平台和第一个 CNCF 项目，帮助用户构建、扩展和管理应用程序及其动态生命周期。

---

应用层（App definition and development)：容器平台最终还是要运行应用的，最主要的应用当然是各个公司的业务，除此之外还有一些比较通用的行业应用，可以根据需求提供类似于应用市场的功能。

应用层提供的技术及产品，既包括涉及跟应用开发相关的基础产品（如数据库、消息队列、缓存、流计算等），也包括跟应用开发相关的软件过程管理（如代码库、镜像库、DevOps）。

---

平台服务（platform)：平台服务是指基于容器技术的更上一层的封装，对开发人员、运维人员提供更加友好的、便捷的、基于容器的应用开发能力，让容器作为一种基础设施服务开箱即用-容器即服务（Container as a Service, CaaS）。

随着 Kubernetes 的快速发展，很多以 Kubernetes 为容器管理平台和应用管理的公司应运而生，大幅降低了用户使用 Kubernetes 管理容器的门槛。容器技术把微服务的概念弄得火热，随后也让 Serverless 这个词出现了大众的面前。既然容器能够屏蔽基础设施，让开发者只关心交付的应用（容器镜像），那么我们可不可以更进一步，让开发者也不需要关心交付的镜像，而只关注业务的核心逻辑呢?这就是 Serverless 的想法。开发者定义好基于事件触发的业务逻辑，其他一切都交给平台，当用户发出请求或者其他事件发生时，平台会根据事先的配置自动运行相应的业务逻辑代码，从而实现真正的按需服务。如果说容器关心的是应用，那么 Serverless 关心的则是函数，由此也催生出一些新的应用开发模式，如函数即服务开发模式（Functions as a Service, FaaS）、后端即服务开发模式（Backend as a Service, BaaS）、小程序开发模式等。

---

监控分析（observability&analysis)：监控系统的运行健康，以确保业务的稳定可靠，是运维工作的主要内容。基于云原生的应用平台建立起来之后，我们要保证整个平台能够正常工作，保证运行在其上的服务不会因为平台错误而不可用，而且还要知道应用整体的运行情况，提前对某些可能出错的地方进行预警，一旦出错能够提供合适的信息进行调试和修复等，这都是监控（observability）和分析（analysis）要做的工作。

监控分析包括运行监控（主机监控、容器监控、应用监控）、分布式日志（日志采集、实时流计算、日志分析）、分布式追踪（全链路追踪、架构感知）等应用领域。监控分析是容器平台运维的重中之重，云原生建设降低了应用部署、升级、构建、测试的难度，但是把难度下沉到容器平台，原来的运维工具和

---

03 CNCF路线图

3.1 容器化

容器化是云原生的第一步，如果不对应用程序进行容器化，就无法实现云原生。容器是一个标准的软件单元，它将代码及其所有依赖关系打包起来，这样应用程序就可以从一个计算环境快速、可靠地运行到另一个计算环境。

至于应用程序的大小和类型，都是无关紧要的。Docker 是容器化的首选平台，你可以将任意大小的应用程序和依赖项，甚至在模拟器上运行的一些程序，都进行容器化。

Docker 容器镜像是一个轻量级、独立、可执行的软件包，包含运行应用程序所需的所有内容。随着时间的推移，你还可以对应用程序进行分割，并将未来的功能编写为微服务。

3.2 CI/CD

设置CI/CD环境，从而使源代码上的任意修改都能够自动通过容器进行编译、测试，并被部署到预生产环境，甚至生产环境中，部署过程中如果有任何异常，可以方便快速地回滚到上一个稳定的版本。软件开发模式从最初的瀑布模型，到后来的敏捷开发，再到今天的 DevOps，这是现代开发人员构建出 色产品的技术路线。随着DevOps的兴起，出现了CI/CD和持续部署的新方法，而传统的软件开发和交付方式在迅速变得过时。在传统开发模式下，多数公司的软件发布频次是每月、每季度甚至每年，而在 DevOps 时代，每周、每天甚至每天多次发布都是常态。

3.3 应用编排

容器编排主要是管理容器的生命周期，尤其是在大规模复杂的生产环境中，软件团队使用容器编排来控和自动化许多任务。

Kubernetes 是目前市场上应用编排领域中使用最广泛的工具，还有其他编排工具，如 Docker swarm、Mesos 等。Helm Charts 可以用来帮助应用开发和发布者用于定义、安装和升级 Kubernetes 上运行的应用。

3.4 监控和分析

在这个步骤中，用户需要为平台选择监控、日志以及跟踪的相关工具。Kubernetes提供了有关应用程序在容器集群上的资源使用情况的详细信息，并不提供应用运行监控的解决方案，但我们可以将许多现有的云原生产品集成到 Kubernetes集群中。例如，将 Prometheus 用于监控、Fluentd 用于日志、Jaeger 用于整个应用调用链的追踪。通过这些信息，我们可以评估应用程序的性能，并可以消除瓶颈，从而提升整体性能。