CNCF官方大使张磊:什么是云原生?

作者|张磊 阿里云容器平台高级技术专家,CNCF 官方大使

编者说:

从 2015 年 Google 牵头成立 CNCF 以来,云原生技术开始进入公众的视线并取得快速的发展,到 2018 年包括 Google、AWS、Azure、Alibaba Cloud 等大型云计算供应商都加入了云原生基金会?CNCF,云原生技术也从原来的应用容器化发展出包括容器、Service Mesh、微服务、不可变基础设施、Serverless、FaaS 等众多技术方向,CFCF 旗下也囊括了越来多的开源项目。

Kubernetes 作为 CNCF 的第一个项目从诞生之初就就令人瞩目,Kubernetes 由 Google 工程师基于 Google 内部多年集群管理系统 Borg 的设计经验,结合云计算时代的基础设施特点重新设计而得,旨在帮助企业解决大规模 IT 基础设施的应用容器编排难题。Google 在 2014 年 6 月开源?Kubernetes 以后,在 Redhat、Microsoft、Alibaba 等厂商和众多开源爱好者共同的努力下,成长为如今容器编排领域的事实标准,极大的推动了云原生领域的发展。

在系统介绍什么是云原生,云原生对开发者来说意味着什么,我们先从云原生技术发展简史开始讲起。

云原生技术发展简史

  • 2004?年— 2007?年,Google 已在内部大规模地使用像 Cgroups?这样的容器技术;
  • 2008?年,Google?将 Cgroups?合并进入了?Linux?内核主干;
  • 2013?年,Docker?项目正式发布。
  • 2014?年,Kubernetes?项目也正式发布。这样的原因也非常容易理解,因为有了容器和?Docker?之后,就需要有一种方式去帮助大家方便、快速、优雅地管理这些容器,这就是?Kubernetes?项目的初衷。在?Google?和?Redhat?发布了?Kubernetes?之后,这个项目的发展速度非常之快。
  • 2015?年,由Google、Redhat?以及微软等大型云计算厂商以及一些开源公司共同牵头成立了?CNCF?云原生基金会。CNCF 成立之初,就有?22?个创始会员,而且?Kubernetes?也成为了?CNCF?托管的第一个开源项目。在这之后,CNCF?的发展速度非常迅猛;
  • 2017?年,CNCF 达到?170?个成员和?14?个基金项目;
  • 2018?年,CNCF?成立三周年有了?195?个成员,19?个基金会项目和?11?个孵化项目,如此之快的发展速度在整个云计算领域都是非常罕见的。

云原生技术生态现状

