CNCF

CNCF

苹果宣布加入云原生计算基金会

大卫 发表了文章 • 0 个评论 • 408 次浏览 • 2019-06-13 08:27 • 来自相关话题

云原生计算基金会(简称CNCF)作为Kubernetes等顶级开源项目的运营方,今天宣布苹果公司即将以最高级白金用户的身份正式加盟。凭借这位新成员,CNCF如今已经拥有89位最终用户成员,其中还包括阿迪达斯、Atlassian、Box、GitHub、纽约 ...查看全部

云原生计算基金会(简称CNCF)作为Kubernetes等顶级开源项目的运营方,今天宣布苹果公司即将以最高级白金用户的身份正式加盟。凭借这位新成员,CNCF如今已经拥有89位最终用户成员,其中还包括阿迪达斯、Atlassian、Box、GitHub、纽约时报、Reddit、Spotify以及沃尔玛等。

与以往的作风一样,苹果公司并没有对此次公告做出评论。但CNCF方面指出,最终用户资格主要面向那些“对开源云原生技术高度依赖”且希望回馈整个社区的重度用户。作为CNCF最终用户成员,苹果公司实际上也正式加入了Linux基金会。

作为成员关系的一部分,苹果公司还在CNCF管理委员会当中获得一个席位,苹果方面的高级工程技术经理Tomer Doron将出任这一职位。

云原生计算基金会CTO Chris Aniszczyk表示,“吸引到苹果这样一家拥有丰富经验与庞大业务规模的企业作为最终用户成员,充分证明了云原生计算在未来基础设施与应用程序开发方面的可观潜力。我们很高兴能够获得苹果公司的支持,并期待着未来能够为更为广泛的云原生项目社区做出更多贡献。”

虽然很多朋友可能不会把苹果公司与开源参与企业联系起来,但事实上该公司确实已经开放了从Darwin操作系统的XNU内核到Swift编程语言等一系列内部成果。话虽如此,苹果方面一般不会参与开源云基础设施社区,而这次的举动可能预示着这位消费电子巨头正在迎来转变。苹果公司肯定拥有自己的数据中心,因此其确实有可能高度依赖着各类开源基础设施项目——当然,按照苹果的一贯风格,其对这类话题往往避而不谈。

原文链接:Apple joins the open-source Cloud Native Computing Foundation

云原生计算基金会宣布containerd项目正式毕业

大卫 发表了文章 • 0 个评论 • 639 次浏览 • 2019-03-01 08:22 • 来自相关话题

【编者的话】时至今日,containerd已经成为阿里云、AWS、Cloud Foundry、Docker、谷歌、IBM、Rancher Labs以及更多生态系统支持方们采用范围最广的容器运行时选项。 作为Kubernetes与Pro ...查看全部
【编者的话】时至今日,containerd已经成为阿里云、AWS、Cloud Foundry、Docker、谷歌、IBM、Rancher Labs以及更多生态系统支持方们采用范围最广的容器运行时选项。

作为Kubernetes与Prometheus等开源技术的坚定支持者,云原生计算基金会日前宣布,继Kubernetes、Prometheus、Envoy以及CoreDNS之后,containerd已经成为其第五个毕业项目。事实上,要从孵化阶段一步步发展成熟至毕业水平,这些项目必须表现出活跃的采用度、良好的多样性、规范的治理过程,以及对社区可持续性与包容性的坚定承诺。

云原生计算基金会CTO Chris Aniszczyk表示,“在被云原生计算基金会接纳近两年之后,containerd如今仍然拥有着显著的发展态势——这意味着整个市场对于基础窗口技术仍然高度渴求。社区中的大量工作与协作成果有力支持着这款核心容器运行时方案的开发与测试。此外,社区还在努力扩大维护者规模与采用基础,同时亦顺利通过了外部安全审计。看到项目能够顺利毕业,我感到非常激动。”

诞生于2014年的containerd最初由Docker所打造,旨在为Docker引擎提供低层运行时管理器。而在2017年3月被纳入云原生计算基金会之后,containerd已经逐步发展成一款行业标准性质的容器运行时方案。此项目始终强调简单性、健壮性与可移植性,目前被广泛用作Docker引擎与OCI runc执行器之间的对接层。

containerd项目维护者兼Docker公司工程师Michael Crosby指出,“Docker公司当初之所以决定将containerd贡献给社区,是因为我们希望能够将这套早已成为Docker引擎中标准化组成部分的方案分享给数以百万计的企业以及不计其数的用户,并推动其成为真正强大且可扩展的运行时解决方案。随着我们不断扩大范围以满足更多现代容器平台(例如Docker平台与Kubernetes生态系统)的需求,我们高兴地看到在过去一年当中,containerd项目在采用量与后续创新方面都带来了喜人的表现。随着containerd采用量的不断增长,我们期待着立足整体生态系统继续开展合作,并借此推动我们的行业长期保持发展。”

IBM Cloud Kubernetes Serivce杰出工程师Dan Berg也表示,“IBM Cloud Kubernetes Service(简称IKS)致力于为我们的客户提供卓越的托管Kubernetes使用体验。为了实现这一目标,我们一直在努力简化IKS的架构与运营方式。迁移至containerd,将有助于简化我们代表客户所配置及管理的Kubernetes架构。通过将containerd选定为我们的容器引擎,我们成功减少了架构中的额外层数量,从而在改善运营效果的同时帮助客户提高了服务性能。”

自项目建立以来,containerd一直吸引着众多维护者与提交者的参与。目前,我们共有来自阿里巴巴、Cruise Automation、Docker、Facebook、谷歌、华为、IBM、微软、NTT以及特斯拉等公司的14位提交者、4406项提交成果以及166位贡献者。大家可以通过DevStats网站查阅containerd项目的统计信息与贡献者资料等。

阿里云高级工程师Li Yi解释称,“自业务建立以来,阿里巴巴一直在使用containerd项目。现在,我们很高兴地看到该项目顺利迎来这一重大里程碑。作为一款容器运行时方案,containerd凭借着开放、可靠与通用等特质一直发挥着关键作用。在阿里云,我们充分将containerd的简单性、健壮性与可扩展性引入到阿里云KubernetesSerivce与Serverless Kubernetes当中。阿里巴巴团队还将继续努力推动社区进一步实现创新与突破。”

为了正式由孵化阶段走向毕业,containerd项目遵循云原生计算基金会提出的基本原则,接受独立的外部安全审计,并确定了自身治理结构以保障社区发展。此外,containerd还获得并保有核心基础设施倡议最佳实践徽章(简称CII徽章)。这项成就于2018年9月1日正式达成,CII徽章代表着整个社区对于代码质量与安全最佳实践做出的不懈承诺。

##containerd项目背景信息

* containerd 是一套行业标准化容器运行时,强调简单性、健壮性与可移植性。Containerd可作为Linux与Windows系统中的守护程序。
* containerd管理其所在主机系统上的整个容器生命周期——从镜像传输到存储、到容器执行与监督,再到底层存储乃至网络附件等等。
* 若您希望下载containerd项目、查阅相关说明文档以及了解如何加入社区,请访问: https://github.com/containerd/containerd。

原文链接:Cloud Native Computing Foundation Announces containerd Graduation

云原生计算基金会宣布CoreDNS项目正式毕业

JetLee 发表了文章 • 0 个评论 • 751 次浏览 • 2019-01-25 09:49 • 来自相关话题

云原生计算基金会(简称CNCF,负责为Kubernetes与Prometheus等开源技术提供支持)日前宣布,继去年毕业的Kubernetes、Prometheux以及Envoy等开源技术之后,CoreDNS成为其2019年的首个毕业项目。要从孵化阶段走向毕业 ...查看全部
云原生计算基金会(简称CNCF,负责为Kubernetes与Prometheus等开源技术提供支持)日前宣布,继去年毕业的Kubernetes、Prometheux以及Envoy等开源技术之后,CoreDNS成为其2019年的首个毕业项目。要从孵化阶段走向毕业,项目必须在市场上表现出活跃的采用积极性、多样性、规范的治理流程,以及对于社区可持续性与包容性做出坚定承诺。

CoreDNS是一套快速、灵活且现代的DNS服务器方案,亦可在云原生部署场景下提供服务发现功能。基于其提供了能够向下兼容,且具备可扩展性的Kubernetes集成能力,因此在Kubernetes的最新版本(1.13)中CoreDNS被指定为未来一切部署场景中的默认DNS选项。此外,该服务器还适用于配合AWS(启用AWS Route 53与etcd)的混合云环境下的原生云集成,未来亦有计划进一步为Google Cloud DNS提供支持。

云原生计算基金会COO Chris Aniszczyk表示,“CoreDNS已经在最近两年中成为云原生计算基金会不可或缺的重要项目,并在社区的努力推动下达到毕业水平,同时正式成为Kubernetes的默认DNS服务器。此外,CoreDNS亦是一款出色的独立DNS服务器方案,正不断被用于更多其它环境——我们很高兴能够随着项目的发展而不断为其社区提供支持。”

该项目由Miek Gieben于2016年3月正式建立,他当时担任谷歌公司的站点可靠性工程师。在构建CoreDNS时,社区考虑到其它DNS服务器方案的局限性,希望打造出一款能够与多个后端(例如etcd、Consul以及Kubernetes)进行通信的通用型DNS服务器。CoreDNS随后于2017年加入到Cloud Native Sandbox当中,并于2018年2月晋升为孵化项目。如今,该项目已经拥有100多位贡献者,16位活跃维护者,亦有众多组织机构在Kubernetes内外的生产环境中加以使用——包括Bose、Hellofresh、Skyscanner、SoundCloud、Trainline以及Zalando等。

CoreDNS维护者Yong Tang表示,“自从2017年年初加入云原生计算基金会以来,CoreDNS迎来了良好的社区增长表现,亦在生产环境中展现出惊人的应用空间。我们非常感谢云原生计算基金会对CoreDNS项目的大力帮助,亦期待继续保持合作以不断扩大我们的社区规模。”

Okkur Labs创始人兼CoreDNS维护者Michael Grosser指出,“CoreDNS项目及社区已经取得巨大进展,而成为云原生计算基金会毕业项目则标志着一大重要里程碑。从一套用于发布Prometheus指标的简单DNS服务器,到一款具备固有灵活性的成熟DNS解决方案,再到大多数Kubernetes集群内的信心组件并为无数用户带来更理想的稳定性与灵活性,这一切都令我们对于CoreDNS背后强大的支持社区充满信心。”

谷歌云计算高级软件工程师、CoreDNS高级维护者John Belamaric表示,“CoreDNS的灵活性以及基于插件的架构设计,已经被证明是一种理想的DNS服务器构建思路。CoreDNS的易于集成与可扩展能力对于各种DNS服务与用例的实现而言至关重要——从Kubernetes服务发现到基于策略的DNS与广告拦截,都离不开这两大重要能力。云原生计算基金会对该项目提供的支持同样不可或缺,我们很高兴能够正式毕业并继续发展我们的多元化项目社区。”

Infoblox公司软件经理Francois Tur指出,“作为一位项目维护者,我专注于调整CoreDNS以供Kubernetes社区使用,以Kubernetes中的CoreDNS部署场景为基础开展协作,并验证CoreDNS作为Kubernetes集群指定DNS服务器的实际效果。今天CoreDNS从云原生计算基金会毕业,对于我们的项目社区来讲是个了不起的成熟。这一旅程开始于两年多之前,而且一切都才刚刚开始。”

为了正式从孵化状态毕业,CoreDNS项目遵循云原生计算基金会的行为准则。CoreDNS团队还在过去一年当中先后发布了12个版本,项目目前拥有35款内置插件以及15款外部插件,其中一部分由Kubernetes社区开发而成。此外,CoreDNS在过去两年中还参与到谷歌公司组织的代码夏令营(Google Summer of Code)当中——活动中导师将与在校实习生们结对探索,旨在推动云原生项目的不断发展。

Infoblox公司高级软件经理Naveen Singh表示,“在Infoblox公司,我们很自豪地能够在自己的SAAS DNS产品当中使用CoreDNS,而且目前也已经在全球范围内部署了众多CoreDNS实例。CoreDNS目前正在为全体Infoblox云客户支持生产DNS流量,其中也包括不少财富五百强企业。我们非常欣赏CoreDNS的插件架构,其为我们带来了巨大的灵活性空间、更高的开发速度与更快的发布周期。”

GitNS创始人Michael Grosser指出,“将GitNS.com建立在CoreDNS这一坚实的基础之上,是我做出的最明智的决定之一。考虑到DNS的基本特性,要求我们必须选择一套具有高性能、高可靠性以及强大扩展能力的系统作为构建基础。CoreDNS项目拥有着令人难以置信的卓越社区,我们非常乐于为其提供支持。随着CoreDNS从云原生计算基金会正式毕业,其将成为构建基础设施与定制化用例中最理想的DNS平台选项之一。”

CoreDNS背景信息:

* CoreDNS是一套由Go语言编写而成的DNS服务器,其遵循Apache License Version 2许可,且完全开源。
* CoreDNS凭借着强大的灵活性而适用于多种环境及用例。其可用于Kubernetes服务发现、权威DNS服务器、高DNS强度应用的本地缓存等等。其中的各款插件能够彼此链接以实现Prometheus指标检测等额外功能,亦可以开箱即用的方式带来重写查询等功能。
* 除了从标准区域文件提供DNS之外,CoreDNS还通过Kubernetes插件与Kubernetes相集成,可利用etcd插件直接对接etcd,并能够与多种其它后端数据提供程序进行整合。
* 若需下载CoreDNS项目本体,或者参阅与项目相关的说明文档与背景信息,请访问 https://github.com/coredns/coredns。

原文链接:Cloud Native Computing Foundation Announces CoreDNS Graduation

云原生技术的初学者指引

Zangying2005 发表了文章 • 0 个评论 • 872 次浏览 • 2019-01-02 16:08 • 来自相关话题

当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目 ...查看全部
当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目方案都包括在这张图内。

我有幸成为CNCF的大使,致力于在加拿大推广社区活动和云原生的教育。同时,在CloudOps社区, 我还带领着Docker和Kubernetes研讨会,向大家普及云原生技术,帮助DevOps团队实践相关的技术应用。

我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。大家通过电子邮件或在博客上@archyufaor的方式保持联系。为他们提供云原生技术的信息咨询。

同时,我还编写了云原生技术的初学者指南。希望能帮助读者理解这个领域并在这个领域取得更好的进展。
#CNCF的历史背景
2014年,谷歌开源了一个主要用于容器编排的,名为博格(Borg)的内部项目。由于没有机构来管理这个项目,谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而Borg项目就更名为Kubernetes,并用Go语言重写了实现部分,成为了CNCF的启动捐赠项目。毫无疑问地讲,Kubernetes只是开始,后续有大批的新项目先后加入到CNCF,围绕着Kubernetes不断地扩展功能。
#CNCF的使命
通过提供多种选项的开发软件社区,帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作,希望实现完全由CNCF成员项目演化出来的成熟技术栈。这便是CNCF在云端的自我使命。
#CNCF的历程
目前共有25个项目已经被CNCF接受,在跟进Kubernetes生态发展。希望加入到CNCF的项目,必须是由技术监督委员会(TOC)选定并通过投票评比,取得绝大多数的投票认同才可以加入。投票过程由TOC贡献者组成的一个优秀社区来辅助进行,而TOC贡献者是来自CNCF成员公司的代表,我有幸也是其中一位。评选通过的项目就叫CNCF成员项目,CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。
##沙箱阶段
这个阶段的项目非常早期,在部署到生产环境之前,需要显著地提升代码成熟度,积极参与开源社区的互动。项目之所以被选中,主要是因为它们具备的潜力是社区所没有的。在CNCF的指南中提到,CNCF将帮助推动沙箱项目的公共可见性,并促进其与现有项目形成体系。但沙箱项目从CNCF获得的资金和营销支持非常少,并且每12个月都要接受审查,发展不够好的项目可能会被淘汰掉。
##孵化阶段
当项目满足所有沙箱标准并具备明显的增长和成熟度特征时,它们就进入孵化阶段。这时,它们必须至少在三家公司的生产环境中使用过,具备稳定的团队,确保稳定提供对社区的贡献,包括处理来自社区的新功能和代码要求等。
##毕业阶段
孵化项目一旦达到生产使用的临界点,TOC就可以投票决定项目是否进入毕业阶段。毕业的项目必须证明有很高的采用率,并满足所有孵化标准。项目的提交者必须至少来自2个不同的组织,具有文档化和结构化的管理流程,并满足Linux基金会核心基础设施计划的最佳实践徽章要求。截止到目前,只有Kubernetes和Prometheus两个毕业项目。
# CNCF项目介绍
我将CNCF成员项目划分了12个类别,分别是:编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流。我希望所提供的信息能够帮助公司或个人评估每个项目做什么,如何演化的,以及如何与其他CNCF项目集成等。
##编排
3.png

Kubernetes

Kubernetes(已毕业)—— Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置,可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排,而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层,将容器分组运行在Pod中,从而实现容器的编排。Kubernetes可以帮助运维人员进行工作负载排期,并允许容器在多云环境中大规模部署。Kubernetes在毕业后被广泛应用,CNCF最新的调查显示,超过40%的企业受访者在生产过程中使用了Kubernetes。
##应用程序开发
4.png

Helm

Helm(孵化阶段)——Helm是程序包管理器,以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)。KubeApps Hub能够列出由Kubernetes社区维护的稳定库和孵化库中的全部chart。通过Helm,用户可以安装Kubernetes之上的所有CNCF项目。并且还可以让企业在Kubernetes上创建和部署自定义的应用程序或微服务。当然,这会涉及到创建YAML清单,根据不同的环境或CI/CD流程匹配不同的部署参数等情况。Helm所创建的单个chart,可以基于应用程序或配置更改来进行版本控制,可以部署在各种环境中,还可以进行跨组织共享。

Helm项目最开始来源于为Kubernetes用户创建自定义体验的Deis项目。早期的Helm版本只有客户端,但后来Deis与谷歌合作在Helm V2版本中添加了服务端‘tiller’,与Kubernetes 1.2同期发布。这就使得Helm成为在Kubernetes之上部署应用的标准方式。

Helm目前正在2018年年底Helm V3发布进行一系列的更改和更新。对于依靠Helm进行日常CI/CD开发的公司,包括Reddit、Ubisoft和Nike,我建议他们按照新的设计进行优化调整。
5.png

Telepresence

Telepresence(沙箱阶段)——虽然在私有云容器应用开发方面,有包括Docker Compose和Minikube在内的流行工具。但在Kubernetes上开发容器化应用程序仍然非常具有挑战性。因为,目前大多数云原生应用都是资源密集型的,并且涉及多个数据库、服务和依赖项。此外,模拟云依赖关系非常复杂,例如在Docker Compose和Minikube中与消息传递系统和数据库的依赖关系就是一个复杂的事情。这里有一个可参考方案,就是使用完全远程的Kubernetes集群,但是这方案会影响IDE、调试器等本地开发工具的应用,并且会导致开发人员出现等待CI去进行测试更改之类的“内部循环”效应。

由Datawire开发的Telepresence在上述设想方面提供了不错的解决方案。它允许开发人员因开发需要在本地运行单个微服务,同时保持与运行在远端Kubernetes集群上的其余部分应用的连接,我们称之为 “实时代码”。Telepresence在远端Kubernetes集群上部署了包含双向网络代理的Pod。将本地机器连接到网络代理。实现了部署真实的开发/测试环境,而无需冻结用于编码、调试和编辑的本地工具。
##监控
6.png

Prometheus

Prometheus(已毕业)——类同于Kubernetes的历程,Prometheus是第二个加入到CNCF的项目,也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案。灵感来自于谷歌的Borgman监控系统。Prometheus完全是拉取式系统,通过配置决定了什么时候拉取什么数据。而不同于通过agent推送数据的push式监视系统。Prometheus将拉取的指标存储在TSDB中。允许用户使用PromSOL类查询语言抽取数据在Grafana仪表板内进行图形展示。用户还可以使用内置的警报管理器生成警报并以slack和电子邮件的方式发送给各种目标。

Prometheus的成功让它已经成为了云原生监控的事实性标准。通过Prometheus,用户可以监控VM、Kubernetes集群和运行在任何地方的微服务,尤其适应像Kubernetes这样的动态系统。Prometheus的度量指标还可以利用Kubernetes的HPA、VPA和集群自动伸缩等功能来进行自动伸缩决策。也支持对其他的CNCF项目的监控,如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的输出集成了许多其他应用和分布式系统。我建议初学者从Helm Chart开始接触。
7.png

OpenMetrics

OpenMetrics (沙箱阶段)——OpenMetrics为应用程序的外部指标格式设定了中性的标准。这个标准让用户可以在更大范围的系统间传输指标数据。OpenMetrics其实是基于Prometheus的指标格式,而后者又是采用Borgmon的运营经验,Borgmon实现了“白盒监控”和低开销的海量数据收集,有着超过300家的服务输出商。在OpenMetrics之前,监控环境主要都是基于像SNMP之类,相对过时的标准和技术,使用专用指标格式,也很少有人关注指标格式规范,存在不少系统差异性的问题。而OpenMetrics出现后,在Prometheus的指标格式之上,定义了更紧凑、更清晰和更严格的语法。很好的改善了系统间指标差异这方面的问题。

虽然OpenMetrics仍在沙箱阶段,但它已经被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生产环境。
8.png

Cortex

Cortex (沙箱阶段)——Prometheus的首要设计目标就是操作简单。因此,它只运行在单节点或单容器内,所使用的存储也是不具备持久或长期存储能力的本地存储。避免采用操作复杂性更高的集群和分布式存储的目的也是为了符合Prometheus的简单原则。Cortex却是具备水平可扩展、支持多租户、采用长效存储设备的辅助解决方案。这对于Prometheus而言,我们认为是不错的补充。它让大型企业在使用Prometheus时,可以具备高可用性,可以访问长效存储设备。虽然在这个领域,目前还有其他一些例如Thanos、Timbala和M3DB的项目也获得社区的关注。但是,Cortex已经在GrafanaLabs和Weaveworks作为SaaS产品进行了battle测试,而且EA和StorageOS也在prem平台上部署了它。
##日志和跟踪
9.png

Fluentd

Fluentd(孵化阶段)——Fluentd采用统一的方法,对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。这统一的方法就是将日志数据定义成JSON格式,实现跨多个源和目的地进行日志的收集、过滤、缓冲和输出。Fluentd的优势之一是可以收集VM和传统应用的日志,但它真正的优势还是在云原生环境Kubernetes之上,作用于那些动态运行的微服务。

Fluentd以daemonset的方式,运行在Kubernetes上每个Pod节点内。它不仅收集容器内所有应用程序的日志(包括CNCF ones),还将日志发送到STDOUT。Fluentd具有逐条解析和缓冲日志记录的能力,并将格式化的日志发送到所配置的目的地,如Elasticsearch、Hadoop和Mongo,让用户可以进行后续处理。

Fluentd最初是用Ruby编写的,虽然功能比较完整,但运行时需要50Mb以上的内存,这对于配对容器部署运行显然不太合适。于是,与Fluentd同时开发的Fluentbit变成了一个替代解决方案。Fluentbit是用C写的,在运行时只需要几Kb的内存,CPU和内存上效率更高,但功能比Fluentd要简单很多,存在比较多的限制。

Fluentd最初是Treasuredata的一个开源开发项目,只是Kubernetes的一个日志插件。较早的可部署版本是0.12,版本比较老、但非常稳定,已被广泛部署在各种生产环境中。近期开发完成的1.X新版本包含了很多改进,例如增加新的API、纳秒级响应和支持Windows环境等。Fluentd正在慢慢成为云原生环境中日志收集的标配, 很大可能成为下一个CNCF毕业项目。
10.png

OpenTracing

OpenTracing(孵化阶段)——开发人员需要能够查看到每条事务并懂得微服务的行为,这使用分布式跟踪对于大规模构建微服务的重要性不能被低估,然而,分布式跟踪非常具有挑战性,需要跟踪工具必须通过已有的服务、包和特定的应用程序代码在流程内和流程之间传播跟踪的上下文。OpenTracing允许应用程序代码、OSS包和OSS服务开发人员无需限定具体供应商的情况下测试自己的代码。 它为应用程序和OSS包提供了一个分布式跟踪标准,这些程序包具有独立的API和9种语言的可用库。专注于分布式跟踪使得OpenTracing非常适合服务集群和分布式系统。但OpenTracing本身并不是一个在UI中运行跟踪来分析spans的跟踪系统。它只是一个与应用业务逻辑、框架和现有工具一起工作的API,可用于创建、传播和标记spans。它创建存储在后端或UI格式的跟踪。目前,OpenTracing集成了开源(如Jaeger,Zipkin)和商业跟踪解决方案(如Instana,Datadog)。
11.png

Jaeger

Jaeger(孵化阶段)——Jaeger是一个开源的分布式跟踪系统解决方案,它与OpenTracing兼容,最初是由Uber开发和测试的。它的名字的发音是yā′gər,即猎人的意思。灵感来自于谷歌的内部跟踪系统Dapper和Zipkin。Zipkin是由Twitter编写,采用了OpenTracing标准(但限制了集成支持能力)构建的开源跟踪系统。Jaeger通过HTTP接受Zipkin格式的spans,并具有Zipkin的向后兼容性。Jaeger的用例监视和基于微服务的故障排除功能,提供了分布式上下文传播、分布式事务监视、根本原因分析、服务依赖关系分析以及性能和延迟优化能力。Jaeger的数据模型和工具包库与OpenTracing兼容。它的Web UI是采用React/Javascript构建的,可以对Cassandra、Elasticsearch和memory等后端提供多种支持。同时,Jaeger集成了包括Istio和Linkerd在内的服务组件,使得跟踪更加容易实现。 

Jaeger默认会暴露Prometheus的指标,并与Fluentd集成来进行日志传输,这让它具有很好可观察性。可以通过Helm chart或最近开发的Jaeger Operator部署到Kubernetes之上。Uber和RedHat为Jaeger代码库提供了大部分的贡献。但还有数百家公司为Jaeger用于云环境和基于微服务的分布式跟踪在进行调优。
##容器注册
12.png

Harbor

Harbor(沙箱阶段)——Harbor最初是由VMWare作为开源解决方案开发的,是一个开源可信任的容器注册器,用于存储、标记和扫描Docker镜像,提供了免费的、增强的Docker注册特性和功能。它提供的Web接口具有基于角色访问控制(RBAC)和LDAP验证支持的安全特性。它集成了由CoreOS开发的用于漏洞扫描的开源项目Clair和用于内容信任的Notary(一个CNCF孵化项目,稍后介绍)。Harbor提供活动审计、Helm chart管理和Harbor实例间的镜像复制(高可用和灾难恢复用途)功能。现在已经被许多公司所使用,包括TrendMicro、Rancher、Pivotal和AXA。
##存储和数据库
13.png

Rook

Rook(孵化阶段)——Rook是Kubernetes的开源存储编排器。它帮助OPS人员在Kubernetes之上运行Ceph等软件分布式系统(SDS)。开发人员可以使用存储动态创建Kubernetes中的持久卷(PV)来部署Jenkins、WordPress等存在状态请求的应用程序。

Ceph是一种流行的开源SDS,它运行在常规的硬件上,对外提供对象存储,块存储和文件系统等多种主流的的存储服务类型。用户可以将Ceph集群直接部署在硬件上,然后使用CSI插件将其连接到Kubernetes。但这样做无疑会增加OPS人员的部署和操作Ceph集群的难度,增加工作挑战性,降低对Ceph集群的欢迎度。而Rook使用自定义资源定义(CRDs)方式将Ceph作为第一个类对象部署到Kubernetes中,并使用操作框架将其变成自管理、自伸缩和自修复的存储服务。这一点恰恰对应了Kubernetes运行的理念,即将人的操作知识编码到软件中,从而可实现简易打包和与终端用户的共享。

与Helm专注于打包和部署Kubernetes应用程序相比,Rook Operator可以部署和管理复杂的SDS应用程序生命周期。以Ceph为例,Rook操作人员可以自动化存储管理员的工作,例如部署、引导、配置、性能指定、水平伸缩、修复、升级、备份、灾难恢复和监视等。

最初的Rook Operator只支持Ceph,在0.8版本时,对Ceph的支持达到Beta版,随后发布了用于存储厂商的Rook框架,这个框架将Rook扩展成为一个通用的云原生存储编配器。具有支持可重用规范、逻辑、策略和测试的多个存储解决方案。目前Rook在alpha中支持CockroachDB、Minio、NFS,后续将支持Cassandra、Nexenta和Alluxio。在生产中使用Ceph的Rook Operator的公司越来越多,尤其是在Prem平台上,包括CENGN、Gini、RPR都有部署,还有许多公司正在评估阶段。
14.png

Vitess

Vitess (孵化阶段)——Vitess是一个数据库的中间件。 它使用通用分片技术在MySQL实例之间分发数据。它可以实现水平伸缩,在不影响应用的情况下,进行水平的无限扩展。 当用户的分片达到满负荷时,Vitess能以零停机时间和良好可观察性,重新对底层数据库进行分片扩展。Vitess还解决了许多与事务性数据相关的问题,项目成长趋势良好。
15.png

TiKV

TiKV(沙箱阶段)——TiKV是一个事务性键值数据库,它具备简化调度和自动平衡的能力。它充当了分布式存储层,提供数据强一致性、分布式事务管理和水平伸缩性的功能。TiKV的设计灵感来自于谷歌Spanner和HBase,但是它的优点是没有分布式文件系统。TiKV由PingCAP开发,目前还有有来自三星、腾讯云和UCloud的贡献者。
##容器运行时
16.png

RKT

RKT(孵化阶段)——RKT(读作Rocket)最初是由CoreOS开发的一个应用程序容器,属于Docker的备选项目。当时,Docker成为Kubernetes的默认容器,但遭遇到来自kubelet的压力,Kubernetes和Docker社区在相互协作方面存在着分歧。开发Docker的公司Docker Inc.有自己的产品路线图,并且正在给Docker添加一些复杂的功能。例如,为Docker添加集群模式,以及将文件系统从AUFS更改为overlay2。但做这些工作时,并没有向外发布信息,导致这些更改影响到了Kubernetes社区和Kubernetes路线图规划和发布日期。况且,Kubernetes用户需要用到的只是一个简单的容器,具备启停容器,并具备伸缩、升级等功能即可。因此,CoreOS就打算将RKT开发成Docker的替代品,专门为Kubernetes而构建。但令人意外的是,这举措却激发了Kubernetes的SIG-Node团队为Kubernetes开发了一个容器接口(CRI),这个接口可以连接任何类型的容器,并从其核心代码中把Docker的代码也被删除了。RKT可以同时使用OCI和Docker格式的镜像。虽然RKT对Kubernetes生态系统产生了积极的影响,但却没有被最终用户所接受,特别是那些习惯了Docker CLI并且不想学习其他应用程序打包方法的开发人员。此外,由于Kubernetes的流行,有许多容器解决方案都在争夺这一细分市场,例如Gvisor和基于OCI的cri-o都越来越流行,而RKT有点风景不再的感觉,可能会成为CNCF孵化器中被移除的项目。
17.png

Containerd

Containerd(孵化阶段)——Containerd是一个强调简单性、健壮性和可移植性的容器。与RKT一样,支持OCI和Docker镜像格式,但不同的是,Containerd设计的目的是嵌入到较大型的系统中,而不是提供给开发人员或最终用户直接使用。Containerd也是Docker捐赠给CNCF的项目。早期的Docker是一个高度集成的应用,但随着时间的推移,集群模式等功能的加入,使其成为一个复杂且难以管理的应用。而且对于要求简单容器功能的Kubernetes用户而言,Docker的复杂功能反而有些多余。因此,Kubernetes开始寻找包括RKT在内的替代方案,来替代默认的Docker容器。这时,Docker项目决定将自己拆分为松耦合的组件,采用更模块化的体系结构。这也就是Moby项目,其中Containerd就是这个项目的核心功能。拆分出来的Containerd通过CRI接口集成到Kubernetes,并改名为ri- Containerd。但从Kubernetes 1.10开始,默认采用Containerd通过内置的CRI插件实现集成,省却了额外的grpc跳转。

随着基于OCI的cri-o和Gvisor这样的项目越来越受欢迎,Containerd慢慢也不被社区所关注。不过它还是Docker平台不可或缺的一部分,在Kubernetes生态系统中还保有一定的位置。
##服务发现
18.png

