Google

Google

Google Cloud Run 详细介绍

Andy_Lee 发表了文章 • 0 个评论 • 226 次浏览 • 2019-05-16 21:28 • 来自相关话题

#Cloud Run介绍 在旧金山举办的 Google Cloud Next 2019 大会上,Google 宣布了 Cloud Run,这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 Knative ...查看全部
#Cloud Run介绍
在旧金山举办的 Google Cloud Next 2019 大会上,Google 宣布了 Cloud Run,这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 Knative 项目,是 Knative 的 Google Cloud 托管版本,也是业界第一个基于 Knative + Kubernetes 的 Serverless 托管服务。

援引来自 Google Cloud 官方网站的介绍资料,对 Cloud Run 的定位是:

Run stateless HTTP containers on a fully managed environment or in your own GKE cluster.



在完全托管的环境或者自己的 GKE 集群中运行 Serverless HTTP 容器。



目前 Google Cloud 还处于测试阶段,尚未GA,而且暂时只在美国地区提供。
#Cloud Run 推出的背景
这里有一个大的背景:在 Knative 出来之前,Serverless 市场虽然火热,但是有一个根本性的问题,就是市场碎片化极其严重,有大大小小几十个产品和开源项目,而且存在严重的供应商绑定风险。因此,Google 牵头推出了 knative 开源项目,希望实现 Serverless 的标准化和规范化。如果你想和者更多 Serverless 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

关于Knative 的详细情况,这里不继续展开,有兴趣的同学可以阅读我之前的演讲分享 Knative: 重新定义Serverless
##Google Cloud 上的 Serverless
在 Cloud Run 出现之后,目前 Google Cloud 上就有三种 Serverless 产品了:

  1. Cloud Functions:事件驱动的 Serverless 计算平台
  2. App Engine:高可扩展的 Serverless Web应用
  3. Cloud Run:无状态的 Serverless HTTP 容器,口号是 Bringing Serverless to Containers

1.png

##Bring Serverless to Containers
这是 Cloud Run / Knative 区别于之前的各种 Serverless 产品的本质不同之处:支持的工作负载不再局限于 Function,而是任意容器!

备注:当然基本的容器运行时契约还是要遵守的,具体要求见下面的介绍。



和 Function 相比,以 Container 方式呈现的工作负载,给使用者更大的自由度,Google Cloud 对此给出的口号是:

* Any langurage / 不限语言
* Any library / 不限类库
* Any binary 不限二进制文件(备注:格式还是要限制的,要求 Linux x86_64 ABI 格式)
* Ecosystem of base images / 基础镜像的生态系统
* Industry standard/工业标准

2.png

Google Cloud Run / Knative 对容器的要求,和通用容器相比,强调 无状态(Stateless) / 请求驱动(request-triggered) / 可自动伸缩(autoscaled):
3.png

如上图所示,请求流量通常并非均匀分布,有突发高峰,有长期低谷,甚至有时没有流量。因此,从资源使用率的角度考虑,处理这些请求流量的服务容器的实例也应该随请求流量变化,做到自动伸缩,按需使用,以节约成本。
#Cloud Run的特性和要求
##Cloud Run 的特性概述
下图是整理的 Cloud Run 的几个主要特性,其核心还是那句口号 “Bring Serverless to Container”:
4.png


* 以容器形式出现的工作负载:不只是 Function,极大的丰富了 Serverless 的玩法
* 兼容 Knative API:这也是近年来 Google 的一贯打法,开源项目先行,对社区开放,拉拢盟友建立标准,以无厂商锁定的风险来吸引客户,我将其简称为”开源开放不锁定”。
* GCP 托管:托管的好处自然是客户无需运维,这也是 Serverless 的由来和最基本的特性
* 流量驱动模式:请求驱动,实例数量可自动伸缩,甚至伸缩到 0,因此无需在业务高峰时预先配置资源和事后手工释放资料,极大的减少运维需要。在此基础上,执行按使用付费,因此可以在不同的应用之间(在公有云上则可以在不同的客户之间)共享成本,以低成本的方式应付短期突发高并发请求。

Cloud Run 的其他特性还有:

* 快速从容器到生产部署
* 开发体验简单
* 高可用:自动跨区域的冗余
* 和 Stackdrive的集成,监控/日志/错误报告都是开箱即用
* 可自定义域名

这些特性容易理解,就不一一展开。
##适用于更多的场景
传统的基于 Function 负载的 Serverless,受限于 Function,适用范围相对有限,尤其不适合非 Function 方式编写的旧有应用,而将应用改造为 Function 一来工作量巨大,二来也不是所有的应用都适合用 Function 形式开发。

在以 Function 为负载的 Serverless 系统中,调用往往发生在外部对 Function 的访问,类似API Gateway下的南北向通信。Function 之间通常不直接相互调用(某些情况下需要调用时,往往也是走外部调用的通道),因此调用关系相对简单。
5.png

当工作负载从 Function 转变为 Container 之后,不仅仅有 Serverless 原有的南北向通信,而且以容器形态出现的工作负载之间相互调用的场景大为增加,这些负载之间的相互调用类似于传统SOA/微服务框架的东西向服务间通信。Cloud Run 通过支持容器作为工作负载,极大的扩大了 Serverless 的适用范围。
6.png

除了前面列出来的两种场景之外,Cloud Run 还可以适用于其他场景,如事件驱动/异步任务/调度服务等:
7.png

这也迎合了目前 Serverless 的发展趋势:未来 Serverless 将渗透到各种场景,任何需要按照请求自动实现资源动态调度的工作负载都应该 Serverless 化。我称之为:万物皆可 Serverless!从 Function 到 Container,Serverless 朝这个目标迈出了一大步。
##Cloud Run的并发模型
重点看一下 Cloud Run 对请求并发的处理,因为这涉及到如何动态调配服务容器实例的个数。

在 Cloud Run 中,每个服务都要自动伸缩容器的实例数量来应对请求流量。在 Cloud Run 中对并发(Concurrency)的定义是:

Concurrency = “maximum number of requests that can be sent at the same time to a given container instance”



并发 = “可以同时对给定容器实例发送请求的最大数量”



也就是我们平时理解的”最大并发请求数”,或者”最大工作线程数”。在这一点上,Cloud Run 的做法和 AWS Lambda 还有 Google 自己的 Cloud Function 不同,后两者的做法是每个实例只能同时接受一个请求,相当于 “Concurrency=1”。如图,当有多个并发请求时就需要启动多个实例。
8.png

而在 Cloud Run 中,并发度是可以设置的,容许的值范围是从 1 到 80,默认值是80,如下图所示:
9.png

如果并发度设置为 1 则 Cloud Run 的行为也就和 AWS Lambda/Google Cloud Function 一致了,不过对于容器形式的工作负载而言,容器启动和销毁的资源消耗和成本就有过高了,因此 Cloud Run 下通常建议根据实际业务场景设置合适的并发度/请求数上限。这样在处理请求时,可以用一个实例对应多个请求,从而不必启动太多的实例。
10.png

##Cloud Run对容器的要求
11.png

在 Google Cloud Run 的文档中, Container运行时契约 中列出了 Cloud Run 对容器的要求,主要包括:

* 语言支持,可以使用任意语言编写代码,可以使用任意基础镜像,但是容器镜像必须是为64位Linux编译的;Cloud Run 支持 Linux x86_64 ABI 格式。
* 请求监听,容器必须在 0.0.0.0 上监听,端口由环境变量 PORT 定义。目前在 Cloud Run 中,PORT 环境变量总是设置为 8080,但是为了可移植性,不能 hardcode。
* 启动时间和响应时间,容器实例必须在收到请求后的四分钟内启动HTTP服务器; 容器实例必须收到HTTP请求后的规定时间内发送响应,该时间由 request timeout setting 配置,包含容器实例的启动时间。否则请求会被终止并返回 504 错误。
* 文件访问,容器的文件系统是可写的并受以下影响:

* 文件系统是基于内存的,写入文件系统会使用容器实例的内存
* 写入到文件系统中的数据不会持久化

* 容器实例生命周期考虑,服务的每个版本都将自动伸缩,如果某个版本没有流量,则会缩减到 0。服务应该是无状态的,计算应该限定于请求的范围,如果没有请求则不能使用CPU。
* 容器实例资源,每个容器实例分配 1 vCPU 而且不能修改。每个容器实例默认 256M 内存,可以修改,最多为 2G。

请注意,Cloud Run 目前处于测试阶段,因此这些要求可能会随时间而发生变化。

Container Runtime Contract 更详细的信息,请参考:

* Google Container Runtime Contract
* Knative Container Runtime Contract
* Open Container Initiative Runtime Specification

##Cloud Run的限制
目前 Cloud Run 的限制有:

* 最多 1 个vCPU 和 2 G 内存
* 不能访问 GPU
* 没有 Cloud SQL (即将提供)
* 没有 VPS 访问(即将提供)
* 不支持全局负载均衡
* 只支持 HTTP (未来会支持gRPC)

而这些限制,都可以通过选择使用 Cloud Run on GKE 来解决。
##安全容器gVisor的使用
gVisor 是由 Google 开源的容器沙箱运行时(Container sandbox runtime)。用于在宿主机操作系统与容器中的应用之间创建一个安全的隔离边界,便于安全的对外提供大规模部署的容器服务——关于安全容器和 gVisor 的介绍就不在这里展开。

在 Cloud Run 中,容器是运行在 gVisor 之上的,而不是默认的Kubernetes runc runtime。gVisor为 Cloud Run 带来了安全容器的隔离,但是也带来了一些限制。如下图所示,gVisor 支持的 System Call 是有限的,不支持所有的 Linux System Call。但是考虑到 Cloud Run 的主要使用场景是无状态的 HTTP 容器,正常情况下应该不会触发这个限制。
12.png

#和 Knative 的关系
Google Cloud 给出的一些PPT中宣称 Cloud Run 就是托管版本的 knative,当然这一点我个人有些质疑:当前开源版本的 knative 实在有些不够成熟,应该还达不到生产级强度,Google Cloud 托管的有可能是 knative 的内部版本。但可以肯定的是,Cloud Run 一定是兼容 knative API 的。

目前 Knative 发展趋势非常不错,尤其社区快速成长,聚拢了一批大小盟友。这里有一份 Google 给出的长长列表,列出了当前参与 Knative 开发的贡献者来自的公司:

VMware, Huawei, Cisco, TriggerMesh, Dropbox, SAP, Microsoft, Schibsted, Apache, Independent, China Mobile NTT, CloudBees, Caicloud, Inovex, Docker, Heureka, CNCF, Liz Rice, Zalando, Douyu.com, Nebula. OpsGenie. Terracotta, Eldarion, Giant Swarm, Heroku, Revolgy, SORINT.lab, Switch, Ticketmaster, Virtustream,, Alipay, Blue Box, Cruise Automation, EPAM Systems, EVRY, Foreningen Kollegienet Odense, Giddyinc, IPB, Manifold.co, Orange, Puppet, Stark & Wayne, Weaveworks, Disney Interactive, Ivx, Mediative, Ministère de l’Agriculture et de l’Alimentation, NatureServe, Samsung SDS. Typeform, Wise2c



当然,其中最重要的力量还是来自 Google 自己,以及 Redhat、Pivotal、IBM 这三位社区巨头。下图是以公司为单位的贡献度比例:
13.png

下图是基于Knative 的几个主要 Serverless 产品,除了 Google 的 Cloud Run 之后,还有 Redhat / Pivotal / IBM 等大厂:
14.png

#Serverless 计算平台选择
Cloud Run 是一个 Serverless 计算平台,用于运行无状态 HTTP 应用程序。 它有两种风格:完全托管的环境或 Google Kubernetes Engine 集群。

  1. Cloud Run:完全托管,完整的serverless体验,客户不需要管理集群,按使用付费。
  2. Cloud Run on GKE:只具有 serverless 的开发体验,客户需要在自己的 GKE 集群中运行,价格包含在 GKE 集群中。

15.png

Cloud Run on GKE 具有和 Cloud Run 相同的开发体验,但是 Cloud Run on GKE 运行在 k8s 上,有更多的灵活性和控制力,不过需要自己运维。Cloud Run on GKE 可以集成基于k8s的策略、控制和管理。允许访问自定义计算机类型,额外的网络和GPU支持,以扩展Cloud Run服务的运行方式。

可以在 Cloud Run 和 Cloud Run on GKE 之间按需要选择,另外 Google Cloud 容许在 Cloud Run 和 Cloud Run on GKE 之间切换,无需改动应用。

Cloud Run 和 Cloud Run on GKE 的详细对比:
16.png

考虑到 Cloud Run 是 Knative 的 Google Cloud 托管版本,对于客户,则理论上在 Cloud Run 和 Cloud Run on GKE 之外还存在另外一种选择:直接使用开源版本的 Knative。
17.png

或者 Google 之外的其他基于 Knative 的产品,如Redhat / IBM / Pivotal 等,从而避免了供应商锁定的风险。

这也是 Google 在宣传 Cloud Run 产品是一直反复强调的:开源、开放、不绑定。

回到在 Google Cloud 上进行 Serverless 平台选择这个话题,现在 Google Cloud 上的 Serverless 有 Function / App / Container 三种模式,而其中的 Container 模式又可以细分为 Cloud Run 和 Cloud Run on GKE 两种形态,还有一个自由度极高可以自由发挥的GKE。下图摘录自 Google 的演讲PPT,做了很好的分类和总结:
18.png

#Cloud Run的计费
最后关注一下 Cloud Run的计费,Cloud Run 的官方文档 Pricing 对此有详细的描述,这里摘录部分内容。

首先,完全托管式的 Cloud Run 仅为使用的资源收取费用,计费到最近的100毫秒。而 Cloud Run on GKE 则不同,GKE 上的 Cloud Run 是 Google Kubernetes Engine 集群的附加组件。而 Cloud Run on GKE 部署的工作量包含在 GKE 定价中。而 GKE 上 Cloud Run 的最终定价要到 GA 才确定。

Cloud Run 的计费模型也颇具创新性,不是完全按请求数量计费,而是同时考量三个指标:CPU /内存/请求数量。搬运一下官方文档作为示意:
19.png

按照这个计费模型,将 concurrency 设置为合适的数值(起码不是1),让一个容器实例可以同时服务多个请求,分享 CPU 和内存,在费用上会更合适。另外上面的计费信息中可以看到,CPU /内存/请求数量都有免费配额,只有超过免费配额的使用才需要付费。免费配额会每月重置。

Cloud Run 对可计费时间的计算比较良心,只有在容器实例有请求在处理时才计算,从第一个请求开始到最后一个请求结束。而容器实例启动的时间和空闲的时间不计算在内,如下图所示:
20.png

#Cloud Run 分析
总结前面的功能介绍,我们可以看到,在 serverless 的常规特性和托管带来的运维便利之外,Cloud Run 的主要特性和卖点在于:

* 拥抱容器生态,将 Serverless 与容器结合,极大的扩展了 Serverless 的适用范围,对于 Serverless 市场是一个巨大的创新。对于习惯使用容器/微服务技术的客户,可以更好的迁移过来。
* 拥抱社区,基于开源的 Knative,拉拢社区和盟友,通过 Knative 实现 Serverless 的标准化和平台化,解决了 Serverless 市场碎片化的问题。
* 极佳的可迁移性,为客户提供了没有供应商锁定风险的解决方案。理论上客户可以根据实际需要选择完全托管的 Cloud Run 或 Cloud Run on GKE,或者开源版本的 Knative,以及其他基于 Knative 的托管平台,。
* 拥抱云原生技术栈,结合使用 Service Mesh 技术和安全容器技术,配合容器/kubernetes,用 Cloud Native 技术栈打通了从底层到上层应用的通道。

总结说,Cloud Run 是 Google Cloud 在 Serverless 领域的全新尝试,具有创新的产品思路,未来的发展值得关注和借鉴。
#参考资料
Cloud Run 刚刚发布才一个多月,目前能找到的资料不多,基本都是 Google Cloud 放出来的新闻稿/博客和官方文档,还有 Cloud Next 大会上的介绍演讲及 PPT。第三方的介绍文章非常的少,因此在调研和整理资料时不得不大量引用来自 Cloud Run 官方渠道的资料和图片。

* Cloud Run官网
* Cloud Run Overview:不到2分钟的介绍视频,官方宣传片
* Differences between Cloud Run and Cloud Run on GKE:官方视频,5分钟长度,展示 cloud run 和 Cloud Run on GKE 之间的相同点和不同点。
* Google Cloud Next’ 19 大会上和 Serverless 相关的演讲:主要信息还是来自 Next’ 19 的演讲,在这个页面中选择 “Serverless” 会列出本次大会和 Serverless 相关的演讲,大概十余个,视频可以回放,也提供PPT下载。(本文的大部分的信息和图片来自这些演讲内容),数量比较多就不一一列举了。

原文链接:Google Cloud Run详细介绍(作者:敖小剑)

在谷歌,女性力量正随 Kubernetes 一同成长

samzhang 发表了文章 • 0 个评论 • 356 次浏览 • 2019-04-23 10:38 • 来自相关话题

【编者的话】在科技公司中,技术部门通常以男性为主导。但如今,女性的力量同样不容忽视。今天的文章介绍了几位身居谷歌高层的女性,这也让我们对于女性技术人员有了一个新的认识。 
众所周知,计算行业中的信息技术部门往往存在严重的男性倾向,领导 ...查看全部
【编者的话】在科技公司中,技术部门通常以男性为主导。但如今,女性的力量同样不容忽视。今天的文章介绍了几位身居谷歌高层的女性,这也让我们对于女性技术人员有了一个新的认识。


众所周知,计算行业中的信息技术部门往往存在严重的男性倾向,领导团队中的女性数量则非常有限。然而,作为计算软件领域的一大突破性成果,Kubernetes 正在为寻求发展空间的女性软件工程师和女性项目经理提供肥沃的发展土壤。


在计算机领域,Kubernetes 已经掀起一场行业革命。它管理下的虚拟容器系统正迅速成长为最流行且高效的云应用运行方式。谷歌公司将 Kubernetes 项目捐赠给 Linux 基金会, 并随后创建了云原生计算基金会(简称 CNCF)。目前, Kubernetes 项目由云原生基金会负责运营,并凭借着开源项目这一定位吸引到整个数字社区的广泛支持。


尽管谷歌不再对 Kubernetes 项目拥有所有权,但却仍在积极参与贡献者社区的管理,旨在借此推动 Kubernetes 与 CNCF 的持续发展。虽然男性在 Kubernetes CNCF 社区中确实占据着更高比例,但其中不少最高级别也最为重要的谷歌参与者却身为女性。


我最近有幸与这些女性大牛进行了面对面交流,听她们讲述自己加入谷歌公司的历程,Kubernetes 为何吸引到她们的参与,以及在世界上最强大的公司之一扮演职业女性角色的心得体会。
##Chen Goldberg
chen-sa-2-150x150.png


Chen Goldberg 是 Goolge Cloud 高级工程总监,并管理着一支拥有几百名成员的团队。Goldberg 并不是计算机科班出身;在加入私有企业之前,她曾参与以色列国防部的信息技术工作。


“我喜欢解决实际问题的感觉,这让我感到非常兴奋,” Goldberg 说。“我认为这种多样化的背景使我能够对我们正在做的事情、以及我们正在努力成就的事物提供一个良好的视角”。
##Dawn Chen
dawnchengoogle-150x150.jpg


Dawn Chen 身为 Google Cloud 高级软件工程师,而且从起步阶段就一直在 Kubernetes 社区中拥有重要地位。从休斯敦大学获得计算机科学硕士学位后,Chen 在 GRIC Communications 工作了一年,随后以软件工程师的身份在赛门铁克公司工作了六年。2007 年,Chen 加入谷歌,她是 Borg 开发团队中不可或缺的一员——顺带一提,Borg 正是 Kubernetes 项目的前身。


Chen 在谷歌拥有超过 10 年的一线工作经验。“自从加入谷歌那天,我认为我已经以某种方式参与了 Kubernetes,也由此接触到开源与云基础设施领域,” Chen 回忆道。“当我最初加入 Borg 项目时,当时大家还在研究公用计算,也就是今天云计算的前身。”
##Sarah Novotny
novotnylinkedin-300x300.jpeg


Sarah Novotny 是 Google Cloud 的开源战略负责人,也是 Linux 基金会的董事会成员。在进入谷歌之前,Novotny 已经拥有很多头衔,并在几家公司担任过高管职位。


在 1990 年代后期,她在亚马逊公司担任系统工程师。她也曾经供职于游戏行业,担当 O’Reilly Media 的节目主持,在 NGINX 公司担任开发者关系负责人。直到 2015 年,当她正式加入谷歌开源部门时,正好赶上 Kubernetes 项目的全面腾飞。


回忆起她参与 Kubernetes 主题会议的点点滴滴时,她表示,“入职谷歌后的第二周,我就参加了第一届 KubeCon 大会。我特别关注项目的治理与整体健康状态。当时我们谷歌团队中有三名成员被调派参与 Kubernetes 生态系统,包括管理贡献者体验与提供治理建议,外加负责 Knative 与 Istio 相关的其他工作。”
##社区焦点


这些女性是 Kubernetes 生态中的有力推动者兼意见领袖。容器技术之所以能够不断得到开发者们的支持,无疑要归功于她们的卓越贡献。




Chen、Novotny 和 Goldberg 在采访当中无法抑制她们对于 Kubernetes 平台的兴奋之情。容器技术承诺给 IT 这个已经节奏飞快的行业带来更上一层楼的机遇。而从这些技术专家这里,我们反复听到的一大共识,正是对社区价值以及开源与云原生世界多样性的强调。


Goldberg 评论称, Kubernetes 项目非常特别,因为它有可能帮助到来自许多不同领域的人。“我们做的不是开源玩具,” 她说,“我们的项目是对人们真正有所帮助的东西,我们能够交付价值。 Kubernetes 团队面临的一大挑战在于,大家需要构建成果并将其集成到其他系统当中。通过我们对于 Kubernetes 的规划思路以及对生态系统及周边环境的投资,我们得以真正帮助众多团队与合作伙伴实现创新。”


Novotny 回应了这些想法。她强调称,“我们不仅要在代码方面投资,还应关注社区,治理以及人际往来。这一切,都是为了帮助项目的最终用户获得理想的投入或影响力回报,或者支持那些希望围绕 Kuberentes 项目建立业务的人们。”


尽管 Chen 在谷歌工作的时间比 Glodberg 和 Novotny 的总和还长,但她仍然保持着积极的工作热情。“我希望人们,无论在世界的任何地方,都能够享用到我的业务成果,” 她说。


这些女性当然很清楚技术领域中的性别差异问题,她们也都希望在自己力所能及的范围内为女性提供更多支持。尽管已然“位高权重”,Novotny 说,但她仍能感受到自己的男性同事们往往升得更高、也升得更快。


“职场对于女性确实不太友好,” Novotny 说。“女性也经常会评估自己的工作内容,而非关注自己所拥有的潜力。另外,虽然问题的核心并不能简单归结于判断,但过去 20 多年以来,这些判断确实拖累了女性的职业发展轨迹。”


Chen 希望赋予她的继任者权力,并以身作则。她是第一位拥有 “发布沙皇”头衔的女性 ——现在被称为 Kubernetes 发布经理,负责监督版本面向开源社区的发布工作。


“我个人认为我们需要更多的行业榜样,” Chen 说。“我们当然也需要改变文化。如果我们想要激励更多的女性、更多的年轻女孩进入科学和计算机科学,我们必须进行一场文化层面的变革。”


Goldberg 回忆起她在刚开始时受到行业榜样指导的经历,她现在希望能够回馈自己当时得到的帮助。“我会说,你必须付出代价,” 她说。当然,Goldberg 将这一切与她的工作联系在一起,这种态度也体现在她对团队成员们的具体管理方式上。


“我们都知道我们想做什么,而且我们都知道我们要如何做到。我们互相尊重,为我们客户的成功而欢呼,我们渴望他们达成目标,因为这是我们的责任,” 她说。也正如她做出的简短总结:“这样确实行得通。”

原文链接:At Google, women power the rise of Kubernetes(翻译:Sam)

谷歌发布Kubeflow 0.1版本,基于Kubernetes的机器学习工具包

YiGagyeong 发表了文章 • 0 个评论 • 1941 次浏览 • 2018-05-05 19:53 • 来自相关话题

【编者的话】Google 发布 Kubeflow 开源工具,旨在让数据科学家充分利用在 Kubernetes 集群上运行机器学习任务的优势。 自从 Google 发布开源容器编排工具——Kubernetes 以来,我们已经见证了其以各 ...查看全部
【编者的话】Google 发布 Kubeflow 开源工具,旨在让数据科学家充分利用在 Kubernetes 集群上运行机器学习任务的优势。

自从 Google 发布开源容器编排工具——Kubernetes 以来,我们已经见证了其以各种方式遍地开花的景象。随着 Kubernetes 越来越受欢迎,许多辅助项目也已经发展起来。现在,Google 发布了Kubeflow 开源工具 0.1 版本,该工具旨在将机器学习带入 Kubernetes 容器的世界。

虽然 Google 早已将 Kubernetes 迁移入 Cloud Native Computing Foundation ,但仍在积极参与该项目,发布 Kubeflow 就是很好的证明。该项目最初只是在去年底奥斯汀举办的 Kubecon 上宣布,但取得了不错反响。

在 Google 运营 Kubeflow 的 David Aronchick,加入Kubeflow之前,已经带领了 Kubernetes 团队两年半的时间。 他表示,该项目背后的想法是让数据科学家充分利用在 Kubernetes 集群上运行机器学习任务的优势。Kubeflow 可以让机器学习团队将现有任务轻松放到集群中运行,而无需作出太多改变。

随着今天的 0.1 版本的发布,该项目将开始推进,并将通过博客公布里程碑,将稳定性提高到一个新的水平,同时还会增加大量社区一直呼吁的新功能。其中包括为 Jupyter Hub 提供用于机器学习任务的协作和交互式训练以、Tensorflow 训练及托管支持等。

Aronchick 强调说,作为一个开源项目,你可以贡献任何你喜欢的工具,而不仅仅限于 Tensorflow,尽管早期的版本确实包含了对 Google 机器学习工具的支持。随着项目进一步发展,预计会有更多额外的工具支持。

在项目最初宣布后的 4 个月内,社区发展迅速,有 70 多个贡献者,20 多个捐助组织以及 15 个 repositoriy 中的 700 多个提交。可以期待一下,可能今年夏天的某个时候就会发布 0.2 版本。
# Kubeflow 0.1 简介
Kubeflow 0.1 提供了一套最精简的软件开发包,用于开发,训练和部署 ML。只需几个命令,就可以获得:

  • Jupyter Hub:用于机器学习任务的协作和交互式训练
  • TensorFlow 训练控制器:支持原生的分布式训练
  • TensorFlow 服务:用于服务托管
  • Argo:工作流
  • SeldonCore:用于复杂推断及非 TF 模型
  • Ambassador:反向代理
  • Wiring:可以使 Kubeflow 在任意 Kubernetes 上运行

下面是入门示例:
# 为 kubeflow 开发环境创建 namespace
NAMESPACE=kubeflow
kubectl create namespace ${NAMESPACE}
VERSION=v0.1.3

# #初始化 ksonnet 应用,设置 namespace 为其默认环境变量
APP_NAME=my-kubeflow
ks init ${APP_NAME}
cd ${APP_NAME}
ks env set default --namespace ${NAMESPACE}

# #安装 Kubeflow 组件
ks registry add kubeflow github.com/kubeflow/kubeflow/tree/${VERSION}/kubeflow
ks pkg install kubeflow/core@${VERSION}
ks pkg install kubeflow/tf-serving@${VERSION}
ks pkg install kubeflow/tf-job@${VERSION}

# #为核心组件创建模板
ks generate kubeflow-core kubeflow-core

# #部署 Kubeflow
ks apply default -c kubeflow-core

至此,JupyterHub 已部署,我们现在可以使用 Jupyter 开始开发模型。一旦有了 python 代码来构建模型,我们就可以构建一个 Docker 镜像并使用 TFJob 运算符通过运行如下命令来训练模型:
ks generate tf-job my-tf-job --name=my-tf-job --image=gcr.io/my/image:latest
ks apply default -c my-tf-job


# #下面部署模型

ks generate tf-serving ${MODEL_COMPONENT} --name=${MODEL_NAME}
ks param set ${MODEL_COMPONENT} modelPath ${MODEL_PATH}
ks apply ${ENV} -c ${MODEL_COMPONENT}

只需要几个命令,数据科学家和软件工程师就可以创建更复杂的 ML 解决方案,并专注于他们最擅长的事情:解决核心业务问题。

