文章目录


01 引言

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

云原生架构(04)-CNCF_基础设施
云原生计算基金会(​​​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 用于整个应用调用链的追踪。通过这些信息,我们可以评估应用程序的性能,并可以消除瓶颈,从而提升整体性能。