Donald

Donald 查看完整档案

填写现居城市  |  填写毕业院校  |  填写所在公司/组织填写个人主网站
编辑

布道者,Linux基金会(LFAPAC)
开发者布道者,云原生计算基金会(CNCF)

个人动态

Donald 发布了文章 · 11月25日

CNCF宣布etcd毕业

在过去的12个月中,广泛使用的数据存储解决方案已经有200位不同的贡献者

旧金山,加利福尼亚州--2020年11月24日--CNCF®(云原生计算基金会,Cloud Native Computing Foundation®),旨在为云原生软件构建可持续的生态系统,今天宣布etcd毕业。从孵化到毕业阶段,etcd已经被越来越多的人采用、拥有开放的治理过程、特性成熟度,以及对社区、可持续性和包容性的强烈承诺。

etcd是分布式的、可靠的键值存储,它提供了可靠的方式来存储需要由分布式系统或机器集群访问的数据。任何复杂的应用程序,从简单的web应用程序到Kubernetes,都可以从etcd读取数据并将数据写入其中。该项目于2013年在CoreOS创建,并于2018年12月作为孵化项目加入CNCF。

“etcd项目是Kubernetes内部的关键组件,其他许多项目都依赖etcd来实现可靠的分布式数据存储。”CNCF CTO Chris Aniszczyk说:“我们对etcd在规模上持续达到的里程碑和在最近的保安审计上的成熟处理方式留下深刻印象,我们期待其作为毕业项目培育社区。”

etcd被许多公司用于生产,包括阿里巴巴、亚马逊、百度、思科、EMC、谷歌、华为、IBM、红帽、Uber、Verizon等,以及Kubernetes、CoreDNS、M3、Rook和TiKV等项目。

“etcd作为我们在Placement Driver中的元数据存储,以及我们在生产中对Raft实施的灵感,已经被证明是TiKV和TiDB的一个很好的选择,可以确保跨TiDB集群的数据一致性和高可用性。”PingCAP联合创始人兼CTO Ed Huang说:“能参与到它的毕业旅程中来,我们感到非常自豪和高兴。未来我们也愿意更多地参与到它的生态系统开发中去。”

维护者团队目前由10名成员组成,代表的公司分布良好,包括阿里巴巴、亚马逊、Cockroach Labs、谷歌云、IBM,以及红帽。自从etcd成为孵化项目以来,已经增加了三位新的维护者。在过去的12个月里,有200名不同的贡献者编写了pull request。

“经过七年的发展,etcd已经成熟,成为许多分布式系统的基石。它成功的最重要的决定是加入了CNCF社区,并在许多组织中培养维护人员,”Xiang说,他是etcd维护者兼CNCF TOC成员,也是阿里云工程总监。“我们很高兴看到它在CNCF毕业。etcd是支撑阿里云的容器服务和许多其他关键服务的核心。我们期待着在未来提高其稳定性、可靠性和性能。”

由CNCF赞助的第三方安全审计是在2020年7月通过Trail of Bits对etcd v3.4的最新主要发行版进行的。根据报告,etcd代码基是一个成熟的、被广泛采用的产品,在etcd的核心组件中没有发现明显的问题。在etcd网关中发现了一个严重的问题,该团队通过修复和向后移植到etcd支持的版本中解决了这个问题。

该项目还在2020年1月通过了Jepsen测试,该测试分析了开源分布式系统,以检查它们是否实现了一致性保证。结果显示了项目功能的成熟度。Jepsen团队还指出了一些需要改进的地方,并由etcd团队实现。

“从一开始,etcd就被设计为简化一致存储操作,这使得它对于像Kubernetes这样的容器编排系统的使用具有吸引力。etcd作为Kubernetes的控制平面存储被证明是非常合适的,两个项目已经一起成长和成熟,”etcd维护者兼谷歌云软件工程师Joe Betz说。“我们很高兴看到etcd在可靠性、可扩展性和质量方面的努力在本次毕业上得到CNCF的认可。今天的公告是etcd的成熟和它对生产工作负载的准备就绪的证明。”

“今天etcd毕业的重要里程碑,没有社区的工作和CNCF的支持,是不可能完成的。”IBM开放技术高级软件工程师兼etcd维护者Sahdev Zala说:“etcd在提供分布式键值存储方面发挥着关键作用,该存储具有高可用性,满足大规模Kubernetes集群的强一致性要求。”

“开源软件在很多方面为我们的生活提供了动力,”AWS Kubernetes总经理Bob Wise说。“从Linux到Kubernetes,各种规模的组织和各行各业的建设者们花费了大量的时间创建和维护项目,这些项目支撑了我们每天使用的互联网、电信、金融、交通、游戏、零售和医疗保健系统。etcd是其中一个重要的项目,我们很自豪etcd作为Amazon EKS的核心部分,并参与帮助这个项目成长和繁荣。我们是etcd毕业的热心支持者,并期待与etcd和其他CNCF项目合作,构建安全、可靠、强大和可扩展的开放源码软件。”

为了从孵化阶段正式毕业,该项目获得了CII最佳实践徽章认证,完成了安全审计并解决了漏洞,定义了自己的治理,并采用了CNCF行为准则

etcd背景

etcd是一个分布式的、可靠的键值存储,用于分布式系统中最关键的数据,关注于:

  • 简单:定义良好、面向用户的API(gRPC)
  • 安全:自动TLS与可选的客户证书身份验证
  • 快速:基准测试10,000写/秒
  • 可靠:使用Raft作合理分布

要了解更多有关etcd的信息,请访问:etcd.io

点击阅读网站原文


开始了!2020年CNCF中国云原生调查