CoreDNS

CoreDNS(孵化阶段)——CoreDNS是云原生部署中提供服务发现的DNS服务器。Kubernetes自1.12版起,将CoreDNS作为默认的集群DNS服务器,而在更早以前,SkyDNS是Kubernetes集群的DNS组件,它本身就是由Caddy和后来的KubeDNS组成的一个分支。SkyDNS是基于DNS的动态服务发现的解决方案,但体系结构不够灵活,很难添加新功能或进行扩展。于是Kubernetes转而采用KubeDNS。但KubeDNS在运行时,分3个容器(Kube-dns,Dnsmasq和Sidecar)运行,容易出现Dnsmasq漏洞,在新功能扩展上也存在类似SkyDNS的问题。而恰好这时,CoreDNS用Go语言进行了全面重写,成为了基于插件的灵活可扩展的DNS解决方案,而且在Kubernetes上,运行时只需启动一个容器,也没有漏洞方面的问题,提供的ConfigMap工具可动态更新配置。此外,CoreDNS通过严格的设计(如验证Pod记录)修复了许多KubeDNS上存在的问题。基于插件的架构使用户可以插件的方式随时添加或删除功能。目前,CoreDNS已包括30多个自有插件和20个以上的外部插件。通过链接插件,用户可以启用Prometheus监控、Jaeger日志跟踪、Fluentd日志记录、Kubernetes API或etcd配置以及其他的高级DNS特性和集成功能。
##Service Meshes
19.png

Linkerd

Linkerd(孵化阶段)——Linkerd是一个用于服务网格部署的开源网络代理服务。服务网格是一个单独的层,用于管理、控制和监视应用程序中的服务到服务之间的通信。Linkerd在无需应用代码变更的情况下,通过可编程的回路制动、速率限制、超时和重试配置来提高应用程序的容错性,帮助开发人员大规模地运行微服务。通过Zipkin提供了对微服务的可视化。以及提供了先进的交通控制设备来支持Canaries、Staging和Blue-green部署。SecOps团队受益于Linkerd的功能,在Kubernetes集群中通过TLS透明地加密了所有跨节点通信。Linkerd是在Twitter的Finagle项目之上开发出来的,项目具有广泛的生产用途,并吸引了许多探索服务网络的公司的兴趣。目前,Linkerd可以与Kubernetes、DC/OS和AWS/ECS一起使用。以DaemonSet的形式部署在Kubernetes上,这也意味着集群中的每个节点都运行了一个Linkerd Pod。

服务网格生态系统最近有新的变化,例如与Kubernetes紧密集成的Istio项目的引入,与微服务一起运行的轻量级代理Envoy的出现等。这些服务网格组件提供了比Linkerd更多的功能,这大大降低了Linkerd的受欢迎程度,甚至出现了质疑Linkerd存在价值的声音。为了重新获得社区的兴趣并支持现有的大量客户,Linkerd所属的公司Buoyant宣布了一个名为Conduit的项目,该项目允许DaemonSets使用Istio作为Sidecar代理,重写了dataplane,用Go语言重写了控制平面。这些改变使许多可能的特性都可以使用Sidecar方式。不久前,Conduit项目被重新命名为Linkerd 2.0,并发布了GA,这表明Linkerd已经准备应用于生产环境。服务网络还在飞速发展,像Istio和Linkerd 2这样的项目将是这方面的核心。
##服务代理
20.png

Envoy

Envoy(孵化阶段)——Envoy是一个为云原生应用设计的边缘节点和服务代理。它是由C++编写的CNCF孵化项目,是具备厂商无关性、高性能、轻量级的应用代理服务,已在Lyft上开发和进行了battle测试。Envoy可在不改变现有应用程序代码行的情况下,为微服务提供针对超时、安全、重试、回路制动在内的容错能力。通过与Prometheus、Fluentd、Jaeger和Kiali的集成,它提供了对微服务之间事件的自动可见性。Envoy还具备执行流量路由和流量分发能力,负载均衡failovers的域感知能力,因此还可以充当一个边缘代理(如Kubernetes L7 Ingress控制器)的角色。

虽然服务代理领域已经有很多可选的项目,但Envoy激发了许多关于服务网格和现代负载平衡的兴趣点和革命性想法,对现有生态起到很好的补充。涉及Envoy部署的有Heptio公布的Contour项目,这个项目是部署Envoy代理作为反向代理和负载平衡器来充当Kubernetes的入口控制器。Contour支持动态配置更新和多团队Kubernetes集群,能够限制可能配置虚拟主机和TLS凭证的命名空间,并提供高级负载平衡策略。另一个以Envoy为核心的项目是datawire Ambassador,这是一个强大的Kubernetes原生API网关。由于Envoy是用C++编写的,非常轻量级,非常适合在Kubernetes内部以Sidecar模式运行,也非常适合与API驱动的配置更新的风格相协同,成为dataplanes服务网格的理想候选方案。另外,服务网格 Istio宣布Envoy是其dataplane的默认服务代理,Envoy代理以Sidecar模式部署在Kubernetes中的每个实例上。创建一个由Istio的控制面板配置管理的透明的服务网格。这种方法与Linkerd v1中使用DaemonSet模式完全不同,后者提供了每个服务的可见性,并提供在Kubernetes甚至混合云场景中为每个服务创建安全TLS的能力。最近,Hashicorp宣布其开源项目Consul Connect也将使用Envoy在微服务之间建立TLS连接。

现在,Envoy在背后没有任何供应商或商业项目的驱动下,创立了一个庞大而活跃的开源社区。如果您想尝试Envoy,也建议试用一下Istio、Ambassador或Contour, 2018年12月10日在西雅图,Kubecon的Envoy社区成功地主办了第1届EnvoyCon,欢迎大家加入到社区。
##安全
21.png

Falco

Falco(沙箱阶段)——Falco是Sysdig开发的开源实时安全工具,设计用来检测在Kubernetes编排系统中的异常活动和入侵行为。它驻留在用户空间中,使用Sysdig内核模块检索系统调用活动。Falco与SecComp或AppArmor之类的执行工具相比,它具备更多的审计功能。

Falco用一组预配置的规则,定义了需要注意的行为和事件。然后以DaemonSet方法运行在Kubernetes中,基于这些规则,Falco可以检测到任何调用Linux系统的行为,并为这些行为添加警报。类似的行为可能来自于在容器内的shell运行脚步,或建立出站网络连接的二进制文件。这些事件可以通过Fluentd在STDERR上捕获,然后发送到ElasticSearch进行过滤或解除告警。从而可以帮助用户迅速应对如容器破坏或损毁的安全事故,减少此类事件造成的经济损失。

随着Falco被纳入CNCF的沙箱阶段,我们希望它以后与更多的其他CNCF项目深度集成,例如在Falco内集成官方的Helm Chart。
22.png

Spiffe

Spiffe(沙箱阶段)——在应用负载之间建立互信是一个复杂的问题,且随着负载的弹性伸缩和动态调度,这个问题变得更为困难甚至危险。但Spiffe是解决这个问题的云原生方案。Spiffe提供了一个策略驱动、API驱动且完全自动化的安全产品标识框架。它通过验证身份来开启应用负载之间的通信。Spiff现在还相对较新,主要是设计用于与Spire紧密配合的项目。
23.png

Spire

Spire(沙箱阶段)——Spire是Spiffe的运行环境,是一系列可集成到云提供商和中间件层的软件组件。Spire采用模块化架构,支持多种平台。目前,围绕Spiffe和Spire的社区发展非常迅速。HashiCorp刚刚宣布在Vault中支持Spiffe ID,使得它可用于关键信息和常态轮换。Spiffe和Spire现在都处于CNCF的沙箱阶段。
24.png

Tuf

Tuf(孵化阶段)——Tuf是“The Update Framework”的缩写。它是一个用于可信内容分发的框架。内容信任问题是一个重要的安全问题。Tuf通过验证软件的出处,并确认只使用软件的最新版本,来提供内容信任,改善这个问题。TUF项目在下面将提到的Notary项目中扮演许多非常重要的角色。也被许多公司用于生产环境构建内部工具和产品,这些公司包括Docker、DigitalOcean、Flynn、Cloudflare和VMware。
25.png

Notary

Notary(孵化阶段)—— Notary是一种安全的软件分发实现。本质上,是基于TUF,确保所有提取的Docker镜像都是具有签名、正确和未篡改的镜像版本。 Notary可以贯穿于CI/CD工作流的所有阶段,解决Kubernetes中基于Docker部署的一个主要安全问题。Notary发布和管理受信内容的集合。它允许DevOps工程师批准已发布的可信数据并创建签名集合。这类似于Linux系统中软件库的管理工具,但只是用于Docker镜像管理。Notary的主要目标包括保证镜像版本的更新情况(始终有最新的内容,以避免漏洞),和对象之间的信用委托。例如用户之间,不可信镜像和传输通道的可信分发等。虽然Tuf和Notary通常不被终端用户直接使用,但它们的解决方案集成到各种商业产品或开源项目中,用于可信分发的内容签名或图像签名,这些产品包括Harbor、Docker Enterprise Registry、Quay Enterprise、Aqua。在这个领域还有另一个有趣的开源项目Grafeas,它是一个开源的元数据API。所存储“attestations”或图像签名可以作为部分授权控制的校验,也可用于容器分析API和GCP的二进制授权。和JFrog,AquaSec的同类功能类似。
26.png

OPA

Open Policy Agent(沙箱阶段)——Open Policy Agent(OPA)采用强制声明方式来指定策略,允许在一个技术堆栈中分发不同类型的策略,并自动更新,而无需重新编译或重新部署。在应用和平台层,OPA以从服务发送查询的方式通知策略决策。它与Docker、Kubernetes、Istio等应用都有不错的集成效果。
##数据流和消息流
27.png

NATS

NATS(孵化阶段)——NATS是一个聚焦中间件的消息传递服务,允许基础设施在分布式系统之间发送和接收消息。它的集群和自动修复技术具备高可用性,并且它基于日志的数据流保证了有历史数据引用消息的送达和所有信息的接收。NATS有一个相对简单的API,支持多种技术用例,包括云中常规消息传递、微服务传输、控制平面和服务发现等消息传递,以及物联网消息传递。与前文所列的日志记录、监视和跟踪解决方案所不同的是,NATS工作在应用层。
28.png

gRPC

gRPC(孵化阶段)——gRPC是一个高性能RPC框架,提供在多个平台上,库、客户端和服务器之间进行通信的能力。可以在任何环境中运行,并为Envoy和Nginx等代理提供支持。gRPC为负载平衡、跟踪、健康检查和身份验证提供可插入的支持,来实现有效地连接服务。将设备、应用程序和浏览器与后端服务连接起来。gRPC是促进消息传递的应用层工具。
29.png

CloudEvents

CloudEvents(沙箱阶段)——CloudEvents为开发人员提供了一种通用的方式来描述跨多云环境下发生的事件。通过提供描述事件数据的规范,CloudEvents简化了跨服务和平台的事件声明和传递。项目仍处于沙箱阶段,还需要极大地提高应用程序的可移植性和效率。
# 后续展望
云原生生态正在不断地飞速增长。在不久的将来,还将有更多的项目被纳入到沙箱阶段,让它们有机会获得社区的兴趣和认识。我们希望像Vitess,NATs,Rook之类与基础设施相关的项目能不断得到CNCF的关注和支持。因为他们是云原生部署的重要推动者。同时,在云原生持续交付的领域还相对空白,我们希望CNCF能够继续关注。

尽管CNCF在不断纳入新项目,让成熟的项目毕业。但同样重要的还需要有一种工作机制,将那些因失去社区关注,价值性不高或被其他项目取代的项目从CNCF孵化器中移除。虽然项目提交过程对任何人都是开放的,但我希望TOC委员会继续只资助最优秀的候选者,使CNCF成为项目间协同良好,多样化的生态系统。

作为CNCF的大使,我希望教会人们如何使用这些技术。在CloudOps,我带领了Docker和Kubernetes的研讨会,推广云原生技术,并帮助DevOps团队实践他们的应用。我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。我也鼓励大家加入CloudNativeCon。通过邮件联系@archyufa或CloudOps,了解更多关于云原生技术的信息。

原文链接:The Beginner’s Guide to the Cloud Native Landscape(翻译:易理林)

石油巨头如何与Kubernetes, DevOps共舞?

灵雀云 发表了文章 • 0 个评论 • 734 次浏览 • 2018-12-05 11:08 • 来自相关话题

近日,中国石油自主知识产权的勘探开发梦想云(E&P Cloud)平台V1.0在京隆重发布。作为支持梦想云落地的唯一容器 PaaS 和云原生技术领域合作伙伴,灵雀云凭借强大的技术实力和卓越的服务能力,协助中油瑞飞全程深度参与了梦想云 PaaS 平台的建设。 ...查看全部
近日,中国石油自主知识产权的勘探开发梦想云(E&P Cloud)平台V1.0在京隆重发布。作为支持梦想云落地的唯一容器 PaaS 和云原生技术领域合作伙伴,灵雀云凭借强大的技术实力和卓越的服务能力,协助中油瑞飞全程深度参与了梦想云 PaaS 平台的建设。


在不久前召开的年度开源技术盛会 KubeCon+CloudNativeCon 上,灵雀云CTO 陈恺携手中油瑞飞资深架构师迟汇发表了以“Big Oil on Kubernetes and DevOps”为主题的演讲,对勘探开发梦想云平台项目进行了阐述。


演讲分为三个部分:
首先,由陈恺做项目背景介绍;其次,由迟汇介绍基于Kubernetes、微服务和DevOps等先进技术和理念的统一技术平台的设计思路和方案;最后,再回到产品和技术,由陈恺介绍灵雀云如何协助中油瑞飞将云原生技术成功落地。
以下为演讲实录:
灵雀云陈恺:


大家好,我是灵雀云的CTO陈恺,今天要为大家分享一下灵雀云为国内最大的能源企业建设企业级PaaS平台的案例。非常荣幸请到中油瑞飞负责DevOps的迟汇和我一起为大家分享,中石油如何落地 Kubernetes 和 DevOps 。

像中石油这样体量的企业,大家可以想象业务环境的复杂和规模的庞大。复杂的业务板块面临很多挑战,比如十几个油田以前没有统一的规划,各自运行自己的IT系统,那么数据就会散落在各个地方,没有办法串联和共享,因此就无法把数据真正地利用起来。从平台级别来看,每个油田也不会做统一的IT平台,难以对上面的业务做统一的支撑。


灵雀云协助中油瑞飞建设的勘探开发梦想云就是应对这些挑战的。在底层我们会建立统一的数据库,把散落在各个油田的各种各样的数据相互之间打通,集中到一起,对数据做一个治理;中间是统一的技术平台,也就是我们今天主要讲到的基于Kubernetes的PaaS平台,这当中主要涵盖三个场景:容器、DevOps和微服务治理,相当于是整个云原生的三个核心要素。


项目的最终目标是建立统一的数据湖和统一的技术中台,在上面解决整个中石油的通用的业务。


那么接下来有请中油瑞飞的迟汇介绍一下中石油项目采用的技术和整体建设思路和方案。


中油瑞飞迟汇:


中石油的DevOps平台主要包含三个模块,第一个模块是DevOps,第二个模块是微服务,第三个模块是容器平台。


我们讲DevOps分为八大体系,分别是项目管理、知识共享、持续构建与测试、持续交付、认证与改进、学习培训、运营统计、运营监控。



pic2.jpg




整个工具链支撑体系中,涉及到的工具是15个,大部分是开源的。



pic3.jpg



下面讲述一下平台建设的部分成果展示。做这个项目的过程当中,形成了14个角色,8个职责,5个权限组。右侧是所有的认证体系,这个认证体系里面我们现在已经准备了6个测试场景,4个课件,有新项目接进来之后我们会对它有一个针对性的培训,最后是一个成熟度的评估。

pic4.jpg




灵雀云陈恺:


下面就让我们回到产品和技术层面,来讨论一下怎么样通过灵雀云的平台,为中石油复杂的业务场景搭建DevOps开发体系的。


先来简单了解一下灵雀云的产品。灵雀云有两条主要的产品线。一个是Alauda Container Platform(ACP), 他是一个高度标准化的,专注于云原生应用管理场景的赋能平台,它本身覆盖了三个场景,分别为容器平台,DevOps和微服务,也是我们云原生技术的三个核心。


pic5.jpg




另外一条产品线是Alauda Cloud Enterprise(ACE),主要面对是大型企业的统一PaaS平台。刚才分享的中石油平台就非常符合这样的场景。


ACE本身包含了ACP所有的能力,在这之上,针对大型企业建设统一PaaS平台的场景的能力又有一些加强。举几个例子,比如说ACE的客户通常来说会有很复杂的基础设施的环境,一般都会有很多个数据中心。一些客户开始尝试公有云的话,不会只用一家的产品服务,最后就会是一个异构的、混合的、跨云的基础环境。我们在每一个数据中心,或者说每一个公有云厂商上面根据他的使用需要去搭建多个K8s的集群。也就是说,管理这些异构、复杂的基础设施以及对多集群的支撑是ACE的核心能力。


在集群管理方面,我们不光可以通过ACE去部署一个灵雀云提供的K8s集群(也就是ACP),我们也可以让用户去导入一个他们已经有的K8s集群,现在我们已经有了一些这方面的实践。


另外一个针对大型企业统一PaaS平台的场景,是企业内部共同的需求。一般来说,企业内部会有几大类职能用户,和我们直接合作的是企业内部的平台部门,这个Team对企业内部的业务部门来说,是云平台的提供者和服务团队。


在此基础之上,ACE典型的使用场景通常来说会有几千个开发者,甚至更多。他们之间也需要根据不同的项目或者不同的部门,去划分出不同的租户,租户内部有团队内部协作的需求,租户之间有一些权限隔离和资源隔离,这也是ACE需要解决的另外一个问题。


pic6.jpg




回到今天的主题DevOps。DevOps是ACE一个核心的模块,在我们跟企业客户了解做 DevOps 诉求的时候,每一家都已经在使用一些工具并且有自己的流程,我们需要把现有的系统进行完善,而不是提供一个封闭式的产品去替代以前用的工具。


所以ACE DevOps 的整体思路,是提供一个开放式的DevOps工具链的集成和编排平台,通过集成之前客户已经在用的,以及需要的新的工具变成一个工具链,然后通过编排把这些工具和平台变成一个整体,最后可以贯穿整个应用全生命周期的管理。ACE的核心价值是将 DevOps 的最佳实践,加以提炼形成一个自动化的平台服务,提供给用户。


DevOps工具链集成一方面需要每个工具通过API集成在我们的容器平台上,另一方面,每个工具和平台的用户权限需要打通。每一个企业级的工具都会有自己的租户模型,这些租户模型和平台本身的租户模型需要有联动和对应。这样平台上的数千个工程师,在不同的项目里面共享这些工具时,会有一定的规范。在ACE中,一些核心场景的主流工具,我们会做深度的集成。在这种情况下,80%以上的使用场景在平台本身就可以完成。


刚才有提到,使用ACE在大型企业内部搭建一个统一PaaS平台,分成两类用户:一个是平台部门,负责搭建、维护平台以及对其他业务部门提供支撑和服务,他是平台管理员;另一个是业务部门,可以理解为企业内部的一些项目,也就是平台上面的一个个租户。在使用上大致的流程是这样的:平台部门准备基础设施,需要去部署和准备一些已有的集群,然后会在平台上面创建租户,并且设置管理员,他可以把集群的资源分给租户。租户管理员获取资源后,可以在集群里面创建环境,可以主动把资源向下派分。


对于DevOps实现来说,管理员可以部署和集成一些工具,然后可以把工具发布出来让租户自行订阅。同时,他也可以给每个工具去创建一些资源,然后主动把这些资源分配给租户。从根部管理员这边获得DevOps工具的资源有三种方式,一是管理员主动分配的,二是开发者订阅了管理员发布的库,第三,开发者也可以在平台上自己部署一个工具。


由于时间关系今天就和大家分享到这里,如果想要了解更多关于灵雀云在各个行业的产品实践,可以会后交流,谢谢大家!

Cloud Native相关的应用增长超过了200%

Zangying2005 发表了文章 • 0 个评论 • 1306 次浏览 • 2018-09-11 10:35 • 来自相关话题

每两年进行一次的CNCF调查洞悉了IT社区对云原生技术应用的认知变化。这已经是CNCF第六次关注调查容器化管理市场的热度。 #关键卖点 1. 自2017年12月以来,CNCF项目在生产环境应用平均增长超过200%,所评 ...查看全部
每两年进行一次的CNCF调查洞悉了IT社区对云原生技术应用的认知变化。这已经是CNCF第六次关注调查容器化管理市场的热度。
#关键卖点

1. 自2017年12月以来,CNCF项目在生产环境应用平均增长超过200%,所评估的项目数甚至达到了372%的增长。
2. 自2017年12月以来,受访者中的大部分都使用了类似AWS Lambda(70%) 的平台服务。这使得无服务器技术的应用不断增长,增幅达到22%。
3. 云原生技术的3大优势为更快速的部署时间,改善弹性和云可移植性。
4. 5000员工以上规模的企业受访者中,40%的企业在生产环境中部署了Kubernetes。

#调查方法和受访者情况
这是迄今为止收到过最多的调查回复,共有2400人有效参与了调查,受访者主要来自北美(40%)和欧洲(36%)。均为研发人员或IT相关的角色,分布情况如下:

1. 研发人员:49%
2. 运维人员:36%
3. IT经理:11%
4. 研发经理:14%

大多数受访者都是来自于员工规模超5000人的公司,这使得本次调查的结果更偏向于在企业中CNCF技术项目的使用。参与者排名靠前的行业是科技(22%)、软件(22%)、金融服务(9%)和电信(8%)。

本项调查是用英文进行的,中文版的调查目前还正在进行,结果将于今年晚些时候公布。你可以通过下图了解调查人群的详细统计信息:
1.jpg

#应用开发环境的变化
在本次最新版的调查问卷中,我们额外添加了发布方面的问题,以便更深入地了解公司如何管理他们的软件开发周期。微服务架构的好处之一是灵活部署的能力,从而允许公司根据需要尽可能频繁的进行应用发布。在微服务之前,典型的发布管理中,应用发布频率要低得多,通常是一年一两次左右。本次调查中,这一点变化突出,除发布频率外,受访者发布周期的各种发布占比相当均匀:

1. 每周发布:20%
2. 每月发布:18%
3. 每天发布:15%
4. 临时发布:14%

应用发布频率:
2.jpg

上述的大多数应用发布都是采用自动化处理(42%),使用混合方法发布的受访者占25%,还有27%的受访者使用手动发布。随着自动化发布的增长,管理CI/CD通道的工具也越来越流行,其中Jenkins是标杆性的工具(70%),其次是Terraform(27%)和定制脚本(26%)。

应用发布方式:
3.jpg

此外,在代码检查频率方面,67%的受访者每天多次检查,每周检查几次为28%,每月检查几次的为6%。

至于服务器数量规模(包括VMs,裸机器等),相较于在2017年12月的那次调查数据,我们看到5000+以上规模的受访者有小幅增长, 由14%上升到17%;6-20台机器的受访者,从18%下降到16%;21-50台机器的受访者的占14%,51-100台机器的受访者占11%。

平均服务器数量分布:
4.jpg

#云的应用情况
企业用云的数据分布情况是:自建数据中心占比64%,私有云占比50%,还有77%的企业采用了公有云的方案。

所采用的数据中心类型:
5.jpg

在采用容器化服务方面,大多数受访者公司都部署在AWS平台上(69%降至63%)。紧随其后的依次是本地数据中心部署(从51%降至43%)、谷歌云平台(39%降至35%)、微软Azure(从16%升至29%)、VMware(24%)和OpenStack(从22%降至20%)。括号内数据为相较于上次调查的数据。

容器化服务所部署的环境:
6.jpg

上述数字表现延续了我们在去年看到的趋势,但存在两个显著变化。首先是自有数据中心部署容器较2017年12月的51%下降到了43%,这很可能是由于私有云的使用增加所导致的。其次,这是我们第一次在这些调查结果中看到在VMware上广泛部署容器服务,在2017年12月的调查中,部署于VMware平台的仅仅为1.2%而已。
#容器化服务数量的增长情况
73%的受访者在生产环境采用容器化服务,剩余的27%表示计划在以后采用这项技术。这个数据在17年12月的调查分别是75%和25%。当前在POC环境采用容器化的受访者有89%,而用于测试环境和开发环境的分别是85%和86%。

容器所用于的环境类型:
7.jpg

公司所运行的容器数量也同比基本保持稳定,运行容器少于50个的占29%,50 -249个的为27%,250-999个的为17%,运行的容器数量超过5000个的为15%。和上次的数据对比,使用容器数不到50的公司增长明显,从2017年12月的23%上升到29%,而容器数在250-999的公司数量略有减少,从22%下降到17%。

企业所运行的容器数量分布:
8.jpg

在容器管理工具方面,Kubernetes以83%的受访者采用稳居第一。其次是Amazon ECS 占24%,Docker Swarm占 21%,Shell Scripts占20%。2017年12月同类型数据分别是77%,18%,17%和12%,存在明显的增长趋势。

容器的管理工具类型分布:
9.png

#Kubernetes
58%的受访者在生产环境中采用了Kubernetes。同时,42%的受访者正在为以后应用进行评估。而在人员规模5000以上的企业中,有40%的受访者在生产环境中使用了Kubernetes。

在生产环境中,40%的受访者运行了2-5个Kubernetes集群,运行1个集群的有22%,6-10个集群的有14%,运行集群数超过50个的受访者公司为13%(2017.12数据为9%)。

在Kubernetes所运行的平台环境方面,51%的受访者运行在AWS(上期数据为57%),企业自有数据中心服务器有37%(上期数据为51%),谷歌云平台从上期的39%下降到了32%,微软Azure从23%降至20%,OpenStack从22%降至16%,然而,运行在VMware平台上的却从1%大幅升至15%。以下图标展现了受访者的Kubernetes所部署的平台和容器所部署平台的对比。

Kubernetes环境 vs 容器环境:
10.jpg

当采用本地部署时,大多数受访者都趋向于选择的环境和所选比例为:Minikube(45%),Docker Kubernetes(39%),on prem Kubernetes installations(30%)。

此外,我们还问询了受访者在管理应用程序的各个方面所采用的工具:
##打包工具
首选的打包工具是Helm,占比68%,其次是Kubernetes内置的打包功能。
##自动伸缩技术应用
自动伸缩的应用情况,64%的受访者采用了自动伸缩无状态应用,其次是Java应用(45%),然后是任务/队列处理应用(37%)。未采用自动伸缩技术的受访者,可能是还没有这个功能的应用意识或者不希望在目前对自有的工作负载采用自动伸缩技术。
##入口提供方
Kubernetes的入口提供方应用最多几位依次是:Nginx占比64%(上期数据57%),HAProxy占29%,F5占15%(上期数据11%)和Envoy占比15%(上期数据9%)。
##向集群外暴露服务
受访者向集群外(如internet或其他虚拟机)暴露服务的首要方式是通过负载均衡器(67%)。其次是L7 ingress(39%)和集成第三方负载均衡器提供33%。
##Kubernetes内组织团队间隔离
在Kubernetes内部,受访者进行多个团队间的隔离,使用最多的技术是命名空间(Namespaces)占比71%,其次是独立的集群(51%),仅仅采用标签的为(15%)。
##隔离Kubernetes内的应用
受访者进行Kubernetes应用隔离采用命名空间(Namespaces)占比78%,其次是独立的集群(50%),仅仅采用标签的为(21%)。
#生产环境中的云原生项目
云原生项目有哪些优势呢?受访者提及最多的3个理由是:

1. 更快速的部署时间
2. 改善弹性
3. 云可移植性

用于生产环境和评估中的CNCF云原生项目分布情况:
11.jpg

数据显示,许多CNCF项目在生产环境中的使用较我们上一次的调查有显著的提升。例如容器服务由18%升至45%;CoreDNS由7%升至36%;Envoy由4%升至24%;Fluentd由38%升至57%; gRPC由18%升至45%;Jaeger由5%升至25%,Linkerd由3%升至16%,以及OpenTracing由8%升至21%。就平均值看,CNCF项目在生产环境的应用较上一次调查有200%以上的提升。

受访者正在评估中的CNCF项目数同样较上期调查增长明显。例如容器服务由22%升至55%;CoreDNS由14%升至64%;Envoy由26%升至74%;Fluentd由22%升至43%; gRPC由16%升至55%;Jaeger由15%升至75%,Linkerd由15%升至84%,以及OpenTracing由25%升至80%。就平均值看,CNCF项目评估较上一次调查增长了372%。

CNCF新开发的项目也有很高的关注度,受访者重点评估的项目如SPIRE(94%)、TUF(93%)、Open Policy Agent(92%)、Vitess(92%)和SPIFEE(92%)等,关注比值都非常高。
#使用和部署容器的挑战
云原生技术改变了企业设计,构建应用的方式,挑战也是无法避免的。受访者反馈所面临的挑战主要有:

1. 研发团队的文化转变:41%
2. 复杂度:由35%提高到40%
3. 培训不足:40%
4. 安全性:由43%降到38%
5. 监控:由38%降到34%
6. 存储:由41%降到30%
7. 网络:由38%降到30%

对于这些挑战,有两个显著的变化。首先,本次调查,虽然这是我们第一次明确询问开发团队的文化变化,但它却被认为是使用和部署容器中的最大挑战。其次,缺乏培训是问卷选项以外的挑战。尽管CNCF在过去的一年里在Kubernetes培训上进行了重度投入,措施包括免费和付费课程,以及为Kubernetes管理员和应用程序开发人员提供认证。因此,随着项目的发展,我们将继续投入更多的培训资源开展新项目。

其余的主要挑战与我们过去的调查基本是一致,但是随着有更多的资源和工具用于解决面临的问题,这些选项的被选比例在持续下降。

使用和部署容器所面临的挑战:
12.jpg

同时,有一个有趣的现象是,随着云原生存储项目应用的增长,存储和网络作为挑战的被选比例呈下降趋势。云原生存储项目的应用情况如下:

1. Rook:生产环境应用的受访者占比11%,正在评估中的受访者占比89%(上期调查29%)。
2. Minio:生产环境应用的受访者占比27%,正在评估中的受访者占比73%(上期调查28%)。
3. OpenSDS:生产环境应用的受访者占比16%,正在评估中的受访者占比84%(上期调查分别为7%和14%)。
4. REX-Ray:生产环境应用的受访者占比18%,正在评估中的受访者占比82%。
5. Openstorage:生产环境应用的受访者占比19%,正在评估中的受访者占比81%(上期调查分别为31%和36%)。

企业所采用的云原生存储项目类型:
13.jpg

#Serverless的增长
在本次调查中,我们仍然持续跟进无服务器技术的增长情况。38%的组织当前在使用无服务器技术(上期同类型数据为31%)。其中32%是采用支持平台,6%是采用安装的软件实现。

与上期数据的41%相比,仍有37%的受访者没有采用无服务器技术,但有另外的26%的受访者表示将在未来的12-18个月内计划采用。

选用最多的可安装的无服务器平台有:

1. Kubeless:42%,上期数据2%
2. Apache OpenWhisk:25%,上期数据12%
3. OpenFaas:20%,上期数据10%

企业组织所采用的无服务器平台分布:
14.jpg

选用最多的公有云无服务器平台是:

1. AWS Lambda服务:70%
2. Google Cloud Functions:25%,上期数据13%
3. Azure Funcitons:20%,上期数据12%

企业组织所采用的公有云无服务器平台分布:
15.jpg

随着无服务器技术的使用增长,受访者对无服务器技术项目CloudEvents表现出了浓厚的兴趣,80%的受访者为我们评估了这个项目,还有21%的人在生产中使用它的技术。CloudEvents是CNCF无服务器工作组所组织的成果,它旨在创建一个以通用的方式描述事件数据的规范。
#如何学习更多的技术知识?
对于刚刚涉足云原生项目并期望学习更多相关知识的初学者,以下是受访者学习云原生技术的首要几种方式:
##文档
20%的受访者使用文档来学习云原生项目,这也是本次调查引用的首要资源。例如,SIG-Docs帮助维护的大量Kubernetes详细文档。这其中包括了从如何开始使用某个特定功能到以贡献者身份参与项目的最佳方式等等的所有内容。每个CNCF项目在其网站上都有大量的文档,可以点击https://www.cncf.io/projects/获取。
##KubeCon + CloudNativeCon
12%的受访者选择参加KubeCon + CloudNativeCon,以了解更多他们正在使用的技术。KubeCon + CloudNativeCon集中了所有CNCF项目,并将来自开源云原生社区的技术大咖聚集一堂,以进一步推动原生云计算的发展。这项活动每年在欧洲、中国和北美各举行一次。
##CNCF网站和在线研讨会
12%的受访者会访问CNCF网站和参加在线研讨会。CNCF.io是所有云原生项目的一个主要来源,提供包括近期活动、培训、认证、博客等等诸多主题的信息。