原文链接:Google Kubeflow, machine learning for Kubernetes, begins to take shapeAnnouncing Kubeflow 0.1(翻译:李加庆

谷歌正式发布其容器优化型操作系统

李颖杰 发表了文章 • 0 个评论 • 4291 次浏览 • 2017-04-05 18:57 • 来自相关话题

立足Google Cloud Platform实现容器技术“开箱即用”能力。 【上海站|3天烧脑式Spring Cloud训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、H ...查看全部
立足Google Cloud Platform实现容器技术“开箱即用”能力。

【上海站|3天烧脑式Spring Cloud训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。

相信任何一位关注IT动态的朋友都已经意识到,容器技术已然成为业界增长最快的成果之一。我们对于这一趋势感到振奋,并不断强化Google Cloud Platform(简称GCP)以确保其能够成为理想的容器运行平台。

目前市面上存在着众多出色的容器托管型操作系统,我们也对客户拥有如此丰富的方案选项感到高兴。不过仍有不少客户表示,尽管他们已经拥有自己的虚拟机方案,但其同样希望选择谷歌所使用的镜像,从而确保其能够拥有与各项谷歌服务相同的优化收益。

去年春季,我们发布了容器优化型操作系统(即Container-Optimized OS,此前曾被称为Container-VM镜像)的beta测试版本,其专门进行了优化以在GCP之上运行各类容器。我们利用容器优化型操作系统运行谷歌内部的多种产品服务(例如Google Cloud SQL以及Google Container Engine等等)。

今天,我们宣布容器优化型操作系统已经正式推出。这意味着如果您身为Compute Engine服务的用户,则可立即利用这套操作系统创建虚拟机实例(请参阅本文文末的示例),从而实现Docker容器“开箱即用”。

容器优化型操作系统代表着我们过去十年中以规模化方式运行容器时总结出的全部最佳实践:

* 受控构建/测试/发布周期:容器优化型操作系统的核心优势在于能够确保用户全面控制构建、测试与发布周期,并为GCP客户(包括谷歌自有服务)提供强化型内核功能与托管更新。发布可通过三种不同渠道实现(包括开发、beta与稳定版本),其各自拥有不同的早期访问与稳定性级别,可进一步提升迭代与发布周期的推进速度。
* 容器就绪型设计:容器优化型操作系统预安装有Docker容器运行时,同时支持Kubernetes以实现面向容器的超大规模部署与管理能力(即容器编排)。
* 在设计中充分考虑安全性需求:容器优化型操作系统在设计中充分考虑安全性需求。其最小化只读root文件系统能够有效削减攻击面,同时包含文件系统完整性检查机制。我们还在其中添加了锁定防火墙与审计日志记录功能。
* 事务更新:容器优化型操作系统采用一套主动/被动root分区机制,这意味着用户可以通过原子事务处理方式对包括内核在内的操作系统镜像进行整体更新,从而显著降低更新失败率。用户亦可以选择自动更新机制。

用户能够在Compute Engine之上通过容器优化型操作系统轻松实现虚拟机实例创建。大家可选择使用Google Cloud控制台GUI或者gcloud命令行工具,具体方法如下:
gcloud compute instances create my-cos-instance \
--image-family cos-stable \
--image-project cos-cloud

在实例创建完成之后,大家即可马上运行自己的容器。举例来说,您可以在刚刚创建完成的实例中通过以下命令运行一套Nginx容器:
gcloud compute ssh my-cos-instance -- "sudo docker run -p 80:80 nginx"

大家亦可通过以下命令在实例中进行登录:
gcloud compute ssh my_cos_instance --project my_project --zone us-east1-d 

再来看另一个简单示例,即利用Container Engine(采用容器优化型操作系统)以运行您的容器。此示例来自谷歌Container Engine快速入门页面。
gcloud container clusters create example-cluster
kubectl run hello-node --image=gcr.io/google-samples/node-hello:1.0 \
--port=8080
kubectl expose deployment hello-node --type="LoadBalancer"
kubectl get service hello-node
curl 104.196.176.115:8080

我们邀请您设置自己的容器优化型操作系统实例并在其上运行您的各类容器。感兴趣的朋友可以点击此处查看容器优化型操作系统的说明文档,亦可点击此处在Chromium OS库中找到其源代码。我们也期待着了解您对于容器优化型操作系统的使用感受反馈;大家可以在StackOverflow上配合google-container-os标签向我们提出问题。

原文链接:Container-Optimized OS from Google is generally available

2.12 K8S Meetup 回顾|Google·陈智峰《谷歌大脑近期工作进展介绍》

caicloud 发表了文章 • 0 个评论 • 1316 次浏览 • 2017-02-28 10:46 • 来自相关话题

2月12日,才云市场团队奔赴上海,在阿拉小优总部1楼举办了“Kubernetes Meetup 中国 2017”第一场——上海站。继 2016 年 Kubernetes Meetup 四城联动之后,才云 2017 年的 Meetup 阵容更加强大,布道城市范围 ...查看全部
2月12日,才云市场团队奔赴上海,在阿拉小优总部1楼举办了“Kubernetes Meetup 中国 2017”第一场——上海站。继 2016 年 Kubernetes Meetup 四城联动之后,才云 2017 年的 Meetup 阵容更加强大,布道城市范围更广,为更多 Kubernetes 爱好者带去技术分享。

嘉宾精彩演讲回顾

陈智峰《谷歌大脑近期工作进展介绍》
陈智峰博士现为谷歌大脑资深工程师,拥有 12 年谷歌工作经验,自 2014 年以来,他参与设计并实现了被广泛应用于重要谷歌产品的新一代谷歌大脑机器学习开源系统 TensorFlow,并成功将 TensorFlow 用于谷歌翻译之中,巨幅提高了谷歌翻译的准确率。谷歌大脑是专注于深度学习的人工智能的研究开发团队。
陈智峰此次的演讲通过介绍过去一年中谷歌大脑在基础研究、系统开发和产品应用各方面的进展,与参会者探讨了人工智能发展的前景和可能的方向。

以下是 Google 陈智峰带来的《谷歌大脑近期工作进展介绍》演讲内容:
大家好,很高兴跟大家分享谷歌大脑在过去一年的进展以及我的一些工作心得。
2014 年,Jeff Dean 带领开发 TensorFlow(以下简写成“TF”),当时希望 TF 能够支持更多容器,运用到更多领域,供更多开发研究人员使用。
2015 年下半年,谷歌开源 TF,整个团队觉得这个项目做得不错,于是在上面添加了更多性能,比如自动 differentiation,control flow 等,另外还增加了很多 operation。
最初,我们只是增加乘法、加法等一些简单的数据运算。去年,我们又添加了一些相对复杂的算法,很多矩行分解的支持,完善文档,增加教材式的文档。


幻灯片03.jpg


过去一年,我们也做了很多支持更多平台的工作。到目前为止,TF 在 Github 上已经有 500 多个贡献者,绝大多数都是 Google 以外的人,现在有超过 1 万多的 commits,据统计下载量超过一百万,在学校也很受欢迎。如果你去 Github 上找,你会发现很多以 TF 为基础的 repository。

幻灯片04.jpg


还有就是发布的一些基础架构软件,以及现成的模型,这些基本上都放在 models 下面(如下图所示),任何人都可以下载文件,做一些图像处理工作,以及自然语言处理,文本语法分析。

幻灯片06.jpg


TF 主要目的是把深度学习的好处带给大家,让大家都享受深度学习带来的好处。TF 不光是在单机上跑起来,我们也增加了对 mobile device 的支持,大概下半年的时候,iOS 上也可以跑 TF。大概 4 月份的时候,我们会发布分布式版本,所以不仅可以在单机上跑 TF,也可以在 AWS 上运行起来。我们还做了一些跟开源生态圈集成的事情,例如支持像 HDFS、Spark、Windows 以及其它的操作系统。

幻灯片07.jpg


目前,TF 也可以通过不同的前端语言进行使用:Python,Java 等等。

幻灯片08.jpg


TF 1.0 里面增加了稳定性和实用性,还会增加一个叫 XLA 的部分,可以把代码直接编译成机器码。

幻灯片09.jpg


但是,有人也会疑惑,做这些东西会对现实有什么影响吗?Alpha Go 再厉害,它也只是个游戏。同时,我们团队的成员也会疑惑 TF 到底会给现实世界带来什么影响?
那么接下来我们就来说一下 TF 带来的现实影响,同时也给大家介绍一下 TF 的学习架构。

幻灯片11.jpg



幻灯片10.jpg



说到 TF 的用途,最热门就是图像识别方向。
2011 年,机器进行图像识别的错误率为 26%,人工识别的错误率为 5%。到 2016 年,图片识别的错误率降低到了 3%。

幻灯片13.jpg


再讲一个 TF 运用在医疗方向的例子。
目前全球有 4 亿患者患糖尿病造成的视网膜病变,诊断过程很长。在印度、非洲等一些医疗设施相对不那么先进的地方,病症诊断专业度不够。谷歌大脑有个团队,增加视网膜图片扫描工具,专门用于扫描照片。让人高兴的是,现在已经可以通过图像识别技术来对病人进行诊断,而且准确率比医务人员能达到的还要高。

幻灯片14.jpg


再回过头来说,TF 对现实世界的具体影响。
比如,斯坦福的另外一个研究,基本上是用同样的方法来诊断皮肤癌。首先在医院拍一张照片,然后通过图像识别,来诊断是否皮肤癌。
TF 对现实世界的影响还表现在自然语言识别领域。
微软在 11 月的时候宣布,在类似语音识别领域,机器做得比人好。10 月份的时候,Google 宣布,他们能大幅提高机器翻译效果。

幻灯片18.jpg


这张图就是神经机器翻译的图。现在输入一个英文的句子,假设句子中有四个单词,然后这个模型就可以对句子进行分析,句子中每个词表示一个向量,每个向量都会经过一个很复杂的数学模块,最后就可以得出四个项目,这四个项目通过计算延到右边这个大的模块里面,然后模块再翻译成中文,最后一个字一个字地输出成中文。右边图中每一个小盒子都代表了一个很复杂的数值计算,每个小盒子都有几百万的运算要求,产生一个词都需要上亿的运算。
早在 2014 年,就有很多学校在做类似研究。研究小组从头到尾写一个模型,这个模型难以描述,训练起来非常困难,且计算量大。就单单一个模型来说,代码其实很简单,但可能需要一个月的时间来进行训练,于是需要转到 TF 模型。
TF 的一个好处就是支持分布式,它可以有很多参数、计算机服务器,能够充分利用资源。相比用 C++,用 TensorFlow 代码量会少很多。

幻灯片19.jpg



幻灯片21.jpg


单个语种的翻译,预测是 2-3 周的时间,每种语言大约超过 1 亿个模型的训练。Google 内部要支持 100 多种语言,每种语言之间都要实现互相翻译。所以如果要实现所有模型,非常耗时间。一般来讲,Google 进行翻译,原理就是把不同语言先翻译成英语,再将这些语言翻译成其它语言。所以真实翻译效果会差很多,而且成本也高。

幻灯片22.jpg


所以有人就想了一个项目,叫做 Multilingual models。

幻灯片23.jpg


Multilingual models 的思路非常简单,用上述的数学模型即可。但是当你训练这个模型的时候,要给它看不同语言的翻译,英文到日文的,英文到韩文的,同时也要给它看日文到英文的,韩文到英文的。而这个时候,你的模型是不会增大的,它只是阅读了不同语言的语料。

幻灯片24.jpg


训练这个模型的时候,一开始,我们只是抱着试一试的心态。但是在生产应用中我们惊喜地发现,这个模型不光能翻译日文到英文,还可以直接翻译韩文到日文,以及日文到韩文!之前我们完全没有想到会有这样的翻译效果。
在其它应用场景里面,也会有一些类似的现象。

幻灯片25.jpg


回到刚才,Google 在做翻译的时候,会把不同语言翻译成英文,再把英文翻译成你想要的语言,这样的话,对于所有自然语言来讲,英文就是表达的中介语言。
上图讲述的就是,表述同一个意思的不同语言的句子,map 到一个二维空间上,然后发现很多语言都有共性远远大于它们之间存在的差异性。
比如说同样一句话,不管是日语还是韩语,它表达的意思都在上图 b 这个圈里,这是一个比较有趣的现象。
通过“机器训练”这个模型,聚集到一起,达到提高翻译水平的效果。

幻灯片26.jpg


然后 Google Brain 不光是做 TF,内部还要很大一部分人在做很前沿的研究。
其实不管是图像识别还是 sequence modeling,其实它的核心概念都可以追溯到十几二十年前。
图像识别的核心可以追溯到 1999 年乃至更之前,机器翻译则可以追溯到 1997 年的 LSTM 甚至更早,一直到 GPU 出现,令这些模型计算更快,模型的效果才显现出来。


幻灯片28.jpg


当然,现在的技术不能解决所有的问题,有些思路还在被探索开发。
刚才讲的谷歌翻译模型,它们对于人的大脑来说是十分小的。Google 的翻译大概是 2 亿 5 千万个参数。但是人大概有 100 倍乃至 1000 倍的神经元。所以 Google Brain 认为,如果你给它更大的模型,更多的数据,那么效果肯定会更好。当然,一种 idea 如何集成为一个更大的模型其实还是受很多信息的限制的。


幻灯片29.jpg


我们可以有很多很多专家,比如说 2000 个专家,每个专家的特长领域都不同,如果我有问题的话,我要先去找哪个专家呢?我会一步一步来解决我的问题。然后具体呢,大家可以看一下,是一个highlight point。

幻灯片30.jpg


比如我刚才讲的谷歌翻译的模型,现在发布的版本大概是 2 亿 5 千万个参数。比如里面有 2000 个 Export,这个模型翻译的效果比我们现在发布的模型要好很多。虽然现在你可以建一个 10 倍大(乃至 100 倍)的模型,当然也会有很多问题,这只是一个设想,就是说如果机器越多,模型越多,那么效果就会越逼近人的智能。
大家有兴趣可以看下这些论文,不光是 Google Brain,很多实验室也在往这个方向努力。

幻灯片31.jpg


另外一个比较有趣的现象就是:learning to learn。如果你看过去几年里深度学习的“套路”,比如你要解决一个人工智能问题,然后用深度学习的方法,必须要有三个要素:在这个领域有专长的专家;有大量的数据;以及很强的计算能力。对于很多公司来讲,数据和计算能力可以购买。但是由于这个领域比较新,所以深度学习领域专家是比较少的。
那么遇到的问题就是,能否找到专家的替代,或者说减少对这些专家的依赖?

幻灯片33.jpg


Google 有两个研究人员,他们写了一篇论文,基本就是说,你构造一个机器学习模型,就像是大家平常写一个程序一样,类似于某个机器在玩游戏的过程,终极目标就是:解决遇到的问题。
比如下一盘棋,那么目标就是赢这盘棋。但是策略是什么呢?这时候,你可以随机生成很多很多这样的程序,这些程序里面,有的运行得好,有的运行得不好,你可以给不同的程序打分,对高分程序进行强化学习,指导搜索过程,找到更好的模型。

幻灯片34.jpg


这个说的就是,参数越多,表达能力就越强。
图中最后四行是程序搜索出来的模型,这个模型在这个测试中,错误率可以降低到 3.84%,去年最低的结果是 3.74%。
所以将来大家遇到问题,比如说你在下棋,你想赢,你就搜索一个方案,这些方案要比你手动去设置模型要有效。整个机器学习领域非常快,几年后这个方向或许就会有大的突破。
大家会觉得图像识别模型已经有了,为什么还要去生成这样的一个模型?你不光可以通过程序生成这样一个图像识别模型。
比如你公司里有很多数据库,你可以 想象能不能产生一个meta program,这个 meta program 通过机器学习的方法产生 database 的 program。

幻灯片35.jpg


深度学习非常依赖计算能力,深度学习模型涉及到很多数值运算。它有个比较大的特点:对述数值运算监控能力很高。核爆炸模拟的时候,要精确到 32 位甚至更高;但是在机器学习模型里面,你会发现其实不需要精确到 32 位;16 位甚至 8 位就可以解决问题。
去年,谷歌内部在做 TPU 芯片,它就是 8 位或者 16 位的,而且价钱要比 CPU 或者 GPU 要便宜很多,低耗能,结构上也要简单很多,速度也有提高。现在硅谷也在做这方面的事情,所以我觉得这两年这方面将会有很大的突破。

幻灯片38.jpg


最后给大家总结一下:大家可以感受到,这两年人工智能(特别是深度学习)的发展非常快,在各个应用领域都表现非凡,相信未来还有更多领域会用到它,期待它的表现。

下载演讲嘉宾 PPT 请关注 Caicloud!或者点击https://mp.weixin.qq.com/s?__biz=MzIzMzExNDQ3MA==&mid=2650093191&idx=1&sn=93960069acfc348c8ee1b2e06f4c5fcc&chksm=f08b088ec7fc81984eff84b1590cdfbfc26361f60e32f449d00dc4528538d3111c4802d62cd9#rd点击“阅读原文”进行下载!

关于云原生的一些思考

kurtzhong 发表了文章 • 0 个评论 • 2463 次浏览 • 2017-01-07 20:00 • 来自相关话题

# 第一部分:定义 在Craig和我开始打造Heptio的时候,我们做了不少关于我们行业发展方向的思考。我们在Google里呆了很久的时间(两个人加起来的日子有16年了),对于Google构建和管理系统的方式有很深入的理解。但是很可能你没有在Goo ...查看全部
# 第一部分:定义
在Craig和我开始打造Heptio的时候,我们做了不少关于我们行业发展方向的思考。我们在Google里呆了很久的时间(两个人加起来的日子有16年了),对于Google构建和管理系统的方式有很深入的理解。但是很可能你没有在Google任职的经历。那么对于一个普通的公司、开发或者运维人员,应该如何理解并应用这些不断演变的新概念呢?

云原生意味着什么,并没有一个固定或死板的定义。实际上,还有一些与之重叠的概念和思想。但在它云原生的核心,是对团队、文化和技术的精心组织,利用自动化和架构的力量来掌控复杂度,突破速度的束缚。在这种模式下的运作,不但是一种技术的扩张方式,更是一种人力的扩张方式。

很重要的一点是,不一定要在云环境中运行才能叫“云原生”。这其中的技术可以在恰当的时候叠加地采用,并且帮助向云过渡的过程变得顺畅。

云原生的真正价值所在远不止与之密切相关的一篮子技术。要真正的理解行业的动向,我们需要思考我们能从哪些地方用什么途径让公司、团队和个人更加成功。

目前,这些技术已经被那些以技术为中心且眼光高远的公司验证,它们为此做出了努力并投入了大量的资源。想想Google、Netflix或者Facebook。同样也有规模更小,灵活性更高的公司实现了价值。然而,除在这些技术的早期采用者之外,这套哲学理念却少见有利用。 当把目光投射到整个IT领域,我们仍然在这条旅程起点不远的地方。

随着早期的经验不断被验证和分享,如今都有哪些涌现的主题呢?

* 更有效率和更开心的团队。云原生的工具让大的问题切分成小的问题,便于分工让更专注和更敏捷的团队来解决。

* 减少枯燥重复的劳动,通过将很多人工操作自动化,也避免了因为人工操作引发的运维上痛苦和停机时间。这一般是通过自愈合、自管理基础设施来达成。系统被期望解决更多的事情。

* 更可靠的基础设施和应用。构建用来处理一些可预见的故障的自动化流程,通常对不可预见的事件和故障是更好的失效模式。举个例子,如果部署开发的应用只需要一个命令或者点击一下按钮,那在灾难恢复的场景下(通过手动或自动的方式)进行自动化部署也更加的容易。

* 可审计,可察视,可调试。复杂的系统会变的非常晦涩难懂。云原生使用的工具,通常能让人对应用内部发生的事情有清楚的了解。

* 深度的安全性。如今很多IT系统的外壳都很坚固,但内在都很脆弱。现代的系统默认情况下应该有安全防护,采取最小信任(least trust)策略。云原生让应用开发者能在应用安全方面扮演重要的角色。

* 资源的更高效的利用。应用和服务的自动化式的、类云环境的部署及管理方式,开启了自动化的算法化机遇。比如,一个集群调度器/编排器可以自动完成工作负载的安放,而不需要运维团队用类似excel的方式进行管理。

在Heptio,我们特别兴奋我们能帮助更广阔的IT领域得到云原生的恩惠。在接下来的部分,我们将讨论与已有的系统进行整合,DevOps,容器和编排,微服务和安全。
# 第二部分:实践
与任何正在经历变革的领域一样,云原生世界中有繁杂的概念。上一个部分列举的概念,不是每人个人都清楚应该如何恰当地利用。同时,很多关键的项目,要么太庞大,要么太重要,不适合重头重写。因此,我们觉得最好把这些新的结构用在新的项目或者老项目的新部件中。在系统老的部件得到了改善后,然后再花时间合理地学习并采用其他新技术。寻找把新的特性或者系统分解成微服务的方式。

没有硬性的规则。每一个机构都是不同的。软件开发的实践必须要根据身边的团队和项目来做出调整。理想不同于现实。有的项目经得起实验折腾,但是很多非常重要的项目应该采取更加谨慎的态度。还有一些场景是介于两者之间的,一些技术即使已经被验证过,但仍需要规范化并且经过大规模的测试,之后才能应用到核心系统上。

云原生的定义中离不开的更好的工具和系统。没有这些工具链,每一个新部署在生产环境的服务都会有很高的运维成本。监控,跟踪,配置等等都增加了一个处理的负担。这个额外的开销是对微服务大小的切分应该合理的主要原因之一。开发团队的速率和在生产环境中运行更多(服务)的成本,这两者的利弊需要权衡。类似的,新的技术和语言引入,尽管可能新鲜刺激,也必须仔细考虑其风险和代价。关于这个话题,Charity Majors有一个非常好的演讲

要降低构建和运行新服务中的运维成本,自动化是关键。像Kubernetes、容器、CI/CD、监控等等这样的系统,都有一个相同的重要目标 - 让应用开发和运维团队的效率更高行动更快,让打造的产品更可靠。

要达到云原生的愿景,最好使用新一代的工具和系统,而不是传统的配置管理工具,因为它们有助于分解问题然后分工给不同的团队处理。通常来讲,新的工具通常能让独立的开发和运维团队拥有自主权,然后通过自服务(self service IT)提高生产力
# 第三部分:DevOps
不妨将DevOps看成一种文化的转型,开发者现在需要关心他们的应用是怎样在生产环境中运行的。而运维也对应用的运作机制有了认识并且授予了知情权,从而可以在帮助打造可靠应用方面发挥重要作用。增进这些团队之间的理解和建立同理心是关键。

但是可以更进一步。如果我们重新思考我们的应用的构建过程和运维团队的结构组成,我们能进一步加深这种关系。

Google没有传统意义的运维团队。相反,Google定义了一种新的叫做SRE(Site Reliability Engineer,网站可靠性工程师)的工程师。他们是技能扎实的工程师(报酬同其他的工程师处同一个水平)他们不但随时保持在线,同时得到授权并被赋予通过自动化来在推动应用变得更加稳固方面扮演至关重要角色的重望。

当在凌晨两点报警触发的时候,任何响应该报警的人都会做同一件事情 - 努力弄清出了什么问题,好早点回去继续睡觉。真正定义一个SRE的地方是第二天早上10点钟发生的事情。运维组的人是否只会抱怨,还是会和开发团队一起协作保证同样的报警不会再次出现?在让应用变得尽可能稳定可靠方面,SRE和开发团队有一样追求。结合不追责的的事后剖析,可以保持项目的健康,不让技术债务堆积。

SRE在Google是最被看重的人群之一。在实际中,很多项目在没有SRE参与启动的时候,开发团队肩负了让他们的产品在生产环境中运行起来的期望。引入SRE团队的流程,通常需要开发团队向SRE团队证明他们的产品已经准备到位。开发团队需要已经做好了所有的准备工作,包括设置好监控和报警,报警的应对策略和发布流程。开发团队要能显示出报警的情况已经达到了最少的程度,并且绝大多数的问题已经被自动化了。

随着运维的角色参与程度更深,与特定的应用相关度更高,让一个运维团队掌控整个运维栈变得不合理。这引出运维规范(Operations Specialization)的问题。从某种意义来说这是一种
“反DevOps(anti-devops)”的做法。让我们来自下而上的看:

* 硬件运维。这一层很显然可以分离出来。实际上,很容易把云IaaS看成是“硬件运营即服务(Hardware Ops as a Service)”。

* 操作系统运维。必须有人保证机器能够顺利启动,并且有一个好的内核。将这一部分从应用的依赖管理中分离出来也反映出了用来托管容器的操作系统发行版(CoreOS, Red Hat Project Atomic, Ubuntu Snappy, Rancher OS, VMWare Photon, Google Container Optimized OS)的最小化趋势。

* 集群运维。在容器化的世界中,一个计算的集群变成了一个逻辑上的基础设施平台。集群系统(Kubernetes)提供了一组原语能让很多传统的运维任务自服务化。

* 应用运维。每一个应用现在可以根据需要拥有一个专门的应用团队。若有必要,开发团队有能力并且应该担任起这个角色。这种运维团队应该更深入应用,因为他们不需要在其他的层次上专研太深。比如,在Google,AdWords的前端SRE团队会和AdWords Frontend的开发团队交流很多,超过他们与集群团队之间的交流。这能带来更好的成果。

很可能还有其他专业性的SRE团队的空间。例如,存储服务可能会划分成单独的服务,或者根据某种政策,可能有团队来负责验证所有团队使用的基础容器镜像。
# 第四部分:容器和集群
有很多人对于容器相关技术兴奋不已。了解为什么大家如此兴奋的的根本原因是有益处的。在我看来,有三个原因:

  1. 打包和移植性
  2. 效率
  3. 安全性

让我们依次地来看。

首先,容器提供了一种打包机制。这能让系统的构建从这部署流程中分离开来。另外,构建的成品和镜像比传统的方式如虚拟机移植性更好。最后,部署变得更加的原子化。传统的配置管理系统(Puppet,Chef,Salt,Ansible)很容易让系统处于一种配置不完整的、很难调试的状态。也很容易在机器中残留一些不易被发现的错误版本。

第二,容器更轻量化,使得资源利用率增加。这是当Google引入cgroups(容器底层的主要核心技术之一)时的一个主要原因。通过共享一个内核,并且允许更流体化的过量使用(fluid overcommit),容器更容易让系统资源每一部分都不浪费(“use every part of the cow”)。随着时间的推移,有望看到更加复杂的用来均衡单个主机上共存容器需求的方式,杜绝吵闹邻居问题。

最后,很多用户把容器看做是一个安全性界限。尽管容器可以比一个简单的Unix进程更安全,当把它们看做是一个硬的安全性边界的时候还是要注意。Linux命名空间提供的安全保证对于那些运行半信任工作量的“软”多租户环境来说合适,但对于那些运行充满敌意的工作量的硬多租户环境却不适用。

有从很多方面的努力来在模糊容器和虚拟机的界限。一些早期研究如unikernel很有意思,但是很多年内尚不能应用于生产。

要达到上述目标,容器尽管是一条简单的途径,但却不是必要的途径。例如,Netflix,传统以来一直运行一个非常现代化的技术栈,它们以类似使用容器的方式,来打包并使用虚拟机镜像。

尽管绝大多数围绕着容器的努力集中于在单个节点上管理软件,使之更加可靠和可预测,这个改革的下一步集中于集群(通常也被称作编排器)。给定一批节点然后把他们和自动化系统绑定起来,为开发和运维团队提供了一组逻辑基础设施的自服务

集群能帮助消除运维中枯燥乏味。有了容器集群我们让计算机来接管工作,决定负载应该由哪台机器来处理。集群也会默默的在硬件失效的时候修复问题,而不是需要去通知某人。

集群的第一个好处就是它启用了运维的规范(见第三部分)可以让应用运维作为一个单独的学科来努力。通过定义个以良好的集群接口,应用开发者们能集中于解决应用自身的一些问题。

集群的第二个好处是它让启动并管理更多的服务成为可能。从而允许使用能为开发团队高速率的架构(通过下一部分介绍的微服务)。
# 第五部分:微服务
微服务是一个已经存在很久的概念的一个新名称。基本上,它是一种将一个大的应用进行切分的方法,使得他们能独立地进行开发和管理。让我们看看此处相关的关键概念:

* 强大和清晰的接口。服务之间的紧耦合必须避免。配套了清晰文档和有版本管理的接口有助于强化这种协定,对于这些服务的消费者和生产者同时又都能保有一定的自由度。

* 独立的部署和管理。微服务应该能够单个更新,无需和其他的服务一起同步进行。同时,大家也都很希望能够轻松地回滚一个微服务的版本。这意味着部署的二进制文件必须在API上和任何数据格式方面保持向前和向后兼容。这可以作为检验运维和开发团队之间的合作和沟通程度的试金石。

* 由内打造的耐受性。微服务应该构建成为并经测试验证有独立的耐受性的。在消费的服务不可用或者异常的时候,那些消费一个服务的代码应该要努力保持正常工作并且做出合理响应。同样的,那些提供的服务应该对于未曾预料的负载和异常输入做好防护。

确定微服务的大小是一个很难做对的事情。我的意见是要避免选择小的过分的服务(pico-services),反之将服务按照自然的边界(编程语言,异步队列,伸缩的要求)进行切分,同时保持团队大小合理(例如:两个披萨团队)。

应用的架构应该能允许以一种切合实际并且自然的方式增长。与其以20个微服务开始,不如从2到3个开始,然后随着该领域复杂度再对服务进行拆分。经常对一个应用的架构的认识直到应用在处于开发阶段才会变得透彻。这也说明了很少有已经竣工完成的应用,他们都总是一个正在施工的工程。

微服务是一个新概念吗? 非也。这其实是另外一种类型的软件组件化(software componentization)。我们过去把代码切分成库。这只是把“链接器”从一个构建阶段的概念转变成了一个运行时的概念(实际上,Buoyant有一个有意思的项目叫做linkerd,其基于Twitter Finagle系统。)。这与多年前的SOA潮很相似,只是不见了各种样式的XML。数据库从另外一个角度看,一直以来几乎是一个微服务,因为它实现和部署的方式都满足上面列的点。

约束可以转变成生产力。 尽管,很容易让每一个团队各自决定在每一个微服务上使用什么语言或框架,但不妨考虑下规范化,定下几种语言或者框架。这么做有助于机构内部的知识技术交流积累,更好应对人员流动。但是,在必要时也要有打破政策的开放心态。这是比起PaaS的垂直式集成结构,这个世界中的一个关键优势,换句话说,约束应该是来自政策层面的,而不是来自技术能力层面(constraints should be a matter of policy rather than capability)。

尽管绝大多数人把微服务看做是实现一个大型应用的技术,服务光谱(services spectrum)中还有很多其他类型的服务:

  1. 服务作为实现细节。正如上面描述过的一样,这对于把一个大的应用团队切分成小的开发和运维团队很有用。

  1. 成果共享,实例私用(Shared Artifact, Private Instance)。在这种场景中,开发过程通过服务的很多实例间共享。有可能有一个开发团队和很多运维团队,或者很可能一个联合的运维团队,在共享专门的实例间工作。很多数据库属于这种类型,很多团队都在使用同一个MySQL安装的私有实例。

  1. 实例公用。这种场景下,机构中的一个团队为很多应用或者团队提供一个共享的服务。服务可能会将数据或者操作按照用户(多租户)进行分区,或者提供一个用途广泛的简单服务(如展示一个通用的品牌条HTML,提供机器学习模型等)。

  1. 大型服务(Big-S Service)。绝大多数的企业不会打造这种的服务,但是可能会使用他们。这是一个典型的“硬性”的多租户服务,用来构建来为大量的分散的客户提供服务。这种服务需要某种层次的记账和加固,通常在企业内是不必要的。SendGrid和Twilio属于这一类。

随着服务从一种实现细节变成一种企业内常见提供的基础实施,服务网络从一个每应用的概念变成了能跨越整个公司的概念。允许这种依赖是一个既有机遇也有忧患。
# 第六部分:安全
注:本文中没有覆盖到新出现的“云原生”中与安全相关方方面面。但同时,尽管我不是一个安全专家,安全却是我整个职业生涯都有在关注的事情。请把它当做是值得考虑的事项清单的一部分。

安全仍然是云原生领域中的一个大问题。以往的技术无法完美的应用,在起初云原生可能看起来在开倒车。但在这片无畏的领域,同时也充满了各种机遇。
## 容器镜像安全
有很多的工具可以帮助对容器镜像进行审计,以确保它们完整地包含了各种补丁。众多选择中,我没有什么很强个人偏好的。

真正的问题在于,在发现了一个有漏洞的镜像之后该怎么做呢?这一块市场尚未提供很好的解决方案。一旦有漏洞的镜像被检出,事情就从一个技术问题变成了一个程序/流程问题。你会想着去找出机构中哪些组件受到了影响,问题应该在容器镜像层级树的什么地方进行修补,以及用什么好办法来进行测试并且发布新的打好补丁的版本。

CD/CD(持续集成/持续部署)是应对良策中的重要内容,因为它可以快速自动地发布新镜像。其与编排系统的集成能让你找出哪些用户正在使用有漏洞的镜像。同时它也能让你验证生产环境上是否采用了已经修复好的版本。最后,部署系统的策略能帮助阻止那些使用有漏洞镜像的容器启动(在Kubernetes的中,这被称作准入(admission))。
## 微服务和网络安全
但即使集群上所有运行的软件都已经是修复过的,也并不能保证网络中有没有不受信任的活动。

在以动态调度、存时短暂为特征的容器世界中,传统的基于网络的安全工具无法发挥理想的效果。存时短暂的容器可能存活时间过短,以至于传统的扫描工具无法及时扫描到。又或者被扫描到了且扫描报告已经生成,奈何相关容器却已经不存在了。

在动态的编排器中,IP地址不再拥有长久的意味,且它们是可以被自动复用的。解决方案是将网络分析工具和编排器集成,让逻辑名称(结合其他元数据)可以和IP地址一并使用。这可能可以让报警更加容易处理一点。

很多网络技术都利用了封装技术来实现“一容器一IP”。这可能会给网络追踪和诊断工具带来问题。如果生产环境上部署了这样的网络系统,那这些工具必须要做出相应改进。幸运的是,VXLAN、VLAN中的很大一部分都都已经被标准化了,或者不采用封装或者虚拟化,以便这些系统都能利用这些支持工具。

然而,个人看法,最大的问题还是跟微服务相关的问题。当在生产环境中运行了很多服务的时候,很有必要确保某特定的服务只能被授权的客户端调用。另外,因为有了IP的重复使用,客户端需要能知道调用的服务是正确的服务。大体上说来,目前这还是一个没有解决的问题。要处理这个问题,有两个(并不互斥的)方案。

首先,让实现主机级别的防火墙规则(在任何的容器之外)的网络系统和选项更灵活,以便能细粒度控制访问策略,来控制某些容器能被其他哪些容器调用。我把这个称之为网络的微隔离(network micro-segmentation)。这里的挑战之一在于在动态调度下如何进行策略的配置。尽管尚处于起步阶段,有很多的公司正在努力简化这一点,通过在网络中添加支持,或者同编排器协作,又或者过在处于高层次的应用中进行定义。一个很大的问题是,服务的使用范围越广,微隔离的效果就越小。如果一个服务有成百的调用者,“拥有访问权即意味着得到授权(access implies authorization)”的简单模型不再适用。

第二个方案是让应用在实现数据中心内的认证和加密中扮演更加重要的作用。这对于那些客户端众多、并且在大的机构中已经形成“软多租户”状态的服务适用。这需要有一个生产环境服务的身份系统。我已经开始一个叫做SPIFFE(Secure Production Identity Framework For Everyone,给大家使用的生产环境安全身份系统框架)的业余项目。这些理念已经在Google这样的公司得到了验证,但是还没有在其他地方施行。

安全是一个很深入的话题,这里肯定有很多威胁和注意事项没有涉及到,还需要持续的探讨。

到这里,我们的云原生系列文章就结束了。欢迎大家在Medium留下自己的想法,或者在Twitter上联系jbeda,cmcluck或者heptio。


原文链接:

* Cloud Native Part 1: Definition
* Cloud Native Part 2: In Practice
* [Cloud Native Part 3: DevOps
](https://blog.heptio.com/cloud-native-part-3-6f9d888c5f07#.xjj0zlzrt)
* Cloud Native Part 4: Containers and Clusters
* Cloud Native Part 5: Microservices
* Cloud Native Part 6: Security

翻译:钟最龙

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(下)

Dataman数人科技 发表了文章 • 0 个评论 • 2046 次浏览 • 2016-11-11 15:22 • 来自相关话题

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)

Dataman数人科技 发表了文章 • 0 个评论 • 4713 次浏览 • 2016-11-10 17:54 • 来自相关话题

谷歌GAE运维揭秘:如何做到每天处理超过1000亿个请求

caicloud 发表了文章 • 0 个评论 • 2490 次浏览 • 2016-04-14 18:10 • 来自相关话题

文章由才云科技翻译,如若转载,必须注明转载自“才云科技” 在这篇博客帖中,我们请到了Chris Jones(他做了三年半Google App Engine运维工程师,到目前为止已经当了9年的谷歌运维工程师),来探索更多关 ...查看全部
文章由才云科技翻译,如若转载,必须注明转载自“才云科技”


在这篇博客帖中,我们请到了Chris Jones(他做了三年半Google App Engine运维工程师,到目前为止已经当了9年的谷歌运维工程师),来探索更多关于在Google上运行产品系统的细节。Chris也是《Site Reliability Engineering: How Google Runs Production Systems》这本书的编辑之一,该书由 一直处于互联网发展前沿的O’Reilly Media出版,现在已经可以买到。

Google App Engine每天都服务超过1000亿个请求。就像你听说的那样,是我们的运维工程师让这成为可能。这的确有点像是魔术,将计算机科学和工程原则运用到编程系统的设计和开发中——这个总体来说是十分庞大。
谷歌运维是一套工程方法,让我们或者任何人更好的运行产品系统。它将运维的推广到更大的IT社区。它用有趣的方式来大规模提高性能和可靠性,这对于任何公司来说都是有用的。做得好的话,SRE技术可以提高操作编程服务的效率。

Q:Chris,能告诉我们有多少SRE在操作App Engine吗,现在有多大规模呢?

Chris:我们每天有百万级以上的应用程序在处理1000亿以上的请求,支持的SRE大概几十个的样子。

Q:只有那么少的人,是如何做到这样的规模的呢?

Chris:SRE也是一个工程方法,它可以操作大规模分布式编程服务。但是让系统高度标准化也是有争议的。高度标准化意味着所有的系统工作都是相似的,这也就意味着对操作人员的需求越来越小了,因为操作的复杂性大大降低了。
自动化也十分重要:我们的启动进程是全自动的,所以我们可以很好地用计算机来对这些进程进行扩容,而不是雇更多的人。如果想要将人放到进程上,那会显得很无趣,很多余。你会发现错误飙升。计算机的对错误的反应次数远远比我们人要来得多,而且快。在我们还没有注意到错误的时候,计算机就已经在将流量引到另一个数据中心了,同时保证服务继续运行。让人做人擅长的事情,让计算机做计算机擅长的事情。

Q:在SRE模式后,还有什么其他的方法吗?

Chris:因为有很多SRE团队在处理Google的服务,所以我们可以在产品上扩展标准化原则:SRE-创建工具原本是用于部署新版本的Gmail 的,例如,可以被整理来覆盖更多的场景。这也就意味着每个团队都不需要再自己创建方法来部署更新。这就确保每个产品在工具提升之后,都会得到改进,这就使得整个系统更好的使用工具。
另外, 软件工程和系统工程知识的结合,令解决方案囊括两者优点。谷歌的软件网络负载均衡器,Maglev,就是一个例子———而且它是Google云平台负载均衡器的底层技术。

Q:那么这些方法是如何影响App Engine和我们运行在AppEngine上的用户的呢?

Chris:我说个故事来阐述这个。在2013年的夏天,我们将所有App Engine的美国区域从国家的一边转移到另一边。这个举动招致没有停工期给我们的用户。

Q:怎么做到的呢?
Chris:我们先关闭一个App Engine集群,然后就如设计的那样,在上面运行的apps自动移动到了剩下的集群。我们早就事先在目标数据中心创建了美国区域的High Replication Database(https://www.youtube.com/watch?v=xO015C3R6dw)的复本,这样那些应用程序的数据(PB级别的数据!)就在该在的地方;对数据存储的修改是自动复制的,这样就可以实时更新。当在新的本地打开App Engine的时候,apps自动被分配到那个从他们备份集群中转移的集群,而且他们所有的数据是已经在适当的地方了。然后我们用剩下的集群来重复进程,直到我们完成之后。
事先准备,将大量的测试和应变计划结合,这就意味着当事情出错时候可以将冲击减少到最小。当然,我们将内部事后析误——SRE如何工作的另一个重要部分——放在一起来理解到底什么出错了,以及如何修复对长远比较好,没有指责。

Q:So cool!那么我们如何找关于SRE更多的消息?
Chris:如果你对SRE是如何在Google运行很感兴趣的话,那么就点击这个网站:https://landing.google.com/sre/,我们这周(四月7-8)也会在SREcon:https://landing.google.com/sre/就这个话题给出不同的演讲。

文章由才云科技翻译,如若转载,必须注明转载自“才云科技”
原文链接:https://cloudplatform.googleblog.com/2016/04/lessons-from-a-Google-App-Engine-SRE-on-how-to-serve-over-100-billion-requests-per-day.html#rd?sukey=fa67fe3435f5c4be3949a9675fc67882cf48cbb960b0e1aa61baa0775aec8768a7021ae7ef0c528c263a73e8161551a8

想要了解更多关于Kubernetes的信息,欢迎关注Caicloud公众平台

图片_1副本.png

谷歌容器管理10年记

liguangcheng 发表了文章 • 0 个评论 • 4080 次浏览 • 2016-03-26 22:55 • 来自相关话题

【编者的话】本文介绍了过去十年谷歌在容器管理方面的实践,包括了Borg,Omega和Kubernetes的历史和架构方面的比较,谷歌在其内部使用容器的概况,以及谷歌试图通过社区来推动其Kubernetes成为容器管理标准的努力。 @C ...查看全部
【编者的话】本文介绍了过去十年谷歌在容器管理方面的实践,包括了Borg,Omega和Kubernetes的历史和架构方面的比较,谷歌在其内部使用容器的概况,以及谷歌试图通过社区来推动其Kubernetes成为容器管理标准的努力。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。

容器的概念和实现并不是搜索引擎巨头谷歌发明的,但是谷歌却通过在上百万的服务器上编排和运行了数以亿计的容器帮助Linux操作系统的容器技术日趋完善。谷歌有很多经验可以分享,但依然谦虚的认识到也还有很多需要学习的地方。

这或许是其中最重要的一个原因使得谷歌在两年前决定开源其容器管理系统Kubernetes。谷歌过去通过发表论文向业界展示通过它的高精尖技术处理大规模环境下中的分析、存储和计算问题。但是这种方式有时候产生事与愿违的效果,例如谷歌的MapReduce理论被雅虎用来实现Hadoop进而孵化出了一个全新的领域。现在,谷歌如果不将其技术和标准贡献给社区让业界来遵从,谷歌将跟整个业界不兼容。

因此我们认为Kubernetes是谷歌的一次尝试,通过分享技术到社区以此推动该容器管理系统的开发,期望在将来能够替代其在内部使用了多年的集群管理的核心Borg,就像他们的名字暗示的那样其中包含了许多不同的技术(例如几年前产生的Omega调度器)。这次,谷歌希望能够得到社区的帮助,目前已经有超大规模集群以及HPC方面的专家在帮助充实Kubernetes以解决其只能支持单一的工作负载的问题,虽然在谷歌内部已经有5,000到50,000个节点的集群,但是其上运行的负载还是相对单一的。

在谷歌内部创建和扩展Brog的跟创建Kubernetes的核心开发团队是同一组人,他们继续在Kubernetes项目中有很大的影响力。这包含了Kubernetes的共同创立者Brendan Burns;过去8年一直在致力于集群管理系统工作的谷歌主管软件工程师John Wilkes;Borg容器管理系统的技术负责人、Brog的扩展组件Omega的创建者、Kubernetes的设计负责人Brian Grant;Kubernetes技术负责人David Oppenheimer;谷歌负责基础设施的副总以及加州大学伯克利分校的教授Eric Brewer。

谷歌发布了两篇介绍其容器管理系统的技术文章起到了重要的作用,第一篇是2013年10月发表的介绍Omega的文章,在介绍Omega的文章发布之后的2013年11月份在大规模系统管理会议(Large Installation System Administration conference)上Wilkes做了精彩的演讲。这解释了谷歌的Borg系统,同时这些信息的批露是在2014年夏天Kubernetes发布之前。在Kubernetes发布之后,带来了不少关于Omega和Borg之间关系的困扰,在2015年4月份发表的第二篇文章解释了谷歌的对于大规模集群管理的视角,在文章发表后,我们也采访了Wikes得到了更多谷歌关于容器和集群调度的洞察。

从事Borg,Omega和Kubernetes工作的谷歌顶尖工程师们ACM Queue上发表了另外一篇更通俗的文章描述了谷歌过去十年间在容器管理方面的经验和教训,提供了更多关于谷歌认为或者说希望看到Kubernetes社区前进的方向。

事实证明了Borg并不是这个搜索引擎巨头创造的第一个集群和应用管理工具。谷歌跟其它所有的公司一样有批处理工作负载和长期运行工作负载的组合,它在物理上将不同的工作负载运行在不同的集群里。一个叫做Babysitter的项目运行长期运行工作负载(例如Web服务和其它基础设施服务),同时另外一个叫做Global Work Queue的项目运行批处理工作负载例如孵化了Hadoop而谷歌仍然在继续使用的MapReduce大数据分析框架。但是,在不同集群里运行不同的应用会造成经常性的计算资源浪费,这对在过去十年快速成长的谷歌来说是不可接受的。

关于软件容器,即使是在十年前也不能算是一个新概念。我们甚至可以说1989年克隆大型机制造商Amdahl提出的PR/SM逻辑分区就已经是容器,毫无疑问IBM自己System z主机系统上的的虚机操作系统产生的虚机在本质上也是软件容器,直到今天还作为在主机系统上运行Linux实例的后台技术。FreeBSD有Jail partitions,Solaris最终也有了自己的容器技术。但是谷歌作为一个Linux公司不得不进行大量的工作在Linux内核中添加容器相关的功能。现在在每一个Linux发行版中都存在的LXC容器技术是在谷歌的工作的基础上创建的,而Docker是这项工作的另外一个分支。

在某种程度上来讲,Kubernetes借鉴了单一化的Borg系统和更加灵活的Omega系统的技术(使得多种工作负载可以共享资源而不必只是排队等待),最终结果是Kubernetes成为谷歌的第三个容器管理系统。如果Kubernetes的复杂程度和规模持续增加的话它可能会成为另外一个Borg,而我们认为这是谷歌的其中一个目标。从另外一个角度来讲,就像我们前面说的那样,谷歌希望Kubernetes能成为容器管理的事实上的标准,这使得构建企业级私有云的用户更有可能去使用谷歌的基于Kubernetes构建的Google Cloud Platform公有云服务。

从谷歌发布的最新文章中透漏出的关于其容器管理系统从裸机到容器的转变的重要信息是意义深远的,这或许对谋求容器作为更好的方式的人来讲不是显而易见的,我们认为这是相比与抬高服务器利用率的服务器虚拟化来讲更廉价的一种方式。一切都变成了应用为中心而不是服务器为中心,这正是IT公司们梦寐以求的天堂。工作负载调度器、集群管理系统和容器管理器协同工作当应用需要时为应用提供正确的容量,不管应用是延迟敏感的负载或者是对延迟不敏感的批处理负载,工程师和开发人员所需要关注只是应用的运行状态,而他们可以非常容易的获取应用运行的状态因为所有的关于状态的API调用都是在应用层面的而不是服务器层面的。

这意味着容器时代的到来,在谷歌里将不在有裸机,这可以作为给那些HPC厂商和其它超大规模集群厂商以及云服务提供商的一堂课,他们还认为需要运行在裸机模式下(我们听所在AWS上运行的很多大数据服务运行在裸机上而不是用定制版Xen Hypervisor支持下的EC2计算实例)。这不是一个确定的结论,但是在些许性能损失(其实比整机使用KVM或者Xen进行虚拟化的性能损失还是小很多的)和容器带来的管理与部署灵活性之间看上去绝对是一个非常划算的折衷。(如果Intel想解决这个问题,可以在每一个芯片中增加一个容器管理核心就足够了,或者在Xeon服务器芯片中用两个或者三个核来运行Hypervisor)。

“容器的隔离性和最小依赖被证明了在谷歌是非常有效的,容器已经成为了谷歌基础设施上运行的唯一实体”, 文章的作者写道,“一个结果就是现在谷歌在任何时间只有很少数量的操作系统版本部署在所有的服务器上,这就只需要很少的人员去维护和更新操作系统版本”。

使用Kubernetes,容器是一个应用程序的运行时,而作为构成微服务的多个容器被聚合到一个更高层次的被称为pod的概念中。Kubernetes最重要的是一个pod管理系统来使得这些容器集合能够协作和运行。Borg有一个类似的架构,Linux容器作为最细的粒度和Allocation的最底层。Allocation,缩写为alloc,是容器集合的一个上层包装。Borg允许某些容器在alloc之外运行,文章的作者说“这是造成诸多不便的原因”,这或许还是一个非常保守的陈述。Kubernetes则不允许你这么做。然而如果在丢安全或者隔离性有更高要求的场合例如在多租户环境的公有云中你可以在容器内运行容器,或者在一个虚拟机内部运行容器。事实上,谷歌在它的Cloud Platform里就是这么做的。一个服务器上运行了一个巨大的容器,在这个容器之上运行了KVM Hypervisor或者其它容器来向公有云上的用户暴露不同的Google Engine实例类型。

就像Omega通过收集和使用谷歌集群状态信息来更好的分配资源给容器化的批处理应用和在线应用,Kubernetes则实行了严格统一的API来跟集群进行接口 – 不像Brog在过去若干年增加了很多的API类型和风格。

“Kubernetes的设计中微服务和小的控制回路的组合是一个通过编排进行控制的例子 – 通过组合协作中的分散和自治实体来达到期望的效果”,谷歌最近这的篇文章中说,“与集中式的编排系统相比Kubernetes是一种更精巧的设计,集中式的编排系统可能在开始时相对较容易,但是随着时间的推移特别是在出现不可预知的错误或者状态变化时就会变得容易出现问题。”

我们的整体印象是Kubernetes是一个虽然还有那么一点不成熟但是却是一个比Borg更好的工具,仅仅是Kubernetes这一个工具就会给整个IT业界一个很大的影响。

谷歌将它过去十年在容器和集群管理方面的经验回馈给开源社区,甚至在它帮助Berkeley的AMPLab推动Mesos系统的开发之后,Mesos系统目前已经被Mesophere商业化。这或许是谷歌后悔做的事情(译者注:指推动Mesos的发展),但是开源Kubernetes对谷歌来说确实是一个艰难的决定。唯一的另外一个可能选项是让Mesos变成像Hadoop一样的另外一个事实上的标准,我们已经看到这件事情的现状了,这显然不是谷歌想要的。谷歌是唯一一个不能轻易从它自创的MapReduce转到Hadoop的超大集群运营者,这意味着它基础设施软件开发的成本从长期来看将持续上涨。

原文链接:A Decade Of Container Control At Google(翻译:李光成)

=================================
译者介绍
李光成,IBM中国研究院资深研究员,研究方向是云计算基础设施及技术。目前在做的是Docker资源隔离方面的研究项目。

Google Cloud Run 详细介绍

Andy_Lee 发表了文章 • 0 个评论 • 226 次浏览 • 2019-05-16 21:28 • 来自相关话题

#Cloud Run介绍 在旧金山举办的 Google Cloud Next 2019 大会上,Google 宣布了 Cloud Run,这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 Knative ...查看全部
#Cloud Run介绍
在旧金山举办的 Google Cloud Next 2019 大会上,Google 宣布了 Cloud Run,这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 Knative 项目,是 Knative 的 Google Cloud 托管版本,也是业界第一个基于 Knative + Kubernetes 的 Serverless 托管服务。

援引来自 Google Cloud 官方网站的介绍资料,对 Cloud Run 的定位是:

Run stateless HTTP containers on a fully managed environment or in your own GKE cluster.



在完全托管的环境或者自己的 GKE 集群中运行 Serverless HTTP 容器。



目前 Google Cloud 还处于测试阶段,尚未GA,而且暂时只在美国地区提供。
#Cloud Run 推出的背景
这里有一个大的背景:在 Knative 出来之前,Serverless 市场虽然火热,但是有一个根本性的问题,就是市场碎片化极其严重,有大大小小几十个产品和开源项目,而且存在严重的供应商绑定风险。因此,Google 牵头推出了 knative 开源项目,希望实现 Serverless 的标准化和规范化。如果你想和者更多 Serverless 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

关于Knative 的详细情况,这里不继续展开,有兴趣的同学可以阅读我之前的演讲分享 Knative: 重新定义Serverless
##Google Cloud 上的 Serverless
在 Cloud Run 出现之后,目前 Google Cloud 上就有三种 Serverless 产品了:

  1. Cloud Functions:事件驱动的 Serverless 计算平台
  2. App Engine:高可扩展的 Serverless Web应用
  3. Cloud Run:无状态的 Serverless HTTP 容器,口号是 Bringing Serverless to Containers

1.png

##Bring Serverless to Containers
这是 Cloud Run / Knative 区别于之前的各种 Serverless 产品的本质不同之处:支持的工作负载不再局限于 Function,而是任意容器!

备注:当然基本的容器运行时契约还是要遵守的,具体要求见下面的介绍。



和 Function 相比,以 Container 方式呈现的工作负载,给使用者更大的自由度,Google Cloud 对此给出的口号是:

* Any langurage / 不限语言
* Any library / 不限类库
* Any binary 不限二进制文件(备注:格式还是要限制的,要求 Linux x86_64 ABI 格式)
* Ecosystem of base images / 基础镜像的生态系统
* Industry standard/工业标准

2.png

Google Cloud Run / Knative 对容器的要求,和通用容器相比,强调 无状态(Stateless) / 请求驱动(request-triggered) / 可自动伸缩(autoscaled):
3.png

如上图所示,请求流量通常并非均匀分布,有突发高峰,有长期低谷,甚至有时没有流量。因此,从资源使用率的角度考虑,处理这些请求流量的服务容器的实例也应该随请求流量变化,做到自动伸缩,按需使用,以节约成本。
#Cloud Run的特性和要求
##Cloud Run 的特性概述
下图是整理的 Cloud Run 的几个主要特性,其核心还是那句口号 “Bring Serverless to Container”:
4.png


* 以容器形式出现的工作负载:不只是 Function,极大的丰富了 Serverless 的玩法
* 兼容 Knative API:这也是近年来 Google 的一贯打法,开源项目先行,对社区开放,拉拢盟友建立标准,以无厂商锁定的风险来吸引客户,我将其简称为”开源开放不锁定”。
* GCP 托管:托管的好处自然是客户无需运维,这也是 Serverless 的由来和最基本的特性
* 流量驱动模式:请求驱动,实例数量可自动伸缩,甚至伸缩到 0,因此无需在业务高峰时预先配置资源和事后手工释放资料,极大的减少运维需要。在此基础上,执行按使用付费,因此可以在不同的应用之间(在公有云上则可以在不同的客户之间)共享成本,以低成本的方式应付短期突发高并发请求。

Cloud Run 的其他特性还有:

* 快速从容器到生产部署
* 开发体验简单
* 高可用:自动跨区域的冗余
* 和 Stackdrive的集成,监控/日志/错误报告都是开箱即用
* 可自定义域名

这些特性容易理解,就不一一展开。
##适用于更多的场景
传统的基于 Function 负载的 Serverless,受限于 Function,适用范围相对有限,尤其不适合非 Function 方式编写的旧有应用,而将应用改造为 Function 一来工作量巨大,二来也不是所有的应用都适合用 Function 形式开发。

在以 Function 为负载的 Serverless 系统中,调用往往发生在外部对 Function 的访问,类似API Gateway下的南北向通信。Function 之间通常不直接相互调用(某些情况下需要调用时,往往也是走外部调用的通道),因此调用关系相对简单。
5.png

当工作负载从 Function 转变为 Container 之后,不仅仅有 Serverless 原有的南北向通信,而且以容器形态出现的工作负载之间相互调用的场景大为增加,这些负载之间的相互调用类似于传统SOA/微服务框架的东西向服务间通信。Cloud Run 通过支持容器作为工作负载,极大的扩大了 Serverless 的适用范围。
6.png

除了前面列出来的两种场景之外,Cloud Run 还可以适用于其他场景,如事件驱动/异步任务/调度服务等:
7.png

这也迎合了目前 Serverless 的发展趋势:未来 Serverless 将渗透到各种场景,任何需要按照请求自动实现资源动态调度的工作负载都应该 Serverless 化。我称之为:万物皆可 Serverless!从 Function 到 Container,Serverless 朝这个目标迈出了一大步。
##Cloud Run的并发模型
重点看一下 Cloud Run 对请求并发的处理,因为这涉及到如何动态调配服务容器实例的个数。

在 Cloud Run 中,每个服务都要自动伸缩容器的实例数量来应对请求流量。在 Cloud Run 中对并发(Concurrency)的定义是:

Concurrency = “maximum number of requests that can be sent at the same time to a given container instance”



并发 = “可以同时对给定容器实例发送请求的最大数量”



也就是我们平时理解的”最大并发请求数”,或者”最大工作线程数”。在这一点上,Cloud Run 的做法和 AWS Lambda 还有 Google 自己的 Cloud Function 不同,后两者的做法是每个实例只能同时接受一个请求,相当于 “Concurrency=1”。如图,当有多个并发请求时就需要启动多个实例。
8.png

而在 Cloud Run 中,并发度是可以设置的,容许的值范围是从 1 到 80,默认值是80,如下图所示:
9.png

如果并发度设置为 1 则 Cloud Run 的行为也就和 AWS Lambda/Google Cloud Function 一致了,不过对于容器形式的工作负载而言,容器启动和销毁的资源消耗和成本就有过高了,因此 Cloud Run 下通常建议根据实际业务场景设置合适的并发度/请求数上限。这样在处理请求时,可以用一个实例对应多个请求,从而不必启动太多的实例。
10.png

##Cloud Run对容器的要求
11.png

在 Google Cloud Run 的文档中, Container运行时契约 中列出了 Cloud Run 对容器的要求,主要包括:

* 语言支持,可以使用任意语言编写代码,可以使用任意基础镜像,但是容器镜像必须是为64位Linux编译的;Cloud Run 支持 Linux x86_64 ABI 格式。
* 请求监听,容器必须在 0.0.0.0 上监听,端口由环境变量 PORT 定义。目前在 Cloud Run 中,PORT 环境变量总是设置为 8080,但是为了可移植性,不能 hardcode。
* 启动时间和响应时间,容器实例必须在收到请求后的四分钟内启动HTTP服务器; 容器实例必须收到HTTP请求后的规定时间内发送响应,该时间由 request timeout setting 配置,包含容器实例的启动时间。否则请求会被终止并返回 504 错误。
* 文件访问,容器的文件系统是可写的并受以下影响:

* 文件系统是基于内存的,写入文件系统会使用容器实例的内存
* 写入到文件系统中的数据不会持久化

* 容器实例生命周期考虑,服务的每个版本都将自动伸缩,如果某个版本没有流量,则会缩减到 0。服务应该是无状态的,计算应该限定于请求的范围,如果没有请求则不能使用CPU。
* 容器实例资源,每个容器实例分配 1 vCPU 而且不能修改。每个容器实例默认 256M 内存,可以修改,最多为 2G。

请注意,Cloud Run 目前处于测试阶段,因此这些要求可能会随时间而发生变化。

Container Runtime Contract 更详细的信息,请参考:

* Google Container Runtime Contract
* Knative Container Runtime Contract
* Open Container Initiative Runtime Specification

##Cloud Run的限制
目前 Cloud Run 的限制有:

* 最多 1 个vCPU 和 2 G 内存
* 不能访问 GPU
* 没有 Cloud SQL (即将提供)
* 没有 VPS 访问(即将提供)
* 不支持全局负载均衡
* 只支持 HTTP (未来会支持gRPC)

而这些限制,都可以通过选择使用 Cloud Run on GKE 来解决。
##安全容器gVisor的使用
gVisor 是由 Google 开源的容器沙箱运行时(Container sandbox runtime)。用于在宿主机操作系统与容器中的应用之间创建一个安全的隔离边界,便于安全的对外提供大规模部署的容器服务——关于安全容器和 gVisor 的介绍就不在这里展开。

在 Cloud Run 中,容器是运行在 gVisor 之上的,而不是默认的Kubernetes runc runtime。gVisor为 Cloud Run 带来了安全容器的隔离,但是也带来了一些限制。如下图所示,gVisor 支持的 System Call 是有限的,不支持所有的 Linux System Call。但是考虑到 Cloud Run 的主要使用场景是无状态的 HTTP 容器,正常情况下应该不会触发这个限制。
12.png

#和 Knative 的关系
Google Cloud 给出的一些PPT中宣称 Cloud Run 就是托管版本的 knative,当然这一点我个人有些质疑:当前开源版本的 knative 实在有些不够成熟,应该还达不到生产级强度,Google Cloud 托管的有可能是 knative 的内部版本。但可以肯定的是,Cloud Run 一定是兼容 knative API 的。

目前 Knative 发展趋势非常不错,尤其社区快速成长,聚拢了一批大小盟友。这里有一份 Google 给出的长长列表,列出了当前参与 Knative 开发的贡献者来自的公司:

VMware, Huawei, Cisco, TriggerMesh, Dropbox, SAP, Microsoft, Schibsted, Apache, Independent, China Mobile NTT, CloudBees, Caicloud, Inovex, Docker, Heureka, CNCF, Liz Rice, Zalando, Douyu.com, Nebula. OpsGenie. Terracotta, Eldarion, Giant Swarm, Heroku, Revolgy, SORINT.lab, Switch, Ticketmaster, Virtustream,, Alipay, Blue Box, Cruise Automation, EPAM Systems, EVRY, Foreningen Kollegienet Odense, Giddyinc, IPB, Manifold.co, Orange, Puppet, Stark & Wayne, Weaveworks, Disney Interactive, Ivx, Mediative, Ministère de l’Agriculture et de l’Alimentation, NatureServe, Samsung SDS. Typeform, Wise2c



当然,其中最重要的力量还是来自 Google 自己,以及 Redhat、Pivotal、IBM 这三位社区巨头。下图是以公司为单位的贡献度比例:
13.png

下图是基于Knative 的几个主要 Serverless 产品,除了 Google 的 Cloud Run 之后,还有 Redhat / Pivotal / IBM 等大厂:
14.png

#Serverless 计算平台选择
Cloud Run 是一个 Serverless 计算平台,用于运行无状态 HTTP 应用程序。 它有两种风格:完全托管的环境或 Google Kubernetes Engine 集群。

  1. Cloud Run:完全托管,完整的serverless体验,客户不需要管理集群,按使用付费。
  2. Cloud Run on GKE:只具有 serverless 的开发体验,客户需要在自己的 GKE 集群中运行,价格包含在 GKE 集群中。

15.png

Cloud Run on GKE 具有和 Cloud Run 相同的开发体验,但是 Cloud Run on GKE 运行在 k8s 上,有更多的灵活性和控制力,不过需要自己运维。Cloud Run on GKE 可以集成基于k8s的策略、控制和管理。允许访问自定义计算机类型,额外的网络和GPU支持,以扩展Cloud Run服务的运行方式。

可以在 Cloud Run 和 Cloud Run on GKE 之间按需要选择,另外 Google Cloud 容许在 Cloud Run 和 Cloud Run on GKE 之间切换,无需改动应用。

Cloud Run 和 Cloud Run on GKE 的详细对比:
16.png

考虑到 Cloud Run 是 Knative 的 Google Cloud 托管版本,对于客户,则理论上在 Cloud Run 和 Cloud Run on GKE 之外还存在另外一种选择:直接使用开源版本的 Knative。
17.png

或者 Google 之外的其他基于 Knative 的产品,如Redhat / IBM / Pivotal 等,从而避免了供应商锁定的风险。

这也是 Google 在宣传 Cloud Run 产品是一直反复强调的:开源、开放、不绑定。

回到在 Google Cloud 上进行 Serverless 平台选择这个话题,现在 Google Cloud 上的 Serverless 有 Function / App / Container 三种模式,而其中的 Container 模式又可以细分为 Cloud Run 和 Cloud Run on GKE 两种形态,还有一个自由度极高可以自由发挥的GKE。下图摘录自 Google 的演讲PPT,做了很好的分类和总结:
18.png

#Cloud Run的计费
最后关注一下 Cloud Run的计费,Cloud Run 的官方文档 Pricing 对此有详细的描述,这里摘录部分内容。

首先,完全托管式的 Cloud Run 仅为使用的资源收取费用,计费到最近的100毫秒。而 Cloud Run on GKE 则不同,GKE 上的 Cloud Run 是 Google Kubernetes Engine 集群的附加组件。而 Cloud Run on GKE 部署的工作量包含在 GKE 定价中。而 GKE 上 Cloud Run 的最终定价要到 GA 才确定。

Cloud Run 的计费模型也颇具创新性,不是完全按请求数量计费,而是同时考量三个指标:CPU /内存/请求数量。搬运一下官方文档作为示意:
19.png

按照这个计费模型,将 concurrency 设置为合适的数值(起码不是1),让一个容器实例可以同时服务多个请求,分享 CPU 和内存,在费用上会更合适。另外上面的计费信息中可以看到,CPU /内存/请求数量都有免费配额,只有超过免费配额的使用才需要付费。免费配额会每月重置。

Cloud Run 对可计费时间的计算比较良心,只有在容器实例有请求在处理时才计算,从第一个请求开始到最后一个请求结束。而容器实例启动的时间和空闲的时间不计算在内,如下图所示:
20.png

#Cloud Run 分析
总结前面的功能介绍,我们可以看到,在 serverless 的常规特性和托管带来的运维便利之外,Cloud Run 的主要特性和卖点在于:

* 拥抱容器生态,将 Serverless 与容器结合,极大的扩展了 Serverless 的适用范围,对于 Serverless 市场是一个巨大的创新。对于习惯使用容器/微服务技术的客户,可以更好的迁移过来。
* 拥抱社区,基于开源的 Knative,拉拢社区和盟友,通过 Knative 实现 Serverless 的标准化和平台化,解决了 Serverless 市场碎片化的问题。
* 极佳的可迁移性,为客户提供了没有供应商锁定风险的解决方案。理论上客户可以根据实际需要选择完全托管的 Cloud Run 或 Cloud Run on GKE,或者开源版本的 Knative,以及其他基于 Knative 的托管平台,。
* 拥抱云原生技术栈,结合使用 Service Mesh 技术和安全容器技术,配合容器/kubernetes,用 Cloud Native 技术栈打通了从底层到上层应用的通道。

总结说,Cloud Run 是 Google Cloud 在 Serverless 领域的全新尝试,具有创新的产品思路,未来的发展值得关注和借鉴。
#参考资料
Cloud Run 刚刚发布才一个多月,目前能找到的资料不多,基本都是 Google Cloud 放出来的新闻稿/博客和官方文档,还有 Cloud Next 大会上的介绍演讲及 PPT。第三方的介绍文章非常的少,因此在调研和整理资料时不得不大量引用来自 Cloud Run 官方渠道的资料和图片。

* Cloud Run官网
* Cloud Run Overview:不到2分钟的介绍视频,官方宣传片
* Differences between Cloud Run and Cloud Run on GKE:官方视频,5分钟长度,展示 cloud run 和 Cloud Run on GKE 之间的相同点和不同点。
* Google Cloud Next’ 19 大会上和 Serverless 相关的演讲:主要信息还是来自 Next’ 19 的演讲,在这个页面中选择 “Serverless” 会列出本次大会和 Serverless 相关的演讲,大概十余个,视频可以回放,也提供PPT下载。(本文的大部分的信息和图片来自这些演讲内容),数量比较多就不一一列举了。

原文链接:Google Cloud Run详细介绍(作者:敖小剑)

谷歌正式发布其容器优化型操作系统

李颖杰 发表了文章 • 0 个评论 • 4291 次浏览 • 2017-04-05 18:57 • 来自相关话题

立足Google Cloud Platform实现容器技术“开箱即用”能力。 【上海站|3天烧脑式Spring Cloud训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、H ...查看全部
立足Google Cloud Platform实现容器技术“开箱即用”能力。

【上海站|3天烧脑式Spring Cloud训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。

相信任何一位关注IT动态的朋友都已经意识到,容器技术已然成为业界增长最快的成果之一。我们对于这一趋势感到振奋,并不断强化Google Cloud Platform(简称GCP)以确保其能够成为理想的容器运行平台。

目前市面上存在着众多出色的容器托管型操作系统,我们也对客户拥有如此丰富的方案选项感到高兴。不过仍有不少客户表示,尽管他们已经拥有自己的虚拟机方案,但其同样希望选择谷歌所使用的镜像,从而确保其能够拥有与各项谷歌服务相同的优化收益。

去年春季,我们发布了容器优化型操作系统(即Container-Optimized OS,此前曾被称为Container-VM镜像)的beta测试版本,其专门进行了优化以在GCP之上运行各类容器。我们利用容器优化型操作系统运行谷歌内部的多种产品服务(例如Google Cloud SQL以及Google Container Engine等等)。

今天,我们宣布容器优化型操作系统已经正式推出。这意味着如果您身为Compute Engine服务的用户,则可立即利用这套操作系统创建虚拟机实例(请参阅本文文末的示例),从而实现Docker容器“开箱即用”。

容器优化型操作系统代表着我们过去十年中以规模化方式运行容器时总结出的全部最佳实践:

* 受控构建/测试/发布周期:容器优化型操作系统的核心优势在于能够确保用户全面控制构建、测试与发布周期,并为GCP客户(包括谷歌自有服务)提供强化型内核功能与托管更新。发布可通过三种不同渠道实现(包括开发、beta与稳定版本),其各自拥有不同的早期访问与稳定性级别,可进一步提升迭代与发布周期的推进速度。
* 容器就绪型设计:容器优化型操作系统预安装有Docker容器运行时,同时支持Kubernetes以实现面向容器的超大规模部署与管理能力(即容器编排)。
* 在设计中充分考虑安全性需求:容器优化型操作系统在设计中充分考虑安全性需求。其最小化只读root文件系统能够有效削减攻击面,同时包含文件系统完整性检查机制。我们还在其中添加了锁定防火墙与审计日志记录功能。
* 事务更新:容器优化型操作系统采用一套主动/被动root分区机制,这意味着用户可以通过原子事务处理方式对包括内核在内的操作系统镜像进行整体更新,从而显著降低更新失败率。用户亦可以选择自动更新机制。

用户能够在Compute Engine之上通过容器优化型操作系统轻松实现虚拟机实例创建。大家可选择使用Google Cloud控制台GUI或者gcloud命令行工具,具体方法如下:
gcloud compute instances create my-cos-instance \
--image-family cos-stable \
--image-project cos-cloud

在实例创建完成之后,大家即可马上运行自己的容器。举例来说,您可以在刚刚创建完成的实例中通过以下命令运行一套Nginx容器:
gcloud compute ssh my-cos-instance -- "sudo docker run -p 80:80 nginx"

大家亦可通过以下命令在实例中进行登录:
gcloud compute ssh my_cos_instance --project my_project --zone us-east1-d 

再来看另一个简单示例,即利用Container Engine(采用容器优化型操作系统)以运行您的容器。此示例来自谷歌Container Engine快速入门页面。
gcloud container clusters create example-cluster
kubectl run hello-node --image=gcr.io/google-samples/node-hello:1.0 \
--port=8080
kubectl expose deployment hello-node --type="LoadBalancer"
kubectl get service hello-node
curl 104.196.176.115:8080

我们邀请您设置自己的容器优化型操作系统实例并在其上运行您的各类容器。感兴趣的朋友可以点击此处查看容器优化型操作系统的说明文档,亦可点击此处在Chromium OS库中找到其源代码。我们也期待着了解您对于容器优化型操作系统的使用感受反馈;大家可以在StackOverflow上配合google-container-os标签向我们提出问题。

原文链接:Container-Optimized OS from Google is generally available

关于云原生的一些思考

kurtzhong 发表了文章 • 0 个评论 • 2463 次浏览 • 2017-01-07 20:00 • 来自相关话题

# 第一部分:定义 在Craig和我开始打造Heptio的时候,我们做了不少关于我们行业发展方向的思考。我们在Google里呆了很久的时间(两个人加起来的日子有16年了),对于Google构建和管理系统的方式有很深入的理解。但是很可能你没有在Goo ...查看全部
# 第一部分:定义
在Craig和我开始打造Heptio的时候,我们做了不少关于我们行业发展方向的思考。我们在Google里呆了很久的时间(两个人加起来的日子有16年了),对于Google构建和管理系统的方式有很深入的理解。但是很可能你没有在Google任职的经历。那么对于一个普通的公司、开发或者运维人员,应该如何理解并应用这些不断演变的新概念呢?

云原生意味着什么,并没有一个固定或死板的定义。实际上,还有一些与之重叠的概念和思想。但在它云原生的核心,是对团队、文化和技术的精心组织,利用自动化和架构的力量来掌控复杂度,突破速度的束缚。在这种模式下的运作,不但是一种技术的扩张方式,更是一种人力的扩张方式。

很重要的一点是,不一定要在云环境中运行才能叫“云原生”。这其中的技术可以在恰当的时候叠加地采用,并且帮助向云过渡的过程变得顺畅。

云原生的真正价值所在远不止与之密切相关的一篮子技术。要真正的理解行业的动向,我们需要思考我们能从哪些地方用什么途径让公司、团队和个人更加成功。

目前,这些技术已经被那些以技术为中心且眼光高远的公司验证,它们为此做出了努力并投入了大量的资源。想想Google、Netflix或者Facebook。同样也有规模更小,灵活性更高的公司实现了价值。然而,除在这些技术的早期采用者之外,这套哲学理念却少见有利用。 当把目光投射到整个IT领域,我们仍然在这条旅程起点不远的地方。

随着早期的经验不断被验证和分享,如今都有哪些涌现的主题呢?

* 更有效率和更开心的团队。云原生的工具让大的问题切分成小的问题,便于分工让更专注和更敏捷的团队来解决。

* 减少枯燥重复的劳动,通过将很多人工操作自动化,也避免了因为人工操作引发的运维上痛苦和停机时间。这一般是通过自愈合、自管理基础设施来达成。系统被期望解决更多的事情。

* 更可靠的基础设施和应用。构建用来处理一些可预见的故障的自动化流程,通常对不可预见的事件和故障是更好的失效模式。举个例子,如果部署开发的应用只需要一个命令或者点击一下按钮,那在灾难恢复的场景下(通过手动或自动的方式)进行自动化部署也更加的容易。

* 可审计,可察视,可调试。复杂的系统会变的非常晦涩难懂。云原生使用的工具,通常能让人对应用内部发生的事情有清楚的了解。

* 深度的安全性。如今很多IT系统的外壳都很坚固,但内在都很脆弱。现代的系统默认情况下应该有安全防护,采取最小信任(least trust)策略。云原生让应用开发者能在应用安全方面扮演重要的角色。

* 资源的更高效的利用。应用和服务的自动化式的、类云环境的部署及管理方式,开启了自动化的算法化机遇。比如,一个集群调度器/编排器可以自动完成工作负载的安放,而不需要运维团队用类似excel的方式进行管理。

在Heptio,我们特别兴奋我们能帮助更广阔的IT领域得到云原生的恩惠。在接下来的部分,我们将讨论与已有的系统进行整合,DevOps,容器和编排,微服务和安全。
# 第二部分:实践
与任何正在经历变革的领域一样,云原生世界中有繁杂的概念。上一个部分列举的概念,不是每人个人都清楚应该如何恰当地利用。同时,很多关键的项目,要么太庞大,要么太重要,不适合重头重写。因此,我们觉得最好把这些新的结构用在新的项目或者老项目的新部件中。在系统老的部件得到了改善后,然后再花时间合理地学习并采用其他新技术。寻找把新的特性或者系统分解成微服务的方式。

没有硬性的规则。每一个机构都是不同的。软件开发的实践必须要根据身边的团队和项目来做出调整。理想不同于现实。有的项目经得起实验折腾,但是很多非常重要的项目应该采取更加谨慎的态度。还有一些场景是介于两者之间的,一些技术即使已经被验证过,但仍需要规范化并且经过大规模的测试,之后才能应用到核心系统上。

云原生的定义中离不开的更好的工具和系统。没有这些工具链,每一个新部署在生产环境的服务都会有很高的运维成本。监控,跟踪,配置等等都增加了一个处理的负担。这个额外的开销是对微服务大小的切分应该合理的主要原因之一。开发团队的速率和在生产环境中运行更多(服务)的成本,这两者的利弊需要权衡。类似的,新的技术和语言引入,尽管可能新鲜刺激,也必须仔细考虑其风险和代价。关于这个话题,Charity Majors有一个非常好的演讲

要降低构建和运行新服务中的运维成本,自动化是关键。像Kubernetes、容器、CI/CD、监控等等这样的系统,都有一个相同的重要目标 - 让应用开发和运维团队的效率更高行动更快,让打造的产品更可靠。

要达到云原生的愿景,最好使用新一代的工具和系统,而不是传统的配置管理工具,因为它们有助于分解问题然后分工给不同的团队处理。通常来讲,新的工具通常能让独立的开发和运维团队拥有自主权,然后通过自服务(self service IT)提高生产力
# 第三部分:DevOps
不妨将DevOps看成一种文化的转型,开发者现在需要关心他们的应用是怎样在生产环境中运行的。而运维也对应用的运作机制有了认识并且授予了知情权,从而可以在帮助打造可靠应用方面发挥重要作用。增进这些团队之间的理解和建立同理心是关键。

但是可以更进一步。如果我们重新思考我们的应用的构建过程和运维团队的结构组成,我们能进一步加深这种关系。

Google没有传统意义的运维团队。相反,Google定义了一种新的叫做SRE(Site Reliability Engineer,网站可靠性工程师)的工程师。他们是技能扎实的工程师(报酬同其他的工程师处同一个水平)他们不但随时保持在线,同时得到授权并被赋予通过自动化来在推动应用变得更加稳固方面扮演至关重要角色的重望。

当在凌晨两点报警触发的时候,任何响应该报警的人都会做同一件事情 - 努力弄清出了什么问题,好早点回去继续睡觉。真正定义一个SRE的地方是第二天早上10点钟发生的事情。运维组的人是否只会抱怨,还是会和开发团队一起协作保证同样的报警不会再次出现?在让应用变得尽可能稳定可靠方面,SRE和开发团队有一样追求。结合不追责的的事后剖析,可以保持项目的健康,不让技术债务堆积。

SRE在Google是最被看重的人群之一。在实际中,很多项目在没有SRE参与启动的时候,开发团队肩负了让他们的产品在生产环境中运行起来的期望。引入SRE团队的流程,通常需要开发团队向SRE团队证明他们的产品已经准备到位。开发团队需要已经做好了所有的准备工作,包括设置好监控和报警,报警的应对策略和发布流程。开发团队要能显示出报警的情况已经达到了最少的程度,并且绝大多数的问题已经被自动化了。

随着运维的角色参与程度更深,与特定的应用相关度更高,让一个运维团队掌控整个运维栈变得不合理。这引出运维规范(Operations Specialization)的问题。从某种意义来说这是一种
“反DevOps(anti-devops)”的做法。让我们来自下而上的看:

* 硬件运维。这一层很显然可以分离出来。实际上,很容易把云IaaS看成是“硬件运营即服务(Hardware Ops as a Service)”。

* 操作系统运维。必须有人保证机器能够顺利启动,并且有一个好的内核。将这一部分从应用的依赖管理中分离出来也反映出了用来托管容器的操作系统发行版(CoreOS, Red Hat Project Atomic, Ubuntu Snappy, Rancher OS, VMWare Photon, Google Container Optimized OS)的最小化趋势。

* 集群运维。在容器化的世界中,一个计算的集群变成了一个逻辑上的基础设施平台。集群系统(Kubernetes)提供了一组原语能让很多传统的运维任务自服务化。

* 应用运维。每一个应用现在可以根据需要拥有一个专门的应用团队。若有必要,开发团队有能力并且应该担任起这个角色。这种运维团队应该更深入应用,因为他们不需要在其他的层次上专研太深。比如,在Google,AdWords的前端SRE团队会和AdWords Frontend的开发团队交流很多,超过他们与集群团队之间的交流。这能带来更好的成果。

很可能还有其他专业性的SRE团队的空间。例如,存储服务可能会划分成单独的服务,或者根据某种政策,可能有团队来负责验证所有团队使用的基础容器镜像。
# 第四部分:容器和集群
有很多人对于容器相关技术兴奋不已。了解为什么大家如此兴奋的的根本原因是有益处的。在我看来,有三个原因:

  1. 打包和移植性
  2. 效率
  3. 安全性

让我们依次地来看。

首先,容器提供了一种打包机制。这能让系统的构建从这部署流程中分离开来。另外,构建的成品和镜像比传统的方式如虚拟机移植性更好。最后,部署变得更加的原子化。传统的配置管理系统(Puppet,Chef,Salt,Ansible)很容易让系统处于一种配置不完整的、很难调试的状态。也很容易在机器中残留一些不易被发现的错误版本。

第二,容器更轻量化,使得资源利用率增加。这是当Google引入cgroups(容器底层的主要核心技术之一)时的一个主要原因。通过共享一个内核,并且允许更流体化的过量使用(fluid overcommit),容器更容易让系统资源每一部分都不浪费(“use every part of the cow”)。随着时间的推移,有望看到更加复杂的用来均衡单个主机上共存容器需求的方式,杜绝吵闹邻居问题。

最后,很多用户把容器看做是一个安全性界限。尽管容器可以比一个简单的Unix进程更安全,当把它们看做是一个硬的安全性边界的时候还是要注意。Linux命名空间提供的安全保证对于那些运行半信任工作量的“软”多租户环境来说合适,但对于那些运行充满敌意的工作量的硬多租户环境却不适用。

有从很多方面的努力来在模糊容器和虚拟机的界限。一些早期研究如unikernel很有意思,但是很多年内尚不能应用于生产。

要达到上述目标,容器尽管是一条简单的途径,但却不是必要的途径。例如,Netflix,传统以来一直运行一个非常现代化的技术栈,它们以类似使用容器的方式,来打包并使用虚拟机镜像。

尽管绝大多数围绕着容器的努力集中于在单个节点上管理软件,使之更加可靠和可预测,这个改革的下一步集中于集群(通常也被称作编排器)。给定一批节点然后把他们和自动化系统绑定起来,为开发和运维团队提供了一组逻辑基础设施的自服务

集群能帮助消除运维中枯燥乏味。有了容器集群我们让计算机来接管工作,决定负载应该由哪台机器来处理。集群也会默默的在硬件失效的时候修复问题,而不是需要去通知某人。

集群的第一个好处就是它启用了运维的规范(见第三部分)可以让应用运维作为一个单独的学科来努力。通过定义个以良好的集群接口,应用开发者们能集中于解决应用自身的一些问题。

集群的第二个好处是它让启动并管理更多的服务成为可能。从而允许使用能为开发团队高速率的架构(通过下一部分介绍的微服务)。
# 第五部分:微服务
微服务是一个已经存在很久的概念的一个新名称。基本上,它是一种将一个大的应用进行切分的方法,使得他们能独立地进行开发和管理。让我们看看此处相关的关键概念:

* 强大和清晰的接口。服务之间的紧耦合必须避免。配套了清晰文档和有版本管理的接口有助于强化这种协定,对于这些服务的消费者和生产者同时又都能保有一定的自由度。

* 独立的部署和管理。微服务应该能够单个更新,无需和其他的服务一起同步进行。同时,大家也都很希望能够轻松地回滚一个微服务的版本。这意味着部署的二进制文件必须在API上和任何数据格式方面保持向前和向后兼容。这可以作为检验运维和开发团队之间的合作和沟通程度的试金石。

* 由内打造的耐受性。微服务应该构建成为并经测试验证有独立的耐受性的。在消费的服务不可用或者异常的时候,那些消费一个服务的代码应该要努力保持正常工作并且做出合理响应。同样的,那些提供的服务应该对于未曾预料的负载和异常输入做好防护。

确定微服务的大小是一个很难做对的事情。我的意见是要避免选择小的过分的服务(pico-services),反之将服务按照自然的边界(编程语言,异步队列,伸缩的要求)进行切分,同时保持团队大小合理(例如:两个披萨团队)。

应用的架构应该能允许以一种切合实际并且自然的方式增长。与其以20个微服务开始,不如从2到3个开始,然后随着该领域复杂度再对服务进行拆分。经常对一个应用的架构的认识直到应用在处于开发阶段才会变得透彻。这也说明了很少有已经竣工完成的应用,他们都总是一个正在施工的工程。

微服务是一个新概念吗? 非也。这其实是另外一种类型的软件组件化(software componentization)。我们过去把代码切分成库。这只是把“链接器”从一个构建阶段的概念转变成了一个运行时的概念(实际上,Buoyant有一个有意思的项目叫做linkerd,其基于Twitter Finagle系统。)。这与多年前的SOA潮很相似,只是不见了各种样式的XML。数据库从另外一个角度看,一直以来几乎是一个微服务,因为它实现和部署的方式都满足上面列的点。

约束可以转变成生产力。 尽管,很容易让每一个团队各自决定在每一个微服务上使用什么语言或框架,但不妨考虑下规范化,定下几种语言或者框架。这么做有助于机构内部的知识技术交流积累,更好应对人员流动。但是,在必要时也要有打破政策的开放心态。这是比起PaaS的垂直式集成结构,这个世界中的一个关键优势,换句话说,约束应该是来自政策层面的,而不是来自技术能力层面(constraints should be a matter of policy rather than capability)。

尽管绝大多数人把微服务看做是实现一个大型应用的技术,服务光谱(services spectrum)中还有很多其他类型的服务:

  1. 服务作为实现细节。正如上面描述过的一样,这对于把一个大的应用团队切分成小的开发和运维团队很有用。

  1. 成果共享,实例私用(Shared Artifact, Private Instance)。在这种场景中,开发过程通过服务的很多实例间共享。有可能有一个开发团队和很多运维团队,或者很可能一个联合的运维团队,在共享专门的实例间工作。很多数据库属于这种类型,很多团队都在使用同一个MySQL安装的私有实例。

  1. 实例公用。这种场景下,机构中的一个团队为很多应用或者团队提供一个共享的服务。服务可能会将数据或者操作按照用户(多租户)进行分区,或者提供一个用途广泛的简单服务(如展示一个通用的品牌条HTML,提供机器学习模型等)。

  1. 大型服务(Big-S Service)。绝大多数的企业不会打造这种的服务,但是可能会使用他们。这是一个典型的“硬性”的多租户服务,用来构建来为大量的分散的客户提供服务。这种服务需要某种层次的记账和加固,通常在企业内是不必要的。SendGrid和Twilio属于这一类。

随着服务从一种实现细节变成一种企业内常见提供的基础实施,服务网络从一个每应用的概念变成了能跨越整个公司的概念。允许这种依赖是一个既有机遇也有忧患。
# 第六部分:安全
注:本文中没有覆盖到新出现的“云原生”中与安全相关方方面面。但同时,尽管我不是一个安全专家,安全却是我整个职业生涯都有在关注的事情。请把它当做是值得考虑的事项清单的一部分。

安全仍然是云原生领域中的一个大问题。以往的技术无法完美的应用,在起初云原生可能看起来在开倒车。但在这片无畏的领域,同时也充满了各种机遇。
## 容器镜像安全
有很多的工具可以帮助对容器镜像进行审计,以确保它们完整地包含了各种补丁。众多选择中,我没有什么很强个人偏好的。

真正的问题在于,在发现了一个有漏洞的镜像之后该怎么做呢?这一块市场尚未提供很好的解决方案。一旦有漏洞的镜像被检出,事情就从一个技术问题变成了一个程序/流程问题。你会想着去找出机构中哪些组件受到了影响,问题应该在容器镜像层级树的什么地方进行修补,以及用什么好办法来进行测试并且发布新的打好补丁的版本。

CD/CD(持续集成/持续部署)是应对良策中的重要内容,因为它可以快速自动地发布新镜像。其与编排系统的集成能让你找出哪些用户正在使用有漏洞的镜像。同时它也能让你验证生产环境上是否采用了已经修复好的版本。最后,部署系统的策略能帮助阻止那些使用有漏洞镜像的容器启动(在Kubernetes的中,这被称作准入(admission))。
## 微服务和网络安全
但即使集群上所有运行的软件都已经是修复过的,也并不能保证网络中有没有不受信任的活动。

在以动态调度、存时短暂为特征的容器世界中,传统的基于网络的安全工具无法发挥理想的效果。存时短暂的容器可能存活时间过短,以至于传统的扫描工具无法及时扫描到。又或者被扫描到了且扫描报告已经生成,奈何相关容器却已经不存在了。

在动态的编排器中,IP地址不再拥有长久的意味,且它们是可以被自动复用的。解决方案是将网络分析工具和编排器集成,让逻辑名称(结合其他元数据)可以和IP地址一并使用。这可能可以让报警更加容易处理一点。

很多网络技术都利用了封装技术来实现“一容器一IP”。这可能会给网络追踪和诊断工具带来问题。如果生产环境上部署了这样的网络系统,那这些工具必须要做出相应改进。幸运的是,VXLAN、VLAN中的很大一部分都都已经被标准化了,或者不采用封装或者虚拟化,以便这些系统都能利用这些支持工具。

然而,个人看法,最大的问题还是跟微服务相关的问题。当在生产环境中运行了很多服务的时候,很有必要确保某特定的服务只能被授权的客户端调用。另外,因为有了IP的重复使用,客户端需要能知道调用的服务是正确的服务。大体上说来,目前这还是一个没有解决的问题。要处理这个问题,有两个(并不互斥的)方案。

首先,让实现主机级别的防火墙规则(在任何的容器之外)的网络系统和选项更灵活,以便能细粒度控制访问策略,来控制某些容器能被其他哪些容器调用。我把这个称之为网络的微隔离(network micro-segmentation)。这里的挑战之一在于在动态调度下如何进行策略的配置。尽管尚处于起步阶段,有很多的公司正在努力简化这一点,通过在网络中添加支持,或者同编排器协作,又或者过在处于高层次的应用中进行定义。一个很大的问题是,服务的使用范围越广,微隔离的效果就越小。如果一个服务有成百的调用者,“拥有访问权即意味着得到授权(access implies authorization)”的简单模型不再适用。

第二个方案是让应用在实现数据中心内的认证和加密中扮演更加重要的作用。这对于那些客户端众多、并且在大的机构中已经形成“软多租户”状态的服务适用。这需要有一个生产环境服务的身份系统。我已经开始一个叫做SPIFFE(Secure Production Identity Framework For Everyone,给大家使用的生产环境安全身份系统框架)的业余项目。这些理念已经在Google这样的公司得到了验证,但是还没有在其他地方施行。

安全是一个很深入的话题,这里肯定有很多威胁和注意事项没有涉及到,还需要持续的探讨。

到这里,我们的云原生系列文章就结束了。欢迎大家在Medium留下自己的想法,或者在Twitter上联系jbeda,cmcluck或者heptio。


原文链接:

* Cloud Native Part 1: Definition
* Cloud Native Part 2: In Practice
* [Cloud Native Part 3: DevOps
](https://blog.heptio.com/cloud-native-part-3-6f9d888c5f07#.xjj0zlzrt)
* Cloud Native Part 4: Containers and Clusters
* Cloud Native Part 5: Microservices
* Cloud Native Part 6: Security

翻译:钟最龙

谷歌容器管理10年记

liguangcheng 发表了文章 • 0 个评论 • 4080 次浏览 • 2016-03-26 22:55 • 来自相关话题

【编者的话】本文介绍了过去十年谷歌在容器管理方面的实践,包括了Borg,Omega和Kubernetes的历史和架构方面的比较,谷歌在其内部使用容器的概况,以及谷歌试图通过社区来推动其Kubernetes成为容器管理标准的努力。 @C ...查看全部
【编者的话】本文介绍了过去十年谷歌在容器管理方面的实践,包括了Borg,Omega和Kubernetes的历史和架构方面的比较,谷歌在其内部使用容器的概况,以及谷歌试图通过社区来推动其Kubernetes成为容器管理标准的努力。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。

容器的概念和实现并不是搜索引擎巨头谷歌发明的,但是谷歌却通过在上百万的服务器上编排和运行了数以亿计的容器帮助Linux操作系统的容器技术日趋完善。谷歌有很多经验可以分享,但依然谦虚的认识到也还有很多需要学习的地方。

这或许是其中最重要的一个原因使得谷歌在两年前决定开源其容器管理系统Kubernetes。谷歌过去通过发表论文向业界展示通过它的高精尖技术处理大规模环境下中的分析、存储和计算问题。但是这种方式有时候产生事与愿违的效果,例如谷歌的MapReduce理论被雅虎用来实现Hadoop进而孵化出了一个全新的领域。现在,谷歌如果不将其技术和标准贡献给社区让业界来遵从,谷歌将跟整个业界不兼容。

因此我们认为Kubernetes是谷歌的一次尝试,通过分享技术到社区以此推动该容器管理系统的开发,期望在将来能够替代其在内部使用了多年的集群管理的核心Borg,就像他们的名字暗示的那样其中包含了许多不同的技术(例如几年前产生的Omega调度器)。这次,谷歌希望能够得到社区的帮助,目前已经有超大规模集群以及HPC方面的专家在帮助充实Kubernetes以解决其只能支持单一的工作负载的问题,虽然在谷歌内部已经有5,000到50,000个节点的集群,但是其上运行的负载还是相对单一的。

在谷歌内部创建和扩展Brog的跟创建Kubernetes的核心开发团队是同一组人,他们继续在Kubernetes项目中有很大的影响力。这包含了Kubernetes的共同创立者Brendan Burns;过去8年一直在致力于集群管理系统工作的谷歌主管软件工程师John Wilkes;Borg容器管理系统的技术负责人、Brog的扩展组件Omega的创建者、Kubernetes的设计负责人Brian Grant;Kubernetes技术负责人David Oppenheimer;谷歌负责基础设施的副总以及加州大学伯克利分校的教授Eric Brewer。

谷歌发布了两篇介绍其容器管理系统的技术文章起到了重要的作用,第一篇是2013年10月发表的介绍Omega的文章,在介绍Omega的文章发布之后的2013年11月份在大规模系统管理会议(Large Installation System Administration conference)上Wilkes做了精彩的演讲。这解释了谷歌的Borg系统,同时这些信息的批露是在2014年夏天Kubernetes发布之前。在Kubernetes发布之后,带来了不少关于Omega和Borg之间关系的困扰,在2015年4月份发表的第二篇文章解释了谷歌的对于大规模集群管理的视角,在文章发表后,我们也采访了Wikes得到了更多谷歌关于容器和集群调度的洞察。

从事Borg,Omega和Kubernetes工作的谷歌顶尖工程师们ACM Queue上发表了另外一篇更通俗的文章描述了谷歌过去十年间在容器管理方面的经验和教训,提供了更多关于谷歌认为或者说希望看到Kubernetes社区前进的方向。

事实证明了Borg并不是这个搜索引擎巨头创造的第一个集群和应用管理工具。谷歌跟其它所有的公司一样有批处理工作负载和长期运行工作负载的组合,它在物理上将不同的工作负载运行在不同的集群里。一个叫做Babysitter的项目运行长期运行工作负载(例如Web服务和其它基础设施服务),同时另外一个叫做Global Work Queue的项目运行批处理工作负载例如孵化了Hadoop而谷歌仍然在继续使用的MapReduce大数据分析框架。但是,在不同集群里运行不同的应用会造成经常性的计算资源浪费,这对在过去十年快速成长的谷歌来说是不可接受的。

关于软件容器,即使是在十年前也不能算是一个新概念。我们甚至可以说1989年克隆大型机制造商Amdahl提出的PR/SM逻辑分区就已经是容器,毫无疑问IBM自己System z主机系统上的的虚机操作系统产生的虚机在本质上也是软件容器,直到今天还作为在主机系统上运行Linux实例的后台技术。FreeBSD有Jail partitions,Solaris最终也有了自己的容器技术。但是谷歌作为一个Linux公司不得不进行大量的工作在Linux内核中添加容器相关的功能。现在在每一个Linux发行版中都存在的LXC容器技术是在谷歌的工作的基础上创建的,而Docker是这项工作的另外一个分支。

在某种程度上来讲,Kubernetes借鉴了单一化的Borg系统和更加灵活的Omega系统的技术(使得多种工作负载可以共享资源而不必只是排队等待),最终结果是Kubernetes成为谷歌的第三个容器管理系统。如果Kubernetes的复杂程度和规模持续增加的话它可能会成为另外一个Borg,而我们认为这是谷歌的其中一个目标。从另外一个角度来讲,就像我们前面说的那样,谷歌希望Kubernetes能成为容器管理的事实上的标准,这使得构建企业级私有云的用户更有可能去使用谷歌的基于Kubernetes构建的Google Cloud Platform公有云服务。

从谷歌发布的最新文章中透漏出的关于其容器管理系统从裸机到容器的转变的重要信息是意义深远的,这或许对谋求容器作为更好的方式的人来讲不是显而易见的,我们认为这是相比与抬高服务器利用率的服务器虚拟化来讲更廉价的一种方式。一切都变成了应用为中心而不是服务器为中心,这正是IT公司们梦寐以求的天堂。工作负载调度器、集群管理系统和容器管理器协同工作当应用需要时为应用提供正确的容量,不管应用是延迟敏感的负载或者是对延迟不敏感的批处理负载,工程师和开发人员所需要关注只是应用的运行状态,而他们可以非常容易的获取应用运行的状态因为所有的关于状态的API调用都是在应用层面的而不是服务器层面的。

这意味着容器时代的到来,在谷歌里将不在有裸机,这可以作为给那些HPC厂商和其它超大规模集群厂商以及云服务提供商的一堂课,他们还认为需要运行在裸机模式下(我们听所在AWS上运行的很多大数据服务运行在裸机上而不是用定制版Xen Hypervisor支持下的EC2计算实例)。这不是一个确定的结论,但是在些许性能损失(其实比整机使用KVM或者Xen进行虚拟化的性能损失还是小很多的)和容器带来的管理与部署灵活性之间看上去绝对是一个非常划算的折衷。(如果Intel想解决这个问题,可以在每一个芯片中增加一个容器管理核心就足够了,或者在Xeon服务器芯片中用两个或者三个核来运行Hypervisor)。

“容器的隔离性和最小依赖被证明了在谷歌是非常有效的,容器已经成为了谷歌基础设施上运行的唯一实体”, 文章的作者写道,“一个结果就是现在谷歌在任何时间只有很少数量的操作系统版本部署在所有的服务器上,这就只需要很少的人员去维护和更新操作系统版本”。

使用Kubernetes,容器是一个应用程序的运行时,而作为构成微服务的多个容器被聚合到一个更高层次的被称为pod的概念中。Kubernetes最重要的是一个pod管理系统来使得这些容器集合能够协作和运行。Borg有一个类似的架构,Linux容器作为最细的粒度和Allocation的最底层。Allocation,缩写为alloc,是容器集合的一个上层包装。Borg允许某些容器在alloc之外运行,文章的作者说“这是造成诸多不便的原因”,这或许还是一个非常保守的陈述。Kubernetes则不允许你这么做。然而如果在丢安全或者隔离性有更高要求的场合例如在多租户环境的公有云中你可以在容器内运行容器,或者在一个虚拟机内部运行容器。事实上,谷歌在它的Cloud Platform里就是这么做的。一个服务器上运行了一个巨大的容器,在这个容器之上运行了KVM Hypervisor或者其它容器来向公有云上的用户暴露不同的Google Engine实例类型。

就像Omega通过收集和使用谷歌集群状态信息来更好的分配资源给容器化的批处理应用和在线应用,Kubernetes则实行了严格统一的API来跟集群进行接口 – 不像Brog在过去若干年增加了很多的API类型和风格。

“Kubernetes的设计中微服务和小的控制回路的组合是一个通过编排进行控制的例子 – 通过组合协作中的分散和自治实体来达到期望的效果”,谷歌最近这的篇文章中说,“与集中式的编排系统相比Kubernetes是一种更精巧的设计,集中式的编排系统可能在开始时相对较容易,但是随着时间的推移特别是在出现不可预知的错误或者状态变化时就会变得容易出现问题。”

我们的整体印象是Kubernetes是一个虽然还有那么一点不成熟但是却是一个比Borg更好的工具,仅仅是Kubernetes这一个工具就会给整个IT业界一个很大的影响。

谷歌将它过去十年在容器和集群管理方面的经验回馈给开源社区,甚至在它帮助Berkeley的AMPLab推动Mesos系统的开发之后,Mesos系统目前已经被Mesophere商业化。这或许是谷歌后悔做的事情(译者注:指推动Mesos的发展),但是开源Kubernetes对谷歌来说确实是一个艰难的决定。唯一的另外一个可能选项是让Mesos变成像Hadoop一样的另外一个事实上的标准,我们已经看到这件事情的现状了,这显然不是谷歌想要的。谷歌是唯一一个不能轻易从它自创的MapReduce转到Hadoop的超大集群运营者,这意味着它基础设施软件开发的成本从长期来看将持续上涨。

原文链接:A Decade Of Container Control At Google(翻译:李光成)

=================================
译者介绍
李光成,IBM中国研究院资深研究员,研究方向是云计算基础设施及技术。目前在做的是Docker资源隔离方面的研究项目。

Amazon与Google间的容器竞争持续发酵

YiGagyeong 发表了文章 • 0 个评论 • 4120 次浏览 • 2016-03-13 01:08 • 来自相关话题

【编者的话】Amazon和Google仍然是在Docker Linux云端容器领域中最强劲的竞争者,由于微软Azure的加入使得他们的竞争进入白热化状态。本文主要介绍了Google GKE和Amazon ECS两个产品在实现自动收缩、冗余性和互操作性上的不同之 ...查看全部
【编者的话】Amazon和Google仍然是在Docker Linux云端容器领域中最强劲的竞争者,由于微软Azure的加入使得他们的竞争进入白热化状态。本文主要介绍了Google GKE和Amazon ECS两个产品在实现自动收缩、冗余性和互操作性上的不同之处,当然还提到了微软Azure的现状。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、点融网等公司的技术负责人将带来实践经验分享,3月21日之前购票只需238元,欢迎感兴趣的同学抢购。

这些公司的云端容器服务将Docker容器管理从用户中抽象出去,从而更加容易地部署和扩展构建在容器之上的应用。但是,在他们成熟的产品中存在着关键的不同,其中包括每家公司为实现自动收缩、冗余性和互操作性方面所选用的第三方工具和云服务。
争论的焦点——自动收缩
Google容器引擎(GKE)由pod、replication controller和节点组成。pod是一组特定的应用程序逻辑主机模型的容器逻辑分组;replication controller确保特定数量的pod副本任何时候都在运行;节点是加强了容器环境的Google计算引擎虚拟机。

GKE基于Google的Kubernetes容器编排平台。Kubernetes 1.1版本在1.0版首次亮相之后4个月的11月24号发布,是市场中第一个能够通过水平节点自动伸缩功能来实现自动伸缩节点的产品,这个功能受到用户的高度追捧,从而为许多使用GKE的案例提供了有力的支持。

“我们为很多各种类型的项目使用自动伸缩”, Descartes Labs公司的联合创始人和首席云架构师Tim Kelton如是说。这家公司位于新墨西哥洲,是机器学习方面的初创公司,能够处理PB级别的卫星数据。

自动伸缩的pod在处理大型批处理作业时能够派上大用场,Kelton解释道。有时,他的公司处理PB级的数据,这就需要扩展到3000个内核。在Kubernetes的第一个版本(随后很快被GKE合并)中,“这不是核心特性集的一部分”,他说。

虽然GKE不支持垂直容器扩展或者节点自动伸缩,但是,根据GKE高级产品经理,同时也主导Kubernetes产品管理的David Aronchick透露,这些功能很快就是实现。

Amazon EC2容器服务(ECS)由服务、任务和实例组成。服务是构成应用程序的任务组,而实例是支持容器的弹性计算云端虚拟机,与GKE中的节点很像。

Google的ECS的自动伸缩能力与GKE是相反的:使用亚马逊CloudWatch和亚马逊网络服务Lamda可以实现服务自动伸缩,实例也可以基于CloudWatch metrics进行自动伸缩,但是任务——等同于pod,属于粗糙逻辑,无法自动伸缩。

虽然所有类型的自动缩放都很重要,但是亚马逊用户希望将任务自动伸缩加入ECS中。

“运行一个新的实例意味着你要有额外的容量来运行额外的任务,但这并不意味着任何新的任务都将被启动”,ACI信息科技集团副总裁Chris Moyer如是说。ACI,位于纽约,是一家基于Web的内容聚合技术的公司,也是TechTarget的贡献者。“如果你只是自动伸缩实例,并不能真正帮助你解决额外的负载——你必须真正运行额外的任务来实现扩展。”
跨区域冗余
在ECS发展过程中,亚马逊优先发展在同一个集群中,针对基于用户需求的任务自动伸缩冗余性,本地跨越可用区域(AZs)的能力,当ECS服务调度启动新的任务时,它也会尝试通过集群中的AZs自动平衡这些任务。

“这很重要,因为单个AZ允许失败,所以如果两个任务都允许在同一个AZ中,很容易拖垮你的服务”,Moyer说。

据Aronchick介绍,Google可以在GKE中通过命令行接口(CLI)跨多个区域。

"实现跨区域非常容易,两三条命令就能搞定",Aronchick如是说。

然而,这就要谈到GKE用户最大的心愿:将跨区域功能改进到Web界面上,包括跨域集群扩展功能。

“实现用户界面需要大量工作”,Vendasta科技首席架构师Dale Hopkins说,Vendasta为媒体公司设计销售和营销软件。用户界面目前支持集群创建以及其他少数功能。Hopkins说:“扩展集群是不直观的。”
互操作性
ECS作为一个可扩展平台,旨在融入客户现有的工作流,主要处理代表用户的集群状态。将ECS集成到现有工作流中来兼容客户在用的工具,比如用以高级调度的Apache Mesos。亚马逊还自豪的声称拥有广泛的容器伙伴网络来为亚马逊ECS贡献新特性,比如监视、持续集成和安全。

同时,Google已经与一批云端容器合作伙伴合作,这些合作商允许Kubernetes可以通过多个云端供应商被部署——这也是CLI现在的一个功能,Aronchick如是说。去年夏天Kubernetes 1.0版本发布时, Google引导了Cloud Native 计算基金会的成立,基金会成员包括云服务公司,比如IBM和Red Hat,以及终端用户如eBay和Twitter。

“[附] Kubernetes,其实我可以在亚马逊部署,在Azure上部署,在IBM上部署,也可以部署在我自己的物理硬件上,”Descartes的Kelton 说。 “这是非常有吸引力的,因为我们有选择。”

Google也有一个开源项目,拥有数百提交者和每月数以千计的代码提交,使得 Kubernetes可以快速的添加新功能,比如水平pod自动扩展。

Google是Kubernetes的创始者,而且Google做了很多杰出的工作壮大了社区,451 Research的研究员Jay Lyman如是说。
富者愈富
尽管如此,使用老牌和熟悉的次级亚马逊服务来实现集成使得亚马逊ECS特别吸引新的客户。

一家总部位于纽约的公司,与一些大的企业就IT项目上进行咨询,计划在两个新项目上使用ECS, 据其创始人John D'Esposito介绍。驱使我们使用ECS的主要优点是使用现有的、成熟的基础设施服务比如弹性负载平衡、虚拟私有云、身份和访问管理,以及弹性块存储可以实现无缝集成。

GKE和Compute Engine的定价还是对客户非常有吸引力的。除了在以10分钟为单位收费的VM资源的底层,GKE包括免费的Kubernetes主节点——这是特别吸引Vendasta的Hopkins的地方。

“直到我可以获得大量机器,我才会给 Kubernetes支付额外的费用。对于第一套机器,GKE为我免费提供Kubernetes节点”,Hopkins说。

在Kubernetes和容器引擎被引入之前,Hopkins和Kelton都已经在用Google云服务,包括Google App引擎。这样,数据重力就会在他们所选择部署的云端容器上起作用。

“我们的大多数数据集是PB级规模的,所以你不能只是移动或复制它们,你必须真正去计算数据”,Kelton说。大多数数据目前存放在Google云平台,虽然Descartes不与AWS的合作伙伴合作。
微软Azure Container服务整装待发
虽然Google和亚马逊在云端容器竞争中到目前为止仍处于前沿,但亚马逊最大的竞争对手仍然是微软的Azure,它在有限预览阶段拥有自己基于Linux的云端容器的服务,以及Windows Server的新版本,今年之后,将支持基于Windows的容器。

“我们的大多数客户都是......无论是在Azure或亚马逊,” 位于Rochester的HKM咨询公司的合伙创始人Chris Riley如是说,“微软已经拿到了一些他们正在开发的有趣工具。如果我们看到一个次要的,它很可能Google之前的Azure“。

简单性和易用性是很多微软的产品的设计重点,Lumagate的CTO Kristian Nese介绍,Lumagate是挪威的一家微软Azure系统集成商。

“我们现在部署Azure的容器服务,仅仅需要100行代码,”Nese说。 “一旦你部署了Azure的容器服务,你实际上部署了23个资源......如果你想手动做到这一点,可能需要数千行代码。”

Azure容器服务在预览阶段也支持自动扩展,是一个独立服务形式,被称作VM量表集

Azure还将提供成熟和熟悉的工具来管理容器,如Azure的资源管理器,Nese补充说。

原文链接:Cloud containers race heats up between Amazon and Google(翻译:李加庆

Kubernetes联合创始人谈云原生计算以及CNCF

codesun 发表了文章 • 0 个评论 • 3352 次浏览 • 2016-02-13 23:09 • 来自相关话题

过去十年以来,谷歌公司已经将大量开发资源投入到系统创建工作当中,旨在顺利实现规模扩展。通过创建高复杂度应用程序以处理大规模流量及数据集已经让我们得以在应用程序架构以及整体操作模式层面积累起丰富的经济与可观的创新型成果。 目前技术业界开 ...查看全部
过去十年以来,谷歌公司已经将大量开发资源投入到系统创建工作当中,旨在顺利实现规模扩展。通过创建高复杂度应用程序以处理大规模流量及数据集已经让我们得以在应用程序架构以及整体操作模式层面积累起丰富的经济与可观的创新型成果。

目前技术业界开始将这类方案称为“云原生计算”,而其与传统系统间的核心区别主要分为以下三种:

1. 容器化封装。以封装形式将应用程序单元部署在应用程序容器内部能够显著提升可预测能力。在规模化场景下,我们无法利用传统的命令或者脚本实现部署任务。单一系统中的任何自由支配空间都不可能直接扩展至互联网规模级别。
2. 动态管理。运营人员无法以人工方式对每周高达20套容器系统进行调度与管理。相反,我们高度依赖容器解决方案构建智能化系统,从而针对所需运行任务之数量以及运行位置做出准确决策。这能够从根本上提升执行效率,让我们的开发人员专注于代码编写工作。这种方式能够让我们建立起小型化、专业化且拥有高度授权的运维团队,并将主要精力集中在提供常规服务身上。
3. 面向微服务。我们的全部系统依赖于松散耦合之架构,且通过服务端点进行关联性描述。这让我们的系统拥有更为出色的敏捷性,同时从根本上提升代码复用率。这也意味着我们不需要为每套子系统创建新的常规服务实例。

在谷歌之外,这种方法被称为“GIFEE”——即Google Infrastructure for Everyone Else。有趣的是,我们也可以将其称为“FIFEE”或者“TIFEE”——因为 Facebook与Twitter也利用类似的计算方案以处理自身规模化运营任务。虽然各方案在具体细节上存在诸多差异,但其基础模式可谓高度一致。这也是最理想的技术进化方式。只有这一种实践手段能够处理互联网规模运营工作,而截至目前,每一家互联网企业也都立足于同样的基础模式创建出属于自己的独特解决思路。

展望未来,我们认为将有更多传统企业被迫面对互联网规模所带来的各类难题。物联网将给企业带来无法预测的流量等级。而更多联网与移动设备介入业务流程则使得客户群体以及企业员工要求利用互联网规模解决方案对其提供支持。几乎可以肯定的是,每家企业都必将面临这些挑战,而技术业界则需要以协作方式将强大的技术堆栈构建成足以支撑此类业务需求的创新成果。
#容器技术的下一发展阶段:标准化
最近一段时间,我们发现众多技术企业开始各自推进关键性技术成果的开发,旨在支持这种面向云原生计算的发展趋势。不过独立方案的弊端在于,其要求单一供应商交付一套“完整堆栈”。由于缺少容器运行时、编排、常规服务以及其它各类技术组件的执行标准,由此建立的云原生堆栈导致每家企业身为单独孤岛,而且其中只有极少数有能力提供完整的解决方案。

在我们看来,每家企业都能够立足于合理的独特设计获得收益。如果一家初创企业对于改进容器运行时环境有着独特的见解,他们应该有能力率先做出尝试并创建出一套独特的运行时环境,而无需受到既定镜像格式的限制。如果另一家初创企业擅长构建调度机制以解决特定工作负载问题,他们亦应该有能力构建并销售相关方案,而不必为其构建一套完整堆栈。

考虑到这一点,我们开始将着眼点放在Kubernetes的发展前景身上——这项容器编排技术由谷歌公司内部编排与调度系统(即Borg项目)的开发团队所打造。最理想的方式在于将其交由基金会打理,并与广泛社区合作以协调各类可交互“堆栈”之间的对接,从而为每家企业客户提供云原生计算支持能力。有鉴于此,我们与Linux基金会取得联系,同时汇集多家技术合作伙伴(包括英特尔、红帽、思科、IBM、VMware、Docker、CoreOS以及Mesosphere等等)共同建立起云原生计算基金会(简称CNCF)。
#新的标准化实现方案
我们建立云原生计算基金会的目标并非创建起一家传统标准机构(即负责定义标准,而后提供参考实现方案),而是建立起一个能够以厂商中立性为前提的相关技术汇聚平台,并随时间推移对此类技术加以协调,最终为用户群体提供跨越不同堆栈层的标准接口。

我们的目标在于创建一套配备有简洁接口(即API)的简洁架构,而后依据参考实现方式作为各语义块的执行标准。各供应商能够对堆栈内的任意组成部分做出必要扩展,但相关变更需要经过强大的资格测试套件加以“认证”,以审查其与参考实现方案的兼容性水平。基于API的一致性还远远不够,语义一致性对于客户从堆栈中提取必要组件并将其合并成适合自己的方案可谓至关重要。

考虑到这一点,我们发布了以下基金会核心价值取向:

1. 始终技术高速执行能力。我们必须确保相关项目进程以高速状态推进,从而支持来自用户的各类前瞻性需求。
2. 开放性。基金会必须保持开放性与可参与性,同时独立于任何特定厂商之利益做出运营决策。其必须接纳一切正面贡献成果,且其技术必须可根据开源价值取向向需要各方开放。
3. 公平性。我们必须创造公平的竞争环境,允许各小型企业以与主流厂商对等的姿态参与创新成果的开发与推动。
4. 一致性。技术方案必须在外观与使用感受层面同风格、理念以及原则保持一致。
5. 强大的技术特征。基金会必须实现并保持高度技术自主能力,并跨越不同项目建立明确的技术特征。
6. 边界明确。必须设立明确的发展目标。但在多数情况下,与基金会既定目标有所区别的工作同样能够促进项目之间的有效并存,进而帮助生态系统了解与创新成果相关的关注方向。

#新型治理模式
为了实现上述目标,我们必须立足于局外审视基金会的运作结构。虽然我们对基金会当前的工作成果感到满意,但有迹象表明,仍有相关一部分关键性目标尚未得到确切实现。而且与传统商业管理委员会不同,我们决定尝试新的治理模式以提高执行效率:

1. 强调技术意见的重要地位。我们的目标是为市场带来极具颠覆性的新型技术成果,同时帮助整个世界向新的、更理想的工作方式过渡。要实现这项目标,我们需要一整套具备高度授权的管理机构,且其决策不会与任何单一供应商之现实利益捆绑起来。有鉴于此,我们建立了技术监督委员会——这个包含九名成员的团队将负责制定技术发展愿景、推动子项目开发并解决技术纠纷。这些成员皆拥有丰富的技术行业从业经验,且立足于社区而非特定供应商之利益。
2. 对最终用户负责。我们发现很多基金会组织往往受到供应商驱动,而缺乏强有力的最终用户问责机制。为了解决这个问题,我们积极招募并建立经过授权的最终用户委员会。此委员会将直接代表最终用户的利益同技术监督委员会进行沟通(类似于代表厂商利益的商务委员会)。
我们希望能够通过建立这些检查与平衡机制建立起一个稳定且专注的社区,从而利用创新成果不断推动全世界向着云原生计算技术的方向持续迈进。

#如何参与云原生计算基金会
要参与这一面向最终用户的问责体系,要求相关企业考虑或者正在着手推进由传统架构面向云原生架构的过渡工作。

参与各方将有机会加入云原生计算基金会的一系列开源项目。欲参与Kubernetes社区,企业可以考虑加入我们的Slack频道、关注GitHub上的Kubernetes项目或者加入谷歌Kubernetes开发团队。随着技术监督委员会逐步推出Kubernetes之外的更多项目,参与途径也将随之增加。

除此之外,云原生计算基金会还需要多个角度的反馈意见以帮助我们指导自身运作。以最终用户成员的身份加入云原生计算基金会将确保您的声音得到倾听与考量。

原文链接:The evolution of internet scale enterprise(翻译:孙科)

Borg和Kubernetes有什么不同以及未来的云需要什么?

DockOne 发表了文章 • 2 个评论 • 10974 次浏览 • 2015-10-31 20:48 • 来自相关话题

大家好,我是来自于华为PaaS部门的钟成,目前正在做相关的一些产品研发。我想分享的主题是从Borg到Kubernetes,其实Borg就是Kubernetes的前身。我今天主要会谈三个方面,第一个是Borg的介绍,第二是Kubernetes基于Borg做了哪些 ...查看全部
大家好,我是来自于华为PaaS部门的钟成,目前正在做相关的一些产品研发。我想分享的主题是从Borg到Kubernetes,其实Borg就是Kubernetes的前身。我今天主要会谈三个方面,第一个是Borg的介绍,第二是Kubernetes基于Borg做了哪些改变,以及它的发展方向,第三个话题想谈一下未来的云可能需要一个怎么样的产品或者是怎么样的形态。
##Borg是什么?它解决了什么问题?
我们先看第一个话题,就是Borg是什么?它解决了什么问题?

我们看一下这张图,这张图来自于一部电影叫做《星际迷航》相信大家大部分人都看过。Borg是里面的一种外星人,反派,他做什么事情呢?他和其他的文明接触,把你这个文明抢占下来,然后它会和你同化,会把你进行改造,把你改造成一个半人半机器的怪物,你就变成他们这个文明当中的一部分,然后他在这个宇宙当中不断的扩张下去。我觉得这是一个非常酷的种族。而Borg就以这个名字来命名其大规模分布式的集成管理系统。他希望他们的系统也可以把不同的机器同化掉,变成他们自己的机器,然后运行他们自己的程序。
1F571EE3-83CC-4784-9516-D34763A76898.png

对谷歌来说,Borg是一个比较顶层的集成管理系统。在它上面跑了谷歌大部分的应用程序和框架包括Gmail、Google Docs、Web Search这样直接面对客户的一些应用程序。它同时也包括一些底层的框架,(MR),包括它的一些GFS这些分布式的存储系统。也就是说你可以认为所有的应用程序都需要通过它来管理底层的这些物理机。Borg在谷歌已经成功的应用的十多年。
1852DE66-CC9B-4146-A584-A968A23D55BF.png


大家可以看一下Borg的整体的架构。它也是一个典型的分布式平台的架构,就是一个逻辑上的master,然后下面有很多的节点,每一个节点上有一些它的代理程序。这里就可以看一下,作为谷歌内部的一个工程师怎么样用这个系统呢?他们使用Borgcfg(命令行)或者Web UI提交需要跑的应用(Task) 到系统,Task可以是任何一种东西,比如说他是一个应用程序,或者是一个批处理任务,或者是一个(MR)的任务。他把这个任务通过Borgcfg提交到BorgMaster,然后BorgMaster会接受这个请求,把请求放到队列里面去,并由Scheduler来扫描这个队列,查看这个应用的资源需求,并在集群中寻找匹配的机器。你其实提交的这个任务,它需要多少的资源,你需要怎么样的机器,大概要跑多少时候,他会做一个匹配,就会看到底层有哪些机器是空闲的。然后就把这个任务发配到这个机器上面去,然后开始运行。
D21A1AA8-C8B3-407F-B1BF-62C86A3A96D3.png

这个就是总体的一个Borg的框架。一个典型的启动时间,从用户提交应用到应用启动是25秒。其中80%的时间是每个节点上下载这个应用包的时间。大家可以看到这个时间是很快的,它的调度时间还不到5秒,其中20秒是耗在传输这一层上。
##关于BorgMaster的调度原理
我后面主要想探讨一下,我今天想说的一个重点就是关于BorgMaster,它这里有很多应用,它怎么样调动这个应用的优先级呢?或者说到底哪台机器应该跑什么应用呢?Borg的做法就是对单个Task做了一个资源上的估量,大家可以看到这里有好几条线,其中一个机器上面最外面的那条虚线就是用户提交的一个资源的一个配额,就是Task再怎么运行也不能超过它的限制,这是一个硬性的限制,如果说超过这个限制,就会限制它,不让它跑。这只是用户提交的数字,大家知道用户提交的数字很多时候是不准确的,你无法预估到底你的程序在你的系统上需要耗多少CPU,占多少内存。Borg是怎么去评估这个资源呢?他在Task启动300秒之后,就进行一个资源回收的工作。大家可以看到中间有一个黄色的区域,黄色的区域就是这个应用程序实际上所消耗的资源。然后它会从外面,慢慢把它推进去,推到绿区的地方,推到绿区的地方划一条线,这条线就是所谓的保留资源,就是Borg这个系统认为你这个应用是长期稳定运行的所需要的资源。
05435753-26E1-46C8-A301-FE7408121C03.png

这里就有一个问题,为什么Borg要这么做呢?原因是为了把剩下的区域的资源给空出来,如果说我知道这个应用实际上就用了这么多的资源。然后我给它划了一定的安全线之后,剩下的这些资源我就可以调度出来,也就是说可以给到其它的应用程序用。

绿色的这一块是黄色的块加上一些安全区组成的,每过几秒重新计算一遍应用程序耗费了多少资源。这实际上是一个动态的过程,它并不是说划走了之后就再也不能变了。绿色的方块是可以一直拓展到外面的虚线的范围之内。这就是对单个Task做的一个策略。然后通过他对系统上跑的应用做了一个区分。就是说,他先想了一下,到底有哪些应用,这些应用有什么样的特性。其中有一类应用就是所谓的生产型的应用,就是prod task,其特征就是永远都是不停止的,他是一个长进程,它永远是面向用户的,比如说Gmail或者是Web Search,它中间不可能断的,它的响应时间是几微秒到几百毫秒。然后这种任务就是说,你必须要优先保证它的运行,它的短期性能波动是比较敏感的。

还有一类任务就是所谓的non-prod task,他是一个批处理任务,类似像Map Reduce,它不是直接面向用户的,对性能不是非常的敏感,跑完了就完了,下一个再跑就是下一个任务了,不是一个长进程。
0211D18D-BBB1-4D0B-B9B3-04673464C980.png

##为什么要区分任务?
当prod task的资源任务消耗比较大的时候,比如说很多人突然都来上一个网站,这个网站的服务器内存CPU就会非常高。这个时候,在这台机器上应用资源不足的时候,他就会把Non-prod task杀掉,杀掉之后让它去其他的机器上去运行。但是在空闲的时候,就可以让任务继续回来。这样的话,我就可以充分利用这台机器上的所有时间点上的资源,可以把这些东西塞的比较满。最后谷歌的测试结果是,大概20%的工作负载可以跑在回收资源上。这个数据其实是非常大的。对谷歌有那么多台的机器,你可以省下20%的资源,对它来说就是非常非常多的钱。
##Borg的价值
我这里稍微总结一下,Borg这套系统给谷歌提供了什么样的价值。它主要是提供了三个方面。第一个是隐藏的资源管理和故障处理的细节,让用户可以专注于应用开发。用户不用操心底层的系统是怎么操作的,就算我挂了他也会帮我启起来。第二个是本身提供高可靠性和高可用性的操作,并支持应用程序做到高可靠高可用。第三个是在数以万计的机器上高资源利用率运行。

对于Borg具体怎么做到这三个方面,google有一篇很长的论文《在Google使用Borg进行大规模集群的管理》,里面有很多细节,今天就不展开说了。
##Kubernetes架构
自从谷歌把Borg这个系统推出之后,对内部来说是非常成功,但是在外面的社区,其实大家都不知道这个东西到底是怎么做的,也不知道他内部是怎么实现的。后来做Borg的那批人他们就做了另外一个软件,这个软件就是Kubernetes,Kubernetes总体而言你可以认为是Borg的一个开源的版本,但是Kubernetes和Borg有一些不一样,我后面会大致的讲一下。这是Kubernetes的架构,大家其实可以看到,它的这个架构和Borg的架构基本上是类似的,包括用户怎么用的也是类似的。用户通过用kubectl这么一个命令行工具,把任务提交上来。
1.png

##Kubernetes与Borg的区别

Borg在谷歌已经运行了十年,而且机器的规模量非常大,他一个集群就是一万台,甚至更多。而Kubernetes是2014年才出来的,我个人认为这是针对亚马逊,亚马逊的公有云非常的成功,谷歌也想进入这个领域,他的方式就是把Kubernetes这个系统开源推出来,在业界产生一定的影响力,让大家都去用。这样的话,后面就可以和亚马逊竞争一下,这是我个人推测他们的一个想法。

Borg底层用的是lxc的容器,而Kubernetes是用的Docker容器。Borg是用C++编写的,Kubernetes是用Go语言编写的。Borg在集群调度的性能上做了很多的优化,Kubernetes还没有做非常多的优化,目前他在这方面还是比较土的,后面还有很多工作需要做。Borg的单集群能够调度的机器有上万台,而按Kubernetes目前只能支持几百台,这是目前的数据。

然后我们再看一下,对于这两个系统的用户来说它们有什么区别。Borg的用户其实就是谷歌的一批工程师,大家也知道谷歌工程师都是世界比较顶尖的工程师,他们在写这个程序的时候就考虑过程序会跑在云上,他知道这个程序是分布式的。他在写这个应用的时候,就会针对这个系统做非常多的优化,在设计的时候就知道我应该做一个分布式的系统。但是Kubernetes他想做的事情更多一些,就是除了运行这些分布式的系统之外,他还想就是说能够支持一些,他首先是支持Docker的这些容器,但是他还希望支持一些比较传统的,比较菜的,技术水平一般的人写的这些应用程序。他在这方面做了一些工作。一个是用了Docker容器,这样的话就支持很多东西了。还有内他还可以挂载外部的持久层,就是你可以把一些分布层面的系统挂在那个系统上面。我的容器就去读取外部的分布式的存储。这样的话,我这个容器就算是挂了,我这个数据也可以比较安全的保存。另外他就提供了一些监控还有一些日志的功能。但是这些功能是不是够呢,这还是有一定的疑问的。后期如果说我想用Kubernetes来跑一些传统的应用,那我肯定还会对这些应用和系统做一定程度的改造,但至少没有困难到无法完成。

这个是它Kubernetes设计上的一些特色,Kubernetes的网络架构是每一个Pod都有一个单独的IP,这样的应用更加友好一些。写应用程序的人就不用考虑冲突这种情况。还有就是它分组的模式,就是我这些容器如何分组。Borg是一个比较专家的系统,他有230多个参数,但是Kubernetes是非常简单的大概就是三四个描述文件就完了。
##Borg和Kubernetes的形象化总结
这里就是我对Borg和Kubernetes的一个形象化的总结。Borg就是一个喷气式飞机的驾驶系统,非常的专业和高大上,他适用于谷歌这样的大公司,它有几百万的机器。Kubernetes是一个它的简化版,它是一辆设计优良的轿车,它适合中小型公司,用它来对自己的集群进行调度。

未来Kubernetes这边也会做一些相应的工作,包括多租户支持,包括容器持久化、集群规模的提升、利用率和网络方面的等等。
2.png

##未来的云需要什么?
最后可以说是我个人的一些思考。我们未来的云到底需要什么样的东西。大家可以看到,自从计算机风靡以来,有很多的系统,很多的软件,一波又一波的起来,有一部分的系统或者说软件是比较成功的,可以长久存在下去,比如说像Java、或者是C,或者是像Windows这样,还有一些系统非常不幸,像Cobol或者是DOS或者是Minix这些系统,它们慢慢的被人所遗弃,慢慢被人所遗忘,最后变成废弃的停车场。

我这里想考虑一下,如果说再过十年,我们现在在用的一些技术,像Kubernetes或者是Borg这样的技术,是会进入到左边这个行列还是右边这个行列呢?我个人是希望进入左边的行列,毕竟我们还是希望他可以成为一款经典的产品。至少对这些系统来说,我们会非常自豪,我们做了一款比较经典的产品,可以长久的被人们所使用下去。

如果说想做到这一点,就得面对我们现在这个时代,整个计算机系统所面临的一个困境,或者说我们集群管理系统所面对的一个困境。这个困境是什么呢?就是这里所展示的Babel塔的困境。在以色列那个地方,这是一个圣经的故事,人们想造成一般座通天之塔,他们想挑战上帝的权威。上帝一看你们这批凡人,就觉得你们这批鸟人居然敢挑战我的权威,他就发明了各种语言,一起做巴别塔工作的人就各自使用不同的语言,他们就无法交流,最后这个塔就造不下去了。

其实在计算机的世界也是如此,大家使用各自的语言,各自的框架,最后使我们合作起来非常的复杂。包括我们的集群管理系统也好,包括其他的系统也好,其实都是帮助我们跨越这个鸿沟,帮助我们大家可以比较好的进行合作。但是目前来说,还没有一个非常好的方案可以让大家非常好的进行合作,我觉得这个是我们做这个系统需要做的一个事情。我这里引一句老子的话,大家可以看一下。

三十幅共一毂,当其无,有车之用。
埏埴以为器,当其无,有器之用。
凿户牖以为室,当其无,有室之用。
故有之以为利,无之以为用。




我在想,是什么因素决定了一个系统或者是一个软件,它是否可以长期生存下去呢?我觉得非常重要的一点,他要明确自己要做什么。其实就是前面讲的端水的端水,扫地的扫地,就是说你不但要明确自己这个软件要做什么,还得明确自己不要做什么。你什么东西是无以之为用,就是这个领域我是不进去的,我是不去做的。如果说你什么东西都做,最后就会比较弱,很容易就会颠覆,或者是被人取代。如果说你单单把一件事情做好,那你今后在这个领域,至少你是无可替代的,可以长期生存下去。我记得前一段时间有人问Linus,怎么看Docker容器。然后他说我才不关心这什么狗屁容器,我就关心我的内核,你不要来问我这个问题。我觉得他这个就是一个非常好的一个态度,他把他自己内核这一个模块做好,他把他系统这一块做好,那么对他而言,他这个工作就可以长期延续下去。

那么对于我们来说,比较详细一点,就是说在我们软件开发当中碰到的情况是这样的。从我们的软件设计到开发到测试、生产都经过非常多,非常反复的过程。同时在大部分的集群系统当中,我们也非常难以调度它。那么我觉得对于我们来说,就是后面要解决几个方面的问题。我觉得这是我们一个大的方向。

我们以后的产品是不是可以减少语言、程序、框架不同带来的复杂性,能不能把流程进行简化,把语言进行简化,把网络和服务依赖进行简化,这是我提的另一个问题。

经典论文 | Google使用Borg进行大规模集群的管理(第七章、第八章、鸣谢、参考文献)

难易 发表了文章 • 0 个评论 • 4476 次浏览 • 2015-10-16 20:01 • 来自相关话题

【编者的话】最后两章探讨的是相关工作和改进。从中可以看到从Borg到Kubernetes,他们也做了不少思考,而这方面的工作远远没有完善,一直在进行中。期待大家都能从Google的实践中学到一些东西,并分享出来。 7. 相关工作 资源调 ...查看全部
【编者的话】最后两章探讨的是相关工作和改进。从中可以看到从Borg到Kubernetes,他们也做了不少思考,而这方面的工作远远没有完善,一直在进行中。期待大家都能从Google的实践中学到一些东西,并分享出来。
7. 相关工作
资源调度在各个领域已经被研究了数十年了,包括在广域HPC超算集群中,在工作站网络中,在大规模服务器集群中。我们主要聚焦在最相关的大规模服务器集群这个领域。

最近的一些研究分析了集群趋势,来自于Yahoo、Google、和Facebook[20, 52, 63, 68, 70, 80, 82],展现了这些现代的数据中心和工作负载在规模和异构化方面碰到的挑战。[69]包含了这些集群管理架构的分类。

Apache Mesos [45]把资源管理和应用部署做了分离,资源管理由中心管理器(类似于Bormaster+scheduler)和多种类的“框架”比如Hadoop [41]和Spark [73],使用offer-based的机制。Borg则主要把这些几种在一起,使用request-based的机制,可以大规模扩展。DRF [29, 35, 36, 66]策略是内赋在Mesos里的;Borg则使用优先级和配额认证来替代。Mesos开发者已经宣布了他们的雄心壮志:推测性资源分配和回收,然后把[69]里面的问题都解决。

YARN [76]是一个Hadoop中心集群管理。每个应用都有一个管理器和中央资源管理器谈判;这和2008年开始Google MapReduce从Borg获取资源如出一辙。YARN的资源管理器最近才能容错。一个相关的开源项目是Hadoop Capacity Scheduler [42],提供了多租户下的容量保证、多层队列、弹性共享和公平调度。YARN最近被扩展成支持多种资源类型、优先级、驱逐、和高级权限控制[21]。俄罗斯方块原型[40]支持了最大完工时间觉察的job打包。

Facebook的Tupperware [64],是一个类Borg系统来调度cgroup容器;虽然只有少量资料泄露,看起来他也提供资源回收利用功能。Twitter有一个开源的Aurora[5],一个类Borg的长进程调度器,跑在Mesos智商,有一个类似于Borg的配置语言和状态机。

来自于微软的Autopilot[48]提供了“自动化的软件部署和开通;系统监控,以及在软硬件故障时的修复操作”给微软集群。Borg生态系统提供了相同的特性,不过还有没说完的;Isaard [48]概括和很多我们想拥护的最佳实践。

Quincy[49]使用了一个网络流模型来提供公平性和数据局部性在几百个节点的DAG数据处理上。Borg用的是配额和优先级在上万台机器上把资源分配给用户。Quincy处理直接执行图在Borg之上。

Cosmos [44]聚焦在批处理上,重点在于用户获得对集群捐献的资源进行公平获取。它使用一个每job的管理器来获取资源;没有更多公开的细节。

微软的Apollo系统[13]使用了一个每job的调度器给短期存活的batch job使用,在和Borg差不多量级的集群下获取高流量输出。Apollo使用了一个低优先级后台任务随机执行策略来增加资源利用率,代价是有多天的延迟。Apollo几点提供一个预测矩阵,关于启动时间为两个资源维度的函数。然后调度器会综合计算启动开销、远程数据获取开销来决定部署到哪里,然后用一个随机延时来避免冲突。Borg用的是中央调度器来决定部署位置,给予优先级分配处理更多的资源维度,而且更关注高可用、长期跑的应用;Apollo也许可以处理更多的task请求并发。

阿里巴巴的Fuxi(译者:也就是伏羲啦)[84]支撑数据分析的负载,从2009年开始运行。就像Borgmaster,一个中央的FuxiMaster(也是做了高可用多副本)从节点上获取可用的资源信息、接受应用的资源请求,然后做匹配。伏羲增加了和Borg完全相反的调度策略:伏羲把最新的可用资源分配给队列里面请求的任务。就像Mesos,伏羲允许定义“虚拟资源”类型。只有系统的工作负载输出是公开的。

Omega [69]支持多并行,特别是“铅垂线”策略,粗略相当于Borgmaster加上它的持久存储和link shards(连接分配)。Omega调度器用的是乐观并行的方式去控制一个共享的cell观察和预期状态,把这些状态放在一个中央的存储里面,和Borglet用独立的连接器进行同步。Omega架构。Omage架构是被设计出来给多种不同的工作负载,这些工作负载都有自己的应用定义的RPC接口、状态机和调度策略(例如长期跑的服务端程序、多个框架下的batch job、存储基础设施、GCE上的虚拟机)。形成对比的是,Borg提供了一种“万灵药”,同样的RPC接口、状态机语义、调度策略,随着时间流逝规模和复杂度增加,需要支持更多的不同方式的负载,而可可扩展性目前来说还不算一个问题($3.4)。

Google的开源Kubernetes系统[53]把应用放在Docker容器内[28],分发到多机器上。它可以跑在物理机(和Borg一样)或跑在其他云比如GCE提供的主机上。Kubernetes的开发者和Borg是同一拨人而且正在狂开发中。Google提供了一个云主机版本叫Google Container Engine [39]。我们会在下一节里面讨论从Borg中学到了哪些东西用在了Kubernetes上。

在高性能计算社区有一些这个领域的长期传统工作(e.g., Maui, Moab, Platform LSF [2, 47, 50]);但是这和Google Cell所需要的规模、工作负载、容错性是完全不一样的。大概来说,这些系统通过让很多任务等待在一个长队列里面来获取极高的资源利用率。

虚拟化提供商例如VMware [77]和数据中心方案提供商例如HP and IBM [46]给了一个大概在1000台机器量级的集群解决方案。另外,一些研究小组用几种方式提升了资源调度质量(e.g., [25, 40, 72, 74])。

最后,就像我们所指出的,大规模集群管理的另外一个重要部分是自动化和无人化。[43]写了如何做故障计划、多租户、健康检查、权限控制、和重启动性来获得更大的机器数/操作员比。Borg的设计哲学也是这样的,让我们的一个SRE能支撑超过万台机器。
8. 经验教训和未来工作
在这一节中我们会聊一些十年以来我们在生产环境操作Borg得到的定性经验,然后描述下这些观察结果是怎么改善Kubernete[53]的设计。
#8.1 教训
我们会从一些受到吐槽的Borg特性开始,然后说说Kubernetes是怎么干的。

Jobs是唯一的task分组的机制。Borg没有天然的方法去管理多个job组成单个实体,或者去指向相关的服务实例(例如,金丝雀和生产跟踪)。作为hack,用户把他们的服务拓扑编码写在job名字里面,然后用更高层的工具区解析这些名字。这个问题的另外一面是,没办法去指向服务的任意子集,这就导致了僵硬的语义,以至于无法滚动升级和改变job的实例数。

为了避免这些困难,Kubernetes不用job这个概念,而是用标签(label)来管理它的调度单位(pods),标签是任意的键值对,用户可以把标签打在系统的所有对象上。这样,对于一个Borg job,就可以在pod上打上job:jobname这样的标签,其他的有用的分组也可以用标签来表示,例如服务、层级、发布类型(生产、测试、阶段)。Kubernetes用标签选择这种方式来选取对象,完成操作。这样就比固定的job分组更加灵活好用。

一台机器一个IP把事情弄复杂了。在Borg里面,所有一台机器上的task都使用同一个IP地址,然后共享端口空间。这就带来几个麻烦:Borg必须把端口当做资源来调度;task必须先声明他们需要多少端口,然后了解启动的时候哪些可以用;Borglet必须完成端口隔离;命名和RPC系统必须和IP一样处理端口。

非常感谢Linux namespace,虚拟机,IPv6和软件定义网络SDN。Kubernetes可以用一种更用户友好的方式来消解这些复杂性:所有pod和service都可以有一个自己的IP地址,允许开发者选择端口而不是委托基础设施来帮他们选择,这些就消除了基础设置管理端口的复杂性。

给资深用户优化而忽略了初级用户。Borg提供了一大堆针对“资深用户”的特性这样他们可以仔细的调试怎么跑他们的程序(BCL有230个参数的选项):开始的目的是为了支持Google的大资源用户,提升他们的效率会带来更大的效益。但是很不幸的是这么复杂的API让初级用户用起来很复杂,约束了他们的进步。我们的解决方案是在Borg上又做了一些自动化的工具和服务,从实验中来决定合理的配置。这就让皮实的应用从实验中获得了自由:即使自动化出了麻烦的问题也不会导致灾难。
#8.2 经验
另一方面,有不少Borg的设计是非常有益的,而且经历了时间考验。

Allocs是有用的。Borg alloc抽象导出了广泛使用的logsaver样式($2.4)和另一个流行样式:定期数据载入更新的web server。Allocs和packages允许这些辅助服务能被一个独立的小组开发。Kubernetes相对于alloc的设计是pod,是一个多个容器共享的资源封装,总是被调度到同一台机器上。Kubernetes用pod里面的辅助容器来替代alloc里面的task,不过思想是一样的。

集群管理比task管理要做更多的事。虽然Borg的主要角色是管理tasks和机器的生命周期,但Borg上的应用还是从其他的集群服务中收益良多,例如命名和负载均衡。Kubernetes用service抽象来支持命名和负载均衡:service有一个名字,用标签选择器来选择多个pod。在底下,Kubernetes自动的在这个service所拥有的pod之间自动负载均衡,然后在pod挂掉后被重新调度到其他机器上的时候也保持跟踪来做负载均衡。

反观自省是至关重要的。虽然Borg基本上是“just works”的,但当有出了问题后,找到这个问题的根源是非常有挑战性的。一个关键设计抉择是Borg把所有的debug信息暴露给用户而不是隐藏:Borg有几千个用户,所以“自助”是debug的第一步。虽然这会让我们很难抛弃一些用户依赖的内部策略,但这还是成功的,而且我们没有找到其他现实的替代方式。为了管理这么巨量的资源,我们提供了几层UI和debug工具,这样就可以升入研究基础设施本身和应用的错误日志和事件细节。

Kubernetes也希望重现很多Borg的自探查技术。例如它和cAdvisor [15] 一切发型用于资源监控,用Elasticsearch/Kibana [30] 和 Fluentd [32]来做日志聚合。从master可以获取一个对象的状态快照。Kubernetes有一个一致的所有组件都能用的事件记录机制(例如pod被调度、容器挂了),这样客户端就能访问。

master是分布式系统的核心.Borgmaster原来被设计成一个单一的系统,但是后来,它变成了服务生态和用户job的核心。比方说,我们把调度器和主UI(Sigma)分离出来成为单独的进程,然后增加了权限控制、纵向横向扩展、重打包task、周期性job提交(cron)、工作流管理,系统操作存档用于离线查询。最后,这些让我们能够提升工作负载和特性集,而无需牺牲性能和可维护性。

Kubernetes的架构走的更远一些:它有一个API服务在核心,仅仅负责处理请求和维护底下的对象的状态。集群管理逻辑做成了一个小的、微服务类型的客户端程序和API服务通信,其中的副本管理器(replication controller),维护在故障情况下pod的服务数量,还有节点管理器(node controller),管理机器生命周期。
#8.3 总结
在过去十年间所有几乎所有的Google集群负载都移到了Borg上。我们将会持续改进,并把学到的东西应用到Kubernetes上。
鸣谢
这篇文章的作者同时也评审了这篇文章。但是几十个设计、实现、维护Borg组件和生态系统工程师才是这个系统成功的关键。我们在这里列表设计、实现、操作Borgmaster和Borglet的主要人员。如有遗漏抱歉。

Borgmaster主设计师和实现者有Jeremy Dion和Mark Vandevoorde,还有Ben Smith, Ken Ashcraft, Maricia Scott, Ming-Yee Iu, Monika Henzinger。Borglet的主要设计实现者是Paul Menage。

其他贡献者包括Abhishek Rai, Abhishek Verma, Andy Zheng, Ashwin Kumar, Beng-Hong Lim, Bin Zhang, Bolu Szewczyk, Brian Budge, Brian Grant, Brian Wickman, Chengdu Huang, Cynthia Wong, Daniel Smith, Dave Bort, David Oppenheimer, David Wall, Dawn Chen, Eric Haugen, Eric Tune, Ethan Solomita, Gaurav Dhiman, Geeta Chaudhry, Greg Roelofs, Grzegorz Czajkowski, James Eady, Jarek Kusmierek, Jaroslaw Przybylowicz, Jason Hickey, Javier Kohen, Jeremy Lau, Jerzy Szczepkowski, John Wilkes, Jonathan Wilson, Joso Eterovic, Jutta Degener, Kai Backman, Kamil Yurtsever, Kenji Kaneda, Kevan Miller, Kurt Steinkraus, Leo Landa, Liza Fireman, Madhukar Korupolu, Mark Logan, Markus Gutschke, Matt Sparks, Maya Haridasan, Michael Abd-El-Malek, Michael Kenniston, Mukesh Kumar, Nate Calvin, OnufryWojtaszczyk, Patrick Johnson, Pedro Valenzuela, PiotrWitusowski, Praveen Kallakuri, Rafal Sokolowski, Richard Gooch, Rishi Gosalia, Rob Radez, Robert Hagmann, Robert Jardine, Robert Kennedy, Rohit Jnagal, Roy Bryant, Rune Dahl, Scott Garriss, Scott Johnson, Sean Howarth, Sheena Madan, Smeeta Jalan, Stan Chesnutt, Temo Arobelidze, Tim Hockin, Todd Wang, Tomasz Blaszczyk, TomaszWozniak, Tomek Zielonka, Victor Marmol, Vish Kannan, Vrigo Gokhale, Walfredo Cirne, Walt Drummond, Weiran Liu, Xiaopan Zhang, Xiao Zhang, Ye Zhao, Zohaib Maya.

Borg SRE团队也是非常重要的,包括Adam Rogoyski, Alex Milivojevic, Anil Das, Cody Smith, Cooper Bethea, Folke Behrens, Matt Liggett, James Sanford, John Millikin, Matt Brown, Miki Habryn, Peter Dahl, Robert van Gent, Seppi Wilhelmi, Seth Hettich, Torsten Marek, and Viraj Alankar。Borg配置语言(BCL)和borgcfg工具是Marcel van Lohuizen, Robert Griesemer制作的。

谢谢我们的审稿人(尤其是especially Eric Brewer, Malte Schwarzkopf and Tom Rodeheffer),以及我们的牧师Christos Kozyrakis,对这篇论文的反馈。

参考文献

[1] O. A. Abdul-Rahman and K. Aida. Towards understanding the usage behavior of Google cloud users: the mice and elephants phenomenon. In Proc. IEEE Int’l Conf. on Cloud Computing Technology and Science (CloudCom), pages 272–277, Singapore, Dec. 2014.

[2] Adaptive Computing Enterprises Inc., Provo, UT. MauiScheduler Administrator’s Guide, 3.2 edition, 2011.

[3] T. Akidau, A. Balikov, K. Bekiro˘glu, S. Chernyak, J. Haberman, R. Lax, S. McVeety, D. Mills, P. Nordstrom,and S. Whittle. MillWheel: fault-tolerant stream processing at internet scale. In Proc. Int’l Conf. on Very Large Data Bases (VLDB), pages 734–746, Riva del Garda, Italy, Aug.2013.

[4] Y. Amir, B. Awerbuch, A. Barak, R. S. Borgstrom, and A. Keren. An opportunity cost approach for job assignment in a scalable computing cluster. IEEE Trans. Parallel Distrib.Syst., 11(7):760–768, July 2000.

[5] Apache Aurora.http://aurora.incubator.apache.org/, 2014.

[6] Aurora Configuration Tutorial. https://aurora.incubator.apache.org/documentation/latest/configuration-tutorial/,2014.

[7] AWS. Amazon Web Services VM Instances. http://aws.amazon.com/ec2/instance-types/, 2014.

[8] J. Baker, C. Bond, J. Corbett, J. Furman, A. Khorlin, J. Larson, J.-M. Leon, Y. Li, A. Lloyd, and V. Yushprakh. Megastore: Providing scalable, highly available storage for interactive services. In Proc. Conference on Innovative Data Systems Research (CIDR), pages 223–234, Asilomar, CA, USA, Jan. 2011.

[9] M. Baker and J. Ousterhout. Availability in the Sprite distributed file system. Operating Systems Review,25(2):95–98, Apr. 1991.

[10] L. A. Barroso, J. Clidaras, and U. H¨olzle. The datacenter as a computer: an introduction to the design of warehouse-scale machines. Morgan Claypool Publishers, 2nd edition, 2013.

[11] L. A. Barroso, J. Dean, and U. Holzle. Web search for a planet: the Google cluster architecture. In IEEE Micro, pages 22–28, 2003.

[12] I. Bokharouss. GCL Viewer: a study in improving the understanding of GCL programs. Technical report, Eindhoven Univ. of Technology, 2008. MS thesis.

[13] E. Boutin, J. Ekanayake, W. Lin, B. Shi, J. Zhou, Z. Qian, M. Wu, and L. Zhou. Apollo: scalable and coordinated scheduling for cloud-scale computing. In Proc. USENIX Symp. on Operating Systems Design and Implementation (OSDI), Oct. 2014.

[14] M. Burrows. The Chubby lock service for loosely-coupled distributed systems. In Proc. USENIX Symp. on Operating Systems Design and Implementation (OSDI), pages 335–350,Seattle, WA, USA, 2006.

[15] cAdvisor. https://github.com/google/cadvisor, 2014

[16] CFS per-entity load patches. http://lwn.net/Articles/531853, 2013.

[17] cgroups. http://en.wikipedia.org/wiki/Cgroups, 2014.

[18] C. Chambers, A. Raniwala, F. Perry, S. Adams, R. R. Henry, R. Bradshaw, and N. Weizenbaum. FlumeJava: easy, efficient data-parallel pipelines. In Proc. ACM SIGPLAN Conf. on Programming Language Design and Implementation (PLDI), pages 363–375, Toronto, Ontario, Canada, 2010.

[19] F. Chang, J. Dean, S. Ghemawat, W. C. Hsieh, D. A. Wallach, M. Burrows, T. Chandra, A. Fikes, and R. E. Gruber. Bigtable: a distributed storage system for structured data. ACM Trans. on Computer Systems, 26(2):4:1–4:26, June 2008.

[20] Y. Chen, S. Alspaugh, and R. H. Katz. Design insights for MapReduce from diverse production workloads. Technical Report UCB/EECS–2012–17, UC Berkeley, Jan. 2012.

[21] C. Curino, D. E. Difallah, C. Douglas, S. Krishnan, R. Ramakrishnan, and S. Rao. Reservation-based scheduling: if you’re late don’t blame us! In Proc. ACM Symp. on Cloud Computing (SoCC), pages 2:1–2:14, Seattle, WA, USA, 2014.

[22] J. Dean and L. A. Barroso. The tail at scale. Communications of the ACM, 56(2):74–80, Feb. 2012.

[23] J. Dean and S. Ghemawat. MapReduce: simplified data processing on large clusters. Communications of the ACM, 51(1):107–113, 2008.

[24] C. Delimitrou and C. Kozyrakis. Paragon: QoS-aware scheduling for heterogeneous datacenters. In Proc. Int’l Conf. on Architectural Support for Programming Languages and Operating Systems (ASPLOS), Mar. 201.

[25] C. Delimitrou and C. Kozyrakis. Quasar: resource-efficient and QoS-aware cluster management. In Proc. Int’l Conf. on Architectural Support for Programming Languages and Operating Systems (ASPLOS), pages 127–144, Salt Lake City, UT, USA, 2014.

[26] S. Di, D. Kondo, and W. Cirne. Characterization and comparison of cloud versus Grid workloads. In International Conference on Cluster Computing (IEEE CLUSTER), pages 230–238, Beijing, China, Sept. 2012.

[27] S. Di, D. Kondo, and C. Franck. Characterizing cloud applications on a Google data center. In Proc. Int’l Conf. on Parallel Processing (ICPP), Lyon, France, Oct. 2013.

[28] Docker Project. https://www.docker.io/, 2014.

[29] D. Dolev, D. G. Feitelson, J. Y. Halpern, R. Kupferman, and N. Linial. No justified complaints: on fair sharing of multiple resources. In Proc. Innovations in Theoretical Computer Science (ITCS), pages 68–75, Cambridge, MA, USA, 2012.

[30] ElasticSearch. http://www.elasticsearch.org, 2014.

[31] D. G. Feitelson. Workload Modeling for Computer Systems Performance Evaluation. Cambridge University Press, 2014.

[32] Fluentd. http://www.fluentd.org/, 2014.

[33] GCE. Google Compute Engine. http: //cloud.google.com/products/compute-engine/, 2014.

[34] S. Ghemawat, H. Gobioff, and S.-T. Leung. The Google File System. In Proc. ACM Symp. on Operating Systems Principles (SOSP), pages 29–43, Bolton Landing, NY, USA, 2003. ACM.

[35] A. Ghodsi, M. Zaharia, B. Hindman, A. Konwinski, S. Shenker, and I. Stoica. Dominant Resource Fairness: fair allocation of multiple resource types. In Proc. USENIX Symp. on Networked Systems Design and Implementation (NSDI), pages 323–326, 2011.

[36] A. Ghodsi, M. Zaharia, S. Shenker, and I. Stoica. Choosy: max-min fair sharing for datacenter jobs with constraints. In Proc. European Conf. on Computer Systems (EuroSys), pages 365–378, Prague, Czech Republic, 2013.

[37] D. Gmach, J. Rolia, and L. Cherkasova. Selling T-shirts and time shares in the cloud. In Proc. IEEE/ACM Int’l Symp. on Cluster, Cloud and Grid Computing (CCGrid), pages 539–546, Ottawa, Canada, 2012.

[38] Google App Engine. http://cloud.google.com/AppEngine, 2014.

[39] Google Container Engine (GKE). https://cloud.google.com/container-engine/, 2015.

[40] R. Grandl, G. Ananthanarayanan, S. Kandula, S. Rao, and A. Akella. Multi-resource packing for cluster schedulers. In Proc. ACM SIGCOMM, Aug. 2014.

[41] Apache Hadoop Project. http://hadoop.apache.org/, 2009.

[42] Hadoop MapReduce Next Generation – Capacity Scheduler. http: //hadoop.apache.org/docs/r2.2.0/hadoop-yarn/ hadoop-yarn-site/CapacityScheduler.html, 2013.

[43] J. Hamilton. On designing and deploying internet-scale services. In Proc. Large Installation System Administration Conf. (LISA), pages 231–242, Dallas, TX, USA, Nov. 2007.

[44] P. Helland. Cosmos: big data and big challenges. http://research.microsoft.com/en-us/events/ fs2011/helland\_cosmos\_big\_data\_and\_big\ _challenges.pdf, 2011.

[45] B. Hindman, A. Konwinski, M. Zaharia, A. Ghodsi, A. Joseph, R. Katz, S. Shenker, and I. Stoica. Mesos: a platform for fine-grained resource sharing in the data center. In Proc. USENIX Symp. on Networked Systems Design and Implementation (NSDI), 2011.

[46] IBM Platform Computing. http://www-03.ibm.com/ systems/technicalcomputing/platformcomputing/ products/clustermanager/index.html.

[47] S. Iqbal, R. Gupta, and Y.-C. Fang. Planning considerations for job scheduling in HPC clusters. Dell Power Solutions, Feb. 2005.

[48] M. Isaard. Autopilot: Automatic data center management. ACM SIGOPS Operating Systems Review, 41(2), 2007.

[49] M. Isard, V. Prabhakaran, J. Currey, U. Wieder, K. Talwar, and A. Goldberg. Quincy: fair scheduling for distributed computing clusters. In Proc. ACM Symp. on Operating Systems Principles (SOSP), 2009.

[50] D. B. Jackson, Q. Snell, and M. J. Clement. Core algorithms of the Maui scheduler. In Proc. Int’l Workshop on Job Scheduling Strategies for Parallel Processing, pages 87–102. Springer-Verlag, 2001.

[51] M. Kambadur, T. Moseley, R. Hank, and M. A. Kim. Measuring interference between live datacenter applications. In Proc. Int’l Conf. for High Performance Computing, Networking, Storage and Analysis (SC), Salt Lake City, UT, Nov. 2012.

[52] S. Kavulya, J. Tan, R. Gandhi, and P. Narasimhan. An analysis of traces from a production MapReduce cluster. In Proc. IEEE/ACM Int’l Symp. on Cluster, Cloud and Grid Computing (CCGrid), pages 94–103, 2010.

[53] Kubernetes. http://kubernetes.io, Aug. 2014.

[54] Kernel Based Virtual Machine. http://www.linux-kvm.org.

[55] L. Lamport. The part-time parliament. ACM Trans. on Computer Systems, 16(2):133–169, May 1998.

[56] J. Leverich and C. Kozyrakis. Reconciling high server utilization and sub-millisecond quality-of-service. In Proc. European Conf. on Computer Systems (EuroSys), page 4, 2014.

[57] Z. Liu and S. Cho. Characterizing machines and workloads on a Google cluster. In Proc. Int’l Workshop on Scheduling and Resource Management for Parallel and Distributed Systems (SRMPDS), Pittsburgh, PA, USA, Sept. 2012.

[58] Google LMCTFY project (let me contain that for you). http://github.com/google/lmctfy, 2014.

[59] G. Malewicz, M. H. Austern, A. J. Bik, J. C. Dehnert, I. Horn, N. Leiser, and G. Czajkowski. Pregel: a system for large-scale graph processing. In Proc. ACM SIGMOD Conference, pages 135–146, Indianapolis, IA, USA, 2010.

[60] J. Mars, L. Tang, R. Hundt, K. Skadron, and M. L. Soffa. Bubble-Up: increasing utilization in modern warehouse scale computers via sensible co-locations. In Proc. Int’l Symp. on Microarchitecture (Micro), Porto Alegre, Brazil, 2011.

[61] S. Melnik, A. Gubarev, J. J. Long, G. Romer, S. Shivakumar, M. Tolton, and T. Vassilakis. Dremel: interactive analysis of web-scale datasets. In Proc. Int’l Conf. on Very Large Data Bases (VLDB), pages 330–339, Singapore, Sept. 2010.

[62] P. Menage. Linux control groups. http://www.kernel. org/doc/Documentation/cgroups/cgroups.txt, 2007–2014.

[63] A. K. Mishra, J. L. Hellerstein, W. Cirne, and C. R. Das. Towards characterizing cloud backend workloads: insights from Google compute clusters. ACM SIGMETRICS Performance Evaluation Review, 37:34–41, Mar. 2010.

[64] A. Narayanan. Tupperware: containerized deployment at Facebook. http://www.slideshare.net/dotCloud/ tupperware-containerized-deployment-at-facebook, June 2014.

[65] K. Ousterhout, P. Wendell, M. Zaharia, and I. Stoica. Sparrow: distributed, low latency scheduling. In Proc. ACM Symp. on Operating Systems Principles (SOSP), pages 69–84, Farminton, PA, USA, 2013.

[66] D. C. Parkes, A. D. Procaccia, and N. Shah. Beyond Dominant Resource Fairness: extensions, limitations, and indivisibilities. In Proc. Electronic Commerce, pages 808–825, Valencia, Spain, 2012.

[67] Protocol buffers. https: //developers.google.com/protocol-buffers/, and https://github.com/google/protobuf/., 2014.

[68] C. Reiss, A. Tumanov, G. Ganger, R. Katz, and M. Kozuch. Heterogeneity and dynamicity of clouds at scale: Google trace analysis. In Proc. ACM Symp. on Cloud Computing (SoCC), San Jose, CA, USA, Oct. 2012.

[69] M. Schwarzkopf, A. Konwinski, M. Abd-El-Malek, and J. Wilkes. Omega: flexible, scalable schedulers for large compute clusters. In Proc. European Conf. on Computer Systems (EuroSys), Prague, Czech Republic, 2013.

[70] B. Sharma, V. Chudnovsky, J. L. Hellerstein, R. Rifaat, and C. R. Das. Modeling and synthesizing task placement constraints in Google compute clusters. In Proc. ACM Symp. on Cloud Computing (SoCC), pages 3:1–3:14, Cascais, Portugal, Oct. 2011.

[71] E. Shmueli and D. G. Feitelson. On simulation and design of parallel-systems schedulers: are we doing the right thing? IEEE Trans. on Parallel and Distributed Systems, 20(7):983–996, July 2009.

[72] A. Singh, M. Korupolu, and D. Mohapatra. Server-storage virtualization: integration and load balancing in data centers. In Proc. Int’l Conf. for High Performance Computing, Networking, Storage and Analysis (SC), pages 53:1–53:12, Austin, TX, USA, 2008.

[73] Apache Spark Project. http://spark.apache.org/, 2014.

[74] A. Tumanov, J. Cipar, M. A. Kozuch, and G. R. Ganger. Alsched: algebraic scheduling of mixed workloads in heterogeneous clouds. In Proc. ACM Symp. on Cloud Computing (SoCC), San Jose, CA, USA, Oct. 2012.

[75] P. Turner, B. Rao, and N. Rao. CPU bandwidth control for CFS. In Proc. Linux Symposium, pages 245–254, July 2010.

[76] V. K. Vavilapalli, A. C. Murthy, C. Douglas, S. Agarwal, M. Konar, R. Evans, T. Graves, J. Lowe, H. Shah, S. Seth, B. Saha, C. Curino, O. O’Malley, S. Radia, B. Reed, and E. Baldeschwieler. Apache Hadoop YARN: Yet Another Resource Negotiator. In Proc. ACM Symp. on Cloud Computing (SoCC), Santa Clara, CA, USA, 2013.

[77] VMware VCloud Suite. http://www.vmware.com/products/vcloud-suite/.

[78] A. Verma, M. Korupolu, and J. Wilkes. Evaluating job packing in warehouse-scale computing. In IEEE Cluster, pages 48–56, Madrid, Spain, Sept. 2014.

[79] W. Whitt. Open and closed models for networks of queues. AT&T Bell Labs Technical Journal, 63(9), Nov. 1984.

[80] J. Wilkes. More Google cluster data. http://googleresearch.blogspot.com/2011/11/ more-google-cluster-data.html, Nov. 2011.

[81] Y. Zhai, X. Zhang, S. Eranian, L. Tang, and J. Mars. HaPPy: Hyperthread-aware power profiling dynamically. In Proc. USENIX Annual Technical Conf. (USENIX ATC), pages 211–217, Philadelphia, PA, USA, June 2014. USENIX Association.

[82] Q. Zhang, J. Hellerstein, and R. Boutaba. Characterizing task usage shapes in Google’s compute clusters. In Proc. Int’l Workshop on Large-Scale Distributed Systems and Middleware (LADIS), 2011.

[83] X. Zhang, E. Tune, R. Hagmann, R. Jnagal, V. Gokhale, and J. Wilkes. CPI2: CPU performance isolation for shared compute clusters. In Proc. European Conf. on Computer Systems (EuroSys), Prague, Czech Republic, 2013.

[84] Z. Zhang, C. Li, Y. Tao, R. Yang, H. Tang, and J. Xu. Fuxi: a fault-tolerant resource management and job scheduling system at internet scale. In Proc. Int’l Conf. on Very Large Data Bases (VLDB), pages 1393–1404. VLDB Endowment Inc., Sept. 2014.

勘误 2015-04-23

自从胶片版定稿后,我们发现了若干疏忽和歧义。

#用户视角

SRE干的比SA(system administration)要多得多:他们是Google生产服务的负责工程师。他们设计和实现软件,包括自动化系统、管理应用、底层基础设施服务来保证Google这个量级的高可靠和高性能。

#鸣谢

我们不小心忽略了Brad Strand, Chris Colohan, Divyesh Shah, Eric Wilcox, and Pavanish Nirula。

#参考文献

[1] Michael Litzkow, Miron Livny, and Matt Mutka. "Condor - A Hunter of Idle Workstations". In
Proc. Int'l Conf. on Distributed Computing Systems (ICDCS) , pages 104-111, June 1988.

[2] Rajesh Raman, Miron Livny, and Marvin Solomon. "Matchmaking: Distributed Resource
Management for High Throughput Computing". In Proc. Int'l Symp. on High Performance
Distributed Computing (HPDC) , Chicago, IL, USA, July 1998.

经典论文 | Google使用Borg进行大规模集群的管理(第一章、第二章)

难易 发表了文章 • 6 个评论 • 10933 次浏览 • 2015-10-10 20:21 • 来自相关话题

【编者的话】本文是对Google在分布式底层架构的经典文章的翻译,尽可能还原Google作者的原意和了解他们设计这个系统的初衷,希望大家多多指正我的翻译,原 ...查看全部
【编者的话】本文是对Google在分布式底层架构的经典文章的翻译,尽可能还原Google作者的原意和了解他们设计这个系统的初衷,希望大家多多指正我的翻译,原文较长,还在翻译中,最后会整理成一篇文章。

原作:
Abhishek Vermay, Luis Pedrosaz, Madhukar Korupolu,
David Oppenheimer, Eric Tune, John Wilkes

Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored.For all other uses, contact the owner/author(s).
EuroSys’15, April 21–24, 2015, Bordeaux, France.
Copyright is held by the owner/author(s).
ACM 978-1-4503-3238-5/15/04.
http://dx.doi.org/10.1145/2741948.2741964

摘要
谷歌的Borg系统群集管理器运行几十万个以上的jobs,来自几千个不同的应用,跨多个集群,每个集群有上万个机器。

它通过管理控制、高效的任务包装、超售、和进程级别性能隔离实现了高利用率。它支持高可用性应用程序与运行时功能,最大限度地减少故障恢复时间,减少相关故障概率的调度策略。Borg简化了用户生活,通过提供一个声明性的工作规范语言,名称服务集成,实时作业监控,和分析和模拟系统行为的工具。

我们将会展现Borg系统架构和特点,重要的设计决策,定量分析它的一些策略,和十年以来的运维经验和学到的东西。
图1.jpg

1. 简介
集群管理系统我们内部叫Borg,它管理、调度、开始、重启和监控谷歌运行的应用程序的生命周期。本文介绍它是怎么做到这些的。

Borg提供了三个主要的好处:它(1)隐藏资源管理和故障处理细节,使其用户可以专注于应用开发;(2)高可靠性和高可用性的操作,并支持应用程序做到高可靠高可用;(3)让我们在跨数以万计的机器上有效运行。Borg不是第一个来解决这些问题的系统,但它是在这个规模,这种程度的弹性和完整性下运行的为数不多的几个系统之一。

本文围绕这些主题来编写,包括了我们在生产环境运行十年的一些功力。
2.用户视角
Borg的用户是谷歌开发人员和系统管理员(网站可靠性工程师 SRE),他们运行谷歌应用与服务。用户以job的方式提交他们的工作给Borg,job由一个或多个task组成,每个task含有同样的二进制程序。一个job在一个Borg的Cell里面跑,一个Cell是包括了多台机器的单元。这一节主要讲用户视角下的Borg系统。
#2.1 工作负载
Borg Cell主要运行两种异构的工作负载。第一种是长期的服务,应该“永远”运行下去,并处理短时间的敏感请求(几微秒到几百毫秒)。这种服务是面向终端用户的产品如Gmail、Google Docs、网页搜索,内部基础设施服务(例如,Bigtable)。第二种是批处理任务,需要几秒到几天来完成,对短期性能波动不敏感。在一个Cell上混合运行了这两种负载,取决于他们的主要租户(比如说,有些Cell就是专门用来跑密集的批处理任务的)。工作负载也随着时间会产生变化:批处理任务做完就好,终端用户服务的负载是以每天为周期的。Borg需要把这两种情况都处理好。

Borg有一个2011年5月的负载数据[80],已经被广泛的分析了[68,26,27,57,1]。

最近几年,很多应用框架是搭建在Borg上的,包括我们内部的MapReduce[23]、flumejava[18]、Millwheel[3]、Pregel[59]。这中间的大部分都是有一个控制器,可以提交job。前2个框架类似于YARN的应用管理器[76]。我们的分布式存储系统,例如GFS[34]和他的后继者CFS、Bigtable[19]、Megastore[8]都是跑在Borg上的。

在这篇文章里面,我们把高优先级的Borg的jobs定义为生产(prod),剩下的是非生产的(non-prod)。大多长期服务是prod的,大部分批处理任务是non-prod的。在一个典型的Cell里面,prod job分配了70%的CPU资源然后实际用了60%;分配了55%的内存资源然后实际用了85%。在$5.5会展示分配和实际值的差是很重要的。
#2.2 集群和Cell
一个Cell里面的所有机器都属于单个集群,集群是由高性能的数据中心级别的光纤网络连接起来的。一个集群安装在数据中心的一座楼里面,n座楼合在一起成为一个site。一个集群通常包括一个大的Cell还有一些小的或测试性质的Cell。我们尽量避免任何单点故障。

在测试的Cell之外,我们中等大小的Cell大概包括10000台机器;一些Cell还要大很多。一个Cell中的机器在很多方面都是异构的:大小(CPU、RAM、disk、network)、处理器类型、性能以及外部IP地址或flash存储。Borg隔离了这些差异,让用户单纯的选择用哪个Cell来跑任务,分配资源、安装程序和其它依赖、监控系统的健康并在故障时重启。

(译者:Cell其实就是逻辑上的集群)
#2.3 job和task
一个Borg的job的属性有:名字、拥有者和有多少个task。job可以有一些约束,来指定这个job跑在什么架构的处理器、操作系统版本、是否有外部IP。约束可以是硬的或者软的。一个job可以指定在另一个job跑完后再开始。一个job只在一个Cell里面跑。

每个task包括了一组linux进程,跑在一台机器的一个容器内[62]。大部分Borg的工作负载没有跑在虚拟机(VM)里面,因为我们不想付出虚拟化的代价。而且,Borg在设计的时候还没硬件虚拟化什么事儿哪。

task也有一些属性,包括资源用量,在job中的排序。大多task的属性和job的通用task属性是一样的,也可以被覆盖 —— 例如,提供task专用的命令行参数,包括CPU核、内存、磁盘空间、磁盘访问速度、TCP端口等等,这些都是可以分别设置并按照一个好的粒度提供。我们不提供固定的资源的单元。Borg程序都是静态编译的,这样在跑的环境下就没有依赖,这些程序都被打成一个包,包括二进制和数据文件,能被Borg安装起来。

用户通过RPC来操作Borg的job,大多是从命令行工具,或者从我们的监控系统($2.6)。大多job描述文件是用一种申明式配置文件BCL -- GCL[12]的一个变种,会产生一个protobuf文件[67]。BCL有一些自己的关键字。GCL提供了lambda表达式来允许计算,这样就能让应用在环境里面调整自己的配置。上万个BCL配置文件超过一千行长,系统中累计跑了了千万行BCL。Borg的job配置很类似于Aurora配置文件[6]。
图2.jpg

图2展现了job的和task的状态机和生命周期。

用户可以在运行时改变一个job中的task的属性,通过推送一个新的job配置给Borg。这个新的配置命令Borg更新task的规格。这就像是跑一个轻量级的,非原子性的事务,而且可以在提交后轻易再改回来。更新是滚动式的,在更新中可以限制task重启的数量,如果有太多task停掉,操作可以终止。

一些task更新,例如更新二进制程序,需要task重启;另外一些例如修改资源需求和限制会导致这个机器不适合跑现有的task,需要停止task再重新调度到别的机器上;还有一些例如修改优先级是可以不用重启或者移动task的。

task需要能够接受Unix的SIGTERM信号,在他们被强制发送SIGKILL之前,这样就有时间去做清理、保存状态、结束现有请求执行、拒绝新请求。实际的notice的delay bound。实践中,80%的task能正常处理终止信号。

#2.4 Allocs
Borg的alloc(allocation的缩写)是在单台机器上的一组保留的资源配额,用来让一个或更多的task跑;这些资源一直分配在那边,无论有没有被用。allocs可以被分配出来给未来的task,用来保持资源在停止一个task和重启这个task之间,用来聚集不同jobs的tasks到同一台机器上——例如一个web server实例和附加的,用于把serverURL日志发送到一个分布式文件系统的日志搜集实例。一个alloc的资源管理方式和一台机器上的资源管理方式是类似的;多个tasks在一个alloc上跑并共享资源。如果一个alloc必须被重新定位到其他的机器上,那么它的task也要跟着重新调度。

一个alloc set就像一个job:它是一组allocs保留了多台机器上的资源。一旦alloc set被创建,一个或多个jobs就可以被提交进去跑。简而言之,我们会用task来表示一个alloc或者一个top-level task(一个alloc之外的),用job来表示一个job或者alloc set。
#2.5 优先级、配额和管理控制
当有超量的工作负载在运行的时候会发生什么事情?我们的解决方案是优先级和配额。

所有job都有优先级,一个小的正整数。高优先级的task可以优先获取资源,即使后面被杀掉。Borg定义了不重叠的优先级段给不同任务用,包括(优先级降序):监控、生产、批任务、高性能(测试或免费)。在这篇文章里面,prod的jobs是在监控和生产段。

虽然一个降级的task总会在cell的其他地方找到一席之地。降级瀑布也有可能会发生,就是一个task降下来之后,把下面运行的task再挤到别的机器上,如此往复。为了避免这种情况,我们禁止了prod级task互相排挤。合理粒度的优先级在其他场景下也很有用——MapReduce的master跑的优先级比worker高一点,来保证他们的可用性。

优先级是jobs的相对重要性,决定了jobs在一个cell里面是跑还是等(pending)。配额则是用来决定jobs是否运行被调度。配额就是一组资源(CPU,RAM,disk)的数量在一个指定的优先级、一个指定的时间段(月这个量级)。数量决定了这个用户的job可以用的最多资源(例子:20TB内存和prod优先级从现在到7月在xx cell内)。配额检查是管理控制的一部分,不是调度层的:配额不足的任务在提交的时候就会被拒绝。

高优先级的配额总是花费的比低优先级要多。prod级的配额是被限制为一个cell里面实际的资源量,所以用户提交了prod级的job的配额时,可以期待这个job一定会跑,去掉一些碎片外。即使这样,我们鼓励用户多买一点比自己需要多一点的配额,很多用户超买是因为他们的应用程序的用户数量增长后需要的配额就大了。对于超买,我们的应对方案是低优先级资源的超售:所有用户在0优先级都可以用无限的配额,虽然在实际运行中这种情况很难跑起来。一个低优先级的job在资源不足时会保持等(pending)状态。

配额分配在Borg系统之外,和我们的物理资源计划有关。这些资源计划在不同的数据中心产生不同的价格和配额。用户jobs只在有足够配额和足够优先级之后才能启动。配额的使用让Dominant Resource Fairness(DRF)[29, 35, 36, 66]不是那么必要了。

Borg有一个容量系统给一些特殊权限给某些用户,例如,允许管理员删除或修改cell里面的job,或者允许用户区访问特定的内核特性或者让Borg对自己的job不做资源估算($5.5)。
#2.6 命名和监控
光是创建和部署task是不够的:一个服务的客户端和其他系统需要能找到它们,即使它换了个地方。为了搞定这一点,Borg创造了一个稳定的“Borg name Service”(BNS)名字给每个task,这个名字包括了cell名字,job名字,和task编号。Borg把task的主机名和端口写入到一个持久化高可用文件里,以BNS名为文件名,放在Chubby[14]上。这个文件被我们的RPC系统使用,用来发现task的终端地址。BNS名称也是task的DNS名的基础构成部分,所以,cc cell的ubar用户的jfoo job的第50个task的DNS名称会是50.jfoo.ubar.cc.borg.google.com。Borg同时还会把job的大小和task的健康信息写入到Chubby在任何情况改变时,这样负载均衡就能知道怎么去路由请求了。

几乎所有的Borg的task都会包含一个内置的HTTP服务,用来发布健康信息和几千个性能指标(例如RPC延时)。Borg监控这些健康检查URL,把其中响应超时的和error的task重启。其他数据也被监控工具追踪并在Dashboard上展示,当服务级别对象(SLO)出问题时就会报警。

用户可以使用一个名叫Sigma的web UI,用来检查他们所有的job状态,一个特殊的cell,或者深入到某个job的某个task的资源用率,详细日志,操作历史,和最终命运。我们的应用产生大量的日志,都会被自动的滚动来避免塞满硬盘,会在一个task结束后保留一小段时间用来debug。如果一个job没有被跑起来,Borg会提供一个为什么挂起的解释,指导用户怎么修改这个job的资源需求来符合目前这个cell的情况。我们发布资源的使用方针,按照这个方针来做就容易被调度起来。

Borg记录所有的job提交和task时间,以及每task的资源使用细节在基础存储服务里面。这个存储服务有一个分布式的只读的SQL-like的交互式接口,通过Dremel[61]提供出来。这些数据在实时使用、debug、系统查错和长期容量规划上都很有用。这些数据也是Google集群负载追踪的数据来源之一[80]。

所有这些特性帮助用户理解和debug Borg的行为和管理他们的job,并且帮助我们的SRE每个人管理超过上万台机器。

原文链接:Large-scale cluster management at Google with Borg(翻译:难易

Google现提供容器服务,允许客户在Google Cloud上运行纯微服务架构

codesun 发表了文章 • 0 个评论 • 4917 次浏览 • 2015-08-27 18:10 • 来自相关话题

【编者的话】IT巨头Google现已加入Docker豪华午餐,它为客户提供了一项简洁、高效且稳定的容器服务,目前GCE已全面对外开放。 Google是最新的容器云服务提供商,而容器技术是一种新兴的虚拟化技术,其支持者称它可以简化在云中 ...查看全部
【编者的话】IT巨头Google现已加入Docker豪华午餐,它为客户提供了一项简洁、高效且稳定的容器服务,目前GCE已全面对外开放。

Google是最新的容器云服务提供商,而容器技术是一种新兴的虚拟化技术,其支持者称它可以简化在云中运行应用的流程。

Google现开始提供名为Google Container Engine(以下简称GCE)的容器管理服务。这为商业用户在Google云平台的容器中运行它们最重要的应用提供了可能。

越来越多的公司开始使用容器来构建应用,它可以方便地实现扩展、复制以及升级。这个新服务提供了一种全新的途径来管理大量容器,免除了涉及到多容器业务流操作的大量底层工作。

Google于2014年11月首次对外发布了容器引擎,不过只是预览版本。随着这次商业性的发布,Google确保该服务已经具备好应对生产环境的各种条件,并承诺99.95%的正常运行时间。

另外,定价也已经确定。少于6个节点的用户可以免费使用,若需管理多于6个节点则需为每个集群支付$0.15/小时的费用。

Google自身早已使用容器来运行Internet服务,例如搜索和邮箱服务。

通过容器,公司可以让每个组件包含一部分应用,以模块化的方式构建它们的应用,这就是广为人知的微服务架构。当应用需要更新时,一个新的容器可以轻易地实现替换,以减小对操作的影响。

容器也为DevOps形式的软件开发创造了条件。这种情况下,开发者在开发应用时快速地迭代,通过在容器中打包,每个独立的组件都可以轻松地进行测试。

通过这个服务,用户在单次操作中,完成对多容器复杂应用的部署。GCE会记录操作日志,以确保每个容器的正确运行,它也提供一条简易的途径,通过增加额外的处理器或内存,来调整集群的大小。

Porch是一家初创公司,它为客户提供一项列表服务来寻找家装专业人士。在一篇宣布GCE发布的文章中,我们发现Porch声称,与其它云服务相比,使用Google的基于容器的解决方案只需要约40%的资源。

基于容器的架构也允许公司在内部部署环境与云服务,抑或是两个云服务之间,迁移它们的应用。Microsoft、IBM、Red Hat和VMware都通过它们各自的服务和企业软件栈提供容器管理技术。

GCE基于Kubernetes,Kubernetes是一个由Google开发的开源容器管理软件。

原文链接:Google's container management service exits beta, gets uptime guarantee(翻译:孙科)

Google Cloud Run 详细介绍

Andy_Lee 发表了文章 • 0 个评论 • 226 次浏览 • 2019-05-16 21:28 • 来自相关话题

#Cloud Run介绍 在旧金山举办的 Google Cloud Next 2019 大会上,Google 宣布了 Cloud Run,这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 Knative ...查看全部
#Cloud Run介绍
在旧金山举办的 Google Cloud Next 2019 大会上,Google 宣布了 Cloud Run,这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 Knative 项目,是 Knative 的 Google Cloud 托管版本,也是业界第一个基于 Knative + Kubernetes 的 Serverless 托管服务。

援引来自 Google Cloud 官方网站的介绍资料,对 Cloud Run 的定位是:

Run stateless HTTP containers on a fully managed environment or in your own GKE cluster.



在完全托管的环境或者自己的 GKE 集群中运行 Serverless HTTP 容器。



目前 Google Cloud 还处于测试阶段,尚未GA,而且暂时只在美国地区提供。
#Cloud Run 推出的背景
这里有一个大的背景:在 Knative 出来之前,Serverless 市场虽然火热,但是有一个根本性的问题,就是市场碎片化极其严重,有大大小小几十个产品和开源项目,而且存在严重的供应商绑定风险。因此,Google 牵头推出了 knative 开源项目,希望实现 Serverless 的标准化和规范化。如果你想和者更多 Serverless 技术专家交流,可以加我微信liyingjiese,备注『加群』。群里每周都有全球各大公司的最佳实践以及行业最新动态

关于Knative 的详细情况,这里不继续展开,有兴趣的同学可以阅读我之前的演讲分享 Knative: 重新定义Serverless
##Google Cloud 上的 Serverless
在 Cloud Run 出现之后,目前 Google Cloud 上就有三种 Serverless 产品了:

  1. Cloud Functions:事件驱动的 Serverless 计算平台
  2. App Engine:高可扩展的 Serverless Web应用
  3. Cloud Run:无状态的 Serverless HTTP 容器,口号是 Bringing Serverless to Containers

1.png

##Bring Serverless to Containers
这是 Cloud Run / Knative 区别于之前的各种 Serverless 产品的本质不同之处:支持的工作负载不再局限于 Function,而是任意容器!

备注:当然基本的容器运行时契约还是要遵守的,具体要求见下面的介绍。



和 Function 相比,以 Container 方式呈现的工作负载,给使用者更大的自由度,Google Cloud 对此给出的口号是:

* Any langurage / 不限语言
* Any library / 不限类库
* Any binary 不限二进制文件(备注:格式还是要限制的,要求 Linux x86_64 ABI 格式)
* Ecosystem of base images / 基础镜像的生态系统
* Industry standard/工业标准

2.png

Google Cloud Run / Knative 对容器的要求,和通用容器相比,强调 无状态(Stateless) / 请求驱动(request-triggered) / 可自动伸缩(autoscaled):
3.png

如上图所示,请求流量通常并非均匀分布,有突发高峰,有长期低谷,甚至有时没有流量。因此,从资源使用率的角度考虑,处理这些请求流量的服务容器的实例也应该随请求流量变化,做到自动伸缩,按需使用,以节约成本。
#Cloud Run的特性和要求
##Cloud Run 的特性概述
下图是整理的 Cloud Run 的几个主要特性,其核心还是那句口号 “Bring Serverless to Container”:
4.png


* 以容器形式出现的工作负载:不只是 Function,极大的丰富了 Serverless 的玩法
* 兼容 Knative API:这也是近年来 Google 的一贯打法,开源项目先行,对社区开放,拉拢盟友建立标准,以无厂商锁定的风险来吸引客户,我将其简称为”开源开放不锁定”。
* GCP 托管:托管的好处自然是客户无需运维,这也是 Serverless 的由来和最基本的特性
* 流量驱动模式:请求驱动,实例数量可自动伸缩,甚至伸缩到 0,因此无需在业务高峰时预先配置资源和事后手工释放资料,极大的减少运维需要。在此基础上,执行按使用付费,因此可以在不同的应用之间(在公有云上则可以在不同的客户之间)共享成本,以低成本的方式应付短期突发高并发请求。

Cloud Run 的其他特性还有:

* 快速从容器到生产部署
* 开发体验简单
* 高可用:自动跨区域的冗余
* 和 Stackdrive的集成,监控/日志/错误报告都是开箱即用
* 可自定义域名

这些特性容易理解,就不一一展开。
##适用于更多的场景
传统的基于 Function 负载的 Serverless,受限于 Function,适用范围相对有限,尤其不适合非 Function 方式编写的旧有应用,而将应用改造为 Function 一来工作量巨大,二来也不是所有的应用都适合用 Function 形式开发。

在以 Function 为负载的 Serverless 系统中,调用往往发生在外部对 Function 的访问,类似API Gateway下的南北向通信。Function 之间通常不直接相互调用(某些情况下需要调用时,往往也是走外部调用的通道),因此调用关系相对简单。
5.png

当工作负载从 Function 转变为 Container 之后,不仅仅有 Serverless 原有的南北向通信,而且以容器形态出现的工作负载之间相互调用的场景大为增加,这些负载之间的相互调用类似于传统SOA/微服务框架的东西向服务间通信。Cloud Run 通过支持容器作为工作负载,极大的扩大了 Serverless 的适用范围。
6.png

除了前面列出来的两种场景之外,Cloud Run 还可以适用于其他场景,如事件驱动/异步任务/调度服务等:
7.png

这也迎合了目前 Serverless 的发展趋势:未来 Serverless 将渗透到各种场景,任何需要按照请求自动实现资源动态调度的工作负载都应该 Serverless 化。我称之为:万物皆可 Serverless!从 Function 到 Container,Serverless 朝这个目标迈出了一大步。
##Cloud Run的并发模型
重点看一下 Cloud Run 对请求并发的处理,因为这涉及到如何动态调配服务容器实例的个数。

在 Cloud Run 中,每个服务都要自动伸缩容器的实例数量来应对请求流量。在 Cloud Run 中对并发(Concurrency)的定义是:

Concurrency = “maximum number of requests that can be sent at the same time to a given container instance”



并发 = “可以同时对给定容器实例发送请求的最大数量”



也就是我们平时理解的”最大并发请求数”,或者”最大工作线程数”。在这一点上,Cloud Run 的做法和 AWS Lambda 还有 Google 自己的 Cloud Function 不同,后两者的做法是每个实例只能同时接受一个请求,相当于 “Concurrency=1”。如图,当有多个并发请求时就需要启动多个实例。
8.png

而在 Cloud Run 中,并发度是可以设置的,容许的值范围是从 1 到 80,默认值是80,如下图所示:
9.png

如果并发度设置为 1 则 Cloud Run 的行为也就和 AWS Lambda/Google Cloud Function 一致了,不过对于容器形式的工作负载而言,容器启动和销毁的资源消耗和成本就有过高了,因此 Cloud Run 下通常建议根据实际业务场景设置合适的并发度/请求数上限。这样在处理请求时,可以用一个实例对应多个请求,从而不必启动太多的实例。
10.png

##Cloud Run对容器的要求
11.png

在 Google Cloud Run 的文档中, Container运行时契约 中列出了 Cloud Run 对容器的要求,主要包括:

* 语言支持,可以使用任意语言编写代码,可以使用任意基础镜像,但是容器镜像必须是为64位Linux编译的;Cloud Run 支持 Linux x86_64 ABI 格式。
* 请求监听,容器必须在 0.0.0.0 上监听,端口由环境变量 PORT 定义。目前在 Cloud Run 中,PORT 环境变量总是设置为 8080,但是为了可移植性,不能 hardcode。
* 启动时间和响应时间,容器实例必须在收到请求后的四分钟内启动HTTP服务器; 容器实例必须收到HTTP请求后的规定时间内发送响应,该时间由 request timeout setting 配置,包含容器实例的启动时间。否则请求会被终止并返回 504 错误。
* 文件访问,容器的文件系统是可写的并受以下影响:

* 文件系统是基于内存的,写入文件系统会使用容器实例的内存
* 写入到文件系统中的数据不会持久化

* 容器实例生命周期考虑,服务的每个版本都将自动伸缩,如果某个版本没有流量,则会缩减到 0。服务应该是无状态的,计算应该限定于请求的范围,如果没有请求则不能使用CPU。
* 容器实例资源,每个容器实例分配 1 vCPU 而且不能修改。每个容器实例默认 256M 内存,可以修改,最多为 2G。

请注意,Cloud Run 目前处于测试阶段,因此这些要求可能会随时间而发生变化。

Container Runtime Contract 更详细的信息,请参考:

* Google Container Runtime Contract
* Knative Container Runtime Contract
* Open Container Initiative Runtime Specification

##Cloud Run的限制
目前 Cloud Run 的限制有:

* 最多 1 个vCPU 和 2 G 内存
* 不能访问 GPU
* 没有 Cloud SQL (即将提供)
* 没有 VPS 访问(即将提供)
* 不支持全局负载均衡
* 只支持 HTTP (未来会支持gRPC)

而这些限制,都可以通过选择使用 Cloud Run on GKE 来解决。
##安全容器gVisor的使用
gVisor 是由 Google 开源的容器沙箱运行时(Container sandbox runtime)。用于在宿主机操作系统与容器中的应用之间创建一个安全的隔离边界,便于安全的对外提供大规模部署的容器服务——关于安全容器和 gVisor 的介绍就不在这里展开。

在 Cloud Run 中,容器是运行在 gVisor 之上的,而不是默认的Kubernetes runc runtime。gVisor为 Cloud Run 带来了安全容器的隔离,但是也带来了一些限制。如下图所示,gVisor 支持的 System Call 是有限的,不支持所有的 Linux System Call。但是考虑到 Cloud Run 的主要使用场景是无状态的 HTTP 容器,正常情况下应该不会触发这个限制。
12.png

#和 Knative 的关系
Google Cloud 给出的一些PPT中宣称 Cloud Run 就是托管版本的 knative,当然这一点我个人有些质疑:当前开源版本的 knative 实在有些不够成熟,应该还达不到生产级强度,Google Cloud 托管的有可能是 knative 的内部版本。但可以肯定的是,Cloud Run 一定是兼容 knative API 的。

目前 Knative 发展趋势非常不错,尤其社区快速成长,聚拢了一批大小盟友。这里有一份 Google 给出的长长列表,列出了当前参与 Knative 开发的贡献者来自的公司:

VMware, Huawei, Cisco, TriggerMesh, Dropbox, SAP, Microsoft, Schibsted, Apache, Independent, China Mobile NTT, CloudBees, Caicloud, Inovex, Docker, Heureka, CNCF, Liz Rice, Zalando, Douyu.com, Nebula. OpsGenie. Terracotta, Eldarion, Giant Swarm, Heroku, Revolgy, SORINT.lab, Switch, Ticketmaster, Virtustream,, Alipay, Blue Box, Cruise Automation, EPAM Systems, EVRY, Foreningen Kollegienet Odense, Giddyinc, IPB, Manifold.co, Orange, Puppet, Stark & Wayne, Weaveworks, Disney Interactive, Ivx, Mediative, Ministère de l’Agriculture et de l’Alimentation, NatureServe, Samsung SDS. Typeform, Wise2c



当然,其中最重要的力量还是来自 Google 自己,以及 Redhat、Pivotal、IBM 这三位社区巨头。下图是以公司为单位的贡献度比例:
13.png

下图是基于Knative 的几个主要 Serverless 产品,除了 Google 的 Cloud Run 之后,还有 Redhat / Pivotal / IBM 等大厂:
14.png

#Serverless 计算平台选择
Cloud Run 是一个 Serverless 计算平台,用于运行无状态 HTTP 应用程序。 它有两种风格:完全托管的环境或 Google Kubernetes Engine 集群。

  1. Cloud Run:完全托管,完整的serverless体验,客户不需要管理集群,按使用付费。
  2. Cloud Run on GKE:只具有 serverless 的开发体验,客户需要在自己的 GKE 集群中运行,价格包含在 GKE 集群中。

15.png

Cloud Run on GKE 具有和 Cloud Run 相同的开发体验,但是 Cloud Run on GKE 运行在 k8s 上,有更多的灵活性和控制力,不过需要自己运维。Cloud Run on GKE 可以集成基于k8s的策略、控制和管理。允许访问自定义计算机类型,额外的网络和GPU支持,以扩展Cloud Run服务的运行方式。

可以在 Cloud Run 和 Cloud Run on GKE 之间按需要选择,另外 Google Cloud 容许在 Cloud Run 和 Cloud Run on GKE 之间切换,无需改动应用。

Cloud Run 和 Cloud Run on GKE 的详细对比:
16.png

考虑到 Cloud Run 是 Knative 的 Google Cloud 托管版本,对于客户,则理论上在 Cloud Run 和 Cloud Run on GKE 之外还存在另外一种选择:直接使用开源版本的 Knative。
17.png

或者 Google 之外的其他基于 Knative 的产品,如Redhat / IBM / Pivotal 等,从而避免了供应商锁定的风险。

这也是 Google 在宣传 Cloud Run 产品是一直反复强调的:开源、开放、不绑定。

回到在 Google Cloud 上进行 Serverless 平台选择这个话题,现在 Google Cloud 上的 Serverless 有 Function / App / Container 三种模式,而其中的 Container 模式又可以细分为 Cloud Run 和 Cloud Run on GKE 两种形态,还有一个自由度极高可以自由发挥的GKE。下图摘录自 Google 的演讲PPT,做了很好的分类和总结:
18.png

#Cloud Run的计费
最后关注一下 Cloud Run的计费,Cloud Run 的官方文档 Pricing 对此有详细的描述,这里摘录部分内容。

首先,完全托管式的 Cloud Run 仅为使用的资源收取费用,计费到最近的100毫秒。而 Cloud Run on GKE 则不同,GKE 上的 Cloud Run 是 Google Kubernetes Engine 集群的附加组件。而 Cloud Run on GKE 部署的工作量包含在 GKE 定价中。而 GKE 上 Cloud Run 的最终定价要到 GA 才确定。

Cloud Run 的计费模型也颇具创新性,不是完全按请求数量计费,而是同时考量三个指标:CPU /内存/请求数量。搬运一下官方文档作为示意:
19.png

按照这个计费模型,将 concurrency 设置为合适的数值(起码不是1),让一个容器实例可以同时服务多个请求,分享 CPU 和内存,在费用上会更合适。另外上面的计费信息中可以看到,CPU /内存/请求数量都有免费配额,只有超过免费配额的使用才需要付费。免费配额会每月重置。

Cloud Run 对可计费时间的计算比较良心,只有在容器实例有请求在处理时才计算,从第一个请求开始到最后一个请求结束。而容器实例启动的时间和空闲的时间不计算在内,如下图所示:
20.png

#Cloud Run 分析
总结前面的功能介绍,我们可以看到,在 serverless 的常规特性和托管带来的运维便利之外,Cloud Run 的主要特性和卖点在于:

* 拥抱容器生态,将 Serverless 与容器结合,极大的扩展了 Serverless 的适用范围,对于 Serverless 市场是一个巨大的创新。对于习惯使用容器/微服务技术的客户,可以更好的迁移过来。
* 拥抱社区,基于开源的 Knative,拉拢社区和盟友,通过 Knative 实现 Serverless 的标准化和平台化,解决了 Serverless 市场碎片化的问题。
* 极佳的可迁移性,为客户提供了没有供应商锁定风险的解决方案。理论上客户可以根据实际需要选择完全托管的 Cloud Run 或 Cloud Run on GKE,或者开源版本的 Knative,以及其他基于 Knative 的托管平台,。
* 拥抱云原生技术栈,结合使用 Service Mesh 技术和安全容器技术,配合容器/kubernetes,用 Cloud Native 技术栈打通了从底层到上层应用的通道。

总结说,Cloud Run 是 Google Cloud 在 Serverless 领域的全新尝试,具有创新的产品思路,未来的发展值得关注和借鉴。
#参考资料
Cloud Run 刚刚发布才一个多月,目前能找到的资料不多,基本都是 Google Cloud 放出来的新闻稿/博客和官方文档,还有 Cloud Next 大会上的介绍演讲及 PPT。第三方的介绍文章非常的少,因此在调研和整理资料时不得不大量引用来自 Cloud Run 官方渠道的资料和图片。

* Cloud Run官网
* Cloud Run Overview:不到2分钟的介绍视频,官方宣传片
* Differences between Cloud Run and Cloud Run on GKE:官方视频,5分钟长度,展示 cloud run 和 Cloud Run on GKE 之间的相同点和不同点。
* Google Cloud Next’ 19 大会上和 Serverless 相关的演讲:主要信息还是来自 Next’ 19 的演讲,在这个页面中选择 “Serverless” 会列出本次大会和 Serverless 相关的演讲,大概十余个,视频可以回放,也提供PPT下载。(本文的大部分的信息和图片来自这些演讲内容),数量比较多就不一一列举了。

原文链接:Google Cloud Run详细介绍(作者:敖小剑)

在谷歌,女性力量正随 Kubernetes 一同成长

samzhang 发表了文章 • 0 个评论 • 356 次浏览 • 2019-04-23 10:38 • 来自相关话题

【编者的话】在科技公司中,技术部门通常以男性为主导。但如今,女性的力量同样不容忽视。今天的文章介绍了几位身居谷歌高层的女性,这也让我们对于女性技术人员有了一个新的认识。 
众所周知,计算行业中的信息技术部门往往存在严重的男性倾向,领导 ...查看全部
【编者的话】在科技公司中,技术部门通常以男性为主导。但如今,女性的力量同样不容忽视。今天的文章介绍了几位身居谷歌高层的女性,这也让我们对于女性技术人员有了一个新的认识。


众所周知,计算行业中的信息技术部门往往存在严重的男性倾向,领导团队中的女性数量则非常有限。然而,作为计算软件领域的一大突破性成果,Kubernetes 正在为寻求发展空间的女性软件工程师和女性项目经理提供肥沃的发展土壤。


在计算机领域,Kubernetes 已经掀起一场行业革命。它管理下的虚拟容器系统正迅速成长为最流行且高效的云应用运行方式。谷歌公司将 Kubernetes 项目捐赠给 Linux 基金会, 并随后创建了云原生计算基金会(简称 CNCF)。目前, Kubernetes 项目由云原生基金会负责运营,并凭借着开源项目这一定位吸引到整个数字社区的广泛支持。


尽管谷歌不再对 Kubernetes 项目拥有所有权,但却仍在积极参与贡献者社区的管理,旨在借此推动 Kubernetes 与 CNCF 的持续发展。虽然男性在 Kubernetes CNCF 社区中确实占据着更高比例,但其中不少最高级别也最为重要的谷歌参与者却身为女性。


我最近有幸与这些女性大牛进行了面对面交流,听她们讲述自己加入谷歌公司的历程,Kubernetes 为何吸引到她们的参与,以及在世界上最强大的公司之一扮演职业女性角色的心得体会。
##Chen Goldberg
chen-sa-2-150x150.png


Chen Goldberg 是 Goolge Cloud 高级工程总监,并管理着一支拥有几百名成员的团队。Goldberg 并不是计算机科班出身;在加入私有企业之前,她曾参与以色列国防部的信息技术工作。


“我喜欢解决实际问题的感觉,这让我感到非常兴奋,” Goldberg 说。“我认为这种多样化的背景使我能够对我们正在做的事情、以及我们正在努力成就的事物提供一个良好的视角”。
##Dawn Chen
dawnchengoogle-150x150.jpg


Dawn Chen 身为 Google Cloud 高级软件工程师,而且从起步阶段就一直在 Kubernetes 社区中拥有重要地位。从休斯敦大学获得计算机科学硕士学位后,Chen 在 GRIC Communications 工作了一年,随后以软件工程师的身份在赛门铁克公司工作了六年。2007 年,Chen 加入谷歌,她是 Borg 开发团队中不可或缺的一员——顺带一提,Borg 正是 Kubernetes 项目的前身。


Chen 在谷歌拥有超过 10 年的一线工作经验。“自从加入谷歌那天,我认为我已经以某种方式参与了 Kubernetes,也由此接触到开源与云基础设施领域,” Chen 回忆道。“当我最初加入 Borg 项目时,当时大家还在研究公用计算,也就是今天云计算的前身。”
##Sarah Novotny
novotnylinkedin-300x300.jpeg


Sarah Novotny 是 Google Cloud 的开源战略负责人,也是 Linux 基金会的董事会成员。在进入谷歌之前,Novotny 已经拥有很多头衔,并在几家公司担任过高管职位。


在 1990 年代后期,她在亚马逊公司担任系统工程师。她也曾经供职于游戏行业,担当 O’Reilly Media 的节目主持,在 NGINX 公司担任开发者关系负责人。直到 2015 年,当她正式加入谷歌开源部门时,正好赶上 Kubernetes 项目的全面腾飞。


回忆起她参与 Kubernetes 主题会议的点点滴滴时,她表示,“入职谷歌后的第二周,我就参加了第一届 KubeCon 大会。我特别关注项目的治理与整体健康状态。当时我们谷歌团队中有三名成员被调派参与 Kubernetes 生态系统,包括管理贡献者体验与提供治理建议,外加负责 Knative 与 Istio 相关的其他工作。”
##社区焦点


这些女性是 Kubernetes 生态中的有力推动者兼意见领袖。容器技术之所以能够不断得到开发者们的支持,无疑要归功于她们的卓越贡献。




Chen、Novotny 和 Goldberg 在采访当中无法抑制她们对于 Kubernetes 平台的兴奋之情。容器技术承诺给 IT 这个已经节奏飞快的行业带来更上一层楼的机遇。而从这些技术专家这里,我们反复听到的一大共识,正是对社区价值以及开源与云原生世界多样性的强调。


Goldberg 评论称, Kubernetes 项目非常特别,因为它有可能帮助到来自许多不同领域的人。“我们做的不是开源玩具,” 她说,“我们的项目是对人们真正有所帮助的东西,我们能够交付价值。 Kubernetes 团队面临的一大挑战在于,大家需要构建成果并将其集成到其他系统当中。通过我们对于 Kubernetes 的规划思路以及对生态系统及周边环境的投资,我们得以真正帮助众多团队与合作伙伴实现创新。”


Novotny 回应了这些想法。她强调称,“我们不仅要在代码方面投资,还应关注社区,治理以及人际往来。这一切,都是为了帮助项目的最终用户获得理想的投入或影响力回报,或者支持那些希望围绕 Kuberentes 项目建立业务的人们。”


尽管 Chen 在谷歌工作的时间比 Glodberg 和 Novotny 的总和还长,但她仍然保持着积极的工作热情。“我希望人们,无论在世界的任何地方,都能够享用到我的业务成果,” 她说。


这些女性当然很清楚技术领域中的性别差异问题,她们也都希望在自己力所能及的范围内为女性提供更多支持。尽管已然“位高权重”,Novotny 说,但她仍能感受到自己的男性同事们往往升得更高、也升得更快。


“职场对于女性确实不太友好,” Novotny 说。“女性也经常会评估自己的工作内容,而非关注自己所拥有的潜力。另外,虽然问题的核心并不能简单归结于判断,但过去 20 多年以来,这些判断确实拖累了女性的职业发展轨迹。”


Chen 希望赋予她的继任者权力,并以身作则。她是第一位拥有 “发布沙皇”头衔的女性 ——现在被称为 Kubernetes 发布经理,负责监督版本面向开源社区的发布工作。


“我个人认为我们需要更多的行业榜样,” Chen 说。“我们当然也需要改变文化。如果我们想要激励更多的女性、更多的年轻女孩进入科学和计算机科学,我们必须进行一场文化层面的变革。”


Goldberg 回忆起她在刚开始时受到行业榜样指导的经历,她现在希望能够回馈自己当时得到的帮助。“我会说,你必须付出代价,” 她说。当然,Goldberg 将这一切与她的工作联系在一起,这种态度也体现在她对团队成员们的具体管理方式上。


“我们都知道我们想做什么,而且我们都知道我们要如何做到。我们互相尊重,为我们客户的成功而欢呼,我们渴望他们达成目标,因为这是我们的责任,” 她说。也正如她做出的简短总结:“这样确实行得通。”

原文链接:At Google, women power the rise of Kubernetes(翻译:Sam)

谷歌发布Kubeflow 0.1版本,基于Kubernetes的机器学习工具包

YiGagyeong 发表了文章 • 0 个评论 • 1941 次浏览 • 2018-05-05 19:53 • 来自相关话题

【编者的话】Google 发布 Kubeflow 开源工具,旨在让数据科学家充分利用在 Kubernetes 集群上运行机器学习任务的优势。 自从 Google 发布开源容器编排工具——Kubernetes 以来,我们已经见证了其以各 ...查看全部
【编者的话】Google 发布 Kubeflow 开源工具,旨在让数据科学家充分利用在 Kubernetes 集群上运行机器学习任务的优势。

自从 Google 发布开源容器编排工具——Kubernetes 以来,我们已经见证了其以各种方式遍地开花的景象。随着 Kubernetes 越来越受欢迎,许多辅助项目也已经发展起来。现在,Google 发布了Kubeflow 开源工具 0.1 版本,该工具旨在将机器学习带入 Kubernetes 容器的世界。

虽然 Google 早已将 Kubernetes 迁移入 Cloud Native Computing Foundation ,但仍在积极参与该项目,发布 Kubeflow 就是很好的证明。该项目最初只是在去年底奥斯汀举办的 Kubecon 上宣布,但取得了不错反响。

在 Google 运营 Kubeflow 的 David Aronchick,加入Kubeflow之前,已经带领了 Kubernetes 团队两年半的时间。 他表示,该项目背后的想法是让数据科学家充分利用在 Kubernetes 集群上运行机器学习任务的优势。Kubeflow 可以让机器学习团队将现有任务轻松放到集群中运行,而无需作出太多改变。

随着今天的 0.1 版本的发布,该项目将开始推进,并将通过博客公布里程碑,将稳定性提高到一个新的水平,同时还会增加大量社区一直呼吁的新功能。其中包括为 Jupyter Hub 提供用于机器学习任务的协作和交互式训练以、Tensorflow 训练及托管支持等。

Aronchick 强调说,作为一个开源项目,你可以贡献任何你喜欢的工具,而不仅仅限于 Tensorflow,尽管早期的版本确实包含了对 Google 机器学习工具的支持。随着项目进一步发展,预计会有更多额外的工具支持。

在项目最初宣布后的 4 个月内,社区发展迅速,有 70 多个贡献者,20 多个捐助组织以及 15 个 repositoriy 中的 700 多个提交。可以期待一下,可能今年夏天的某个时候就会发布 0.2 版本。
# Kubeflow 0.1 简介
Kubeflow 0.1 提供了一套最精简的软件开发包,用于开发,训练和部署 ML。只需几个命令,就可以获得:

  • Jupyter Hub:用于机器学习任务的协作和交互式训练
  • TensorFlow 训练控制器:支持原生的分布式训练
  • TensorFlow 服务:用于服务托管
  • Argo:工作流
  • SeldonCore:用于复杂推断及非 TF 模型
  • Ambassador:反向代理
  • Wiring:可以使 Kubeflow 在任意 Kubernetes 上运行

下面是入门示例:
# 为 kubeflow 开发环境创建 namespace
NAMESPACE=kubeflow
kubectl create namespace ${NAMESPACE}
VERSION=v0.1.3

# #初始化 ksonnet 应用,设置 namespace 为其默认环境变量
APP_NAME=my-kubeflow
ks init ${APP_NAME}
cd ${APP_NAME}
ks env set default --namespace ${NAMESPACE}

# #安装 Kubeflow 组件
ks registry add kubeflow github.com/kubeflow/kubeflow/tree/${VERSION}/kubeflow
ks pkg install kubeflow/core@${VERSION}
ks pkg install kubeflow/tf-serving@${VERSION}
ks pkg install kubeflow/tf-job@${VERSION}

# #为核心组件创建模板
ks generate kubeflow-core kubeflow-core

# #部署 Kubeflow
ks apply default -c kubeflow-core

至此,JupyterHub 已部署,我们现在可以使用 Jupyter 开始开发模型。一旦有了 python 代码来构建模型,我们就可以构建一个 Docker 镜像并使用 TFJob 运算符通过运行如下命令来训练模型:
ks generate tf-job my-tf-job --name=my-tf-job --image=gcr.io/my/image:latest
ks apply default -c my-tf-job


# #下面部署模型

ks generate tf-serving ${MODEL_COMPONENT} --name=${MODEL_NAME}
ks param set ${MODEL_COMPONENT} modelPath ${MODEL_PATH}
ks apply ${ENV} -c ${MODEL_COMPONENT}

只需要几个命令,数据科学家和软件工程师就可以创建更复杂的 ML 解决方案,并专注于他们最擅长的事情:解决核心业务问题。

原文链接:Google Kubeflow, machine learning for Kubernetes, begins to take shapeAnnouncing Kubeflow 0.1(翻译:李加庆

谷歌正式发布其容器优化型操作系统

李颖杰 发表了文章 • 0 个评论 • 4291 次浏览 • 2017-04-05 18:57 • 来自相关话题

立足Google Cloud Platform实现容器技术“开箱即用”能力。 【上海站|3天烧脑式Spring Cloud训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、H ...查看全部
立足Google Cloud Platform实现容器技术“开箱即用”能力。

【上海站|3天烧脑式Spring Cloud训练营】培训内容包括:DevOps、微服务、Spring Cloud、Eureka、Ribbon、Feign、Hystrix、Zuul、Spring Cloud Config、Spring Cloud Sleuth等。

相信任何一位关注IT动态的朋友都已经意识到,容器技术已然成为业界增长最快的成果之一。我们对于这一趋势感到振奋,并不断强化Google Cloud Platform(简称GCP)以确保其能够成为理想的容器运行平台。

目前市面上存在着众多出色的容器托管型操作系统,我们也对客户拥有如此丰富的方案选项感到高兴。不过仍有不少客户表示,尽管他们已经拥有自己的虚拟机方案,但其同样希望选择谷歌所使用的镜像,从而确保其能够拥有与各项谷歌服务相同的优化收益。

去年春季,我们发布了容器优化型操作系统(即Container-Optimized OS,此前曾被称为Container-VM镜像)的beta测试版本,其专门进行了优化以在GCP之上运行各类容器。我们利用容器优化型操作系统运行谷歌内部的多种产品服务(例如Google Cloud SQL以及Google Container Engine等等)。

今天,我们宣布容器优化型操作系统已经正式推出。这意味着如果您身为Compute Engine服务的用户,则可立即利用这套操作系统创建虚拟机实例(请参阅本文文末的示例),从而实现Docker容器“开箱即用”。

容器优化型操作系统代表着我们过去十年中以规模化方式运行容器时总结出的全部最佳实践:

* 受控构建/测试/发布周期:容器优化型操作系统的核心优势在于能够确保用户全面控制构建、测试与发布周期,并为GCP客户(包括谷歌自有服务)提供强化型内核功能与托管更新。发布可通过三种不同渠道实现(包括开发、beta与稳定版本),其各自拥有不同的早期访问与稳定性级别,可进一步提升迭代与发布周期的推进速度。
* 容器就绪型设计:容器优化型操作系统预安装有Docker容器运行时,同时支持Kubernetes以实现面向容器的超大规模部署与管理能力(即容器编排)。
* 在设计中充分考虑安全性需求:容器优化型操作系统在设计中充分考虑安全性需求。其最小化只读root文件系统能够有效削减攻击面,同时包含文件系统完整性检查机制。我们还在其中添加了锁定防火墙与审计日志记录功能。
* 事务更新:容器优化型操作系统采用一套主动/被动root分区机制,这意味着用户可以通过原子事务处理方式对包括内核在内的操作系统镜像进行整体更新,从而显著降低更新失败率。用户亦可以选择自动更新机制。

用户能够在Compute Engine之上通过容器优化型操作系统轻松实现虚拟机实例创建。大家可选择使用Google Cloud控制台GUI或者gcloud命令行工具,具体方法如下:
gcloud compute instances create my-cos-instance \
--image-family cos-stable \
--image-project cos-cloud

在实例创建完成之后,大家即可马上运行自己的容器。举例来说,您可以在刚刚创建完成的实例中通过以下命令运行一套Nginx容器:
gcloud compute ssh my-cos-instance -- "sudo docker run -p 80:80 nginx"

大家亦可通过以下命令在实例中进行登录:
gcloud compute ssh my_cos_instance --project my_project --zone us-east1-d 

再来看另一个简单示例,即利用Container Engine(采用容器优化型操作系统)以运行您的容器。此示例来自谷歌Container Engine快速入门页面。
gcloud container clusters create example-cluster
kubectl run hello-node --image=gcr.io/google-samples/node-hello:1.0 \
--port=8080
kubectl expose deployment hello-node --type="LoadBalancer"
kubectl get service hello-node
curl 104.196.176.115:8080

我们邀请您设置自己的容器优化型操作系统实例并在其上运行您的各类容器。感兴趣的朋友可以点击此处查看容器优化型操作系统的说明文档,亦可点击此处在Chromium OS库中找到其源代码。我们也期待着了解您对于容器优化型操作系统的使用感受反馈;大家可以在StackOverflow上配合google-container-os标签向我们提出问题。

原文链接:Container-Optimized OS from Google is generally available

2.12 K8S Meetup 回顾|Google·陈智峰《谷歌大脑近期工作进展介绍》

caicloud 发表了文章 • 0 个评论 • 1316 次浏览 • 2017-02-28 10:46 • 来自相关话题

2月12日,才云市场团队奔赴上海,在阿拉小优总部1楼举办了“Kubernetes Meetup 中国 2017”第一场——上海站。继 2016 年 Kubernetes Meetup 四城联动之后,才云 2017 年的 Meetup 阵容更加强大,布道城市范围 ...查看全部
2月12日,才云市场团队奔赴上海,在阿拉小优总部1楼举办了“Kubernetes Meetup 中国 2017”第一场——上海站。继 2016 年 Kubernetes Meetup 四城联动之后,才云 2017 年的 Meetup 阵容更加强大,布道城市范围更广,为更多 Kubernetes 爱好者带去技术分享。

嘉宾精彩演讲回顾

陈智峰《谷歌大脑近期工作进展介绍》
陈智峰博士现为谷歌大脑资深工程师,拥有 12 年谷歌工作经验,自 2014 年以来,他参与设计并实现了被广泛应用于重要谷歌产品的新一代谷歌大脑机器学习开源系统 TensorFlow,并成功将 TensorFlow 用于谷歌翻译之中,巨幅提高了谷歌翻译的准确率。谷歌大脑是专注于深度学习的人工智能的研究开发团队。
陈智峰此次的演讲通过介绍过去一年中谷歌大脑在基础研究、系统开发和产品应用各方面的进展,与参会者探讨了人工智能发展的前景和可能的方向。

以下是 Google 陈智峰带来的《谷歌大脑近期工作进展介绍》演讲内容:
大家好,很高兴跟大家分享谷歌大脑在过去一年的进展以及我的一些工作心得。
2014 年,Jeff Dean 带领开发 TensorFlow(以下简写成“TF”),当时希望 TF 能够支持更多容器,运用到更多领域,供更多开发研究人员使用。
2015 年下半年,谷歌开源 TF,整个团队觉得这个项目做得不错,于是在上面添加了更多性能,比如自动 differentiation,control flow 等,另外还增加了很多 operation。
最初,我们只是增加乘法、加法等一些简单的数据运算。去年,我们又添加了一些相对复杂的算法,很多矩行分解的支持,完善文档,增加教材式的文档。


幻灯片03.jpg


过去一年,我们也做了很多支持更多平台的工作。到目前为止,TF 在 Github 上已经有 500 多个贡献者,绝大多数都是 Google 以外的人,现在有超过 1 万多的 commits,据统计下载量超过一百万,在学校也很受欢迎。如果你去 Github 上找,你会发现很多以 TF 为基础的 repository。

幻灯片04.jpg


还有就是发布的一些基础架构软件,以及现成的模型,这些基本上都放在 models 下面(如下图所示),任何人都可以下载文件,做一些图像处理工作,以及自然语言处理,文本语法分析。

幻灯片06.jpg


TF 主要目的是把深度学习的好处带给大家,让大家都享受深度学习带来的好处。TF 不光是在单机上跑起来,我们也增加了对 mobile device 的支持,大概下半年的时候,iOS 上也可以跑 TF。大概 4 月份的时候,我们会发布分布式版本,所以不仅可以在单机上跑 TF,也可以在 AWS 上运行起来。我们还做了一些跟开源生态圈集成的事情,例如支持像 HDFS、Spark、Windows 以及其它的操作系统。

幻灯片07.jpg


目前,TF 也可以通过不同的前端语言进行使用:Python,Java 等等。

幻灯片08.jpg


TF 1.0 里面增加了稳定性和实用性,还会增加一个叫 XLA 的部分,可以把代码直接编译成机器码。

幻灯片09.jpg


但是,有人也会疑惑,做这些东西会对现实有什么影响吗?Alpha Go 再厉害,它也只是个游戏。同时,我们团队的成员也会疑惑 TF 到底会给现实世界带来什么影响?
那么接下来我们就来说一下 TF 带来的现实影响,同时也给大家介绍一下 TF 的学习架构。

幻灯片11.jpg



幻灯片10.jpg



说到 TF 的用途,最热门就是图像识别方向。
2011 年,机器进行图像识别的错误率为 26%,人工识别的错误率为 5%。到 2016 年,图片识别的错误率降低到了 3%。

幻灯片13.jpg


再讲一个 TF 运用在医疗方向的例子。
目前全球有 4 亿患者患糖尿病造成的视网膜病变,诊断过程很长。在印度、非洲等一些医疗设施相对不那么先进的地方,病症诊断专业度不够。谷歌大脑有个团队,增加视网膜图片扫描工具,专门用于扫描照片。让人高兴的是,现在已经可以通过图像识别技术来对病人进行诊断,而且准确率比医务人员能达到的还要高。

幻灯片14.jpg


再回过头来说,TF 对现实世界的具体影响。
比如,斯坦福的另外一个研究,基本上是用同样的方法来诊断皮肤癌。首先在医院拍一张照片,然后通过图像识别,来诊断是否皮肤癌。
TF 对现实世界的影响还表现在自然语言识别领域。
微软在 11 月的时候宣布,在类似语音识别领域,机器做得比人好。10 月份的时候,Google 宣布,他们能大幅提高机器翻译效果。

幻灯片18.jpg


这张图就是神经机器翻译的图。现在输入一个英文的句子,假设句子中有四个单词,然后这个模型就可以对句子进行分析,句子中每个词表示一个向量,每个向量都会经过一个很复杂的数学模块,最后就可以得出四个项目,这四个项目通过计算延到右边这个大的模块里面,然后模块再翻译成中文,最后一个字一个字地输出成中文。右边图中每一个小盒子都代表了一个很复杂的数值计算,每个小盒子都有几百万的运算要求,产生一个词都需要上亿的运算。
早在 2014 年,就有很多学校在做类似研究。研究小组从头到尾写一个模型,这个模型难以描述,训练起来非常困难,且计算量大。就单单一个模型来说,代码其实很简单,但可能需要一个月的时间来进行训练,于是需要转到 TF 模型。
TF 的一个好处就是支持分布式,它可以有很多参数、计算机服务器,能够充分利用资源。相比用 C++,用 TensorFlow 代码量会少很多。

幻灯片19.jpg



幻灯片21.jpg


单个语种的翻译,预测是 2-3 周的时间,每种语言大约超过 1 亿个模型的训练。Google 内部要支持 100 多种语言,每种语言之间都要实现互相翻译。所以如果要实现所有模型,非常耗时间。一般来讲,Google 进行翻译,原理就是把不同语言先翻译成英语,再将这些语言翻译成其它语言。所以真实翻译效果会差很多,而且成本也高。

幻灯片22.jpg


所以有人就想了一个项目,叫做 Multilingual models。

幻灯片23.jpg


Multilingual models 的思路非常简单,用上述的数学模型即可。但是当你训练这个模型的时候,要给它看不同语言的翻译,英文到日文的,英文到韩文的,同时也要给它看日文到英文的,韩文到英文的。而这个时候,你的模型是不会增大的,它只是阅读了不同语言的语料。

幻灯片24.jpg


训练这个模型的时候,一开始,我们只是抱着试一试的心态。但是在生产应用中我们惊喜地发现,这个模型不光能翻译日文到英文,还可以直接翻译韩文到日文,以及日文到韩文!之前我们完全没有想到会有这样的翻译效果。
在其它应用场景里面,也会有一些类似的现象。

幻灯片25.jpg


回到刚才,Google 在做翻译的时候,会把不同语言翻译成英文,再把英文翻译成你想要的语言,这样的话,对于所有自然语言来讲,英文就是表达的中介语言。
上图讲述的就是,表述同一个意思的不同语言的句子,map 到一个二维空间上,然后发现很多语言都有共性远远大于它们之间存在的差异性。
比如说同样一句话,不管是日语还是韩语,它表达的意思都在上图 b 这个圈里,这是一个比较有趣的现象。
通过“机器训练”这个模型,聚集到一起,达到提高翻译水平的效果。

幻灯片26.jpg


然后 Google Brain 不光是做 TF,内部还要很大一部分人在做很前沿的研究。
其实不管是图像识别还是 sequence modeling,其实它的核心概念都可以追溯到十几二十年前。
图像识别的核心可以追溯到 1999 年乃至更之前,机器翻译则可以追溯到 1997 年的 LSTM 甚至更早,一直到 GPU 出现,令这些模型计算更快,模型的效果才显现出来。


幻灯片28.jpg


当然,现在的技术不能解决所有的问题,有些思路还在被探索开发。
刚才讲的谷歌翻译模型,它们对于人的大脑来说是十分小的。Google 的翻译大概是 2 亿 5 千万个参数。但是人大概有 100 倍乃至 1000 倍的神经元。所以 Google Brain 认为,如果你给它更大的模型,更多的数据,那么效果肯定会更好。当然,一种 idea 如何集成为一个更大的模型其实还是受很多信息的限制的。


幻灯片29.jpg


我们可以有很多很多专家,比如说 2000 个专家,每个专家的特长领域都不同,如果我有问题的话,我要先去找哪个专家呢?我会一步一步来解决我的问题。然后具体呢,大家可以看一下,是一个highlight point。

幻灯片30.jpg


比如我刚才讲的谷歌翻译的模型,现在发布的版本大概是 2 亿 5 千万个参数。比如里面有 2000 个 Export,这个模型翻译的效果比我们现在发布的模型要好很多。虽然现在你可以建一个 10 倍大(乃至 100 倍)的模型,当然也会有很多问题,这只是一个设想,就是说如果机器越多,模型越多,那么效果就会越逼近人的智能。
大家有兴趣可以看下这些论文,不光是 Google Brain,很多实验室也在往这个方向努力。

幻灯片31.jpg


另外一个比较有趣的现象就是:learning to learn。如果你看过去几年里深度学习的“套路”,比如你要解决一个人工智能问题,然后用深度学习的方法,必须要有三个要素:在这个领域有专长的专家;有大量的数据;以及很强的计算能力。对于很多公司来讲,数据和计算能力可以购买。但是由于这个领域比较新,所以深度学习领域专家是比较少的。
那么遇到的问题就是,能否找到专家的替代,或者说减少对这些专家的依赖?

幻灯片33.jpg


Google 有两个研究人员,他们写了一篇论文,基本就是说,你构造一个机器学习模型,就像是大家平常写一个程序一样,类似于某个机器在玩游戏的过程,终极目标就是:解决遇到的问题。
比如下一盘棋,那么目标就是赢这盘棋。但是策略是什么呢?这时候,你可以随机生成很多很多这样的程序,这些程序里面,有的运行得好,有的运行得不好,你可以给不同的程序打分,对高分程序进行强化学习,指导搜索过程,找到更好的模型。

幻灯片34.jpg


这个说的就是,参数越多,表达能力就越强。
图中最后四行是程序搜索出来的模型,这个模型在这个测试中,错误率可以降低到 3.84%,去年最低的结果是 3.74%。
所以将来大家遇到问题,比如说你在下棋,你想赢,你就搜索一个方案,这些方案要比你手动去设置模型要有效。整个机器学习领域非常快,几年后这个方向或许就会有大的突破。
大家会觉得图像识别模型已经有了,为什么还要去生成这样的一个模型?你不光可以通过程序生成这样一个图像识别模型。
比如你公司里有很多数据库,你可以 想象能不能产生一个meta program,这个 meta program 通过机器学习的方法产生 database 的 program。

幻灯片35.jpg


深度学习非常依赖计算能力,深度学习模型涉及到很多数值运算。它有个比较大的特点:对述数值运算监控能力很高。核爆炸模拟的时候,要精确到 32 位甚至更高;但是在机器学习模型里面,你会发现其实不需要精确到 32 位;16 位甚至 8 位就可以解决问题。
去年,谷歌内部在做 TPU 芯片,它就是 8 位或者 16 位的,而且价钱要比 CPU 或者 GPU 要便宜很多,低耗能,结构上也要简单很多,速度也有提高。现在硅谷也在做这方面的事情,所以我觉得这两年这方面将会有很大的突破。

幻灯片38.jpg


最后给大家总结一下:大家可以感受到,这两年人工智能(特别是深度学习)的发展非常快,在各个应用领域都表现非凡,相信未来还有更多领域会用到它,期待它的表现。

下载演讲嘉宾 PPT 请关注 Caicloud!或者点击https://mp.weixin.qq.com/s?__biz=MzIzMzExNDQ3MA==&mid=2650093191&idx=1&sn=93960069acfc348c8ee1b2e06f4c5fcc&chksm=f08b088ec7fc81984eff84b1590cdfbfc26361f60e32f449d00dc4528538d3111c4802d62cd9#rd点击“阅读原文”进行下载!

关于云原生的一些思考

kurtzhong 发表了文章 • 0 个评论 • 2463 次浏览 • 2017-01-07 20:00 • 来自相关话题

# 第一部分:定义 在Craig和我开始打造Heptio的时候,我们做了不少关于我们行业发展方向的思考。我们在Google里呆了很久的时间(两个人加起来的日子有16年了),对于Google构建和管理系统的方式有很深入的理解。但是很可能你没有在Goo ...查看全部
# 第一部分:定义
在Craig和我开始打造Heptio的时候,我们做了不少关于我们行业发展方向的思考。我们在Google里呆了很久的时间(两个人加起来的日子有16年了),对于Google构建和管理系统的方式有很深入的理解。但是很可能你没有在Google任职的经历。那么对于一个普通的公司、开发或者运维人员,应该如何理解并应用这些不断演变的新概念呢?

云原生意味着什么,并没有一个固定或死板的定义。实际上,还有一些与之重叠的概念和思想。但在它云原生的核心,是对团队、文化和技术的精心组织,利用自动化和架构的力量来掌控复杂度,突破速度的束缚。在这种模式下的运作,不但是一种技术的扩张方式,更是一种人力的扩张方式。

很重要的一点是,不一定要在云环境中运行才能叫“云原生”。这其中的技术可以在恰当的时候叠加地采用,并且帮助向云过渡的过程变得顺畅。

云原生的真正价值所在远不止与之密切相关的一篮子技术。要真正的理解行业的动向,我们需要思考我们能从哪些地方用什么途径让公司、团队和个人更加成功。

目前,这些技术已经被那些以技术为中心且眼光高远的公司验证,它们为此做出了努力并投入了大量的资源。想想Google、Netflix或者Facebook。同样也有规模更小,灵活性更高的公司实现了价值。然而,除在这些技术的早期采用者之外,这套哲学理念却少见有利用。 当把目光投射到整个IT领域,我们仍然在这条旅程起点不远的地方。

随着早期的经验不断被验证和分享,如今都有哪些涌现的主题呢?

* 更有效率和更开心的团队。云原生的工具让大的问题切分成小的问题,便于分工让更专注和更敏捷的团队来解决。

* 减少枯燥重复的劳动,通过将很多人工操作自动化,也避免了因为人工操作引发的运维上痛苦和停机时间。这一般是通过自愈合、自管理基础设施来达成。系统被期望解决更多的事情。

* 更可靠的基础设施和应用。构建用来处理一些可预见的故障的自动化流程,通常对不可预见的事件和故障是更好的失效模式。举个例子,如果部署开发的应用只需要一个命令或者点击一下按钮,那在灾难恢复的场景下(通过手动或自动的方式)进行自动化部署也更加的容易。

* 可审计,可察视,可调试。复杂的系统会变的非常晦涩难懂。云原生使用的工具,通常能让人对应用内部发生的事情有清楚的了解。

* 深度的安全性。如今很多IT系统的外壳都很坚固,但内在都很脆弱。现代的系统默认情况下应该有安全防护,采取最小信任(least trust)策略。云原生让应用开发者能在应用安全方面扮演重要的角色。

* 资源的更高效的利用。应用和服务的自动化式的、类云环境的部署及管理方式,开启了自动化的算法化机遇。比如,一个集群调度器/编排器可以自动完成工作负载的安放,而不需要运维团队用类似excel的方式进行管理。

在Heptio,我们特别兴奋我们能帮助更广阔的IT领域得到云原生的恩惠。在接下来的部分,我们将讨论与已有的系统进行整合,DevOps,容器和编排,微服务和安全。
# 第二部分:实践
与任何正在经历变革的领域一样,云原生世界中有繁杂的概念。上一个部分列举的概念,不是每人个人都清楚应该如何恰当地利用。同时,很多关键的项目,要么太庞大,要么太重要,不适合重头重写。因此,我们觉得最好把这些新的结构用在新的项目或者老项目的新部件中。在系统老的部件得到了改善后,然后再花时间合理地学习并采用其他新技术。寻找把新的特性或者系统分解成微服务的方式。

没有硬性的规则。每一个机构都是不同的。软件开发的实践必须要根据身边的团队和项目来做出调整。理想不同于现实。有的项目经得起实验折腾,但是很多非常重要的项目应该采取更加谨慎的态度。还有一些场景是介于两者之间的,一些技术即使已经被验证过,但仍需要规范化并且经过大规模的测试,之后才能应用到核心系统上。

云原生的定义中离不开的更好的工具和系统。没有这些工具链,每一个新部署在生产环境的服务都会有很高的运维成本。监控,跟踪,配置等等都增加了一个处理的负担。这个额外的开销是对微服务大小的切分应该合理的主要原因之一。开发团队的速率和在生产环境中运行更多(服务)的成本,这两者的利弊需要权衡。类似的,新的技术和语言引入,尽管可能新鲜刺激,也必须仔细考虑其风险和代价。关于这个话题,Charity Majors有一个非常好的演讲

要降低构建和运行新服务中的运维成本,自动化是关键。像Kubernetes、容器、CI/CD、监控等等这样的系统,都有一个相同的重要目标 - 让应用开发和运维团队的效率更高行动更快,让打造的产品更可靠。

要达到云原生的愿景,最好使用新一代的工具和系统,而不是传统的配置管理工具,因为它们有助于分解问题然后分工给不同的团队处理。通常来讲,新的工具通常能让独立的开发和运维团队拥有自主权,然后通过自服务(self service IT)提高生产力
# 第三部分:DevOps
不妨将DevOps看成一种文化的转型,开发者现在需要关心他们的应用是怎样在生产环境中运行的。而运维也对应用的运作机制有了认识并且授予了知情权,从而可以在帮助打造可靠应用方面发挥重要作用。增进这些团队之间的理解和建立同理心是关键。

但是可以更进一步。如果我们重新思考我们的应用的构建过程和运维团队的结构组成,我们能进一步加深这种关系。

Google没有传统意义的运维团队。相反,Google定义了一种新的叫做SRE(Site Reliability Engineer,网站可靠性工程师)的工程师。他们是技能扎实的工程师(报酬同其他的工程师处同一个水平)他们不但随时保持在线,同时得到授权并被赋予通过自动化来在推动应用变得更加稳固方面扮演至关重要角色的重望。

当在凌晨两点报警触发的时候,任何响应该报警的人都会做同一件事情 - 努力弄清出了什么问题,好早点回去继续睡觉。真正定义一个SRE的地方是第二天早上10点钟发生的事情。运维组的人是否只会抱怨,还是会和开发团队一起协作保证同样的报警不会再次出现?在让应用变得尽可能稳定可靠方面,SRE和开发团队有一样追求。结合不追责的的事后剖析,可以保持项目的健康,不让技术债务堆积。

SRE在Google是最被看重的人群之一。在实际中,很多项目在没有SRE参与启动的时候,开发团队肩负了让他们的产品在生产环境中运行起来的期望。引入SRE团队的流程,通常需要开发团队向SRE团队证明他们的产品已经准备到位。开发团队需要已经做好了所有的准备工作,包括设置好监控和报警,报警的应对策略和发布流程。开发团队要能显示出报警的情况已经达到了最少的程度,并且绝大多数的问题已经被自动化了。

随着运维的角色参与程度更深,与特定的应用相关度更高,让一个运维团队掌控整个运维栈变得不合理。这引出运维规范(Operations Specialization)的问题。从某种意义来说这是一种
“反DevOps(anti-devops)”的做法。让我们来自下而上的看:

* 硬件运维。这一层很显然可以分离出来。实际上,很容易把云IaaS看成是“硬件运营即服务(Hardware Ops as a Service)”。

* 操作系统运维。必须有人保证机器能够顺利启动,并且有一个好的内核。将这一部分从应用的依赖管理中分离出来也反映出了用来托管容器的操作系统发行版(CoreOS, Red Hat Project Atomic, Ubuntu Snappy, Rancher OS, VMWare Photon, Google Container Optimized OS)的最小化趋势。

* 集群运维。在容器化的世界中,一个计算的集群变成了一个逻辑上的基础设施平台。集群系统(Kubernetes)提供了一组原语能让很多传统的运维任务自服务化。

* 应用运维。每一个应用现在可以根据需要拥有一个专门的应用团队。若有必要,开发团队有能力并且应该担任起这个角色。这种运维团队应该更深入应用,因为他们不需要在其他的层次上专研太深。比如,在Google,AdWords的前端SRE团队会和AdWords Frontend的开发团队交流很多,超过他们与集群团队之间的交流。这能带来更好的成果。

很可能还有其他专业性的SRE团队的空间。例如,存储服务可能会划分成单独的服务,或者根据某种政策,可能有团队来负责验证所有团队使用的基础容器镜像。
# 第四部分:容器和集群
有很多人对于容器相关技术兴奋不已。了解为什么大家如此兴奋的的根本原因是有益处的。在我看来,有三个原因:

  1. 打包和移植性
  2. 效率
  3. 安全性

让我们依次地来看。

首先,容器提供了一种打包机制。这能让系统的构建从这部署流程中分离开来。另外,构建的成品和镜像比传统的方式如虚拟机移植性更好。最后,部署变得更加的原子化。传统的配置管理系统(Puppet,Chef,Salt,Ansible)很容易让系统处于一种配置不完整的、很难调试的状态。也很容易在机器中残留一些不易被发现的错误版本。

第二,容器更轻量化,使得资源利用率增加。这是当Google引入cgroups(容器底层的主要核心技术之一)时的一个主要原因。通过共享一个内核,并且允许更流体化的过量使用(fluid overcommit),容器更容易让系统资源每一部分都不浪费(“use every part of the cow”)。随着时间的推移,有望看到更加复杂的用来均衡单个主机上共存容器需求的方式,杜绝吵闹邻居问题。

最后,很多用户把容器看做是一个安全性界限。尽管容器可以比一个简单的Unix进程更安全,当把它们看做是一个硬的安全性边界的时候还是要注意。Linux命名空间提供的安全保证对于那些运行半信任工作量的“软”多租户环境来说合适,但对于那些运行充满敌意的工作量的硬多租户环境却不适用。

有从很多方面的努力来在模糊容器和虚拟机的界限。一些早期研究如unikernel很有意思,但是很多年内尚不能应用于生产。

要达到上述目标,容器尽管是一条简单的途径,但却不是必要的途径。例如,Netflix,传统以来一直运行一个非常现代化的技术栈,它们以类似使用容器的方式,来打包并使用虚拟机镜像。

尽管绝大多数围绕着容器的努力集中于在单个节点上管理软件,使之更加可靠和可预测,这个改革的下一步集中于集群(通常也被称作编排器)。给定一批节点然后把他们和自动化系统绑定起来,为开发和运维团队提供了一组逻辑基础设施的自服务

集群能帮助消除运维中枯燥乏味。有了容器集群我们让计算机来接管工作,决定负载应该由哪台机器来处理。集群也会默默的在硬件失效的时候修复问题,而不是需要去通知某人。

集群的第一个好处就是它启用了运维的规范(见第三部分)可以让应用运维作为一个单独的学科来努力。通过定义个以良好的集群接口,应用开发者们能集中于解决应用自身的一些问题。

集群的第二个好处是它让启动并管理更多的服务成为可能。从而允许使用能为开发团队高速率的架构(通过下一部分介绍的微服务)。
# 第五部分:微服务
微服务是一个已经存在很久的概念的一个新名称。基本上,它是一种将一个大的应用进行切分的方法,使得他们能独立地进行开发和管理。让我们看看此处相关的关键概念:

* 强大和清晰的接口。服务之间的紧耦合必须避免。配套了清晰文档和有版本管理的接口有助于强化这种协定,对于这些服务的消费者和生产者同时又都能保有一定的自由度。

* 独立的部署和管理。微服务应该能够单个更新,无需和其他的服务一起同步进行。同时,大家也都很希望能够轻松地回滚一个微服务的版本。这意味着部署的二进制文件必须在API上和任何数据格式方面保持向前和向后兼容。这可以作为检验运维和开发团队之间的合作和沟通程度的试金石。

* 由内打造的耐受性。微服务应该构建成为并经测试验证有独立的耐受性的。在消费的服务不可用或者异常的时候,那些消费一个服务的代码应该要努力保持正常工作并且做出合理响应。同样的,那些提供的服务应该对于未曾预料的负载和异常输入做好防护。

确定微服务的大小是一个很难做对的事情。我的意见是要避免选择小的过分的服务(pico-services),反之将服务按照自然的边界(编程语言,异步队列,伸缩的要求)进行切分,同时保持团队大小合理(例如:两个披萨团队)。

应用的架构应该能允许以一种切合实际并且自然的方式增长。与其以20个微服务开始,不如从2到3个开始,然后随着该领域复杂度再对服务进行拆分。经常对一个应用的架构的认识直到应用在处于开发阶段才会变得透彻。这也说明了很少有已经竣工完成的应用,他们都总是一个正在施工的工程。

微服务是一个新概念吗? 非也。这其实是另外一种类型的软件组件化(software componentization)。我们过去把代码切分成库。这只是把“链接器”从一个构建阶段的概念转变成了一个运行时的概念(实际上,Buoyant有一个有意思的项目叫做linkerd,其基于Twitter Finagle系统。)。这与多年前的SOA潮很相似,只是不见了各种样式的XML。数据库从另外一个角度看,一直以来几乎是一个微服务,因为它实现和部署的方式都满足上面列的点。

约束可以转变成生产力。 尽管,很容易让每一个团队各自决定在每一个微服务上使用什么语言或框架,但不妨考虑下规范化,定下几种语言或者框架。这么做有助于机构内部的知识技术交流积累,更好应对人员流动。但是,在必要时也要有打破政策的开放心态。这是比起PaaS的垂直式集成结构,这个世界中的一个关键优势,换句话说,约束应该是来自政策层面的,而不是来自技术能力层面(constraints should be a matter of policy rather than capability)。

尽管绝大多数人把微服务看做是实现一个大型应用的技术,服务光谱(services spectrum)中还有很多其他类型的服务:

  1. 服务作为实现细节。正如上面描述过的一样,这对于把一个大的应用团队切分成小的开发和运维团队很有用。

  1. 成果共享,实例私用(Shared Artifact, Private Instance)。在这种场景中,开发过程通过服务的很多实例间共享。有可能有一个开发团队和很多运维团队,或者很可能一个联合的运维团队,在共享专门的实例间工作。很多数据库属于这种类型,很多团队都在使用同一个MySQL安装的私有实例。

  1. 实例公用。这种场景下,机构中的一个团队为很多应用或者团队提供一个共享的服务。服务可能会将数据或者操作按照用户(多租户)进行分区,或者提供一个用途广泛的简单服务(如展示一个通用的品牌条HTML,提供机器学习模型等)。

  1. 大型服务(Big-S Service)。绝大多数的企业不会打造这种的服务,但是可能会使用他们。这是一个典型的“硬性”的多租户服务,用来构建来为大量的分散的客户提供服务。这种服务需要某种层次的记账和加固,通常在企业内是不必要的。SendGrid和Twilio属于这一类。

随着服务从一种实现细节变成一种企业内常见提供的基础实施,服务网络从一个每应用的概念变成了能跨越整个公司的概念。允许这种依赖是一个既有机遇也有忧患。
# 第六部分:安全
注:本文中没有覆盖到新出现的“云原生”中与安全相关方方面面。但同时,尽管我不是一个安全专家,安全却是我整个职业生涯都有在关注的事情。请把它当做是值得考虑的事项清单的一部分。

安全仍然是云原生领域中的一个大问题。以往的技术无法完美的应用,在起初云原生可能看起来在开倒车。但在这片无畏的领域,同时也充满了各种机遇。
## 容器镜像安全
有很多的工具可以帮助对容器镜像进行审计,以确保它们完整地包含了各种补丁。众多选择中,我没有什么很强个人偏好的。

真正的问题在于,在发现了一个有漏洞的镜像之后该怎么做呢?这一块市场尚未提供很好的解决方案。一旦有漏洞的镜像被检出,事情就从一个技术问题变成了一个程序/流程问题。你会想着去找出机构中哪些组件受到了影响,问题应该在容器镜像层级树的什么地方进行修补,以及用什么好办法来进行测试并且发布新的打好补丁的版本。

CD/CD(持续集成/持续部署)是应对良策中的重要内容,因为它可以快速自动地发布新镜像。其与编排系统的集成能让你找出哪些用户正在使用有漏洞的镜像。同时它也能让你验证生产环境上是否采用了已经修复好的版本。最后,部署系统的策略能帮助阻止那些使用有漏洞镜像的容器启动(在Kubernetes的中,这被称作准入(admission))。
## 微服务和网络安全
但即使集群上所有运行的软件都已经是修复过的,也并不能保证网络中有没有不受信任的活动。

在以动态调度、存时短暂为特征的容器世界中,传统的基于网络的安全工具无法发挥理想的效果。存时短暂的容器可能存活时间过短,以至于传统的扫描工具无法及时扫描到。又或者被扫描到了且扫描报告已经生成,奈何相关容器却已经不存在了。

在动态的编排器中,IP地址不再拥有长久的意味,且它们是可以被自动复用的。解决方案是将网络分析工具和编排器集成,让逻辑名称(结合其他元数据)可以和IP地址一并使用。这可能可以让报警更加容易处理一点。

很多网络技术都利用了封装技术来实现“一容器一IP”。这可能会给网络追踪和诊断工具带来问题。如果生产环境上部署了这样的网络系统,那这些工具必须要做出相应改进。幸运的是,VXLAN、VLAN中的很大一部分都都已经被标准化了,或者不采用封装或者虚拟化,以便这些系统都能利用这些支持工具。

然而,个人看法,最大的问题还是跟微服务相关的问题。当在生产环境中运行了很多服务的时候,很有必要确保某特定的服务只能被授权的客户端调用。另外,因为有了IP的重复使用,客户端需要能知道调用的服务是正确的服务。大体上说来,目前这还是一个没有解决的问题。要处理这个问题,有两个(并不互斥的)方案。

首先,让实现主机级别的防火墙规则(在任何的容器之外)的网络系统和选项更灵活,以便能细粒度控制访问策略,来控制某些容器能被其他哪些容器调用。我把这个称之为网络的微隔离(network micro-segmentation)。这里的挑战之一在于在动态调度下如何进行策略的配置。尽管尚处于起步阶段,有很多的公司正在努力简化这一点,通过在网络中添加支持,或者同编排器协作,又或者过在处于高层次的应用中进行定义。一个很大的问题是,服务的使用范围越广,微隔离的效果就越小。如果一个服务有成百的调用者,“拥有访问权即意味着得到授权(access implies authorization)”的简单模型不再适用。

第二个方案是让应用在实现数据中心内的认证和加密中扮演更加重要的作用。这对于那些客户端众多、并且在大的机构中已经形成“软多租户”状态的服务适用。这需要有一个生产环境服务的身份系统。我已经开始一个叫做SPIFFE(Secure Production Identity Framework For Everyone,给大家使用的生产环境安全身份系统框架)的业余项目。这些理念已经在Google这样的公司得到了验证,但是还没有在其他地方施行。

安全是一个很深入的话题,这里肯定有很多威胁和注意事项没有涉及到,还需要持续的探讨。

到这里,我们的云原生系列文章就结束了。欢迎大家在Medium留下自己的想法,或者在Twitter上联系jbeda,cmcluck或者heptio。


原文链接:

* Cloud Native Part 1: Definition
* Cloud Native Part 2: In Practice
* [Cloud Native Part 3: DevOps
](https://blog.heptio.com/cloud-native-part-3-6f9d888c5f07#.xjj0zlzrt)
* Cloud Native Part 4: Containers and Clusters
* Cloud Native Part 5: Microservices
* Cloud Native Part 6: Security

翻译:钟最龙

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(下)

Dataman数人科技 发表了文章 • 0 个评论 • 2046 次浏览 • 2016-11-11 15:22 • 来自相关话题

SRE系列教程 | 孙宇聪:来自Google的DevOps理念及实践(上)

Dataman数人科技 发表了文章 • 0 个评论 • 4713 次浏览 • 2016-11-10 17:54 • 来自相关话题

谷歌GAE运维揭秘:如何做到每天处理超过1000亿个请求

caicloud 发表了文章 • 0 个评论 • 2490 次浏览 • 2016-04-14 18:10 • 来自相关话题

文章由才云科技翻译,如若转载,必须注明转载自“才云科技” 在这篇博客帖中,我们请到了Chris Jones(他做了三年半Google App Engine运维工程师,到目前为止已经当了9年的谷歌运维工程师),来探索更多关 ...查看全部
文章由才云科技翻译,如若转载,必须注明转载自“才云科技”


在这篇博客帖中,我们请到了Chris Jones(他做了三年半Google App Engine运维工程师,到目前为止已经当了9年的谷歌运维工程师),来探索更多关于在Google上运行产品系统的细节。Chris也是《Site Reliability Engineering: How Google Runs Production Systems》这本书的编辑之一,该书由 一直处于互联网发展前沿的O’Reilly Media出版,现在已经可以买到。

Google App Engine每天都服务超过1000亿个请求。就像你听说的那样,是我们的运维工程师让这成为可能。这的确有点像是魔术,将计算机科学和工程原则运用到编程系统的设计和开发中——这个总体来说是十分庞大。
谷歌运维是一套工程方法,让我们或者任何人更好的运行产品系统。它将运维的推广到更大的IT社区。它用有趣的方式来大规模提高性能和可靠性,这对于任何公司来说都是有用的。做得好的话,SRE技术可以提高操作编程服务的效率。

Q:Chris,能告诉我们有多少SRE在操作App Engine吗,现在有多大规模呢?

Chris:我们每天有百万级以上的应用程序在处理1000亿以上的请求,支持的SRE大概几十个的样子。

Q:只有那么少的人,是如何做到这样的规模的呢?

Chris:SRE也是一个工程方法,它可以操作大规模分布式编程服务。但是让系统高度标准化也是有争议的。高度标准化意味着所有的系统工作都是相似的,这也就意味着对操作人员的需求越来越小了,因为操作的复杂性大大降低了。
自动化也十分重要:我们的启动进程是全自动的,所以我们可以很好地用计算机来对这些进程进行扩容,而不是雇更多的人。如果想要将人放到进程上,那会显得很无趣,很多余。你会发现错误飙升。计算机的对错误的反应次数远远比我们人要来得多,而且快。在我们还没有注意到错误的时候,计算机就已经在将流量引到另一个数据中心了,同时保证服务继续运行。让人做人擅长的事情,让计算机做计算机擅长的事情。

Q:在SRE模式后,还有什么其他的方法吗?

Chris:因为有很多SRE团队在处理Google的服务,所以我们可以在产品上扩展标准化原则:SRE-创建工具原本是用于部署新版本的Gmail 的,例如,可以被整理来覆盖更多的场景。这也就意味着每个团队都不需要再自己创建方法来部署更新。这就确保每个产品在工具提升之后,都会得到改进,这就使得整个系统更好的使用工具。
另外, 软件工程和系统工程知识的结合,令解决方案囊括两者优点。谷歌的软件网络负载均衡器,Maglev,就是一个例子———而且它是Google云平台负载均衡器的底层技术。

Q:那么这些方法是如何影响App Engine和我们运行在AppEngine上的用户的呢?

Chris:我说个故事来阐述这个。在2013年的夏天,我们将所有App Engine的美国区域从国家的一边转移到另一边。这个举动招致没有停工期给我们的用户。

Q:怎么做到的呢?
Chris:我们先关闭一个App Engine集群,然后就如设计的那样,在上面运行的apps自动移动到了剩下的集群。我们早就事先在目标数据中心创建了美国区域的High Replication Database(https://www.youtube.com/watch?v=xO015C3R6dw)的复本,这样那些应用程序的数据(PB级别的数据!)就在该在的地方;对数据存储的修改是自动复制的,这样就可以实时更新。当在新的本地打开App Engine的时候,apps自动被分配到那个从他们备份集群中转移的集群,而且他们所有的数据是已经在适当的地方了。然后我们用剩下的集群来重复进程,直到我们完成之后。
事先准备,将大量的测试和应变计划结合,这就意味着当事情出错时候可以将冲击减少到最小。当然,我们将内部事后析误——SRE如何工作的另一个重要部分——放在一起来理解到底什么出错了,以及如何修复对长远比较好,没有指责。

Q:So cool!那么我们如何找关于SRE更多的消息?
Chris:如果你对SRE是如何在Google运行很感兴趣的话,那么就点击这个网站:https://landing.google.com/sre/,我们这周(四月7-8)也会在SREcon:https://landing.google.com/sre/就这个话题给出不同的演讲。

文章由才云科技翻译,如若转载,必须注明转载自“才云科技”
原文链接:https://cloudplatform.googleblog.com/2016/04/lessons-from-a-Google-App-Engine-SRE-on-how-to-serve-over-100-billion-requests-per-day.html#rd?sukey=fa67fe3435f5c4be3949a9675fc67882cf48cbb960b0e1aa61baa0775aec8768a7021ae7ef0c528c263a73e8161551a8

想要了解更多关于Kubernetes的信息,欢迎关注Caicloud公众平台

图片_1副本.png

谷歌容器管理10年记

liguangcheng 发表了文章 • 0 个评论 • 4080 次浏览 • 2016-03-26 22:55 • 来自相关话题

【编者的话】本文介绍了过去十年谷歌在容器管理方面的实践,包括了Borg,Omega和Kubernetes的历史和架构方面的比较,谷歌在其内部使用容器的概况,以及谷歌试图通过社区来推动其Kubernetes成为容器管理标准的努力。 @C ...查看全部
【编者的话】本文介绍了过去十年谷歌在容器管理方面的实践,包括了Borg,Omega和Kubernetes的历史和架构方面的比较,谷歌在其内部使用容器的概况,以及谷歌试图通过社区来推动其Kubernetes成为容器管理标准的努力。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办,来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网等公司的技术负责人将带来实践经验分享,4月7日之前购票只需338元,欢迎感兴趣的同学抢购。

容器的概念和实现并不是搜索引擎巨头谷歌发明的,但是谷歌却通过在上百万的服务器上编排和运行了数以亿计的容器帮助Linux操作系统的容器技术日趋完善。谷歌有很多经验可以分享,但依然谦虚的认识到也还有很多需要学习的地方。

这或许是其中最重要的一个原因使得谷歌在两年前决定开源其容器管理系统Kubernetes。谷歌过去通过发表论文向业界展示通过它的高精尖技术处理大规模环境下中的分析、存储和计算问题。但是这种方式有时候产生事与愿违的效果,例如谷歌的MapReduce理论被雅虎用来实现Hadoop进而孵化出了一个全新的领域。现在,谷歌如果不将其技术和标准贡献给社区让业界来遵从,谷歌将跟整个业界不兼容。

因此我们认为Kubernetes是谷歌的一次尝试,通过分享技术到社区以此推动该容器管理系统的开发,期望在将来能够替代其在内部使用了多年的集群管理的核心Borg,就像他们的名字暗示的那样其中包含了许多不同的技术(例如几年前产生的Omega调度器)。这次,谷歌希望能够得到社区的帮助,目前已经有超大规模集群以及HPC方面的专家在帮助充实Kubernetes以解决其只能支持单一的工作负载的问题,虽然在谷歌内部已经有5,000到50,000个节点的集群,但是其上运行的负载还是相对单一的。

在谷歌内部创建和扩展Brog的跟创建Kubernetes的核心开发团队是同一组人,他们继续在Kubernetes项目中有很大的影响力。这包含了Kubernetes的共同创立者Brendan Burns;过去8年一直在致力于集群管理系统工作的谷歌主管软件工程师John Wilkes;Borg容器管理系统的技术负责人、Brog的扩展组件Omega的创建者、Kubernetes的设计负责人Brian Grant;Kubernetes技术负责人David Oppenheimer;谷歌负责基础设施的副总以及加州大学伯克利分校的教授Eric Brewer。

谷歌发布了两篇介绍其容器管理系统的技术文章起到了重要的作用,第一篇是2013年10月发表的介绍Omega的文章,在介绍Omega的文章发布之后的2013年11月份在大规模系统管理会议(Large Installation System Administration conference)上Wilkes做了精彩的演讲。这解释了谷歌的Borg系统,同时这些信息的批露是在2014年夏天Kubernetes发布之前。在Kubernetes发布之后,带来了不少关于Omega和Borg之间关系的困扰,在2015年4月份发表的第二篇文章解释了谷歌的对于大规模集群管理的视角,在文章发表后,我们也采访了Wikes得到了更多谷歌关于容器和集群调度的洞察。

从事Borg,Omega和Kubernetes工作的谷歌顶尖工程师们ACM Queue上发表了另外一篇更通俗的文章描述了谷歌过去十年间在容器管理方面的经验和教训,提供了更多关于谷歌认为或者说希望看到Kubernetes社区前进的方向。

事实证明了Borg并不是这个搜索引擎巨头创造的第一个集群和应用管理工具。谷歌跟其它所有的公司一样有批处理工作负载和长期运行工作负载的组合,它在物理上将不同的工作负载运行在不同的集群里。一个叫做Babysitter的项目运行长期运行工作负载(例如Web服务和其它基础设施服务),同时另外一个叫做Global Work Queue的项目运行批处理工作负载例如孵化了Hadoop而谷歌仍然在继续使用的MapReduce大数据分析框架。但是,在不同集群里运行不同的应用会造成经常性的计算资源浪费,这对在过去十年快速成长的谷歌来说是不可接受的。

关于软件容器,即使是在十年前也不能算是一个新概念。我们甚至可以说1989年克隆大型机制造商Amdahl提出的PR/SM逻辑分区就已经是容器,毫无疑问IBM自己System z主机系统上的的虚机操作系统产生的虚机在本质上也是软件容器,直到今天还作为在主机系统上运行Linux实例的后台技术。FreeBSD有Jail partitions,Solaris最终也有了自己的容器技术。但是谷歌作为一个Linux公司不得不进行大量的工作在Linux内核中添加容器相关的功能。现在在每一个Linux发行版中都存在的LXC容器技术是在谷歌的工作的基础上创建的,而Docker是这项工作的另外一个分支。

在某种程度上来讲,Kubernetes借鉴了单一化的Borg系统和更加灵活的Omega系统的技术(使得多种工作负载可以共享资源而不必只是排队等待),最终结果是Kubernetes成为谷歌的第三个容器管理系统。如果Kubernetes的复杂程度和规模持续增加的话它可能会成为另外一个Borg,而我们认为这是谷歌的其中一个目标。从另外一个角度来讲,就像我们前面说的那样,谷歌希望Kubernetes能成为容器管理的事实上的标准,这使得构建企业级私有云的用户更有可能去使用谷歌的基于Kubernetes构建的Google Cloud Platform公有云服务。

从谷歌发布的最新文章中透漏出的关于其容器管理系统从裸机到容器的转变的重要信息是意义深远的,这或许对谋求容器作为更好的方式的人来讲不是显而易见的,我们认为这是相比与抬高服务器利用率的服务器虚拟化来讲更廉价的一种方式。一切都变成了应用为中心而不是服务器为中心,这正是IT公司们梦寐以求的天堂。工作负载调度器、集群管理系统和容器管理器协同工作当应用需要时为应用提供正确的容量,不管应用是延迟敏感的负载或者是对延迟不敏感的批处理负载,工程师和开发人员所需要关注只是应用的运行状态,而他们可以非常容易的获取应用运行的状态因为所有的关于状态的API调用都是在应用层面的而不是服务器层面的。

这意味着容器时代的到来,在谷歌里将不在有裸机,这可以作为给那些HPC厂商和其它超大规模集群厂商以及云服务提供商的一堂课,他们还认为需要运行在裸机模式下(我们听所在AWS上运行的很多大数据服务运行在裸机上而不是用定制版Xen Hypervisor支持下的EC2计算实例)。这不是一个确定的结论,但是在些许性能损失(其实比整机使用KVM或者Xen进行虚拟化的性能损失还是小很多的)和容器带来的管理与部署灵活性之间看上去绝对是一个非常划算的折衷。(如果Intel想解决这个问题,可以在每一个芯片中增加一个容器管理核心就足够了,或者在Xeon服务器芯片中用两个或者三个核来运行Hypervisor)。

“容器的隔离性和最小依赖被证明了在谷歌是非常有效的,容器已经成为了谷歌基础设施上运行的唯一实体”, 文章的作者写道,“一个结果就是现在谷歌在任何时间只有很少数量的操作系统版本部署在所有的服务器上,这就只需要很少的人员去维护和更新操作系统版本”。

使用Kubernetes,容器是一个应用程序的运行时,而作为构成微服务的多个容器被聚合到一个更高层次的被称为pod的概念中。Kubernetes最重要的是一个pod管理系统来使得这些容器集合能够协作和运行。Borg有一个类似的架构,Linux容器作为最细的粒度和Allocation的最底层。Allocation,缩写为alloc,是容器集合的一个上层包装。Borg允许某些容器在alloc之外运行,文章的作者说“这是造成诸多不便的原因”,这或许还是一个非常保守的陈述。Kubernetes则不允许你这么做。然而如果在丢安全或者隔离性有更高要求的场合例如在多租户环境的公有云中你可以在容器内运行容器,或者在一个虚拟机内部运行容器。事实上,谷歌在它的Cloud Platform里就是这么做的。一个服务器上运行了一个巨大的容器,在这个容器之上运行了KVM Hypervisor或者其它容器来向公有云上的用户暴露不同的Google Engine实例类型。

就像Omega通过收集和使用谷歌集群状态信息来更好的分配资源给容器化的批处理应用和在线应用,Kubernetes则实行了严格统一的API来跟集群进行接口 – 不像Brog在过去若干年增加了很多的API类型和风格。

“Kubernetes的设计中微服务和小的控制回路的组合是一个通过编排进行控制的例子 – 通过组合协作中的分散和自治实体来达到期望的效果”,谷歌最近这的篇文章中说,“与集中式的编排系统相比Kubernetes是一种更精巧的设计,集中式的编排系统可能在开始时相对较容易,但是随着时间的推移特别是在出现不可预知的错误或者状态变化时就会变得容易出现问题。”

我们的整体印象是Kubernetes是一个虽然还有那么一点不成熟但是却是一个比Borg更好的工具,仅仅是Kubernetes这一个工具就会给整个IT业界一个很大的影响。

谷歌将它过去十年在容器和集群管理方面的经验回馈给开源社区,甚至在它帮助Berkeley的AMPLab推动Mesos系统的开发之后,Mesos系统目前已经被Mesophere商业化。这或许是谷歌后悔做的事情(译者注:指推动Mesos的发展),但是开源Kubernetes对谷歌来说确实是一个艰难的决定。唯一的另外一个可能选项是让Mesos变成像Hadoop一样的另外一个事实上的标准,我们已经看到这件事情的现状了,这显然不是谷歌想要的。谷歌是唯一一个不能轻易从它自创的MapReduce转到Hadoop的超大集群运营者,这意味着它基础设施软件开发的成本从长期来看将持续上涨。

原文链接:A Decade Of Container Control At Google(翻译:李光成)

=================================
译者介绍
李光成,IBM中国研究院资深研究员,研究方向是云计算基础设施及技术。目前在做的是Docker资源隔离方面的研究项目。