问卷链接(https://www.wjx.cn/jq/9714648...


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
在这里插入图片描述

查看原文

赞 0 收藏 0 评论 0

Donald 发布了文章 · 11月24日

DevOps+无服务器=事件驱动自动化

北美KubeCon + CloudNativeCon虚拟大会赞助文章作者:Josh Berkus,Red Hat

云原生技术是否会取代较旧的DevOps工具,像Kubernetes取代配置管理?还是补充它呢?代替是种流行的说法,但是使用新技术来增强和重建旧技术更为有效。在我们的案例中,我们将说明如何使用Kubernetes、CloudEvents和Knative使Ansible更具可扩展性、分布性和有效性。

但是,为了理解这种方法,你必须首先摆脱关于无服务器是什么的流行想法。

无服务器:不仅仅是FaaS

在大多数情况下,无服务器被视为FaaS(Function as a Service,函数即服务)。虽然当今大多数正在实施的无服务器代码确实是FaaS,但这不是目标,而是进站。无服务器领域仍在发展。让我们一起去探索无服务器的发展趋势。

我们的行业始于我所说的“1.0阶段”,那时我们刚开始谈论或听到有关Serverless的内容,并且在大多数情况下,我们只是将其视为“函数”,即按需在短时间内运行的小段代码。AWS Lambda使得这种范例非常流行,但是它在执行时间、协议和本地开发经验方面存在其自身的局限性。

从那时起,越来越多的人意识到可以将相同的无服务器特性和好处应用于微服务和Linux容器。这将我们引向我所说的“1.5阶段”。这里的一些解决方案完全抽象了Kubernetes,通过位于其之上的抽象层(如Knative)提供了无服务器体验。通过向容器开放Serverless,用户不仅限于函数运行时,而且现在可以使用他们想要的任何编程语言。他们还可以利用容器的可移植性并转移工作负载,从而打破云提供商的锁定。

但是,我们的旅程的终点,是当我们发展无服务器实现以处理更复杂的编排和集成模式,以及某种程度的状态管理。在大多数情况下,无服务器意味着无状态的应用程序,但是现在正在创建许多解决方案,以帮助业务流程重新创建众所周知的集成模式,但以无服务器的方式。此外,当我们实现此“2.0阶段”时,无服务器实质上将成为你的平台即服务的另一功能,因为实际上大多数企业将运行无服务器和非无服务器工作负载的组合。微服务、单体或函数都作为容器运行,使我们的客户有能力在需要时选择最佳工具。

此2.0阶段无服务器的核心是什么?事件(Events和Eventing)。以最简单的形式,当有请求进入时,就需要执行任务。从事件和动作方面进行思考,揭示了使用无服务器方法发展基础架构和应用程序的广泛机会。这是迁移到事件驱动自动化(EDA)的驱动力,该驱动器比以前的模型更好地处理云的弹性、规模和响应性。EDA是无服务器,请求驱动的应用程序/函数扩展的核心,它具有强大的基础结构来生成和使用事件。

DevOps:不仅仅是配置

正如无服务器通常被误认为是FaaS一样,像Ansible这样的DevOps自动化平台经常被错误地定义为完全与配置管理有关。人们会忘记,DevOps的核心目标是使人类以前完成的任务自动化,以使其可重复和可扩展,并且自动化远比配置管理大。因此,尽管你当然可以使用Ansible之类的工具来管理配置,但它们能够执行范围更广的自动化任务。“使一切自动化”是项目的口号。

当开始将DevOps平台视为自动化工具,它们在云原生时代的持续适用性就变得更加明显。尽管我们可能已经完全改变了处理配置的方式,但我们并没有失去管理硬件、网络、外部系统、第三方API和安全策略并与之交互的需求。传统的DevOps工具已经具有处理所有这些问题的模块,而新的云原生工具通常没有。

事件驱动自动化

这向我们展示了旧的自动化与新的无服务器之间的一些清晰的集成点。无服务器平台侦听并路由事件;自动化平台接收命令或状态声明,然后执行工作。以最简单的形式,当请求进入时,需要执行任务。这是向事件驱动架构过渡的动力,事实证明,EDA可以解决许多前所未有的挑战。它使分布式应用程序的弹性和规模成为可能。

例如,我们可以设置一个队列来处理来自AWS账户的CloudWatch事件。由SQS数据馈送为CloudWatch生成的事件由Knative事件源转换为CloudEvents,而这些CloudEvents又可以通过队列放入Kubernetes上的Knative中。

该流水线允许工作流根据平台中的事件自动触发,例如发生某些网络事件,或者自动扩展到超过一定数量的节点,从而启动负载平衡器的自动重新配置。你还可以将团队策略应用于创建新的VPC或VM,并警告某人或在配置不足时自动删除它们。

使用此处演示的技术和标准,可以从多个云或本地平台上实现工作流自动化,然后你可以选择要在哪里处理这些事件。例如,如果你在另一个公有云或数据中心上有容量或访问问题,则可以使用它在一个公有云或数据中心上增加资源。开发人员甚至可以使用它来实现ChatOps。

此仓库此仓库中,有一些简单的示例可用于设置和使用带有Knative的Serverless和Ansible。

想像一下:

  • 支持案例已经具有工程师所需的所有必需信息,可以立即开始进行故障排除
  • 动态文档,你所拥有的信息在需要时准确无误
  • 与你所有基础架构的无缝集成,将最佳的容器和传统环境结合在一起
  • 自我修复的基础结构,事件可在其中进行故障排除Ansible Playbook,无需人工干预即可纠正问题

希望我们能帮助你了解将新的云原生技术和较旧的DevOps技术融合到单个事件驱动的架构中的可能性。可以利用新功能,而无需放弃对现有自动化的投资。只需将你的想法扩展到功能和配置之外,然后立即开始扩展自动化。

链接:

Knative-Ansible Github项目:

入门指南:

无服务器:

Cloud Events项目:

点击阅读网站原文


开始了!2020年CNCF中国云原生调查

问卷链接(https://www.wjx.cn/jq/9714648...


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

查看原文

赞 0 收藏 0 评论 0

Donald 发布了文章 · 11月24日

开始了!2020年CNCF中国云原生调查

CNCF云原生调查把脉社区,以便更好地了解CNCF项目和云原生技术的采用情况。

调查结果会载入报告和大家分享,突出我们在各个行业中观察到的新的变化趋势。

问卷链接:
https://www.wjx.cn/jq/9714648...

点击直达问卷链接


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

查看原文

赞 0 收藏 0 评论 0

Donald 发布了文章 · 11月20日

集群的云原生安全

作者:Pushkar Joglekar

在过去的几年中,一个关注安全的小型社区一直在努力工作,以加深我们对安全的理解,并给出了不断发展的云原生基础设施和相应的迭代部署实践。为了能够与社区的其他成员共享这一知识,由Emily Fox领导的CNCF SIG Security的成员(一个向CNCF TOC回报的小组,他们也是Kubernetes SIG Security的朋友)在白皮书中概述了整体的云原生安全问题和最佳实践。在来自世界各地35个成员的1200多个评论、修改和讨论之后,我们很自豪地与大家分享云原生安全白皮书v1.0,它是企业、金融和医疗保健行业、学术界、政府和非营利组织的安全领导必备的阅读材料。

白皮书试图不关注任何特定的云原生项目。相反,其目的是将安全性建模并注入云原生应用生命周期的四个逻辑阶段:开发、分发、部署和运行时。

Kubernetes原生安全控制

当使用Kubernetes作为工作负载协调器时,这个版本的白皮书推荐的一些安全控制如下:

  • Pod安全策略:为整个集群的“最少特权”工作负载实现一个真实源
  • 资源请求和限制:对共享资源(如内存和CPU)应用请求(软约束)和限制(硬约束)
  • 审计日志分析:启用Kubernetes API审计和筛选与安全相关的事件
  • 控制平面身份验证和信任的证书根:启用相互TLS身份验证,使用可信的CA在集群内进行通信
  • 秘密管理:与内置或外部秘密存储集成

云原生互补安全控制

Kubernetes直接参与部署阶段,较少参与运行时阶段。为了使Kubernetes中的工作负载“默认情况下是安全的”,必须确保安全地开发和分发工件。在云原生应用程序生命周期的所有阶段,存在一些针对Kubernetes编排的工作负载的补充性安全控制,包括但不限于:

  • 开发:

    • 镜像签名与验证
    • 镜像漏洞扫描器
  • 分发:

    • 部署前检查是否存在过度特权
    • 启用可观察性和日志记录
  • 部署:

    • 使用服务网格进行工作负载身份验证和授权
    • 通过网络插件为工作负载间通信强制执行“默认拒绝”网络策略
  • 运行时:

    • 为工作负载部署安全监视代理
    • 使用SELinux、AppArmor等隔离在同一节点上运行的应用程序。
    • 根据公认的安全基线扫描节点、工作负载和协调器的配置

先了解,后安全

云原生方式(包括容器)为其用户提供了巨大的安全优势:不变性、模块化、更快的升级和跨环境的一致状态。意识到“做事方式”的这种根本性变化,促使我们从云原生的角度来看待安全问题。对于白皮书作者来说显而易见的一件事是,如果你不了解手头的工具、模式和框架,那么就如何以及哪些在云原生生态系统中进行保护就很难做出更明智的决定(除了了解自己的重要资产之外)。因此,对于那些想要成为合作伙伴而不是在操作、产品开发和合规方面为朋友看门人的安全从业者来说,让我们尝试学习更多知识以便更好地确保安全。

我们推荐遵循这7步R.U.N.T.I.M.E.路径来开始云原生安全:

  1. 阅读(Run )白皮书和其中任何相关的材料
  2. 了解(Understand)环境中的挑战和限制
  3. 注意(Note)应用于环境的内容和控件
  4. 和你的同伴谈论(Talk)你的观察
  5. 让你的领导参与(Involve)进来,寻求帮助
  6. 基于现有的和缺失的安全控制,制作(Make)一个风险概要
  7. 在适当的地方,花费(Expend)时间、金钱和资源来改善安全状况并降低风险。

鸣谢

感谢Emily Fox、Tim Bannister(The Scale Factory)、Chase Pettet(Mirantis)和Wayne Haber(GitLab)为这篇博客提供的精彩建议。

点击阅读网站原文


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

查看原文

赞 0 收藏 0 评论 0

Donald 发布了文章 · 11月19日

CNCF最终用户技术雷达:数据库存储(2020年11月)

今天,CNCF发布了季度第三期CNCF最终用户技术雷达;该技术雷达的主题是数据库存储。

6月,我们推出了CNCF最终用户技术雷达,这是CNCF最终用户社区的一个新倡议。这是一个由超过140家顶级公司和初创公司组成的团体,他们定期开会讨论在采用云原生技术时面临的挑战和最佳实践。CNCF最终用户技术雷达的目标是分享最终用户正在积极使用的工具、他们推荐的工具以及他们的使用模式。更多关于该方法的信息可以在这里找到。

radar.cncf.io可寻到其他雷达、选票和代表的行业。

请锁定11月20日星期五下午4:00 ET时区的北美KubeCon + CloudNativeCon虚拟大会,收看TechRadar与Cheryl Hung和Radar的编辑们的现场问答环节,将会听到他们对结果的更多想法和了解。

数据库存储的调查

在2020年10月,最终用户社区的成员被问及他们评估、试验并随后采纳了哪些数据库存储解决方案。总共273个数据点被排序和审查,以确定最终的位置。

这可以解读为:

  • “采纳(Adopt)”中的六种工具被受访者广泛采纳和推荐。
  • “试验(Trial)”中的技术得到了一些最终用户的推荐,但他们要么没有得到足够的总体响应,要么只有少数人投了“采纳”票。
  • “评估(Assess)”的项目缺乏明确的共识。对MariaDB、CockroachDB和Vitess有一定了解,但只有少数用户推荐采纳。寻找新的数据库存储解决方案的组织在考虑“评估”中的需求时应该考虑到它们自己的需求。

主题

主题描述了有趣的模式和编辑观察:

1. 公司对自己的数据很谨慎,采用新技术的速度也很慢。

新技术,如CockroachDB、TiDB和Vitess,还没有被许多作出回应的公司广泛研究。CockroachDB和Vitess最终出现在“评估”。

一些不同的因素促使组织对他们的数据采取谨慎的态度,但主要的原因是难以管理。在将大量数据(有时是tb或pb)从一种数据存储技术转移到另一种数据存储技术时,会产生大量的开销。要想行动有意义,收益必须大于成本。即使在从遗留解决方案过渡到云计算时,一些公司也会考虑集成他们已经拥有的工具。

另一个因素可能是更难雇佣在这些新技术方面有专长的开发人员。“评估”中的所有项目(CockroachDB、MariaDB和Vitess)都与“采纳”中的技术具有API兼容性,因此组织可以在不转换到新工具的情况下集成元素。

有趣的是,etcd并没有出现在雷达上。etcd的使用主要是由Kubernetes驱动的,因为它是唯一受支持的后端。公司很少使用etcd作为独立的数据托管选择,这意味着从遗留基础设施过渡过来的公司不太可能有使用它的经验。

2. 选择托管数据库服务在很大程度上取决于用例。

我们惊讶地看到云管理服务的使用率很低。这让我们认识到,托管数据库服务的使用可能因用例的不同而差异很大--应用程序部署的位置、存储的数据量,以及是否已经使用了云提供商。例如,如果一个公司有大量数据,那么使用托管数据库解决方案可能会带来巨大的成本开销。

云管理数据库的使用可能会受到公司是否已经在使用特定云提供商的影响。例如,如果一家公司只在其他云服务上使用AWS,那么他们很可能也会使用AWS相关的数据库技术。如果它们在本地运行,它们很可能不会只在云中运行数据库。

在其他情况下,决策可能由数据安全和保护驱动。处理敏感数据的公司更有可能在内部建立数据库,甚至可能被要求这样做。

虽然我们确实问过RDS,但它最终并没有出现在雷达上。我们删除了它,因为它的用法含糊不清,也不清楚使用了什么特殊的技术。

3. 保持开放的心态!

我们发现,数据库存储仍然是一个不断发展的领域。有些项目已经存在了很长时间,这可能会提高它们的采用率,特别是考虑到在大公司的使用。这些遗留技术中的许多都享有良好的声誉,因为它们是稳定的,并且被证明可以工作。

新的云原生项目正在出现,其中许多更适合新的用例。有一些具有特殊用例的新技术没有进入雷达;我们没有看到任何图形数据库、指标的长期存储或无服务器数据库。

最终,你必须为你、你的团队和你的组织选择正确的技术。使用一种你可以随时介入并替换的技术,与强迫工程师去适应某种技术相比,是否更有意义?你正在考虑的开源项目背后是否有一个蓬勃发展的社区?做你的研究,做有意义的事情,但是不要害怕尝试新事物!

编辑

Jackie Fong是Ticketmaster平台部门的工程主管,负责容器编排、CI/CD、观察能力和开发经验。在2020年初,Jackie在CNCF成立了一个服务网最终用户小组,并担任联合主席。

Smaine Kahlouch是Dailymotion的DevOps团队负责人。他领导了一个团队,负责构建一个可靠的、可扩展的平台,以及发布管理。他是CNCF在巴黎meetup的组织者,也是CNCF在法国的大使。Twitter: smana

Mya Pitzeruse是Indeed公司服务平台部门的首席工程师,负责设计和指导跨计算、存储和观测的云原生平台的开发。Twitter: myajpitz

阅读延伸

案例研究:了解京东SlackSquare如何使用CNCF技术处理数据库存储。

接下来

下一个CNCF最终用户技术雷达将于2021年2月发布,关注的是云原生的一个不同主题。投票帮助决定下一个CNCF最终用户技术雷达的主题

加入CNCF最终用户社区

  • 找出到底是谁在使用每个项目,并阅读他们的评论。
  • 贡献和编辑未来的CNCF最终用户技术雷达。

我们很高兴向社区提供这份报告,我们也很乐意听到你的想法。反馈邮件发送到info@cncf.io。

关于方法

2020年10月,CNCF最终用户社区的140家公司描述他们的公司对不同解决方案的建议:暂缓、评估、试验或采纳。他们也可以给出更详细的评论。由于答案是通过谷歌电子表格提交的,所以在小组中既不保密也不匿名。

29家公司提交了关于36个解决方案的273个数据点。这些被排序以确定最终的位置。最后,编辑编写主题以反映更广泛的模式。

点击阅读网站原文


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

查看原文

赞 0 收藏 0 评论 0

Donald 发布了文章 · 11月19日

TOC批准Buildpacks从沙箱提升到孵化阶段

今天,CNCF技术监督委员会(TOC)投票决定将云原生Buildpacks从CNCF沙箱提升到孵化阶段。自2018年加入CNCF以来,Cloud Native Buildpacks项目已经增加了超过15个新的生产用户和来自更多组织的新提交者,并定义了一个开放的治理流程和清晰的项目路线图。

Cloud Native Buildpacks(CNB)项目的目标是将源代码转换为容器镜像,重点关注开发人员的生产力、容器安全性和涉及大规模容器化应用程序的操作。该项目还旨在将过去的构建包(buildpack)生态系统与现代云原生平台的定义良好的契约理想统一起来。

“云原生Buildpacks使开发人员能够在对他们最有生产力的抽象层上工作,同时解决像脆弱依赖和构建缓慢这样的大问题。”VMware的Buildpacks维护者和工程师Emily Casey说:“该项目强大的规范和工具帮助促进了可组合构建包的生态系统,可以与不同的平台互操作。随着Buildpacks进入孵化阶段,我们很高兴能继续发展社区。”

“Heroku(Salesforce)在2012年开源了最初的Buildpacks项目,希望它们能扩展到Heroku平台之外,”Buildpacks联合创始人兼Salesforce首席工程师Terence Lee说。“2018年,Heroku和Pivotal(VMware)合作创建了云原生Buildpacks,这是一个CNCF沙箱项目。从CNCF的沙箱到孵化阶段,Buildpacks正在实现这一愿景,同时使用OCI镜像标准,增加透明度,建设我们的社区。我们期待着与社区合作,开发新的功能,并获得更多用户的接受。”

2018年10月,云原生Buildpacks被CNCF沙箱接受。Buildpacks被最终用户组织用于生产,包括Greenhouse、Salesforce和VMware;云计算原生开源软件包括Cloud Foundry on K8s、谷歌Skaffold、Hashicorp Waypoint和kpack;商业产品包括DigitalOcean应用平台、谷歌云、Salesforce Evergreen和VMware Tanzu Build Service。

“HashiCorp Waypoint从第一天开始就设定使用Buildpacks。我们希望开发人员能够尽可能快速、轻松地从编写代码到部署,而云原生Buildpacks提供了实现这一目标的标准、技术和社区,”HashiCorp创始人Mitchell Hashimoto说,“我们期待继续投资和改进我们的Buildpacks使用。”

“开发人员不应该考虑如何打包他们的应用程序来进行部署,所以我很高兴看到云原生Buildpacks被提升为CNCF孵化项目。”谷歌云开发人员倡导者James Ward说:“在谷歌云,我们已经开源了我们的Buildpacks,并将对它们的支持添加到许多产品中,包括Cloud Build、Cloud Run、App Engine、Cloud Functions、Cloud Code、云Shell和Skaffold。现在,从源代码到在云上运行就更容易了。”

Buildpacks的主要特性:

  • 规范--描述平台到Buildpacks契约的正式语言规范。
  • 实现--平台需要健壮的生命周期工具以添加使用Buildpacks构建镜像的支持。
  • 平台--直接向最终用户提供开发体验的组件,包括与流行构建工具和云平台的集成。

里程碑亮点:

  • 6名来自Salesforce和VMware的维护者
  • 20名提交者
  • 2k以上贡献
  • 几乎5k提交
  • 超过1200万GitHub星星
  • 15名贡献者

云原生Buildpacks项目是对其他CNCF项目的补充,包括Helm、Harbor和Kubernetes。云原生Buildpacks生成由Helm管理、存储在Harbor并部署到Kubernetes的OCI(Open Container Initiative,开放容器倡议)镜像。该项目的首要目标是提供一种可靠、安全、模块化和快速的方法来从源或输入工件构建OCI镜像。

“云原生Buildpacks提供了一种可靠而无缝的方式来将代码转换为容器。”CNCF CTO兼OCI执行董事Chris Aniszczyk说:“这降低了开发人员利用云原生技术的障碍,并改善了部分开发人员和云原生平台的开发体验。”

“用户需要一种简单的方式来打包、提供和管理云原生应用程序。最初由Heroku或Cloud Foundry使用的Buildpacks现在已经完全云原生化,包括Kubernetes推广的关键模式。”Weaveworks首席执行官兼CNCF TOC前成员Alexis Richardson说,“这些都是作为GitOps核心的关键模式,结合使用它们,Weaveworks的客户可以升级和修补他们的应用部署。”

作为CNCF托管项目,加入孵化技术Argo、CloudEvents、CNI、Contour、Cortex、CRI-O、Dragonfly、etcd、Falco、gRPC、KubeEdge、Linkerd、NATS、Notary、OPA、OpenTracing、Operator Framework、Rook、SPIFFE、SPIRE和Thanos,Cloud Native Buildpacks是一个中立的基金会的一部分,该基金会与它的技术兴趣保持一致,而更大的Linux基金会则提供了治理、市场支持和社区服务。每个CNCF项目都有一个相关的成熟度级别:沙箱、孵化或毕业级。有关每个等级的成熟度要求的更多信息,请参阅CNCF毕业标准

要了解更多关于云原生Buildpacks的信息,请访问buildpacks.io。项目维护者将在2020年北美KubeCon + CloudNativeCon虚拟大会期间提供办公时间,回答有关该项目的任何问题。请务必在美国东部时间11月20日星期五下午4:00注册并加入。

点击阅读网站原文


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

查看原文

赞 0 收藏 0 评论 0

Donald 发布了文章 · 11月18日

Envoy Mobile项目加入CNCF

Envoy项目文章,作者:Michael Schore

就在一年前,我们发布了Envoy Mobile的初次开源预览。今天,我们要分享一些激动人心的消息:Envoy Mobile正式加入其母项目Envoy,成为CNCF的一部分!从一开始,我们就承诺将Envoy Mobile开发为一个开源项目。我们相信,作为移动网络的一个模式,它有潜力开创新的领域,并且对围绕着Envoy成长起来的充满活力的社区的认可,使开源成为我们明确的选择。在过去的一年里,与社区的互动带来了巨大的回报,因为我们已经从最早的概念验证阶段过渡到实验阶段,然后是生产解决方案,完全公开。今天是一个重要的里程碑,我们荣幸地参加了CNCF管理下的项目,就像Envoy、Kubernetes、gRPC等。

简史

Envoy项目之所以成功,是因为它为一个由多种语言系统组成的网络提供了一个共同的基础。部署Envoy意味着在整个机群中实现一致的可观察性、可配置性和可扩展性,而不考虑单个服务的任何独特特征。Envoy的主动/被动健康检查模型和最终一致的路由配置,在面对不可预测的网络和软件故障时,提供了稳定性和可靠性。

Envoy Mobile项目始于一个问题:为什么我们将移动设备与后端基础设施中的节点区别对待?即使企业在这两个平台上运行关键软件,一个被视为核心基础设施,而另一个被视为独立的外部客户端。历史上默认的假设是,这两个组成部分是根本不同的。虽然确实存在差异,但移动客户端遇到的许多挑战类似于我们之前使用Envoy在服务器上解决的问题。

对许多组织来说,实现对移动应用程序运行状况和性能的可见性是一项持续的斗争。类似地,自定义运行时/动态配置解决方案是大规模部署应用程序的标准。考虑到Android和iOS都必须同时支持,共享代码很困难。此外,与后端基础设施相比,移动客户端所面临的网络条件更不可预测,更容易出现故障。我们在后台利用Envoy作为这些问题的共同解决方案。Envoy能成为移动客户端的解决方案吗?我们决定:“绝对能够。”,Envoy Mobile出现了。

移动网络库

“Envoy已经成为应用网络的通用可编程数据平面。我们很高兴看到Envoy Mobile将Envoy的好处带到移动生态系统中。我们现在有能力向客户端应用程序提供可编程性,比如支持真正的端到端云原生服务的移动应用程序。”
-Anna Berenberg,谷歌云杰出工程师

在我们开始这个旅程之前,我们花了一些时间来评估其他的可能性。有许多功能强大的移动网络库,它们都有强大的追随者。但是Envoy提供的一个关键区别是,它为分布式应用程序中的所有网络提供了一个公共层。最终,我们得出结论,我们在移动客户端取得同样优势的唯一途径就是使用Envoy本身。

当然,Envoy并不是设计成进程内库的,更不用说在移动应用程序中运行了。但是它的许多设计决策使它能够非常好地适应这个新目标--从它的单线程代码库到它的缓冲区管理模型。我们将在以后的文章中分享更多关于这方面的内容,但要深入了解我们是如何将Envoy变成一个库而不是一个服务器,请参阅我们去年在KubeCon和EnvoyCon上的演讲(Envoy Mobile in Depth: From Server to Multi-platform Library - Jose Nino & Michael Schore, Lyft)。Envoy的现代架构和设计为证明我们的想法的可行性提供了一个显著的开端。

开源

当我们第一次发布Envoy Mobile仓库时,这个库仅仅是一个工作原型。Envoy运行并可以在iOS和Android上处理请求。我们有个雄心勃勃的路线图,但是我们并没有闭门执行项目,并且只有当我们有一个生产就绪的解决方案时才分享它,我们慎重地决定不仅开放我们的初始项目,而且开放路线图本身。我们相信,Envoy Mobile背后的理念有可能从根本上改变企业看待移动客户端和物联网设备的方式,并与之互动。分享这个愿景和这个项目最早的版本,部分是我们对这个信念的承诺,部分是对社区的承诺,我们希望为每个人实现这些好处。

一年过去了,Envoy Mobile被汇编到Lyft应用程序中,并发送我们的生产流量。该库具有一流的绑定,并支持Swift、Kotlin、Objective-C和Java(Python开发中!)我们现在已经拥有了一个真正的基础,可以构建未来的移动网络。

下一步

“Envoy的社区增长和无数的使用案例继续超出我最疯狂的期望。虽然Envoy对服务器端云原生分布式系统的构建方式有着深远的影响,但移动客户端和物联网设备与服务器端设备存在相同的问题,包括可观察性、容错、负载平衡和配置。Envoy Mobile进入CNCF将加速Envoy作为端到端云原生网络平台的采用,使复杂的分布式应用能够更健壮地部署。我太激动了。”
- Matt Klein,Envoy的创造者

有了跨客户端和后端服务的统一基础和公共网络抽象,特性可以一次性创建并在任何地方使用。我们有Envoy Mobile发展的下一个篇章的宏伟计划。非常简短的亮点包括:

  • 强类型API生成--允许使用IDL(如protocol buffer)定义API,并利用代码生成来消除样板文件和抽象传输。
  • 通过API/IDL注释,选择基于策略支持的网络特性--包括缓存、重试、延迟API、流、推和优先级。
  • 先进的协议支持和网络优化--支持QUIC、HTTP/3、DNS替代、和自定义协议扩展,智能连接加权和选择。
  • xDS--利用Envoy的配置发现API,通过与传统网格相同的控制平面动态配置。

要了解更多关于我们的计划或贡献的机会,我们的路线图也是开源的!

Envoy Mobile加入CNCF的时机恰到好处。这个新的,中立的家园将使我们更容易与其他组织合作,并接受来自其他组织的贡献。它还将使我们更紧密地与Envoy的开发周期保持一致,允许我们执行共享的CI测试覆盖率,以及两个项目之间更紧密集成的上游特性。通过这一步,我们期待着与CNCF以及你们所有人一起重新定义我们对客户端到服务器通信的看法。

点击阅读网站原文


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

查看原文

赞 0 收藏 0 评论 0

Donald 发布了文章 · 11月17日

使用Prometheus和Linkerd建立Kubernetes服务水平目标(SLO)的指南

客座文章最初由Kevin LeimkuhLer在Buoyant的博客上发布

有了服务网格,SLO就容易多了

在本教程中,你将学习如何使用Prometheus(一个开源时间序列数据库)和Linkerd(一个开源超轻服务网格)在Kubernetes上轻松创建服务运行状况SLO。你将看到如何使用服务网格解决SLO中最困难的部分之一:为你想要度量的东西获得一致的度量标准。

但在我们开始之前,让我们先深入了解一下为什么SLO和Kubernetes会携手并进。

Kubernetes和服务网格的一个SLO案例

SLO,或者服务级别目标(service level objective),最近已经成为描述应用程序可靠性的流行工具。正如谷歌SRE书中所描述的,SLO是应用程序开发人员和SRE团队明确捕获应用程序风险容忍度的一种方法,通过定义可接受的失败级别,然后根据该决策做出风险vs回报的决策。

对于平台所有者,他们较少关注应用程序,更多关注底层平台,SLO还有另一个用途:它们提供了一种方法,可以了解平台上运行的服务的健康状况,而无需了解任何有关其运营历史的信息。这在Kubernetes中特别有用,在Kubernetes中,你可能在几十个集群中运行数百或数千个服务。你不需要了解每个服务的操作上下文,而可以使用SLO作为获得上下文无关判断的一种方法。(参见SLO vs Kubernetes指标)。

令人高兴的是,在Kubernetes上获得服务运行状况方面的SLO比你想象的要容易得多。这是因为SLO最难的部分之一是获得一致的、统一的度量,而这正是服务网格所做的!例如,Linkerd为你所有的服务提供了一个统一的、一致的黄金度量层--成功率、延迟、请求量--并且不需要任何配置。有了Linkerd的指标在手,获得基本的服务运行状况SLO就可以归结为做一些计算。

(当然,服务网格并不是SLO的完整解决方案,因为它不能捕获应用程序特定指标之类的东西。但对于常见的服务运行状况度量,如成功率和延迟,至少可以通过提取服务网格数据轻松构建服务运行状况SLO。)

让我们用一个演示用例来动手吧。

用Linkerd和Prometheus计算SLO

在本教程中,我们将看到如何为在Kubernetes上运行的gRPC服务设置一个滚动窗口的基本成功率SLO。当然,我们这里使用的技术同样适用于不同类型的指标和SLO。

首先,让我们回顾一下Linkerd如何捕捉它的黄金指标。当Linkerd被添加到服务中时,它会自动记录对服务pod的任何HTTP和gRPC调用。它记录这些调用的响应类和延迟,并将它们聚合到Prometheus的一个内部实例中。这个Prometheus实例为Linkerd的仪表板和CLI提供动力,并包含所有网格服务的观察黄金指标

因此,为了达到我们的目标,我们需要将存储在Linkerd的Prometheus中的成功率指标转换为SLO。

安装:访问Kubernetes集群并安装Linkerd CLI

让我们从最基本的开始。我们假设你有一个运行的Kubernetes集群和一个指向它的kubectl命令。在本节中,我们将带你完成Linkerd入门指南的简化版,以在这个集群上安装Linkerd和一个演示应用程序。

首先,安装Linkerd CLI:

curl -sL https://run.linkerd.io/install | sh
export PATH=$PATH:$HOME/.linkerd2/bin

(或者,直接从Linkerd发布页面下载。)

验证你的Kubernetes集群能够处理Linkerd;安装Linkerd;并验证安装:

linkerd check --pre
linkerd install | kubectl apply -f -
linkerd check

最后,安装我们将要使用的“Emojivoto”演示应用程序:

curl -sL https://run.linkerd.io/emojivoto.yml 
 | linkerd inject - 
 | kubectl apply -f -

此时,我们已经准备好获得一些实际的指标了。但首先,让我们谈谈SLO中最重要的数字:错误预算(error budge)。

错误预算

错误预算可以说是SLO中最重要的部分。但它到底是什么,我们如何得到它?

让我们从一个例子开始。假设在过去7天内,你已经决定你的服务必须有80%的成功率。这是我们的SLO。我们可以将这个语句分解为三个基本组件:一个服务水平指示器(SLI),这是我们的度量;目标,也就是我们的门槛;还有时间窗口。在这种情况下:

SLI:服务成功率

目标:80%

时间窗口:7天

这个SLO意味着在7天滚动周期内20%的请求可能会失败,而我们并不认为这是一个问题。因此,我们的错误预算仅仅是衡量我们在一段时间内“消耗”了20%中的多少。

例如,如果我们在过去7天内成功地提供了所有响应的100%,那么我们的错误预算将保持100%—没有任何响应失败。另一方面,如果我们在过去7天成功地服务了80%的响应,那么我们就有0%的错误预算剩余。如果我们在这段时间内提供了少于80%的成功回应,我们的错误预算就会是负的,我们就违反了SLO。

错误预算由下式计算:

Error budget = 1-[(1-compliance)/(1-objective)]

compliance是在时间窗口内测量的SLI。因此,为了计算你的错误预算,我们在时间窗口内测量SLI(计算compliance),并将其与目标进行比较。

用Prometheus计算错误预算

好,回到键盘上来。让我们访问在Linkerd控制平面中的Prometheus实例,我们在上一步中通过一个port-forward安装了它:

# Get the name of the prometheus pod
$ kubectl -n linkerd get pods
NAME                                      READY   STATUS    RESTARTS   AGE
..
linkerd-prometheus-54dd7dd977-zrgqw       2/2     Running   0          16h

用PODNAME表示pod的名称,我们现在可以这样做:

kubectl -n linkerd port-forward linkerd-prometheus-PODNAME 9090:9090

现在我们可以打开localhost:9090并开始试验Prometheus的查询语言PromQL。


Prometheus仪表板

本教程不需要完全掌握语法知识,但是浏览示例熟悉一下肯定会有帮助!

构建Prometheus的查询

在上面的例子中,100%和80%的响应是成功的--这是我们在这段时间内的compliance数字。让我们先用Prometheus查询来计算这个数字。对于我们的服务,我们将使用Emojivoto的投票服务,它作为Emojivoto命名空间中的部署资源。

首先,让我们看看总共有多少对投票部署的响应:

查询:

response_total{deployment="voting", direction="inbound", namespace="emojivoto"}

结果:

response_total{classification="success",deployment="voting",direction="inbound",namespace="emojivoto",..} 46499
response_total{classification="failure",deployment="voting",direction="inbound",namespace="emojivoto",..} 8652

在这里我们看到两个结果,因为指标是由一个标签值分开的,它们的不同之处是:classification(分类)。我们有46499个成功的响应和8652个失败的响应。

在此基础上,通过添加classification="success"标签和[7d]时间范围,我们可以看到过去7天每个时间戳上成功响应的数量:

查询:

response_total{deployment="voting", classification="success", direction="inbound", namespace="emojivoto"}[7d]

这个查询的响应很大,但是我们可以使用increase()和sum() PromQL函数来简化它,通过标签分组来区分不同的值:

查询:

sum(increase(response_total{deployment="voting", classification="success", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, classification, tls)

结果:

{classification="success",deployment="voting",namespace="emojivoto",tls="true"} 26445.68142198795

这意味着在过去7天里,通过投票部署已经有大约26445个成功的响应(小数来自increase()计算的机制)。

使用这个,我们现在可以通过将这个数字除以响应总数来计算我们的compliance--只需删除classification="success"标签:

查询:

sum(increase(response_total{deployment="voting", classification="success", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, classification, tls) / ignoring(classification) sum(increase(response_total{deployment="voting", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, tls)

结果:

{deployment="voting",namespace="emojivoto",tls="true"} 0.846113068695625

我们发现,在过去7天内,84.61%的响应都是成功的。

计算错误预算

我们使用核心查询来计算剩余的错误预算。现在我们只需要把它们代入上面的公式:

Error budget = 1-[(1-compliance)/(1-objective)]

插入我们80%(0.8)的目标(objective):

查询:

1 - ((1 - (sum(increase(response_total{deployment="voting", classification="success", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, classification, tls)) / ignoring(classification) sum(increase(response_total{deployment="voting", direction="inbound", namespace="emojivoto"}[7d])) by (namespace, deployment, tls)) / (1 - .80))

结果:

{deployment="voting",namespace="emojivoto",tls="true"} 0.2312188519042635

在我们的例子中,投票部署还有23.12%的错误预算。

祝贺你,你已经成功地计算了你的第一个错误预算!

用Grafana捕捉结果

数字很好,但花哨的图表呢?你是幸运的。Linkerd安装了一个Grafana实例,我们可以通过Linkerd的仪表板在本地访问它。

首先,通过运行Linkerd dashboard命令加载Linkerd的仪表板。

现在,让我们通过单击相应的Grafana徽标来查看emojivoto命名空间的Grafana仪表板。


Linkerd仪表盘与Grafana集成

向下滚动到deploy/voting,我们可以看到黄金指标面板:成功率、请求率和延迟。让我们为剩余的错误预算添加一个面板。


Linkerd在Grafana仪表板上

为了保持简单,让我们添加面板标题7-day error budget (success rate),并在PromQL查询框中添加上面的最终查询。

应用结果,你现在应该有一个面板来跟踪投票部署的剩余错误预算!


Grafana与Linkerd指标显示错误预算。

进一步

有很多方法可以调整上面使用的查询以适应特定的用例。

现在我们有了一个跟踪服务错误预算的图表,我们可以使用额外的PromQL函数(如rate())来跟踪服务的错误预算消耗率。

如果你想以不同的方式查看你的预算,请尝试更改数据的可视化。在这里,我选择了测量和添加阈值来指示我是否应该关注。


7天错误预算(成功率)与测量。

要跟踪emojivoto命名空间中所有服务的剩余错误预算,只需删除deployment="voting"标签。请记住,这将假设命名空间中的所有服务都有相同的80%目标。


所有服务的7天错误预算(成功率)。

从SLO到可操作的观察性

你已经根据Linkerd的黄金度量标准制定了服务运行状况的SLO,计算了错误预算,并用Grafana绘制了它们的图表。祝贺你,你正在使用SLO!

下一步是什么呢?

遗憾的是,即使有了所有这些,要真正使用SLO仍然需要做很多工作。你需要为你平台上的每个相关服务一致地计算它们;你需要把它们交到组织中其他需要了解它们的人手中;当错误预算开始迅速下降时,你需要能够采取行动。如果没有这些部分,你的SLO将只是一个空数字。

在Buoyant,我们是SLO的巨大信徒,尤其是Kubernetes。这也是我们创建Dive的部分原因,它允许你通过点击一个按钮来设置SLO。Dive构建在Linkerd之上,并使用相同的指标来自动跟踪集群上运行的所有服务。Dive还提供了很棒的可共享仪表盘,你可以将其发送给团队的其他成员,允许你预测何时会违反你的SLO,以及许多其他有趣的东西。

Dive仪表板显示SLO遵从性和错误预算的7天窗口。

无论你最终是使用Dive进行Linkerd服务的健康SLO,还是坚持我们上面概述的Prometheus和Grafana方法,我们都祝你在SLO旅程中好运!

点击阅读网站原文


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

查看原文

赞 0 收藏 0 评论 0

Donald 发布了文章 · 11月13日

2019年CNCF中国云原生调查报告

中国72%的受访者生产中使用Kubernetes

在CNCF,为更好地了解开源和云原生技术的使用,我们定期调查社区。这是第三次中国云原生调查,以中文进行,以便更深入地了解中国云原生技术采用的步伐及如何在庞大且不断发展的社区中赋能开发者并作出变革。本报告基于2018年3月2018年11月发布的前两份中国报告。

中国云原生调查的重点

  • 49%的受访者在生产中使用容器,另有32%计划这样做。与2018年11月相比,这是一个显着的增长,当时生产中仅20%使用容器。
  • 72%的受访者在生产中使用Kubernetes,高于2018年11月的40%。
  • 公有云的使用率从2018年11月的51%下降到了36%,取而代之的是使用39%的混合新选项。
  • CNCF项目呈指数增长。CNCF现有四个在中国诞生并在该地区更广泛使用的项目:孵化阶段的Dragonfly和KubeEdge,以及刚毕业的Harbor和TiKV。

2019年中国云原生调查包括300名受访对象-其中97%来自亚洲,主要是中国。

容器使用

我们知道容器已经改变了基于云的基础架构,但是在过去的一年中,容器在生产中的使用已成为常态。根据我们今年初发布的2019全球云原生调查,84%的受访对象在生产中使用容器,使得容器在全球范围内无处不在。

中国调查表明,尽管中国的容器使用落后于全球,但其势头正在增强。在中国调查中,将近一半(49%)的受访对象在生产中使用容器–从2018年3月调查的32%和2018年11月的20%跃升至更高水平。

计划在生产中使用容器的中国会员越来越少-现在32%,2018年3月的调查中为57%,11月为40%。这意味着许多组织已将容器计划付诸实施,而不再处于计划阶段,但仍存在增长空间,希望继续增长。


Your organization uses containers for 您的组织使用容器为了 …
Proof of concept 概念验证
Development 开发
Test测试
Production生产

随着生产中应用的增加,测试环境中容器减少。约28%的中国调查受访者目前测试中使用容器-与2018年3月的24%相比略有上升,但与2018年11月的调查中的42%相比有所下降。

尽管容器带来了惊人的优势,但也带来了挑战。随着时间的推移发生了变化,但是复杂性的挑战一直保持不变。在中国调查中,53%的受访者将复杂性列为最大挑战。相比之下,2018年3月的调查中, 44%受访者认为复杂性是最大挑战,占比最高。2018年11月的调查中28%的受访者,占比排第三。

在挑战方面,安全性排名第二,受访者占比39%。安全首次被列为首要挑战。培训不足和网络并列第三,占比36%,而35%的调查受访者将可靠性和监控性作为部署挑战。


container challenges容器挑战
complexity 复杂性
security安全性
lack of training培训不足
networking 网络
reliability可靠性
monitoring监控
service mash服务网络
cultural changes w/development team文化改变w/开发团队
scaling deployments based upon the load基于负载的拓展部署
difficulty in choosing an orchestration solution很难选择编排流程解决方案

Kubernetes增长

Kubernetes作为一个容器编排通用平台正在行业中崭露头角并在中国的CNCF社区中的采用率也急剧上升。72%的受访者表示在生产中使用Kubernetes-与2018年11月的40%相比有了大幅增长。

因此,评估Kubernetes的人数从42%降至17%。


using in production 生产中使用evaluating 评估

我们还看到Kubernetes的生产集群在部署范围两端的增长。大部分中国调查的受访组织使用不到10个集群,但是运行50个以上的集群的组织有所增加。这可能是由于在生产中使用容器的新受访者数量增加,从而增加了集群。

36%的受访者拥有2到5个集群,高于2018年11月的25%,一半的受访者使用1到5个集群,70%的受访者使用1到10个。只有13%多的受访者生产中有超过50个集群,而在2018年11月时仅有5%的受访者。


如果您使用Kubernetes,那么您有多少个生产集群?

打包

Helm是打包Kubernetes应用程序最受欢迎的方法,54%的受访者选择了这种方法

入口

NGINX(54%)是使用最多的Kubernetes入口提供商,其次是HAProxy(18%),F5(16%)和Envoy(15%)。

分离Kubernetes应用程序

在集群中管理对象是个挑战,但是命名空间通过按组过滤和控制来帮助管理。71%的受访者用命名空间分离Kubernetes应用程序。在多个团队中使用Kubernetes的调查对象中,有68%使用命名空间。

监控,日志和跟踪

对于那些使用监控,日志和跟踪解决方案的用户来说,本地运行还是通过远程服务器托管更普遍。46%的受访者使用本地监控工具,而20%的受访者通过远程服务运行。整体上使用日志和跟踪的受访者较少,但是26%的受访者在本地运行跟踪,而20%通过远程服务运行跟踪。21%的企业内部运行跟踪工具,另外21%的企业通过远程服务运行。

代码

由于持续集成(CI)和持续交付(CD)的支持,云和容器的强大功能共同推动了中国的开发和部署速度。我们的调查通过开发者将代码检入存储库的频率来量化开发速度。35%的受访对象每天多次检入代码。43%的每周几次检入代码,16%的每月几次检入代码。


您检入代码的频率是?
A few times a month 一月几次
Multiple times a day一天几次
A few times a week 一周几次

大多数受访对象发布周期是每周一次(43%),而仅五分之一多的(21%)是每月一次。而18%的是每日一次。12%的受访对象按特定时间表工作。


您的发布周期是?

CI/CD

许多人认为成功的CI / CD的基础是流程自动化。但是,我们在中国的调查显示,纯自动化环境相对较少-只有21%的受访对象采用自动发布周期,而31%依靠手动流程。最受欢迎的是混合方式,占46%。


您的发布周期是手动还是自动?

CI/CD是实现云原生系统灵活交付和生命周期管理一种哲学和技术。Jenkins是中国社区中最受欢迎的CI/CD工具,占社区的一半以上53%,GitLab占40%。

云与内部部署

云在增长,但是今年的中国调查显示了从公共云的转移,私有云的合并以及混合云的出现。2018年11月调查中,公共云的使用似乎达到了峰值51%,而今年下降到36%。私有云保持稳定42%,2018年11月是43%。混合云是今年的新选择,占39%。


您公司/组织使用以下哪种数据中心?
Private cloud私有云
Public cloud公有云
Hybrid cloud混合云
Other 其他

云原生项目

CNCF管理着大量的开源项目,这些项目对于云原生的开发,部署和生命周期管理至关重要。CNCF项目在中国呈指数级增长。例如57%的受访者使用Prometheus监控和警报系统,较2018年3月的16%有显著增长。现在35%受访者使用CoreDNS, 2018年3月只有10%。Containerd运行时也实现了惊人增长 –从2018年3月的3%增长到2019年初的29%。

CNCF还托管了在中国创建的四个项目,这些项目在该地区得到了更广泛的应用。Dragonfly(17%受访者在生产中使用)和KubeEdge(11%受访者在生产中使用)是最常用的两个沙箱项目, 现在两个都在孵化阶段。Harbor和TiKV是毕业项目,分别有27%和5%受访者用于生产。


毕业的CNCF项目使用
*不包括:新的毕业项目Rook


孵化的CNCF项目使用
*不包括:新的孵化项目Argo,Contour和Operator Framework。Rook现在是毕业项目。

自CNCF上次的中国调查以来,在生产中使用云原生项目的好处发生了转变:

  • 更快的部署时间首次成为最大好处,被47%的受访者引用。
  • 改进的可扩展性保留其早期的第二名,占35%。
  • 成本节省仍然排名第三,为33%。
  • 提高开发者生产力,云可移性和更高的可用性并列第四,受访者占31%。2018年11月,可用性排名第一,可移性排名第四。

无服务器

您的组织使用无服务器技术么?

在中国的调查中,36%受访者使用托管平台作无服务器,22%使用可安装软件。


您的组织使用哪个无服务器托管平台?

对于那些使用托管平台作为无服务器工具的企业,排名前三的提供商是阿里云功能计算(46%),AWS Lambda(34%)以及腾讯云无服务器云功能和华为FunctionStage并列(12%)。


您的组织使用哪个无服务器可安装平台?

对于那些使用可安装软件作为无服务器工具的用户,Kubeless排名第一(29%),其次是Knative(22%),以及Apache OpenWhisk(20%)。

2019年,我们在云原生存储和服务网络上增加了新问题。这些是流行的云原生项目,可在活跃生产环境中支撑这些优势:

存储


您的组织在生产中使用云原生存储项目么?

最常用的云原生存储项目是Ceph(24%),Amazon Elastic Block Storage(EBS)(23%)和容器存储接口(CSI)(18%)

服务网络


您的组织在生产中使用服务网络么?

中国云原生社区

CNCF现在在中国有近50个成员。中国还是CNCF项目的第三大贡献者(按贡献者和提交者计),仅次于美国和德国。

我们有一些中国公司的案例研究,包括:

  • 京东使用Harbor为其私有图像中央存储器节省了大约60%的维护时间。
  • 中国民生银行交付效率提高了3-4倍,并且使用Kubernetes资源利用率翻了一番。
  • 蚂蚁金服使用云原生技术,运营方面至少提升十倍。

我们还在中国开设了20,000多人参加的Kubernetes and Cloud Native课程,最近还完成了首届中国 Cloud Native + Open Source虚拟峰会。

中国社区以多种不同方式了解云原生技术。


您如何了解云原生技术?
Documentation 文件
Technical podcast 技术播客
KubeCon+ CloudNativeCon
Meetups and local events聚会和本地活动
Kubernetes blog  Kubernetes博客
Trade press articals, blogs行业刊物文章 ,博客
Articles文章
Technical Webinars 技术研讨会
CNCF website CNCF网站
Twitter
Kubernetes case studies Kubernetes案例研究
Business-orientied webinars 业务导向的研讨会
CNCF webinars CNCF研讨会
Industry Analyst Reports/Data 行业分析报告/数据
Case Study Podcasts 案例研究播客
Other其他

文档

72%的中国受访者通过文档了解了云原生技术。每个CNCF项目在其网站上都有大量文档,可在此处找到。

CNCF每年投资数千美元来改善项目文档。其中包括项目文档托管,添加教程,操作指南等。

活动

活动是受访者了解云原生技术的一种流行方式。

41%的受访者选择KubeCon + CloudNativeCon作为学习新技术的地方。下一个虚拟KubeCon + CloudNativeCon计划于11月17日至20日举行。

37%的受访者选择了聚会和本地活动,(例如Cloud Native Community Groups)作为了解云原生技术的一种方式。

网络研讨会

22%的受访者通过技术网络研讨会了解云原生技术,另有8%选择面向业务的网络研讨会,还有8%选择CNCF网络研讨会。

CNCF加强了其网络研讨会项目,并计划为中国观众安排定期的网络研讨会。您可以在此处查看即将到来的日程安排及录像,幻灯片和之前网络研讨会的回放。

关于调查方法和受访对象

非常感谢参与此调查的每个人!

该调查于2019年10月进行。该调查以中文进行,300名受访对象中97%来自亚洲。


您公司/组织的规模是?


您公司/组织的行业属于?
Financial services 金融服务
Government 政府
Healthcare医疗
Hotel and food services酒店和餐饮服务
Manufacturing制造
Media/Analyst媒体/分析
Non-profit非盈利
Professional services 专业服务
Technology技术
Transportation交通
Retail零售
Real estate, rental, leasing 房地产,租借,租赁
Scientific or technical services 科学技术服务
Software 软件
Telecommunications 通讯
Transportation and  交通和
Utilities 设备
Other 其他


您的工作职能是?

点击阅读网站原文


CNCF (Cloud Native Computing Foundation)成立于2015年12月,隶属于Linux  Foundation,是非营利性组织。
CNCF(云原生计算基金会)致力于培育和维护一个厂商中立的开源生态系统,来推广云原生技术。我们通过将最前沿的模式民主化,让这些创新为大众所用。扫描二维码关注CNCF微信公众号。
image

查看原文

赞 1 收藏 0 评论 0

Donald 发布了文章 · 11月11日

Gojek和谷歌云合作开发的FEAST加入LF AI & Data作为孵化项目

作者:Christina Harter

LF AI & Data 基金会--该组织正在构建一个生态系统,以支持人工智能(AI)、机器学习(ML)、深度学习(DL)和数据开源项目中的开源创新--今天宣布FEAST为其最新孵化项目。FeastFeature Store,特征商店)是个用于机器学习的开源特征商店。

今天,运行可操作机器学习系统的团队面临着许多技术和组织上的挑战:

  1. 模型对特征数据没有一致的视图,并且与数据基础结构紧密耦合。
  2. 在生产环境中部署新特征是困难的。
  3. 特征泄漏降低模型精度。
  4. 特征不能跨项目重用。
  5. 运营团队不能监控为模型提供数据的质量。

Feast是Gojek和谷歌云在2018年合作开发的,于2019年初开放源码。该计划旨在应付以下挑战:

  1. 提供单一的数据访问层,将模型从用于生成、存储和服务特征数据的基础结构中分离出来。
  2. 通过集中式存储将特征的创建与使用分离开来,从而允许团队在最少的工程支持下将特征交付到生产中。
  3. 为模型训练和在线服务提供实时准确的特征数据检索。
  4. 通过允许组织构建特征部件的共享基础来鼓励特征部件的重用。
  5. 提供以数据为中心的操作监视,以确保操作团队可以放心地大规模运行生产机器学习系统。

“创建Feast是为了解决我们在Gojek所面临的数据挑战,同时扩大叫车、送餐、数字支付、欺诈检测和其他无数用例的机器学习。”Feast的创始人Willem Pienaar表示:“在项目开源之后,我们看到了对软件的需求爆炸式增长,导致了强大的采用和社区增长。进入LF AI & Data基金会是我们走向分权治理和更广泛的行业采用和发展的重要一步。”

Kubeflow创始人Jeremy Lewi表示:“Feast进入LF AI & Data基金会,既是该项目的一个重要里程碑,也是对该项目在解决机器学习数据生产方面一些最困难问题方面所取得进展的认可。像Feast这样的技术有潜力塑造未来的机器学习堆栈,而且随着它在LF AI & Data的孵化,该项目现在拥有了理想的环境来扩展其社区,建立一流的开源特征商店。”

LF AI & Data执行董事Ibrahim Haddad博士表示:“我们非常激动地欢迎FEAST来到LF AI & Data,并帮助它在一个开放治理模式下的供应商中立环境中蓬勃发展。随着FEAST的加入,我们将增加数据类别下托管项目的数量,并期待我们的数据项目与所有其他项目加强合作,推动数据、分析和人工智能开源技术的创新。”

LF AI & Data通过广泛的服务支持项目,第一步是作为孵化项目加入。LF AI & Data将支持FEAST的中立开放治理,帮助培育项目成长。请查看文档,从今天开始使用FEAST。在GitHub上了解更多关于FEAST的信息,一定要加入FEAST-AnnounceFEAST-Technical-Discuss邮件列表,加入社区并保持最新的更新。

热烈欢迎FEAST!我们期待这个项目作为LF AI & Data基金会的一部分继续增长和成功。要了解如何与我们一起托管开源项目,请访问LF AI & Data网站

点击阅读网站原文


Linux基金会是非营利性组织,是技术生态系统的重要组成部分。
Linux基金会通过提供财务和智力资源、基础设施、服务、活动以及培训来支持创建永续开源生态系统。在共享技术的创建中,Linux基金会及其项目通过共同努力形成了非凡成功的投资。扫描二维码关注LFAPAC微信公众号。
image

查看原文

赞 0 收藏 0 评论 0

认证与成就

  • 获得 30 次点赞
  • 获得 1 枚徽章 获得 0 枚金徽章, 获得 0 枚银徽章, 获得 1 枚铜徽章

擅长技能
编辑

(゚∀゚ )
暂时没有

开源项目 & 著作
编辑

(゚∀゚ )
暂时没有

注册于 2018-12-13
个人主页被 1.9k 人浏览