CNCF在线研讨会每周二上午10点到11点(PT)举行。您可以查看近期日程,并查看往期在线研讨会的录音和幻灯片。
##聚会和当地活动
有11%的受访者会通过参加聚会和当地活动来了解云原生技术。CNCF在我们会员体系下主办了149个聚会,活动遍布33个国家,涉及会员超过76000人。你可以点击这里查看的你所在地的聚会。

您可以点击这里查看近期CNCF和世界各地云原生社区的活动,包括从会议到路演等等。
##推特
10%的受访者通过Twitter获取信息。通过Twitter账号,CNCF发布项目、社区和基金会的新闻。读者可以关注自己所喜欢的云原生项目,点击这里可以找到这些Twitter列表(和相关的社交账户)。

学习云原生技术的途径:
16.jpg

#致谢
非常感谢所有参与我们调查的人。我们希望在上海的KubeCon + CloudNativeCon(2018年11月12-15日)和西雅图(2018年12月11-13日)见到您。

请继续关注我们今年晚些时候公布的中文调查结果!

你亦可在此查阅过往的调查结果:

March 2018: China is Going Native with Cloud
December 2017: Cloud Native Technologies Are Scaling Production Applications
June 2017: Survey Shows Kubernetes Leading as Orchestration Platform
January 2017: Kubernetes moves out of testing and into production
June 2016: Container Survey
March 2016: Container survey results

原文链接:CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%(翻译:易理林)

云原生应用的10大关键属性

cleverlzc 发表了文章 • 0 个评论 • 1256 次浏览 • 2018-08-12 10:12 • 来自相关话题

【编者的话】云原生是一系列基于容器、微服务、DevOps工作流以及弹性基础设施的集合,能够更加高效、可靠和敏捷的交付应用价值,本文的10个关键属性将带领你更深入的理解云原生应用。 云原生是一个用于描述基于容器环境的术语。云原生技术用于 ...查看全部
【编者的话】云原生是一系列基于容器、微服务、DevOps工作流以及弹性基础设施的集合,能够更加高效、可靠和敏捷的交付应用价值,本文的10个关键属性将带领你更深入的理解云原生应用。

云原生是一个用于描述基于容器环境的术语。云原生技术用于开发构建应用程序,这些应用程序使用容器打包并且将被部署为微服务,通过敏捷DevOps流程和持续交付工作流,在弹性基础设施上进行管理。

运维团队将手工管理传统应用程序的基础设施资源分配,而云原生应用程序部署在抽象底层计算、存储和网络原语的基础设施上。处理这种新型应用程序的开发人员和运维人员不会直接与基础设施提供者公开的应用程序编程接口(API)交互。相反,编排引擎根据DevOps团队制定的策略自动处理资源分配。控制器和调度器是编制引擎的重要组件,它们处理资源分配和应用程序的生命周期。

像Kubernetes这样的云原生平台暴露了一个扁平网络,该网络覆盖在云提供商的现有网络拓扑和原语上。类似地,通常抽象本地存储层以暴露与容器集成的逻辑卷。运维人员可以分配开发人员和资源管理员访问的存储配额和网络策略。基础架构的抽象不仅解决了跨云环境的可移植性需求,还让开发人员利用新兴模式来构建和部署应用程序。无论基于物理服务器或虚拟机,私有云还是公共云的底层基础架构,业务流程管理器都将成为部署目标。

Kubernetes是当代运行云原生应用程序的工作负载的理想平台。它已经成为云的事实上的操作系统,就像Linux是底层机器的操作系统一样。只要开发人员遵循设计和开发软件作为一组包含云原生应用程序的微服务的最佳实践,DevOps团队就能够在Kubernetes中打包和部署它们。以下是开发人员在设计云原生应用程序时应牢记的云原生应用程序的10个关键属性。


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

原文地址:10 KEY ATTRIBUTES OF CLOUD-NATIVE APPLICATIONS (翻译:刘志超)

CNCF在PromCon上宣布:Prometheus是继Kubernetes之后的第二个CNCF“毕业”项目

wise2c 发表了文章 • 0 个评论 • 1143 次浏览 • 2018-08-10 15:12 • 来自相关话题

SAN FRANCISCO, Calif., August 9, 2018 - 管理Kubernetes和Prometheus等云原生开源技术的 Cloud Native Computing Foundation(CNCF)在PromCon(年度Prometh ...查看全部
SAN FRANCISCO, Calif., August 9, 2018 - 管理Kubernetes和Prometheus等云原生开源技术的 Cloud Native Computing Foundation(CNCF)在PromCon(年度Prometheus会议)上宣布Prometheus是继Kubernetes之后的第二个CNCF毕业项目。在CNCF管理的项目中,要从’孵化’转为’毕业’的成熟水平,项目必须被社区广泛的采用,有结构完整的治理过程文档,以及对社区可持续性和包容性的坚定承诺。

“自2012年成立以来,Prometheus已成为构建现代云原生应用程序的企业首选的开源监控工具之一,”CNCF首席运营官Chris Aniszczyk表示。 “自从被接受成为CNCF的第二个管理项目以来,Prometheus已经培养了一个活跃的开发者和用户社区,让TOC充满信心地毕业了这个项目。作为其成熟的证明,我们很高兴看到Prometheus社区推出OpenMetrics,它采用Prometheus exposition format,并努力将其演变为事实上的行业规范。“

毕业微信图片_20180810115617.png


Prometheus项目于2012年在SoundCloud创建,并于2016年5月捐赠给CNCF。该项目自进入CNCF的’孵化’水平以来已有包括主要版本和次要版本的30个正式版本发布。

“作为该项目的主要支持者,创始人和最终用户,SoundCloud祝贺Prometheus团队在此项目中的成就,”SoundCloud基础设施和核心工程副总裁Jake Maizel说。 “Prometheus帮助改进了许多公司的监控和警报实践,很高兴看到这个项目在官方毕业后进一步发展。恭喜所有参与者!“

Prometheus现在拥有近20个活跃的维护者,超过1,000个贡献者和超过13,000个来自其不断增长的用户群的commits,其中包括ShuttleCloud,Datawire,DigitalOcean,Weaveworks,ShowMax,iAdvize和Uber等。除此之外,Prometheus还与CNCF的首个托管项目Kubernetes集成,以支持服务发现和动态调度服务的监控。

“自从成为CNCF的一部分以来,Prometheus已经成为现代基础设施堆栈的重要组成部分,并帮助塑造了组织监控关键应用程序的方式,”Prometheus项目联合创始人Julius Volz说。 “我们非常自豪能让Prometheus毕业,我们期待与CNCF合作,以维持和发展我们的社区。”

为了正式从孵化进入状态毕业,该项目还采用了CNCF行为准则,执行了独立的安全审计,并确定了自己的治理结构,以发展社区。此外,Prometheus于2017年6月23日完成并获得核心基础设施倡议的最佳实践徽章。 CII徽章展示了Prometheus项目对代码质量和安全最佳实践的持续承诺。

原文链接:Cloud Native Computing Foundation Announces Prometheus Graduation

Kubernetes会被它厚重的复杂度压垮吗?

wjun 发表了文章 • 0 个评论 • 1822 次浏览 • 2018-06-07 13:37 • 来自相关话题

【编者的话】Paul Dix在Kubernetes如日中天的今天写下了这篇文章。粗看是有点不太合时宜,可能不会在如今喧嚣的Kubernetes风潮中溅起一丝涟漪。但恰恰言简意赅的点出了很多平台和社区方方面面的问题,也给出了建议。作为一个已经在多个云端平台和企业 ...查看全部
【编者的话】Paul Dix在Kubernetes如日中天的今天写下了这篇文章。粗看是有点不太合时宜,可能不会在如今喧嚣的Kubernetes风潮中溅起一丝涟漪。但恰恰言简意赅的点出了很多平台和社区方方面面的问题,也给出了建议。作为一个已经在多个云端平台和企业IDC环境落地Kubernetes的团队,我们感同身受文中提到的阵痛期以及对Kubernetes未来的关切。同样希望社区和平台贡献者能看到这些观点,将Kubernetes变得对开发者更加友好,从而让生态更健康,让开发者能把优势资源更多的集中在去发布商业价值的本份上。

思考:服务好应用开发者的重要性

几周之前,我参加了欧洲区的KubeCon并讲了话。这是一次有将近4700人参加的空前的盛会。这让我想起了2014年那次在巴黎的OpenStack峰会。如出一辙的疯狂宣传,供应商的各种秀,以及在主会场的公共区域举行的由开发者组织的大型派对。然而,我感到了这整个场面之后的隐忧:每个和我聊的人不是运维就是SRE(译者:网站可靠性工程师)。我们的应用开发人员在哪里?他们不应该正是这整个复杂的基础架构要服务的人吗?社区真正将有需求的使用者联系起来了吗?进而它让我疑虑:是不是Kubernetes过于复杂了?它会被它厚重的复杂度终结吗?它会跟OpenStack当初一样在2014年后逐渐消失吗?

好吧, 我承认我演的有点过了, 但我要说的是,在我看来这根本不可能发生。Kubernetes有一些优势是OpenStack从来不具备的。首先,Kubernetes已经更具扩展性,因此,所谓能在千万级服务器规模的环境中调度的集群,它能使其梦想成真。其次,三大云供应商(AWS、Azure、Google Cloud)已经开始提供在其之上托管Kubernetes的各种服务(译者:EKS、AKS、GKE)。在短短四年内,Kubernetes已经将自己的地位提高成为云服务商和传统IT基础架构的通用平台。但是,复杂度问题依然让人头疼不已。
# 大部分开发者没有遇到和Google一样的扩展性问题
开发Kubernetes的初衷是为了解决Google公司在扩展性上面临的复杂度以及各种问题。你可能期望这个基础架构是可自愈的,可以横向扩展的,并能支持申明式编程(即infrastructure as code, 基础设施即代码)。然而,对绝大部分的应用和应用开发者来说并没有这样的世界观。大部分应用要么是在用更加现代和高阶的术语来描述它们所谓的扩展性(比如项目的部署规模和用户量)要么还只是刚开始调研自己的市场定位。

那些完全不会有扩展性问题的应用, 通常不需要系统具备可自愈可横向扩展,来徒增复杂度。只要简单地考虑使用单个节点的数据库服务和应用服务,就能够处理你的业务。而且,如果有人做些常规排错的运维,让它能够保持99.5%的可用性,那就已经满足了很多应用和业务的需求。建一套分布式系统所带来的无谓复杂度,以及在投放市场前所开销的额外时间,都完全不值得去纠结和投入。

对于那些全新的应用,他们最大的风险是在于找不到自己的市场定位。就是说,他们都部署好了但没人用。这些代码最终被丢弃,因为,它做出来了但没人要。这样的情况代表了绝大部分的已经写好的应用。我个人就把职业生涯大量的时间用在了寻找“恰当的代码匹配恰当的功能”。只有当你发现了对的应用场景和功能需求,你才去扩展你的应用。否则就是拔苗助长(译者:出自“premature optimization is the root of all evil”)。

我看到Kubernetes的问题在于,在它上面做一个项目,其初期的认知负荷太高。那堆你需要做和考虑的事阻碍了你快速开始和迭代一个项目。在项目初期,实现需求的效率和迭代速度是非常重要的因素。我看Heroku就有个很好的开发模式。你已经有了个托管的Postgres数据库,你只需要git push把代码部署上去并发布。几乎没什么需要去纠结。它也许不支持无限扩展,也有可能成本比较高,但至少你可以等这些真成了你的痛点之后再去操心。

简而言之, Kubernetes让简单的事变难了,也让难的事变得有可能(出自Tom Wilkie一句用在另个项目上的话)。如果Kubernetes真的要成功,它必须要让项目启动期变得更加简单。它必须要降低应用开发者的认知负荷。如果在某些时候,开发者有需要去学Kubernetes的晦涩概念的细节,那也行。因为项目做大了,每件事都会复杂和有难度。但一个成功的开发平台不会在还没必要的情况下,就把那些决策负担和认知压力放到开发者的面前。这话David Heinemeier Hansson(译者:DHH,Ruby on Rails的作者)在2018年的RailsConf的“JIT Learning" 中讲过

说到DHH, 这里我想用Rails作为例子。首先我想来探讨的是:为什么Rail那时会那么火?不是因为Ruby的流行(它曾是一个来自日本并不为人知的语言),也不是因为Rails和Ruby曾是服务动态web页面的框架中响应速度最快的。而是因为它大幅提高了开发者的工作效率。当DHH谈如何在15分钟内搭建博客网站的时候,那些动辄要用数周甚至数月才能完成相同事情的Java和.NET开发人员都惊讶不已。开发者使用Rails是因为他们能将新功能更快的发布给用户,这才应该是所有这些应用框架和系统架构的根本目的。

Rails做的另一个了不起的事是,它会为你开发的应用程序提供了一个命令行工具并帮你去生成scaffolds和项目需要的其他组成部分。这就让开发人员的事情变得简单,他们没必要在项目一开始就要去做成吨的决策。应用程序的代码该如何组织,数据模型该放哪, asset pipeline是什么样,怎么做数据库迁移,以及其他很多为你而完成的任务和决策。如果你想一试框架限定外的东西,也行的,但你不是非得在一开始就去考虑。

我想Kubernetes也可以从Rails的这些各种各样的生成器中获得灵感。事实上Kubernetes里已经有了特定资源的生成器,但还远远不及我想要的。如果对不同类型的应用能有相应模板就会很好。哪怕只有个最通用的模板也好。把关系数据库,应用层,缓存服务器,消息队列,以及worker节点池组合到一起,就能把其中的复杂度封装, 从而满足90%或更多应用在开发时的需求。如此简单的一个结构能够横向扩展进而支撑一个难以置信的请求数量和复杂度。一个模板或者生成器就能把所有东西变得开箱即用,还帮你把这些适用于Kubernetes上的资源和代码组织的好好的,对开发者而言这将会非常有帮助。

比如,要是有一个通用元素的Scaffold生成器,事情就会变得很棒。要个MySQL数据库?像这样来个命令就行:
kubectl scaffold mysql --generate

原本创建一个stateful set,service以及其他的必须品都要走段很长的路。现在只要一个简单命令就能在Kubernetes环境里部署一个scaffold,并且,你还能只通过几行命令就能有一个可以直接上生产的数据库。如法炮制,各种流行的应用框架,message brokers,以及其他我们能想到的东西都能被创建出来。

也许operators与Helm Chart的组合就能搞定上面说的,但我觉得这不能算完。总不能强迫开发者还要再去学两个Kubernetes外的东西吧。虽说只是多学一些新语法和装个新的命令行工具,那也是额外费心费力的事。这样的功能应该是Kubernetes的“一等公民”,是Kubernetes拥有“开箱即用”般体验的组成部分。他们要能够通过kubectl就可以用起来。
# CNCF项目版图很大而且越来越大
这不是Kubernets特有的问题,而是CNCF项目版图就很巨大。这就使得KubeCon和CNCF的峰会被极度的碎片化。光在峰会的不同场次就有14个宣讲。而作为开发人员,下图这些工具中哪些是我项目需要的呢? 来看看这张项目版图吧:
cloud-native-landscape.png

好吧,看了也没办法搞清楚。更好的方式, 是把预先就挑好的工具提供给应用开发人员,让他们先按照简便方法走,如果他们能想到去用不同的工具,那更好,但是他们不需要一开始就非要去考虑。CNCF正在激增的复杂度和广度有可能会分散人们聚焦在Kubernetes的注意力也会弱化它作为开发平台的定位。对此我也不知道该怎么说,或者讲得夸张点,仅从我个人角度来看,现在这峰会俨然就是部工具为主角的小电影。试问,你都能把整个职业生涯消耗在去学如何为平台开发新的工具上了,还费什么劲去解决用户的问题?

怎么强调都不够:基础架构只是一个帮助开发者解决真实用户问题的工具。它应该能帮助开发者优化效率和提高发布的能力。在这点上能做得好的开放平台就能胜人一筹。
# 所需知识
有时,开发者需要对基础架构的各种工具有更深的了解。像大部分AWS上的开发者对那个云上的组件比较熟悉,就跟GCP或Azure上的开发者熟悉他们云上的组件一样。让Kubernetes作为项目的基础架构也许会更有前景,因为开发者只学这一种范式就能把它和项目铺上任何公有云或者私有云。

这点也许就是我们选择Kubernetes的原因,把它作为我们新开发的2.0版云服务的基础架构。可学习曲线是明摆在那儿的,所以我们开发团队还在热身。为了达到目的,我让整个研发团队必读Kubernetes : Up and Running这本书。

我希望学习曲线是相对温和的, 而Kubernetes作为一个生态,要去拥抱开发者的需求才能真正成功。通过提供面向用户的应用来解决客户问题,在这样一个服务过程中,说到底,基础架构只是一个支持型的工具。“激发应用开发者的效率”是最好的也是最明确能让一个平台被广泛使用和接受的正道。

原文链接:Will Kubernetes Collapse Under the Weight of Its Complexity? (翻译:万俊)

=============================================================
译者介绍
万俊,MicroFocus上海软件研发部经理。

BoCloud博云获得CNCF Kubernetes服务提供商认证

博云BoCloud 发表了文章 • 0 个评论 • 794 次浏览 • 2018-05-29 08:50 • 来自相关话题

近日,BoCloud博云正式获得 CNCF 和 Linux 基金认证的 Kubernetes 服务提供商资质(KCSP),此认证证明BoCloud博云在 Kubernetes 社区从事活动(包括积极贡献代码)、支持企业最终用户的商业模式、以及将工程师派驻客户现 ...查看全部

近日,BoCloud博云正式获得 CNCF 和 Linux 基金认证的 Kubernetes 服务提供商资质(KCSP),此认证证明BoCloud博云在 Kubernetes 社区从事活动(包括积极贡献代码)、支持企业最终用户的商业模式、以及将工程师派驻客户现场这三面具有相应的技术实力。


默认标题_官方公众号首图_2018.05_.28_.png



KCSP 计划(全称 Kubernetes Certified Service Provider)是由 CNCF 和 Linux 基金会发起,旨在对在 Kubernetes 的企业应用中拥有丰富经验的服务商进行认证。而被认证的 Kubernetes 供应商均可提供 Kubernetes 支持、咨询、专业服务和培训。同时,KCSP 计划可以确保计划采用 Kubernetes 的组织得到更加专业的支持和服务,确保可以支持其生产和运营方面的要求。

根据 CNCF 相关规定,KCSP 计划要求申请企业除了积极参与 Kubernetes 社区活动,长期做出积极贡献之外,更为关键的是企业的商业模式支持为客户提供各种 Kubernetes 技术支持服务,包括将工程师派驻客户现场,并且企业需要至少三名工程师通过Kubernetes管理员(CKA)考试认证。


TIM截图20180528142428.png



“KCSP 的创始成员代表 Kubernetes 生态系统趋于成熟,还表明 Kubernetes 已准备好广泛用于大大小小的企业。随着
> Kubernetes 不断发展,企业对于专家服务和支持这方面的要求也随之提高。与 KCSP
> 合作的企业可以确信,他们选择合作的商业伙伴拥有帮助在 Kubernetes 方面取得成功所需的培训服务和技能。”
>
> ——云原生计算基金会的执行董事丹·科恩(Dan Kohn)



BoCloud博云成立于2012年,是国内云计算开源软件商业化服务商的领导者,为企业级客户提供私有云、混合云、智能化运维系统、大数据基础设施的咨询、建设、维护、升级服务,帮助企业在关键运营场景中实现数字化转型,提升企业主业的生产率。凭借对客户业务流程和应用管理难点的深刻理解,以及对云计算前沿技术的持续跟踪投入,BoCloud博云形成了系列产品以创新云技术支撑企业核心业务,构建数字化高效 IT 系统。公司自主研发的多项软件产品,包括企业级 PaaS 容器管理平台 BeyondContainer、统一云管平台 BeyondCMP、自动化运维产品 BeyondBSM等,已在金融、电力、石油、政务、IDC、航空等行业领域的生产系统中落地实施,为国有电力公司、股份制银行、大型支付机构等标杆行业客户的重要生产系统提供服务。

此次成为 CNCF 认证的 Kubernetes 服务提供商之后,BoCloud博云将继续支持云原生技术,在推动云计算开放性、标准化方面贡献自己的力量。同时,也将成为企业用户在 Kubernetes 领域内合作的最佳合作伙伴。

苹果宣布加入云原生计算基金会

大卫 发表了文章 • 0 个评论 • 408 次浏览 • 2019-06-13 08:27 • 来自相关话题

云原生计算基金会(简称CNCF)作为Kubernetes等顶级开源项目的运营方,今天宣布苹果公司即将以最高级白金用户的身份正式加盟。凭借这位新成员,CNCF如今已经拥有89位最终用户成员,其中还包括阿迪达斯、Atlassian、Box、GitHub、纽约 ...查看全部

云原生计算基金会(简称CNCF)作为Kubernetes等顶级开源项目的运营方,今天宣布苹果公司即将以最高级白金用户的身份正式加盟。凭借这位新成员,CNCF如今已经拥有89位最终用户成员,其中还包括阿迪达斯、Atlassian、Box、GitHub、纽约时报、Reddit、Spotify以及沃尔玛等。

与以往的作风一样,苹果公司并没有对此次公告做出评论。但CNCF方面指出,最终用户资格主要面向那些“对开源云原生技术高度依赖”且希望回馈整个社区的重度用户。作为CNCF最终用户成员,苹果公司实际上也正式加入了Linux基金会。

作为成员关系的一部分,苹果公司还在CNCF管理委员会当中获得一个席位,苹果方面的高级工程技术经理Tomer Doron将出任这一职位。

云原生计算基金会CTO Chris Aniszczyk表示,“吸引到苹果这样一家拥有丰富经验与庞大业务规模的企业作为最终用户成员,充分证明了云原生计算在未来基础设施与应用程序开发方面的可观潜力。我们很高兴能够获得苹果公司的支持,并期待着未来能够为更为广泛的云原生项目社区做出更多贡献。”

虽然很多朋友可能不会把苹果公司与开源参与企业联系起来,但事实上该公司确实已经开放了从Darwin操作系统的XNU内核到Swift编程语言等一系列内部成果。话虽如此,苹果方面一般不会参与开源云基础设施社区,而这次的举动可能预示着这位消费电子巨头正在迎来转变。苹果公司肯定拥有自己的数据中心,因此其确实有可能高度依赖着各类开源基础设施项目——当然,按照苹果的一贯风格,其对这类话题往往避而不谈。

原文链接:Apple joins the open-source Cloud Native Computing Foundation

云原生计算基金会宣布containerd项目正式毕业

大卫 发表了文章 • 0 个评论 • 639 次浏览 • 2019-03-01 08:22 • 来自相关话题

【编者的话】时至今日,containerd已经成为阿里云、AWS、Cloud Foundry、Docker、谷歌、IBM、Rancher Labs以及更多生态系统支持方们采用范围最广的容器运行时选项。 作为Kubernetes与Pro ...查看全部
【编者的话】时至今日,containerd已经成为阿里云、AWS、Cloud Foundry、Docker、谷歌、IBM、Rancher Labs以及更多生态系统支持方们采用范围最广的容器运行时选项。

作为Kubernetes与Prometheus等开源技术的坚定支持者,云原生计算基金会日前宣布,继Kubernetes、Prometheus、Envoy以及CoreDNS之后,containerd已经成为其第五个毕业项目。事实上,要从孵化阶段一步步发展成熟至毕业水平,这些项目必须表现出活跃的采用度、良好的多样性、规范的治理过程,以及对社区可持续性与包容性的坚定承诺。

云原生计算基金会CTO Chris Aniszczyk表示,“在被云原生计算基金会接纳近两年之后,containerd如今仍然拥有着显著的发展态势——这意味着整个市场对于基础窗口技术仍然高度渴求。社区中的大量工作与协作成果有力支持着这款核心容器运行时方案的开发与测试。此外,社区还在努力扩大维护者规模与采用基础,同时亦顺利通过了外部安全审计。看到项目能够顺利毕业,我感到非常激动。”

诞生于2014年的containerd最初由Docker所打造,旨在为Docker引擎提供低层运行时管理器。而在2017年3月被纳入云原生计算基金会之后,containerd已经逐步发展成一款行业标准性质的容器运行时方案。此项目始终强调简单性、健壮性与可移植性,目前被广泛用作Docker引擎与OCI runc执行器之间的对接层。

containerd项目维护者兼Docker公司工程师Michael Crosby指出,“Docker公司当初之所以决定将containerd贡献给社区,是因为我们希望能够将这套早已成为Docker引擎中标准化组成部分的方案分享给数以百万计的企业以及不计其数的用户,并推动其成为真正强大且可扩展的运行时解决方案。随着我们不断扩大范围以满足更多现代容器平台(例如Docker平台与Kubernetes生态系统)的需求,我们高兴地看到在过去一年当中,containerd项目在采用量与后续创新方面都带来了喜人的表现。随着containerd采用量的不断增长,我们期待着立足整体生态系统继续开展合作,并借此推动我们的行业长期保持发展。”

IBM Cloud Kubernetes Serivce杰出工程师Dan Berg也表示,“IBM Cloud Kubernetes Service(简称IKS)致力于为我们的客户提供卓越的托管Kubernetes使用体验。为了实现这一目标,我们一直在努力简化IKS的架构与运营方式。迁移至containerd,将有助于简化我们代表客户所配置及管理的Kubernetes架构。通过将containerd选定为我们的容器引擎,我们成功减少了架构中的额外层数量,从而在改善运营效果的同时帮助客户提高了服务性能。”

自项目建立以来,containerd一直吸引着众多维护者与提交者的参与。目前,我们共有来自阿里巴巴、Cruise Automation、Docker、Facebook、谷歌、华为、IBM、微软、NTT以及特斯拉等公司的14位提交者、4406项提交成果以及166位贡献者。大家可以通过DevStats网站查阅containerd项目的统计信息与贡献者资料等。

阿里云高级工程师Li Yi解释称,“自业务建立以来,阿里巴巴一直在使用containerd项目。现在,我们很高兴地看到该项目顺利迎来这一重大里程碑。作为一款容器运行时方案,containerd凭借着开放、可靠与通用等特质一直发挥着关键作用。在阿里云,我们充分将containerd的简单性、健壮性与可扩展性引入到阿里云KubernetesSerivce与Serverless Kubernetes当中。阿里巴巴团队还将继续努力推动社区进一步实现创新与突破。”

为了正式由孵化阶段走向毕业,containerd项目遵循云原生计算基金会提出的基本原则,接受独立的外部安全审计,并确定了自身治理结构以保障社区发展。此外,containerd还获得并保有核心基础设施倡议最佳实践徽章(简称CII徽章)。这项成就于2018年9月1日正式达成,CII徽章代表着整个社区对于代码质量与安全最佳实践做出的不懈承诺。

##containerd项目背景信息

* containerd 是一套行业标准化容器运行时,强调简单性、健壮性与可移植性。Containerd可作为Linux与Windows系统中的守护程序。
* containerd管理其所在主机系统上的整个容器生命周期——从镜像传输到存储、到容器执行与监督,再到底层存储乃至网络附件等等。
* 若您希望下载containerd项目、查阅相关说明文档以及了解如何加入社区,请访问: https://github.com/containerd/containerd。

原文链接:Cloud Native Computing Foundation Announces containerd Graduation

云原生计算基金会宣布CoreDNS项目正式毕业

JetLee 发表了文章 • 0 个评论 • 751 次浏览 • 2019-01-25 09:49 • 来自相关话题

云原生计算基金会(简称CNCF,负责为Kubernetes与Prometheus等开源技术提供支持)日前宣布,继去年毕业的Kubernetes、Prometheux以及Envoy等开源技术之后,CoreDNS成为其2019年的首个毕业项目。要从孵化阶段走向毕业 ...查看全部
云原生计算基金会(简称CNCF,负责为Kubernetes与Prometheus等开源技术提供支持)日前宣布,继去年毕业的Kubernetes、Prometheux以及Envoy等开源技术之后,CoreDNS成为其2019年的首个毕业项目。要从孵化阶段走向毕业,项目必须在市场上表现出活跃的采用积极性、多样性、规范的治理流程,以及对于社区可持续性与包容性做出坚定承诺。

CoreDNS是一套快速、灵活且现代的DNS服务器方案,亦可在云原生部署场景下提供服务发现功能。基于其提供了能够向下兼容,且具备可扩展性的Kubernetes集成能力,因此在Kubernetes的最新版本(1.13)中CoreDNS被指定为未来一切部署场景中的默认DNS选项。此外,该服务器还适用于配合AWS(启用AWS Route 53与etcd)的混合云环境下的原生云集成,未来亦有计划进一步为Google Cloud DNS提供支持。

云原生计算基金会COO Chris Aniszczyk表示,“CoreDNS已经在最近两年中成为云原生计算基金会不可或缺的重要项目,并在社区的努力推动下达到毕业水平,同时正式成为Kubernetes的默认DNS服务器。此外,CoreDNS亦是一款出色的独立DNS服务器方案,正不断被用于更多其它环境——我们很高兴能够随着项目的发展而不断为其社区提供支持。”

该项目由Miek Gieben于2016年3月正式建立,他当时担任谷歌公司的站点可靠性工程师。在构建CoreDNS时,社区考虑到其它DNS服务器方案的局限性,希望打造出一款能够与多个后端(例如etcd、Consul以及Kubernetes)进行通信的通用型DNS服务器。CoreDNS随后于2017年加入到Cloud Native Sandbox当中,并于2018年2月晋升为孵化项目。如今,该项目已经拥有100多位贡献者,16位活跃维护者,亦有众多组织机构在Kubernetes内外的生产环境中加以使用——包括Bose、Hellofresh、Skyscanner、SoundCloud、Trainline以及Zalando等。

CoreDNS维护者Yong Tang表示,“自从2017年年初加入云原生计算基金会以来,CoreDNS迎来了良好的社区增长表现,亦在生产环境中展现出惊人的应用空间。我们非常感谢云原生计算基金会对CoreDNS项目的大力帮助,亦期待继续保持合作以不断扩大我们的社区规模。”

Okkur Labs创始人兼CoreDNS维护者Michael Grosser指出,“CoreDNS项目及社区已经取得巨大进展,而成为云原生计算基金会毕业项目则标志着一大重要里程碑。从一套用于发布Prometheus指标的简单DNS服务器,到一款具备固有灵活性的成熟DNS解决方案,再到大多数Kubernetes集群内的信心组件并为无数用户带来更理想的稳定性与灵活性,这一切都令我们对于CoreDNS背后强大的支持社区充满信心。”

谷歌云计算高级软件工程师、CoreDNS高级维护者John Belamaric表示,“CoreDNS的灵活性以及基于插件的架构设计,已经被证明是一种理想的DNS服务器构建思路。CoreDNS的易于集成与可扩展能力对于各种DNS服务与用例的实现而言至关重要——从Kubernetes服务发现到基于策略的DNS与广告拦截,都离不开这两大重要能力。云原生计算基金会对该项目提供的支持同样不可或缺,我们很高兴能够正式毕业并继续发展我们的多元化项目社区。”

Infoblox公司软件经理Francois Tur指出,“作为一位项目维护者,我专注于调整CoreDNS以供Kubernetes社区使用,以Kubernetes中的CoreDNS部署场景为基础开展协作,并验证CoreDNS作为Kubernetes集群指定DNS服务器的实际效果。今天CoreDNS从云原生计算基金会毕业,对于我们的项目社区来讲是个了不起的成熟。这一旅程开始于两年多之前,而且一切都才刚刚开始。”

为了正式从孵化状态毕业,CoreDNS项目遵循云原生计算基金会的行为准则。CoreDNS团队还在过去一年当中先后发布了12个版本,项目目前拥有35款内置插件以及15款外部插件,其中一部分由Kubernetes社区开发而成。此外,CoreDNS在过去两年中还参与到谷歌公司组织的代码夏令营(Google Summer of Code)当中——活动中导师将与在校实习生们结对探索,旨在推动云原生项目的不断发展。

Infoblox公司高级软件经理Naveen Singh表示,“在Infoblox公司,我们很自豪地能够在自己的SAAS DNS产品当中使用CoreDNS,而且目前也已经在全球范围内部署了众多CoreDNS实例。CoreDNS目前正在为全体Infoblox云客户支持生产DNS流量,其中也包括不少财富五百强企业。我们非常欣赏CoreDNS的插件架构,其为我们带来了巨大的灵活性空间、更高的开发速度与更快的发布周期。”

GitNS创始人Michael Grosser指出,“将GitNS.com建立在CoreDNS这一坚实的基础之上,是我做出的最明智的决定之一。考虑到DNS的基本特性,要求我们必须选择一套具有高性能、高可靠性以及强大扩展能力的系统作为构建基础。CoreDNS项目拥有着令人难以置信的卓越社区,我们非常乐于为其提供支持。随着CoreDNS从云原生计算基金会正式毕业,其将成为构建基础设施与定制化用例中最理想的DNS平台选项之一。”

CoreDNS背景信息:

* CoreDNS是一套由Go语言编写而成的DNS服务器,其遵循Apache License Version 2许可,且完全开源。
* CoreDNS凭借着强大的灵活性而适用于多种环境及用例。其可用于Kubernetes服务发现、权威DNS服务器、高DNS强度应用的本地缓存等等。其中的各款插件能够彼此链接以实现Prometheus指标检测等额外功能,亦可以开箱即用的方式带来重写查询等功能。
* 除了从标准区域文件提供DNS之外,CoreDNS还通过Kubernetes插件与Kubernetes相集成,可利用etcd插件直接对接etcd,并能够与多种其它后端数据提供程序进行整合。
* 若需下载CoreDNS项目本体,或者参阅与项目相关的说明文档与背景信息,请访问 https://github.com/coredns/coredns。

原文链接:Cloud Native Computing Foundation Announces CoreDNS Graduation

云原生技术的初学者指引

Zangying2005 发表了文章 • 0 个评论 • 872 次浏览 • 2019-01-02 16:08 • 来自相关话题

当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目 ...查看全部
当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目方案都包括在这张图内。

我有幸成为CNCF的大使,致力于在加拿大推广社区活动和云原生的教育。同时,在CloudOps社区, 我还带领着Docker和Kubernetes研讨会,向大家普及云原生技术,帮助DevOps团队实践相关的技术应用。

我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。大家通过电子邮件或在博客上@archyufaor的方式保持联系。为他们提供云原生技术的信息咨询。

同时,我还编写了云原生技术的初学者指南。希望能帮助读者理解这个领域并在这个领域取得更好的进展。
#CNCF的历史背景
2014年,谷歌开源了一个主要用于容器编排的,名为博格(Borg)的内部项目。由于没有机构来管理这个项目,谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而Borg项目就更名为Kubernetes,并用Go语言重写了实现部分,成为了CNCF的启动捐赠项目。毫无疑问地讲,Kubernetes只是开始,后续有大批的新项目先后加入到CNCF,围绕着Kubernetes不断地扩展功能。
#CNCF的使命
通过提供多种选项的开发软件社区,帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作,希望实现完全由CNCF成员项目演化出来的成熟技术栈。这便是CNCF在云端的自我使命。
#CNCF的历程
目前共有25个项目已经被CNCF接受,在跟进Kubernetes生态发展。希望加入到CNCF的项目,必须是由技术监督委员会(TOC)选定并通过投票评比,取得绝大多数的投票认同才可以加入。投票过程由TOC贡献者组成的一个优秀社区来辅助进行,而TOC贡献者是来自CNCF成员公司的代表,我有幸也是其中一位。评选通过的项目就叫CNCF成员项目,CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。
##沙箱阶段
这个阶段的项目非常早期,在部署到生产环境之前,需要显著地提升代码成熟度,积极参与开源社区的互动。项目之所以被选中,主要是因为它们具备的潜力是社区所没有的。在CNCF的指南中提到,CNCF将帮助推动沙箱项目的公共可见性,并促进其与现有项目形成体系。但沙箱项目从CNCF获得的资金和营销支持非常少,并且每12个月都要接受审查,发展不够好的项目可能会被淘汰掉。
##孵化阶段
当项目满足所有沙箱标准并具备明显的增长和成熟度特征时,它们就进入孵化阶段。这时,它们必须至少在三家公司的生产环境中使用过,具备稳定的团队,确保稳定提供对社区的贡献,包括处理来自社区的新功能和代码要求等。
##毕业阶段
孵化项目一旦达到生产使用的临界点,TOC就可以投票决定项目是否进入毕业阶段。毕业的项目必须证明有很高的采用率,并满足所有孵化标准。项目的提交者必须至少来自2个不同的组织,具有文档化和结构化的管理流程,并满足Linux基金会核心基础设施计划的最佳实践徽章要求。截止到目前,只有Kubernetes和Prometheus两个毕业项目。
# CNCF项目介绍
我将CNCF成员项目划分了12个类别,分别是:编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流。我希望所提供的信息能够帮助公司或个人评估每个项目做什么,如何演化的,以及如何与其他CNCF项目集成等。
##编排
3.png

Kubernetes

Kubernetes(已毕业)—— Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置,可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排,而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层,将容器分组运行在Pod中,从而实现容器的编排。Kubernetes可以帮助运维人员进行工作负载排期,并允许容器在多云环境中大规模部署。Kubernetes在毕业后被广泛应用,CNCF最新的调查显示,超过40%的企业受访者在生产过程中使用了Kubernetes。
##应用程序开发
4.png

Helm

Helm(孵化阶段)——Helm是程序包管理器,以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)。KubeApps Hub能够列出由Kubernetes社区维护的稳定库和孵化库中的全部chart。通过Helm,用户可以安装Kubernetes之上的所有CNCF项目。并且还可以让企业在Kubernetes上创建和部署自定义的应用程序或微服务。当然,这会涉及到创建YAML清单,根据不同的环境或CI/CD流程匹配不同的部署参数等情况。Helm所创建的单个chart,可以基于应用程序或配置更改来进行版本控制,可以部署在各种环境中,还可以进行跨组织共享。