因此,如今我们所讨论的云原生技术生态是一个庞大的技术集合。CNCF?有一张云原生全景图(https://github.com/cncf/landscape),在这个全景图里已经有?200?多个项目和产品了,这些项目和产品也都是和?CNCF?的观点所契合的。

所以,如果以这张全景图作为背景,加以思考就会发现,我们今天所讨论的云原生其实主要谈论了以下几点:

  1. 云原生基金会?—— CNCF;

CNCF (云原生基金会)是目前云计算领域最成功的
开源基金会之一,是 Kubernetes,containerd,etcd
,Envoy 等知名开源项目的托管基金会

  1. 云原生技术社区

CNCF 目前托管的 20 + 正式项目共同构成了现代云
计算生态的基石。其中 Kubernetes 项目是全世界第
四活跃的开源项目

  1. 云原生技术产业

除了前面两点之外,现在全球各大公有云厂商都已经支持了?Kubernetes。此外,还有?100?多家技术创业公司也在持续地进行投入,总体市场于2021年逼近 1000 亿美元。现在阿里巴巴也在全面上云,而且上云就要上云原生,这也是各大技术公司拥抱云原生的一个例子。

我们正处于时代的关键节点


2019?年正是云原生时代的关键节点,为什么这么说?我们这里就为大家简单梳理一下。

从?2013?年?Docker?项目发布开始说起,Docker?项目的发布使得全操作系统语义的沙盒技术唾手可得,使得用户能够更好地、更完整地打包自己的应用,使得开发者可以轻而易举的获得了一个应用的最小可运行单位,而不需要依赖任何 PaaS 能力。这对经典?PaaS?产业其实是一个“降维打击”。

2014?年的时候,Kubernetes?项目发布,其意义在于?Google?将内部的?Borg/Omega?系统思想借助开源社区实现了“重生”,并且提出了“容器设计模式”的思想。而?Google?之所以选择间接开源?Kubernetes?而不是直接开源?Borg?项目,其实背后的原因也比较容易理解:Borg/Omega?这样的系统太复杂了,是没办法提供给?Google?之外的人使用,但是?Borg/Omega?这样的设计思想却可以借助?Kubernetes?让大家接触到,这也是开源?Kubernetes?的重要背景。

这样到了?2015?年到?2016?年,就到了容器编排“三国争霸”的时代,当时?Docker、Swarm、Mesos、Kubernetes?都在容器编排领域展开角逐,他们竞争的原因其实也比较容易理解, 那就是?Docker?或者容器本身的价值虽然大,但是如果想要让其产生商业价值或者说对云的价值,那么就一定需要在编排上面占据一个有利的位置。

Swarm?和?Mesos?的特点,那就是各自只在生态和技术方面比较强,其中,Swarm?更偏向于生态,而?Mesos?技术更强一些。相比之下, Kubernetes?则兼具了两者优势,最终在 2017?年“三国争霸”的局面中得以胜出,成为了当时直到现在的容器编排标准。这一过程的代表性事件就是?Docker?公司宣布在核心产品中内置了?Kubernetes?服务,并且?Swarm?项目逐渐停止维护。

到了?2018?年的时候,云原生技术理念开始逐渐萌芽,这是因为此时?Kubernetes?以及容器都成为了云厂商的既定标准,以“云”为核心的软件研发思想逐步形成。

而到了?2019?年,情况似乎又将发生一些变化。

什么是“云原生”?云原生该怎么落地?

云原生的定义

很多人都会问“到底什么是云原生?”

实际上,云原生是一条最佳路径或者最佳实践。更详细的说,云原生为用户指定了一条低心智负担的、敏捷的、能够以可扩展、可复制的方式最大化地利用云的能力、发挥云的价值的最佳路径。

因此,云原生其实是一套指导进行软件架构设计的思想。按照这样的思想而设计出来的软件:首先,天然就“生在云上,长在云上”;其次,能够最大化地发挥云的能力,使得我们开发的软件和“云”能够天然地集成在一起,发挥出“云”的最大价值。

所以,云原生的最大价值和愿景,就是认为未来的软件,会从诞生起就生长在云上,并且遵循一种新的软件开发、发布和运维模式,从而使得软件能够最大化地发挥云的能力。说到了这里,大家可以思考一下为什么容器技术具有革命性?

其实,容器技术和集装箱技术的革命性非常类似,即:容器技术使得应用具有了一种“自包含”的定义方式。所以,这样的应用才能以敏捷的、以可扩展可复制的方式发布在云上,发挥出云的能力。这也就是容器技术对云发挥出的革命性影响所在,所以说,容器技术正是云原生技术的核心底盘。

云原生的技术范畴

云原生的技术范畴包括了以下几个方面:

  • 第一部分是云应用定义与开发流程。这包括应用定义与镜像制作、配置?CI/CD、消息和?Streaming?以及数据库等。
  • 第二部分是云应用的编排与管理流程。这也是?Kubernetes?比较关注的一部分,包括了应用编排与调度、服务发现治理、远程调用、API?网关以及?Service Mesh。
  • 第三部分是监控与可观测性。这部分所强调的是云上应用如何进行监控、日志收集、Tracing?以及在云上如何实现破坏性测试,也就是混沌工程的概念。
  • 第四部分就是云原生的底层技术,比如容器运行时、云原生存储技术、云原生网络技术等。
  • 第五部分是云原生工具集,在前面的这些核心技术点之上,还有很多配套的生态或者周边的工具需要使用,比如流程自动化与配置管理、容器镜像仓库、云原生安全技术以及云端密码管理等。
  • 最后则是?Serverless。Serverless?是一种?PaaS?的特殊形态,它定义了一种更为“极端抽象”的应用编写方式,包含了?FaaS?和 BaaS?这样的概念。而无论是?FaaS?还是?BaaS,其最为典型的特点就是按实际使用计费(Pay as you go),因此?Serverless?计费也是重要的知识和概念。

云原生思想的两个理论

在了解完云原生的技术范畴之后你就会发现,其所包含的技术内容还是很多的,但是这些内容的技术本质却是类似的。云原生技术的本质是两个理论基础。

  • 第一个理论基础是:不可变基础设施。这一点目前是通过容器镜像来实现的,其含义就是应用的基础设施应该是不可变的,是一个自包含、自描述可以完全在不同环境中迁移的东西;
  • 第二个理论基础就是:云应用编排理论。当前的实现方式就是?Google?所提出来的“容器设计模式”,这也是 Kubernetes?部分文章中所需主要讲述的内容。

基础设施向云演进的过程

首先为大家介绍一下“不可变基础设施”的概念。其实,应用所依赖的基础设施也在经历一个向云演进的过程,举例而言,对于传统的应用基础设施而言,其实往往是可变的。

大家可能经常会干这样一件事情,比如需要发布或者更新一个软件,那么流程大致是这样的,先通过?SSH?连到服务器,然后手动升级或者降级软件包,逐个调整服务器上的配置文件,并且将新代码直接都部署到现有服务器上。因此,这套基础设施会不断地被调整和修改。

但是在云上,对“云”友好的应用基础设施是不可变的。

这种场景下的上述更新过程会这么做:一旦应用部署完成之后,那么这套应用基础设施就不会再修改了。如果需要更新,那么需要现更改公共镜像来构建新服务直接替换旧服务。而我们之所以能够实现直接替换,就是因为容器提供了自包含的环境(包含应用运行所需的所有依赖)。所以对于应用而言,完全不需要关心容器发生了什么变化,只需要把容器镜像本身修改掉就可以了。因此,对于云友好的基础设施是随时可以替换和更换的,这就是因为容器具有敏捷和一致性的能力,也就是云时代的应用基础设施。

所以,总结而言,云时代的基础设施就像是可以替代的“牲口”,可以随时替换;而传统的基础设施则是独一无二的“宠物”,需要细心呵护,这就体现出了云时代不可变基础设施的优点。

基础设施向云演进的意义

所以,像这样的基础设施向“不可变”演进的过程,为我们提供了两个非常重要的优点。

    1. 基础设施的一致性和可靠性。同样一个镜像,无论是在美国打开,在中国打开,还是在印度打开都是一样的。并且其中的?OS?环境对于应用而言都是一致的。而对于应用而言,它就不需要关心容器跑在哪里,这就是基础设施一致性非常重要的一个特征。
    1. 这样的镜像本身就是自包含的,其包含了应用运行所需要的所有依赖,因此也可以漂移到云上的任何一个位置。

此外,云原生的基础设施还提供了简单、可预测的部署和运维能力。由于现在有了镜像,应用还是自描述的,通过镜像运行起来的整个容器其实可以像?Kubernetes?的?Operator?技术一样将其做成自运维的,所以整个应用本身都是自包含的行为,使得其能够迁移到云上任何一个位置。这也使得整个流程的自动化变得非常容易。

应用本身也可以更好地扩容,从?1?个实例变成?100?个实例,进而变成?1?万个实例,这个过程对于容器化后的应用没有任何特殊的。最后,我们这时也能够通过不可变的基础设施来地快速周围的管控系统和支撑组件。因为,这些组件本身也是容器化的,是符合不可变基础设施这样一套理论的组件。

以上就是不可变基础设施为用户带来的最大的优点。

2019?年——云原生技术普及元年

为什么说?2019?年很可能是一个关键节点呢?我们认为?2019?年是云原生技术的普及元年。

首先大家可以看到,在?2019?年,阿里巴巴宣布要全面上云,而且“上云就要上云原生”。我们还可以看到,以“云”为核心的软件研发思想,正逐步成为所有开发者的默认选项。像?Kubernetes?等云原生技术正在成为技术人员的必修课,大量的工作岗位正在涌现出来。

这种背景下,“会?Kubernetes”已经远远不够了,“懂?Kubernetes”、“会云原生架构”的重要性正日益凸显出来。 从?2019?年开始,云原生技术将会大规模普及,这也是为什么大家都要在这个时间点上学习和投资云原生技术的重要原因。

阿里云和 CNCF 联合发布了《云原生技术公开课》,希望通过 29 节课程设置让开发者对云原生有全局的认知。

阿里巴巴云原生微信公众号(ID:Alicloudnative)关注微服务、Serverless、容器、Service Mesh等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术公众号。

原文地址:https://www.cnblogs.com/alisystemsoftware/p/11977781.html

时间: 2024-08-04 01:26:59

CNCF官方大使张磊:什么是云原生?的相关文章

始于阿里,回归社区:阿里8个项目进入CNCF云原生全景图

破土而出的生命力,源自理想主义者心底对技术的信念. 云原生技术正席卷全球,云原生基金会在去年KubeCon +CloudNativeCon NA的现场宣布: 其正在孵化的项目已达14个,入驻的厂家或产品已超过300家,并吸引了2.2万开发者参与项目代码贡献,其明星产品Kubenetes 的GitHub 上Authors 和 Issues 量已排行开源领域的第二名. 今年,KubeCon + CloudNativeCon 首次来到中国. 在2018 KubeCon + CloudNativeCon

阿里巴巴 Kubernetes 能力再获 CNCF 认可 | 云原生生态周报 Vol. 32

作者 | 丁海洋? 陈有坤 李鹏? 孙健波 业界要闻 阿里巴巴 Kubernetes 技术能力再获 CNCF 认可 CNCF 官网发布博文<Demystifying Kubernetes as a Service – How Alibaba Cloud Manages 10,000s of Kubernetes Clusters>.这篇长文从为什么需要超大数量的 K8s 集群,以及如何高效的管理这些集群出发,系统介绍了 Alibaba 在 Kubernetes 上取得的成绩. GitHub 欲

CNCF 2019 年度报告重磅发布 | 云原生生态周报 Vol. 41

作者 | 孙健波.陈有坤.李鹏.丁海洋.高相林 业界要闻 Istio 1.5 正式发布 大量重大更新,包括控制面组件重新回归单体,整体变得更简单.更易用,性能提升等等. CNCF 2019 年度调查报告发布 其中包含了几条重要信息: Cloud Native 社区项目在生产环境中应用成为新常态,超过 50% 的 Cloud Native 项目在生产中应用: Service Mesh 真正进入生产实践,超过 18% 的受访者表示已经在生产环境中使用 Service Mesh: Serverless

持续投入开源社区建设 | 阿里巴巴又一开源项目被列入 CNCF 云原生全景图

近日,阿里巴巴服务发现和配置管理领域开源项目Nacos被列入云原生全景图谱配置管理和服务发现象限,这是继Dragonfly.Dubbo.RocketMQ.OpenMessaging. PouchContainer和Sentinel后,阿里巴巴又一开源项目被列入该图谱.借助Nacos,用户在云原生时代构建微服务架构时,可极大的降低生产上的落地难度和实施风险. CNCF(Cloud Native Computing Foundation)于 2015 年 7 月成立,隶属于 Linux 基金会,初衷

Falco 进入 CNCF Incubator 项目 | 云原生生态周报 Vol. 35

作者 |?王思宇.陈洁.敖小剑 业界要闻 Falco 进入 CNCF?Incubator 项目 原于?2018 年 8 月进入 sandbox,旨在 Kubernetes 运行时环境下支持配置规则来加强应用安全性.降低风险. Kubernetes v1.17.1 发布 解决部分 cloud provider 和 kubelet 相关问题,比如: kubelet 更新 Pod ready status 失败 kubelet 清理 Pod volumes 发生 panic CFP 2020 K8s

CNCF 公布 2020 年 TOC 选举结果 | 云原生生态周报 Vol. 36

作者 | 陈洁.高相林 业界要闻 CNCF TOC 2020 年选举结果公布 2020 年 2 月 3 日,CNCF 进行了 TOC(技术监督委员会)选举,确定了 5 名新增的 TOC 成员,其中 3 名的提名者和投票者来自于 Governing Board,1 名的提名者和投票者来自于维护者,1 名的提名者和投票者来自于最终用户社区. CNCF 发布 2019 年度报告 2019 年 CNCF 新增 173 家成员,增长 50% 以上: KubeCon Shanghai.Barcelona.S

Argo 项目加入 CNCF 孵化器 | 云原生生态周报 Vol. 45

作者 | 陈洁.高相林.陈有坤.敖小剑 业界要闻 Argo 项目加入 CNCF 孵化器 Argo 项目是一组 Kubernetes 原生工具,用于运行和管理 Kubernetes 上的作业和应用程序.目前由 Argo Workflows,Argo Events,Argo CD 和 Argo Rollouts 四个子项目组成.4 月 8 日,CNCF 技术监督委员会(Technical Oversight Committee,TOC)投票决定接受 Argo 作为孵化级别的托管项目. Argo CD

云原生生态周报 Vol. 2

摘要: Cloud Native Weekly China Vol. 2 业界要闻 Kubernetes External Secrets 近日,世界上最大的域名托管公司 Godaddy公司,正式宣布并详细解读了其开源的K8s外部 Secrets 管理项目:Kubernetes External Secrets,简称KES.这个项目定义了ExternalSecrets API,让开发者可以在K8s内部以和使用内部Secret相似的方式使用外部系统提供的Secrets,大大简化了开发者为了让应用获

Knative 暂时不会捐给任何基金会 | 云原生生态周报 Vol. 22

作者 | 新胜.心贵.进超.元毅.衷源 业界要闻 谷歌:不会向任何基金会捐赠 Knative 自 Knative 项目开始以来,一直存在关于是否将 Knative 捐赠给基金会(例如 CNCF)的疑问. Google 领导层已经考虑了这一点,并决定在可预见的未来不向任何基金会捐赠 Knative. containerd v1.3 正式发布 CNCF 毕业后首个版本,功能扩展主要包括对 Windows v2 runtime 的支持以及 Plugins 相关支持(如允许 Plugin 注册为一个 T