Helm项目最开始来源于为Kubernetes用户创建自定义体验的Deis项目。早期的Helm版本只有客户端,但后来Deis与谷歌合作在Helm V2版本中添加了服务端‘tiller’,与Kubernetes 1.2同期发布。这就使得Helm成为在Kubernetes之上部署应用的标准方式。

Helm目前正在2018年年底Helm V3发布进行一系列的更改和更新。对于依靠Helm进行日常CI/CD开发的公司,包括Reddit、Ubisoft和Nike,我建议他们按照新的设计进行优化调整。
5.png

Telepresence

Telepresence(沙箱阶段)——虽然在私有云容器应用开发方面,有包括Docker Compose和Minikube在内的流行工具。但在Kubernetes上开发容器化应用程序仍然非常具有挑战性。因为,目前大多数云原生应用都是资源密集型的,并且涉及多个数据库、服务和依赖项。此外,模拟云依赖关系非常复杂,例如在Docker Compose和Minikube中与消息传递系统和数据库的依赖关系就是一个复杂的事情。这里有一个可参考方案,就是使用完全远程的Kubernetes集群,但是这方案会影响IDE、调试器等本地开发工具的应用,并且会导致开发人员出现等待CI去进行测试更改之类的“内部循环”效应。

由Datawire开发的Telepresence在上述设想方面提供了不错的解决方案。它允许开发人员因开发需要在本地运行单个微服务,同时保持与运行在远端Kubernetes集群上的其余部分应用的连接,我们称之为 “实时代码”。Telepresence在远端Kubernetes集群上部署了包含双向网络代理的Pod。将本地机器连接到网络代理。实现了部署真实的开发/测试环境,而无需冻结用于编码、调试和编辑的本地工具。
##监控
6.png

Prometheus

Prometheus(已毕业)——类同于Kubernetes的历程,Prometheus是第二个加入到CNCF的项目,也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案。灵感来自于谷歌的Borgman监控系统。Prometheus完全是拉取式系统,通过配置决定了什么时候拉取什么数据。而不同于通过agent推送数据的push式监视系统。Prometheus将拉取的指标存储在TSDB中。允许用户使用PromSOL类查询语言抽取数据在Grafana仪表板内进行图形展示。用户还可以使用内置的警报管理器生成警报并以slack和电子邮件的方式发送给各种目标。

Prometheus的成功让它已经成为了云原生监控的事实性标准。通过Prometheus,用户可以监控VM、Kubernetes集群和运行在任何地方的微服务,尤其适应像Kubernetes这样的动态系统。Prometheus的度量指标还可以利用Kubernetes的HPA、VPA和集群自动伸缩等功能来进行自动伸缩决策。也支持对其他的CNCF项目的监控,如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的输出集成了许多其他应用和分布式系统。我建议初学者从Helm Chart开始接触。
7.png

OpenMetrics

OpenMetrics (沙箱阶段)——OpenMetrics为应用程序的外部指标格式设定了中性的标准。这个标准让用户可以在更大范围的系统间传输指标数据。OpenMetrics其实是基于Prometheus的指标格式,而后者又是采用Borgmon的运营经验,Borgmon实现了“白盒监控”和低开销的海量数据收集,有着超过300家的服务输出商。在OpenMetrics之前,监控环境主要都是基于像SNMP之类,相对过时的标准和技术,使用专用指标格式,也很少有人关注指标格式规范,存在不少系统差异性的问题。而OpenMetrics出现后,在Prometheus的指标格式之上,定义了更紧凑、更清晰和更严格的语法。很好的改善了系统间指标差异这方面的问题。

虽然OpenMetrics仍在沙箱阶段,但它已经被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生产环境。
8.png

Cortex

Cortex (沙箱阶段)——Prometheus的首要设计目标就是操作简单。因此,它只运行在单节点或单容器内,所使用的存储也是不具备持久或长期存储能力的本地存储。避免采用操作复杂性更高的集群和分布式存储的目的也是为了符合Prometheus的简单原则。Cortex却是具备水平可扩展、支持多租户、采用长效存储设备的辅助解决方案。这对于Prometheus而言,我们认为是不错的补充。它让大型企业在使用Prometheus时,可以具备高可用性,可以访问长效存储设备。虽然在这个领域,目前还有其他一些例如Thanos、Timbala和M3DB的项目也获得社区的关注。但是,Cortex已经在GrafanaLabs和Weaveworks作为SaaS产品进行了battle测试,而且EA和StorageOS也在prem平台上部署了它。
##日志和跟踪
9.png

Fluentd

Fluentd(孵化阶段)——Fluentd采用统一的方法,对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。这统一的方法就是将日志数据定义成JSON格式,实现跨多个源和目的地进行日志的收集、过滤、缓冲和输出。Fluentd的优势之一是可以收集VM和传统应用的日志,但它真正的优势还是在云原生环境Kubernetes之上,作用于那些动态运行的微服务。

Fluentd以daemonset的方式,运行在Kubernetes上每个Pod节点内。它不仅收集容器内所有应用程序的日志(包括CNCF ones),还将日志发送到STDOUT。Fluentd具有逐条解析和缓冲日志记录的能力,并将格式化的日志发送到所配置的目的地,如Elasticsearch、Hadoop和Mongo,让用户可以进行后续处理。

Fluentd最初是用Ruby编写的,虽然功能比较完整,但运行时需要50Mb以上的内存,这对于配对容器部署运行显然不太合适。于是,与Fluentd同时开发的Fluentbit变成了一个替代解决方案。Fluentbit是用C写的,在运行时只需要几Kb的内存,CPU和内存上效率更高,但功能比Fluentd要简单很多,存在比较多的限制。

Fluentd最初是Treasuredata的一个开源开发项目,只是Kubernetes的一个日志插件。较早的可部署版本是0.12,版本比较老、但非常稳定,已被广泛部署在各种生产环境中。近期开发完成的1.X新版本包含了很多改进,例如增加新的API、纳秒级响应和支持Windows环境等。Fluentd正在慢慢成为云原生环境中日志收集的标配, 很大可能成为下一个CNCF毕业项目。
10.png

OpenTracing

OpenTracing(孵化阶段)——开发人员需要能够查看到每条事务并懂得微服务的行为,这使用分布式跟踪对于大规模构建微服务的重要性不能被低估,然而,分布式跟踪非常具有挑战性,需要跟踪工具必须通过已有的服务、包和特定的应用程序代码在流程内和流程之间传播跟踪的上下文。OpenTracing允许应用程序代码、OSS包和OSS服务开发人员无需限定具体供应商的情况下测试自己的代码。 它为应用程序和OSS包提供了一个分布式跟踪标准,这些程序包具有独立的API和9种语言的可用库。专注于分布式跟踪使得OpenTracing非常适合服务集群和分布式系统。但OpenTracing本身并不是一个在UI中运行跟踪来分析spans的跟踪系统。它只是一个与应用业务逻辑、框架和现有工具一起工作的API,可用于创建、传播和标记spans。它创建存储在后端或UI格式的跟踪。目前,OpenTracing集成了开源(如Jaeger,Zipkin)和商业跟踪解决方案(如Instana,Datadog)。
11.png

Jaeger

Jaeger(孵化阶段)——Jaeger是一个开源的分布式跟踪系统解决方案,它与OpenTracing兼容,最初是由Uber开发和测试的。它的名字的发音是yā′gər,即猎人的意思。灵感来自于谷歌的内部跟踪系统Dapper和Zipkin。Zipkin是由Twitter编写,采用了OpenTracing标准(但限制了集成支持能力)构建的开源跟踪系统。Jaeger通过HTTP接受Zipkin格式的spans,并具有Zipkin的向后兼容性。Jaeger的用例监视和基于微服务的故障排除功能,提供了分布式上下文传播、分布式事务监视、根本原因分析、服务依赖关系分析以及性能和延迟优化能力。Jaeger的数据模型和工具包库与OpenTracing兼容。它的Web UI是采用React/Javascript构建的,可以对Cassandra、Elasticsearch和memory等后端提供多种支持。同时,Jaeger集成了包括Istio和Linkerd在内的服务组件,使得跟踪更加容易实现。 

Jaeger默认会暴露Prometheus的指标,并与Fluentd集成来进行日志传输,这让它具有很好可观察性。可以通过Helm chart或最近开发的Jaeger Operator部署到Kubernetes之上。Uber和RedHat为Jaeger代码库提供了大部分的贡献。但还有数百家公司为Jaeger用于云环境和基于微服务的分布式跟踪在进行调优。
##容器注册
12.png

Harbor

Harbor(沙箱阶段)——Harbor最初是由VMWare作为开源解决方案开发的,是一个开源可信任的容器注册器,用于存储、标记和扫描Docker镜像,提供了免费的、增强的Docker注册特性和功能。它提供的Web接口具有基于角色访问控制(RBAC)和LDAP验证支持的安全特性。它集成了由CoreOS开发的用于漏洞扫描的开源项目Clair和用于内容信任的Notary(一个CNCF孵化项目,稍后介绍)。Harbor提供活动审计、Helm chart管理和Harbor实例间的镜像复制(高可用和灾难恢复用途)功能。现在已经被许多公司所使用,包括TrendMicro、Rancher、Pivotal和AXA。
##存储和数据库
13.png

Rook

Rook(孵化阶段)——Rook是Kubernetes的开源存储编排器。它帮助OPS人员在Kubernetes之上运行Ceph等软件分布式系统(SDS)。开发人员可以使用存储动态创建Kubernetes中的持久卷(PV)来部署Jenkins、WordPress等存在状态请求的应用程序。

Ceph是一种流行的开源SDS,它运行在常规的硬件上,对外提供对象存储,块存储和文件系统等多种主流的的存储服务类型。用户可以将Ceph集群直接部署在硬件上,然后使用CSI插件将其连接到Kubernetes。但这样做无疑会增加OPS人员的部署和操作Ceph集群的难度,增加工作挑战性,降低对Ceph集群的欢迎度。而Rook使用自定义资源定义(CRDs)方式将Ceph作为第一个类对象部署到Kubernetes中,并使用操作框架将其变成自管理、自伸缩和自修复的存储服务。这一点恰恰对应了Kubernetes运行的理念,即将人的操作知识编码到软件中,从而可实现简易打包和与终端用户的共享。

与Helm专注于打包和部署Kubernetes应用程序相比,Rook Operator可以部署和管理复杂的SDS应用程序生命周期。以Ceph为例,Rook操作人员可以自动化存储管理员的工作,例如部署、引导、配置、性能指定、水平伸缩、修复、升级、备份、灾难恢复和监视等。

最初的Rook Operator只支持Ceph,在0.8版本时,对Ceph的支持达到Beta版,随后发布了用于存储厂商的Rook框架,这个框架将Rook扩展成为一个通用的云原生存储编配器。具有支持可重用规范、逻辑、策略和测试的多个存储解决方案。目前Rook在alpha中支持CockroachDB、Minio、NFS,后续将支持Cassandra、Nexenta和Alluxio。在生产中使用Ceph的Rook Operator的公司越来越多,尤其是在Prem平台上,包括CENGN、Gini、RPR都有部署,还有许多公司正在评估阶段。
14.png

Vitess

Vitess (孵化阶段)——Vitess是一个数据库的中间件。 它使用通用分片技术在MySQL实例之间分发数据。它可以实现水平伸缩,在不影响应用的情况下,进行水平的无限扩展。 当用户的分片达到满负荷时,Vitess能以零停机时间和良好可观察性,重新对底层数据库进行分片扩展。Vitess还解决了许多与事务性数据相关的问题,项目成长趋势良好。
15.png

TiKV

TiKV(沙箱阶段)——TiKV是一个事务性键值数据库,它具备简化调度和自动平衡的能力。它充当了分布式存储层,提供数据强一致性、分布式事务管理和水平伸缩性的功能。TiKV的设计灵感来自于谷歌Spanner和HBase,但是它的优点是没有分布式文件系统。TiKV由PingCAP开发,目前还有有来自三星、腾讯云和UCloud的贡献者。
##容器运行时
16.png

RKT

RKT(孵化阶段)——RKT(读作Rocket)最初是由CoreOS开发的一个应用程序容器,属于Docker的备选项目。当时,Docker成为Kubernetes的默认容器,但遭遇到来自kubelet的压力,Kubernetes和Docker社区在相互协作方面存在着分歧。开发Docker的公司Docker Inc.有自己的产品路线图,并且正在给Docker添加一些复杂的功能。例如,为Docker添加集群模式,以及将文件系统从AUFS更改为overlay2。但做这些工作时,并没有向外发布信息,导致这些更改影响到了Kubernetes社区和Kubernetes路线图规划和发布日期。况且,Kubernetes用户需要用到的只是一个简单的容器,具备启停容器,并具备伸缩、升级等功能即可。因此,CoreOS就打算将RKT开发成Docker的替代品,专门为Kubernetes而构建。但令人意外的是,这举措却激发了Kubernetes的SIG-Node团队为Kubernetes开发了一个容器接口(CRI),这个接口可以连接任何类型的容器,并从其核心代码中把Docker的代码也被删除了。RKT可以同时使用OCI和Docker格式的镜像。虽然RKT对Kubernetes生态系统产生了积极的影响,但却没有被最终用户所接受,特别是那些习惯了Docker CLI并且不想学习其他应用程序打包方法的开发人员。此外,由于Kubernetes的流行,有许多容器解决方案都在争夺这一细分市场,例如Gvisor和基于OCI的cri-o都越来越流行,而RKT有点风景不再的感觉,可能会成为CNCF孵化器中被移除的项目。
17.png

Containerd

Containerd(孵化阶段)——Containerd是一个强调简单性、健壮性和可移植性的容器。与RKT一样,支持OCI和Docker镜像格式,但不同的是,Containerd设计的目的是嵌入到较大型的系统中,而不是提供给开发人员或最终用户直接使用。Containerd也是Docker捐赠给CNCF的项目。早期的Docker是一个高度集成的应用,但随着时间的推移,集群模式等功能的加入,使其成为一个复杂且难以管理的应用。而且对于要求简单容器功能的Kubernetes用户而言,Docker的复杂功能反而有些多余。因此,Kubernetes开始寻找包括RKT在内的替代方案,来替代默认的Docker容器。这时,Docker项目决定将自己拆分为松耦合的组件,采用更模块化的体系结构。这也就是Moby项目,其中Containerd就是这个项目的核心功能。拆分出来的Containerd通过CRI接口集成到Kubernetes,并改名为ri- Containerd。但从Kubernetes 1.10开始,默认采用Containerd通过内置的CRI插件实现集成,省却了额外的grpc跳转。

随着基于OCI的cri-o和Gvisor这样的项目越来越受欢迎,Containerd慢慢也不被社区所关注。不过它还是Docker平台不可或缺的一部分,在Kubernetes生态系统中还保有一定的位置。
##服务发现
18.png

CoreDNS

CoreDNS(孵化阶段)——CoreDNS是云原生部署中提供服务发现的DNS服务器。Kubernetes自1.12版起,将CoreDNS作为默认的集群DNS服务器,而在更早以前,SkyDNS是Kubernetes集群的DNS组件,它本身就是由Caddy和后来的KubeDNS组成的一个分支。SkyDNS是基于DNS的动态服务发现的解决方案,但体系结构不够灵活,很难添加新功能或进行扩展。于是Kubernetes转而采用KubeDNS。但KubeDNS在运行时,分3个容器(Kube-dns,Dnsmasq和Sidecar)运行,容易出现Dnsmasq漏洞,在新功能扩展上也存在类似SkyDNS的问题。而恰好这时,CoreDNS用Go语言进行了全面重写,成为了基于插件的灵活可扩展的DNS解决方案,而且在Kubernetes上,运行时只需启动一个容器,也没有漏洞方面的问题,提供的ConfigMap工具可动态更新配置。此外,CoreDNS通过严格的设计(如验证Pod记录)修复了许多KubeDNS上存在的问题。基于插件的架构使用户可以插件的方式随时添加或删除功能。目前,CoreDNS已包括30多个自有插件和20个以上的外部插件。通过链接插件,用户可以启用Prometheus监控、Jaeger日志跟踪、Fluentd日志记录、Kubernetes API或etcd配置以及其他的高级DNS特性和集成功能。
##Service Meshes
19.png

Linkerd

Linkerd(孵化阶段)——Linkerd是一个用于服务网格部署的开源网络代理服务。服务网格是一个单独的层,用于管理、控制和监视应用程序中的服务到服务之间的通信。Linkerd在无需应用代码变更的情况下,通过可编程的回路制动、速率限制、超时和重试配置来提高应用程序的容错性,帮助开发人员大规模地运行微服务。通过Zipkin提供了对微服务的可视化。以及提供了先进的交通控制设备来支持Canaries、Staging和Blue-green部署。SecOps团队受益于Linkerd的功能,在Kubernetes集群中通过TLS透明地加密了所有跨节点通信。Linkerd是在Twitter的Finagle项目之上开发出来的,项目具有广泛的生产用途,并吸引了许多探索服务网络的公司的兴趣。目前,Linkerd可以与Kubernetes、DC/OS和AWS/ECS一起使用。以DaemonSet的形式部署在Kubernetes上,这也意味着集群中的每个节点都运行了一个Linkerd Pod。

服务网格生态系统最近有新的变化,例如与Kubernetes紧密集成的Istio项目的引入,与微服务一起运行的轻量级代理Envoy的出现等。这些服务网格组件提供了比Linkerd更多的功能,这大大降低了Linkerd的受欢迎程度,甚至出现了质疑Linkerd存在价值的声音。为了重新获得社区的兴趣并支持现有的大量客户,Linkerd所属的公司Buoyant宣布了一个名为Conduit的项目,该项目允许DaemonSets使用Istio作为Sidecar代理,重写了dataplane,用Go语言重写了控制平面。这些改变使许多可能的特性都可以使用Sidecar方式。不久前,Conduit项目被重新命名为Linkerd 2.0,并发布了GA,这表明Linkerd已经准备应用于生产环境。服务网络还在飞速发展,像Istio和Linkerd 2这样的项目将是这方面的核心。
##服务代理
20.png

Envoy

Envoy(孵化阶段)——Envoy是一个为云原生应用设计的边缘节点和服务代理。它是由C++编写的CNCF孵化项目,是具备厂商无关性、高性能、轻量级的应用代理服务,已在Lyft上开发和进行了battle测试。Envoy可在不改变现有应用程序代码行的情况下,为微服务提供针对超时、安全、重试、回路制动在内的容错能力。通过与Prometheus、Fluentd、Jaeger和Kiali的集成,它提供了对微服务之间事件的自动可见性。Envoy还具备执行流量路由和流量分发能力,负载均衡failovers的域感知能力,因此还可以充当一个边缘代理(如Kubernetes L7 Ingress控制器)的角色。

虽然服务代理领域已经有很多可选的项目,但Envoy激发了许多关于服务网格和现代负载平衡的兴趣点和革命性想法,对现有生态起到很好的补充。涉及Envoy部署的有Heptio公布的Contour项目,这个项目是部署Envoy代理作为反向代理和负载平衡器来充当Kubernetes的入口控制器。Contour支持动态配置更新和多团队Kubernetes集群,能够限制可能配置虚拟主机和TLS凭证的命名空间,并提供高级负载平衡策略。另一个以Envoy为核心的项目是datawire Ambassador,这是一个强大的Kubernetes原生API网关。由于Envoy是用C++编写的,非常轻量级,非常适合在Kubernetes内部以Sidecar模式运行,也非常适合与API驱动的配置更新的风格相协同,成为dataplanes服务网格的理想候选方案。另外,服务网格 Istio宣布Envoy是其dataplane的默认服务代理,Envoy代理以Sidecar模式部署在Kubernetes中的每个实例上。创建一个由Istio的控制面板配置管理的透明的服务网格。这种方法与Linkerd v1中使用DaemonSet模式完全不同,后者提供了每个服务的可见性,并提供在Kubernetes甚至混合云场景中为每个服务创建安全TLS的能力。最近,Hashicorp宣布其开源项目Consul Connect也将使用Envoy在微服务之间建立TLS连接。

现在,Envoy在背后没有任何供应商或商业项目的驱动下,创立了一个庞大而活跃的开源社区。如果您想尝试Envoy,也建议试用一下Istio、Ambassador或Contour, 2018年12月10日在西雅图,Kubecon的Envoy社区成功地主办了第1届EnvoyCon,欢迎大家加入到社区。
##安全
21.png

Falco

Falco(沙箱阶段)——Falco是Sysdig开发的开源实时安全工具,设计用来检测在Kubernetes编排系统中的异常活动和入侵行为。它驻留在用户空间中,使用Sysdig内核模块检索系统调用活动。Falco与SecComp或AppArmor之类的执行工具相比,它具备更多的审计功能。

Falco用一组预配置的规则,定义了需要注意的行为和事件。然后以DaemonSet方法运行在Kubernetes中,基于这些规则,Falco可以检测到任何调用Linux系统的行为,并为这些行为添加警报。类似的行为可能来自于在容器内的shell运行脚步,或建立出站网络连接的二进制文件。这些事件可以通过Fluentd在STDERR上捕获,然后发送到ElasticSearch进行过滤或解除告警。从而可以帮助用户迅速应对如容器破坏或损毁的安全事故,减少此类事件造成的经济损失。

随着Falco被纳入CNCF的沙箱阶段,我们希望它以后与更多的其他CNCF项目深度集成,例如在Falco内集成官方的Helm Chart。
22.png

Spiffe

Spiffe(沙箱阶段)——在应用负载之间建立互信是一个复杂的问题,且随着负载的弹性伸缩和动态调度,这个问题变得更为困难甚至危险。但Spiffe是解决这个问题的云原生方案。Spiffe提供了一个策略驱动、API驱动且完全自动化的安全产品标识框架。它通过验证身份来开启应用负载之间的通信。Spiff现在还相对较新,主要是设计用于与Spire紧密配合的项目。
23.png

Spire

Spire(沙箱阶段)——Spire是Spiffe的运行环境,是一系列可集成到云提供商和中间件层的软件组件。Spire采用模块化架构,支持多种平台。目前,围绕Spiffe和Spire的社区发展非常迅速。HashiCorp刚刚宣布在Vault中支持Spiffe ID,使得它可用于关键信息和常态轮换。Spiffe和Spire现在都处于CNCF的沙箱阶段。
24.png

Tuf

Tuf(孵化阶段)——Tuf是“The Update Framework”的缩写。它是一个用于可信内容分发的框架。内容信任问题是一个重要的安全问题。Tuf通过验证软件的出处,并确认只使用软件的最新版本,来提供内容信任,改善这个问题。TUF项目在下面将提到的Notary项目中扮演许多非常重要的角色。也被许多公司用于生产环境构建内部工具和产品,这些公司包括Docker、DigitalOcean、Flynn、Cloudflare和VMware。
25.png

Notary

Notary(孵化阶段)—— Notary是一种安全的软件分发实现。本质上,是基于TUF,确保所有提取的Docker镜像都是具有签名、正确和未篡改的镜像版本。 Notary可以贯穿于CI/CD工作流的所有阶段,解决Kubernetes中基于Docker部署的一个主要安全问题。Notary发布和管理受信内容的集合。它允许DevOps工程师批准已发布的可信数据并创建签名集合。这类似于Linux系统中软件库的管理工具,但只是用于Docker镜像管理。Notary的主要目标包括保证镜像版本的更新情况(始终有最新的内容,以避免漏洞),和对象之间的信用委托。例如用户之间,不可信镜像和传输通道的可信分发等。虽然Tuf和Notary通常不被终端用户直接使用,但它们的解决方案集成到各种商业产品或开源项目中,用于可信分发的内容签名或图像签名,这些产品包括Harbor、Docker Enterprise Registry、Quay Enterprise、Aqua。在这个领域还有另一个有趣的开源项目Grafeas,它是一个开源的元数据API。所存储“attestations”或图像签名可以作为部分授权控制的校验,也可用于容器分析API和GCP的二进制授权。和JFrog,AquaSec的同类功能类似。
26.png

OPA

Open Policy Agent(沙箱阶段)——Open Policy Agent(OPA)采用强制声明方式来指定策略,允许在一个技术堆栈中分发不同类型的策略,并自动更新,而无需重新编译或重新部署。在应用和平台层,OPA以从服务发送查询的方式通知策略决策。它与Docker、Kubernetes、Istio等应用都有不错的集成效果。
##数据流和消息流
27.png

NATS

NATS(孵化阶段)——NATS是一个聚焦中间件的消息传递服务,允许基础设施在分布式系统之间发送和接收消息。它的集群和自动修复技术具备高可用性,并且它基于日志的数据流保证了有历史数据引用消息的送达和所有信息的接收。NATS有一个相对简单的API,支持多种技术用例,包括云中常规消息传递、微服务传输、控制平面和服务发现等消息传递,以及物联网消息传递。与前文所列的日志记录、监视和跟踪解决方案所不同的是,NATS工作在应用层。
28.png

gRPC

gRPC(孵化阶段)——gRPC是一个高性能RPC框架,提供在多个平台上,库、客户端和服务器之间进行通信的能力。可以在任何环境中运行,并为Envoy和Nginx等代理提供支持。gRPC为负载平衡、跟踪、健康检查和身份验证提供可插入的支持,来实现有效地连接服务。将设备、应用程序和浏览器与后端服务连接起来。gRPC是促进消息传递的应用层工具。
29.png

CloudEvents

CloudEvents(沙箱阶段)——CloudEvents为开发人员提供了一种通用的方式来描述跨多云环境下发生的事件。通过提供描述事件数据的规范,CloudEvents简化了跨服务和平台的事件声明和传递。项目仍处于沙箱阶段,还需要极大地提高应用程序的可移植性和效率。
# 后续展望
云原生生态正在不断地飞速增长。在不久的将来,还将有更多的项目被纳入到沙箱阶段,让它们有机会获得社区的兴趣和认识。我们希望像Vitess,NATs,Rook之类与基础设施相关的项目能不断得到CNCF的关注和支持。因为他们是云原生部署的重要推动者。同时,在云原生持续交付的领域还相对空白,我们希望CNCF能够继续关注。

尽管CNCF在不断纳入新项目,让成熟的项目毕业。但同样重要的还需要有一种工作机制,将那些因失去社区关注,价值性不高或被其他项目取代的项目从CNCF孵化器中移除。虽然项目提交过程对任何人都是开放的,但我希望TOC委员会继续只资助最优秀的候选者,使CNCF成为项目间协同良好,多样化的生态系统。

作为CNCF的大使,我希望教会人们如何使用这些技术。在CloudOps,我带领了Docker和Kubernetes的研讨会,推广云原生技术,并帮助DevOps团队实践他们的应用。我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。我也鼓励大家加入CloudNativeCon。通过邮件联系@archyufa或CloudOps,了解更多关于云原生技术的信息。

原文链接:The Beginner’s Guide to the Cloud Native Landscape(翻译:易理林)

Cloud Native相关的应用增长超过了200%

Zangying2005 发表了文章 • 0 个评论 • 1306 次浏览 • 2018-09-11 10:35 • 来自相关话题

每两年进行一次的CNCF调查洞悉了IT社区对云原生技术应用的认知变化。这已经是CNCF第六次关注调查容器化管理市场的热度。 #关键卖点 1. 自2017年12月以来,CNCF项目在生产环境应用平均增长超过200%,所评 ...查看全部
每两年进行一次的CNCF调查洞悉了IT社区对云原生技术应用的认知变化。这已经是CNCF第六次关注调查容器化管理市场的热度。
#关键卖点

1. 自2017年12月以来,CNCF项目在生产环境应用平均增长超过200%,所评估的项目数甚至达到了372%的增长。
2. 自2017年12月以来,受访者中的大部分都使用了类似AWS Lambda(70%) 的平台服务。这使得无服务器技术的应用不断增长,增幅达到22%。
3. 云原生技术的3大优势为更快速的部署时间,改善弹性和云可移植性。
4. 5000员工以上规模的企业受访者中,40%的企业在生产环境中部署了Kubernetes。

#调查方法和受访者情况
这是迄今为止收到过最多的调查回复,共有2400人有效参与了调查,受访者主要来自北美(40%)和欧洲(36%)。均为研发人员或IT相关的角色,分布情况如下:

1. 研发人员:49%
2. 运维人员:36%
3. IT经理:11%
4. 研发经理:14%

大多数受访者都是来自于员工规模超5000人的公司,这使得本次调查的结果更偏向于在企业中CNCF技术项目的使用。参与者排名靠前的行业是科技(22%)、软件(22%)、金融服务(9%)和电信(8%)。

本项调查是用英文进行的,中文版的调查目前还正在进行,结果将于今年晚些时候公布。你可以通过下图了解调查人群的详细统计信息:
1.jpg

#应用开发环境的变化
在本次最新版的调查问卷中,我们额外添加了发布方面的问题,以便更深入地了解公司如何管理他们的软件开发周期。微服务架构的好处之一是灵活部署的能力,从而允许公司根据需要尽可能频繁的进行应用发布。在微服务之前,典型的发布管理中,应用发布频率要低得多,通常是一年一两次左右。本次调查中,这一点变化突出,除发布频率外,受访者发布周期的各种发布占比相当均匀:

1. 每周发布:20%
2. 每月发布:18%
3. 每天发布:15%
4. 临时发布:14%

应用发布频率:
2.jpg

上述的大多数应用发布都是采用自动化处理(42%),使用混合方法发布的受访者占25%,还有27%的受访者使用手动发布。随着自动化发布的增长,管理CI/CD通道的工具也越来越流行,其中Jenkins是标杆性的工具(70%),其次是Terraform(27%)和定制脚本(26%)。

应用发布方式:
3.jpg

此外,在代码检查频率方面,67%的受访者每天多次检查,每周检查几次为28%,每月检查几次的为6%。

至于服务器数量规模(包括VMs,裸机器等),相较于在2017年12月的那次调查数据,我们看到5000+以上规模的受访者有小幅增长, 由14%上升到17%;6-20台机器的受访者,从18%下降到16%;21-50台机器的受访者的占14%,51-100台机器的受访者占11%。

平均服务器数量分布:
4.jpg

#云的应用情况
企业用云的数据分布情况是:自建数据中心占比64%,私有云占比50%,还有77%的企业采用了公有云的方案。

所采用的数据中心类型:
5.jpg

在采用容器化服务方面,大多数受访者公司都部署在AWS平台上(69%降至63%)。紧随其后的依次是本地数据中心部署(从51%降至43%)、谷歌云平台(39%降至35%)、微软Azure(从16%升至29%)、VMware(24%)和OpenStack(从22%降至20%)。括号内数据为相较于上次调查的数据。

容器化服务所部署的环境:
6.jpg

上述数字表现延续了我们在去年看到的趋势,但存在两个显著变化。首先是自有数据中心部署容器较2017年12月的51%下降到了43%,这很可能是由于私有云的使用增加所导致的。其次,这是我们第一次在这些调查结果中看到在VMware上广泛部署容器服务,在2017年12月的调查中,部署于VMware平台的仅仅为1.2%而已。
#容器化服务数量的增长情况
73%的受访者在生产环境采用容器化服务,剩余的27%表示计划在以后采用这项技术。这个数据在17年12月的调查分别是75%和25%。当前在POC环境采用容器化的受访者有89%,而用于测试环境和开发环境的分别是85%和86%。

容器所用于的环境类型:
7.jpg

公司所运行的容器数量也同比基本保持稳定,运行容器少于50个的占29%,50 -249个的为27%,250-999个的为17%,运行的容器数量超过5000个的为15%。和上次的数据对比,使用容器数不到50的公司增长明显,从2017年12月的23%上升到29%,而容器数在250-999的公司数量略有减少,从22%下降到17%。

企业所运行的容器数量分布:
8.jpg

在容器管理工具方面,Kubernetes以83%的受访者采用稳居第一。其次是Amazon ECS 占24%,Docker Swarm占 21%,Shell Scripts占20%。2017年12月同类型数据分别是77%,18%,17%和12%,存在明显的增长趋势。

容器的管理工具类型分布:
9.png

#Kubernetes
58%的受访者在生产环境中采用了Kubernetes。同时,42%的受访者正在为以后应用进行评估。而在人员规模5000以上的企业中,有40%的受访者在生产环境中使用了Kubernetes。

在生产环境中,40%的受访者运行了2-5个Kubernetes集群,运行1个集群的有22%,6-10个集群的有14%,运行集群数超过50个的受访者公司为13%(2017.12数据为9%)。

在Kubernetes所运行的平台环境方面,51%的受访者运行在AWS(上期数据为57%),企业自有数据中心服务器有37%(上期数据为51%),谷歌云平台从上期的39%下降到了32%,微软Azure从23%降至20%,OpenStack从22%降至16%,然而,运行在VMware平台上的却从1%大幅升至15%。以下图标展现了受访者的Kubernetes所部署的平台和容器所部署平台的对比。

Kubernetes环境 vs 容器环境:
10.jpg

当采用本地部署时,大多数受访者都趋向于选择的环境和所选比例为:Minikube(45%),Docker Kubernetes(39%),on prem Kubernetes installations(30%)。

此外,我们还问询了受访者在管理应用程序的各个方面所采用的工具:
##打包工具
首选的打包工具是Helm,占比68%,其次是Kubernetes内置的打包功能。
##自动伸缩技术应用
自动伸缩的应用情况,64%的受访者采用了自动伸缩无状态应用,其次是Java应用(45%),然后是任务/队列处理应用(37%)。未采用自动伸缩技术的受访者,可能是还没有这个功能的应用意识或者不希望在目前对自有的工作负载采用自动伸缩技术。
##入口提供方
Kubernetes的入口提供方应用最多几位依次是:Nginx占比64%(上期数据57%),HAProxy占29%,F5占15%(上期数据11%)和Envoy占比15%(上期数据9%)。
##向集群外暴露服务
受访者向集群外(如internet或其他虚拟机)暴露服务的首要方式是通过负载均衡器(67%)。其次是L7 ingress(39%)和集成第三方负载均衡器提供33%。
##Kubernetes内组织团队间隔离
在Kubernetes内部,受访者进行多个团队间的隔离,使用最多的技术是命名空间(Namespaces)占比71%,其次是独立的集群(51%),仅仅采用标签的为(15%)。
##隔离Kubernetes内的应用
受访者进行Kubernetes应用隔离采用命名空间(Namespaces)占比78%,其次是独立的集群(50%),仅仅采用标签的为(21%)。
#生产环境中的云原生项目
云原生项目有哪些优势呢?受访者提及最多的3个理由是:

1. 更快速的部署时间
2. 改善弹性
3. 云可移植性

用于生产环境和评估中的CNCF云原生项目分布情况:
11.jpg

数据显示,许多CNCF项目在生产环境中的使用较我们上一次的调查有显著的提升。例如容器服务由18%升至45%;CoreDNS由7%升至36%;Envoy由4%升至24%;Fluentd由38%升至57%; gRPC由18%升至45%;Jaeger由5%升至25%,Linkerd由3%升至16%,以及OpenTracing由8%升至21%。就平均值看,CNCF项目在生产环境的应用较上一次调查有200%以上的提升。

受访者正在评估中的CNCF项目数同样较上期调查增长明显。例如容器服务由22%升至55%;CoreDNS由14%升至64%;Envoy由26%升至74%;Fluentd由22%升至43%; gRPC由16%升至55%;Jaeger由15%升至75%,Linkerd由15%升至84%,以及OpenTracing由25%升至80%。就平均值看,CNCF项目评估较上一次调查增长了372%。

CNCF新开发的项目也有很高的关注度,受访者重点评估的项目如SPIRE(94%)、TUF(93%)、Open Policy Agent(92%)、Vitess(92%)和SPIFEE(92%)等,关注比值都非常高。
#使用和部署容器的挑战
云原生技术改变了企业设计,构建应用的方式,挑战也是无法避免的。受访者反馈所面临的挑战主要有:

1. 研发团队的文化转变:41%
2. 复杂度:由35%提高到40%
3. 培训不足:40%
4. 安全性:由43%降到38%
5. 监控:由38%降到34%
6. 存储:由41%降到30%
7. 网络:由38%降到30%

对于这些挑战,有两个显著的变化。首先,本次调查,虽然这是我们第一次明确询问开发团队的文化变化,但它却被认为是使用和部署容器中的最大挑战。其次,缺乏培训是问卷选项以外的挑战。尽管CNCF在过去的一年里在Kubernetes培训上进行了重度投入,措施包括免费和付费课程,以及为Kubernetes管理员和应用程序开发人员提供认证。因此,随着项目的发展,我们将继续投入更多的培训资源开展新项目。

其余的主要挑战与我们过去的调查基本是一致,但是随着有更多的资源和工具用于解决面临的问题,这些选项的被选比例在持续下降。

使用和部署容器所面临的挑战:
12.jpg

同时,有一个有趣的现象是,随着云原生存储项目应用的增长,存储和网络作为挑战的被选比例呈下降趋势。云原生存储项目的应用情况如下:

1. Rook:生产环境应用的受访者占比11%,正在评估中的受访者占比89%(上期调查29%)。
2. Minio:生产环境应用的受访者占比27%,正在评估中的受访者占比73%(上期调查28%)。
3. OpenSDS:生产环境应用的受访者占比16%,正在评估中的受访者占比84%(上期调查分别为7%和14%)。
4. REX-Ray:生产环境应用的受访者占比18%,正在评估中的受访者占比82%。
5. Openstorage:生产环境应用的受访者占比19%,正在评估中的受访者占比81%(上期调查分别为31%和36%)。

企业所采用的云原生存储项目类型:
13.jpg

#Serverless的增长
在本次调查中,我们仍然持续跟进无服务器技术的增长情况。38%的组织当前在使用无服务器技术(上期同类型数据为31%)。其中32%是采用支持平台,6%是采用安装的软件实现。

与上期数据的41%相比,仍有37%的受访者没有采用无服务器技术,但有另外的26%的受访者表示将在未来的12-18个月内计划采用。

选用最多的可安装的无服务器平台有:

1. Kubeless:42%,上期数据2%
2. Apache OpenWhisk:25%,上期数据12%
3. OpenFaas:20%,上期数据10%

企业组织所采用的无服务器平台分布:
14.jpg

选用最多的公有云无服务器平台是:

1. AWS Lambda服务:70%
2. Google Cloud Functions:25%,上期数据13%
3. Azure Funcitons:20%,上期数据12%

企业组织所采用的公有云无服务器平台分布:
15.jpg

随着无服务器技术的使用增长,受访者对无服务器技术项目CloudEvents表现出了浓厚的兴趣,80%的受访者为我们评估了这个项目,还有21%的人在生产中使用它的技术。CloudEvents是CNCF无服务器工作组所组织的成果,它旨在创建一个以通用的方式描述事件数据的规范。
#如何学习更多的技术知识?
对于刚刚涉足云原生项目并期望学习更多相关知识的初学者,以下是受访者学习云原生技术的首要几种方式:
##文档
20%的受访者使用文档来学习云原生项目,这也是本次调查引用的首要资源。例如,SIG-Docs帮助维护的大量Kubernetes详细文档。这其中包括了从如何开始使用某个特定功能到以贡献者身份参与项目的最佳方式等等的所有内容。每个CNCF项目在其网站上都有大量的文档,可以点击https://www.cncf.io/projects/获取。
##KubeCon + CloudNativeCon
12%的受访者选择参加KubeCon + CloudNativeCon,以了解更多他们正在使用的技术。KubeCon + CloudNativeCon集中了所有CNCF项目,并将来自开源云原生社区的技术大咖聚集一堂,以进一步推动原生云计算的发展。这项活动每年在欧洲、中国和北美各举行一次。
##CNCF网站和在线研讨会
12%的受访者会访问CNCF网站和参加在线研讨会。CNCF.io是所有云原生项目的一个主要来源,提供包括近期活动、培训、认证、博客等等诸多主题的信息。

CNCF在线研讨会每周二上午10点到11点(PT)举行。您可以查看近期日程,并查看往期在线研讨会的录音和幻灯片。
##聚会和当地活动
有11%的受访者会通过参加聚会和当地活动来了解云原生技术。CNCF在我们会员体系下主办了149个聚会,活动遍布33个国家,涉及会员超过76000人。你可以点击这里查看的你所在地的聚会。

您可以点击这里查看近期CNCF和世界各地云原生社区的活动,包括从会议到路演等等。
##推特
10%的受访者通过Twitter获取信息。通过Twitter账号,CNCF发布项目、社区和基金会的新闻。读者可以关注自己所喜欢的云原生项目,点击这里可以找到这些Twitter列表(和相关的社交账户)。

学习云原生技术的途径:
16.jpg

#致谢
非常感谢所有参与我们调查的人。我们希望在上海的KubeCon + CloudNativeCon(2018年11月12-15日)和西雅图(2018年12月11-13日)见到您。

请继续关注我们今年晚些时候公布的中文调查结果!

你亦可在此查阅过往的调查结果:

March 2018: China is Going Native with Cloud
December 2017: Cloud Native Technologies Are Scaling Production Applications
June 2017: Survey Shows Kubernetes Leading as Orchestration Platform
January 2017: Kubernetes moves out of testing and into production
June 2016: Container Survey
March 2016: Container survey results

原文链接:CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%(翻译:易理林)

云原生应用的10大关键属性

cleverlzc 发表了文章 • 0 个评论 • 1256 次浏览 • 2018-08-12 10:12 • 来自相关话题

【编者的话】云原生是一系列基于容器、微服务、DevOps工作流以及弹性基础设施的集合,能够更加高效、可靠和敏捷的交付应用价值,本文的10个关键属性将带领你更深入的理解云原生应用。 云原生是一个用于描述基于容器环境的术语。云原生技术用于 ...查看全部
【编者的话】云原生是一系列基于容器、微服务、DevOps工作流以及弹性基础设施的集合,能够更加高效、可靠和敏捷的交付应用价值,本文的10个关键属性将带领你更深入的理解云原生应用。

云原生是一个用于描述基于容器环境的术语。云原生技术用于开发构建应用程序,这些应用程序使用容器打包并且将被部署为微服务,通过敏捷DevOps流程和持续交付工作流,在弹性基础设施上进行管理。

运维团队将手工管理传统应用程序的基础设施资源分配,而云原生应用程序部署在抽象底层计算、存储和网络原语的基础设施上。处理这种新型应用程序的开发人员和运维人员不会直接与基础设施提供者公开的应用程序编程接口(API)交互。相反,编排引擎根据DevOps团队制定的策略自动处理资源分配。控制器和调度器是编制引擎的重要组件,它们处理资源分配和应用程序的生命周期。

像Kubernetes这样的云原生平台暴露了一个扁平网络,该网络覆盖在云提供商的现有网络拓扑和原语上。类似地,通常抽象本地存储层以暴露与容器集成的逻辑卷。运维人员可以分配开发人员和资源管理员访问的存储配额和网络策略。基础架构的抽象不仅解决了跨云环境的可移植性需求,还让开发人员利用新兴模式来构建和部署应用程序。无论基于物理服务器或虚拟机,私有云还是公共云的底层基础架构,业务流程管理器都将成为部署目标。

Kubernetes是当代运行云原生应用程序的工作负载的理想平台。它已经成为云的事实上的操作系统,就像Linux是底层机器的操作系统一样。只要开发人员遵循设计和开发软件作为一组包含云原生应用程序的微服务的最佳实践,DevOps团队就能够在Kubernetes中打包和部署它们。以下是开发人员在设计云原生应用程序时应牢记的云原生应用程序的10个关键属性。


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

原文地址:10 KEY ATTRIBUTES OF CLOUD-NATIVE APPLICATIONS (翻译:刘志超)

CNCF在PromCon上宣布:Prometheus是继Kubernetes之后的第二个CNCF“毕业”项目

wise2c 发表了文章 • 0 个评论 • 1143 次浏览 • 2018-08-10 15:12 • 来自相关话题

SAN FRANCISCO, Calif., August 9, 2018 - 管理Kubernetes和Prometheus等云原生开源技术的 Cloud Native Computing Foundation(CNCF)在PromCon(年度Prometh ...查看全部
SAN FRANCISCO, Calif., August 9, 2018 - 管理Kubernetes和Prometheus等云原生开源技术的 Cloud Native Computing Foundation(CNCF)在PromCon(年度Prometheus会议)上宣布Prometheus是继Kubernetes之后的第二个CNCF毕业项目。在CNCF管理的项目中,要从’孵化’转为’毕业’的成熟水平,项目必须被社区广泛的采用,有结构完整的治理过程文档,以及对社区可持续性和包容性的坚定承诺。

“自2012年成立以来,Prometheus已成为构建现代云原生应用程序的企业首选的开源监控工具之一,”CNCF首席运营官Chris Aniszczyk表示。 “自从被接受成为CNCF的第二个管理项目以来,Prometheus已经培养了一个活跃的开发者和用户社区,让TOC充满信心地毕业了这个项目。作为其成熟的证明,我们很高兴看到Prometheus社区推出OpenMetrics,它采用Prometheus exposition format,并努力将其演变为事实上的行业规范。“

毕业微信图片_20180810115617.png


Prometheus项目于2012年在SoundCloud创建,并于2016年5月捐赠给CNCF。该项目自进入CNCF的’孵化’水平以来已有包括主要版本和次要版本的30个正式版本发布。

“作为该项目的主要支持者,创始人和最终用户,SoundCloud祝贺Prometheus团队在此项目中的成就,”SoundCloud基础设施和核心工程副总裁Jake Maizel说。 “Prometheus帮助改进了许多公司的监控和警报实践,很高兴看到这个项目在官方毕业后进一步发展。恭喜所有参与者!“

Prometheus现在拥有近20个活跃的维护者,超过1,000个贡献者和超过13,000个来自其不断增长的用户群的commits,其中包括ShuttleCloud,Datawire,DigitalOcean,Weaveworks,ShowMax,iAdvize和Uber等。除此之外,Prometheus还与CNCF的首个托管项目Kubernetes集成,以支持服务发现和动态调度服务的监控。

“自从成为CNCF的一部分以来,Prometheus已经成为现代基础设施堆栈的重要组成部分,并帮助塑造了组织监控关键应用程序的方式,”Prometheus项目联合创始人Julius Volz说。 “我们非常自豪能让Prometheus毕业,我们期待与CNCF合作,以维持和发展我们的社区。”

为了正式从孵化进入状态毕业,该项目还采用了CNCF行为准则,执行了独立的安全审计,并确定了自己的治理结构,以发展社区。此外,Prometheus于2017年6月23日完成并获得核心基础设施倡议的最佳实践徽章。 CII徽章展示了Prometheus项目对代码质量和安全最佳实践的持续承诺。

原文链接:Cloud Native Computing Foundation Announces Prometheus Graduation

Kubernetes会被它厚重的复杂度压垮吗?

wjun 发表了文章 • 0 个评论 • 1822 次浏览 • 2018-06-07 13:37 • 来自相关话题

【编者的话】Paul Dix在Kubernetes如日中天的今天写下了这篇文章。粗看是有点不太合时宜,可能不会在如今喧嚣的Kubernetes风潮中溅起一丝涟漪。但恰恰言简意赅的点出了很多平台和社区方方面面的问题,也给出了建议。作为一个已经在多个云端平台和企业 ...查看全部
【编者的话】Paul Dix在Kubernetes如日中天的今天写下了这篇文章。粗看是有点不太合时宜,可能不会在如今喧嚣的Kubernetes风潮中溅起一丝涟漪。但恰恰言简意赅的点出了很多平台和社区方方面面的问题,也给出了建议。作为一个已经在多个云端平台和企业IDC环境落地Kubernetes的团队,我们感同身受文中提到的阵痛期以及对Kubernetes未来的关切。同样希望社区和平台贡献者能看到这些观点,将Kubernetes变得对开发者更加友好,从而让生态更健康,让开发者能把优势资源更多的集中在去发布商业价值的本份上。

思考:服务好应用开发者的重要性

几周之前,我参加了欧洲区的KubeCon并讲了话。这是一次有将近4700人参加的空前的盛会。这让我想起了2014年那次在巴黎的OpenStack峰会。如出一辙的疯狂宣传,供应商的各种秀,以及在主会场的公共区域举行的由开发者组织的大型派对。然而,我感到了这整个场面之后的隐忧:每个和我聊的人不是运维就是SRE(译者:网站可靠性工程师)。我们的应用开发人员在哪里?他们不应该正是这整个复杂的基础架构要服务的人吗?社区真正将有需求的使用者联系起来了吗?进而它让我疑虑:是不是Kubernetes过于复杂了?它会被它厚重的复杂度终结吗?它会跟OpenStack当初一样在2014年后逐渐消失吗?

好吧, 我承认我演的有点过了, 但我要说的是,在我看来这根本不可能发生。Kubernetes有一些优势是OpenStack从来不具备的。首先,Kubernetes已经更具扩展性,因此,所谓能在千万级服务器规模的环境中调度的集群,它能使其梦想成真。其次,三大云供应商(AWS、Azure、Google Cloud)已经开始提供在其之上托管Kubernetes的各种服务(译者:EKS、AKS、GKE)。在短短四年内,Kubernetes已经将自己的地位提高成为云服务商和传统IT基础架构的通用平台。但是,复杂度问题依然让人头疼不已。
# 大部分开发者没有遇到和Google一样的扩展性问题
开发Kubernetes的初衷是为了解决Google公司在扩展性上面临的复杂度以及各种问题。你可能期望这个基础架构是可自愈的,可以横向扩展的,并能支持申明式编程(即infrastructure as code, 基础设施即代码)。然而,对绝大部分的应用和应用开发者来说并没有这样的世界观。大部分应用要么是在用更加现代和高阶的术语来描述它们所谓的扩展性(比如项目的部署规模和用户量)要么还只是刚开始调研自己的市场定位。

那些完全不会有扩展性问题的应用, 通常不需要系统具备可自愈可横向扩展,来徒增复杂度。只要简单地考虑使用单个节点的数据库服务和应用服务,就能够处理你的业务。而且,如果有人做些常规排错的运维,让它能够保持99.5%的可用性,那就已经满足了很多应用和业务的需求。建一套分布式系统所带来的无谓复杂度,以及在投放市场前所开销的额外时间,都完全不值得去纠结和投入。

对于那些全新的应用,他们最大的风险是在于找不到自己的市场定位。就是说,他们都部署好了但没人用。这些代码最终被丢弃,因为,它做出来了但没人要。这样的情况代表了绝大部分的已经写好的应用。我个人就把职业生涯大量的时间用在了寻找“恰当的代码匹配恰当的功能”。只有当你发现了对的应用场景和功能需求,你才去扩展你的应用。否则就是拔苗助长(译者:出自“premature optimization is the root of all evil”)。

我看到Kubernetes的问题在于,在它上面做一个项目,其初期的认知负荷太高。那堆你需要做和考虑的事阻碍了你快速开始和迭代一个项目。在项目初期,实现需求的效率和迭代速度是非常重要的因素。我看Heroku就有个很好的开发模式。你已经有了个托管的Postgres数据库,你只需要git push把代码部署上去并发布。几乎没什么需要去纠结。它也许不支持无限扩展,也有可能成本比较高,但至少你可以等这些真成了你的痛点之后再去操心。

简而言之, Kubernetes让简单的事变难了,也让难的事变得有可能(出自Tom Wilkie一句用在另个项目上的话)。如果Kubernetes真的要成功,它必须要让项目启动期变得更加简单。它必须要降低应用开发者的认知负荷。如果在某些时候,开发者有需要去学Kubernetes的晦涩概念的细节,那也行。因为项目做大了,每件事都会复杂和有难度。但一个成功的开发平台不会在还没必要的情况下,就把那些决策负担和认知压力放到开发者的面前。这话David Heinemeier Hansson(译者:DHH,Ruby on Rails的作者)在2018年的RailsConf的“JIT Learning" 中讲过

说到DHH, 这里我想用Rails作为例子。首先我想来探讨的是:为什么Rail那时会那么火?不是因为Ruby的流行(它曾是一个来自日本并不为人知的语言),也不是因为Rails和Ruby曾是服务动态web页面的框架中响应速度最快的。而是因为它大幅提高了开发者的工作效率。当DHH谈如何在15分钟内搭建博客网站的时候,那些动辄要用数周甚至数月才能完成相同事情的Java和.NET开发人员都惊讶不已。开发者使用Rails是因为他们能将新功能更快的发布给用户,这才应该是所有这些应用框架和系统架构的根本目的。

Rails做的另一个了不起的事是,它会为你开发的应用程序提供了一个命令行工具并帮你去生成scaffolds和项目需要的其他组成部分。这就让开发人员的事情变得简单,他们没必要在项目一开始就要去做成吨的决策。应用程序的代码该如何组织,数据模型该放哪, asset pipeline是什么样,怎么做数据库迁移,以及其他很多为你而完成的任务和决策。如果你想一试框架限定外的东西,也行的,但你不是非得在一开始就去考虑。

我想Kubernetes也可以从Rails的这些各种各样的生成器中获得灵感。事实上Kubernetes里已经有了特定资源的生成器,但还远远不及我想要的。如果对不同类型的应用能有相应模板就会很好。哪怕只有个最通用的模板也好。把关系数据库,应用层,缓存服务器,消息队列,以及worker节点池组合到一起,就能把其中的复杂度封装, 从而满足90%或更多应用在开发时的需求。如此简单的一个结构能够横向扩展进而支撑一个难以置信的请求数量和复杂度。一个模板或者生成器就能把所有东西变得开箱即用,还帮你把这些适用于Kubernetes上的资源和代码组织的好好的,对开发者而言这将会非常有帮助。

比如,要是有一个通用元素的Scaffold生成器,事情就会变得很棒。要个MySQL数据库?像这样来个命令就行:
kubectl scaffold mysql --generate

原本创建一个stateful set,service以及其他的必须品都要走段很长的路。现在只要一个简单命令就能在Kubernetes环境里部署一个scaffold,并且,你还能只通过几行命令就能有一个可以直接上生产的数据库。如法炮制,各种流行的应用框架,message brokers,以及其他我们能想到的东西都能被创建出来。

也许operators与Helm Chart的组合就能搞定上面说的,但我觉得这不能算完。总不能强迫开发者还要再去学两个Kubernetes外的东西吧。虽说只是多学一些新语法和装个新的命令行工具,那也是额外费心费力的事。这样的功能应该是Kubernetes的“一等公民”,是Kubernetes拥有“开箱即用”般体验的组成部分。他们要能够通过kubectl就可以用起来。
# CNCF项目版图很大而且越来越大
这不是Kubernets特有的问题,而是CNCF项目版图就很巨大。这就使得KubeCon和CNCF的峰会被极度的碎片化。光在峰会的不同场次就有14个宣讲。而作为开发人员,下图这些工具中哪些是我项目需要的呢? 来看看这张项目版图吧:
cloud-native-landscape.png

好吧,看了也没办法搞清楚。更好的方式, 是把预先就挑好的工具提供给应用开发人员,让他们先按照简便方法走,如果他们能想到去用不同的工具,那更好,但是他们不需要一开始就非要去考虑。CNCF正在激增的复杂度和广度有可能会分散人们聚焦在Kubernetes的注意力也会弱化它作为开发平台的定位。对此我也不知道该怎么说,或者讲得夸张点,仅从我个人角度来看,现在这峰会俨然就是部工具为主角的小电影。试问,你都能把整个职业生涯消耗在去学如何为平台开发新的工具上了,还费什么劲去解决用户的问题?

怎么强调都不够:基础架构只是一个帮助开发者解决真实用户问题的工具。它应该能帮助开发者优化效率和提高发布的能力。在这点上能做得好的开放平台就能胜人一筹。
# 所需知识
有时,开发者需要对基础架构的各种工具有更深的了解。像大部分AWS上的开发者对那个云上的组件比较熟悉,就跟GCP或Azure上的开发者熟悉他们云上的组件一样。让Kubernetes作为项目的基础架构也许会更有前景,因为开发者只学这一种范式就能把它和项目铺上任何公有云或者私有云。

这点也许就是我们选择Kubernetes的原因,把它作为我们新开发的2.0版云服务的基础架构。可学习曲线是明摆在那儿的,所以我们开发团队还在热身。为了达到目的,我让整个研发团队必读Kubernetes : Up and Running这本书。

我希望学习曲线是相对温和的, 而Kubernetes作为一个生态,要去拥抱开发者的需求才能真正成功。通过提供面向用户的应用来解决客户问题,在这样一个服务过程中,说到底,基础架构只是一个支持型的工具。“激发应用开发者的效率”是最好的也是最明确能让一个平台被广泛使用和接受的正道。

原文链接:Will Kubernetes Collapse Under the Weight of Its Complexity? (翻译:万俊)

=============================================================
译者介绍
万俊,MicroFocus上海软件研发部经理。

CNCF得意门生结业,Kubernetes全面走向成熟

尼古拉斯 发表了文章 • 0 个评论 • 1357 次浏览 • 2018-03-07 09:55 • 来自相关话题

两年多之前,CNCF(即云原生容器基金会)正式成立,而其技术领导者们则热烈欢迎Kubernetes成为其首个参与项目。自那时以来,该基金会迅速吸引到更多新的贡献者,外加各类组织、云服务供应商以及用户的广泛参与。即使是在“高手林立”的GitHub上,Kubern ...查看全部
两年多之前,CNCF(即云原生容器基金会)正式成立,而其技术领导者们则热烈欢迎Kubernetes成为其首个参与项目。自那时以来,该基金会迅速吸引到更多新的贡献者,外加各类组织、云服务供应商以及用户的广泛参与。即使是在“高手林立”的GitHub上,Kubernetes也在提交量方面排名第九,作者/问题数量更是排名第二——仅次于开源界的至高成果Linux。

优步、彭博、Blackrok、BlaBlaCar、《纽约时报》、Lyft、eBay、Buffer、Ancestry、GolfNow、高盛投资以及其它众多全球性组织都在着手建立大规模生产性Kubernetes。目前,三家规模最大的云服务供应商皆提供自己的托管Kubernetes服务。此外,根据Redmonk公布的数据,全球财富一百强企业当中有71%在使用容器,而超过半数财富百强企业利用Kubernetes作为其容器业务流程平台。

出于上述原因,CNCF技术监督委员会(简称TOC)通过投票表决,最终认定Kubernetes成为该基金会的首个结业项目。获得这一称号将给Kubernetes带来多方面助益。这标志着Kubernetes已经拥有充分的成熟度与弹性水平,足以在任何行业中的各类企业内对容器进行大规模管理。而作为“结业项目”,Kubernetes将处于更为强大的地位,能够更快地发展并始终保持住自己充满活力、健康且多元的技术社区。

多达11258位开发贡献者、GitHub上拥有75000多次提交以及全球Meetup组中的15万8千名成员,反复证明着Kubernetes社区所展现的活力与延伸水平。Kubernetes在30个发展速度最快的开源项目当中排名第三。凭借这样的排名,很多人甚至将Kubernetes定义为开源历史上发展速度最快的项目之一。Redmonk在最近发布的一篇博文当中,也表示Kubernetes是其见过的发展最快的技术方案之一!

在另一方面,Kubernetes项目非常庞大,包含近100套资源库,因此我们不得不自行开发管理审批权限机制。我们拥有数百名审批者,他们在项目中超过4000个OWNERS文件当中有所体现。感兴趣的朋友可以点击此处通过CNCF的Devstats仪表板查看Kubernetes令人印象深刻的提交与贡献合并流程——根据该仪表板所示,Kubernetes项目每月需要处理成千上万次这样的合并。

为了正式从孵化状态中结业,Kubernetes还必须获得(并保持)核心基础设施项目最佳实践徽章(简称CII徽章)。这项目标于2016年8月即告完成,标志着Kubernetes项目对于代码质量与安全最佳实践作出的明确承诺。

另外,为了保持迅猛的发展速度,该项目的治理与社区管理实践也在随着项目自身的发展而不断变化及成熟。Kubernetes还通过了CNCF的行为准则考核,此项考核是为了传递“贡献者人人平等”这一关键性理念。
chop-wood-768x341.png

COO Chris Aniszczyk在奥斯汀召开的KubeCon大会上展示Chop Wood/Carry

从技术角度来看,Kubernetes在2017年先后发布了四个版本。最新的1.9版本包含一个稳定的核心工作负载API、面向Windows服务器容器的beta支持功能(用户可借此在Kubernetes上运行基于Windows与.Net的容器)。另外,通过启用CSI支持,该项目还可充分发挥云原生存储选项的巨大优势。这意味着存储供应商能够更轻松地支持Kubernetes,并为最终用户提供更多存储选项与开放性解决方案。这一最新版本所引发的媒体报道热度也达到新的历史水平;通过社交媒体渠道发布的各类文章共计237篇,转载超过4000次。Kubernetes的1.10版本预计将于今年3月底发布,感兴趣的朋友不妨关注http://blog.kubernetes.io/ 以了解更多发布细节。

Kubernetes,祝贺你!今天是你的好日子。你将踏上更伟大的征程,并迎接更加光明的未来!

原文链接:Kubernetes Is First CNCF Project To Graduate

云原生架构概述

尼古拉斯 发表了文章 • 0 个评论 • 19863 次浏览 • 2017-12-25 20:51 • 来自相关话题

#1. 什么是云原生 ##1.1 CNCF组织 在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。 目前CN ...查看全部
#1. 什么是云原生
##1.1 CNCF组织
在讲云原生之前,我们先了解一下CNCF,即云原生计算基金会,2015年由谷歌牵头成立,基金会成员目前已有一百多企业与机构,包括亚马逊、微软。思科等巨头。

目前CNCF所托管的应用已达14个,下图为其公布的Cloud Native Landscape,给出了云原生生态的参考体系。
2.jpg

Cloud Native Landscape
##1.2 云原生
CNCF给出了云原生应用的三大特征:

* 容器化封装:以容器为基础,提高整体开发水平,形成代码和组件重用,简化云原生应用程序的维护。在容器中运行应用程序和进程,并作为应用程序部署的独立单元,实现高水平资源隔离。
* 动态管理:通过集中式的编排调度系统来动态的管理和调度。
* 面向微服务:明确服务间的依赖,互相解耦。

云原生包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。

这边引用网上关于云原生所需要的能力和特征总结,如下图。
03.jpg

云原生所需要的能力和特征
##1.3 The Twelve Factors
12-Factors经常被直译为12要素,也被称为12原则,12原则由公有云PaaS的先驱Heroku于2012年提出(https://12factor.net/),目的是告诉开发者如何利用云平台提供的便利来开发更具可靠性和扩展性、更加易于维护的云原生应用。具体如下:

* 基准代码
* 显式声明依赖关系
* 在环境中存储配置
* 把后端服务当作附加资源
* 严格分离构建、发布和运行
* 无状态进程
* 通过端口绑定提供服务
* 通过进程模型进行扩展
* 快速启动和优雅终止
* 开发环境与线上环境等价
* 日志作为事件流
* 管理进程

另外还有补充的三点:

* API声明管理
* 认证和授权
* 监控与告警

距离12原则的提出已有五年多,12原则的有些细节可能已经不那么跟得上时代,也有人批评12原则的提出从一开始就有过于依赖Heroku自身特性的倾向。不过不管怎么说,12原则依旧是业界最为系统的云原生应用开发指南。
#2. 容器化封装
最近几年Docker容器化技术很火,经常在各种场合能够听到关于Docker的分享。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。Docker背后的想法是创建软件程序可移植的轻量容器,让其可以在任何安装了Docker的机器上运行,而不用关心底层操作系统。

Docker可以解决虚拟机能够解决的问题,同时也能够解决虚拟机由于资源要求过高而无法解决的问题。其优势包括:

* 隔离应用依赖
* 创建应用镜像并进行复制
* 创建容易分发的即启即用的应用
* 允许实例简单、快速地扩展
* 测试应用并随后销毁它们

自动化运维工具可以降低环境搭建的复杂度,但仍然不能从根本上解决环境的问题。在看似稳定而成熟的场景下,使用Docker的好处越来越多。
#3. 服务编排
笔者看到Jimmy Song对云原生架构中运用服务编排的总结是:

Kubernetes——让容器应用进入大规模工业生产。



这个总结确实很贴切。编排调度的开源组件还有:Kubernetes、Mesos和Docker Swarm。

Kubernetes是目前世界上关注度最高的开源项目,它是一个出色的容器编排系统。Kubernetes出身于互联网行业的巨头Google公司,它借鉴了由上百位工程师花费十多年时间打造Borg系统的理念,通过极其简易的安装,以及灵活的网络层对接方式,提供一站式的服务。
Mesos则更善于构建一个可靠的平台,用以运行多任务关键工作负载,包括Docker容器、遗留应用程序(例如Java)和分布式数据服务(例如Spark、Kafka、Cassandra、Elastic)。Mesos采用两级调度的架构,开发人员可以很方便的结合公司业务场景自定制MesosFramework。



他们为云原生应用提供的强有力的编排和调度能力,它们是云平台上的分布式操作系统。在单机上运行容器,无法发挥它的最大效能,只有形成集群,才能最大程度发挥容器的良好隔离、资源分配与编排管理的优势,而对于容器的编排管理,Swarm、Mesos和Kubernetes的大战已经基本宣告结束,Kubernetes成为了无可争议的赢家。
#4. 微服务架构
传统的Web开发方式,一般被称为单体架构(Monolithic)所有的功能打包在一个WAR包里,基本没有外部依赖(除了容器),部署在一个JEE容器(Tomcat,JBoss,WebLogic)里,包含了DO/DAO,Service,UI等所有逻辑。其架构如下图所示。
4.jpg

传统的单体架构

单体架构进行演化升级之后,过渡到SOA架构,即面向服务架构。近几年微服务架构(Micro-Service Archeticture)是最流行的架构风格,旨在通过将功能模块分解到各个独立的子系统中以实现解耦,它并没有一成不变的规定,而是需要根据业务来做设计。微服务架构是对SOA的传承,是SOA的具体实践方法。微服务架构中,每个微服务模块只是对简单、独立、明确的任务进行处理,通过REST API返回处理结果给外部。在微服务推广实践角度来看,微服务将整个系统进行拆分,拆分成更小的粒度,保持这些服务独立运行,应用容器化技术将微服务独立运行在容器中。过去设计架构时,是在内存中以参数或对象的方式实现粒度细化。微服务使用各个子服务控制模块的思想代替总线。不同的业务要求,服务控制模块至少包含服务的发布、注册、路由、代理功能。

容器化的出现,一定程度上带动了微服务架构。架构演化从单体式应用到分布式,再从分布式架构到云原生架构,微服务在其中有着不可或缺的角色。微服务带给我们很多开发和部署上的灵活性和技术多样性,但是也增加了服务调用的开销、分布式系事务、调试与服务治理方面的难题。
5.png

Spring Cloud整体架构图

从上图Spring Cloud组件的架构可以看出在微服务架构中所必须的组件,包括:服务发现与注册、熔断机制、路由、全局锁、中心配置管理、控制总线、决策竞选、分布式会话和集群状态管理等基础组件。
6.png

Spring Cloud VS Kubernetes

Spring Cloud和Kubernetes有很大的不同,Spring Cloud和Kubernetes处理了不同范围的微服务架构技术点,而且是用了不同的方法。Spring Cloud方法是试图解决在JVM中的微服务架构要点,而Kubernetes方法是试图让问题消失,为开发者在平台层解决。Spring Cloud在JVM中非常强大,Kubernetes管理那些JVM很强大。看起来各取所长,充分利用这两者的优势是自然而然的趋势了。
#5. 总结
技术架构的演变非常快,各种新的名词也是层出不穷。本文主要是对云原生的概述。云原生应用的三大特征:容器化封装、动态管理、面向微服务。首先由CNCF组织介绍了云原生的概念,然后分别对这三个特征进行详述。云原生架构是当下很火的讨论话题,是不同思想的集合,集目前各种热门技术之大成。

苹果宣布加入云原生计算基金会

大卫 发表了文章 • 0 个评论 • 408 次浏览 • 2019-06-13 08:27 • 来自相关话题

云原生计算基金会(简称CNCF)作为Kubernetes等顶级开源项目的运营方,今天宣布苹果公司即将以最高级白金用户的身份正式加盟。凭借这位新成员,CNCF如今已经拥有89位最终用户成员,其中还包括阿迪达斯、Atlassian、Box、GitHub、纽约 ...查看全部

云原生计算基金会(简称CNCF)作为Kubernetes等顶级开源项目的运营方,今天宣布苹果公司即将以最高级白金用户的身份正式加盟。凭借这位新成员,CNCF如今已经拥有89位最终用户成员,其中还包括阿迪达斯、Atlassian、Box、GitHub、纽约时报、Reddit、Spotify以及沃尔玛等。

与以往的作风一样,苹果公司并没有对此次公告做出评论。但CNCF方面指出,最终用户资格主要面向那些“对开源云原生技术高度依赖”且希望回馈整个社区的重度用户。作为CNCF最终用户成员,苹果公司实际上也正式加入了Linux基金会。

作为成员关系的一部分,苹果公司还在CNCF管理委员会当中获得一个席位,苹果方面的高级工程技术经理Tomer Doron将出任这一职位。

云原生计算基金会CTO Chris Aniszczyk表示,“吸引到苹果这样一家拥有丰富经验与庞大业务规模的企业作为最终用户成员,充分证明了云原生计算在未来基础设施与应用程序开发方面的可观潜力。我们很高兴能够获得苹果公司的支持,并期待着未来能够为更为广泛的云原生项目社区做出更多贡献。”

虽然很多朋友可能不会把苹果公司与开源参与企业联系起来,但事实上该公司确实已经开放了从Darwin操作系统的XNU内核到Swift编程语言等一系列内部成果。话虽如此,苹果方面一般不会参与开源云基础设施社区,而这次的举动可能预示着这位消费电子巨头正在迎来转变。苹果公司肯定拥有自己的数据中心,因此其确实有可能高度依赖着各类开源基础设施项目——当然,按照苹果的一贯风格,其对这类话题往往避而不谈。

原文链接:Apple joins the open-source Cloud Native Computing Foundation

云原生计算基金会宣布containerd项目正式毕业

大卫 发表了文章 • 0 个评论 • 639 次浏览 • 2019-03-01 08:22 • 来自相关话题

【编者的话】时至今日,containerd已经成为阿里云、AWS、Cloud Foundry、Docker、谷歌、IBM、Rancher Labs以及更多生态系统支持方们采用范围最广的容器运行时选项。 作为Kubernetes与Pro ...查看全部
【编者的话】时至今日,containerd已经成为阿里云、AWS、Cloud Foundry、Docker、谷歌、IBM、Rancher Labs以及更多生态系统支持方们采用范围最广的容器运行时选项。

作为Kubernetes与Prometheus等开源技术的坚定支持者,云原生计算基金会日前宣布,继Kubernetes、Prometheus、Envoy以及CoreDNS之后,containerd已经成为其第五个毕业项目。事实上,要从孵化阶段一步步发展成熟至毕业水平,这些项目必须表现出活跃的采用度、良好的多样性、规范的治理过程,以及对社区可持续性与包容性的坚定承诺。

云原生计算基金会CTO Chris Aniszczyk表示,“在被云原生计算基金会接纳近两年之后,containerd如今仍然拥有着显著的发展态势——这意味着整个市场对于基础窗口技术仍然高度渴求。社区中的大量工作与协作成果有力支持着这款核心容器运行时方案的开发与测试。此外,社区还在努力扩大维护者规模与采用基础,同时亦顺利通过了外部安全审计。看到项目能够顺利毕业,我感到非常激动。”

诞生于2014年的containerd最初由Docker所打造,旨在为Docker引擎提供低层运行时管理器。而在2017年3月被纳入云原生计算基金会之后,containerd已经逐步发展成一款行业标准性质的容器运行时方案。此项目始终强调简单性、健壮性与可移植性,目前被广泛用作Docker引擎与OCI runc执行器之间的对接层。

containerd项目维护者兼Docker公司工程师Michael Crosby指出,“Docker公司当初之所以决定将containerd贡献给社区,是因为我们希望能够将这套早已成为Docker引擎中标准化组成部分的方案分享给数以百万计的企业以及不计其数的用户,并推动其成为真正强大且可扩展的运行时解决方案。随着我们不断扩大范围以满足更多现代容器平台(例如Docker平台与Kubernetes生态系统)的需求,我们高兴地看到在过去一年当中,containerd项目在采用量与后续创新方面都带来了喜人的表现。随着containerd采用量的不断增长,我们期待着立足整体生态系统继续开展合作,并借此推动我们的行业长期保持发展。”

IBM Cloud Kubernetes Serivce杰出工程师Dan Berg也表示,“IBM Cloud Kubernetes Service(简称IKS)致力于为我们的客户提供卓越的托管Kubernetes使用体验。为了实现这一目标,我们一直在努力简化IKS的架构与运营方式。迁移至containerd,将有助于简化我们代表客户所配置及管理的Kubernetes架构。通过将containerd选定为我们的容器引擎,我们成功减少了架构中的额外层数量,从而在改善运营效果的同时帮助客户提高了服务性能。”

自项目建立以来,containerd一直吸引着众多维护者与提交者的参与。目前,我们共有来自阿里巴巴、Cruise Automation、Docker、Facebook、谷歌、华为、IBM、微软、NTT以及特斯拉等公司的14位提交者、4406项提交成果以及166位贡献者。大家可以通过DevStats网站查阅containerd项目的统计信息与贡献者资料等。

阿里云高级工程师Li Yi解释称,“自业务建立以来,阿里巴巴一直在使用containerd项目。现在,我们很高兴地看到该项目顺利迎来这一重大里程碑。作为一款容器运行时方案,containerd凭借着开放、可靠与通用等特质一直发挥着关键作用。在阿里云,我们充分将containerd的简单性、健壮性与可扩展性引入到阿里云KubernetesSerivce与Serverless Kubernetes当中。阿里巴巴团队还将继续努力推动社区进一步实现创新与突破。”

为了正式由孵化阶段走向毕业,containerd项目遵循云原生计算基金会提出的基本原则,接受独立的外部安全审计,并确定了自身治理结构以保障社区发展。此外,containerd还获得并保有核心基础设施倡议最佳实践徽章(简称CII徽章)。这项成就于2018年9月1日正式达成,CII徽章代表着整个社区对于代码质量与安全最佳实践做出的不懈承诺。

##containerd项目背景信息

* containerd 是一套行业标准化容器运行时,强调简单性、健壮性与可移植性。Containerd可作为Linux与Windows系统中的守护程序。
* containerd管理其所在主机系统上的整个容器生命周期——从镜像传输到存储、到容器执行与监督,再到底层存储乃至网络附件等等。
* 若您希望下载containerd项目、查阅相关说明文档以及了解如何加入社区,请访问: https://github.com/containerd/containerd。

原文链接:Cloud Native Computing Foundation Announces containerd Graduation

云原生计算基金会宣布CoreDNS项目正式毕业

JetLee 发表了文章 • 0 个评论 • 751 次浏览 • 2019-01-25 09:49 • 来自相关话题

云原生计算基金会(简称CNCF,负责为Kubernetes与Prometheus等开源技术提供支持)日前宣布,继去年毕业的Kubernetes、Prometheux以及Envoy等开源技术之后,CoreDNS成为其2019年的首个毕业项目。要从孵化阶段走向毕业 ...查看全部
云原生计算基金会(简称CNCF,负责为Kubernetes与Prometheus等开源技术提供支持)日前宣布,继去年毕业的Kubernetes、Prometheux以及Envoy等开源技术之后,CoreDNS成为其2019年的首个毕业项目。要从孵化阶段走向毕业,项目必须在市场上表现出活跃的采用积极性、多样性、规范的治理流程,以及对于社区可持续性与包容性做出坚定承诺。

CoreDNS是一套快速、灵活且现代的DNS服务器方案,亦可在云原生部署场景下提供服务发现功能。基于其提供了能够向下兼容,且具备可扩展性的Kubernetes集成能力,因此在Kubernetes的最新版本(1.13)中CoreDNS被指定为未来一切部署场景中的默认DNS选项。此外,该服务器还适用于配合AWS(启用AWS Route 53与etcd)的混合云环境下的原生云集成,未来亦有计划进一步为Google Cloud DNS提供支持。

云原生计算基金会COO Chris Aniszczyk表示,“CoreDNS已经在最近两年中成为云原生计算基金会不可或缺的重要项目,并在社区的努力推动下达到毕业水平,同时正式成为Kubernetes的默认DNS服务器。此外,CoreDNS亦是一款出色的独立DNS服务器方案,正不断被用于更多其它环境——我们很高兴能够随着项目的发展而不断为其社区提供支持。”

该项目由Miek Gieben于2016年3月正式建立,他当时担任谷歌公司的站点可靠性工程师。在构建CoreDNS时,社区考虑到其它DNS服务器方案的局限性,希望打造出一款能够与多个后端(例如etcd、Consul以及Kubernetes)进行通信的通用型DNS服务器。CoreDNS随后于2017年加入到Cloud Native Sandbox当中,并于2018年2月晋升为孵化项目。如今,该项目已经拥有100多位贡献者,16位活跃维护者,亦有众多组织机构在Kubernetes内外的生产环境中加以使用——包括Bose、Hellofresh、Skyscanner、SoundCloud、Trainline以及Zalando等。

CoreDNS维护者Yong Tang表示,“自从2017年年初加入云原生计算基金会以来,CoreDNS迎来了良好的社区增长表现,亦在生产环境中展现出惊人的应用空间。我们非常感谢云原生计算基金会对CoreDNS项目的大力帮助,亦期待继续保持合作以不断扩大我们的社区规模。”

Okkur Labs创始人兼CoreDNS维护者Michael Grosser指出,“CoreDNS项目及社区已经取得巨大进展,而成为云原生计算基金会毕业项目则标志着一大重要里程碑。从一套用于发布Prometheus指标的简单DNS服务器,到一款具备固有灵活性的成熟DNS解决方案,再到大多数Kubernetes集群内的信心组件并为无数用户带来更理想的稳定性与灵活性,这一切都令我们对于CoreDNS背后强大的支持社区充满信心。”

谷歌云计算高级软件工程师、CoreDNS高级维护者John Belamaric表示,“CoreDNS的灵活性以及基于插件的架构设计,已经被证明是一种理想的DNS服务器构建思路。CoreDNS的易于集成与可扩展能力对于各种DNS服务与用例的实现而言至关重要——从Kubernetes服务发现到基于策略的DNS与广告拦截,都离不开这两大重要能力。云原生计算基金会对该项目提供的支持同样不可或缺,我们很高兴能够正式毕业并继续发展我们的多元化项目社区。”

Infoblox公司软件经理Francois Tur指出,“作为一位项目维护者,我专注于调整CoreDNS以供Kubernetes社区使用,以Kubernetes中的CoreDNS部署场景为基础开展协作,并验证CoreDNS作为Kubernetes集群指定DNS服务器的实际效果。今天CoreDNS从云原生计算基金会毕业,对于我们的项目社区来讲是个了不起的成熟。这一旅程开始于两年多之前,而且一切都才刚刚开始。”

为了正式从孵化状态毕业,CoreDNS项目遵循云原生计算基金会的行为准则。CoreDNS团队还在过去一年当中先后发布了12个版本,项目目前拥有35款内置插件以及15款外部插件,其中一部分由Kubernetes社区开发而成。此外,CoreDNS在过去两年中还参与到谷歌公司组织的代码夏令营(Google Summer of Code)当中——活动中导师将与在校实习生们结对探索,旨在推动云原生项目的不断发展。

Infoblox公司高级软件经理Naveen Singh表示,“在Infoblox公司,我们很自豪地能够在自己的SAAS DNS产品当中使用CoreDNS,而且目前也已经在全球范围内部署了众多CoreDNS实例。CoreDNS目前正在为全体Infoblox云客户支持生产DNS流量,其中也包括不少财富五百强企业。我们非常欣赏CoreDNS的插件架构,其为我们带来了巨大的灵活性空间、更高的开发速度与更快的发布周期。”

GitNS创始人Michael Grosser指出,“将GitNS.com建立在CoreDNS这一坚实的基础之上,是我做出的最明智的决定之一。考虑到DNS的基本特性,要求我们必须选择一套具有高性能、高可靠性以及强大扩展能力的系统作为构建基础。CoreDNS项目拥有着令人难以置信的卓越社区,我们非常乐于为其提供支持。随着CoreDNS从云原生计算基金会正式毕业,其将成为构建基础设施与定制化用例中最理想的DNS平台选项之一。”

CoreDNS背景信息:

* CoreDNS是一套由Go语言编写而成的DNS服务器,其遵循Apache License Version 2许可,且完全开源。
* CoreDNS凭借着强大的灵活性而适用于多种环境及用例。其可用于Kubernetes服务发现、权威DNS服务器、高DNS强度应用的本地缓存等等。其中的各款插件能够彼此链接以实现Prometheus指标检测等额外功能,亦可以开箱即用的方式带来重写查询等功能。
* 除了从标准区域文件提供DNS之外,CoreDNS还通过Kubernetes插件与Kubernetes相集成,可利用etcd插件直接对接etcd,并能够与多种其它后端数据提供程序进行整合。
* 若需下载CoreDNS项目本体,或者参阅与项目相关的说明文档与背景信息,请访问 https://github.com/coredns/coredns。

原文链接:Cloud Native Computing Foundation Announces CoreDNS Graduation

云原生技术的初学者指引

Zangying2005 发表了文章 • 0 个评论 • 872 次浏览 • 2019-01-02 16:08 • 来自相关话题

当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目 ...查看全部
当我们初接触云原生技术时,可能会觉得它有些复杂和混乱。不过,我们可以先来了解一个开放,活力的软件社区,即云原生计算基金会(CNCF)。它为数不清的云原生技术项目提供了持续不断的支持和贡献。而且,CNCF有一张涵盖了全部云原生解决方案的全景图,许多耳熟能详的项目方案都包括在这张图内。

我有幸成为CNCF的大使,致力于在加拿大推广社区活动和云原生的教育。同时,在CloudOps社区, 我还带领着Docker和Kubernetes研讨会,向大家普及云原生技术,帮助DevOps团队实践相关的技术应用。

我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。大家通过电子邮件或在博客上@archyufaor的方式保持联系。为他们提供云原生技术的信息咨询。

同时,我还编写了云原生技术的初学者指南。希望能帮助读者理解这个领域并在这个领域取得更好的进展。
#CNCF的历史背景
2014年,谷歌开源了一个主要用于容器编排的,名为博格(Borg)的内部项目。由于没有机构来管理这个项目,谷歌就与Linux基金会联合创建了旨在鼓励Kubernetes和其他云原生解决方案的开发和协作的云原生计算基金会(CNCF)。而Borg项目就更名为Kubernetes,并用Go语言重写了实现部分,成为了CNCF的启动捐赠项目。毫无疑问地讲,Kubernetes只是开始,后续有大批的新项目先后加入到CNCF,围绕着Kubernetes不断地扩展功能。
#CNCF的使命
通过提供多种选项的开发软件社区,帮助最终用户构建云原生应用。从而培育云原生开源项目的生态体系。CNCF鼓励项目之间的相互协作,希望实现完全由CNCF成员项目演化出来的成熟技术栈。这便是CNCF在云端的自我使命。
#CNCF的历程
目前共有25个项目已经被CNCF接受,在跟进Kubernetes生态发展。希望加入到CNCF的项目,必须是由技术监督委员会(TOC)选定并通过投票评比,取得绝大多数的投票认同才可以加入。投票过程由TOC贡献者组成的一个优秀社区来辅助进行,而TOC贡献者是来自CNCF成员公司的代表,我有幸也是其中一位。评选通过的项目就叫CNCF成员项目,CNCF将根据成员项目代码成熟度级别分别定义为沙箱、孵化或毕业阶段。
##沙箱阶段
这个阶段的项目非常早期,在部署到生产环境之前,需要显著地提升代码成熟度,积极参与开源社区的互动。项目之所以被选中,主要是因为它们具备的潜力是社区所没有的。在CNCF的指南中提到,CNCF将帮助推动沙箱项目的公共可见性,并促进其与现有项目形成体系。但沙箱项目从CNCF获得的资金和营销支持非常少,并且每12个月都要接受审查,发展不够好的项目可能会被淘汰掉。
##孵化阶段
当项目满足所有沙箱标准并具备明显的增长和成熟度特征时,它们就进入孵化阶段。这时,它们必须至少在三家公司的生产环境中使用过,具备稳定的团队,确保稳定提供对社区的贡献,包括处理来自社区的新功能和代码要求等。
##毕业阶段
孵化项目一旦达到生产使用的临界点,TOC就可以投票决定项目是否进入毕业阶段。毕业的项目必须证明有很高的采用率,并满足所有孵化标准。项目的提交者必须至少来自2个不同的组织,具有文档化和结构化的管理流程,并满足Linux基金会核心基础设施计划的最佳实践徽章要求。截止到目前,只有Kubernetes和Prometheus两个毕业项目。
# CNCF项目介绍
我将CNCF成员项目划分了12个类别,分别是:编排、应用程序开发、监控、日志记录、跟踪、容器注册、存储和数据库、运行时间、服务发现、服务网格、服务代理、安全以及数据流和消息流。我希望所提供的信息能够帮助公司或个人评估每个项目做什么,如何演化的,以及如何与其他CNCF项目集成等。
##编排
3.png

Kubernetes

Kubernetes(已毕业)—— Kubernetes这个单词在古希腊语是舵手的意思。强调自动化和声明性配置,可自动化完成容器化应用的部署、伸缩和管理。Kubernetes进行容器编排,而所编排的容器是可移植和模块化的微服务包。它为应用添加了一个抽象层,将容器分组运行在Pod中,从而实现容器的编排。Kubernetes可以帮助运维人员进行工作负载排期,并允许容器在多云环境中大规模部署。Kubernetes在毕业后被广泛应用,CNCF最新的调查显示,超过40%的企业受访者在生产过程中使用了Kubernetes。
##应用程序开发
4.png

Helm

Helm(孵化阶段)——Helm是程序包管理器,以chart的形式让用户轻松地查找、共享、安装和升级Kubernetes应用。帮助终端用户使用KubeApps Hub部署已有应用(包括MySQL、Jenkins、Artifactory等)。KubeApps Hub能够列出由Kubernetes社区维护的稳定库和孵化库中的全部chart。通过Helm,用户可以安装Kubernetes之上的所有CNCF项目。并且还可以让企业在Kubernetes上创建和部署自定义的应用程序或微服务。当然,这会涉及到创建YAML清单,根据不同的环境或CI/CD流程匹配不同的部署参数等情况。Helm所创建的单个chart,可以基于应用程序或配置更改来进行版本控制,可以部署在各种环境中,还可以进行跨组织共享。

Helm项目最开始来源于为Kubernetes用户创建自定义体验的Deis项目。早期的Helm版本只有客户端,但后来Deis与谷歌合作在Helm V2版本中添加了服务端‘tiller’,与Kubernetes 1.2同期发布。这就使得Helm成为在Kubernetes之上部署应用的标准方式。

Helm目前正在2018年年底Helm V3发布进行一系列的更改和更新。对于依靠Helm进行日常CI/CD开发的公司,包括Reddit、Ubisoft和Nike,我建议他们按照新的设计进行优化调整。
5.png

Telepresence

Telepresence(沙箱阶段)——虽然在私有云容器应用开发方面,有包括Docker Compose和Minikube在内的流行工具。但在Kubernetes上开发容器化应用程序仍然非常具有挑战性。因为,目前大多数云原生应用都是资源密集型的,并且涉及多个数据库、服务和依赖项。此外,模拟云依赖关系非常复杂,例如在Docker Compose和Minikube中与消息传递系统和数据库的依赖关系就是一个复杂的事情。这里有一个可参考方案,就是使用完全远程的Kubernetes集群,但是这方案会影响IDE、调试器等本地开发工具的应用,并且会导致开发人员出现等待CI去进行测试更改之类的“内部循环”效应。

由Datawire开发的Telepresence在上述设想方面提供了不错的解决方案。它允许开发人员因开发需要在本地运行单个微服务,同时保持与运行在远端Kubernetes集群上的其余部分应用的连接,我们称之为 “实时代码”。Telepresence在远端Kubernetes集群上部署了包含双向网络代理的Pod。将本地机器连接到网络代理。实现了部署真实的开发/测试环境,而无需冻结用于编码、调试和编辑的本地工具。
##监控
6.png

Prometheus

Prometheus(已毕业)——类同于Kubernetes的历程,Prometheus是第二个加入到CNCF的项目,也是第二个毕业的项目。它是一个适合动态云环境和容器环境的监视解决方案。灵感来自于谷歌的Borgman监控系统。Prometheus完全是拉取式系统,通过配置决定了什么时候拉取什么数据。而不同于通过agent推送数据的push式监视系统。Prometheus将拉取的指标存储在TSDB中。允许用户使用PromSOL类查询语言抽取数据在Grafana仪表板内进行图形展示。用户还可以使用内置的警报管理器生成警报并以slack和电子邮件的方式发送给各种目标。

Prometheus的成功让它已经成为了云原生监控的事实性标准。通过Prometheus,用户可以监控VM、Kubernetes集群和运行在任何地方的微服务,尤其适应像Kubernetes这样的动态系统。Prometheus的度量指标还可以利用Kubernetes的HPA、VPA和集群自动伸缩等功能来进行自动伸缩决策。也支持对其他的CNCF项目的监控,如Rook、Vitesse、Envoy、Linkerd、CoreDNS、Fluentd和NATS。Prometheus的输出集成了许多其他应用和分布式系统。我建议初学者从Helm Chart开始接触。
7.png

OpenMetrics

OpenMetrics (沙箱阶段)——OpenMetrics为应用程序的外部指标格式设定了中性的标准。这个标准让用户可以在更大范围的系统间传输指标数据。OpenMetrics其实是基于Prometheus的指标格式,而后者又是采用Borgmon的运营经验,Borgmon实现了“白盒监控”和低开销的海量数据收集,有着超过300家的服务输出商。在OpenMetrics之前,监控环境主要都是基于像SNMP之类,相对过时的标准和技术,使用专用指标格式,也很少有人关注指标格式规范,存在不少系统差异性的问题。而OpenMetrics出现后,在Prometheus的指标格式之上,定义了更紧凑、更清晰和更严格的语法。很好的改善了系统间指标差异这方面的问题。

虽然OpenMetrics仍在沙箱阶段,但它已经被AppOptics、Cortex、Datadog、谷歌、InfluxData、OpenCensus、Prometheus、Sysdig和Uber等公司用于生产环境。
8.png

Cortex

Cortex (沙箱阶段)——Prometheus的首要设计目标就是操作简单。因此,它只运行在单节点或单容器内,所使用的存储也是不具备持久或长期存储能力的本地存储。避免采用操作复杂性更高的集群和分布式存储的目的也是为了符合Prometheus的简单原则。Cortex却是具备水平可扩展、支持多租户、采用长效存储设备的辅助解决方案。这对于Prometheus而言,我们认为是不错的补充。它让大型企业在使用Prometheus时,可以具备高可用性,可以访问长效存储设备。虽然在这个领域,目前还有其他一些例如Thanos、Timbala和M3DB的项目也获得社区的关注。但是,Cortex已经在GrafanaLabs和Weaveworks作为SaaS产品进行了battle测试,而且EA和StorageOS也在prem平台上部署了它。
##日志和跟踪
9.png

Fluentd

Fluentd(孵化阶段)——Fluentd采用统一的方法,对应用程序的日志进行收集、解析和传输。使用户可以更好地理解和利用这些日志信息。这统一的方法就是将日志数据定义成JSON格式,实现跨多个源和目的地进行日志的收集、过滤、缓冲和输出。Fluentd的优势之一是可以收集VM和传统应用的日志,但它真正的优势还是在云原生环境Kubernetes之上,作用于那些动态运行的微服务。

Fluentd以daemonset的方式,运行在Kubernetes上每个Pod节点内。它不仅收集容器内所有应用程序的日志(包括CNCF ones),还将日志发送到STDOUT。Fluentd具有逐条解析和缓冲日志记录的能力,并将格式化的日志发送到所配置的目的地,如Elasticsearch、Hadoop和Mongo,让用户可以进行后续处理。

Fluentd最初是用Ruby编写的,虽然功能比较完整,但运行时需要50Mb以上的内存,这对于配对容器部署运行显然不太合适。于是,与Fluentd同时开发的Fluentbit变成了一个替代解决方案。Fluentbit是用C写的,在运行时只需要几Kb的内存,CPU和内存上效率更高,但功能比Fluentd要简单很多,存在比较多的限制。

Fluentd最初是Treasuredata的一个开源开发项目,只是Kubernetes的一个日志插件。较早的可部署版本是0.12,版本比较老、但非常稳定,已被广泛部署在各种生产环境中。近期开发完成的1.X新版本包含了很多改进,例如增加新的API、纳秒级响应和支持Windows环境等。Fluentd正在慢慢成为云原生环境中日志收集的标配, 很大可能成为下一个CNCF毕业项目。
10.png

OpenTracing

OpenTracing(孵化阶段)——开发人员需要能够查看到每条事务并懂得微服务的行为,这使用分布式跟踪对于大规模构建微服务的重要性不能被低估,然而,分布式跟踪非常具有挑战性,需要跟踪工具必须通过已有的服务、包和特定的应用程序代码在流程内和流程之间传播跟踪的上下文。OpenTracing允许应用程序代码、OSS包和OSS服务开发人员无需限定具体供应商的情况下测试自己的代码。 它为应用程序和OSS包提供了一个分布式跟踪标准,这些程序包具有独立的API和9种语言的可用库。专注于分布式跟踪使得OpenTracing非常适合服务集群和分布式系统。但OpenTracing本身并不是一个在UI中运行跟踪来分析spans的跟踪系统。它只是一个与应用业务逻辑、框架和现有工具一起工作的API,可用于创建、传播和标记spans。它创建存储在后端或UI格式的跟踪。目前,OpenTracing集成了开源(如Jaeger,Zipkin)和商业跟踪解决方案(如Instana,Datadog)。
11.png

Jaeger

Jaeger(孵化阶段)——Jaeger是一个开源的分布式跟踪系统解决方案,它与OpenTracing兼容,最初是由Uber开发和测试的。它的名字的发音是yā′gər,即猎人的意思。灵感来自于谷歌的内部跟踪系统Dapper和Zipkin。Zipkin是由Twitter编写,采用了OpenTracing标准(但限制了集成支持能力)构建的开源跟踪系统。Jaeger通过HTTP接受Zipkin格式的spans,并具有Zipkin的向后兼容性。Jaeger的用例监视和基于微服务的故障排除功能,提供了分布式上下文传播、分布式事务监视、根本原因分析、服务依赖关系分析以及性能和延迟优化能力。Jaeger的数据模型和工具包库与OpenTracing兼容。它的Web UI是采用React/Javascript构建的,可以对Cassandra、Elasticsearch和memory等后端提供多种支持。同时,Jaeger集成了包括Istio和Linkerd在内的服务组件,使得跟踪更加容易实现。 

Jaeger默认会暴露Prometheus的指标,并与Fluentd集成来进行日志传输,这让它具有很好可观察性。可以通过Helm chart或最近开发的Jaeger Operator部署到Kubernetes之上。Uber和RedHat为Jaeger代码库提供了大部分的贡献。但还有数百家公司为Jaeger用于云环境和基于微服务的分布式跟踪在进行调优。
##容器注册
12.png

Harbor

Harbor(沙箱阶段)——Harbor最初是由VMWare作为开源解决方案开发的,是一个开源可信任的容器注册器,用于存储、标记和扫描Docker镜像,提供了免费的、增强的Docker注册特性和功能。它提供的Web接口具有基于角色访问控制(RBAC)和LDAP验证支持的安全特性。它集成了由CoreOS开发的用于漏洞扫描的开源项目Clair和用于内容信任的Notary(一个CNCF孵化项目,稍后介绍)。Harbor提供活动审计、Helm chart管理和Harbor实例间的镜像复制(高可用和灾难恢复用途)功能。现在已经被许多公司所使用,包括TrendMicro、Rancher、Pivotal和AXA。
##存储和数据库
13.png

Rook

Rook(孵化阶段)——Rook是Kubernetes的开源存储编排器。它帮助OPS人员在Kubernetes之上运行Ceph等软件分布式系统(SDS)。开发人员可以使用存储动态创建Kubernetes中的持久卷(PV)来部署Jenkins、WordPress等存在状态请求的应用程序。

Ceph是一种流行的开源SDS,它运行在常规的硬件上,对外提供对象存储,块存储和文件系统等多种主流的的存储服务类型。用户可以将Ceph集群直接部署在硬件上,然后使用CSI插件将其连接到Kubernetes。但这样做无疑会增加OPS人员的部署和操作Ceph集群的难度,增加工作挑战性,降低对Ceph集群的欢迎度。而Rook使用自定义资源定义(CRDs)方式将Ceph作为第一个类对象部署到Kubernetes中,并使用操作框架将其变成自管理、自伸缩和自修复的存储服务。这一点恰恰对应了Kubernetes运行的理念,即将人的操作知识编码到软件中,从而可实现简易打包和与终端用户的共享。

与Helm专注于打包和部署Kubernetes应用程序相比,Rook Operator可以部署和管理复杂的SDS应用程序生命周期。以Ceph为例,Rook操作人员可以自动化存储管理员的工作,例如部署、引导、配置、性能指定、水平伸缩、修复、升级、备份、灾难恢复和监视等。

最初的Rook Operator只支持Ceph,在0.8版本时,对Ceph的支持达到Beta版,随后发布了用于存储厂商的Rook框架,这个框架将Rook扩展成为一个通用的云原生存储编配器。具有支持可重用规范、逻辑、策略和测试的多个存储解决方案。目前Rook在alpha中支持CockroachDB、Minio、NFS,后续将支持Cassandra、Nexenta和Alluxio。在生产中使用Ceph的Rook Operator的公司越来越多,尤其是在Prem平台上,包括CENGN、Gini、RPR都有部署,还有许多公司正在评估阶段。
14.png

Vitess

Vitess (孵化阶段)——Vitess是一个数据库的中间件。 它使用通用分片技术在MySQL实例之间分发数据。它可以实现水平伸缩,在不影响应用的情况下,进行水平的无限扩展。 当用户的分片达到满负荷时,Vitess能以零停机时间和良好可观察性,重新对底层数据库进行分片扩展。Vitess还解决了许多与事务性数据相关的问题,项目成长趋势良好。
15.png

TiKV

TiKV(沙箱阶段)——TiKV是一个事务性键值数据库,它具备简化调度和自动平衡的能力。它充当了分布式存储层,提供数据强一致性、分布式事务管理和水平伸缩性的功能。TiKV的设计灵感来自于谷歌Spanner和HBase,但是它的优点是没有分布式文件系统。TiKV由PingCAP开发,目前还有有来自三星、腾讯云和UCloud的贡献者。
##容器运行时
16.png

RKT

RKT(孵化阶段)——RKT(读作Rocket)最初是由CoreOS开发的一个应用程序容器,属于Docker的备选项目。当时,Docker成为Kubernetes的默认容器,但遭遇到来自kubelet的压力,Kubernetes和Docker社区在相互协作方面存在着分歧。开发Docker的公司Docker Inc.有自己的产品路线图,并且正在给Docker添加一些复杂的功能。例如,为Docker添加集群模式,以及将文件系统从AUFS更改为overlay2。但做这些工作时,并没有向外发布信息,导致这些更改影响到了Kubernetes社区和Kubernetes路线图规划和发布日期。况且,Kubernetes用户需要用到的只是一个简单的容器,具备启停容器,并具备伸缩、升级等功能即可。因此,CoreOS就打算将RKT开发成Docker的替代品,专门为Kubernetes而构建。但令人意外的是,这举措却激发了Kubernetes的SIG-Node团队为Kubernetes开发了一个容器接口(CRI),这个接口可以连接任何类型的容器,并从其核心代码中把Docker的代码也被删除了。RKT可以同时使用OCI和Docker格式的镜像。虽然RKT对Kubernetes生态系统产生了积极的影响,但却没有被最终用户所接受,特别是那些习惯了Docker CLI并且不想学习其他应用程序打包方法的开发人员。此外,由于Kubernetes的流行,有许多容器解决方案都在争夺这一细分市场,例如Gvisor和基于OCI的cri-o都越来越流行,而RKT有点风景不再的感觉,可能会成为CNCF孵化器中被移除的项目。
17.png

Containerd

Containerd(孵化阶段)——Containerd是一个强调简单性、健壮性和可移植性的容器。与RKT一样,支持OCI和Docker镜像格式,但不同的是,Containerd设计的目的是嵌入到较大型的系统中,而不是提供给开发人员或最终用户直接使用。Containerd也是Docker捐赠给CNCF的项目。早期的Docker是一个高度集成的应用,但随着时间的推移,集群模式等功能的加入,使其成为一个复杂且难以管理的应用。而且对于要求简单容器功能的Kubernetes用户而言,Docker的复杂功能反而有些多余。因此,Kubernetes开始寻找包括RKT在内的替代方案,来替代默认的Docker容器。这时,Docker项目决定将自己拆分为松耦合的组件,采用更模块化的体系结构。这也就是Moby项目,其中Containerd就是这个项目的核心功能。拆分出来的Containerd通过CRI接口集成到Kubernetes,并改名为ri- Containerd。但从Kubernetes 1.10开始,默认采用Containerd通过内置的CRI插件实现集成,省却了额外的grpc跳转。

随着基于OCI的cri-o和Gvisor这样的项目越来越受欢迎,Containerd慢慢也不被社区所关注。不过它还是Docker平台不可或缺的一部分,在Kubernetes生态系统中还保有一定的位置。
##服务发现
18.png

CoreDNS

CoreDNS(孵化阶段)——CoreDNS是云原生部署中提供服务发现的DNS服务器。Kubernetes自1.12版起,将CoreDNS作为默认的集群DNS服务器,而在更早以前,SkyDNS是Kubernetes集群的DNS组件,它本身就是由Caddy和后来的KubeDNS组成的一个分支。SkyDNS是基于DNS的动态服务发现的解决方案,但体系结构不够灵活,很难添加新功能或进行扩展。于是Kubernetes转而采用KubeDNS。但KubeDNS在运行时,分3个容器(Kube-dns,Dnsmasq和Sidecar)运行,容易出现Dnsmasq漏洞,在新功能扩展上也存在类似SkyDNS的问题。而恰好这时,CoreDNS用Go语言进行了全面重写,成为了基于插件的灵活可扩展的DNS解决方案,而且在Kubernetes上,运行时只需启动一个容器,也没有漏洞方面的问题,提供的ConfigMap工具可动态更新配置。此外,CoreDNS通过严格的设计(如验证Pod记录)修复了许多KubeDNS上存在的问题。基于插件的架构使用户可以插件的方式随时添加或删除功能。目前,CoreDNS已包括30多个自有插件和20个以上的外部插件。通过链接插件,用户可以启用Prometheus监控、Jaeger日志跟踪、Fluentd日志记录、Kubernetes API或etcd配置以及其他的高级DNS特性和集成功能。
##Service Meshes
19.png

Linkerd

Linkerd(孵化阶段)——Linkerd是一个用于服务网格部署的开源网络代理服务。服务网格是一个单独的层,用于管理、控制和监视应用程序中的服务到服务之间的通信。Linkerd在无需应用代码变更的情况下,通过可编程的回路制动、速率限制、超时和重试配置来提高应用程序的容错性,帮助开发人员大规模地运行微服务。通过Zipkin提供了对微服务的可视化。以及提供了先进的交通控制设备来支持Canaries、Staging和Blue-green部署。SecOps团队受益于Linkerd的功能,在Kubernetes集群中通过TLS透明地加密了所有跨节点通信。Linkerd是在Twitter的Finagle项目之上开发出来的,项目具有广泛的生产用途,并吸引了许多探索服务网络的公司的兴趣。目前,Linkerd可以与Kubernetes、DC/OS和AWS/ECS一起使用。以DaemonSet的形式部署在Kubernetes上,这也意味着集群中的每个节点都运行了一个Linkerd Pod。

服务网格生态系统最近有新的变化,例如与Kubernetes紧密集成的Istio项目的引入,与微服务一起运行的轻量级代理Envoy的出现等。这些服务网格组件提供了比Linkerd更多的功能,这大大降低了Linkerd的受欢迎程度,甚至出现了质疑Linkerd存在价值的声音。为了重新获得社区的兴趣并支持现有的大量客户,Linkerd所属的公司Buoyant宣布了一个名为Conduit的项目,该项目允许DaemonSets使用Istio作为Sidecar代理,重写了dataplane,用Go语言重写了控制平面。这些改变使许多可能的特性都可以使用Sidecar方式。不久前,Conduit项目被重新命名为Linkerd 2.0,并发布了GA,这表明Linkerd已经准备应用于生产环境。服务网络还在飞速发展,像Istio和Linkerd 2这样的项目将是这方面的核心。
##服务代理
20.png

Envoy

Envoy(孵化阶段)——Envoy是一个为云原生应用设计的边缘节点和服务代理。它是由C++编写的CNCF孵化项目,是具备厂商无关性、高性能、轻量级的应用代理服务,已在Lyft上开发和进行了battle测试。Envoy可在不改变现有应用程序代码行的情况下,为微服务提供针对超时、安全、重试、回路制动在内的容错能力。通过与Prometheus、Fluentd、Jaeger和Kiali的集成,它提供了对微服务之间事件的自动可见性。Envoy还具备执行流量路由和流量分发能力,负载均衡failovers的域感知能力,因此还可以充当一个边缘代理(如Kubernetes L7 Ingress控制器)的角色。

虽然服务代理领域已经有很多可选的项目,但Envoy激发了许多关于服务网格和现代负载平衡的兴趣点和革命性想法,对现有生态起到很好的补充。涉及Envoy部署的有Heptio公布的Contour项目,这个项目是部署Envoy代理作为反向代理和负载平衡器来充当Kubernetes的入口控制器。Contour支持动态配置更新和多团队Kubernetes集群,能够限制可能配置虚拟主机和TLS凭证的命名空间,并提供高级负载平衡策略。另一个以Envoy为核心的项目是datawire Ambassador,这是一个强大的Kubernetes原生API网关。由于Envoy是用C++编写的,非常轻量级,非常适合在Kubernetes内部以Sidecar模式运行,也非常适合与API驱动的配置更新的风格相协同,成为dataplanes服务网格的理想候选方案。另外,服务网格 Istio宣布Envoy是其dataplane的默认服务代理,Envoy代理以Sidecar模式部署在Kubernetes中的每个实例上。创建一个由Istio的控制面板配置管理的透明的服务网格。这种方法与Linkerd v1中使用DaemonSet模式完全不同,后者提供了每个服务的可见性,并提供在Kubernetes甚至混合云场景中为每个服务创建安全TLS的能力。最近,Hashicorp宣布其开源项目Consul Connect也将使用Envoy在微服务之间建立TLS连接。

现在,Envoy在背后没有任何供应商或商业项目的驱动下,创立了一个庞大而活跃的开源社区。如果您想尝试Envoy,也建议试用一下Istio、Ambassador或Contour, 2018年12月10日在西雅图,Kubecon的Envoy社区成功地主办了第1届EnvoyCon,欢迎大家加入到社区。
##安全
21.png

Falco

Falco(沙箱阶段)——Falco是Sysdig开发的开源实时安全工具,设计用来检测在Kubernetes编排系统中的异常活动和入侵行为。它驻留在用户空间中,使用Sysdig内核模块检索系统调用活动。Falco与SecComp或AppArmor之类的执行工具相比,它具备更多的审计功能。

Falco用一组预配置的规则,定义了需要注意的行为和事件。然后以DaemonSet方法运行在Kubernetes中,基于这些规则,Falco可以检测到任何调用Linux系统的行为,并为这些行为添加警报。类似的行为可能来自于在容器内的shell运行脚步,或建立出站网络连接的二进制文件。这些事件可以通过Fluentd在STDERR上捕获,然后发送到ElasticSearch进行过滤或解除告警。从而可以帮助用户迅速应对如容器破坏或损毁的安全事故,减少此类事件造成的经济损失。

随着Falco被纳入CNCF的沙箱阶段,我们希望它以后与更多的其他CNCF项目深度集成,例如在Falco内集成官方的Helm Chart。
22.png

Spiffe

Spiffe(沙箱阶段)——在应用负载之间建立互信是一个复杂的问题,且随着负载的弹性伸缩和动态调度,这个问题变得更为困难甚至危险。但Spiffe是解决这个问题的云原生方案。Spiffe提供了一个策略驱动、API驱动且完全自动化的安全产品标识框架。它通过验证身份来开启应用负载之间的通信。Spiff现在还相对较新,主要是设计用于与Spire紧密配合的项目。
23.png

Spire

Spire(沙箱阶段)——Spire是Spiffe的运行环境,是一系列可集成到云提供商和中间件层的软件组件。Spire采用模块化架构,支持多种平台。目前,围绕Spiffe和Spire的社区发展非常迅速。HashiCorp刚刚宣布在Vault中支持Spiffe ID,使得它可用于关键信息和常态轮换。Spiffe和Spire现在都处于CNCF的沙箱阶段。
24.png

Tuf

Tuf(孵化阶段)——Tuf是“The Update Framework”的缩写。它是一个用于可信内容分发的框架。内容信任问题是一个重要的安全问题。Tuf通过验证软件的出处,并确认只使用软件的最新版本,来提供内容信任,改善这个问题。TUF项目在下面将提到的Notary项目中扮演许多非常重要的角色。也被许多公司用于生产环境构建内部工具和产品,这些公司包括Docker、DigitalOcean、Flynn、Cloudflare和VMware。
25.png

Notary

Notary(孵化阶段)—— Notary是一种安全的软件分发实现。本质上,是基于TUF,确保所有提取的Docker镜像都是具有签名、正确和未篡改的镜像版本。 Notary可以贯穿于CI/CD工作流的所有阶段,解决Kubernetes中基于Docker部署的一个主要安全问题。Notary发布和管理受信内容的集合。它允许DevOps工程师批准已发布的可信数据并创建签名集合。这类似于Linux系统中软件库的管理工具,但只是用于Docker镜像管理。Notary的主要目标包括保证镜像版本的更新情况(始终有最新的内容,以避免漏洞),和对象之间的信用委托。例如用户之间,不可信镜像和传输通道的可信分发等。虽然Tuf和Notary通常不被终端用户直接使用,但它们的解决方案集成到各种商业产品或开源项目中,用于可信分发的内容签名或图像签名,这些产品包括Harbor、Docker Enterprise Registry、Quay Enterprise、Aqua。在这个领域还有另一个有趣的开源项目Grafeas,它是一个开源的元数据API。所存储“attestations”或图像签名可以作为部分授权控制的校验,也可用于容器分析API和GCP的二进制授权。和JFrog,AquaSec的同类功能类似。
26.png

OPA

Open Policy Agent(沙箱阶段)——Open Policy Agent(OPA)采用强制声明方式来指定策略,允许在一个技术堆栈中分发不同类型的策略,并自动更新,而无需重新编译或重新部署。在应用和平台层,OPA以从服务发送查询的方式通知策略决策。它与Docker、Kubernetes、Istio等应用都有不错的集成效果。
##数据流和消息流
27.png

NATS

NATS(孵化阶段)——NATS是一个聚焦中间件的消息传递服务,允许基础设施在分布式系统之间发送和接收消息。它的集群和自动修复技术具备高可用性,并且它基于日志的数据流保证了有历史数据引用消息的送达和所有信息的接收。NATS有一个相对简单的API,支持多种技术用例,包括云中常规消息传递、微服务传输、控制平面和服务发现等消息传递,以及物联网消息传递。与前文所列的日志记录、监视和跟踪解决方案所不同的是,NATS工作在应用层。
28.png

gRPC

gRPC(孵化阶段)——gRPC是一个高性能RPC框架,提供在多个平台上,库、客户端和服务器之间进行通信的能力。可以在任何环境中运行,并为Envoy和Nginx等代理提供支持。gRPC为负载平衡、跟踪、健康检查和身份验证提供可插入的支持,来实现有效地连接服务。将设备、应用程序和浏览器与后端服务连接起来。gRPC是促进消息传递的应用层工具。
29.png

CloudEvents

CloudEvents(沙箱阶段)——CloudEvents为开发人员提供了一种通用的方式来描述跨多云环境下发生的事件。通过提供描述事件数据的规范,CloudEvents简化了跨服务和平台的事件声明和传递。项目仍处于沙箱阶段,还需要极大地提高应用程序的可移植性和效率。
# 后续展望
云原生生态正在不断地飞速增长。在不久的将来,还将有更多的项目被纳入到沙箱阶段,让它们有机会获得社区的兴趣和认识。我们希望像Vitess,NATs,Rook之类与基础设施相关的项目能不断得到CNCF的关注和支持。因为他们是云原生部署的重要推动者。同时,在云原生持续交付的领域还相对空白,我们希望CNCF能够继续关注。

尽管CNCF在不断纳入新项目,让成熟的项目毕业。但同样重要的还需要有一种工作机制,将那些因失去社区关注,价值性不高或被其他项目取代的项目从CNCF孵化器中移除。虽然项目提交过程对任何人都是开放的,但我希望TOC委员会继续只资助最优秀的候选者,使CNCF成为项目间协同良好,多样化的生态系统。

作为CNCF的大使,我希望教会人们如何使用这些技术。在CloudOps,我带领了Docker和Kubernetes的研讨会,推广云原生技术,并帮助DevOps团队实践他们的应用。我也组织Kubernetes和云原生技术相关的会议,邀请了来自世界各地的演讲者展示他们各种类型的技术项目。这些演讲者在蒙特利尔、渥太华、多伦多、基奇纳-滑铁卢和魁北克市等地推动他们的项目运行。我也鼓励大家加入CloudNativeCon。通过邮件联系@archyufa或CloudOps,了解更多关于云原生技术的信息。

原文链接:The Beginner’s Guide to the Cloud Native Landscape(翻译:易理林)

石油巨头如何与Kubernetes, DevOps共舞?

灵雀云 发表了文章 • 0 个评论 • 734 次浏览 • 2018-12-05 11:08 • 来自相关话题

近日,中国石油自主知识产权的勘探开发梦想云(E&P Cloud)平台V1.0在京隆重发布。作为支持梦想云落地的唯一容器 PaaS 和云原生技术领域合作伙伴,灵雀云凭借强大的技术实力和卓越的服务能力,协助中油瑞飞全程深度参与了梦想云 PaaS 平台的建设。 ...查看全部
近日,中国石油自主知识产权的勘探开发梦想云(E&P Cloud)平台V1.0在京隆重发布。作为支持梦想云落地的唯一容器 PaaS 和云原生技术领域合作伙伴,灵雀云凭借强大的技术实力和卓越的服务能力,协助中油瑞飞全程深度参与了梦想云 PaaS 平台的建设。


在不久前召开的年度开源技术盛会 KubeCon+CloudNativeCon 上,灵雀云CTO 陈恺携手中油瑞飞资深架构师迟汇发表了以“Big Oil on Kubernetes and DevOps”为主题的演讲,对勘探开发梦想云平台项目进行了阐述。


演讲分为三个部分:
首先,由陈恺做项目背景介绍;其次,由迟汇介绍基于Kubernetes、微服务和DevOps等先进技术和理念的统一技术平台的设计思路和方案;最后,再回到产品和技术,由陈恺介绍灵雀云如何协助中油瑞飞将云原生技术成功落地。
以下为演讲实录:
灵雀云陈恺:


大家好,我是灵雀云的CTO陈恺,今天要为大家分享一下灵雀云为国内最大的能源企业建设企业级PaaS平台的案例。非常荣幸请到中油瑞飞负责DevOps的迟汇和我一起为大家分享,中石油如何落地 Kubernetes 和 DevOps 。

像中石油这样体量的企业,大家可以想象业务环境的复杂和规模的庞大。复杂的业务板块面临很多挑战,比如十几个油田以前没有统一的规划,各自运行自己的IT系统,那么数据就会散落在各个地方,没有办法串联和共享,因此就无法把数据真正地利用起来。从平台级别来看,每个油田也不会做统一的IT平台,难以对上面的业务做统一的支撑。


灵雀云协助中油瑞飞建设的勘探开发梦想云就是应对这些挑战的。在底层我们会建立统一的数据库,把散落在各个油田的各种各样的数据相互之间打通,集中到一起,对数据做一个治理;中间是统一的技术平台,也就是我们今天主要讲到的基于Kubernetes的PaaS平台,这当中主要涵盖三个场景:容器、DevOps和微服务治理,相当于是整个云原生的三个核心要素。


项目的最终目标是建立统一的数据湖和统一的技术中台,在上面解决整个中石油的通用的业务。


那么接下来有请中油瑞飞的迟汇介绍一下中石油项目采用的技术和整体建设思路和方案。


中油瑞飞迟汇:


中石油的DevOps平台主要包含三个模块,第一个模块是DevOps,第二个模块是微服务,第三个模块是容器平台。


我们讲DevOps分为八大体系,分别是项目管理、知识共享、持续构建与测试、持续交付、认证与改进、学习培训、运营统计、运营监控。



pic2.jpg




整个工具链支撑体系中,涉及到的工具是15个,大部分是开源的。



pic3.jpg



下面讲述一下平台建设的部分成果展示。做这个项目的过程当中,形成了14个角色,8个职责,5个权限组。右侧是所有的认证体系,这个认证体系里面我们现在已经准备了6个测试场景,4个课件,有新项目接进来之后我们会对它有一个针对性的培训,最后是一个成熟度的评估。

pic4.jpg




灵雀云陈恺:


下面就让我们回到产品和技术层面,来讨论一下怎么样通过灵雀云的平台,为中石油复杂的业务场景搭建DevOps开发体系的。


先来简单了解一下灵雀云的产品。灵雀云有两条主要的产品线。一个是Alauda Container Platform(ACP), 他是一个高度标准化的,专注于云原生应用管理场景的赋能平台,它本身覆盖了三个场景,分别为容器平台,DevOps和微服务,也是我们云原生技术的三个核心。


pic5.jpg




另外一条产品线是Alauda Cloud Enterprise(ACE),主要面对是大型企业的统一PaaS平台。刚才分享的中石油平台就非常符合这样的场景。


ACE本身包含了ACP所有的能力,在这之上,针对大型企业建设统一PaaS平台的场景的能力又有一些加强。举几个例子,比如说ACE的客户通常来说会有很复杂的基础设施的环境,一般都会有很多个数据中心。一些客户开始尝试公有云的话,不会只用一家的产品服务,最后就会是一个异构的、混合的、跨云的基础环境。我们在每一个数据中心,或者说每一个公有云厂商上面根据他的使用需要去搭建多个K8s的集群。也就是说,管理这些异构、复杂的基础设施以及对多集群的支撑是ACE的核心能力。


在集群管理方面,我们不光可以通过ACE去部署一个灵雀云提供的K8s集群(也就是ACP),我们也可以让用户去导入一个他们已经有的K8s集群,现在我们已经有了一些这方面的实践。


另外一个针对大型企业统一PaaS平台的场景,是企业内部共同的需求。一般来说,企业内部会有几大类职能用户,和我们直接合作的是企业内部的平台部门,这个Team对企业内部的业务部门来说,是云平台的提供者和服务团队。


在此基础之上,ACE典型的使用场景通常来说会有几千个开发者,甚至更多。他们之间也需要根据不同的项目或者不同的部门,去划分出不同的租户,租户内部有团队内部协作的需求,租户之间有一些权限隔离和资源隔离,这也是ACE需要解决的另外一个问题。


pic6.jpg




回到今天的主题DevOps。DevOps是ACE一个核心的模块,在我们跟企业客户了解做 DevOps 诉求的时候,每一家都已经在使用一些工具并且有自己的流程,我们需要把现有的系统进行完善,而不是提供一个封闭式的产品去替代以前用的工具。


所以ACE DevOps 的整体思路,是提供一个开放式的DevOps工具链的集成和编排平台,通过集成之前客户已经在用的,以及需要的新的工具变成一个工具链,然后通过编排把这些工具和平台变成一个整体,最后可以贯穿整个应用全生命周期的管理。ACE的核心价值是将 DevOps 的最佳实践,加以提炼形成一个自动化的平台服务,提供给用户。


DevOps工具链集成一方面需要每个工具通过API集成在我们的容器平台上,另一方面,每个工具和平台的用户权限需要打通。每一个企业级的工具都会有自己的租户模型,这些租户模型和平台本身的租户模型需要有联动和对应。这样平台上的数千个工程师,在不同的项目里面共享这些工具时,会有一定的规范。在ACE中,一些核心场景的主流工具,我们会做深度的集成。在这种情况下,80%以上的使用场景在平台本身就可以完成。


刚才有提到,使用ACE在大型企业内部搭建一个统一PaaS平台,分成两类用户:一个是平台部门,负责搭建、维护平台以及对其他业务部门提供支撑和服务,他是平台管理员;另一个是业务部门,可以理解为企业内部的一些项目,也就是平台上面的一个个租户。在使用上大致的流程是这样的:平台部门准备基础设施,需要去部署和准备一些已有的集群,然后会在平台上面创建租户,并且设置管理员,他可以把集群的资源分给租户。租户管理员获取资源后,可以在集群里面创建环境,可以主动把资源向下派分。


对于DevOps实现来说,管理员可以部署和集成一些工具,然后可以把工具发布出来让租户自行订阅。同时,他也可以给每个工具去创建一些资源,然后主动把这些资源分配给租户。从根部管理员这边获得DevOps工具的资源有三种方式,一是管理员主动分配的,二是开发者订阅了管理员发布的库,第三,开发者也可以在平台上自己部署一个工具。


由于时间关系今天就和大家分享到这里,如果想要了解更多关于灵雀云在各个行业的产品实践,可以会后交流,谢谢大家!

Cloud Native相关的应用增长超过了200%

Zangying2005 发表了文章 • 0 个评论 • 1306 次浏览 • 2018-09-11 10:35 • 来自相关话题

每两年进行一次的CNCF调查洞悉了IT社区对云原生技术应用的认知变化。这已经是CNCF第六次关注调查容器化管理市场的热度。 #关键卖点 1. 自2017年12月以来,CNCF项目在生产环境应用平均增长超过200%,所评 ...查看全部
每两年进行一次的CNCF调查洞悉了IT社区对云原生技术应用的认知变化。这已经是CNCF第六次关注调查容器化管理市场的热度。
#关键卖点

1. 自2017年12月以来,CNCF项目在生产环境应用平均增长超过200%,所评估的项目数甚至达到了372%的增长。
2. 自2017年12月以来,受访者中的大部分都使用了类似AWS Lambda(70%) 的平台服务。这使得无服务器技术的应用不断增长,增幅达到22%。
3. 云原生技术的3大优势为更快速的部署时间,改善弹性和云可移植性。
4. 5000员工以上规模的企业受访者中,40%的企业在生产环境中部署了Kubernetes。

#调查方法和受访者情况
这是迄今为止收到过最多的调查回复,共有2400人有效参与了调查,受访者主要来自北美(40%)和欧洲(36%)。均为研发人员或IT相关的角色,分布情况如下:

1. 研发人员:49%
2. 运维人员:36%
3. IT经理:11%
4. 研发经理:14%

大多数受访者都是来自于员工规模超5000人的公司,这使得本次调查的结果更偏向于在企业中CNCF技术项目的使用。参与者排名靠前的行业是科技(22%)、软件(22%)、金融服务(9%)和电信(8%)。

本项调查是用英文进行的,中文版的调查目前还正在进行,结果将于今年晚些时候公布。你可以通过下图了解调查人群的详细统计信息:
1.jpg

#应用开发环境的变化
在本次最新版的调查问卷中,我们额外添加了发布方面的问题,以便更深入地了解公司如何管理他们的软件开发周期。微服务架构的好处之一是灵活部署的能力,从而允许公司根据需要尽可能频繁的进行应用发布。在微服务之前,典型的发布管理中,应用发布频率要低得多,通常是一年一两次左右。本次调查中,这一点变化突出,除发布频率外,受访者发布周期的各种发布占比相当均匀:

1. 每周发布:20%
2. 每月发布:18%
3. 每天发布:15%
4. 临时发布:14%

应用发布频率:
2.jpg

上述的大多数应用发布都是采用自动化处理(42%),使用混合方法发布的受访者占25%,还有27%的受访者使用手动发布。随着自动化发布的增长,管理CI/CD通道的工具也越来越流行,其中Jenkins是标杆性的工具(70%),其次是Terraform(27%)和定制脚本(26%)。

应用发布方式:
3.jpg

此外,在代码检查频率方面,67%的受访者每天多次检查,每周检查几次为28%,每月检查几次的为6%。

至于服务器数量规模(包括VMs,裸机器等),相较于在2017年12月的那次调查数据,我们看到5000+以上规模的受访者有小幅增长, 由14%上升到17%;6-20台机器的受访者,从18%下降到16%;21-50台机器的受访者的占14%,51-100台机器的受访者占11%。

平均服务器数量分布:
4.jpg

#云的应用情况
企业用云的数据分布情况是:自建数据中心占比64%,私有云占比50%,还有77%的企业采用了公有云的方案。

所采用的数据中心类型:
5.jpg

在采用容器化服务方面,大多数受访者公司都部署在AWS平台上(69%降至63%)。紧随其后的依次是本地数据中心部署(从51%降至43%)、谷歌云平台(39%降至35%)、微软Azure(从16%升至29%)、VMware(24%)和OpenStack(从22%降至20%)。括号内数据为相较于上次调查的数据。

容器化服务所部署的环境:
6.jpg

上述数字表现延续了我们在去年看到的趋势,但存在两个显著变化。首先是自有数据中心部署容器较2017年12月的51%下降到了43%,这很可能是由于私有云的使用增加所导致的。其次,这是我们第一次在这些调查结果中看到在VMware上广泛部署容器服务,在2017年12月的调查中,部署于VMware平台的仅仅为1.2%而已。
#容器化服务数量的增长情况
73%的受访者在生产环境采用容器化服务,剩余的27%表示计划在以后采用这项技术。这个数据在17年12月的调查分别是75%和25%。当前在POC环境采用容器化的受访者有89%,而用于测试环境和开发环境的分别是85%和86%。

容器所用于的环境类型:
7.jpg

公司所运行的容器数量也同比基本保持稳定,运行容器少于50个的占29%,50 -249个的为27%,250-999个的为17%,运行的容器数量超过5000个的为15%。和上次的数据对比,使用容器数不到50的公司增长明显,从2017年12月的23%上升到29%,而容器数在250-999的公司数量略有减少,从22%下降到17%。

企业所运行的容器数量分布:
8.jpg

在容器管理工具方面,Kubernetes以83%的受访者采用稳居第一。其次是Amazon ECS 占24%,Docker Swarm占 21%,Shell Scripts占20%。2017年12月同类型数据分别是77%,18%,17%和12%,存在明显的增长趋势。

容器的管理工具类型分布:
9.png

#Kubernetes
58%的受访者在生产环境中采用了Kubernetes。同时,42%的受访者正在为以后应用进行评估。而在人员规模5000以上的企业中,有40%的受访者在生产环境中使用了Kubernetes。

在生产环境中,40%的受访者运行了2-5个Kubernetes集群,运行1个集群的有22%,6-10个集群的有14%,运行集群数超过50个的受访者公司为13%(2017.12数据为9%)。

在Kubernetes所运行的平台环境方面,51%的受访者运行在AWS(上期数据为57%),企业自有数据中心服务器有37%(上期数据为51%),谷歌云平台从上期的39%下降到了32%,微软Azure从23%降至20%,OpenStack从22%降至16%,然而,运行在VMware平台上的却从1%大幅升至15%。以下图标展现了受访者的Kubernetes所部署的平台和容器所部署平台的对比。

Kubernetes环境 vs 容器环境:
10.jpg

当采用本地部署时,大多数受访者都趋向于选择的环境和所选比例为:Minikube(45%),Docker Kubernetes(39%),on prem Kubernetes installations(30%)。

此外,我们还问询了受访者在管理应用程序的各个方面所采用的工具:
##打包工具
首选的打包工具是Helm,占比68%,其次是Kubernetes内置的打包功能。
##自动伸缩技术应用
自动伸缩的应用情况,64%的受访者采用了自动伸缩无状态应用,其次是Java应用(45%),然后是任务/队列处理应用(37%)。未采用自动伸缩技术的受访者,可能是还没有这个功能的应用意识或者不希望在目前对自有的工作负载采用自动伸缩技术。
##入口提供方
Kubernetes的入口提供方应用最多几位依次是:Nginx占比64%(上期数据57%),HAProxy占29%,F5占15%(上期数据11%)和Envoy占比15%(上期数据9%)。
##向集群外暴露服务
受访者向集群外(如internet或其他虚拟机)暴露服务的首要方式是通过负载均衡器(67%)。其次是L7 ingress(39%)和集成第三方负载均衡器提供33%。
##Kubernetes内组织团队间隔离
在Kubernetes内部,受访者进行多个团队间的隔离,使用最多的技术是命名空间(Namespaces)占比71%,其次是独立的集群(51%),仅仅采用标签的为(15%)。
##隔离Kubernetes内的应用
受访者进行Kubernetes应用隔离采用命名空间(Namespaces)占比78%,其次是独立的集群(50%),仅仅采用标签的为(21%)。
#生产环境中的云原生项目
云原生项目有哪些优势呢?受访者提及最多的3个理由是:

1. 更快速的部署时间
2. 改善弹性
3. 云可移植性

用于生产环境和评估中的CNCF云原生项目分布情况:
11.jpg

数据显示,许多CNCF项目在生产环境中的使用较我们上一次的调查有显著的提升。例如容器服务由18%升至45%;CoreDNS由7%升至36%;Envoy由4%升至24%;Fluentd由38%升至57%; gRPC由18%升至45%;Jaeger由5%升至25%,Linkerd由3%升至16%,以及OpenTracing由8%升至21%。就平均值看,CNCF项目在生产环境的应用较上一次调查有200%以上的提升。

受访者正在评估中的CNCF项目数同样较上期调查增长明显。例如容器服务由22%升至55%;CoreDNS由14%升至64%;Envoy由26%升至74%;Fluentd由22%升至43%; gRPC由16%升至55%;Jaeger由15%升至75%,Linkerd由15%升至84%,以及OpenTracing由25%升至80%。就平均值看,CNCF项目评估较上一次调查增长了372%。

CNCF新开发的项目也有很高的关注度,受访者重点评估的项目如SPIRE(94%)、TUF(93%)、Open Policy Agent(92%)、Vitess(92%)和SPIFEE(92%)等,关注比值都非常高。
#使用和部署容器的挑战
云原生技术改变了企业设计,构建应用的方式,挑战也是无法避免的。受访者反馈所面临的挑战主要有:

1. 研发团队的文化转变:41%
2. 复杂度:由35%提高到40%
3. 培训不足:40%
4. 安全性:由43%降到38%
5. 监控:由38%降到34%
6. 存储:由41%降到30%
7. 网络:由38%降到30%

对于这些挑战,有两个显著的变化。首先,本次调查,虽然这是我们第一次明确询问开发团队的文化变化,但它却被认为是使用和部署容器中的最大挑战。其次,缺乏培训是问卷选项以外的挑战。尽管CNCF在过去的一年里在Kubernetes培训上进行了重度投入,措施包括免费和付费课程,以及为Kubernetes管理员和应用程序开发人员提供认证。因此,随着项目的发展,我们将继续投入更多的培训资源开展新项目。

其余的主要挑战与我们过去的调查基本是一致,但是随着有更多的资源和工具用于解决面临的问题,这些选项的被选比例在持续下降。

使用和部署容器所面临的挑战:
12.jpg

同时,有一个有趣的现象是,随着云原生存储项目应用的增长,存储和网络作为挑战的被选比例呈下降趋势。云原生存储项目的应用情况如下:

1. Rook:生产环境应用的受访者占比11%,正在评估中的受访者占比89%(上期调查29%)。
2. Minio:生产环境应用的受访者占比27%,正在评估中的受访者占比73%(上期调查28%)。
3. OpenSDS:生产环境应用的受访者占比16%,正在评估中的受访者占比84%(上期调查分别为7%和14%)。
4. REX-Ray:生产环境应用的受访者占比18%,正在评估中的受访者占比82%。
5. Openstorage:生产环境应用的受访者占比19%,正在评估中的受访者占比81%(上期调查分别为31%和36%)。

企业所采用的云原生存储项目类型:
13.jpg

#Serverless的增长
在本次调查中,我们仍然持续跟进无服务器技术的增长情况。38%的组织当前在使用无服务器技术(上期同类型数据为31%)。其中32%是采用支持平台,6%是采用安装的软件实现。

与上期数据的41%相比,仍有37%的受访者没有采用无服务器技术,但有另外的26%的受访者表示将在未来的12-18个月内计划采用。

选用最多的可安装的无服务器平台有:

1. Kubeless:42%,上期数据2%
2. Apache OpenWhisk:25%,上期数据12%
3. OpenFaas:20%,上期数据10%

企业组织所采用的无服务器平台分布:
14.jpg

选用最多的公有云无服务器平台是:

1. AWS Lambda服务:70%
2. Google Cloud Functions:25%,上期数据13%
3. Azure Funcitons:20%,上期数据12%

企业组织所采用的公有云无服务器平台分布:
15.jpg

随着无服务器技术的使用增长,受访者对无服务器技术项目CloudEvents表现出了浓厚的兴趣,80%的受访者为我们评估了这个项目,还有21%的人在生产中使用它的技术。CloudEvents是CNCF无服务器工作组所组织的成果,它旨在创建一个以通用的方式描述事件数据的规范。
#如何学习更多的技术知识?
对于刚刚涉足云原生项目并期望学习更多相关知识的初学者,以下是受访者学习云原生技术的首要几种方式:
##文档
20%的受访者使用文档来学习云原生项目,这也是本次调查引用的首要资源。例如,SIG-Docs帮助维护的大量Kubernetes详细文档。这其中包括了从如何开始使用某个特定功能到以贡献者身份参与项目的最佳方式等等的所有内容。每个CNCF项目在其网站上都有大量的文档,可以点击https://www.cncf.io/projects/获取。
##KubeCon + CloudNativeCon
12%的受访者选择参加KubeCon + CloudNativeCon,以了解更多他们正在使用的技术。KubeCon + CloudNativeCon集中了所有CNCF项目,并将来自开源云原生社区的技术大咖聚集一堂,以进一步推动原生云计算的发展。这项活动每年在欧洲、中国和北美各举行一次。
##CNCF网站和在线研讨会
12%的受访者会访问CNCF网站和参加在线研讨会。CNCF.io是所有云原生项目的一个主要来源,提供包括近期活动、培训、认证、博客等等诸多主题的信息。

CNCF在线研讨会每周二上午10点到11点(PT)举行。您可以查看近期日程,并查看往期在线研讨会的录音和幻灯片。
##聚会和当地活动
有11%的受访者会通过参加聚会和当地活动来了解云原生技术。CNCF在我们会员体系下主办了149个聚会,活动遍布33个国家,涉及会员超过76000人。你可以点击这里查看的你所在地的聚会。

您可以点击这里查看近期CNCF和世界各地云原生社区的活动,包括从会议到路演等等。
##推特
10%的受访者通过Twitter获取信息。通过Twitter账号,CNCF发布项目、社区和基金会的新闻。读者可以关注自己所喜欢的云原生项目,点击这里可以找到这些Twitter列表(和相关的社交账户)。

学习云原生技术的途径:
16.jpg

#致谢
非常感谢所有参与我们调查的人。我们希望在上海的KubeCon + CloudNativeCon(2018年11月12-15日)和西雅图(2018年12月11-13日)见到您。

请继续关注我们今年晚些时候公布的中文调查结果!

你亦可在此查阅过往的调查结果:

March 2018: China is Going Native with Cloud
December 2017: Cloud Native Technologies Are Scaling Production Applications
June 2017: Survey Shows Kubernetes Leading as Orchestration Platform
January 2017: Kubernetes moves out of testing and into production
June 2016: Container Survey
March 2016: Container survey results

原文链接:CNCF Survey: Use of Cloud Native Technologies in Production Has Grown Over 200%(翻译:易理林)

云原生应用的10大关键属性

cleverlzc 发表了文章 • 0 个评论 • 1256 次浏览 • 2018-08-12 10:12 • 来自相关话题

【编者的话】云原生是一系列基于容器、微服务、DevOps工作流以及弹性基础设施的集合,能够更加高效、可靠和敏捷的交付应用价值,本文的10个关键属性将带领你更深入的理解云原生应用。 云原生是一个用于描述基于容器环境的术语。云原生技术用于 ...查看全部
【编者的话】云原生是一系列基于容器、微服务、DevOps工作流以及弹性基础设施的集合,能够更加高效、可靠和敏捷的交付应用价值,本文的10个关键属性将带领你更深入的理解云原生应用。

云原生是一个用于描述基于容器环境的术语。云原生技术用于开发构建应用程序,这些应用程序使用容器打包并且将被部署为微服务,通过敏捷DevOps流程和持续交付工作流,在弹性基础设施上进行管理。

运维团队将手工管理传统应用程序的基础设施资源分配,而云原生应用程序部署在抽象底层计算、存储和网络原语的基础设施上。处理这种新型应用程序的开发人员和运维人员不会直接与基础设施提供者公开的应用程序编程接口(API)交互。相反,编排引擎根据DevOps团队制定的策略自动处理资源分配。控制器和调度器是编制引擎的重要组件,它们处理资源分配和应用程序的生命周期。

像Kubernetes这样的云原生平台暴露了一个扁平网络,该网络覆盖在云提供商的现有网络拓扑和原语上。类似地,通常抽象本地存储层以暴露与容器集成的逻辑卷。运维人员可以分配开发人员和资源管理员访问的存储配额和网络策略。基础架构的抽象不仅解决了跨云环境的可移植性需求,还让开发人员利用新兴模式来构建和部署应用程序。无论基于物理服务器或虚拟机,私有云还是公共云的底层基础架构,业务流程管理器都将成为部署目标。

Kubernetes是当代运行云原生应用程序的工作负载的理想平台。它已经成为云的事实上的操作系统,就像Linux是底层机器的操作系统一样。只要开发人员遵循设计和开发软件作为一组包含云原生应用程序的微服务的最佳实践,DevOps团队就能够在Kubernetes中打包和部署它们。以下是开发人员在设计云原生应用程序时应牢记的云原生应用程序的10个关键属性。


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

原文地址:10 KEY ATTRIBUTES OF CLOUD-NATIVE APPLICATIONS (翻译:刘志超)

CNCF在PromCon上宣布:Prometheus是继Kubernetes之后的第二个CNCF“毕业”项目

wise2c 发表了文章 • 0 个评论 • 1143 次浏览 • 2018-08-10 15:12 • 来自相关话题

SAN FRANCISCO, Calif., August 9, 2018 - 管理Kubernetes和Prometheus等云原生开源技术的 Cloud Native Computing Foundation(CNCF)在PromCon(年度Prometh ...查看全部
SAN FRANCISCO, Calif., August 9, 2018 - 管理Kubernetes和Prometheus等云原生开源技术的 Cloud Native Computing Foundation(CNCF)在PromCon(年度Prometheus会议)上宣布Prometheus是继Kubernetes之后的第二个CNCF毕业项目。在CNCF管理的项目中,要从’孵化’转为’毕业’的成熟水平,项目必须被社区广泛的采用,有结构完整的治理过程文档,以及对社区可持续性和包容性的坚定承诺。

“自2012年成立以来,Prometheus已成为构建现代云原生应用程序的企业首选的开源监控工具之一,”CNCF首席运营官Chris Aniszczyk表示。 “自从被接受成为CNCF的第二个管理项目以来,Prometheus已经培养了一个活跃的开发者和用户社区,让TOC充满信心地毕业了这个项目。作为其成熟的证明,我们很高兴看到Prometheus社区推出OpenMetrics,它采用Prometheus exposition format,并努力将其演变为事实上的行业规范。“

毕业微信图片_20180810115617.png


Prometheus项目于2012年在SoundCloud创建,并于2016年5月捐赠给CNCF。该项目自进入CNCF的’孵化’水平以来已有包括主要版本和次要版本的30个正式版本发布。

“作为该项目的主要支持者,创始人和最终用户,SoundCloud祝贺Prometheus团队在此项目中的成就,”SoundCloud基础设施和核心工程副总裁Jake Maizel说。 “Prometheus帮助改进了许多公司的监控和警报实践,很高兴看到这个项目在官方毕业后进一步发展。恭喜所有参与者!“

Prometheus现在拥有近20个活跃的维护者,超过1,000个贡献者和超过13,000个来自其不断增长的用户群的commits,其中包括ShuttleCloud,Datawire,DigitalOcean,Weaveworks,ShowMax,iAdvize和Uber等。除此之外,Prometheus还与CNCF的首个托管项目Kubernetes集成,以支持服务发现和动态调度服务的监控。

“自从成为CNCF的一部分以来,Prometheus已经成为现代基础设施堆栈的重要组成部分,并帮助塑造了组织监控关键应用程序的方式,”Prometheus项目联合创始人Julius Volz说。 “我们非常自豪能让Prometheus毕业,我们期待与CNCF合作,以维持和发展我们的社区。”

为了正式从孵化进入状态毕业,该项目还采用了CNCF行为准则,执行了独立的安全审计,并确定了自己的治理结构,以发展社区。此外,Prometheus于2017年6月23日完成并获得核心基础设施倡议的最佳实践徽章。 CII徽章展示了Prometheus项目对代码质量和安全最佳实践的持续承诺。

原文链接:Cloud Native Computing Foundation Announces Prometheus Graduation

Kubernetes会被它厚重的复杂度压垮吗?

wjun 发表了文章 • 0 个评论 • 1822 次浏览 • 2018-06-07 13:37 • 来自相关话题

【编者的话】Paul Dix在Kubernetes如日中天的今天写下了这篇文章。粗看是有点不太合时宜,可能不会在如今喧嚣的Kubernetes风潮中溅起一丝涟漪。但恰恰言简意赅的点出了很多平台和社区方方面面的问题,也给出了建议。作为一个已经在多个云端平台和企业 ...查看全部
【编者的话】Paul Dix在Kubernetes如日中天的今天写下了这篇文章。粗看是有点不太合时宜,可能不会在如今喧嚣的Kubernetes风潮中溅起一丝涟漪。但恰恰言简意赅的点出了很多平台和社区方方面面的问题,也给出了建议。作为一个已经在多个云端平台和企业IDC环境落地Kubernetes的团队,我们感同身受文中提到的阵痛期以及对Kubernetes未来的关切。同样希望社区和平台贡献者能看到这些观点,将Kubernetes变得对开发者更加友好,从而让生态更健康,让开发者能把优势资源更多的集中在去发布商业价值的本份上。

思考:服务好应用开发者的重要性

几周之前,我参加了欧洲区的KubeCon并讲了话。这是一次有将近4700人参加的空前的盛会。这让我想起了2014年那次在巴黎的OpenStack峰会。如出一辙的疯狂宣传,供应商的各种秀,以及在主会场的公共区域举行的由开发者组织的大型派对。然而,我感到了这整个场面之后的隐忧:每个和我聊的人不是运维就是SRE(译者:网站可靠性工程师)。我们的应用开发人员在哪里?他们不应该正是这整个复杂的基础架构要服务的人吗?社区真正将有需求的使用者联系起来了吗?进而它让我疑虑:是不是Kubernetes过于复杂了?它会被它厚重的复杂度终结吗?它会跟OpenStack当初一样在2014年后逐渐消失吗?

好吧, 我承认我演的有点过了, 但我要说的是,在我看来这根本不可能发生。Kubernetes有一些优势是OpenStack从来不具备的。首先,Kubernetes已经更具扩展性,因此,所谓能在千万级服务器规模的环境中调度的集群,它能使其梦想成真。其次,三大云供应商(AWS、Azure、Google Cloud)已经开始提供在其之上托管Kubernetes的各种服务(译者:EKS、AKS、GKE)。在短短四年内,Kubernetes已经将自己的地位提高成为云服务商和传统IT基础架构的通用平台。但是,复杂度问题依然让人头疼不已。
# 大部分开发者没有遇到和Google一样的扩展性问题
开发Kubernetes的初衷是为了解决Google公司在扩展性上面临的复杂度以及各种问题。你可能期望这个基础架构是可自愈的,可以横向扩展的,并能支持申明式编程(即infrastructure as code, 基础设施即代码)。然而,对绝大部分的应用和应用开发者来说并没有这样的世界观。大部分应用要么是在用更加现代和高阶的术语来描述它们所谓的扩展性(比如项目的部署规模和用户量)要么还只是刚开始调研自己的市场定位。

那些完全不会有扩展性问题的应用, 通常不需要系统具备可自愈可横向扩展,来徒增复杂度。只要简单地考虑使用单个节点的数据库服务和应用服务,就能够处理你的业务。而且,如果有人做些常规排错的运维,让它能够保持99.5%的可用性,那就已经满足了很多应用和业务的需求。建一套分布式系统所带来的无谓复杂度,以及在投放市场前所开销的额外时间,都完全不值得去纠结和投入。

对于那些全新的应用,他们最大的风险是在于找不到自己的市场定位。就是说,他们都部署好了但没人用。这些代码最终被丢弃,因为,它做出来了但没人要。这样的情况代表了绝大部分的已经写好的应用。我个人就把职业生涯大量的时间用在了寻找“恰当的代码匹配恰当的功能”。只有当你发现了对的应用场景和功能需求,你才去扩展你的应用。否则就是拔苗助长(译者:出自“premature optimization is the root of all evil”)。

我看到Kubernetes的问题在于,在它上面做一个项目,其初期的认知负荷太高。那堆你需要做和考虑的事阻碍了你快速开始和迭代一个项目。在项目初期,实现需求的效率和迭代速度是非常重要的因素。我看Heroku就有个很好的开发模式。你已经有了个托管的Postgres数据库,你只需要git push把代码部署上去并发布。几乎没什么需要去纠结。它也许不支持无限扩展,也有可能成本比较高,但至少你可以等这些真成了你的痛点之后再去操心。

简而言之, Kubernetes让简单的事变难了,也让难的事变得有可能(出自Tom Wilkie一句用在另个项目上的话)。如果Kubernetes真的要成功,它必须要让项目启动期变得更加简单。它必须要降低应用开发者的认知负荷。如果在某些时候,开发者有需要去学Kubernetes的晦涩概念的细节,那也行。因为项目做大了,每件事都会复杂和有难度。但一个成功的开发平台不会在还没必要的情况下,就把那些决策负担和认知压力放到开发者的面前。这话David Heinemeier Hansson(译者:DHH,Ruby on Rails的作者)在2018年的RailsConf的“JIT Learning" 中讲过

说到DHH, 这里我想用Rails作为例子。首先我想来探讨的是:为什么Rail那时会那么火?不是因为Ruby的流行(它曾是一个来自日本并不为人知的语言),也不是因为Rails和Ruby曾是服务动态web页面的框架中响应速度最快的。而是因为它大幅提高了开发者的工作效率。当DHH谈如何在15分钟内搭建博客网站的时候,那些动辄要用数周甚至数月才能完成相同事情的Java和.NET开发人员都惊讶不已。开发者使用Rails是因为他们能将新功能更快的发布给用户,这才应该是所有这些应用框架和系统架构的根本目的。

Rails做的另一个了不起的事是,它会为你开发的应用程序提供了一个命令行工具并帮你去生成scaffolds和项目需要的其他组成部分。这就让开发人员的事情变得简单,他们没必要在项目一开始就要去做成吨的决策。应用程序的代码该如何组织,数据模型该放哪, asset pipeline是什么样,怎么做数据库迁移,以及其他很多为你而完成的任务和决策。如果你想一试框架限定外的东西,也行的,但你不是非得在一开始就去考虑。

我想Kubernetes也可以从Rails的这些各种各样的生成器中获得灵感。事实上Kubernetes里已经有了特定资源的生成器,但还远远不及我想要的。如果对不同类型的应用能有相应模板就会很好。哪怕只有个最通用的模板也好。把关系数据库,应用层,缓存服务器,消息队列,以及worker节点池组合到一起,就能把其中的复杂度封装, 从而满足90%或更多应用在开发时的需求。如此简单的一个结构能够横向扩展进而支撑一个难以置信的请求数量和复杂度。一个模板或者生成器就能把所有东西变得开箱即用,还帮你把这些适用于Kubernetes上的资源和代码组织的好好的,对开发者而言这将会非常有帮助。

比如,要是有一个通用元素的Scaffold生成器,事情就会变得很棒。要个MySQL数据库?像这样来个命令就行:
kubectl scaffold mysql --generate

原本创建一个stateful set,service以及其他的必须品都要走段很长的路。现在只要一个简单命令就能在Kubernetes环境里部署一个scaffold,并且,你还能只通过几行命令就能有一个可以直接上生产的数据库。如法炮制,各种流行的应用框架,message brokers,以及其他我们能想到的东西都能被创建出来。

也许operators与Helm Chart的组合就能搞定上面说的,但我觉得这不能算完。总不能强迫开发者还要再去学两个Kubernetes外的东西吧。虽说只是多学一些新语法和装个新的命令行工具,那也是额外费心费力的事。这样的功能应该是Kubernetes的“一等公民”,是Kubernetes拥有“开箱即用”般体验的组成部分。他们要能够通过kubectl就可以用起来。
# CNCF项目版图很大而且越来越大
这不是Kubernets特有的问题,而是CNCF项目版图就很巨大。这就使得KubeCon和CNCF的峰会被极度的碎片化。光在峰会的不同场次就有14个宣讲。而作为开发人员,下图这些工具中哪些是我项目需要的呢? 来看看这张项目版图吧:
cloud-native-landscape.png

好吧,看了也没办法搞清楚。更好的方式, 是把预先就挑好的工具提供给应用开发人员,让他们先按照简便方法走,如果他们能想到去用不同的工具,那更好,但是他们不需要一开始就非要去考虑。CNCF正在激增的复杂度和广度有可能会分散人们聚焦在Kubernetes的注意力也会弱化它作为开发平台的定位。对此我也不知道该怎么说,或者讲得夸张点,仅从我个人角度来看,现在这峰会俨然就是部工具为主角的小电影。试问,你都能把整个职业生涯消耗在去学如何为平台开发新的工具上了,还费什么劲去解决用户的问题?

怎么强调都不够:基础架构只是一个帮助开发者解决真实用户问题的工具。它应该能帮助开发者优化效率和提高发布的能力。在这点上能做得好的开放平台就能胜人一筹。
# 所需知识
有时,开发者需要对基础架构的各种工具有更深的了解。像大部分AWS上的开发者对那个云上的组件比较熟悉,就跟GCP或Azure上的开发者熟悉他们云上的组件一样。让Kubernetes作为项目的基础架构也许会更有前景,因为开发者只学这一种范式就能把它和项目铺上任何公有云或者私有云。

这点也许就是我们选择Kubernetes的原因,把它作为我们新开发的2.0版云服务的基础架构。可学习曲线是明摆在那儿的,所以我们开发团队还在热身。为了达到目的,我让整个研发团队必读Kubernetes : Up and Running这本书。

我希望学习曲线是相对温和的, 而Kubernetes作为一个生态,要去拥抱开发者的需求才能真正成功。通过提供面向用户的应用来解决客户问题,在这样一个服务过程中,说到底,基础架构只是一个支持型的工具。“激发应用开发者的效率”是最好的也是最明确能让一个平台被广泛使用和接受的正道。

原文链接:Will Kubernetes Collapse Under the Weight of Its Complexity? (翻译:万俊)

=============================================================
译者介绍
万俊,MicroFocus上海软件研发部经理。

BoCloud博云获得CNCF Kubernetes服务提供商认证

博云BoCloud 发表了文章 • 0 个评论 • 794 次浏览 • 2018-05-29 08:50 • 来自相关话题

近日,BoCloud博云正式获得 CNCF 和 Linux 基金认证的 Kubernetes 服务提供商资质(KCSP),此认证证明BoCloud博云在 Kubernetes 社区从事活动(包括积极贡献代码)、支持企业最终用户的商业模式、以及将工程师派驻客户现 ...查看全部

近日,BoCloud博云正式获得 CNCF 和 Linux 基金认证的 Kubernetes 服务提供商资质(KCSP),此认证证明BoCloud博云在 Kubernetes 社区从事活动(包括积极贡献代码)、支持企业最终用户的商业模式、以及将工程师派驻客户现场这三面具有相应的技术实力。


默认标题_官方公众号首图_2018.05_.28_.png



KCSP 计划(全称 Kubernetes Certified Service Provider)是由 CNCF 和 Linux 基金会发起,旨在对在 Kubernetes 的企业应用中拥有丰富经验的服务商进行认证。而被认证的 Kubernetes 供应商均可提供 Kubernetes 支持、咨询、专业服务和培训。同时,KCSP 计划可以确保计划采用 Kubernetes 的组织得到更加专业的支持和服务,确保可以支持其生产和运营方面的要求。

根据 CNCF 相关规定,KCSP 计划要求申请企业除了积极参与 Kubernetes 社区活动,长期做出积极贡献之外,更为关键的是企业的商业模式支持为客户提供各种 Kubernetes 技术支持服务,包括将工程师派驻客户现场,并且企业需要至少三名工程师通过Kubernetes管理员(CKA)考试认证。


TIM截图20180528142428.png



“KCSP 的创始成员代表 Kubernetes 生态系统趋于成熟,还表明 Kubernetes 已准备好广泛用于大大小小的企业。随着
> Kubernetes 不断发展,企业对于专家服务和支持这方面的要求也随之提高。与 KCSP
> 合作的企业可以确信,他们选择合作的商业伙伴拥有帮助在 Kubernetes 方面取得成功所需的培训服务和技能。”
>
> ——云原生计算基金会的执行董事丹·科恩(Dan Kohn)



BoCloud博云成立于2012年,是国内云计算开源软件商业化服务商的领导者,为企业级客户提供私有云、混合云、智能化运维系统、大数据基础设施的咨询、建设、维护、升级服务,帮助企业在关键运营场景中实现数字化转型,提升企业主业的生产率。凭借对客户业务流程和应用管理难点的深刻理解,以及对云计算前沿技术的持续跟踪投入,BoCloud博云形成了系列产品以创新云技术支撑企业核心业务,构建数字化高效 IT 系统。公司自主研发的多项软件产品,包括企业级 PaaS 容器管理平台 BeyondContainer、统一云管平台 BeyondCMP、自动化运维产品 BeyondBSM等,已在金融、电力、石油、政务、IDC、航空等行业领域的生产系统中落地实施,为国有电力公司、股份制银行、大型支付机构等标杆行业客户的重要生产系统提供服务。

此次成为 CNCF 认证的 Kubernetes 服务提供商之后,BoCloud博云将继续支持云原生技术,在推动云计算开放性、标准化方面贡献自己的力量。同时,也将成为企业用户在 Kubernetes 领域内合作的最佳合作伙伴。

Cloud Native Computing Foundation,于 2015 年 7 月成立,隶属于 Linux 基金会,初衷围绕“云原生”服务云计算,致力于维护和集成开源技术,支持编排容器化微服务架构应用。