云计算

云计算

【腾讯云】#容器团队#高级容器研发#招聘

Shirleyee 发表了文章 • 1 个评论 • 209 次浏览 • 2019-05-24 10:33 • 来自相关话题

高级容器研发工程师 工作职责 负责公有云/私有云中 Kubernetes/Devops 等产品技术方案设计与研发工作;负责 Kubernetes 相关前沿技术规划和调研工作,从技术上保证产品的竞争力;负责与产品及客户沟通,判定需求的合理 ...查看全部
高级容器研发工程师
工作职责
  1. 负责公有云/私有云中 Kubernetes/Devops 等产品技术方案设计与研发工作;
  2. 负责 Kubernetes 相关前沿技术规划和调研工作,从技术上保证产品的竞争力;
  3. 负责与产品及客户沟通,判定需求的合理性,找出最合适的方式解决客户问题。
工作要求
  1. 3 年以上后端开发经验,Coding、Debug 能力强, 有丰富的架构设计经验;
  2. 熟悉 C/C++/Go/Java/Python/Ruby 等至少二种编程语言;
  3. 熟悉 Docker/Kubernetes/Swarm/Mesos 等技术;
  4. 熟悉 Jenkins/ELK/Prometheus 等技术优先;
  5. 熟悉 AWS/Google Cloud 等云计算厂商产品优先。


有意请戳:
Wechat:13723737494
Email:Shirleyeee@foxmail.com

Serverless系列 | 云计算究竟如何进化出了Serverless?

灵雀云 发表了文章 • 0 个评论 • 538 次浏览 • 2019-04-10 16:14 • 来自相关话题

导读:近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is serverless》一书的部分内容,可以说是对Serverless科普与观察的上佳素材。本文为第1篇,他首先通过回溯云计算的发展史,来找出是什么原 ...查看全部

导读:近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is serverless》一书的部分内容,可以说是对Serverless科普与观察的上佳素材。本文为第1篇,他首先通过回溯云计算的发展史,来找出是什么原因导致进化出了 Serverless,然后解释 Serverless 到底为何物,最后总结为什么 Serverless 是云计算成长的必然产物,同时也是应用交付方式的巨大飞跃,非常值得一读!
原著:《What is serverless : understand the latest advances in cloud and service-based architecture》

作者:Mike Roberts & John Chapin
译文来源:深入浅出谈架构(ID:deep-easy-arch)
译者:灵雀云邵明岐

让我们回到2006年, 那时候还没有 iPhone 和移动互联网,Ruby on Rails 是一个非常热门的编程框架,Web 2.0 在当时是互联网最火热的名词。那时候大部分应用程序的后端服务,都是运行在托管或者自建的数据中心和物理服务器上。

云的诞生

2006年8月发生的事情将从根本上改变这种模式。 亚马逊新的IT部门 AWS 宣布推出Elastic Compute Cloud(EC2),EC2是众多基础架构即服务(IaaS)产品中的第一个, IaaS允许公司租用计算资源 (主要是面向互联网应用的虚拟主机),而不是购买自己的服务器, 它还允许人们在几分钟之内就可以获取到主机资源。 EC2的五个主要优势是:

1.降低人工成本
在 IaaS 出现之前,公司需要雇佣有专门技能的人来管理数据中心和里面的物理服务器,他们需要管理从电源和网络,到货架和安装,到修复机器的磁盘等物理问题,到设置操作系统(OS)。 通过IaaS,所有这些都消失了,而是都交给 IaaS 服务提供商,比如 AWS 或者阿里云。

2.降低风险
在管理自己的物理服务器时,经常会遭遇一些意外事件,比如硬件故障,从而导致系统不稳定或者长时间宕机,因为硬件问题很难预测,并且可能需要很长时间才能解决。 通过IaaS,客户虽然仍需要做一些工作来对抗硬件故障发生的风险,但不再需要知道如何修复硬件, 相反,可以简单地在几分钟内申请到新机器实例,并重新安装应用程序,从而限制了这些问题的风险。

3.降低基础设施成本
在大部分情况下,当您考虑电源、网络等成本的时候,EC2实例的成本比运行自己的硬件便宜,尤其是当您只想临时需要运行主机几天或几周而不是几个月时。

4.灵活扩展
考虑到IaaS带来的扩展优势,基础设施成本显着下降,通过IaaS,公司在扩展其运行的服务器的数量和类型方面具有更大的灵活性, 不再需要提前几个月预先购买10台高端服务器,相反,您可以从一个或两个低功耗,廉价的实例开始,然后随着时间的推移逐渐扩展您的实例数量和类型。

5.交付时间短
在托管服务器的旧时代,为新应用程序采购和配置服务器可能需要数月时间。 如果你想出新的想法,并且希望尽快尝试一下,在传统的方式下很难办到。 使用IaaS,交付时间从几个月缩短到几分钟。
基础设施外包
使用 IaaS,本质上我们可以认为是基础设施外包的技术。 当我们开发和运营软件时,我们需要做的工作大致可以分为两类:一类是针对需求需要定制的工作。另外一类是和其他公司都差不多,比较通用的工作。
基础设施就是属于第二种,其范围包括物理的设备,例如运行我们机器,电路,网络等,也包括一些通用的软件功能,比如用户认证。
基础设施外包通常可以由服务提供商(SP)提供。 例如,电力由电力供应商提供,并且网络由互联网服务提供商(ISP)提供,他们通过 2 种模式来减低成本和提高效率:规模化和技术创新。

规模化
几乎所有形式的基础设施外包都通过规模化的模式来降低成本,把大量工作打包在一起批量做,成本比单独一件一件做,效率大大提高。例如,AWS 可以以远低于小公司的价格购买相同规格的服务器,因为 AWS 一次性购买成千上万的服务器,而不是购买几十台服务器。 同样,AWS 的每台服务器运营成本远低于自建 IDC 的公司。

技术创新
基础设施外包通常也部分归因于技术创新。比如 EC2,是通过硬件虚拟化的技术来实现的。在IaaS出现之前,一些IT供应商已经开始允许公司来按月租用物理服务器。显然,EC2 的按小时租用主机的方式更具吸引力,而且,虚拟化技术可以将物理服务器细分为许多更小的,快速启动和关闭的虚拟机(VM),这样 IaaS 才变得可行。
基础设施外包与 IaaS 的五大好处完全一致:
• 降低人工成本 :减少人员,减少维护基础设施工作所需的时间;
• 降低风险 :消除了一部分对特殊技能专家的需求,并且能够获得及时的运营支持能力;
• 降低资源成本 :同样功能的成本更低;
• 提高扩展的灵活性:可以访问更多资源和不同类型的类似资源,而不会造成重大损失或浪费;
• 缩短交付周期:缩短从新想法到生产可用性的交付时间;
当然,基础设施外包也有其缺点和局限性,我们将在后面的部分介绍。

云计算的发展
云计算的发展是从IaaS开始的,比如EC2和AWS Simple Storage Service(S3), AWS是云计算早期的推动者,紧随其后的还有微软、谷歌、阿里云等。当我们谈论“云”时,我们通常指的是公共云,但是,我们也看到了私有云的市场发展的也不错,比如OpenStack。
公共云之后的另外一个潮流是PaaS,Heroku是当时最受欢迎的PaaS厂商之一, PaaS层面置于IaaS之上,将操作系统(OS)添加到外包的基础架构中,使用PaaS,您只需部署应用程序,云平台负责操作系统安装、补丁升级、系统级监控、服务发现等。
Heroku是公有云服务,Cloud Foundry是PaaS的一个私有云版本, 由于PaaS位于现有虚拟化解决方案之上,因此您可以在企业内部部署或者在IaaS公共云服务上部署“私有PaaS”,同时使用公共云和私有云通常被称为混合云, 能够在混合云环境中实现一个统一的PaaS平台对企业特别有用。
在虚拟机之上使用PaaS的最新方式是使用容器,Docker在过去几年中变得非常非常受欢迎,因为它可以从操作系统开始,更清楚地描述应用程序的系统需求,而管理/编排容器的云服务,通常称为容器服务(CaaS),比如Google的Container Engine和AWS的ECS。 一些私有云的CaaS是Kubernetes和Mesos,您也可以把它们搭建在公共IaaS或者私有IaaS之上运行。
就像IaaS一样,PaaS和CaaS都是基础设施外包的另外一种更加高级的形式,它们和IaaS的主要不同之处是,有更高级别的抽象性,允许我们将运行应用的更多技术细节交给云平台,因此,PaaS和CaaS带给我们的好处,与我们之前列出的IaaS的五个好处完全一样,所以,我们可以将所有这三个(IaaS,PaaS,CaaS)组合为计算即服务(Compute as a Service)。
**
Serverless时代到来**
前面解释了半天云计算的发展史,主要就是想引入主题——Serverless。它将会是云计算演进的下一个重要技术,也是另外一种形式的基础设施外包,它同样具有我们已经看到的云计算的五大优势,云厂商同样也是通过规模化和技术创新来提供这些优势。

Serverless 并不等于 FaaS
大部分人开始了解Serverless时,会有一个误区,以为Serverless就是FaaS,比如AWS的Lambda,Google的Cloud Function。但深入研究就会发现,Serverless实际上涵盖了一系列技术,我们将这些技术分为两类:Backend as a Service(BaaS)和Functions as a Service(FaaS),所以,简单来说Serverless=BaaS+FaaS。

BaaS
BaaS就是用现成的第三方服务替换原来自己编码实现或者自己搭建的服务器端组件,它在概念上更接近于Software as a Service(SaaS),不同之处在于SaaS通常是关于外包业务流程,比如人力资源或销售工具,或者像Github这样的服务技术工作者的产品。然而对于BaaS来说,实际上是将应用程序分解成更小的组件,并将其中一部分组件用第三方提供的服务来完成,这个第三方服务通常就叫做BaaS。
BaaS服务是通过API远程调用的组件,而不是SDK,或者Library,我们通过远程API的调用,来完成应用程序的一部分功能。这里有一个很好的例子是身份验证,许多应用程序通过自己的代码来实现注册、登录、密码管理等功能,但是这些代码在很多应用程序中非常相似,同样的事情无数的公司和团队做过了无数遍,已经非常成熟了,可以把它们抽象出来变成一个第三方公共服务再好不过,这正是Auth0和亚马逊的Cogono等产品的目标,这两种产品都允许任何人,不需要写一行代码的情况,就可以在移动应用程序和Web应用程序上实现非常完善的身份验证和用户管理功能。

BaaS最早的时候,在移动应用程序开发中特别受欢迎,一开始人们甚至把它叫做Mobile Backend as a Service(MBaaS),但是实际上,BaaS除了被用作移动应用的后端服务之外,还可以应用到非常多的场景,比如我们可以不需要自己搭建和维护Mysql实例,而是使用亚马逊的RDS服务,或者可以用Kinesis替换自己搭建和管理的Kafka消息队列,其他数据基础设施服务包括文件系统、对象存储和数据仓库、语音分析、以及我们之前提到的身份验证,这些服务都是BaaS,都可以作为一个应用的后端服务的一部分。

FaaS
Serverless的另一半是FaaS, FaaS是Compute as a Service的另一种形式,概念上容易混淆的地方在于,AWS有时候将自己的FaaS服务,Lambda,称为Serverless Compute。
FaaS是一种构建和部署服务器端软件的新方法,只不过粒度更细,能够独立的部署某一个函数,许多人认为Serverless就是FaaS,但是实际上并不完全正确。
我们通过传统方式部署服务器端软件时,从主机实例开始,通常是虚拟机(VM)实例或容器(参见下图), 然后我们在主机中部署应用程序,如果主机是VM或容器,那么应用程序是一个操作系统进程, 通常我们的应用程序中的代码实现了一些不同功能的操作,例如,Web服务提供检索和更新资源的操作。

pic2.jpg



FaaS改变了这种部署模式(如下图), 部署模型中少了主机实例和应用程序进程,我们只关注实现应用程序逻辑的各个操作和函数,将这些函数代码单独上传到云供应商提供的FaaS平台。

pic3.jpg



但是,这些函数在云服务托管的服务器进程中缺省处于空闲状态,直到需要它们运行的时候才会被激活(如下图), 通过配置FaaS平台来监听每个函数的激活事件。 当该事件发生时,FaaS平台实例化函数,然后使用触发事件调用它。

pic4.jpg



一旦该函数执行结束了,理论上FaaS平台可以销毁掉实例,不过,通常为了优化性能,会将函数实例保留一段时间,可以被下一个事件复用。
FaaS本质上是一种事件驱动的模型,除了提供托管和执行代码的平台之外,FaaS平台还集成了各种同步和异步事件源,HTTP API网关就是一种同步事件源,消息总线、对象存储或类似于(cron)的定时器就是一种异步源。
AWS在2014年就推出了Lambda,到目前为止成熟度和接受度已经获得大幅的提高,一些公司每天在使用Lambda处理数十亿的事件,到目前为止,Lambda集成了超过20种不同类型的事件源,可以支持各种不同类型的应用程序。
除了AWS Lambda之外,还有其他一些来自Microsoft,IBM,Google厂商的商业FaaS产品,正如我们之前讨论的各种其他计算即服务平台(IaaS,PaaS,CaaS)一样,也有可以运行在私有云上开源FaaS项目,私有的FaaS领域目前比较早期,没有绝对的领先者,一些比较活跃的项目有OpenWhisk、Fission、IronFuncions、Serverless、Nuclio等。

为什么FaaS和BaaS都叫Serverless?
从表面上看,BaaS和FaaS完全不同,BaaS是托管应用程序的一部分依赖组件,FaaS托管应用程序的代码,那么为什么我们把它们放在一起,都叫做Serverless呢?
这里的关键就是不需要管理自己的服务器主机或服务器进程,完全使用Serverless架构的应用程序,将不再需要考虑服务器或者进程,应用程序的所有逻辑。无论您是自己编写的,还是与第三方服务集成的部分,都运行在完全弹性的环境中,状态也采用以类似弹性的形式存储,无服务器并不意味着服务器已经消失,这只是意味着着您不再需要关心它们了。

Serverless带给云计算的重大变化
在云计算过去十年的发展中,我们已经将应用程序的运行环境和通用组件,越来越多的外包给云厂商。Serverless也同样符合这一趋势,主机管理、操作系统管理、资源分配、扩展、甚至应用逻辑的整个组件,都外包给云厂商,在成本和运营效率方面获得了显著的提升。
但是,在应用程序架构方面,Serverless有很大的变化。之前的云计算服务,并没有从根本上改变设计应用程序的方式,例如,当使用Docker这样的工具时,我们在应用程序周围放置了一个更薄的“盒子”,但它仍然是一个盒子,逻辑架构不会发生显著的变化,在云中托管MySQL实例时,我们仍然需要考虑工作负载所需的虚拟机资源,而且仍需要考虑故障切换。

这种情况随着Serverless而发生变化,并且是非常大的变化,FaaS本质上是和传统架构非常不一样的架构类型——事件驱动模型。它的部署方式更加细粒度,以及需要将状态保存到FaaS组件之外,BaaS使我们无需编写完整的逻辑组件,但需要将应用程序与云厂商提供的特定接口和模型集成。
那么,Serverless的应用程序架构到底有什么不同之处,它看起来到底长什么样子? 这是我们接下来要讨论的内容。

2019年企业云服务的十一大趋势

Rancher 发表了文章 • 1 个评论 • 468 次浏览 • 2019-01-17 10:57 • 来自相关话题

云计算已成为企业应用程序的主要范式。 随着企业使其计算和网络架构现代化,云原生架构是主要的目标环境。 随着2019年的到来,很明显,无所不包的云计算趋势并未放缓。 以下是我对今年这个充满活力的市场的预测。 ...查看全部
云计算已成为企业应用程序的主要范式。 随着企业使其计算和网络架构现代化,云原生架构是主要的目标环境。



随着2019年的到来,很明显,无所不包的云计算趋势并未放缓。 以下是我对今年这个充满活力的市场的预测。



软件即服务(SaaS)提供商将深化他们的企业应用程序投资组合



显然,Oracle、SAP、Salesforce.com和其他SaaS提供商将无法削弱Amazon Web Services、Microsoft Azure和谷歌云平台在公共云市场的平台即服务(PaaS)和基础设施即服务(IaaS)领域所享有的势头。为了在这种趋势下保持增长,并防止占主导地位的PaaS/IaaS提供商侵占它们的地盘,SaaS提供商将加倍投资于企业资源规划、人力资源、客户关系管理和其他业务应用程序。2019年,我们将看到SaaS提供商推出更广泛的垂直行业产品,同时深化这些服务的AI驱动数字助理,嵌入式推荐器和机器人自动化流程功能,以提高用户的工作效率。



企业将会加速把应用程序、工作量和数据迁移到云原生主干网



越来越多的商业混合和multicloud工具将加速并降低将企业IT资源从现有遗留平台转移到原生云PaaS和IaaS平台的成本。



2019年,更多的企业将在不需要重写现有应用程序的情况下编辑遗留工作量,从而降低与复杂迁移相关的技术风险。公有云提供商将优先考虑提供迁移工具、multicloud底板和专业服务,以帮助企业以可控的风险来快速、经济有效地执行这些迁移。



公有云提供商将完全托管的内部设备定位为其混合云入口



去年,亚马逊Amazon Web Services宣布推出AWS Outposts,这是一种完全托管的基于计算/存储机架的服务,允许客户使用现有的VMware许可证在其场内运行选定的公有云服务。在2019年末发布之后,我们将看到这个解决方案是否能够引起企业的响应,这些企业可能仍然不确定如何平衡安全性、遵从性和延迟问题(这些问题迫使他们将计算资源保留在原有的平台上)与迁移到公有云的可伸缩性、效率和敏捷性优势之间的关系。



为了在Outposts发布之前削弱AWS在混合云领域的势头,AWS的公有云竞争对手将增强和推广其现有的混合云本地计算/存储机架。然而,Microsoft Azure Stack、IBM Cloud Private、Oracle Cloud At Customer等公司在将现有企业客户迁移到其各自的公有云的战略推进中,是否会为这些供应商提供任何优势,仍然值得怀疑。






随着核心开源代码库的稳定,Kubernetes的应用将会加速



核心的Kubernetes开源平台显示出成熟的迹象,因为贡献的总数已经放缓,提交速度正在减慢。2019年,Kubernetes生态系统的创新将转向在外部GitHub组织中在CNCF外部管理的项目。



在商业化方面,新兴的Kubernetes生态系统中的启动活动和产品发布将会增长,性能、安全性、自动化、可伸缩性、集群管理、边缘优化本地编辑、应用程序负载平衡和无服务器提取将成为创新和采用的巨大焦点。



解决方案提供商将把他们的Kubernetes实现构建到成熟的网络操作系统中



Kubernetes正在成为供应商管理的工具、服务和集成底板的投资组合的基础,这些工具、服务和集成底板可以支持用于虚拟化、本地编辑化和无服务器应用程序环境的日益复杂的网络操作系统。2019年,所有领先的公有云提供商将在各自的Kubernetes实现上进行更深入的投资,其中亚马逊网络服务(Amazon Web Services)、微软(Microsoft)、谷歌、IBM及其红帽(Red Hat)子公司、甲骨文(Oracle)、思科系统(Cisco Systems)、威睿(VMware)和阿里巴巴(Alibaba)将保持领先。



容器将越来越多地跨越有状态和无状态语义



云原生环境正在发展,通过扩展存储架构支持有状态交互,同时为跨混合无服务器multicloud的无状态、事件驱动型计算的下一个飞跃提供了基础。2019年,更多的企业将在Kubernetes上采用Knative实现无服务器功能,同时部署新一代存储解决方案,优化了容器结构中的持久性。



服务网格将成为云计算中最主要的网络管理底板



在云原生行业服务网络计划的进展中,最值得注意的是,Istio、Envoy和LinkerD将提升这些项目在企业multicloud计算中的显著性。到2019年,许多企业将把服务网格纳入其努力的核心,即在其分布式计算环境中,在本地编辑内部资源和越来越多的公有和私有云结构之间搭建灵活的桥梁。云提供商将加强对托管服务的支持,这些托管服务简化了通过网格和中心辐条架构对数千个虚拟私有云和内部网络的互联和管理。



Cloud-to-edge分布式计算结构将会扩展



在过去的一年中,供应商向市场推出了一系列创新的边缘网关、本地计算/存储机架和设备级别的容器运行时。到2019年,这些创新将汇聚成一个面向边缘、分布式和联合的本地云计算结构,使数据、应用程序和工作量更灵活地分布到代理点附近。



随着物联网成为云计算的主要入口,“AIOps” IT管理自动化工具遍布整个结构,“数据中心”的概念将为完全分散管理的“软件定义的数据中心”所代替。



在这个Cloud-to-edge的计算结构中,区块链和其他超级账本的主干网将不断发展,为所有网络、系统和应用程序级的操作提供不可变的审计日志。






本地编辑将转换网络路由平面



虚拟区域网络操作系统将变为云原生,将所有协议和管理功能放在微服务中,并使用通过Kubernetes编排的不可变本地编辑。



到2019年,更多的网络运营商将能够通过开发运维持续集成和持续部署工作流来管理路由和流量管理功能的更新。这将允许网络运营商只部署所需的网络功能,从而降低复杂性和减少网络攻击面。



云原生开发运维工具将融合虚拟化、容器化和无服务器



企业客户要求能够组合云原生微服务,以便在虚拟机、容器和无服务器结构的各种协调混合中执行。到2019年,我们将看到更多的开发工具将迄今为止不同的程序聚合在一起,并使CI/CD能够跨日益异构的multicloud,这些multicloud将Kubernetes集群联合起来,同时为无状态、事件驱动的微服务的轻量级开发提供无服务器接口。



这种应用程序范例聚合的关键是“基础设施即代码”工具,这些工具支持云原生应用程序结果的声明性规范,以驱动必要本地编辑、无服务器功能、分布式编排和其他应用程序逻辑的自动编译和部署。



容器化的微服务市场将会扩大



公有云提供商已经建立了他们的可信本地编辑化解决方案的在线市场,这些解决方案包括他们自己的产品和不断增长的合作伙伴生态系统。 在2019年,我们将看到这些市场在所提供的解决方案的范围和多样性得到扩展,因为公有云提供商更多地关注合作伙伴,软件供应商将这些渠道作为其主要的市场进入方法。



为了帮助客户实施针对其用户采用基于云的解决方案的策略,公有云提供商将提供私有市场功能,使企业采购人员能够定义和管理与组织策略一致的、经过批准的、经编辑的云就绪解决方案列表。



原文链接



https://www.infoworld.com/article/3328860/cloud-computing/key-enterprise-cloud-trends-for-2019.html?upd=1547605102533

不同于混合云,你了解云计算的下一阶段——“多云”吗?

Rancher 发表了文章 • 1 个评论 • 504 次浏览 • 2019-01-11 13:50 • 来自相关话题

也许你会认为“多云”和“混合云”是一个意思,其实在云计算的发展演进过程中,这二者处于的是不同阶段。 人们喜欢给一切东西命名。在云计算领域,一项技术或产品的命名通常反映着它的使用方式:公有云,私有云,混合云。 ...查看全部
也许你会认为“多云”和“混合云”是一个意思,其实在云计算的发展演进过程中,这二者处于的是不同阶段。



人们喜欢给一切东西命名。在云计算领域,一项技术或产品的命名通常反映着它的使用方式:公有云,私有云,混合云。现在,“多云”这个新术语又出现了,它象征的是云计算的另一种新兴模式。



术语及定义



“多云”意味着使用多个公有云。当企业试图避免依赖单个公有云提供商,或当企业需要从每个公有云中选择不同的、特定的功能或服务,又或者上述两个目的兼而有之时,就会出现“多云”这种使用模式。



“多云”与“混合云”的区别



那么,多云(multicloud)和混合云(hybrid cloud)是什么关系?有些人会互换使用这两个词,但实际上它们确实有不同的含义。 混合云是私有云(基于云技术构建的本地数据中心)与公有云的配对。



如果您将多个公有云与私有云一起使用,那么这仍然是一个“多云”。 (有些人可能会称它为混合多云,这也是可以的。)



“实用混合云”的定义



近期还有一种新出现的概念/架构叫做“实用混合云(pragmatic hybrid cloud)”,它是指将传统企业数据中心与公有云的配对一起使用。这样用法的企业很多是对私有云感到失望,因此寻求一种将现有的云与公有云相结合的方法。



相比之下,多云架构使用的两个或更多公有云。




多云趋势的背后是什么



云计算正在变得越来越复杂,这是大家无可否认的趋势。几年前很多企业的愿景是能够将工作负载放在单个云上,无论是公有云还是私有云。但随着时间推移,混合云架构变得更具吸引力,因为它为企业提供了更多选择。



企业IT需要这样的选择,因为在亚马逊AWS之外,美国的谷歌、微软以及中国的华为、阿里、腾讯等其他巨头公司都开发了引人注目的公有云平台,为企业提供了除了AWS之外的更多启动公有云业务的可行替代方案。还有其他企业提供商——包括IBM、惠普、甲骨文等等——也加入了竞争,尽管目前这些公有云方案尚不如业界领先的几家成功。



正是由于公有云的可选择项越来越多,因此企业开始将它们混合在一起使用,无论是通过正式的架构流程还是通过“影子IT”(即公司中有团队在不让企业IT部门知晓的情况下,自己使用某种公有云)。各种影子IT经常选择不同的公有云,然后又希望企业IT部门能来管理这些云的运维工作。



总的来说,无论是用何种形式和方法,大多数企业现在都在管理着多云基础设施。



虽然许多IT组织在管理这些复杂的多云环境时,使用的是来自每个云的原生工具和服务,但也越来越多的企业变得越来越聪明,开始借助平台或工具,将自身从多云管理的复杂工作中抽离出来。



通过使用云管理平台(CMP)和云服务代理(CSB)等工具,企业可以像管理单个云一样管理多个云。但是,这里需要权衡的是,您也许只能使用每个云的一部分功能;也就是说,采取的是“最小公分母”的方法。



建议:关注云技术的作用而非名称



公共云,私有云,混合云,实用混合云,多云……语义超载?确实。



但是,我建议你不要被称谓困扰,而是专注于它们所做的事情。事实上,我相信云架构在未来几年也将有新的发展,并且新的模式也将继续出现。我也肯定,更多的新名字即将到来。


------------



作者介绍



David S. Linthicum



Deloitte Consulting的首席云战略官,也是国际公认的行业专家和思想领袖。Dave撰写过共计13本关于计算的书籍,担任过多家成功软件公司的首席技术官和首席执行官,以及财富100强公司的高级管理职位。他关注云计算、SOA、企业应用程序集成和企业架构的相关领域。



------------



原文链接:



https://www.infoworld.com/article/3226484/cloud-computing/what-is-multicloud-the-next-step-in-cloud-computing.html



下一代云计算:低熵云 | 演讲实录 (附PPT下载)

博云BoCloud 发表了文章 • 0 个评论 • 628 次浏览 • 2018-12-17 16:43 • 来自相关话题

12月5日,由BoCloud博云主办的IT进化大会·2018在北京圆满落幕。中科院计算所先进计算机系统研究中心主任包云岗分享了《下一代云计算:低熵云》的主题演讲,为现场嘉宾带来了学术界前沿研究的精彩介绍,获得了广泛关注。经包教授授权,我们将现场演讲整理出来分享 ...查看全部
12月5日,由BoCloud博云主办的IT进化大会·2018在北京圆满落幕。中科院计算所先进计算机系统研究中心主任包云岗分享了《下一代云计算:低熵云》的主题演讲,为现场嘉宾带来了学术界前沿研究的精彩介绍,获得了广泛关注。经包教授授权,我们将现场演讲整理出来分享给大家。


嘉宾介绍
包云岗,现为中科院计算所研究员,博士生导师,先进计算机系统研究中心主任,中国科学院大学岗位教授。研究方向是计算机系统结构,主持研制多款达到国际先进水平的系统,在国际会议期刊发表了40余篇论文,多次受邀担任ASPLOS、ISCA、MICRO、SC等国际顶级会议程序委员会委员。担任中国计算机学会理事、普及工作委员会主任,中科院青年创新促进会理事,ACM China副主席。


大家好,今天和大家一起从学术界的角度,来探讨云计算现在发展到什么样的状况,以及未来发展还会有哪些新的趋势。我们希望探讨的前沿技术可以在创业公司里帮助整个IT技术部门更好地服务更多客户。

幻灯片2.JPG

首先我们看一下过去十年,云计算经历了两个大的阶段。早期是虚拟化技术的使用,在云里面用了很多的虚拟化技术,比如Xen、VMware等等,但是后来大数据逐渐开始流行,越来越多的云平台或者数据都开始为大数据分析进行服务。横坐标是数据中心资源的利用率,纵坐标是用户体验,慢慢的利用率与用户体验就会分化,我们的应用分为两大类,有的应用是对用户体验要求特别高,有的是吞吐要求特别高,把系统的资源充分的利用起来,这是一个发展的阶段。


幻灯片3.JPG

但是随着这样的阶段往下走,我们的现状会出现什么情况?现状一:基础设施成本极高。为了服务这种大而新的业务,我们的基础设施投入越来越大,成本越来越高,这是微软的一位朋友在西雅图做基础设施给的数据,是2015年的数据,他说现在已经超过三百亿美元,这还是一个公司的投入,当然我们国内的公司也是投入很大,像阿里在张北的数据中心,都是上百亿。


幻灯片4.JPG

现状二:数据中心利用率极低。我们可以看到,其实数据中心利用率很低,并没有我们想象得那么高。一方面投入这么大,左边的这个图实际上是亚马逊在2011年左右的数据,稍微有点老,但是当时它测了一周的AWS整个利用率,大概是7%到17%,右边这个图是国内的运算数据中心,大部分的机器利用率还是低于20%,所以现在我们很多企业特别上规模的企业希望可以把整个系统的利用率充分提升。但是,这个提升不是那么简单的,背后有很多的技术挑战。


幻灯片5.JPG

现状三:用户体验不稳定。在提升技术的时候,还要保证用户体验,因为用户是第一位的。而现有的云计算或者数据中心平台,在用户体验保障上做得有很多问题,所以导致了Facebook这样的公司在亚马逊上用云的时候会占很多,但是用的很少。我们总结这个词语叫Stranding:占而不用。全世界来看这是数据中心面临很大的一个问题,你不得不超载或者需要提供额外多的资源来满足用户体验。


幻灯片6.JPG

我们看背后的因素,这里面我们可以看到Facebook用了很多的Memcached,基本上100个微秒请求就可以返回去,当利用率提高到70%的时候,有一批用户的用户体验就会非常糟糕,会比原来要增长十倍,所以现在在云里面是面临云计算系统性不稳定的巨大挑战。


幻灯片7.JPG

云计算下一个十年的发展是要提供高品质的云计算。我们希望云可以同时提供高的资源利用率和好的用户体验,只有这样我们才可以更方便地把与用户体验相关的应用放到云上去,当然我们还有其他的需求,比如安全等等,这里我就暂时不看安全的问题。


幻灯片8.JPG

这个判断实际上也不光是我们,而是业界一个共识。我们看到谷歌数据中心专家Amin Vahdat,在去年ONS的keynote讲到了Cloud 3.0应该关注隔离。HotDC研讨会上斯坦福Christos Kozyrakis教授讲到在新一代Cloud 3.0里低延迟是非常关键的。所以我们可以看到这是国际的共识,我们未来的发展都会朝这个方向前进。



幻灯片10.JPG

为什么延迟很重要?而且实现低延迟很难,是一个挑战。我想在座应该有一些做技术的朋友,我们做一个实验,如果一台服务器上跑一个应用,这种场景最后出来的结果会是什么样?



幻灯片11.JPG

这是我们做过的实验,跑一万次出来的数据,如果看执行时间这里有一个分布,这个时间分布是非常非常稳定的,波动幅度小于1%,但是整个机器只有一个应用,显然不是我们希望的。


幻灯片12.JPG

真正的服务器会在上面跑很多应用,我们把整个系统的应用率可以提上来,这是典型的共享云服务器。如果达到这样的水平,我们再来看一下刚才类似的例子会怎么样,这是谷歌的测试,我们布到这样的服务器上,处理一万个请求,可以看到时间分布,好像在前面很像,但是我们看横坐标是对冲坐标时间波动范围是在6到10倍,当你在云的环境下去测这些,是很容易产生很大的波动的。


幻灯片14.JPG

我们自己在学术界想要去尝试刻画这种现象,那么我们怎么刻画?我们认为熵是很好的描述不确定性和无序的度量,所以我们觉得未来得发展应该是低熵的云计算系统。首先是一种有序的、可控的计算系统,从而可以提高我们的利用率,比如说把系统整个利用率提高到60%以上,但是在这个前提上我们可以保证用户体验,可以达到很低的延迟,可控,还是需要通用的支持不同的云平台,这是我们的愿景。


幻灯片16.JPG

事实上现在的云更像是一朵乌云,我们看到一个基础设施是由两方面驱动的,一方面是应用,另一方面是底层技术,底层的器件架构。我们可以看到上面应用有大数据、人工智能等不断地在云里部署,开发人员越来越喜欢高级的语言等等,非常容易就可以训练大家在云上开发,还有微服务和Serverless新的形式不断地布到云上,这些都驱动云平台在基础设施上有相应的变化。

底层也是一样,越来越多异构的硬件、加速器、资源池、超融合和新型的SSD不断在云上布,我们云的设施化变成了一个大熔炉了,越是复杂越是熔炉,如果你没有管理和控制,它就会带来很大的问题,这是当前云的基础设施一定程度像无序共享的状态。


幻灯片17.JPG

大家都玩微信,我们有一半时间是在腾讯的数据中心里完成的,没去测点到点的实践,但如果你测出来,时间分布会是像图中这样的,这个是微软在北美测的数据,可以看到有很大的时间波动。这种时间波动在我们玩微信的时候可以接受,但是如果未来假设无人驾驶也要接入到云,比如AR/VR要到云端互动,这样的延迟会波动到两秒钟、四秒钟甚至到十秒钟,这肯定是不能接受的。这就是今天的云计算面临的很大问题,不能让更多的应用部署到云里。


幻灯片18.JPG

给大家介绍下我们的工作,我们在几年前得到国家的一些支持,来做云基础理论方面的研究。我们也在探讨,如果要去改变现在这种云的状况去实现低熵云计算系统,要做哪些变化?


幻灯片19.JPG

我们发现传统做云计算,虚拟化云基本上是虚拟机的调度,三十个毫秒,像分区,我把在线的分开,在物理上进行隔离,是可以保证比较好的应用性能和用户体验,但是资源利用率不高。而未来我们需要一种更细的调度机制,如果可以做到总线周期级调度,并且是纳秒级的,那么原来做不到的事情现在就可以做到,这是总的思路。我们希望实现非常细的调度机制,可以保证资源利用率以及用户体验。


幻灯片20.JPG

我们提出了实用可计算性理论,为了在设计系统时考虑用户体验因素,我们希望可以将云计算的重要实践经验形式化,比如说用户体验差的功能是不存在的功能,因为我们不想用(体验差的功能),所以这个是我们希望在理论上分析的。


幻灯片21.JPG

实际上我们有一个猜想,就是DIP猜想。你需要一个系统可以做到区分D、隔离I、优先化P,整个系统可以保证用户体验,同时可以提升利用率。



幻灯片22.JPG

但是真正要做到这一点还不是那么容易,因为今天最底层的计算机结构是不支持DIP的,底层结构包括存储、计算、输出输入是不支持DIP的。导致像右边这样的图,这个是美国联邦航空管理局测的数据,我们可以看到在飞机上是不敢用多核的,因为当你有多个应用一起跑的时候,计算机性能非常不确定,所以有时候实时系统里和我们云计算场景有很多类似的地方。


幻灯片23.JPG

我们实际上也提出了一种标签化冯诺依曼的体系结构。提供一套标签,用标签把不同的东西识别出来,对不同的标签进行控制,我们花了很多的时间,也有不少的进展。


幻灯片27.JPG

标签化思想的应用,可以在处理器里、可以在存储里,比如存储容器是我们在做的,也可以做到别的网络协议栈里,就是把不同的标签区分出来。


幻灯片25.JPG

举例,我们说标签化存储容器,就是用标签做协同的控制来做流量和用户的保障。大家可以看到如果用标签可以保证用户体验的情况下,把资源利用率提升1.5倍。


幻灯片27.JPG

还有一个例子是调度。以前的调度我们在计算机里有很多,但是这些调度都是独立的,每个人自己做自己的,如果我们用标签打破,可以让它们相互感受,我们就可以做到更好的调度。如果用这种方式,我们可以把整个用户所谓的延迟降低2.5倍,当然我们也是做了一些Bench的测试,混合场景下把应用布上去看企业和资源利用率之间的联系。


幻灯片30.JPG

前面都是想法,但是实际上我们已经真正实现了。这是我们做的火苗系统,是基于RISC-V做的一个小的集群,这里面有8个节点,每个节点都是标签化的,可以保证用户体验,提升用户体验率。我们跟Berkeley今年6月份推出的达到了相当的水平,我们有自己的特色,所以国内很多的大学,清华北大和天津大学还有深圳的大学都在这个平台上做企业的研究,包括用它开本科生的课程。


幻灯片31.JPG

标签可以用来做什么?我举几个例子,比如我们可以把传统的虚拟化层去掉,把它通过标签放到硬件里,假如没有容器,我们就可以把整个系统做隔离,用红线在物理上隔离,这条红线还可以左右的移动,是可编程的。


还有一个例子,可以做性能的隔离。这个例子是在火苗系统上,是一个四核的平台,我们在上面如果运行一个单独的应用,会把所有的资源占掉,这个时候它的性能还是不错的,上面那条横线其实可以看到当时的请求是几个毫秒,我们把其他三个分区跑起来,跑不同的应用,把资源利用率提上去,就可以看到最左边的应用性能开始波动了,但是整个一些资源就开始竞争了,这个时候我们标签的机制进行隔离,我们把红色的应用实行90%的高速缓存,所以你可以看到占到将近90%,我们也把带宽做约束,使用更多的带宽,这样很快就可以看到它的性能不再波动了,开始往下降,回到原来单独运行的状态,而整个系统的利用率,实际上已经是比原来大大的提升了,因为你有其他三个应用在同时运行,所以这种方式我们就可以做到把利用率提升的情况下还可以保证在线应用的实时响应,所有都是开源的。


幻灯片34.JPG

今年我是被邀请到剑桥介绍标签化技术,因为ARM希望在他们的芯片里实现表现机制的隔离形式,我们本身成立了联盟,叫做中国开放指令生态联盟,是希望可以推动开源芯片的生态。

幻灯片36.JPG

未来的云计算,低熵云计算还有很多的挑战。一方面我们看到请求,很多应用的延迟需求是很高的,从毫秒级甚至到微秒级。我们希望云上有更多的用户用,很多的用户希望用python写程序,大家可以看到以一个写python程序的人,如果你不经过优化,这个程序和我由一个懂计算机系统的人,计算机体系结构芯片技术人写出来的程序差了六万多倍,这里面这么大的性能差异,我们可以是在云平台层次上优化和改进的,这是给我们提供了很多优化的空间。


幻灯片37.JPG

云计算还有很多的事情可以做,我们还有很多的空间可以挖掘,可以让用户体验更好。软件定义计算,可以解决我们系统的思路,希望能去定义实现智能云的设施,我们在每个层次都可以快速应用开发和部署,也可以实现智能定义的形式,包括智能自组合的操作等等。以上就是我跟大家分享的我们的想法,谢谢。



如何在 Kubernetes 之上架构应用?

piglei 发表了文章 • 0 个评论 • 1564 次浏览 • 2018-08-05 21:51 • 来自相关话题

# 简介 设计并运行一个兼顾可扩展性、可移植性和健壮性的应用是一件很有挑战的事情,尤其是当系统复杂度在不断增长时。应用或系统本身的架构极大的影响着其运行方式、对环境的依赖性,以及与相关组件的耦合强弱。当应用在一个高度分布式的环境中运行时,如果能在设 ...查看全部
# 简介
设计并运行一个兼顾可扩展性、可移植性和健壮性的应用是一件很有挑战的事情,尤其是当系统复杂度在不断增长时。应用或系统本身的架构极大的影响着其运行方式、对环境的依赖性,以及与相关组件的耦合强弱。当应用在一个高度分布式的环境中运行时,如果能在设计阶段遵循特定模式,在运维阶段恪守特定实践,就可以帮助我们更好的应对那些最常出现的问题。

尽管软件设计模式和开发方法论可以帮助我们生产出满足恰当扩展性指标的应用,基础设施与运行环境也在影响着已部署系统的运维操作。像 DockerKubernetes 这些技术可以帮助团队打包、分发、部署以及在分布式环境中扩展应用。学习如何最好的驾驭这些工具,可以帮助你在管理应用时拥有更好的机动性、控制性和响应能力。

在这份指南里,我们将探讨一些你可能想采用的准则和模式,它们可以帮助你在 Kubernetes 上更好的扩展和管理你的工作集(workloads)。尽管在 Kubernetes 上可以运行各种各样的工作集,但是你的不同选择会影响运维难度和部署时的可选项。你如何架构和构建应用、如何将服务用容器打包、如何配置生命周期管理以及在 Kubernetes 上如何操作,每一个点都会影响你的体验。
# 为可扩展性做应用设计
当开发软件时,你所选用的模式与架构会被很多需求所影响。对于 Kubernetes 来说,它最重要的特征之一就是要求应用拥有水平扩展能力——通过调整应用副本数来分担负载以及提升可用性。这与垂直扩展不同,垂直扩展尝试使用同样的参数将应用部署到性能更强或更弱的服务器上。

比如,微服务架构是一种适合在集群中运行多个可扩展应用的软件设计模式。开发者们创建一些可组合的简单应用,它们通过良好定义的 REST 接口进行网络通信,而不是像更复杂的单体式应用那样通过程序内部机制通信。将单体式应用拆分为多个独立的单一功能组件后,我们可以独立的扩展每个功能组件。很多之前通常存在于应用层的组合与复杂度被转移到了运维领域,而它们刚好可以被像 Kubernetes 这样的平台搞定。

比特定的软件模式更进一步,云原生(cloud native)应用在设计之初就有一些额外的考量。云原生应用是遵循了微服务架构模式的程序,拥有内置的可恢复性、可观测性和可管理性,专门用于适应云集群平台提供的环境。

举例来说,云原生应用在被创造出时都带有健康度指标数据,当某个实例变得不健康时,平台可以根据指标数据来管理实例的生命周期。这些指标产生(也可以被导出)稳定的遥控数据来给运维人员告警,让他们可以依据这些数据做决策。应用被设计成可以应付常规的重启、失败、后端可用性变化以及高负载等各种情况,而不会损坏数据或者变得无法响应。
## 遵循 “12 法则应用”应用理论
在创建准备跑在云上的 web 应用时,有一个流行的方法论可以帮你关注到那些最重要的特征:“12 法则应用理论”( Twelve-Factor App)。它最初被编写出来,是为了帮助开发者和运维团队了解所有被设计成在云环境运行的 web 服务的共有核心特征,而对于那些将在 Kubernetes 这种集群环境中运行的应用,这个理论也非常适用。尽管单体式应用可以从这些建议中获益,围绕这些原则设计的微服务架构应用也会工作的非常好。

“12 法则”的一份简单摘要:

  1. 基准代码(Codebase):将你的所有代码都放在版本控制系统中(比如 Git 或者 Mercurial)。被部署的内容完全由基准代码决定。
  2. 依赖(Dependencies):应用依赖应该由基准代码全部显式管理起来,无论是用 vendor(指依赖代码和应用代码保存在一起),还是通过可由包管理软件解析安装的依赖配置文件的方式。
  3. 配置(Config):把应用配置参数与应用本身分开来,配置应该在部署环境中定义,而不是被嵌入到应用本身。
  4. 后端服务(Backing Services):本地或远程的依赖服务都应该被抽象为可通过网络访问的资源,连接细节应该在配置中定义。
  5. 构建、发布、运行(Build, release, run):应用的构建阶段应该完全与发布、运维阶段区分开来。构建阶段从应用源码创建出一个可执行包,发布阶段负责把可执行包和配置组合起来,然后在运行阶段执行这个发布版本。
  6. 进程(Processes):应用应该由不依赖任何本地状态存储的进程实现。状态应该被存储在第 4 个法则描述的后端服务中。
  7. 端口绑定(Port binding):应用应该原生绑定端口和监听连接。所有的路由和请求转发工作应该由外部处理。
  8. 并发(Concurrency):应用应该依赖于进程模型扩展。只需同时运行多份应用(可能分布在不同服务器上),就能实现不调整应用代码扩展的目的。
  9. 易处理(Disposability):进程应该可以被快速启动、优雅停止,而不产生任何严重的副作用。
  10. 开发环境与线上环境等价(Dev/prod parity):你的测试、预发布以及线上环境应该尽可能一致而且保持同步。环境间的差异有可能会导致兼容性问题和未经测试的配置突然出现。
  11. 日志(Logs):应用应该将日志输出到标准输出(stdout),然后由外部服务来决定最佳的处理方式。
  12. 管理进程(Admin processes):一次性管理进程应该和主进程代码一起发布,基于某个特定的发布版本运行。

依照“12 法则”所提供的指南,你可以使用完全适用于 Kubernetes 运行环境的模型来创建和运行应用。“12 法则”鼓励开发者们专注于他们应用的首要职责,考虑运维条件以及组件间的接口设计,并使用输入、输出和标准进程管理功能,最终以可被预见的方式将应用在 Kubernetes 中跑起来。
# 容器化应用组件
Kubernetes 使用容器在集群节点上运行隔离的打包应用程序。要在 Kubernetes 上运行,你的应用必须被封装在一个或者多个容器镜像中,并使用 Docker 这样的容器运行时执行。尽管容器化你的组件是 Kubernetes 的要求之一,但其实这个过程也帮助强化了刚刚谈到的“12法则应用”里的很多准则,从而让我们可以简单的扩展和管理应用。

举例来说,容器提供了应用环境与外部宿主机环境之间的隔离,提供了一个基于网络、面向服务的应用间通信方式,并且通常都是从环境变量读取配置、将日志写到标准输出与标准错误输出中。容器本身鼓励基于进程的并发策略,并且可以通过保持独立扩展性和捆绑运行时环境来帮助保持开发/线上环境一致性(#10 Dev/prod parity)。这些特性让你可以顺利打包应用,从而顺利的在 Kubernetes 上运行起来。
## 容器优化准则
因为容器技术的灵活性,我们有很多不同种封装应用的方式。但是在 Kubernetes 环境中,其中一些方式比其他方式工作的更好。

镜像构建(image building),是指你定义应用将如何在容器里被设置与运行的过程,绝大多数关于“如何容器化应用”的最佳实践都与镜像构建过程有关。通常来说,保持镜像尺寸小以及可组合会带来很多好处。在镜像升级时,通过保持构建步骤可管理以及复用现有镜像层,被优化过尺寸的的镜像可以减少在集群中启动一个新容器所需要的时间与资源。

当构建容器镜像时,尽最大努力将构建步骤与最终在生产环境运行的镜像区分开来是一个好的开始。构建软件通常需要额外的工具、花费更多时间,并且会生产出在不同容器里表现不同、或是在最终运行时环境里根本不需要的内容。将构建过程与运行时环境清晰分开的办法之一是使用 Docker 的“多阶段构建(multi-stage builds)” 特性。多阶段构建配置允许你为构建阶段和运行阶段设置不同的基础镜像。也就是说,你可以使用一个安装了所有构建工具的镜像来构建软件,然后将结果可执行软件包复制到一个精简过的、之后每次都会用到的镜像中。

有了这类功能后,基于最小化的父镜像来构建生产环境镜像通常会是个好主意。如果你想完全避免由 `ubuntu:16.04`(该镜像包含了一个完整的 Ubuntu 16.04 环境)这类 “Linux 发行版” 风格父镜像带来的臃肿,你可以尝试用 `scratch` - Docker 的最简基础镜像 - 来构建你的镜像。不过 `scratch` 基础镜像缺了一些核心工具,所以部分软件可能会因为环境问题而无法运行。另外一个方案是使用 Alpine Linux 的 `alpine` 镜像,该镜像提供了一个轻量但是拥有完整特性的 Linux 发行版。它作为一个稳定的最小基础环境获得了广泛的使用。

对于像 Python 或 Ruby 这种解释型编程语言来说,上面的例子会稍有变化。因为它们不存在“编译”阶段,而且在生产环境运行代码时一定需要有解释器。不过因为大家仍然追求精简的镜像,所以 Docker Hub 上还是有很多基于 Alpine Linux 构建的各语言优化版镜像。对于解释型语言来说,使用更小镜像带来的好处和编译型语言差不多:在开始正式工作前,Kubernetes 能够在新节点上快速拉取到所有必须的容器镜像。
# 在 Pod 和“容器”之间做选择
虽然你的应用必须被“容器”化后才能在 Kubernetes 上跑起来,但 pods(译注:因为 pod、service、ingress 这类资源名称不适合翻译为中文,此处及后面均使用英文原文) 才是 Kubernetes 能直接管理的最小抽象单位。pod 是由一个或更多紧密关联的容器组合在一起的 Kubernetes 对象。同一个 pod 里的所有容器共享同一生命周期且作为一个独立单位被管理。比如,这些容器总是被调度到同一个节点上、一起被启动或停止,同时共享 IP 和文件系统这类资源。

一开始,找到将应用拆分为 pods 和容器的最佳方式会比较困难。所以,了解 Kubernetes 是如何处理这些对象,以及每个抽象层为你的系统带来了什么变得非常重要。下面这些事项可以帮助你在使用这些抽象概念封装应用时,找到一些自然的边界点。

寻找自然开发边界是为你的容器决定有效范围的手段之一。如果你的系统采用了微服务架构,所有容器都经过良好设计、被频繁构建,各自负责不同的独立功能,并且可以被经常用到不同场景中。这个程度的抽象可以让你的团队通过容器镜像来发布变更,然后将这个新功能发布到所有使用了这个镜像的环境中去。应用可以通过组合很多容器来构建,这些容器里的每一个都实现了特定的功能,但是又不能独立成事。

与上面相反,当考虑的是系统中的哪些部分可以从独立管理中获益最多时,我们常常会用 pods。Kubernetes 使用 pods 作为它面向用户的最小抽象,因此它们是 Kubernetes API 和工具可以直接交互与控制的最原生单位。你可以启动、停止或者重启 pods,或者使用基于 pods 建立的更高级别抽象来引入副本集和生命周期管理这些特性。Kubernetes 不允许你单独管理一个 Pod 里的不同容器,所以如果某些容器可以从独立管理中获得好处,那么你就不应该把它们分到到一个组里。

因为 Kubernetes 的很多特性和抽象概念都直接和 pods 打交道,所以把那些应该被一起扩缩容的东西捆绑到一个 pod 里、应该被分开扩缩容的分到不同 pod 中是很有道理的。举例来说,将前端 web 服务器和应用服务放到不同 pods 里让你可以根据需求单独对每一层进行扩缩容。不过,有时候把 web 服务器和数据库适配层放在同一个 pod 里也说得过去,如果那个适配器为 web 服务器提供了它正常运行所需的基本功能的话。
## 通过和支撑性容器捆绑到一起来增强 Pod 功能
了解了上面这点后,到底什么类型的容器应该被捆绑到同一个 pod 里呢?通常来说,pod 里的主容器负责提供 pod 的核心功能,但是我们可以定义附加容器来修改或者扩展那个主容器,或者帮助它适配到某个特定的部署环境中。

比如,在一个 web 服务器 pod 中,可能会存在一个 Nginx 容器来监听请求和托管静态内容,而这些静态内容则是由另外一个容器来监听项目变动并更新的。虽然把这两个组件打包到同一个容器里的主意听上去不错,但是把它们作为独立的容器来实现是有很多好处的。nginx 容器和内容拉取容器都可以独立的在不同情景中使用。它们可以由不同的团队维护并分别开发,达到将行为通用化来与不同的容器协同工作的目的。

Brendan Burns 和 David Oppenheimer 在他们关于“基于容器的分布式系统设计模式”的论文中定义了三种打包支撑性容器的主要模式。它们代表了一些最常见的将容器打包到 pod 里的用例:

  • Sidecar(边车模式):在这个模式中,次要容器扩展和增强了主容器的核心功能。这个模式涉及在一个独立容器里执行非标准或工具功能。举例来说,某个转发日志或者监听配置值改动的容器可以扩展某个 pod 的功能,而不会改动它的主要关注点。
  • Ambassador(大使模式):Ambassador 模式使用一个支援性容器来为主容器完成远程资源的抽象。主容器直接连接到 Ambassador 容器,而 Ambassador 容器反过来连接到可能很复杂的外部资源池 - 比如说一个分布式 Redis 集群 - 并完成资源抽象。主容器可以完成连接外部服务,而不必知道或者关心它们实际的部署环境。
  • Adaptor(适配器模式):Adaptor 模式被用来翻译主容器的数据、协议或是所使用的接口,来与外部用户的期望标准对齐。Adaptor 容器也可以统一化中心服务的访问入口,即便它们服务的用户原本只支持互不兼容的接口规范。

# 使用 Configmaps 和 Secrets 来保存配置
尽管应用配置可以被一起打包进容器镜像里,但是让你的组件在运行时保持可被配置能更好支持多环境部署以及提供更多管理灵活性。为了管理运行时的配置参数,Kubernetes 提供了两个对象:ConfigMapsSecrets

ConfigMaps 是一种用于保存可在运行时暴露给 pods 和其他对象的数据的机制。保存在 ConfigMaps 里的数据可以通过环境变量使用,或是作为文件挂载到 pod 中。通过将应用设计成从这些位置读取配置后,你可以在应用运行时使用 ConfigMaps 注入配置,并以此来修改组件行为而不用重新构建整个容器镜像。

Secrets 是一种类似的 Kubernetes 对象类型,它主要被用来安全的保存敏感数据,并根据需要选择性的的允许 pods 或是其他组件访问。Secrets 是一种方便的往应用传递敏感内容的方式,它不必像普通配置一样将这些内容用纯文本存储在可以被轻易访问到的地方。从功能性上讲,它们的工作方式和 ConfigMaps 几乎完全一致,所以应用可以用完全一样的方式从二者中获取数据。

ConfigMaps 和 Secrets 可以帮你避免将配置内容直接放在 Kubernetes 对象定义中。你可以只映射配置的键名而不是值,这样可以允许你通过修改 CongfigMap 或 Secret 来动态更新配置。这使你可以修改线上 pod 和其他 kubernetes 对象的运行时行为,而不用修改这些资源本身的定义。
# 实现“就绪检测(Readiness)”与“存活检测(Liveness)”探针
Kubernetes 包含了非常多用来管理组件生命周期的开箱即用功能,它们可以确保你的应用始终保持健康和可用状态。不过,为了利用好这些特性,Kubernetes 必须要理解它应该如何监控和解释你的应用健康情况。为此,Kubernetes 允许你定义“就绪检测探针(Readiness Probe)”与“存活检测探针(Liveness Probe)”。

“存活检测探针”允许 Kubernetes 来确定某个容器里的应用是否处于存活与运行状态。Kubernetes 可以在容器内周期性的执行一些命令来检查基本的应用行为,或者可以往特定地址发送 HTTP / TCP 网络请求来判断进程是否可用、响应是否符合预期。如果某个“存活探测指针”失败了,Kubernetes 将会重启容器来尝试恢复整个 pod 的功能。

“就绪检测探针”是一个类似的工具,它主要用来判断某个 Pod 是否已经准备好接受请求流量了。在容器应用完全就绪,可以接受客户端请求前,它们可能需要执行一些初始化过程,或者当接到新配置时需要重新加载进程。当一个“就绪检测探针”失败后,Kubernetes 会暂停往这个 Pod 发送请求,而不是重启它。这使得 Pod 可以完成自身的初始化或者维护任务,而不会影响到整个组的整体健康状况。

通过结合使用“存活检测探针”与“就绪检测探针”,你可以控制 Kubernetes 自动重启 pods 或是将它们从后端服务组里剔除。通过配置基础设施来利用好这些特性,你可以让 Kubernetes 来管理应用的可用性和健康状况,而无需执行额外的运维工作。
# 使用 Deployments 来管理扩展性与可用性
在早些时候讨论 Pod 设计基础时,我们提到其他 Kubernetes 对象会建立在 Pod 的基础上来提供更高级的功能。而 deployment 这个复合对象,可能是被定义和操作的最多次的 Kubernetes 对象。

Deployments 是一种复合对象,它通过建立在其他 Kubernetes 基础对象之上来提供额外功能。它们为一类名为 replicasets 的中间对象添加了生命周期管理功能,比如可以实施“滚动升级(Rolling updates)”、回滚到旧版本、以及在不同状态间转换的能力。这些 replicasets 允许你定义 pod 模板并根据它快速拉起和管理多份基于这个模板的副本。这可以帮助你方便的扩展基础设施、管理可用性要求,并在故障发生时自动重启 Pods。

这些额外特性为相对简单的 pod 抽象提供了一个管理框架和自我修复能力。尽管你定义的工作集最终还是由 pods 单元来承载,但是它们却不是你通常应该最多配置和管理的单位。相反,当 pods 由 deployments 这种更高级对象配置时,应该把它们当做可以稳定运行应用的基础构建块来考虑。
# 创建 Services 与 Ingress 规则来管理到应用层的访问
Deployment 允许你配置和管理可互换的 Pod 集合,以扩展应用以及满足用户需求。但是,如何将请求流量路由到这些 pods 则是例外一码事了。鉴于 pods 会在滚动升级的过程中被换出、重启,或者因为机器故障发生转移,之前被分配给这个运行组的网络地址也会发生变化。Kubernetes services 通过维护动态 pods 资源池以及管理各基础设施层的访问权限,来帮助你管理这部分复杂性。

在 Kuberntes 里,services 是控制流量如何被路由到多批 pods 的机制。无论是为外部客户转发流量,还是管理多个内部组件之间的连接,services 允许你来控制流量该如何流动。然后,Kubernetes 将更新和维护将连接转发到相关 pods 的所有必需信息,即使环境或网络条件发生变化也一样。
## 从内部访问 Services
为了有效的使用 services,你首先应该确定每组 pods 服务的目标用户是谁。如果你的 service 只会被部署在同一个 Kubernetes 集群的其他应用所使用,那么 ClusterIP 类型允许你使用一个仅在集群内部可路由的固定 IP 地址来访问一组 pods。所有部署在集群上的对象都可以通过直接往这个 service IP 地址发送请求来与这组 pod 副本通信。这是最简单的 service 类型,很适合在内部应用层使用。

Kubernetes 提供了可选的 DNS 插件来为 services 提供名字解析服务。这允许 pods 和其他对象可以使用域名来代替 IP 地址进行通信。这套机制不会显著改动 service 的用法,但基于域名的标识符可以使连接组件和定义服务间交互变得更简单,而不需要提前知道 service IP 地址。
## 将 Services 向公网开放
如果你的应用需要被公网访问,那么 “负载均衡器(load balancer)”类型的 service 通常会是你的最佳选择。它会使用应用所在的特定云提供商 API 来配置一个负载均衡器,由这个负载均衡器通过一个公网 IP 来服务所有到 service pods 的流量。这种方式提供了一个到集群内部网络的可控网络通道,从而将外部流量引入到你的 service pods 中。

由于“负载均衡器”类型会为每一个 service 都创建一个负载均衡器,因此用这种方式来暴露 Kubernetes 服务可能会有些昂贵。为了帮助缓解这个问题,我们可以使用 Kubernetes ingress 对象来描述如何基于预定规则集来将不同类型的请求路由到不同 services。例如,发往 “example.com” 的请求可能会被指向到 service A,而往 “sammytheshark.com” 的请求可能会被路由到 service B。Ingress 对象提供了一种描述如何基于预定义模式将混合请求流分别路由到它们的目标 services 的方式。

Ingress 规则必须由一个 ingress controller 来解析,它通常是某种负载均衡器(比如 Nginx),以 pod 的方式部署在集群中,它实现了 ingress 规则并基于规则将流量分发到 Kubernetes serices 上。目前,ingress 资源对象定义仍然处于 beta 阶段,但是市面上已经有好几个能工作的具体实现了,它们可以帮助集群所有者最小化需要运行的外部负载均衡器数量。
# 使用声明式语法来管理 Kubernetes 状态
Kubernetes 在定义和管理部署到集群的资源方面提供了很大灵活性。使用 `kubectl` 这样的工具,你可以命令式的定义一次性资源并将其快速部署到集群中。虽然在学习 Kubernetes 阶段,这个方法对于快速部署资源可能很有用,但这种方式也存在很多缺点,不适合长周期的生产环境管理。

命令式管理方式的最大问题之一就是它不保存你往集群部署过的变更记录。这使得故障时恢复和跟踪系统内运维变更操作变得非常困难,甚至不可能。

幸运的是,Kubernetes 提供了另外一种声明式的语法,它允许你使用文本文件来完整定义资源,并随后使用 `kubectl` 命令应用这些配置或更改。将这些配置文件保存在版本控制系统里,是监控变更以及与你的公司内其他部分的审阅过程集成的一种简单方式。基于文件的管理方式也让将已有模式适配到新资源时变得简单,只需要复制然后修改现有资源定义即可。将 Kubernetes 对象定义保存在版本化目录里允许你维护集群在每个时间节点的期望集群状态快照。当你需要进行故障恢复、迁移,或是追踪系统里某些意料之外的变更时,这些内容的价值是不可估量的。
# 总结
管理运行应用的基础设施,并学习如何最好的利用这些现代化编排系统提供的特性,这些事情可能会令人望而生畏。但是,只有当你的开发与运维过程与这些工具的构建概念一致时,Kubernetes 系统、容器技术提供的优势才能更好的体现出来。遵循 Kubernetes 最擅长的那些模式来架构你的系统,以及了解特定功能如何能缓解由高度复杂的部署带来的挑战,可以帮助改善你运行平台时的体验。

原文链接:architecting-applications-for-kubernetes(翻译:朱雷(piglei))

时速云企业级容器PaaS技术沙龙 第八期

tenxcloud 发表了文章 • 1 个评论 • 1037 次浏览 • 2018-04-02 16:11 • 来自相关话题

目前,基于 Kubernetes 的容器 PaaS 在企业级数字化转型中扮演了越来越重要的角色。而 Kubernetes 在开源容器编排技术里独占鳌头,并在市场中迅速升温,越来越多的企业开始使用基于 Kubernetes 技术构建企业级 PaaS 平台,从而加 ...查看全部
目前,基于 Kubernetes 的容器 PaaS 在企业级数字化转型中扮演了越来越重要的角色。而 Kubernetes 在开源容器编排技术里独占鳌头,并在市场中迅速升温,越来越多的企业开始使用基于 Kubernetes 技术构建企业级 PaaS 平台,从而加速业务应用的交付、提高运维效率、实现微服务架构升级。可以预见,未来几年企业级容器 PaaS 市场将呈现出持续的爆发式增长。

那么,对于还未使用这一技术,或者尚在探索阶段的企业和开发者来说,如何应用好它,如何构建企业级 PaaS 平台,如何把 Kubernetes 技术与具体业务结合?未来又有怎样的发展趋势?我们将在本次沙龙为大家带来一些经验分享。

时速云( TenxCloud )自 2014 年成立之日起,就根植于技术社区。迄今为止时速云已在北京、上海、深圳等地成功举办 7 期 Docker&Kubernetes 技术沙龙,得到众多企业及开发者的大力支持。

2018 年 4 月 14 日,时速云( TenxCloud )诚邀您参加第八期企业级容器 PaaS 技术沙龙。本次沙龙由时速云主办,阿里云和青云协办,届时,您将获得与来自时速云、阿里云、青云的技术大咖们面对面交流的机会,希望大家踊跃报名。

时间地点:

时间:2018 年 04 月 14 日 13:30-17:30 地点:北京市海淀区海淀大街 27 号-天使汇极客咖啡 2 层

活动议程:

13:30-14:00 沙龙签到
14:00-14:40 时速云 王磊 《 Kubernetes Native DevOps 实践》
14:40-15:20 青云 于爽 《容器及 k8s 实践经验分享》
15:20-15:50 茶歇
15:50-16:30 时速云 魏巍 《 Calico 网络在容器云平台上的实践与思考》
16:30-17:10 阿里云 徐晓舟 《 Kubernetes 助力企业敏捷开发》
17:10-17:30 提问环节

邀请嘉宾:

于爽( Calvin Yu ),QingCloud 容器研发工程师,负责青云 QingCloud PaaS 平台容器相关服务的设计与研发工作。 演讲主题:《容器及 k8s 实践经验分享》

徐晓舟,阿里云资深开发工程师,2015 年加入阿里巴巴。 主要负责阿里云容器服务公有云管控系统开发的开发工作,以及私有云容器平台的部署和管控。 演讲主题:《 Kubernetes 助力企业敏捷开发》

王磊,时速云联合创始人 - CTO。原 IBM 中国开发实验室资深软件工程师,IBM BPM 产品开发组 Team Lead,曾参与 IBM 服务器、中间件、Bluemix 平台等多个产品的设计与开发工作 演讲主题:《 Kubernetes Native DevOps 实践》

魏巍,时速云容器架构负责人 - Architect,Certified Kubernetes Administrator。 演讲主题:《 Calico 网络在容器云平台上的实践与思考》

报名方式: 本次技术沙龙采用报名制,全程免费,前 100 名签到者可获得精美礼品。 请在 http://cn.mikecrm.com/QNfD0m8 正确填写即可报名。在沙龙前我们会发送提醒邮件,请您注意查收。 诚邀广大技术爱好者莅临参加!

基于Helm和Operator的K8S应用管理

Rancher 发表了文章 • 0 个评论 • 2487 次浏览 • 2018-03-08 13:07 • 来自相关话题

大家好,今天我们分享的内容是基于Helm和Operator的K8S应用管理。 我们知道,Kubernetes基于服务粒度提供了多种资源描述类型。描述一个应用系统尤其是微服务架构系统,需要组合使用大量的Kubernetes资源。针对 ...查看全部
大家好,今天我们分享的内容是基于Helm和Operator的K8S应用管理。

我们知道,Kubernetes基于服务粒度提供了多种资源描述类型。描述一个应用系统尤其是微服务架构系统,需要组合使用大量的Kubernetes资源。针对有状态应用,常常还需要复杂的运维管理操作以及更多的领域知识。

今晚的分享就将介绍如何用Helm这一Kubernetes应用包管理的社区主导方案来简化应用的部署管理,如何制作应用模板以及打造Kubernetes版应用商店,以及如何利用operator自动化应用的运维。


----------


我们知道在K8S社区里面,根据不同的领域,分成了不同的兴趣小组,英文叫SIG。今晚的话题属于APP这个领域。它们是为了解决K8S的应用管理里面的一些问题而生的。

一、Helm
让我们从零开始吧。比如说我们现在已经部署了一个K8S的集群。不管是用GKE或者是EKS,都不是难事,因为现在部署K8S已经不是以前那么麻烦的事情了。然后我们做了应用的容器化。接下来,我们要试着去把我们的应用部署到K8S上面去。
其实在K8S里面,资源对象是很多的:



对于一些微服务架构来说,会有不同的服务在上面运行,你可能要管理诸如deployment、service、有状态的Statefulset、权限的控制等等。你会发现,部署应用后还会有很多其他关联的东西以及你需要考虑的点:比如说你的不同团队,要去管理这样一个应用,从开发到测试再到生产,在不同的环境中,同样一套东西可能都需要不同的配置。例如,你在开发的时候,不需要用到PV,而是用一些暂时的存储就行了;但是在生产环境中,你必须要持久存储;并且你可能会在团队之间做共享,然后去存档。

另外,你不仅仅要部署这个应用资源,你还要去管理其生命周期,包括升级、更新换代、后续的删除等。我们知道,K8S里面的deployment是有版本管理的,但是从整个应用或某个应用模块来考虑的话,除了deployment,可能还会有其他的configmap之类的去跟其关联。这时我们会想,是否有这样一个工具可以在更上层的维度去管理这些应用呢?这个时候我们就有了社区的一个包管理工具:Helm。

我们知道K8S的意思是舵手,即掌控船舵的那个人。而Helm其实就是那个舵。

在Helm里面,它的一个应用包叫Charts,Charts其实是航海图的意思。它是什么东西呢?

它其实就是一个应用的定义描述。里面包括了这个应用的一些元数据,以及该应用的K8S资源定义的模板及其配置。其次,Charts还可以包括一些文档的说明,这些可以存储在chart的仓库里面。
怎么用Helm这个工具呢?Helm其实就是一个二进制工具。你只要把它下载下来,已经配置好了kubeconfig的一些相关配置信息,就可以在K8S中做应用的部署和管理了。
用Helm可以做什么事情呢?其实Helm分为服务端跟客户端两部分,你在helm init之后,它会把一个叫做Tiller的服务端,部署在K8S里面。这个服务端可以帮你管理Helm Chart应用包的一个完整生命周期。

Release == Chart 的安装实例:



接着说说Helm Chart。它本质上是一个应用包,你可以把它理解成dpkg或者像rpm这样的包。只不过,它是基于K8S领域的一个应用包的概念。你可以对同一个chart包进行多次部署,每次安装它都会产生一个Release。这个Release相当于一个chart中的安装实例。

现在我们已经把Tiller部署进去了,那么就可以去做我们应用的管理了:

$ helm install

```
# (stable/mariadb, ./nginx-1.2.3.tgz, ./nginx, https://example.com/charts/nginx-1.2.3.tgz)
$ helm upgrade
$ helm delete
```

关于一些常用的命令例如安装一个应用包,可以用install,它其实是可以支持不同格式的:比如说本地的一些chart包,或者说你的远程仓库路径。
对于应用的更新,用Helm upgrade。
如果要删除的话,就用Helm Delete。
Helm的一个Release会生成对应的Configmap,由它去存储这个Release的信息,并存在K8S里面。它相当于把应用的一个生命周期的迭代,直接跟K8S去做关联,哪怕Tiller挂了,但只要你的配置信息还在,这个应用的发布和迭代历程不会丢失:例如想回滚到以前的版本,或者是查看它的升级路径等。
接下来我们看一个chart的结构。

$ helm create demoapp



用Helm create的话,它会提供一个大概的框架,你可以去创建自己的一个应用。比如说这个应用就叫做Demoapp,里面会有如下内容:



其中最核心的是templates,即模板化的K8S manifests文件,这里面会包括资源的定义,例如deployment、service等。现在我们create出来的是一个默认的、用一个nginx deployment去部署的应用。

它本质上就是一个Go的template模板。Helm在Go template模板的基础上,还会增加很多东西。如一些自定义的元数据信息、扩展的库以及一些类似于编程形式的工作流,例如条件语句、管道等等。这些东西都会使得我们的模板变得非常丰富。
有了模板,我们怎么把我们的配置融入进去呢?用的就是这个values文件。
这两部分内容其实就是chart的核心功能。





这个deployment,就是一个Go template的模板。里面可以定义一些预设的配置变量。这些变量就是从values文件中读取出来的。这样一来,我们就有了一个应用包的模板,可以用不同的配置将这个应用包部署在不同的环境中去。
除此之外,在Helm install/upgrade时候,可以使用不同的value。

配置选项:




```
$ helm install --set image.tag=latest ./demoapp
$ helm install -f stagingvalues.yaml ./demoapp
```

比如说你可以set某个单独的变量,你可以用整个File去做一个部署,它会用你现在的配置覆盖掉它的默认配置。因此我们可以在不同的团队之间,直接用不同的配置文件,并用同样的应用包去做应用管理。

Chart.yaml即chart的元数据,描述的就是这个chart包的信息。




另外还有一些文档的说明,例如NOTES.txt,一般放在templates里面,它是在你安装或者说你察看这个部署详情之时(helm status),自动列出来的。通常会放一些部署了的应用和如何访问等一些描述性的信息。



除了模板以外,Helm chart的另一个作用就是管理依赖。



比如说你部署一个Wordpress,它可以依赖一些数据库服务。你可以把数据库服务作为一个chart形式,放在一个依赖的目录下面。这样的话应用之间的依赖管理就可以做的很方便了。
假如现在已经创建了我们自己的应用包,想要有一个仓库去管理这个包,在团队之间共享应该怎么做?

chart的仓库其实就是一个HTTP服务器。只要你把你的chart以及它的索引文件放到上面,在Helm install的时候,就可以通过上面的路径去拿。

Helm工具本身也提供一个简单的指令,叫Helm serve,帮你去做一个开发调试用的仓库。

例如 https://example.com/charts 的仓库目录结构:



关于 Helm,社区版其实已经有了很多的应用包,一般放在K8S下面的一些项目中,比如安装Helm时候,它默认就有一个Stable的项目。里面会有各种各样的应用包。

Stable和incubator chart 仓库:https://github.com/kubernetes/charts

另外,社区版还会提供类似于Rancher Catalog应用商店的这样一个概念的UI,你可以在这上面做管理。它叫Monocular,即单筒望远镜的意思,这些项目的开发都非常的活跃,一直在随着K8S的迭代做着更新。

Monocular: chart的UI管理项目:https://github.com/kubernetes-helm/monocular



那么怎么去部署K8S版的应用商店呢?其实也非常简单。因为有了Helm之后,你只要使用Helm install这个Monocular,先把它的仓库加进来,再install一下,就可以把这个应用部署到你的K8S集群之中了。它其实也是利用了Helm Tiller去做部署。我们可以在上面去搜索一些chart,管理你的仓库,例如官方的stable,或者是incubator里面的一些项目。



你也可以管理一些已经部署的应用。比如说你要搜索一个应用,点一下部署,就可以把它部署上去了。不过这其中还有很多亟待完善的东西,比如这里的部署不能配置各种不同的参数,它只能输入namespace。其次,里面的一些管理依然存在局限性,比如不能很方便地在UI上做更新。

围绕Helm chart我们也会跟一些公有云厂商有相关的合作。因为Helm chart的好处就是:一个应用包可以在多个地方部署。比如公有云的服务,可以基于它去实现应用的编排和管理,把一个服务便利地提供给不同的用户。Rancher也会在2.0的应用商店中加入对helm chart的支持,希望帮助用户在方便利用已有模板的同时提供良好的体验。

在stable的仓库里面已经有很多chart,其实并不是特别完善,还有很多应用是可以补充和增强的。就我们的实践经验来说,什么都可以chart化,不管是分布式的数据库集群,还是并行计算框架,都可以以这样的形式在K8S上部署和管理起来。
另外一点就是Helm是插件化的,helm的插件有Helm-templates, helm-github,等等。
比如你在Helm install的时候,它可以调用插件去做扩展。它没有官方的仓库,但是已经有一些功能可用。其实是把Restless/release的信息以及你的chart信息以及Tiller的连接信息交给插件去处理。Helm本身不管插件是用什么形式去实现的,只要它是应用包,则对传入的这些参数做它自己的处理就行。

Helm的好处,大概就有这些:
•利用已有的Chart快速部署进行实验
•创建自定义Chart,方便地在团队间共享
•便于管理应用的生命周期
•便于应用的依赖管理和重用
•将K8S集群作为应用发布协作中心

二、Operator
我们接下来说说Operator。为什么讲Operator呢?Operator其实并不是一个工具,而是为了解决一个问题而存在的一个思路。什么问题?就是我们在管理应用时,会遇到无状态和有状态的应用。管理无状态的应用是相对来说比较简单的,但是有状态的应用则比较复杂。在Helm chart的stable仓库里面,很多数据库的chart其实是单节点的,因为分布式的数据库做起来会较为麻烦。

Operator的理念是希望注入领域知识,用软件管理复杂的应用。例如对于有状态应用来说,每一个东西都不一样,都可能需要你有专业的知识去处理。对于不同的数据库服务,扩容缩容以及备份等方式各有区别。能不能利用K8S便捷的特性去把这些复杂的东西简单化呢?这就是Operator想做的事情。
以无状态应用来说,把它做成一个Scale UP的话是比较简单的:扩充一下它的数量就行了。





接着在deployment或者是说ReplicaSet的controller中,会去判断它当前的状态,并向目标状态进行迁移。对有状态的应用来说,我们常常需要考虑很多复杂的事情,包括升级、配置更新、备份、灾难恢复、Scale调整数量等等,有时相当于将整个配置刷一遍,甚至可能要重启一些服务。

比如像Zookeeper315以前不能实时更新集群状态,想要扩容非常麻烦,可能需要把整个节点重启一轮。有些数据库可能方便一点,到master那里注册一下就好。因此每个服务都会有它自己的特点。
拿etcd来说,它是K8S里面主要的存储。
如果对它做一个Scale up的话,需要往集群中添加一些新节点的连接信息,从而获取到集群的不同Member的配置连接。然后用它的集群信息去启动一个新的etcd节点。

如果有了etcd Operator,会怎么样?

Operator其实是CoreOS布道的东西。CoreOS给社区出了几个开源的Operator,包括etcd,那么如何在这种情况下去扩容一个etcd集群?
首先可以以deployment的形式把etcd Operator部署到K8S中。
部署完这个Operator之后,想要部署一个etcd的集群,其实很方便。因为不需要再去管理这个集群的配置信息了,你只要告诉我,你需要多少的节点,你需要什么版本的etcd,然后创建这样一个自定义的资源,Operator会监听你的需求,帮你创建出配置信息来。

$ kubectl create –f etcd-cluster.yaml


要扩容的话也很简单,只要更新数量(比如从3改到5),再apply一下,它同样会监听这个自定义资源的变动,去做对应的更新。

$ kubectl apply -f upgrade-example.yaml


这样就相当于把以前需要运维人员去处理集群的一些工作全部都交付给Operator去完成了。
如何做到的呢?即应用了K8S的一个扩展性的API——CRD(在以前称为第三方资源)。

在部署了一个etcd Operator之后,通过kubernetes API去管理和维护目标的应用状态。本质上走的就是K8S里面的Controller的模式。K8S Controller会对它的resource做这样的一个管理:去监听或者是说检查它预期的状态,然后跟当前的状态作对比。如果其中它会有一些差异的话,它会去做对应的更新。

Kubernetes Controller 模式:



etcd的做法是在拉起一个etcd Operator的时候,创建一个叫etcd cluster的自定义资源,监听应用的变化。比如你的声明你的更新,它都会去产生对应的一个事件,去做对应的更新,将你的etcd集群维护在这样的状态。
除了etcd以外,社区比如还有普罗米修斯Operator都可以以这种方便的形式,去帮你管理一些有状态的应用。
值得一提的是,Rancher2.0广泛采用了Kubernetes-native的Controller模式,去管理应用负载乃至K8S集群,调侃地说,是个Kubernetes operator。

三、Helm和Operator的对比
这两个东西讲完了,我们来对比一下二者吧。

Operator本质上是针对特定的场景去做有状态服务,或者说针对拥有复杂应用的应用场景去简化其运维管理的工具。Helm的话,它其实是一个比较普适的工具,想法也很简单,就是把你的K8S资源模板化,方便共享,然后在不同的配置中重用。

其实Operator做的东西Helm大部分也可以做。用Operator去监控更新etcd的集群状态,也可以用定制的Chart做同样的事情。只不过你可能需要一些更复杂的处理而已,例如在etcd没有建立起来时候,你可能需要一些init Container去做配置的更新,去检查状态,然后把这个节点用对应的信息给拉起来。删除的时候,则加一些PostHook去做一些处理。所以说Helm是一个更加普适的工具。两者甚至可以结合使用,比如stable仓库里就有etcd-operator chart。
就个人理解来说,在K8S这个庞然大物之上,他们两者都诞生于简单但自然的想法,helm是为了配置分离,operator则是针对复杂应用的自动化管理。

我今天分享的内容就到这里,我们可以在QA环节继续交流。

QA环节
Q1:像Rancher有自带的应用商店Catalog,那Helm是相当于K8S的应用商店吗?
A1:是的,Rancher大概是在早期版本、Rancher 1.3开始支持Helm了。用户在Rancher部署K8S的时候,Rancher会把Helm工具都给装好给用户使用。现在的Rancher在K8S里面是没有应用商店的,我们就是考虑到Helm社区很活跃与成熟了,用户可以直接用Helm这个工具,所以K8S里面的应用商店其实是拿掉了的。Rancher 1.x版本,用户使用helm chart并没有cattle catalog那么好,不过2.0里这一点就极大改善了。

Q2:如何将本地的chart包push到远程仓库?
A2:chart repository就是普通的http web 服务器带特定的index文件,把chart包按对应格式传到host的目录就可以了,具体可以参考https://docs.helm.sh/developing_charts/#the-chart-repository-guide

Q3:想添加本地某个目录(包含index.yaml)作为私有仓库该怎么做?
A3:最简单的用helm提供的serve命令。

Q4:helm是一个图形化管理工具吗?
A4:不是图形化管理工具,但是有对应的ui项目。

Q5:helm架构中的tiller是指什么?
A5:tiller就是部署在k8s中的服务端,实际执行部署更新等操作,你用的helm binary是client端会向它发请求

Q6:helm目前国内使用不是很方便,目前所有的charts都是放在google服务器的, 国内用什么好用的repository么?
A6:可以翻墙或者自己搭,我没怎么了解过国内的源(捂脸)

Q7:所以operator是一种管理有状态应用的软件架构模式?
A7:通常用作管理有状态应用,就是利用k8s的crd扩展及声明式定义的方式做应用管理的模式。

Q8:operator业界有通用框架吗?
A8:在k8s的世界就是controller模式那一套,可以参考之前的一篇go-client相关的文章:http://mp.weixin.qq.com/s/MHjuS21iIyV99-o5hESWCw

如若转载,请注明出处谢谢!
微信号:RancherLabs

盘点那些你可能错过的CNCF优秀开源项目

Rancher 发表了文章 • 0 个评论 • 1294 次浏览 • 2018-03-07 08:53 • 来自相关话题

自2015年成立以来,云原生计算基金会(CNCF)已经成为开源生态系统中最重要的推动者之一,特别是当涉及到影响容器和其他“云原生”技术的工具时。CNCF成立的目的是促进和组织与大型行业趋势相关的项目,包括容器化、编排和微服务架构。自那以后,CNCF已经增加了1 ...查看全部
自2015年成立以来,云原生计算基金会(CNCF)已经成为开源生态系统中最重要的推动者之一,特别是当涉及到影响容器和其他“云原生”技术的工具时。CNCF成立的目的是促进和组织与大型行业趋势相关的项目,包括容器化、编排和微服务架构。自那以后,CNCF已经增加了10个开源项目。
即使您从未听说过CNCF,一定也听说过比它更受欢迎的项目之一:Kubernetes容器编排平台,但是CNCF比Kubernetes要大得多。如果您想要了解容器和云计算领域的重要发展,可以看看下文中介绍的CNCF生态系统中其他值得关注的重要项目。


LINKERD
第一个是Linkerd,一个基于微服务的原生云应用程序的开源“服务网格”项目。
Linkerd背后的想法是:微服务固然很好,但是只有当你有一个好方法来连接它们、形成完整的应用程序时,微服务的好处才能够体现。如若不然,你的微服务应用程序就会变成一个笨重的移动部件,它们彼此也不能很好地结合在一起。
Linkerd是一个开源项目,旨在通过提供开发人员所说的“service mesh(服务网格)”来解决这一挑战。Linkerd的服务网格提供了一个方便可靠的接口,不同的服务可以交互运行。除了通过为连接服务提供简单的方式和一致的抽象层来简化程序员的工作之外,Linkerd还具备可伸缩性、高可用性和安全性等特点。该项目由Buoyant监管,于2017年初加入CNCF。

FLUENTD
度量只是微服务应用程序可见性难题的一个方面。集中化的日志则是另一个。
随着应用程序的数量和公司规模的增长(尤其是越来越多的服务被容器化),在一个地方收集、分析和查询结构化日志是非常重要的。
这就是Fluentd的初衷。Fluentd是一个日志收集器(类似于logstorage),通过它可以对日志进行过滤、清洁和路由到各种目的地。与其他日志收集器一样,Fluentd可以与各种核心和第三方输入及输出插件(如Elasticsearch插件、S3插件等)一起使用。
Fluentd还具有一定的内存存储和可靠性。从多个主机到Fluentd、接着到Elasticsearch集群的rsyslog文件的日志路径极其简洁,这一简单的例子也充分证明了使用Fluentd的益处所在。

OPENTRACING
值得关注的第三个项目是分布式跟踪。随着单体应用程序被分解为各种更小的服务,自然会有越来越多的数据在服务中传输,从前端传输到后端,从一个服务传输到另一个服务。但是,当一个具有各种依赖关系的公共应用程序突然出现延迟时,会发生什么情况呢?这就是分布式跟踪的由来。其核心在于,跟踪是通过不同的请求调用、线程和流程来传播元数据,并最终基于此元数据构建一个图表。
OpenTracing是一种跟踪标准,它是为响应分布式跟踪领域长期存在的问题而创建的——即,当一个公司的堆栈可能由大量第三方软件、操作系统和自定义应用程序组成的时候,如何协调跟踪?OpenTracing,一种标准化的跟踪程式,就是这一难题的解决方案。该项目为跨越(即计时操作)管理和进程间传播,提供了的仪器API的标准化服务。因此,用户可以轻松地切换到跟踪库或集中式跟踪系统(如Zipkin、Dapper等),无须复杂的配置,免去了很多麻烦。

GPRC
到目前为止,我们已经知道了如何部署、调度和了解云中的微服务。但是他们之间的交流方式是什么呢?
让我们来看看“远程程序调用(RPC)”。
远程程序调用的概念已经存在了一段时间了,它指的是一种模式,在这种模式中,函数被称为远程调用,通常在系统中使用,而不是基于RESTful服务的CRUD模型。
但是,gRPC指的是谷歌实现的远程程序调用,它利用了http/2和协议缓冲区。与基于jsf的RPC相比,gRPC已经被证明在数量级上更快,这使得它成为大型分布式平台的优秀选择。事实上,etcd(来自CoreOS的流行键值存储)和谷歌自己的BigTable都是gRPC!

RKT
最后一个值得关注的项目是rkt(也称为Rocket),一个容器运行时。尽管Docker的containerd运行时可能是以推广容器概念的容器为目的的运行时,但是Docker仍然是编排生态系统中常用的运行时,因此我们相信RKT在后期会变得越来越受欢迎。
两者之间的差异也是显而易见的。虽然Docker已经选择了在集群中打包,并由一个守护进程和通过REST API与保护进程通信的可执行程序组成,但是RKT要简单得多。它由一个简单的命令行工具组成,当给定一个镜像、一个规范格式和一个镜像发现机制时,RKT就能运行一个容器。
使用RKT,用户可以在配置容器运行时时避免像systemd这样的问题。此外,RKT不仅可以运行App Container format中的镜像,还可以运行标准的Docker镜像。
结论
我们正在一步步更快地向微服务架构的世界迈进,与此同时,越来越多的开源项目涌现,以期为那些真正想要做到“云原生”的用户服务。CNCF有大量优秀却未必广为人知的项目,本文只涵盖了其中一部分,建议您也可以多了解其他的项目,为未来储备:https://www.cncf.io

作者简介
Sneha Inguva是一位热心的软件工程师,目前正在DigitalOcean研发软件开发工具。在过去的几年里,她在各种各样的初创公司里工作过,并且对折衷垂直领域(教育、3D打印和赌场等)的软件构建和部署拥有独特的视角。

原文:http://rancher.com/cncf-projects-may-missed/

微信号:RancherLabs

腾讯云微计算实践:从Serverless说起,谈谈边缘计算的未来

腾讯云技术社区 发表了文章 • 0 个评论 • 1771 次浏览 • 2018-02-27 16:03 • 来自相关话题

欢迎大家前往[云+社区][1],获取更多腾讯海量技术实践干货哦~ 作者:黄文俊,腾讯云高级产品经理,曾经历过企业级存储、企业级容器平台等产品的架构与开发,对容器、微服务、无服务器、DevOps等都有浓厚兴趣。 > 由 ...查看全部
欢迎大家前往[云+社区][1],获取更多腾讯海量技术实践干货哦~

作者:黄文俊,腾讯云高级产品经理,曾经历过企业级存储、企业级容器平台等产品的架构与开发,对容器、微服务、无服务器、DevOps等都有浓厚兴趣。
> 由 腾讯云serverless团队 发布在 云+社区



本文整理自1月20日腾讯云微服务架构交流会。

Serverless是一个比较新的概念,2017年开始在行业内兴起,边缘计算则是一个更新的技术。那么Serverless在边缘计算中能产生的什么样的效果、产品以及形态并推进出来在大家面前呢?今天来为大家分享一下。

首先讲讲Serverless是什么?

下面这张图可以很清晰的看到,Serverless从架构上可以分成两部分。

  • 一是Backend as a Service,后端即服务,腾讯云上目前已经提供很多这类产品,例如COS对象存储、CMQ消息队列、CDN内容分发、CDB云数据库、API网关,这些产品更多的是承载数据的存储。
  • 二是Function as a Service,函数即服务,也是Serverless比较核心的技术点,腾讯云云函数就属于这种。






从Serverless或者云函数来看,更多是对用户的计算进行托管。用户将代码和配置提交到云函数平台上,此处的代码是指用户的一份代码或者代码包,配置,一个是指本身对于函数运行环境的配置,使用的是哪种环境、所需的内存、超时时间等;另一个是触发器的配置。因为整个函数即服务的运行方式是触发式运行,触发就需要有一个事件来源,而事件来源是和腾讯云其他产品进行关联后而产生。例如COS对象存储产品,它的关联就在COS的存储桶中,当用户上传一张图片或者删除一张图片时,就会产生一个事件,这个事件会触发云函数的运行;例如和API网关的对接,也可以作为事件来源,在用户的HTTP请求到达网关之后,API网关会把该请求作为事件转发给云函数,触发云函数的运行,云函数拿到请求之后进行处理,生成响应给到用户。





上图左侧,是代码和配置提交到云函数平台进行保存,真正事件产生后,针对每一个事件都会拉起一个函数实例,实现触发式运行;真正事件来临时,用户函数才会运行,用户代码运行时才有云函数代码的数据运算和费用计算。

因为函数本身是托管型的,用户本身无法感知到实例在哪里运行。云函数平台背后有个大的计算资源池,用户实例触发之后,我们会从资源池中随机选取可运行的位置,把用户的函数实例在对应位置上跑起来。因此整个调度过程,或者事件来临之后的函数扩缩容过程,都是由平台进行的。对用户来说,调度的粒度更细了,而且调度也都托管给平台了。





而从整个的计算过程来说,为什么会有这种产品的出现?对于传统的数据存储过程来说,数据产生后,更多会先把数据进行缓存或者存储,如以对象存储文件的形式保存,或者数据库中以结构化形式存储下来,再进行分析应用。有了函数服务产品后,我们可以有很大的加速,可以在事件产生的时候就立刻对数据进行处理,因此就变成了先处理,再对结果进行保存使用的过程。


那么,还能不能缩短中间数据产生到数据处理的传递过程?

对于传统应用来说,数据在用户那里产生,传到云上进行处理,再进行相应的存储。这里说的缩短距离实际是把处理过程更加靠近用户,靠近用户就可以认为是边缘计算的过程。并且这里的靠近用户指的并不是加速网络速度,而是更多把计算下发,放到更靠近用户的位置。

之前无论使用容器也好,或者使用主机也好,运算能力都是在云上提供,而边缘计算要做的事情是把运算能力下发到云之外去。

边缘计算的理念,就是把计算能力下发更靠近真正的用户,更加靠近设备这一端。


为什么会有这种需求的产生?

随着互联网以及物联网的迅速发展,接入的用户越来越多,设备也越来越多,在这种情况下,产生的数据量也越来越多。无论是个人用户,还是物联网接入设备,每时每刻都在产生大量的数据。数据不断增多的情况下,也同时要求我们对于用户的响应、设备响应越来越快,本身设备的计算能力也要越来越强。

10年前的一台PC都比不上现在一台智能手机的处理能力,设备的计算能力在越来越强的情况下,实现了把计算能力下发到更加边缘的位置的能力。


云函数目前在做的探索,从两方面出发。一是物联网方向,物联网主要是和设备打交道,实现设备上的边缘计算;从云函数本身的特点来讲,它属于触发型运算,真正数据产生之后才会拉起运算。云函数交由平台托管的调度,可以把云函数调度到用户设备上去,二把云函数调度到CDN的节点上去,虽然CDN可以认为是云的一部分,但CDN本身已经很靠近用户,CDN节点实际上已经在云的边缘。


接下来给大家做一个和物联网相关的效果演示。

先简单介绍一下几款设备,第一个是树莓派,熟悉物联网的同学一般都了解;第二个是光感的传感器,可以感测环境光,从中读取到环境光的流明值;第三个是LED灯。


目前这个设备已经跑起来了,它所做的事情是当环境光足够亮的情况下,LED灯就会暗掉,当环境光足够暗的情况下,LED灯会亮起来。演示过程可以看到,当我把光感器遮盖的时候,LED灯有一个亮起来的动作。目前的环境光和背景足够亮,当我打开的时候,因为光足够亮,所以LED灯会灭掉。

针对这个代码我做一个解释。首先大家可以看到目前在树莓派上跑的一段函数,已经下到树莓派上跑了,在网上看到的是线上的代码。接下来我会对代码进行修改,从代码中大家可以看到,当从传感器中读出的流明值足够大的时候,GPIO做拉高或者拉低的动作,目前是正常的表现。

刚刚我完成了一个修改,现在我要把代码下发到仪器上运行,同时把这里拉起,查看数值是否正确。下面不断刷新的就是传感器出来的流明值,目前传感器已经变化了,因为大家可以看到这个数值已经超过了200,LED灯是亮着的,当我把感光器遮盖以后,LED灯变暗,这是通过代码把行为做了反转的变化。

我们在目前的调试过程中也会做实际的设备调试,这里演示的就是真正把云函数下放到物理设备上进行执行的效果。

接下来讲的是目前云函数和用户协同推进的AI能力,用户数据只要在云上利用CVM、GPU服务器、腾讯TML机器学习,进行AI训练,得出相应的训练后模型,再把模型和外围的导入代码进行打包,放入云函数,或者是带有GPU的云函数,就可以对外提供AI的推理能力。用户真正使用AI的时候,从外面送过来一段用户需要推理的语音、文本或图像,在云函数中拉起训练模型,就可以对这段数据进行推理。


AI能力表面上看起来和边缘计算没有关系,其实不然。如果本身已经在物联网的边缘设计上具有了云函数的执行能力,那么是不是可以进一步考虑把AI能力下发到设备上去的,比如我们在云中进行数据的收集和训练,生成模型之后,利用模型更新云上的函数,然后可以利用一键下发把这种能力下发到设备中,使设备具备更强的AI能力。

通过这种方式可以让更多的设备接入AI能力,比如让家里的摄象头直接识别人脸,认识你的家人,或者让更多的医疗设备直接对医疗检查结果做出判断,识别疾病类型等。这些都将会是后期持续和各个物联网厂商进行摸索,往前推进的过程。


另外一个角度来说,我们为什么做CDN的边缘计算?CDN本身是把数据放到边缘去的一个过程,而边缘计算是为了把计算放到边缘去。为了更快的响应用户的操作需求,对于边缘传上来的数据进行更快的处理,这也是云函数对于边缘的探索。

对于边缘计算来说,云函数要做到的就是用户在云中能完成函数的编写、管理,在所需的位置把云函数下放各个位置运行和使用。

云函数未来在边缘计算中还会有大量的探索机会,CDN厂商、物联网厂商、硬件厂商等都将会有持续不断的合作发展,去探索尝试将边缘的物联网能力、边缘的AI能力、边缘CDN能力落地。

Q&A

Q:腾讯云Serverless可以自己部署吗?

A:自己部署有分两种,一种是把云函数部署到设备上的能力,一种是Agent的部署。Agent本身是需要用户自行部署到用户自有的设备上去的。而今天演示用的是树莓派,Agent不局限于树莓派,它可以在更强的服务器中运行,比如可以用到设备的GPU、设备的存储、文件等进行分析计算。



Q:我们想在自己内部部署一个类似的Serverless,腾讯云可以支持吗?

A:您说的是私有化部署,云函数本身没有考虑,腾讯云云函数管理整体是在云上的,边缘计算提供更多的是边缘的调度和计算能力,函数在云上配置后,调度到设备上运行,云函数本身对于设备上的数据读取全部由自己控制,读取不用走网络,因为执行的代码包已经下发到设备上去了,体现的是让计算更加靠近数据的理念。



Q:如果提前设置好代码下发到设备上去,AI也可以断网吗?

A:对,代码运行在你的设备上。两种情况,一种是我刚才演示的物联网的边缘计算。本身的代码包装下发到设备之后,在设备上运行,断网没有关系。
> 云函数本身也提供AI能力,在云上提供,所以在云上运行。
> 对于AI,云上产品化的速度会更快,目前腾讯云已经在为部分客户进行支持,云上的相关操作说明后续也会提供出来,大家可以在线体验AI能力。



Q:针对IoT这块腾讯云发布了没有?

A:这个还没有发布,还在产品化,目前也是和一些客户协同推进这个能力,物联网设备各种各样,包括底层的硬件环境,比如树莓派的ARM,或者X86,或者mips等平台,对于Linux里的内核功能,文件系统的支持,对于存储、内存、CPU的要求也在整理中。



Q:云函数能够被用于传统应用吗?

A:云函数的特性因为本身是触发式运行,短暂运行的方式,所以和传统的很多开发单体的运行方式不太一样,更多是偏向于新业务开发,或者是小的新业务上线,或者急需要弹性应用能力的使用,传统的可以做改造,但是到时候需要提供一些改造的建议。
效率提升更多是在业务开发的速度上,实际上对于业务运行环境不用再过多做运维性的动作,对于扩缩容也不用考虑,业务开发之后就可以上线,运维交给平台,扩缩容能力也是交给平台,为用户减轻压力,业务用量上来之后怎么承载业务,怎么保证业务不崩溃,云函数已经解决了这个问题,本身的扩容可以理解为无限能力的扩容。



Q:Serverless在线能力有没有额外的规划?Serverless的程序和代码能不能访问云主机上面的接口?

A:目前有在做很多,包括边缘计算、CDN以及和腾讯云的各种云产品打通,Serverless本身最大的价值在于和各个云产品打通之后的效能,可以认为是各个云产品之间的黏合剂或者是轻量级计算的联合。而和后端的对接,包括数据库、CVM直接打通,更多是网络上的问题,即将会推出和VPC网络的打通,用户VPC业务可以用云函数直接访问。



相关阅读

[使用腾讯云“自定义监控”监控GPU使用率][2]
[如何在Python中从零开始实现随机森林][3]
[自然语言处理的神经网络模型初探][4]
***
此文已由作者授权云加社区发布,转载请注明[文章出处][5]


[1]: https://cloud.tencent.com/developer
[2]: https://cloud.tencent.com/developer/article/1043874
[3]: https://cloud.tencent.com/developer/article/1043093
[4]: https://cloud.tencent.com/developer/article/1036794
[5]: https://cloud.tencent.com/developer/article/1044457

如何在 Kubernetes 之上架构应用?

piglei 发表了文章 • 0 个评论 • 1564 次浏览 • 2018-08-05 21:51 • 来自相关话题

# 简介 设计并运行一个兼顾可扩展性、可移植性和健壮性的应用是一件很有挑战的事情,尤其是当系统复杂度在不断增长时。应用或系统本身的架构极大的影响着其运行方式、对环境的依赖性,以及与相关组件的耦合强弱。当应用在一个高度分布式的环境中运行时,如果能在设 ...查看全部
# 简介
设计并运行一个兼顾可扩展性、可移植性和健壮性的应用是一件很有挑战的事情,尤其是当系统复杂度在不断增长时。应用或系统本身的架构极大的影响着其运行方式、对环境的依赖性,以及与相关组件的耦合强弱。当应用在一个高度分布式的环境中运行时,如果能在设计阶段遵循特定模式,在运维阶段恪守特定实践,就可以帮助我们更好的应对那些最常出现的问题。

尽管软件设计模式和开发方法论可以帮助我们生产出满足恰当扩展性指标的应用,基础设施与运行环境也在影响着已部署系统的运维操作。像 DockerKubernetes 这些技术可以帮助团队打包、分发、部署以及在分布式环境中扩展应用。学习如何最好的驾驭这些工具,可以帮助你在管理应用时拥有更好的机动性、控制性和响应能力。

在这份指南里,我们将探讨一些你可能想采用的准则和模式,它们可以帮助你在 Kubernetes 上更好的扩展和管理你的工作集(workloads)。尽管在 Kubernetes 上可以运行各种各样的工作集,但是你的不同选择会影响运维难度和部署时的可选项。你如何架构和构建应用、如何将服务用容器打包、如何配置生命周期管理以及在 Kubernetes 上如何操作,每一个点都会影响你的体验。
# 为可扩展性做应用设计
当开发软件时,你所选用的模式与架构会被很多需求所影响。对于 Kubernetes 来说,它最重要的特征之一就是要求应用拥有水平扩展能力——通过调整应用副本数来分担负载以及提升可用性。这与垂直扩展不同,垂直扩展尝试使用同样的参数将应用部署到性能更强或更弱的服务器上。

比如,微服务架构是一种适合在集群中运行多个可扩展应用的软件设计模式。开发者们创建一些可组合的简单应用,它们通过良好定义的 REST 接口进行网络通信,而不是像更复杂的单体式应用那样通过程序内部机制通信。将单体式应用拆分为多个独立的单一功能组件后,我们可以独立的扩展每个功能组件。很多之前通常存在于应用层的组合与复杂度被转移到了运维领域,而它们刚好可以被像 Kubernetes 这样的平台搞定。

比特定的软件模式更进一步,云原生(cloud native)应用在设计之初就有一些额外的考量。云原生应用是遵循了微服务架构模式的程序,拥有内置的可恢复性、可观测性和可管理性,专门用于适应云集群平台提供的环境。

举例来说,云原生应用在被创造出时都带有健康度指标数据,当某个实例变得不健康时,平台可以根据指标数据来管理实例的生命周期。这些指标产生(也可以被导出)稳定的遥控数据来给运维人员告警,让他们可以依据这些数据做决策。应用被设计成可以应付常规的重启、失败、后端可用性变化以及高负载等各种情况,而不会损坏数据或者变得无法响应。
## 遵循 “12 法则应用”应用理论
在创建准备跑在云上的 web 应用时,有一个流行的方法论可以帮你关注到那些最重要的特征:“12 法则应用理论”( Twelve-Factor App)。它最初被编写出来,是为了帮助开发者和运维团队了解所有被设计成在云环境运行的 web 服务的共有核心特征,而对于那些将在 Kubernetes 这种集群环境中运行的应用,这个理论也非常适用。尽管单体式应用可以从这些建议中获益,围绕这些原则设计的微服务架构应用也会工作的非常好。

“12 法则”的一份简单摘要:

  1. 基准代码(Codebase):将你的所有代码都放在版本控制系统中(比如 Git 或者 Mercurial)。被部署的内容完全由基准代码决定。
  2. 依赖(Dependencies):应用依赖应该由基准代码全部显式管理起来,无论是用 vendor(指依赖代码和应用代码保存在一起),还是通过可由包管理软件解析安装的依赖配置文件的方式。
  3. 配置(Config):把应用配置参数与应用本身分开来,配置应该在部署环境中定义,而不是被嵌入到应用本身。
  4. 后端服务(Backing Services):本地或远程的依赖服务都应该被抽象为可通过网络访问的资源,连接细节应该在配置中定义。
  5. 构建、发布、运行(Build, release, run):应用的构建阶段应该完全与发布、运维阶段区分开来。构建阶段从应用源码创建出一个可执行包,发布阶段负责把可执行包和配置组合起来,然后在运行阶段执行这个发布版本。
  6. 进程(Processes):应用应该由不依赖任何本地状态存储的进程实现。状态应该被存储在第 4 个法则描述的后端服务中。
  7. 端口绑定(Port binding):应用应该原生绑定端口和监听连接。所有的路由和请求转发工作应该由外部处理。
  8. 并发(Concurrency):应用应该依赖于进程模型扩展。只需同时运行多份应用(可能分布在不同服务器上),就能实现不调整应用代码扩展的目的。
  9. 易处理(Disposability):进程应该可以被快速启动、优雅停止,而不产生任何严重的副作用。
  10. 开发环境与线上环境等价(Dev/prod parity):你的测试、预发布以及线上环境应该尽可能一致而且保持同步。环境间的差异有可能会导致兼容性问题和未经测试的配置突然出现。
  11. 日志(Logs):应用应该将日志输出到标准输出(stdout),然后由外部服务来决定最佳的处理方式。
  12. 管理进程(Admin processes):一次性管理进程应该和主进程代码一起发布,基于某个特定的发布版本运行。

依照“12 法则”所提供的指南,你可以使用完全适用于 Kubernetes 运行环境的模型来创建和运行应用。“12 法则”鼓励开发者们专注于他们应用的首要职责,考虑运维条件以及组件间的接口设计,并使用输入、输出和标准进程管理功能,最终以可被预见的方式将应用在 Kubernetes 中跑起来。
# 容器化应用组件
Kubernetes 使用容器在集群节点上运行隔离的打包应用程序。要在 Kubernetes 上运行,你的应用必须被封装在一个或者多个容器镜像中,并使用 Docker 这样的容器运行时执行。尽管容器化你的组件是 Kubernetes 的要求之一,但其实这个过程也帮助强化了刚刚谈到的“12法则应用”里的很多准则,从而让我们可以简单的扩展和管理应用。

举例来说,容器提供了应用环境与外部宿主机环境之间的隔离,提供了一个基于网络、面向服务的应用间通信方式,并且通常都是从环境变量读取配置、将日志写到标准输出与标准错误输出中。容器本身鼓励基于进程的并发策略,并且可以通过保持独立扩展性和捆绑运行时环境来帮助保持开发/线上环境一致性(#10 Dev/prod parity)。这些特性让你可以顺利打包应用,从而顺利的在 Kubernetes 上运行起来。
## 容器优化准则
因为容器技术的灵活性,我们有很多不同种封装应用的方式。但是在 Kubernetes 环境中,其中一些方式比其他方式工作的更好。

镜像构建(image building),是指你定义应用将如何在容器里被设置与运行的过程,绝大多数关于“如何容器化应用”的最佳实践都与镜像构建过程有关。通常来说,保持镜像尺寸小以及可组合会带来很多好处。在镜像升级时,通过保持构建步骤可管理以及复用现有镜像层,被优化过尺寸的的镜像可以减少在集群中启动一个新容器所需要的时间与资源。

当构建容器镜像时,尽最大努力将构建步骤与最终在生产环境运行的镜像区分开来是一个好的开始。构建软件通常需要额外的工具、花费更多时间,并且会生产出在不同容器里表现不同、或是在最终运行时环境里根本不需要的内容。将构建过程与运行时环境清晰分开的办法之一是使用 Docker 的“多阶段构建(multi-stage builds)” 特性。多阶段构建配置允许你为构建阶段和运行阶段设置不同的基础镜像。也就是说,你可以使用一个安装了所有构建工具的镜像来构建软件,然后将结果可执行软件包复制到一个精简过的、之后每次都会用到的镜像中。

有了这类功能后,基于最小化的父镜像来构建生产环境镜像通常会是个好主意。如果你想完全避免由 `ubuntu:16.04`(该镜像包含了一个完整的 Ubuntu 16.04 环境)这类 “Linux 发行版” 风格父镜像带来的臃肿,你可以尝试用 `scratch` - Docker 的最简基础镜像 - 来构建你的镜像。不过 `scratch` 基础镜像缺了一些核心工具,所以部分软件可能会因为环境问题而无法运行。另外一个方案是使用 Alpine Linux 的 `alpine` 镜像,该镜像提供了一个轻量但是拥有完整特性的 Linux 发行版。它作为一个稳定的最小基础环境获得了广泛的使用。

对于像 Python 或 Ruby 这种解释型编程语言来说,上面的例子会稍有变化。因为它们不存在“编译”阶段,而且在生产环境运行代码时一定需要有解释器。不过因为大家仍然追求精简的镜像,所以 Docker Hub 上还是有很多基于 Alpine Linux 构建的各语言优化版镜像。对于解释型语言来说,使用更小镜像带来的好处和编译型语言差不多:在开始正式工作前,Kubernetes 能够在新节点上快速拉取到所有必须的容器镜像。
# 在 Pod 和“容器”之间做选择
虽然你的应用必须被“容器”化后才能在 Kubernetes 上跑起来,但 pods(译注:因为 pod、service、ingress 这类资源名称不适合翻译为中文,此处及后面均使用英文原文) 才是 Kubernetes 能直接管理的最小抽象单位。pod 是由一个或更多紧密关联的容器组合在一起的 Kubernetes 对象。同一个 pod 里的所有容器共享同一生命周期且作为一个独立单位被管理。比如,这些容器总是被调度到同一个节点上、一起被启动或停止,同时共享 IP 和文件系统这类资源。

一开始,找到将应用拆分为 pods 和容器的最佳方式会比较困难。所以,了解 Kubernetes 是如何处理这些对象,以及每个抽象层为你的系统带来了什么变得非常重要。下面这些事项可以帮助你在使用这些抽象概念封装应用时,找到一些自然的边界点。

寻找自然开发边界是为你的容器决定有效范围的手段之一。如果你的系统采用了微服务架构,所有容器都经过良好设计、被频繁构建,各自负责不同的独立功能,并且可以被经常用到不同场景中。这个程度的抽象可以让你的团队通过容器镜像来发布变更,然后将这个新功能发布到所有使用了这个镜像的环境中去。应用可以通过组合很多容器来构建,这些容器里的每一个都实现了特定的功能,但是又不能独立成事。

与上面相反,当考虑的是系统中的哪些部分可以从独立管理中获益最多时,我们常常会用 pods。Kubernetes 使用 pods 作为它面向用户的最小抽象,因此它们是 Kubernetes API 和工具可以直接交互与控制的最原生单位。你可以启动、停止或者重启 pods,或者使用基于 pods 建立的更高级别抽象来引入副本集和生命周期管理这些特性。Kubernetes 不允许你单独管理一个 Pod 里的不同容器,所以如果某些容器可以从独立管理中获得好处,那么你就不应该把它们分到到一个组里。

因为 Kubernetes 的很多特性和抽象概念都直接和 pods 打交道,所以把那些应该被一起扩缩容的东西捆绑到一个 pod 里、应该被分开扩缩容的分到不同 pod 中是很有道理的。举例来说,将前端 web 服务器和应用服务放到不同 pods 里让你可以根据需求单独对每一层进行扩缩容。不过,有时候把 web 服务器和数据库适配层放在同一个 pod 里也说得过去,如果那个适配器为 web 服务器提供了它正常运行所需的基本功能的话。
## 通过和支撑性容器捆绑到一起来增强 Pod 功能
了解了上面这点后,到底什么类型的容器应该被捆绑到同一个 pod 里呢?通常来说,pod 里的主容器负责提供 pod 的核心功能,但是我们可以定义附加容器来修改或者扩展那个主容器,或者帮助它适配到某个特定的部署环境中。

比如,在一个 web 服务器 pod 中,可能会存在一个 Nginx 容器来监听请求和托管静态内容,而这些静态内容则是由另外一个容器来监听项目变动并更新的。虽然把这两个组件打包到同一个容器里的主意听上去不错,但是把它们作为独立的容器来实现是有很多好处的。nginx 容器和内容拉取容器都可以独立的在不同情景中使用。它们可以由不同的团队维护并分别开发,达到将行为通用化来与不同的容器协同工作的目的。

Brendan Burns 和 David Oppenheimer 在他们关于“基于容器的分布式系统设计模式”的论文中定义了三种打包支撑性容器的主要模式。它们代表了一些最常见的将容器打包到 pod 里的用例:

  • Sidecar(边车模式):在这个模式中,次要容器扩展和增强了主容器的核心功能。这个模式涉及在一个独立容器里执行非标准或工具功能。举例来说,某个转发日志或者监听配置值改动的容器可以扩展某个 pod 的功能,而不会改动它的主要关注点。
  • Ambassador(大使模式):Ambassador 模式使用一个支援性容器来为主容器完成远程资源的抽象。主容器直接连接到 Ambassador 容器,而 Ambassador 容器反过来连接到可能很复杂的外部资源池 - 比如说一个分布式 Redis 集群 - 并完成资源抽象。主容器可以完成连接外部服务,而不必知道或者关心它们实际的部署环境。
  • Adaptor(适配器模式):Adaptor 模式被用来翻译主容器的数据、协议或是所使用的接口,来与外部用户的期望标准对齐。Adaptor 容器也可以统一化中心服务的访问入口,即便它们服务的用户原本只支持互不兼容的接口规范。

# 使用 Configmaps 和 Secrets 来保存配置
尽管应用配置可以被一起打包进容器镜像里,但是让你的组件在运行时保持可被配置能更好支持多环境部署以及提供更多管理灵活性。为了管理运行时的配置参数,Kubernetes 提供了两个对象:ConfigMapsSecrets

ConfigMaps 是一种用于保存可在运行时暴露给 pods 和其他对象的数据的机制。保存在 ConfigMaps 里的数据可以通过环境变量使用,或是作为文件挂载到 pod 中。通过将应用设计成从这些位置读取配置后,你可以在应用运行时使用 ConfigMaps 注入配置,并以此来修改组件行为而不用重新构建整个容器镜像。

Secrets 是一种类似的 Kubernetes 对象类型,它主要被用来安全的保存敏感数据,并根据需要选择性的的允许 pods 或是其他组件访问。Secrets 是一种方便的往应用传递敏感内容的方式,它不必像普通配置一样将这些内容用纯文本存储在可以被轻易访问到的地方。从功能性上讲,它们的工作方式和 ConfigMaps 几乎完全一致,所以应用可以用完全一样的方式从二者中获取数据。

ConfigMaps 和 Secrets 可以帮你避免将配置内容直接放在 Kubernetes 对象定义中。你可以只映射配置的键名而不是值,这样可以允许你通过修改 CongfigMap 或 Secret 来动态更新配置。这使你可以修改线上 pod 和其他 kubernetes 对象的运行时行为,而不用修改这些资源本身的定义。
# 实现“就绪检测(Readiness)”与“存活检测(Liveness)”探针
Kubernetes 包含了非常多用来管理组件生命周期的开箱即用功能,它们可以确保你的应用始终保持健康和可用状态。不过,为了利用好这些特性,Kubernetes 必须要理解它应该如何监控和解释你的应用健康情况。为此,Kubernetes 允许你定义“就绪检测探针(Readiness Probe)”与“存活检测探针(Liveness Probe)”。

“存活检测探针”允许 Kubernetes 来确定某个容器里的应用是否处于存活与运行状态。Kubernetes 可以在容器内周期性的执行一些命令来检查基本的应用行为,或者可以往特定地址发送 HTTP / TCP 网络请求来判断进程是否可用、响应是否符合预期。如果某个“存活探测指针”失败了,Kubernetes 将会重启容器来尝试恢复整个 pod 的功能。

“就绪检测探针”是一个类似的工具,它主要用来判断某个 Pod 是否已经准备好接受请求流量了。在容器应用完全就绪,可以接受客户端请求前,它们可能需要执行一些初始化过程,或者当接到新配置时需要重新加载进程。当一个“就绪检测探针”失败后,Kubernetes 会暂停往这个 Pod 发送请求,而不是重启它。这使得 Pod 可以完成自身的初始化或者维护任务,而不会影响到整个组的整体健康状况。

通过结合使用“存活检测探针”与“就绪检测探针”,你可以控制 Kubernetes 自动重启 pods 或是将它们从后端服务组里剔除。通过配置基础设施来利用好这些特性,你可以让 Kubernetes 来管理应用的可用性和健康状况,而无需执行额外的运维工作。
# 使用 Deployments 来管理扩展性与可用性
在早些时候讨论 Pod 设计基础时,我们提到其他 Kubernetes 对象会建立在 Pod 的基础上来提供更高级的功能。而 deployment 这个复合对象,可能是被定义和操作的最多次的 Kubernetes 对象。

Deployments 是一种复合对象,它通过建立在其他 Kubernetes 基础对象之上来提供额外功能。它们为一类名为 replicasets 的中间对象添加了生命周期管理功能,比如可以实施“滚动升级(Rolling updates)”、回滚到旧版本、以及在不同状态间转换的能力。这些 replicasets 允许你定义 pod 模板并根据它快速拉起和管理多份基于这个模板的副本。这可以帮助你方便的扩展基础设施、管理可用性要求,并在故障发生时自动重启 Pods。

这些额外特性为相对简单的 pod 抽象提供了一个管理框架和自我修复能力。尽管你定义的工作集最终还是由 pods 单元来承载,但是它们却不是你通常应该最多配置和管理的单位。相反,当 pods 由 deployments 这种更高级对象配置时,应该把它们当做可以稳定运行应用的基础构建块来考虑。
# 创建 Services 与 Ingress 规则来管理到应用层的访问
Deployment 允许你配置和管理可互换的 Pod 集合,以扩展应用以及满足用户需求。但是,如何将请求流量路由到这些 pods 则是例外一码事了。鉴于 pods 会在滚动升级的过程中被换出、重启,或者因为机器故障发生转移,之前被分配给这个运行组的网络地址也会发生变化。Kubernetes services 通过维护动态 pods 资源池以及管理各基础设施层的访问权限,来帮助你管理这部分复杂性。

在 Kuberntes 里,services 是控制流量如何被路由到多批 pods 的机制。无论是为外部客户转发流量,还是管理多个内部组件之间的连接,services 允许你来控制流量该如何流动。然后,Kubernetes 将更新和维护将连接转发到相关 pods 的所有必需信息,即使环境或网络条件发生变化也一样。
## 从内部访问 Services
为了有效的使用 services,你首先应该确定每组 pods 服务的目标用户是谁。如果你的 service 只会被部署在同一个 Kubernetes 集群的其他应用所使用,那么 ClusterIP 类型允许你使用一个仅在集群内部可路由的固定 IP 地址来访问一组 pods。所有部署在集群上的对象都可以通过直接往这个 service IP 地址发送请求来与这组 pod 副本通信。这是最简单的 service 类型,很适合在内部应用层使用。

Kubernetes 提供了可选的 DNS 插件来为 services 提供名字解析服务。这允许 pods 和其他对象可以使用域名来代替 IP 地址进行通信。这套机制不会显著改动 service 的用法,但基于域名的标识符可以使连接组件和定义服务间交互变得更简单,而不需要提前知道 service IP 地址。
## 将 Services 向公网开放
如果你的应用需要被公网访问,那么 “负载均衡器(load balancer)”类型的 service 通常会是你的最佳选择。它会使用应用所在的特定云提供商 API 来配置一个负载均衡器,由这个负载均衡器通过一个公网 IP 来服务所有到 service pods 的流量。这种方式提供了一个到集群内部网络的可控网络通道,从而将外部流量引入到你的 service pods 中。

由于“负载均衡器”类型会为每一个 service 都创建一个负载均衡器,因此用这种方式来暴露 Kubernetes 服务可能会有些昂贵。为了帮助缓解这个问题,我们可以使用 Kubernetes ingress 对象来描述如何基于预定规则集来将不同类型的请求路由到不同 services。例如,发往 “example.com” 的请求可能会被指向到 service A,而往 “sammytheshark.com” 的请求可能会被路由到 service B。Ingress 对象提供了一种描述如何基于预定义模式将混合请求流分别路由到它们的目标 services 的方式。

Ingress 规则必须由一个 ingress controller 来解析,它通常是某种负载均衡器(比如 Nginx),以 pod 的方式部署在集群中,它实现了 ingress 规则并基于规则将流量分发到 Kubernetes serices 上。目前,ingress 资源对象定义仍然处于 beta 阶段,但是市面上已经有好几个能工作的具体实现了,它们可以帮助集群所有者最小化需要运行的外部负载均衡器数量。
# 使用声明式语法来管理 Kubernetes 状态
Kubernetes 在定义和管理部署到集群的资源方面提供了很大灵活性。使用 `kubectl` 这样的工具,你可以命令式的定义一次性资源并将其快速部署到集群中。虽然在学习 Kubernetes 阶段,这个方法对于快速部署资源可能很有用,但这种方式也存在很多缺点,不适合长周期的生产环境管理。

命令式管理方式的最大问题之一就是它不保存你往集群部署过的变更记录。这使得故障时恢复和跟踪系统内运维变更操作变得非常困难,甚至不可能。

幸运的是,Kubernetes 提供了另外一种声明式的语法,它允许你使用文本文件来完整定义资源,并随后使用 `kubectl` 命令应用这些配置或更改。将这些配置文件保存在版本控制系统里,是监控变更以及与你的公司内其他部分的审阅过程集成的一种简单方式。基于文件的管理方式也让将已有模式适配到新资源时变得简单,只需要复制然后修改现有资源定义即可。将 Kubernetes 对象定义保存在版本化目录里允许你维护集群在每个时间节点的期望集群状态快照。当你需要进行故障恢复、迁移,或是追踪系统里某些意料之外的变更时,这些内容的价值是不可估量的。
# 总结
管理运行应用的基础设施,并学习如何最好的利用这些现代化编排系统提供的特性,这些事情可能会令人望而生畏。但是,只有当你的开发与运维过程与这些工具的构建概念一致时,Kubernetes 系统、容器技术提供的优势才能更好的体现出来。遵循 Kubernetes 最擅长的那些模式来架构你的系统,以及了解特定功能如何能缓解由高度复杂的部署带来的挑战,可以帮助改善你运行平台时的体验。

原文链接:architecting-applications-for-kubernetes(翻译:朱雷(piglei))

DockOne微信分享(一四零):Serverless云函数架构精解

腾讯云技术社区 发表了文章 • 0 个评论 • 2653 次浏览 • 2017-09-06 17:18 • 来自相关话题

【编者的话】继虚拟机,容器技术之后,无服务器化成为新的行业热点,无服务器云函数可以让用户无需关心服务器的部署运营,只需开发最核心的业务逻辑,即可实现上线运营,具备分布容灾能力,可依据负载自动扩缩容,按照实际调用次数与时长计费。本次主要分享腾讯云无服务器云函数在 ...查看全部
【编者的话】继虚拟机,容器技术之后,无服务器化成为新的行业热点,无服务器云函数可以让用户无需关心服务器的部署运营,只需开发最核心的业务逻辑,即可实现上线运营,具备分布容灾能力,可依据负载自动扩缩容,按照实际调用次数与时长计费。本次主要分享腾讯云无服务器云函数在技术实现上的挑战及架构实现原理。

【烧脑式Kubernetes实战训练营】本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。

无服务器云函数(Serverless Cloud Function)是无服务器(serverless)执行环境,帮助用户在没有购买和管理服务器时仍能运行代码。用户只需要使用云平台支持的语言编写核心代码及设置代码运行的条件,代码即可在腾讯云基础设施上弹性、安全地运行,并可完全管理底层计算资源,包括服务器CPU、内存、网络、代码部署、弹性伸缩、负载均衡等服务。

使用无服务器云函数将可免除所有运维性操作,企业和开发者可以更加专注于核心业务的开发,实现快速上线和迭代,把握业务发展的节奏。
# 云函数的价值及使用场景
随着云计算服务市场的成熟,用户对云计算接受程度逐渐提高,借助各类基础云组件,将业务上线时间从月级缩短到天级,但对比传统模式,用户仍需基于云组件重构非功能性需求。

云函数尝试将业务算法和流程提炼出来交由用户实现,打通各种云服务,并实现通用的负载均衡、自动伸缩、故障容灾、安全监管等通用功能,真正使得用户像搭积木一样打造个性化服务,将业务上线时间从天级缩短到分钟级。
1.png

相比云主机,云函数更适合于支持微服务架构业务场景。以图片多规格压缩服务为例,该服务在用户上传图片至COS时,自动将原始图片压缩成适配手机、平板、电脑等多种大小的规格。如利用云函数实现该服务,用户只需创建函数,定义函数触发条件为“图片上传”,在线编辑或使用IDE完成代码编写后上传,服务即构建完成。用户上传图片时,自动调用定义的函数完成图片的多规格压缩,云函数平台根据上传并发量自动扩缩容函数实例,并最终按照实际调用消耗计费。
2.png

从该示例可以看出,云函数为用户带来的主要价值为:

  • 加快用户服务上线时间,用户只需实现业务算法及流程,上线时间缩短为分钟级;
  • 减少用户的运营负担,用户无须承担服务扩容,故障恢复运维工作;
  • 消除用户的资源成本,用户无需承担资源闲置费用,只为实际调用消耗付费。
#云函数架构原理云函数平台整体架构原理如图所示。
3.png
云函数为用户提供SDK/WEBUI两种使用方式,并通过事件注册与回调机制与其它云组件打通,提供标准的API接口;调用分发根据函数所属的区域,用户,名字,版本号,鉴权等信息申请函数实例,并将调用均匀的分发到可用函数实例;函数管理负责创建/修改/删除函数,并提供函数代码管理,版本管理等功能;函数调度根据函数资源需求选择合适的位置创建/销毁函数实例;函数实例部署用户定义的函数,负责函数的执行及监管。从云函数的定位及架构原理看,衡量云函数平台的关键技术指标可概括为:
  • 不仅支持业务快速上线,且能实现持续发展;
  • 不仅支持业务按需取用,且能释放闲置资源;
  • 不仅支持业务永不中断,且能扩展运行范围;
  • 不仅支持业务自由运行,且能避免干扰入侵。
下文将展开详述。## 支持业务快速上线,且能实现持续发展支持业务分钟级上线,需要尽可能的减少用户研发工作量,云函数用户仅需提供简单的函数配置及代码即可完成上线。以图片压缩为例,用户自行编辑Python代码如下,即可实现一个图片压缩服务:
4.png
其中第1行引入依赖库,第4~9行解析输入参数,第11行调用库完成图片压缩,12~15行判断结果及返回。用户可在线完成代码的编辑并提交,也可像开发本地程序一样使用喜欢的IDE编辑,调试通过后打成zip包通过SDK提交,提交成功服务即上线。支持业务可持续发展,需提供用户函数平滑升级及版本变更能力,当用户更新函数代码或配置后,新调用请求被分发至新函数实例,原调用请求执行完成后,旧函数实例自动消亡,服务在客户不感知情况下平滑更新。即将支持用户函数多版本管理,将函数别名映射至用户指定版本,在客户不感知情况下实现多版本间平滑切换。
5.png
函数运行过程中间,用户打印日志,标准输出/错误输出日志分类上传至腾讯云日志服务平台,用户可实时监控函数运行情况。## 支持业务按需取用,且能释放闲置资源要支持云函数真正按需取用,需实现用户第一次调用时延迟分配资源,函数调用过程如下图所示:
6.png
云函数平台在调用分发时,会判断是否有函数实例存在,如若不存在,则实时启动实例,实例启动完成后,才开始执行函数调用。为了达到第一次调用足够快的目标,在调用过程中需分阶段逐层优化:
  • 分发调用阶段:需减少调用分发层级,比如对于用户主动发起的http同步调用,正常路径可免去存入持久化队列过程;
  • 镜像及代码下载阶段:需尽量预部署以减少下载时间,比如对新提交函数,并行启动预加载,使得第一次调用发起时无须再去实时下载;
  • 容器启动过程:需简化容器启动脚本,使得启动过程尽量轻量,对于对延时敏感的业务,提供实例预留机制,用户可选择预留少量实例以减少第一次调用的额外延时;
  • 执行函数调用:需尽量减少函数参数,返回数据及日志传递导致的内存拷贝次数;
  • 返回调用:需尽量减少返回层级。
通过逐层优化,第一次调用平台耗时可控制在2s左右,后续调用平台耗时控制在5ms左右。随着客户请求量的增加或减少,函数实例随着自动扩缩容,一般算法如下:

If 当前请求数/当前实例数 > 扩容阈值:扩容实例else 当前请求数/当前实例数 < 缩容阈值:缩容实例

当缩容至最后一个函数实例时,为避免函数实例短时间内重复启动/停止导致客户调用延时增加,需保留一段时间延迟释放。##支持业务永不中断,且能扩展运行范围要支持云函数永不中断,需实现2个容灾目标:
  • 硬件故障时服务不中断
  • 平台升级时服务不中断
为实现这三个容灾目标,整体架构需实现set化,且在各层均需对应的支持:
  • 接入层:基于腾讯云CLB实现横向扩展,负载均衡,7层路由能力;
  • 逻辑层:实现模块无状态化,模块内部无状态数据,可随意启停替换;
  • 数据层:采用一致性存储仓库存储关键数据;
  • 节点层:实现快速节点故障检测及替换恢复。

比如平台内部Invoker模块实例硬件故障时,如下图所示,由于Invoker模块无状态,故障时可由接入层CLB模块自动剔除,剔除后新请求分发至剩余invoker模块实例,已接收的异步事件可由其它Invoker重试完成,同步http调用会直接返回给用户错误请求,由用户重试,在故障Invoker实例恢复后,自动添加至CLB中,继续分担负载。
7.png

当平台需要升级API接口时,采用只增不改策略,提供新版本API接口,保持用户原有服务兼容性,用户采用新接口时,CLB通过7层路由,路由至新版本invoker模块实例,旧版本实例随着负载的降低逐步缩容,新版本实例随着负载升高逐步扩容,以此实现了用户透明的版本平滑升级。
8.png

要实现云函数需与各类云组件打通,需要云组件提供事件注册及回调机制,云组件提供可注册事件及对应的回调接口,云函数确保云组件通信的用户权限打通传递。当前云函数实现了与腾讯云COS存储组件的打通,马上将实现与腾讯云CMQ、云监控等其它云产品的打通,并将运行范围扩展至CDN节点及IOT设备网关,实现边缘计算。
## 支持业务自由运行,且能避免干扰入侵
云函数需支持用户本地测试通过的代码无缝在云函数平台,需具备足够的兼容性,及用户函数运行时环境,需要具备和用户开发测试环境类似的软件包,安全等配置;同时避免函数间干扰,防止恶意入侵。

为了避免用户函数间干扰,云函数使用了Docker容器来封装函数实例,通过Docker的名字隔离、空间隔离、权限限制等机制实现用户间隔离,辅以实时冲突监控调度等措施及时处理干扰。

为了避免用户执行代码影响整个云函数平台,如下图所示,实现了云函数管理平台与用户函数的隔离,用户函数无法感知管理平台的网络地址,运行日志等信息,从而无从影响云函数平台的运行。
9.png

为了避免用户恶意代码对网络的探测和入侵,如下图所示,用户函数实例被限制到了受限的公共VPC网络,需通过网关实现与外网服务、其它函数实例、云组件的互访,同时,为了支持用户函数实例与个人CVM虚拟机的集成,云函数平台通过弹性网卡打通了与其私有VPC的网络通信。
10.png

# 云函数行业进展趋势
近年Serverless、微服务等理念逐步深入人心,云函数开始被用户了解接受。为了满足用户对于更快速上线、更低成本、更优架构的求索,腾讯云推出了云函数产品。用户不妨从解决实际问题开始试用云函数,比如实现一个简单的服务拨测工具,实现一个定时任务,实现存储于COS的图片、视频、文件的计算等。随着云函数可联动云组件的拓展,支持语言的丰富,调试工具,流程引擎等逐步完善,云函数会逐步成为整个云平台的粘合剂,将各种云组件融合一起,让云成为你的公共后台,到时可支持更为复杂的状态服务场景,成为用户通用体贴厚实的后盾。
# Q&A
Q:请问代码怎么部署到Docker中?

A:直接将代码下载至母机,再将代码目录挂载至Docker。



Q:云函数是通用的还是只能在云平台运行?

A:云提供了云函数服务,自己也可搭建,目前GitHub上有不少开源云函数平台,比如OpenLambda,Iron.io等,建议直接使用云的服务,因为可以和多个云产品打通,单靠云函数自身难以构建完整服务。



Q:事件传递使用的是队列吗?

A:异步事件用了CMQ消息队列持久化存储,同步事件未使用。



Q:请问云函数对开发语言有限制否?如果有,目前对Go语言的支持如何?

A:目前支持Python 2.7/3.6,Node.js 4.3/6.10,Java 8,如果有通用的用户需求,可以支持其它语言,比如PHP、Go等。



Q:有系统函数调用吗?自定义函数的颗粒度有何建议?

A:绝大部分的系统调用都可调用,除了一些危险操作,比如关机,重启,网络服务监听等,函数颗粒度可参考微服务的设计原则,将功能尽量拆细。



Q:能介绍下将请求调度到函数实例的实现吗?

A:这里有个Invoker模块对每个函数维持有一个请求队列,目前没设置优先级,按照先来先到的顺序依次调度,调度时会从函数所有可用的函数实例中,选择一个下发。函数实例里有个循环接受请求,收到时传递参数调用用户函数。



Q:代码可以下云落地吗?

A:代码里一般会涉及其它云产品的调用,所以一般对云平台有一些依赖,可以关注下开源的Serverless框架,在公有云云函数上封装了一层,用来解除依赖,实现在各个云平台的平滑迁移。



Q:云函数的代码有哪些限制?比如什么样的函数不可以调用,什么样的库不能import?

A:可以基本认为无限制,但会禁止恶意行为,比如关机,重启,端口扫描等;也会禁止端口监听,因为常驻进程不符合云函数按需启用的原则。如果预装库不符合要求,可以自行将依赖库打包至zip里上传。



以上内容根据2017年08月22日晚微信群分享内容整理。 分享人陈杰,腾讯云架构平台部技术专家,10年云计算经验,现供职于腾讯架构平台部,负责弹性计算及云函数技术研发,致力于提供领先的基础设施平台以提升资源利用率及优化提升程序员开发运维效率。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesa,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

弯道超车:容器技术究竟为云计算带来了什么?

崔婧雯 发表了文章 • 1 个评论 • 7256 次浏览 • 2016-02-25 15:15 • 来自相关话题

这两年容器技术及其相关工具,平台异常火爆。在各大技术论坛或云计算峰会议题中,都会占很大比重,各主流云计算平台也无一例外地迅速提供了容器服务。从2014年或更早,就有专家预见到Docker/容器技术会是云计算的颠覆力量(disruptive force)。坦率地 ...查看全部
这两年容器技术及其相关工具,平台异常火爆。在各大技术论坛或云计算峰会议题中,都会占很大比重,各主流云计算平台也无一例外地迅速提供了容器服务。从2014年或更早,就有专家预见到Docker/容器技术会是云计算的颠覆力量(disruptive force)。坦率地讲,云计算作为一种服务和应用的业务模式,很难讲会被颠覆,但容器技术的确是云计算的game changer,它改变了我们思考云计算的视角,是云计算的reinventor。

目前很多容器技术分析和经验分享中,人们谈论了它带来的诸多好处:

- 极其轻量:只打包了必要的Bin/Lib;
- 秒级部署:根据镜像的不同,容器的部署大概在毫秒与秒之间;
- 易于移植:一次构建,随处部署,因为本身是一个自包含镜像;
- 弹性伸缩:Docker、Kubernetes、Mesos这类容器管理平台有着与生俱来的弹性管理能力;

但貌似这些特点,之前虚拟化云管理平台也或多或少都可实现。容器镜像在某种程度上也常被视作为轻量级虚机镜像,至于快速部署,弹性伸缩也可通过自动化脚本、监控、编排(比如heat)来组合完成。那么,容器技术究竟给云计算带来什么本质的改变呢?
图1.jpg

图1. 部署速度的演进(引自Adrian Cockcroft, Battery Ventures)

这张图是Adrian Cockcroft在2014 DockerCon上第一次提出,介绍了部署速度的演进,但其分类貌似没严格遵循统一视角,比如Virtualization和Container从技术角度讲,而Serverless更像应用实现架构的视角,不特指某种技术。假如做个粗浅的解释, Datacenters可以理解为传统技术下的IT平台,Virtualization可以理解为基于虚拟化的云计算平台,Containers可以是Docker、Kurbernetes、Mesos之类的容器平台,而Serverless则可是AWS Lambda为代表的新型应用平台。这里,有了另一个问题,毫秒级的部署和秒级的生命周期对云计算又意味着什么?

先以AWS Lambda为例,了解一下Serverless。 Lambda是个事件驱动的弹性计算平台。用户可以写一段代码,AWS为其创建一个Lambda资源,这样,当指定的事件来临的时候,AWS的runtime会创建相应运行环境,执行代码,执行完毕(或者timeout)后,回收相应资源。看起来很平常,但Lambda一推出即惊艳四溢,为什么?

AWS网站上有个Lambda对流数据处理分析参考案例。Localytics是一家网络和移动应用分析公司,他们需要对来自安装在超过30亿设备中37,000多个App的数据进行App使用情况和用户行为进行分析。工程团队需要经常对子数据集提供新的分析处理服务,通常这意味着分析平台需要考虑额外的容量规划,性能监测和基础设施管理。然而,在这样量级上,这无疑会让平台变得复杂,新服务上线变得缓慢而痛苦。Localytics采用了Lambda实现了新的数据分析服务,这些服务可以并行访问来自30亿个设备的流数据,从而能迅速为客户提供相应的分析报告,如图2所示。(具体可参考:https://aws.amazon.com/solutions/case-studies/localytics/)
图2.jpg

图2. Lambda对社交媒体数据流处理(来自Amazon网站)

在AWS Lambda之前,IFTTT已经在提供类似事件驱动动作(/计算)的服务,但一直不温不火。为什么到AWS Lambda就火呢?从目前了解的有限资料来看,AWS Lambda是基于容器技术实现的,它把核心函数和服务包装成容器,相信也同样打包了用户代码,同时高度优化了容器的管理和调度,实现快速几乎实时的大规模scale out和scale down。也就是说,同样的业务场景,容器技术让AWS Lambda和IFTTT产生了完全不同效果。同样,也正是容器易于部署,编排的特性,让用户专注于应用本身而不是计算资源的管理,这就催生了Serverless的概念。

Lacalytics的例子很好说明了容器技术以应用/服务为中心的(application centric),而传统基于虚拟化技术的云平台是以机器(虚拟或真实的物理资源)为中心,后者势必让我们去考虑很多所谓DevOps的工作,而显然那将是需要不断提高但却永无止境的付出。容器技术以应用/服务为核心,跳出了原有以资源管理维护为中心的思维模式,显然是云计算演进过程中的一个里程碑式的跨越。

除了催生Serverless概念,容器技术还发展出了另外一个概念:immutable infrastructure(不可变基础架构)。所谓不可变基础架构,就是说系统一旦部署,就不再更变升级。当服务/应用需要升级时,只要部署一个新版系统,摧毁旧版就好了。在这个过程中,系统对外服务几乎是持续的。从这个概念描述中,我们很容易想到容器及相应的编排管理框架可以自然地实现immutable infrastructure。 Google的Brendan Burns有一段对Kurbenetes介绍视频,其中一个非常直观的演示场景就是在几乎不影响对外服务的情况下如何迅速将Container封装的应用从1.0升级到1.1。这利用到了container轻量化,快速部署的特性,使得以新替旧的成本大大低于升级维护旧Container ------ 听起来是个很不错的免维护的场景。表1对immutable infrastructure和artisanal infrastructure(手工艺架构)做了比较:
表1.jpg

表1. Immutable Infrastructure vs. Artisanal Infrastructure

事实上,类似免维护的观念在硬件领域已非常普遍。比如电脑的显示屏不亮了,维修工程师要么换屏,要么换主板,没有人会再用仪器去检测显示芯片组了,因为这样的投入费时费工。这里,修(维护升级)还是换(去旧补新)基于很简单的成本逻辑,一旦换新的比升级旧的成本更低时,人们自然选择直接换新的。同样,Container标准化封装和快捷部署和销毁,让新应用/服务取代旧应用/服务,比研究如何给应用/服务打patch升级更为简化高效。由此,容器技术让应用的immutable infrastructure变成现实。

此外,经常跟容器技术一起谈论的另一个概念是Microservice架构。Martin Fowler在一篇文章中用下图3 形象地做了说明:
图3.jpg

图3. 整体封装(应用)与Mirco-Serivce架构

并谈到了微服务的几个主要特征:

- 组件化的服务(封装)
- 围绕业务能力组织
- 是独立产品不是项目
- 简化的通讯与连接
- 去中心管理
- 去中心数据管理
- 基础架构自动化
- 容错设计
- 递进设计

从这些特性看,容器技术及其相关的编排管理框架是得它成为实现Microservice架构最自然的载体。比如,通常一个Container镜像是一个应用/服务的独立完整的封装,一般要求是Stateless,而且从管理角度看,Container平台都提供自动化的生命周期,scale out和scale down的管理。

Serverless架构,Immutable Infrastructure和Micro-service架构,这些概念/方法的出现,给我们构建云计算应用/服务提供了全新视角,使得创建和部署新应用就像使用乐高积木一样简单,大规模的弹性伸缩就如同自动点一下复制和删除命令一样快捷。我们在创建应用/服务时,不用再考虑机器(资源),不用再考虑维护,而且有很多可随时拼装的组件待用,同时服务的部署也非常快捷,让失败的成本大幅降低,我们唯一所需关心的只是应用和服务本身。通过上面的讨论,我们看到这一切最重要的推动力量就是容器技术。

容器,这个十几年前的技术,结合近年发展起来编排管理框架,把Serverless、Immutable Infrastructure 和Micro-Service这些美好概念变成了真正的现实,从而给云计算的发展带来了革命性的进步。正如Docker的创始人Solomon Hykes在DockerCon 15的主题演讲谈到的,Container技术让互联网可编程(programmable),使得大规模创新(massive innovations)成为可能。

===========================
作者介绍
鄢达来,IBM云计算方案开发经理。

【腾讯云】#容器团队#高级容器研发#招聘

Shirleyee 发表了文章 • 1 个评论 • 209 次浏览 • 2019-05-24 10:33 • 来自相关话题

高级容器研发工程师 工作职责 负责公有云/私有云中 Kubernetes/Devops 等产品技术方案设计与研发工作;负责 Kubernetes 相关前沿技术规划和调研工作,从技术上保证产品的竞争力;负责与产品及客户沟通,判定需求的合理 ...查看全部
高级容器研发工程师
工作职责
  1. 负责公有云/私有云中 Kubernetes/Devops 等产品技术方案设计与研发工作;
  2. 负责 Kubernetes 相关前沿技术规划和调研工作,从技术上保证产品的竞争力;
  3. 负责与产品及客户沟通,判定需求的合理性,找出最合适的方式解决客户问题。
工作要求
  1. 3 年以上后端开发经验,Coding、Debug 能力强, 有丰富的架构设计经验;
  2. 熟悉 C/C++/Go/Java/Python/Ruby 等至少二种编程语言;
  3. 熟悉 Docker/Kubernetes/Swarm/Mesos 等技术;
  4. 熟悉 Jenkins/ELK/Prometheus 等技术优先;
  5. 熟悉 AWS/Google Cloud 等云计算厂商产品优先。


有意请戳:
Wechat:13723737494
Email:Shirleyeee@foxmail.com

Serverless系列 | 云计算究竟如何进化出了Serverless?

灵雀云 发表了文章 • 0 个评论 • 538 次浏览 • 2019-04-10 16:14 • 来自相关话题

导读:近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is serverless》一书的部分内容,可以说是对Serverless科普与观察的上佳素材。本文为第1篇,他首先通过回溯云计算的发展史,来找出是什么原 ...查看全部

导读:近期灵雀云技术专家邵明岐翻译了Mike Roberts & John Chapin所著的《What is serverless》一书的部分内容,可以说是对Serverless科普与观察的上佳素材。本文为第1篇,他首先通过回溯云计算的发展史,来找出是什么原因导致进化出了 Serverless,然后解释 Serverless 到底为何物,最后总结为什么 Serverless 是云计算成长的必然产物,同时也是应用交付方式的巨大飞跃,非常值得一读!
原著:《What is serverless : understand the latest advances in cloud and service-based architecture》

作者:Mike Roberts & John Chapin
译文来源:深入浅出谈架构(ID:deep-easy-arch)
译者:灵雀云邵明岐

让我们回到2006年, 那时候还没有 iPhone 和移动互联网,Ruby on Rails 是一个非常热门的编程框架,Web 2.0 在当时是互联网最火热的名词。那时候大部分应用程序的后端服务,都是运行在托管或者自建的数据中心和物理服务器上。

云的诞生

2006年8月发生的事情将从根本上改变这种模式。 亚马逊新的IT部门 AWS 宣布推出Elastic Compute Cloud(EC2),EC2是众多基础架构即服务(IaaS)产品中的第一个, IaaS允许公司租用计算资源 (主要是面向互联网应用的虚拟主机),而不是购买自己的服务器, 它还允许人们在几分钟之内就可以获取到主机资源。 EC2的五个主要优势是:

1.降低人工成本
在 IaaS 出现之前,公司需要雇佣有专门技能的人来管理数据中心和里面的物理服务器,他们需要管理从电源和网络,到货架和安装,到修复机器的磁盘等物理问题,到设置操作系统(OS)。 通过IaaS,所有这些都消失了,而是都交给 IaaS 服务提供商,比如 AWS 或者阿里云。

2.降低风险
在管理自己的物理服务器时,经常会遭遇一些意外事件,比如硬件故障,从而导致系统不稳定或者长时间宕机,因为硬件问题很难预测,并且可能需要很长时间才能解决。 通过IaaS,客户虽然仍需要做一些工作来对抗硬件故障发生的风险,但不再需要知道如何修复硬件, 相反,可以简单地在几分钟内申请到新机器实例,并重新安装应用程序,从而限制了这些问题的风险。

3.降低基础设施成本
在大部分情况下,当您考虑电源、网络等成本的时候,EC2实例的成本比运行自己的硬件便宜,尤其是当您只想临时需要运行主机几天或几周而不是几个月时。

4.灵活扩展
考虑到IaaS带来的扩展优势,基础设施成本显着下降,通过IaaS,公司在扩展其运行的服务器的数量和类型方面具有更大的灵活性, 不再需要提前几个月预先购买10台高端服务器,相反,您可以从一个或两个低功耗,廉价的实例开始,然后随着时间的推移逐渐扩展您的实例数量和类型。

5.交付时间短
在托管服务器的旧时代,为新应用程序采购和配置服务器可能需要数月时间。 如果你想出新的想法,并且希望尽快尝试一下,在传统的方式下很难办到。 使用IaaS,交付时间从几个月缩短到几分钟。
基础设施外包
使用 IaaS,本质上我们可以认为是基础设施外包的技术。 当我们开发和运营软件时,我们需要做的工作大致可以分为两类:一类是针对需求需要定制的工作。另外一类是和其他公司都差不多,比较通用的工作。
基础设施就是属于第二种,其范围包括物理的设备,例如运行我们机器,电路,网络等,也包括一些通用的软件功能,比如用户认证。
基础设施外包通常可以由服务提供商(SP)提供。 例如,电力由电力供应商提供,并且网络由互联网服务提供商(ISP)提供,他们通过 2 种模式来减低成本和提高效率:规模化和技术创新。

规模化
几乎所有形式的基础设施外包都通过规模化的模式来降低成本,把大量工作打包在一起批量做,成本比单独一件一件做,效率大大提高。例如,AWS 可以以远低于小公司的价格购买相同规格的服务器,因为 AWS 一次性购买成千上万的服务器,而不是购买几十台服务器。 同样,AWS 的每台服务器运营成本远低于自建 IDC 的公司。

技术创新
基础设施外包通常也部分归因于技术创新。比如 EC2,是通过硬件虚拟化的技术来实现的。在IaaS出现之前,一些IT供应商已经开始允许公司来按月租用物理服务器。显然,EC2 的按小时租用主机的方式更具吸引力,而且,虚拟化技术可以将物理服务器细分为许多更小的,快速启动和关闭的虚拟机(VM),这样 IaaS 才变得可行。
基础设施外包与 IaaS 的五大好处完全一致:
• 降低人工成本 :减少人员,减少维护基础设施工作所需的时间;
• 降低风险 :消除了一部分对特殊技能专家的需求,并且能够获得及时的运营支持能力;
• 降低资源成本 :同样功能的成本更低;
• 提高扩展的灵活性:可以访问更多资源和不同类型的类似资源,而不会造成重大损失或浪费;
• 缩短交付周期:缩短从新想法到生产可用性的交付时间;
当然,基础设施外包也有其缺点和局限性,我们将在后面的部分介绍。

云计算的发展
云计算的发展是从IaaS开始的,比如EC2和AWS Simple Storage Service(S3), AWS是云计算早期的推动者,紧随其后的还有微软、谷歌、阿里云等。当我们谈论“云”时,我们通常指的是公共云,但是,我们也看到了私有云的市场发展的也不错,比如OpenStack。
公共云之后的另外一个潮流是PaaS,Heroku是当时最受欢迎的PaaS厂商之一, PaaS层面置于IaaS之上,将操作系统(OS)添加到外包的基础架构中,使用PaaS,您只需部署应用程序,云平台负责操作系统安装、补丁升级、系统级监控、服务发现等。
Heroku是公有云服务,Cloud Foundry是PaaS的一个私有云版本, 由于PaaS位于现有虚拟化解决方案之上,因此您可以在企业内部部署或者在IaaS公共云服务上部署“私有PaaS”,同时使用公共云和私有云通常被称为混合云, 能够在混合云环境中实现一个统一的PaaS平台对企业特别有用。
在虚拟机之上使用PaaS的最新方式是使用容器,Docker在过去几年中变得非常非常受欢迎,因为它可以从操作系统开始,更清楚地描述应用程序的系统需求,而管理/编排容器的云服务,通常称为容器服务(CaaS),比如Google的Container Engine和AWS的ECS。 一些私有云的CaaS是Kubernetes和Mesos,您也可以把它们搭建在公共IaaS或者私有IaaS之上运行。
就像IaaS一样,PaaS和CaaS都是基础设施外包的另外一种更加高级的形式,它们和IaaS的主要不同之处是,有更高级别的抽象性,允许我们将运行应用的更多技术细节交给云平台,因此,PaaS和CaaS带给我们的好处,与我们之前列出的IaaS的五个好处完全一样,所以,我们可以将所有这三个(IaaS,PaaS,CaaS)组合为计算即服务(Compute as a Service)。
**
Serverless时代到来**
前面解释了半天云计算的发展史,主要就是想引入主题——Serverless。它将会是云计算演进的下一个重要技术,也是另外一种形式的基础设施外包,它同样具有我们已经看到的云计算的五大优势,云厂商同样也是通过规模化和技术创新来提供这些优势。

Serverless 并不等于 FaaS
大部分人开始了解Serverless时,会有一个误区,以为Serverless就是FaaS,比如AWS的Lambda,Google的Cloud Function。但深入研究就会发现,Serverless实际上涵盖了一系列技术,我们将这些技术分为两类:Backend as a Service(BaaS)和Functions as a Service(FaaS),所以,简单来说Serverless=BaaS+FaaS。

BaaS
BaaS就是用现成的第三方服务替换原来自己编码实现或者自己搭建的服务器端组件,它在概念上更接近于Software as a Service(SaaS),不同之处在于SaaS通常是关于外包业务流程,比如人力资源或销售工具,或者像Github这样的服务技术工作者的产品。然而对于BaaS来说,实际上是将应用程序分解成更小的组件,并将其中一部分组件用第三方提供的服务来完成,这个第三方服务通常就叫做BaaS。
BaaS服务是通过API远程调用的组件,而不是SDK,或者Library,我们通过远程API的调用,来完成应用程序的一部分功能。这里有一个很好的例子是身份验证,许多应用程序通过自己的代码来实现注册、登录、密码管理等功能,但是这些代码在很多应用程序中非常相似,同样的事情无数的公司和团队做过了无数遍,已经非常成熟了,可以把它们抽象出来变成一个第三方公共服务再好不过,这正是Auth0和亚马逊的Cogono等产品的目标,这两种产品都允许任何人,不需要写一行代码的情况,就可以在移动应用程序和Web应用程序上实现非常完善的身份验证和用户管理功能。

BaaS最早的时候,在移动应用程序开发中特别受欢迎,一开始人们甚至把它叫做Mobile Backend as a Service(MBaaS),但是实际上,BaaS除了被用作移动应用的后端服务之外,还可以应用到非常多的场景,比如我们可以不需要自己搭建和维护Mysql实例,而是使用亚马逊的RDS服务,或者可以用Kinesis替换自己搭建和管理的Kafka消息队列,其他数据基础设施服务包括文件系统、对象存储和数据仓库、语音分析、以及我们之前提到的身份验证,这些服务都是BaaS,都可以作为一个应用的后端服务的一部分。

FaaS
Serverless的另一半是FaaS, FaaS是Compute as a Service的另一种形式,概念上容易混淆的地方在于,AWS有时候将自己的FaaS服务,Lambda,称为Serverless Compute。
FaaS是一种构建和部署服务器端软件的新方法,只不过粒度更细,能够独立的部署某一个函数,许多人认为Serverless就是FaaS,但是实际上并不完全正确。
我们通过传统方式部署服务器端软件时,从主机实例开始,通常是虚拟机(VM)实例或容器(参见下图), 然后我们在主机中部署应用程序,如果主机是VM或容器,那么应用程序是一个操作系统进程, 通常我们的应用程序中的代码实现了一些不同功能的操作,例如,Web服务提供检索和更新资源的操作。

pic2.jpg



FaaS改变了这种部署模式(如下图), 部署模型中少了主机实例和应用程序进程,我们只关注实现应用程序逻辑的各个操作和函数,将这些函数代码单独上传到云供应商提供的FaaS平台。

pic3.jpg



但是,这些函数在云服务托管的服务器进程中缺省处于空闲状态,直到需要它们运行的时候才会被激活(如下图), 通过配置FaaS平台来监听每个函数的激活事件。 当该事件发生时,FaaS平台实例化函数,然后使用触发事件调用它。

pic4.jpg



一旦该函数执行结束了,理论上FaaS平台可以销毁掉实例,不过,通常为了优化性能,会将函数实例保留一段时间,可以被下一个事件复用。
FaaS本质上是一种事件驱动的模型,除了提供托管和执行代码的平台之外,FaaS平台还集成了各种同步和异步事件源,HTTP API网关就是一种同步事件源,消息总线、对象存储或类似于(cron)的定时器就是一种异步源。
AWS在2014年就推出了Lambda,到目前为止成熟度和接受度已经获得大幅的提高,一些公司每天在使用Lambda处理数十亿的事件,到目前为止,Lambda集成了超过20种不同类型的事件源,可以支持各种不同类型的应用程序。
除了AWS Lambda之外,还有其他一些来自Microsoft,IBM,Google厂商的商业FaaS产品,正如我们之前讨论的各种其他计算即服务平台(IaaS,PaaS,CaaS)一样,也有可以运行在私有云上开源FaaS项目,私有的FaaS领域目前比较早期,没有绝对的领先者,一些比较活跃的项目有OpenWhisk、Fission、IronFuncions、Serverless、Nuclio等。

为什么FaaS和BaaS都叫Serverless?
从表面上看,BaaS和FaaS完全不同,BaaS是托管应用程序的一部分依赖组件,FaaS托管应用程序的代码,那么为什么我们把它们放在一起,都叫做Serverless呢?
这里的关键就是不需要管理自己的服务器主机或服务器进程,完全使用Serverless架构的应用程序,将不再需要考虑服务器或者进程,应用程序的所有逻辑。无论您是自己编写的,还是与第三方服务集成的部分,都运行在完全弹性的环境中,状态也采用以类似弹性的形式存储,无服务器并不意味着服务器已经消失,这只是意味着着您不再需要关心它们了。

Serverless带给云计算的重大变化
在云计算过去十年的发展中,我们已经将应用程序的运行环境和通用组件,越来越多的外包给云厂商。Serverless也同样符合这一趋势,主机管理、操作系统管理、资源分配、扩展、甚至应用逻辑的整个组件,都外包给云厂商,在成本和运营效率方面获得了显著的提升。
但是,在应用程序架构方面,Serverless有很大的变化。之前的云计算服务,并没有从根本上改变设计应用程序的方式,例如,当使用Docker这样的工具时,我们在应用程序周围放置了一个更薄的“盒子”,但它仍然是一个盒子,逻辑架构不会发生显著的变化,在云中托管MySQL实例时,我们仍然需要考虑工作负载所需的虚拟机资源,而且仍需要考虑故障切换。

这种情况随着Serverless而发生变化,并且是非常大的变化,FaaS本质上是和传统架构非常不一样的架构类型——事件驱动模型。它的部署方式更加细粒度,以及需要将状态保存到FaaS组件之外,BaaS使我们无需编写完整的逻辑组件,但需要将应用程序与云厂商提供的特定接口和模型集成。
那么,Serverless的应用程序架构到底有什么不同之处,它看起来到底长什么样子? 这是我们接下来要讨论的内容。

2019年企业云服务的十一大趋势

Rancher 发表了文章 • 1 个评论 • 468 次浏览 • 2019-01-17 10:57 • 来自相关话题

云计算已成为企业应用程序的主要范式。 随着企业使其计算和网络架构现代化,云原生架构是主要的目标环境。 随着2019年的到来,很明显,无所不包的云计算趋势并未放缓。 以下是我对今年这个充满活力的市场的预测。 ...查看全部
云计算已成为企业应用程序的主要范式。 随着企业使其计算和网络架构现代化,云原生架构是主要的目标环境。



随着2019年的到来,很明显,无所不包的云计算趋势并未放缓。 以下是我对今年这个充满活力的市场的预测。



软件即服务(SaaS)提供商将深化他们的企业应用程序投资组合



显然,Oracle、SAP、Salesforce.com和其他SaaS提供商将无法削弱Amazon Web Services、Microsoft Azure和谷歌云平台在公共云市场的平台即服务(PaaS)和基础设施即服务(IaaS)领域所享有的势头。为了在这种趋势下保持增长,并防止占主导地位的PaaS/IaaS提供商侵占它们的地盘,SaaS提供商将加倍投资于企业资源规划、人力资源、客户关系管理和其他业务应用程序。2019年,我们将看到SaaS提供商推出更广泛的垂直行业产品,同时深化这些服务的AI驱动数字助理,嵌入式推荐器和机器人自动化流程功能,以提高用户的工作效率。



企业将会加速把应用程序、工作量和数据迁移到云原生主干网



越来越多的商业混合和multicloud工具将加速并降低将企业IT资源从现有遗留平台转移到原生云PaaS和IaaS平台的成本。



2019年,更多的企业将在不需要重写现有应用程序的情况下编辑遗留工作量,从而降低与复杂迁移相关的技术风险。公有云提供商将优先考虑提供迁移工具、multicloud底板和专业服务,以帮助企业以可控的风险来快速、经济有效地执行这些迁移。



公有云提供商将完全托管的内部设备定位为其混合云入口



去年,亚马逊Amazon Web Services宣布推出AWS Outposts,这是一种完全托管的基于计算/存储机架的服务,允许客户使用现有的VMware许可证在其场内运行选定的公有云服务。在2019年末发布之后,我们将看到这个解决方案是否能够引起企业的响应,这些企业可能仍然不确定如何平衡安全性、遵从性和延迟问题(这些问题迫使他们将计算资源保留在原有的平台上)与迁移到公有云的可伸缩性、效率和敏捷性优势之间的关系。



为了在Outposts发布之前削弱AWS在混合云领域的势头,AWS的公有云竞争对手将增强和推广其现有的混合云本地计算/存储机架。然而,Microsoft Azure Stack、IBM Cloud Private、Oracle Cloud At Customer等公司在将现有企业客户迁移到其各自的公有云的战略推进中,是否会为这些供应商提供任何优势,仍然值得怀疑。






随着核心开源代码库的稳定,Kubernetes的应用将会加速



核心的Kubernetes开源平台显示出成熟的迹象,因为贡献的总数已经放缓,提交速度正在减慢。2019年,Kubernetes生态系统的创新将转向在外部GitHub组织中在CNCF外部管理的项目。



在商业化方面,新兴的Kubernetes生态系统中的启动活动和产品发布将会增长,性能、安全性、自动化、可伸缩性、集群管理、边缘优化本地编辑、应用程序负载平衡和无服务器提取将成为创新和采用的巨大焦点。



解决方案提供商将把他们的Kubernetes实现构建到成熟的网络操作系统中



Kubernetes正在成为供应商管理的工具、服务和集成底板的投资组合的基础,这些工具、服务和集成底板可以支持用于虚拟化、本地编辑化和无服务器应用程序环境的日益复杂的网络操作系统。2019年,所有领先的公有云提供商将在各自的Kubernetes实现上进行更深入的投资,其中亚马逊网络服务(Amazon Web Services)、微软(Microsoft)、谷歌、IBM及其红帽(Red Hat)子公司、甲骨文(Oracle)、思科系统(Cisco Systems)、威睿(VMware)和阿里巴巴(Alibaba)将保持领先。



容器将越来越多地跨越有状态和无状态语义



云原生环境正在发展,通过扩展存储架构支持有状态交互,同时为跨混合无服务器multicloud的无状态、事件驱动型计算的下一个飞跃提供了基础。2019年,更多的企业将在Kubernetes上采用Knative实现无服务器功能,同时部署新一代存储解决方案,优化了容器结构中的持久性。



服务网格将成为云计算中最主要的网络管理底板



在云原生行业服务网络计划的进展中,最值得注意的是,Istio、Envoy和LinkerD将提升这些项目在企业multicloud计算中的显著性。到2019年,许多企业将把服务网格纳入其努力的核心,即在其分布式计算环境中,在本地编辑内部资源和越来越多的公有和私有云结构之间搭建灵活的桥梁。云提供商将加强对托管服务的支持,这些托管服务简化了通过网格和中心辐条架构对数千个虚拟私有云和内部网络的互联和管理。



Cloud-to-edge分布式计算结构将会扩展



在过去的一年中,供应商向市场推出了一系列创新的边缘网关、本地计算/存储机架和设备级别的容器运行时。到2019年,这些创新将汇聚成一个面向边缘、分布式和联合的本地云计算结构,使数据、应用程序和工作量更灵活地分布到代理点附近。



随着物联网成为云计算的主要入口,“AIOps” IT管理自动化工具遍布整个结构,“数据中心”的概念将为完全分散管理的“软件定义的数据中心”所代替。



在这个Cloud-to-edge的计算结构中,区块链和其他超级账本的主干网将不断发展,为所有网络、系统和应用程序级的操作提供不可变的审计日志。






本地编辑将转换网络路由平面



虚拟区域网络操作系统将变为云原生,将所有协议和管理功能放在微服务中,并使用通过Kubernetes编排的不可变本地编辑。



到2019年,更多的网络运营商将能够通过开发运维持续集成和持续部署工作流来管理路由和流量管理功能的更新。这将允许网络运营商只部署所需的网络功能,从而降低复杂性和减少网络攻击面。



云原生开发运维工具将融合虚拟化、容器化和无服务器



企业客户要求能够组合云原生微服务,以便在虚拟机、容器和无服务器结构的各种协调混合中执行。到2019年,我们将看到更多的开发工具将迄今为止不同的程序聚合在一起,并使CI/CD能够跨日益异构的multicloud,这些multicloud将Kubernetes集群联合起来,同时为无状态、事件驱动的微服务的轻量级开发提供无服务器接口。



这种应用程序范例聚合的关键是“基础设施即代码”工具,这些工具支持云原生应用程序结果的声明性规范,以驱动必要本地编辑、无服务器功能、分布式编排和其他应用程序逻辑的自动编译和部署。



容器化的微服务市场将会扩大



公有云提供商已经建立了他们的可信本地编辑化解决方案的在线市场,这些解决方案包括他们自己的产品和不断增长的合作伙伴生态系统。 在2019年,我们将看到这些市场在所提供的解决方案的范围和多样性得到扩展,因为公有云提供商更多地关注合作伙伴,软件供应商将这些渠道作为其主要的市场进入方法。



为了帮助客户实施针对其用户采用基于云的解决方案的策略,公有云提供商将提供私有市场功能,使企业采购人员能够定义和管理与组织策略一致的、经过批准的、经编辑的云就绪解决方案列表。



原文链接



https://www.infoworld.com/article/3328860/cloud-computing/key-enterprise-cloud-trends-for-2019.html?upd=1547605102533

不同于混合云,你了解云计算的下一阶段——“多云”吗?

Rancher 发表了文章 • 1 个评论 • 504 次浏览 • 2019-01-11 13:50 • 来自相关话题

也许你会认为“多云”和“混合云”是一个意思,其实在云计算的发展演进过程中,这二者处于的是不同阶段。 人们喜欢给一切东西命名。在云计算领域,一项技术或产品的命名通常反映着它的使用方式:公有云,私有云,混合云。 ...查看全部
也许你会认为“多云”和“混合云”是一个意思,其实在云计算的发展演进过程中,这二者处于的是不同阶段。



人们喜欢给一切东西命名。在云计算领域,一项技术或产品的命名通常反映着它的使用方式:公有云,私有云,混合云。现在,“多云”这个新术语又出现了,它象征的是云计算的另一种新兴模式。



术语及定义



“多云”意味着使用多个公有云。当企业试图避免依赖单个公有云提供商,或当企业需要从每个公有云中选择不同的、特定的功能或服务,又或者上述两个目的兼而有之时,就会出现“多云”这种使用模式。



“多云”与“混合云”的区别



那么,多云(multicloud)和混合云(hybrid cloud)是什么关系?有些人会互换使用这两个词,但实际上它们确实有不同的含义。 混合云是私有云(基于云技术构建的本地数据中心)与公有云的配对。



如果您将多个公有云与私有云一起使用,那么这仍然是一个“多云”。 (有些人可能会称它为混合多云,这也是可以的。)



“实用混合云”的定义



近期还有一种新出现的概念/架构叫做“实用混合云(pragmatic hybrid cloud)”,它是指将传统企业数据中心与公有云的配对一起使用。这样用法的企业很多是对私有云感到失望,因此寻求一种将现有的云与公有云相结合的方法。



相比之下,多云架构使用的两个或更多公有云。




多云趋势的背后是什么



云计算正在变得越来越复杂,这是大家无可否认的趋势。几年前很多企业的愿景是能够将工作负载放在单个云上,无论是公有云还是私有云。但随着时间推移,混合云架构变得更具吸引力,因为它为企业提供了更多选择。



企业IT需要这样的选择,因为在亚马逊AWS之外,美国的谷歌、微软以及中国的华为、阿里、腾讯等其他巨头公司都开发了引人注目的公有云平台,为企业提供了除了AWS之外的更多启动公有云业务的可行替代方案。还有其他企业提供商——包括IBM、惠普、甲骨文等等——也加入了竞争,尽管目前这些公有云方案尚不如业界领先的几家成功。



正是由于公有云的可选择项越来越多,因此企业开始将它们混合在一起使用,无论是通过正式的架构流程还是通过“影子IT”(即公司中有团队在不让企业IT部门知晓的情况下,自己使用某种公有云)。各种影子IT经常选择不同的公有云,然后又希望企业IT部门能来管理这些云的运维工作。



总的来说,无论是用何种形式和方法,大多数企业现在都在管理着多云基础设施。



虽然许多IT组织在管理这些复杂的多云环境时,使用的是来自每个云的原生工具和服务,但也越来越多的企业变得越来越聪明,开始借助平台或工具,将自身从多云管理的复杂工作中抽离出来。



通过使用云管理平台(CMP)和云服务代理(CSB)等工具,企业可以像管理单个云一样管理多个云。但是,这里需要权衡的是,您也许只能使用每个云的一部分功能;也就是说,采取的是“最小公分母”的方法。



建议:关注云技术的作用而非名称



公共云,私有云,混合云,实用混合云,多云……语义超载?确实。



但是,我建议你不要被称谓困扰,而是专注于它们所做的事情。事实上,我相信云架构在未来几年也将有新的发展,并且新的模式也将继续出现。我也肯定,更多的新名字即将到来。


------------



作者介绍



David S. Linthicum



Deloitte Consulting的首席云战略官,也是国际公认的行业专家和思想领袖。Dave撰写过共计13本关于计算的书籍,担任过多家成功软件公司的首席技术官和首席执行官,以及财富100强公司的高级管理职位。他关注云计算、SOA、企业应用程序集成和企业架构的相关领域。



------------



原文链接:



https://www.infoworld.com/article/3226484/cloud-computing/what-is-multicloud-the-next-step-in-cloud-computing.html



下一代云计算:低熵云 | 演讲实录 (附PPT下载)

博云BoCloud 发表了文章 • 0 个评论 • 628 次浏览 • 2018-12-17 16:43 • 来自相关话题

12月5日,由BoCloud博云主办的IT进化大会·2018在北京圆满落幕。中科院计算所先进计算机系统研究中心主任包云岗分享了《下一代云计算:低熵云》的主题演讲,为现场嘉宾带来了学术界前沿研究的精彩介绍,获得了广泛关注。经包教授授权,我们将现场演讲整理出来分享 ...查看全部
12月5日,由BoCloud博云主办的IT进化大会·2018在北京圆满落幕。中科院计算所先进计算机系统研究中心主任包云岗分享了《下一代云计算:低熵云》的主题演讲,为现场嘉宾带来了学术界前沿研究的精彩介绍,获得了广泛关注。经包教授授权,我们将现场演讲整理出来分享给大家。


嘉宾介绍
包云岗,现为中科院计算所研究员,博士生导师,先进计算机系统研究中心主任,中国科学院大学岗位教授。研究方向是计算机系统结构,主持研制多款达到国际先进水平的系统,在国际会议期刊发表了40余篇论文,多次受邀担任ASPLOS、ISCA、MICRO、SC等国际顶级会议程序委员会委员。担任中国计算机学会理事、普及工作委员会主任,中科院青年创新促进会理事,ACM China副主席。


大家好,今天和大家一起从学术界的角度,来探讨云计算现在发展到什么样的状况,以及未来发展还会有哪些新的趋势。我们希望探讨的前沿技术可以在创业公司里帮助整个IT技术部门更好地服务更多客户。

幻灯片2.JPG

首先我们看一下过去十年,云计算经历了两个大的阶段。早期是虚拟化技术的使用,在云里面用了很多的虚拟化技术,比如Xen、VMware等等,但是后来大数据逐渐开始流行,越来越多的云平台或者数据都开始为大数据分析进行服务。横坐标是数据中心资源的利用率,纵坐标是用户体验,慢慢的利用率与用户体验就会分化,我们的应用分为两大类,有的应用是对用户体验要求特别高,有的是吞吐要求特别高,把系统的资源充分的利用起来,这是一个发展的阶段。


幻灯片3.JPG

但是随着这样的阶段往下走,我们的现状会出现什么情况?现状一:基础设施成本极高。为了服务这种大而新的业务,我们的基础设施投入越来越大,成本越来越高,这是微软的一位朋友在西雅图做基础设施给的数据,是2015年的数据,他说现在已经超过三百亿美元,这还是一个公司的投入,当然我们国内的公司也是投入很大,像阿里在张北的数据中心,都是上百亿。


幻灯片4.JPG

现状二:数据中心利用率极低。我们可以看到,其实数据中心利用率很低,并没有我们想象得那么高。一方面投入这么大,左边的这个图实际上是亚马逊在2011年左右的数据,稍微有点老,但是当时它测了一周的AWS整个利用率,大概是7%到17%,右边这个图是国内的运算数据中心,大部分的机器利用率还是低于20%,所以现在我们很多企业特别上规模的企业希望可以把整个系统的利用率充分提升。但是,这个提升不是那么简单的,背后有很多的技术挑战。


幻灯片5.JPG

现状三:用户体验不稳定。在提升技术的时候,还要保证用户体验,因为用户是第一位的。而现有的云计算或者数据中心平台,在用户体验保障上做得有很多问题,所以导致了Facebook这样的公司在亚马逊上用云的时候会占很多,但是用的很少。我们总结这个词语叫Stranding:占而不用。全世界来看这是数据中心面临很大的一个问题,你不得不超载或者需要提供额外多的资源来满足用户体验。


幻灯片6.JPG

我们看背后的因素,这里面我们可以看到Facebook用了很多的Memcached,基本上100个微秒请求就可以返回去,当利用率提高到70%的时候,有一批用户的用户体验就会非常糟糕,会比原来要增长十倍,所以现在在云里面是面临云计算系统性不稳定的巨大挑战。


幻灯片7.JPG

云计算下一个十年的发展是要提供高品质的云计算。我们希望云可以同时提供高的资源利用率和好的用户体验,只有这样我们才可以更方便地把与用户体验相关的应用放到云上去,当然我们还有其他的需求,比如安全等等,这里我就暂时不看安全的问题。


幻灯片8.JPG

这个判断实际上也不光是我们,而是业界一个共识。我们看到谷歌数据中心专家Amin Vahdat,在去年ONS的keynote讲到了Cloud 3.0应该关注隔离。HotDC研讨会上斯坦福Christos Kozyrakis教授讲到在新一代Cloud 3.0里低延迟是非常关键的。所以我们可以看到这是国际的共识,我们未来的发展都会朝这个方向前进。



幻灯片10.JPG

为什么延迟很重要?而且实现低延迟很难,是一个挑战。我想在座应该有一些做技术的朋友,我们做一个实验,如果一台服务器上跑一个应用,这种场景最后出来的结果会是什么样?



幻灯片11.JPG

这是我们做过的实验,跑一万次出来的数据,如果看执行时间这里有一个分布,这个时间分布是非常非常稳定的,波动幅度小于1%,但是整个机器只有一个应用,显然不是我们希望的。


幻灯片12.JPG

真正的服务器会在上面跑很多应用,我们把整个系统的应用率可以提上来,这是典型的共享云服务器。如果达到这样的水平,我们再来看一下刚才类似的例子会怎么样,这是谷歌的测试,我们布到这样的服务器上,处理一万个请求,可以看到时间分布,好像在前面很像,但是我们看横坐标是对冲坐标时间波动范围是在6到10倍,当你在云的环境下去测这些,是很容易产生很大的波动的。


幻灯片14.JPG

我们自己在学术界想要去尝试刻画这种现象,那么我们怎么刻画?我们认为熵是很好的描述不确定性和无序的度量,所以我们觉得未来得发展应该是低熵的云计算系统。首先是一种有序的、可控的计算系统,从而可以提高我们的利用率,比如说把系统整个利用率提高到60%以上,但是在这个前提上我们可以保证用户体验,可以达到很低的延迟,可控,还是需要通用的支持不同的云平台,这是我们的愿景。


幻灯片16.JPG

事实上现在的云更像是一朵乌云,我们看到一个基础设施是由两方面驱动的,一方面是应用,另一方面是底层技术,底层的器件架构。我们可以看到上面应用有大数据、人工智能等不断地在云里部署,开发人员越来越喜欢高级的语言等等,非常容易就可以训练大家在云上开发,还有微服务和Serverless新的形式不断地布到云上,这些都驱动云平台在基础设施上有相应的变化。

底层也是一样,越来越多异构的硬件、加速器、资源池、超融合和新型的SSD不断在云上布,我们云的设施化变成了一个大熔炉了,越是复杂越是熔炉,如果你没有管理和控制,它就会带来很大的问题,这是当前云的基础设施一定程度像无序共享的状态。


幻灯片17.JPG

大家都玩微信,我们有一半时间是在腾讯的数据中心里完成的,没去测点到点的实践,但如果你测出来,时间分布会是像图中这样的,这个是微软在北美测的数据,可以看到有很大的时间波动。这种时间波动在我们玩微信的时候可以接受,但是如果未来假设无人驾驶也要接入到云,比如AR/VR要到云端互动,这样的延迟会波动到两秒钟、四秒钟甚至到十秒钟,这肯定是不能接受的。这就是今天的云计算面临的很大问题,不能让更多的应用部署到云里。


幻灯片18.JPG

给大家介绍下我们的工作,我们在几年前得到国家的一些支持,来做云基础理论方面的研究。我们也在探讨,如果要去改变现在这种云的状况去实现低熵云计算系统,要做哪些变化?


幻灯片19.JPG

我们发现传统做云计算,虚拟化云基本上是虚拟机的调度,三十个毫秒,像分区,我把在线的分开,在物理上进行隔离,是可以保证比较好的应用性能和用户体验,但是资源利用率不高。而未来我们需要一种更细的调度机制,如果可以做到总线周期级调度,并且是纳秒级的,那么原来做不到的事情现在就可以做到,这是总的思路。我们希望实现非常细的调度机制,可以保证资源利用率以及用户体验。


幻灯片20.JPG

我们提出了实用可计算性理论,为了在设计系统时考虑用户体验因素,我们希望可以将云计算的重要实践经验形式化,比如说用户体验差的功能是不存在的功能,因为我们不想用(体验差的功能),所以这个是我们希望在理论上分析的。


幻灯片21.JPG

实际上我们有一个猜想,就是DIP猜想。你需要一个系统可以做到区分D、隔离I、优先化P,整个系统可以保证用户体验,同时可以提升利用率。



幻灯片22.JPG

但是真正要做到这一点还不是那么容易,因为今天最底层的计算机结构是不支持DIP的,底层结构包括存储、计算、输出输入是不支持DIP的。导致像右边这样的图,这个是美国联邦航空管理局测的数据,我们可以看到在飞机上是不敢用多核的,因为当你有多个应用一起跑的时候,计算机性能非常不确定,所以有时候实时系统里和我们云计算场景有很多类似的地方。


幻灯片23.JPG

我们实际上也提出了一种标签化冯诺依曼的体系结构。提供一套标签,用标签把不同的东西识别出来,对不同的标签进行控制,我们花了很多的时间,也有不少的进展。


幻灯片27.JPG

标签化思想的应用,可以在处理器里、可以在存储里,比如存储容器是我们在做的,也可以做到别的网络协议栈里,就是把不同的标签区分出来。


幻灯片25.JPG

举例,我们说标签化存储容器,就是用标签做协同的控制来做流量和用户的保障。大家可以看到如果用标签可以保证用户体验的情况下,把资源利用率提升1.5倍。


幻灯片27.JPG

还有一个例子是调度。以前的调度我们在计算机里有很多,但是这些调度都是独立的,每个人自己做自己的,如果我们用标签打破,可以让它们相互感受,我们就可以做到更好的调度。如果用这种方式,我们可以把整个用户所谓的延迟降低2.5倍,当然我们也是做了一些Bench的测试,混合场景下把应用布上去看企业和资源利用率之间的联系。


幻灯片30.JPG

前面都是想法,但是实际上我们已经真正实现了。这是我们做的火苗系统,是基于RISC-V做的一个小的集群,这里面有8个节点,每个节点都是标签化的,可以保证用户体验,提升用户体验率。我们跟Berkeley今年6月份推出的达到了相当的水平,我们有自己的特色,所以国内很多的大学,清华北大和天津大学还有深圳的大学都在这个平台上做企业的研究,包括用它开本科生的课程。


幻灯片31.JPG

标签可以用来做什么?我举几个例子,比如我们可以把传统的虚拟化层去掉,把它通过标签放到硬件里,假如没有容器,我们就可以把整个系统做隔离,用红线在物理上隔离,这条红线还可以左右的移动,是可编程的。


还有一个例子,可以做性能的隔离。这个例子是在火苗系统上,是一个四核的平台,我们在上面如果运行一个单独的应用,会把所有的资源占掉,这个时候它的性能还是不错的,上面那条横线其实可以看到当时的请求是几个毫秒,我们把其他三个分区跑起来,跑不同的应用,把资源利用率提上去,就可以看到最左边的应用性能开始波动了,但是整个一些资源就开始竞争了,这个时候我们标签的机制进行隔离,我们把红色的应用实行90%的高速缓存,所以你可以看到占到将近90%,我们也把带宽做约束,使用更多的带宽,这样很快就可以看到它的性能不再波动了,开始往下降,回到原来单独运行的状态,而整个系统的利用率,实际上已经是比原来大大的提升了,因为你有其他三个应用在同时运行,所以这种方式我们就可以做到把利用率提升的情况下还可以保证在线应用的实时响应,所有都是开源的。


幻灯片34.JPG

今年我是被邀请到剑桥介绍标签化技术,因为ARM希望在他们的芯片里实现表现机制的隔离形式,我们本身成立了联盟,叫做中国开放指令生态联盟,是希望可以推动开源芯片的生态。

幻灯片36.JPG

未来的云计算,低熵云计算还有很多的挑战。一方面我们看到请求,很多应用的延迟需求是很高的,从毫秒级甚至到微秒级。我们希望云上有更多的用户用,很多的用户希望用python写程序,大家可以看到以一个写python程序的人,如果你不经过优化,这个程序和我由一个懂计算机系统的人,计算机体系结构芯片技术人写出来的程序差了六万多倍,这里面这么大的性能差异,我们可以是在云平台层次上优化和改进的,这是给我们提供了很多优化的空间。


幻灯片37.JPG

云计算还有很多的事情可以做,我们还有很多的空间可以挖掘,可以让用户体验更好。软件定义计算,可以解决我们系统的思路,希望能去定义实现智能云的设施,我们在每个层次都可以快速应用开发和部署,也可以实现智能定义的形式,包括智能自组合的操作等等。以上就是我跟大家分享的我们的想法,谢谢。



如何在 Kubernetes 之上架构应用?

piglei 发表了文章 • 0 个评论 • 1564 次浏览 • 2018-08-05 21:51 • 来自相关话题

# 简介 设计并运行一个兼顾可扩展性、可移植性和健壮性的应用是一件很有挑战的事情,尤其是当系统复杂度在不断增长时。应用或系统本身的架构极大的影响着其运行方式、对环境的依赖性,以及与相关组件的耦合强弱。当应用在一个高度分布式的环境中运行时,如果能在设 ...查看全部
# 简介
设计并运行一个兼顾可扩展性、可移植性和健壮性的应用是一件很有挑战的事情,尤其是当系统复杂度在不断增长时。应用或系统本身的架构极大的影响着其运行方式、对环境的依赖性,以及与相关组件的耦合强弱。当应用在一个高度分布式的环境中运行时,如果能在设计阶段遵循特定模式,在运维阶段恪守特定实践,就可以帮助我们更好的应对那些最常出现的问题。

尽管软件设计模式和开发方法论可以帮助我们生产出满足恰当扩展性指标的应用,基础设施与运行环境也在影响着已部署系统的运维操作。像 DockerKubernetes 这些技术可以帮助团队打包、分发、部署以及在分布式环境中扩展应用。学习如何最好的驾驭这些工具,可以帮助你在管理应用时拥有更好的机动性、控制性和响应能力。

在这份指南里,我们将探讨一些你可能想采用的准则和模式,它们可以帮助你在 Kubernetes 上更好的扩展和管理你的工作集(workloads)。尽管在 Kubernetes 上可以运行各种各样的工作集,但是你的不同选择会影响运维难度和部署时的可选项。你如何架构和构建应用、如何将服务用容器打包、如何配置生命周期管理以及在 Kubernetes 上如何操作,每一个点都会影响你的体验。
# 为可扩展性做应用设计
当开发软件时,你所选用的模式与架构会被很多需求所影响。对于 Kubernetes 来说,它最重要的特征之一就是要求应用拥有水平扩展能力——通过调整应用副本数来分担负载以及提升可用性。这与垂直扩展不同,垂直扩展尝试使用同样的参数将应用部署到性能更强或更弱的服务器上。

比如,微服务架构是一种适合在集群中运行多个可扩展应用的软件设计模式。开发者们创建一些可组合的简单应用,它们通过良好定义的 REST 接口进行网络通信,而不是像更复杂的单体式应用那样通过程序内部机制通信。将单体式应用拆分为多个独立的单一功能组件后,我们可以独立的扩展每个功能组件。很多之前通常存在于应用层的组合与复杂度被转移到了运维领域,而它们刚好可以被像 Kubernetes 这样的平台搞定。

比特定的软件模式更进一步,云原生(cloud native)应用在设计之初就有一些额外的考量。云原生应用是遵循了微服务架构模式的程序,拥有内置的可恢复性、可观测性和可管理性,专门用于适应云集群平台提供的环境。

举例来说,云原生应用在被创造出时都带有健康度指标数据,当某个实例变得不健康时,平台可以根据指标数据来管理实例的生命周期。这些指标产生(也可以被导出)稳定的遥控数据来给运维人员告警,让他们可以依据这些数据做决策。应用被设计成可以应付常规的重启、失败、后端可用性变化以及高负载等各种情况,而不会损坏数据或者变得无法响应。
## 遵循 “12 法则应用”应用理论
在创建准备跑在云上的 web 应用时,有一个流行的方法论可以帮你关注到那些最重要的特征:“12 法则应用理论”( Twelve-Factor App)。它最初被编写出来,是为了帮助开发者和运维团队了解所有被设计成在云环境运行的 web 服务的共有核心特征,而对于那些将在 Kubernetes 这种集群环境中运行的应用,这个理论也非常适用。尽管单体式应用可以从这些建议中获益,围绕这些原则设计的微服务架构应用也会工作的非常好。

“12 法则”的一份简单摘要:

  1. 基准代码(Codebase):将你的所有代码都放在版本控制系统中(比如 Git 或者 Mercurial)。被部署的内容完全由基准代码决定。
  2. 依赖(Dependencies):应用依赖应该由基准代码全部显式管理起来,无论是用 vendor(指依赖代码和应用代码保存在一起),还是通过可由包管理软件解析安装的依赖配置文件的方式。
  3. 配置(Config):把应用配置参数与应用本身分开来,配置应该在部署环境中定义,而不是被嵌入到应用本身。
  4. 后端服务(Backing Services):本地或远程的依赖服务都应该被抽象为可通过网络访问的资源,连接细节应该在配置中定义。
  5. 构建、发布、运行(Build, release, run):应用的构建阶段应该完全与发布、运维阶段区分开来。构建阶段从应用源码创建出一个可执行包,发布阶段负责把可执行包和配置组合起来,然后在运行阶段执行这个发布版本。
  6. 进程(Processes):应用应该由不依赖任何本地状态存储的进程实现。状态应该被存储在第 4 个法则描述的后端服务中。
  7. 端口绑定(Port binding):应用应该原生绑定端口和监听连接。所有的路由和请求转发工作应该由外部处理。
  8. 并发(Concurrency):应用应该依赖于进程模型扩展。只需同时运行多份应用(可能分布在不同服务器上),就能实现不调整应用代码扩展的目的。
  9. 易处理(Disposability):进程应该可以被快速启动、优雅停止,而不产生任何严重的副作用。
  10. 开发环境与线上环境等价(Dev/prod parity):你的测试、预发布以及线上环境应该尽可能一致而且保持同步。环境间的差异有可能会导致兼容性问题和未经测试的配置突然出现。
  11. 日志(Logs):应用应该将日志输出到标准输出(stdout),然后由外部服务来决定最佳的处理方式。
  12. 管理进程(Admin processes):一次性管理进程应该和主进程代码一起发布,基于某个特定的发布版本运行。

依照“12 法则”所提供的指南,你可以使用完全适用于 Kubernetes 运行环境的模型来创建和运行应用。“12 法则”鼓励开发者们专注于他们应用的首要职责,考虑运维条件以及组件间的接口设计,并使用输入、输出和标准进程管理功能,最终以可被预见的方式将应用在 Kubernetes 中跑起来。
# 容器化应用组件
Kubernetes 使用容器在集群节点上运行隔离的打包应用程序。要在 Kubernetes 上运行,你的应用必须被封装在一个或者多个容器镜像中,并使用 Docker 这样的容器运行时执行。尽管容器化你的组件是 Kubernetes 的要求之一,但其实这个过程也帮助强化了刚刚谈到的“12法则应用”里的很多准则,从而让我们可以简单的扩展和管理应用。

举例来说,容器提供了应用环境与外部宿主机环境之间的隔离,提供了一个基于网络、面向服务的应用间通信方式,并且通常都是从环境变量读取配置、将日志写到标准输出与标准错误输出中。容器本身鼓励基于进程的并发策略,并且可以通过保持独立扩展性和捆绑运行时环境来帮助保持开发/线上环境一致性(#10 Dev/prod parity)。这些特性让你可以顺利打包应用,从而顺利的在 Kubernetes 上运行起来。
## 容器优化准则
因为容器技术的灵活性,我们有很多不同种封装应用的方式。但是在 Kubernetes 环境中,其中一些方式比其他方式工作的更好。

镜像构建(image building),是指你定义应用将如何在容器里被设置与运行的过程,绝大多数关于“如何容器化应用”的最佳实践都与镜像构建过程有关。通常来说,保持镜像尺寸小以及可组合会带来很多好处。在镜像升级时,通过保持构建步骤可管理以及复用现有镜像层,被优化过尺寸的的镜像可以减少在集群中启动一个新容器所需要的时间与资源。

当构建容器镜像时,尽最大努力将构建步骤与最终在生产环境运行的镜像区分开来是一个好的开始。构建软件通常需要额外的工具、花费更多时间,并且会生产出在不同容器里表现不同、或是在最终运行时环境里根本不需要的内容。将构建过程与运行时环境清晰分开的办法之一是使用 Docker 的“多阶段构建(multi-stage builds)” 特性。多阶段构建配置允许你为构建阶段和运行阶段设置不同的基础镜像。也就是说,你可以使用一个安装了所有构建工具的镜像来构建软件,然后将结果可执行软件包复制到一个精简过的、之后每次都会用到的镜像中。

有了这类功能后,基于最小化的父镜像来构建生产环境镜像通常会是个好主意。如果你想完全避免由 `ubuntu:16.04`(该镜像包含了一个完整的 Ubuntu 16.04 环境)这类 “Linux 发行版” 风格父镜像带来的臃肿,你可以尝试用 `scratch` - Docker 的最简基础镜像 - 来构建你的镜像。不过 `scratch` 基础镜像缺了一些核心工具,所以部分软件可能会因为环境问题而无法运行。另外一个方案是使用 Alpine Linux 的 `alpine` 镜像,该镜像提供了一个轻量但是拥有完整特性的 Linux 发行版。它作为一个稳定的最小基础环境获得了广泛的使用。

对于像 Python 或 Ruby 这种解释型编程语言来说,上面的例子会稍有变化。因为它们不存在“编译”阶段,而且在生产环境运行代码时一定需要有解释器。不过因为大家仍然追求精简的镜像,所以 Docker Hub 上还是有很多基于 Alpine Linux 构建的各语言优化版镜像。对于解释型语言来说,使用更小镜像带来的好处和编译型语言差不多:在开始正式工作前,Kubernetes 能够在新节点上快速拉取到所有必须的容器镜像。
# 在 Pod 和“容器”之间做选择
虽然你的应用必须被“容器”化后才能在 Kubernetes 上跑起来,但 pods(译注:因为 pod、service、ingress 这类资源名称不适合翻译为中文,此处及后面均使用英文原文) 才是 Kubernetes 能直接管理的最小抽象单位。pod 是由一个或更多紧密关联的容器组合在一起的 Kubernetes 对象。同一个 pod 里的所有容器共享同一生命周期且作为一个独立单位被管理。比如,这些容器总是被调度到同一个节点上、一起被启动或停止,同时共享 IP 和文件系统这类资源。

一开始,找到将应用拆分为 pods 和容器的最佳方式会比较困难。所以,了解 Kubernetes 是如何处理这些对象,以及每个抽象层为你的系统带来了什么变得非常重要。下面这些事项可以帮助你在使用这些抽象概念封装应用时,找到一些自然的边界点。

寻找自然开发边界是为你的容器决定有效范围的手段之一。如果你的系统采用了微服务架构,所有容器都经过良好设计、被频繁构建,各自负责不同的独立功能,并且可以被经常用到不同场景中。这个程度的抽象可以让你的团队通过容器镜像来发布变更,然后将这个新功能发布到所有使用了这个镜像的环境中去。应用可以通过组合很多容器来构建,这些容器里的每一个都实现了特定的功能,但是又不能独立成事。

与上面相反,当考虑的是系统中的哪些部分可以从独立管理中获益最多时,我们常常会用 pods。Kubernetes 使用 pods 作为它面向用户的最小抽象,因此它们是 Kubernetes API 和工具可以直接交互与控制的最原生单位。你可以启动、停止或者重启 pods,或者使用基于 pods 建立的更高级别抽象来引入副本集和生命周期管理这些特性。Kubernetes 不允许你单独管理一个 Pod 里的不同容器,所以如果某些容器可以从独立管理中获得好处,那么你就不应该把它们分到到一个组里。

因为 Kubernetes 的很多特性和抽象概念都直接和 pods 打交道,所以把那些应该被一起扩缩容的东西捆绑到一个 pod 里、应该被分开扩缩容的分到不同 pod 中是很有道理的。举例来说,将前端 web 服务器和应用服务放到不同 pods 里让你可以根据需求单独对每一层进行扩缩容。不过,有时候把 web 服务器和数据库适配层放在同一个 pod 里也说得过去,如果那个适配器为 web 服务器提供了它正常运行所需的基本功能的话。
## 通过和支撑性容器捆绑到一起来增强 Pod 功能
了解了上面这点后,到底什么类型的容器应该被捆绑到同一个 pod 里呢?通常来说,pod 里的主容器负责提供 pod 的核心功能,但是我们可以定义附加容器来修改或者扩展那个主容器,或者帮助它适配到某个特定的部署环境中。

比如,在一个 web 服务器 pod 中,可能会存在一个 Nginx 容器来监听请求和托管静态内容,而这些静态内容则是由另外一个容器来监听项目变动并更新的。虽然把这两个组件打包到同一个容器里的主意听上去不错,但是把它们作为独立的容器来实现是有很多好处的。nginx 容器和内容拉取容器都可以独立的在不同情景中使用。它们可以由不同的团队维护并分别开发,达到将行为通用化来与不同的容器协同工作的目的。

Brendan Burns 和 David Oppenheimer 在他们关于“基于容器的分布式系统设计模式”的论文中定义了三种打包支撑性容器的主要模式。它们代表了一些最常见的将容器打包到 pod 里的用例:

  • Sidecar(边车模式):在这个模式中,次要容器扩展和增强了主容器的核心功能。这个模式涉及在一个独立容器里执行非标准或工具功能。举例来说,某个转发日志或者监听配置值改动的容器可以扩展某个 pod 的功能,而不会改动它的主要关注点。
  • Ambassador(大使模式):Ambassador 模式使用一个支援性容器来为主容器完成远程资源的抽象。主容器直接连接到 Ambassador 容器,而 Ambassador 容器反过来连接到可能很复杂的外部资源池 - 比如说一个分布式 Redis 集群 - 并完成资源抽象。主容器可以完成连接外部服务,而不必知道或者关心它们实际的部署环境。
  • Adaptor(适配器模式):Adaptor 模式被用来翻译主容器的数据、协议或是所使用的接口,来与外部用户的期望标准对齐。Adaptor 容器也可以统一化中心服务的访问入口,即便它们服务的用户原本只支持互不兼容的接口规范。

# 使用 Configmaps 和 Secrets 来保存配置
尽管应用配置可以被一起打包进容器镜像里,但是让你的组件在运行时保持可被配置能更好支持多环境部署以及提供更多管理灵活性。为了管理运行时的配置参数,Kubernetes 提供了两个对象:ConfigMapsSecrets

ConfigMaps 是一种用于保存可在运行时暴露给 pods 和其他对象的数据的机制。保存在 ConfigMaps 里的数据可以通过环境变量使用,或是作为文件挂载到 pod 中。通过将应用设计成从这些位置读取配置后,你可以在应用运行时使用 ConfigMaps 注入配置,并以此来修改组件行为而不用重新构建整个容器镜像。

Secrets 是一种类似的 Kubernetes 对象类型,它主要被用来安全的保存敏感数据,并根据需要选择性的的允许 pods 或是其他组件访问。Secrets 是一种方便的往应用传递敏感内容的方式,它不必像普通配置一样将这些内容用纯文本存储在可以被轻易访问到的地方。从功能性上讲,它们的工作方式和 ConfigMaps 几乎完全一致,所以应用可以用完全一样的方式从二者中获取数据。

ConfigMaps 和 Secrets 可以帮你避免将配置内容直接放在 Kubernetes 对象定义中。你可以只映射配置的键名而不是值,这样可以允许你通过修改 CongfigMap 或 Secret 来动态更新配置。这使你可以修改线上 pod 和其他 kubernetes 对象的运行时行为,而不用修改这些资源本身的定义。
# 实现“就绪检测(Readiness)”与“存活检测(Liveness)”探针
Kubernetes 包含了非常多用来管理组件生命周期的开箱即用功能,它们可以确保你的应用始终保持健康和可用状态。不过,为了利用好这些特性,Kubernetes 必须要理解它应该如何监控和解释你的应用健康情况。为此,Kubernetes 允许你定义“就绪检测探针(Readiness Probe)”与“存活检测探针(Liveness Probe)”。

“存活检测探针”允许 Kubernetes 来确定某个容器里的应用是否处于存活与运行状态。Kubernetes 可以在容器内周期性的执行一些命令来检查基本的应用行为,或者可以往特定地址发送 HTTP / TCP 网络请求来判断进程是否可用、响应是否符合预期。如果某个“存活探测指针”失败了,Kubernetes 将会重启容器来尝试恢复整个 pod 的功能。

“就绪检测探针”是一个类似的工具,它主要用来判断某个 Pod 是否已经准备好接受请求流量了。在容器应用完全就绪,可以接受客户端请求前,它们可能需要执行一些初始化过程,或者当接到新配置时需要重新加载进程。当一个“就绪检测探针”失败后,Kubernetes 会暂停往这个 Pod 发送请求,而不是重启它。这使得 Pod 可以完成自身的初始化或者维护任务,而不会影响到整个组的整体健康状况。

通过结合使用“存活检测探针”与“就绪检测探针”,你可以控制 Kubernetes 自动重启 pods 或是将它们从后端服务组里剔除。通过配置基础设施来利用好这些特性,你可以让 Kubernetes 来管理应用的可用性和健康状况,而无需执行额外的运维工作。
# 使用 Deployments 来管理扩展性与可用性
在早些时候讨论 Pod 设计基础时,我们提到其他 Kubernetes 对象会建立在 Pod 的基础上来提供更高级的功能。而 deployment 这个复合对象,可能是被定义和操作的最多次的 Kubernetes 对象。

Deployments 是一种复合对象,它通过建立在其他 Kubernetes 基础对象之上来提供额外功能。它们为一类名为 replicasets 的中间对象添加了生命周期管理功能,比如可以实施“滚动升级(Rolling updates)”、回滚到旧版本、以及在不同状态间转换的能力。这些 replicasets 允许你定义 pod 模板并根据它快速拉起和管理多份基于这个模板的副本。这可以帮助你方便的扩展基础设施、管理可用性要求,并在故障发生时自动重启 Pods。

这些额外特性为相对简单的 pod 抽象提供了一个管理框架和自我修复能力。尽管你定义的工作集最终还是由 pods 单元来承载,但是它们却不是你通常应该最多配置和管理的单位。相反,当 pods 由 deployments 这种更高级对象配置时,应该把它们当做可以稳定运行应用的基础构建块来考虑。
# 创建 Services 与 Ingress 规则来管理到应用层的访问
Deployment 允许你配置和管理可互换的 Pod 集合,以扩展应用以及满足用户需求。但是,如何将请求流量路由到这些 pods 则是例外一码事了。鉴于 pods 会在滚动升级的过程中被换出、重启,或者因为机器故障发生转移,之前被分配给这个运行组的网络地址也会发生变化。Kubernetes services 通过维护动态 pods 资源池以及管理各基础设施层的访问权限,来帮助你管理这部分复杂性。

在 Kuberntes 里,services 是控制流量如何被路由到多批 pods 的机制。无论是为外部客户转发流量,还是管理多个内部组件之间的连接,services 允许你来控制流量该如何流动。然后,Kubernetes 将更新和维护将连接转发到相关 pods 的所有必需信息,即使环境或网络条件发生变化也一样。
## 从内部访问 Services
为了有效的使用 services,你首先应该确定每组 pods 服务的目标用户是谁。如果你的 service 只会被部署在同一个 Kubernetes 集群的其他应用所使用,那么 ClusterIP 类型允许你使用一个仅在集群内部可路由的固定 IP 地址来访问一组 pods。所有部署在集群上的对象都可以通过直接往这个 service IP 地址发送请求来与这组 pod 副本通信。这是最简单的 service 类型,很适合在内部应用层使用。

Kubernetes 提供了可选的 DNS 插件来为 services 提供名字解析服务。这允许 pods 和其他对象可以使用域名来代替 IP 地址进行通信。这套机制不会显著改动 service 的用法,但基于域名的标识符可以使连接组件和定义服务间交互变得更简单,而不需要提前知道 service IP 地址。
## 将 Services 向公网开放
如果你的应用需要被公网访问,那么 “负载均衡器(load balancer)”类型的 service 通常会是你的最佳选择。它会使用应用所在的特定云提供商 API 来配置一个负载均衡器,由这个负载均衡器通过一个公网 IP 来服务所有到 service pods 的流量。这种方式提供了一个到集群内部网络的可控网络通道,从而将外部流量引入到你的 service pods 中。

由于“负载均衡器”类型会为每一个 service 都创建一个负载均衡器,因此用这种方式来暴露 Kubernetes 服务可能会有些昂贵。为了帮助缓解这个问题,我们可以使用 Kubernetes ingress 对象来描述如何基于预定规则集来将不同类型的请求路由到不同 services。例如,发往 “example.com” 的请求可能会被指向到 service A,而往 “sammytheshark.com” 的请求可能会被路由到 service B。Ingress 对象提供了一种描述如何基于预定义模式将混合请求流分别路由到它们的目标 services 的方式。

Ingress 规则必须由一个 ingress controller 来解析,它通常是某种负载均衡器(比如 Nginx),以 pod 的方式部署在集群中,它实现了 ingress 规则并基于规则将流量分发到 Kubernetes serices 上。目前,ingress 资源对象定义仍然处于 beta 阶段,但是市面上已经有好几个能工作的具体实现了,它们可以帮助集群所有者最小化需要运行的外部负载均衡器数量。
# 使用声明式语法来管理 Kubernetes 状态
Kubernetes 在定义和管理部署到集群的资源方面提供了很大灵活性。使用 `kubectl` 这样的工具,你可以命令式的定义一次性资源并将其快速部署到集群中。虽然在学习 Kubernetes 阶段,这个方法对于快速部署资源可能很有用,但这种方式也存在很多缺点,不适合长周期的生产环境管理。

命令式管理方式的最大问题之一就是它不保存你往集群部署过的变更记录。这使得故障时恢复和跟踪系统内运维变更操作变得非常困难,甚至不可能。

幸运的是,Kubernetes 提供了另外一种声明式的语法,它允许你使用文本文件来完整定义资源,并随后使用 `kubectl` 命令应用这些配置或更改。将这些配置文件保存在版本控制系统里,是监控变更以及与你的公司内其他部分的审阅过程集成的一种简单方式。基于文件的管理方式也让将已有模式适配到新资源时变得简单,只需要复制然后修改现有资源定义即可。将 Kubernetes 对象定义保存在版本化目录里允许你维护集群在每个时间节点的期望集群状态快照。当你需要进行故障恢复、迁移,或是追踪系统里某些意料之外的变更时,这些内容的价值是不可估量的。
# 总结
管理运行应用的基础设施,并学习如何最好的利用这些现代化编排系统提供的特性,这些事情可能会令人望而生畏。但是,只有当你的开发与运维过程与这些工具的构建概念一致时,Kubernetes 系统、容器技术提供的优势才能更好的体现出来。遵循 Kubernetes 最擅长的那些模式来架构你的系统,以及了解特定功能如何能缓解由高度复杂的部署带来的挑战,可以帮助改善你运行平台时的体验。

原文链接:architecting-applications-for-kubernetes(翻译:朱雷(piglei))

时速云企业级容器PaaS技术沙龙 第八期

tenxcloud 发表了文章 • 1 个评论 • 1037 次浏览 • 2018-04-02 16:11 • 来自相关话题

目前,基于 Kubernetes 的容器 PaaS 在企业级数字化转型中扮演了越来越重要的角色。而 Kubernetes 在开源容器编排技术里独占鳌头,并在市场中迅速升温,越来越多的企业开始使用基于 Kubernetes 技术构建企业级 PaaS 平台,从而加 ...查看全部
目前,基于 Kubernetes 的容器 PaaS 在企业级数字化转型中扮演了越来越重要的角色。而 Kubernetes 在开源容器编排技术里独占鳌头,并在市场中迅速升温,越来越多的企业开始使用基于 Kubernetes 技术构建企业级 PaaS 平台,从而加速业务应用的交付、提高运维效率、实现微服务架构升级。可以预见,未来几年企业级容器 PaaS 市场将呈现出持续的爆发式增长。

那么,对于还未使用这一技术,或者尚在探索阶段的企业和开发者来说,如何应用好它,如何构建企业级 PaaS 平台,如何把 Kubernetes 技术与具体业务结合?未来又有怎样的发展趋势?我们将在本次沙龙为大家带来一些经验分享。

时速云( TenxCloud )自 2014 年成立之日起,就根植于技术社区。迄今为止时速云已在北京、上海、深圳等地成功举办 7 期 Docker&Kubernetes 技术沙龙,得到众多企业及开发者的大力支持。

2018 年 4 月 14 日,时速云( TenxCloud )诚邀您参加第八期企业级容器 PaaS 技术沙龙。本次沙龙由时速云主办,阿里云和青云协办,届时,您将获得与来自时速云、阿里云、青云的技术大咖们面对面交流的机会,希望大家踊跃报名。

时间地点:

时间:2018 年 04 月 14 日 13:30-17:30 地点:北京市海淀区海淀大街 27 号-天使汇极客咖啡 2 层

活动议程:

13:30-14:00 沙龙签到
14:00-14:40 时速云 王磊 《 Kubernetes Native DevOps 实践》
14:40-15:20 青云 于爽 《容器及 k8s 实践经验分享》
15:20-15:50 茶歇
15:50-16:30 时速云 魏巍 《 Calico 网络在容器云平台上的实践与思考》
16:30-17:10 阿里云 徐晓舟 《 Kubernetes 助力企业敏捷开发》
17:10-17:30 提问环节

邀请嘉宾:

于爽( Calvin Yu ),QingCloud 容器研发工程师,负责青云 QingCloud PaaS 平台容器相关服务的设计与研发工作。 演讲主题:《容器及 k8s 实践经验分享》

徐晓舟,阿里云资深开发工程师,2015 年加入阿里巴巴。 主要负责阿里云容器服务公有云管控系统开发的开发工作,以及私有云容器平台的部署和管控。 演讲主题:《 Kubernetes 助力企业敏捷开发》

王磊,时速云联合创始人 - CTO。原 IBM 中国开发实验室资深软件工程师,IBM BPM 产品开发组 Team Lead,曾参与 IBM 服务器、中间件、Bluemix 平台等多个产品的设计与开发工作 演讲主题:《 Kubernetes Native DevOps 实践》

魏巍,时速云容器架构负责人 - Architect,Certified Kubernetes Administrator。 演讲主题:《 Calico 网络在容器云平台上的实践与思考》

报名方式: 本次技术沙龙采用报名制,全程免费,前 100 名签到者可获得精美礼品。 请在 http://cn.mikecrm.com/QNfD0m8 正确填写即可报名。在沙龙前我们会发送提醒邮件,请您注意查收。 诚邀广大技术爱好者莅临参加!

基于Helm和Operator的K8S应用管理

Rancher 发表了文章 • 0 个评论 • 2487 次浏览 • 2018-03-08 13:07 • 来自相关话题

大家好,今天我们分享的内容是基于Helm和Operator的K8S应用管理。 我们知道,Kubernetes基于服务粒度提供了多种资源描述类型。描述一个应用系统尤其是微服务架构系统,需要组合使用大量的Kubernetes资源。针对 ...查看全部
大家好,今天我们分享的内容是基于Helm和Operator的K8S应用管理。

我们知道,Kubernetes基于服务粒度提供了多种资源描述类型。描述一个应用系统尤其是微服务架构系统,需要组合使用大量的Kubernetes资源。针对有状态应用,常常还需要复杂的运维管理操作以及更多的领域知识。

今晚的分享就将介绍如何用Helm这一Kubernetes应用包管理的社区主导方案来简化应用的部署管理,如何制作应用模板以及打造Kubernetes版应用商店,以及如何利用operator自动化应用的运维。


----------


我们知道在K8S社区里面,根据不同的领域,分成了不同的兴趣小组,英文叫SIG。今晚的话题属于APP这个领域。它们是为了解决K8S的应用管理里面的一些问题而生的。

一、Helm
让我们从零开始吧。比如说我们现在已经部署了一个K8S的集群。不管是用GKE或者是EKS,都不是难事,因为现在部署K8S已经不是以前那么麻烦的事情了。然后我们做了应用的容器化。接下来,我们要试着去把我们的应用部署到K8S上面去。
其实在K8S里面,资源对象是很多的:



对于一些微服务架构来说,会有不同的服务在上面运行,你可能要管理诸如deployment、service、有状态的Statefulset、权限的控制等等。你会发现,部署应用后还会有很多其他关联的东西以及你需要考虑的点:比如说你的不同团队,要去管理这样一个应用,从开发到测试再到生产,在不同的环境中,同样一套东西可能都需要不同的配置。例如,你在开发的时候,不需要用到PV,而是用一些暂时的存储就行了;但是在生产环境中,你必须要持久存储;并且你可能会在团队之间做共享,然后去存档。

另外,你不仅仅要部署这个应用资源,你还要去管理其生命周期,包括升级、更新换代、后续的删除等。我们知道,K8S里面的deployment是有版本管理的,但是从整个应用或某个应用模块来考虑的话,除了deployment,可能还会有其他的configmap之类的去跟其关联。这时我们会想,是否有这样一个工具可以在更上层的维度去管理这些应用呢?这个时候我们就有了社区的一个包管理工具:Helm。

我们知道K8S的意思是舵手,即掌控船舵的那个人。而Helm其实就是那个舵。

在Helm里面,它的一个应用包叫Charts,Charts其实是航海图的意思。它是什么东西呢?

它其实就是一个应用的定义描述。里面包括了这个应用的一些元数据,以及该应用的K8S资源定义的模板及其配置。其次,Charts还可以包括一些文档的说明,这些可以存储在chart的仓库里面。
怎么用Helm这个工具呢?Helm其实就是一个二进制工具。你只要把它下载下来,已经配置好了kubeconfig的一些相关配置信息,就可以在K8S中做应用的部署和管理了。
用Helm可以做什么事情呢?其实Helm分为服务端跟客户端两部分,你在helm init之后,它会把一个叫做Tiller的服务端,部署在K8S里面。这个服务端可以帮你管理Helm Chart应用包的一个完整生命周期。

Release == Chart 的安装实例:



接着说说Helm Chart。它本质上是一个应用包,你可以把它理解成dpkg或者像rpm这样的包。只不过,它是基于K8S领域的一个应用包的概念。你可以对同一个chart包进行多次部署,每次安装它都会产生一个Release。这个Release相当于一个chart中的安装实例。

现在我们已经把Tiller部署进去了,那么就可以去做我们应用的管理了:

$ helm install

```
# (stable/mariadb, ./nginx-1.2.3.tgz, ./nginx, https://example.com/charts/nginx-1.2.3.tgz)
$ helm upgrade
$ helm delete
```

关于一些常用的命令例如安装一个应用包,可以用install,它其实是可以支持不同格式的:比如说本地的一些chart包,或者说你的远程仓库路径。
对于应用的更新,用Helm upgrade。
如果要删除的话,就用Helm Delete。
Helm的一个Release会生成对应的Configmap,由它去存储这个Release的信息,并存在K8S里面。它相当于把应用的一个生命周期的迭代,直接跟K8S去做关联,哪怕Tiller挂了,但只要你的配置信息还在,这个应用的发布和迭代历程不会丢失:例如想回滚到以前的版本,或者是查看它的升级路径等。
接下来我们看一个chart的结构。

$ helm create demoapp



用Helm create的话,它会提供一个大概的框架,你可以去创建自己的一个应用。比如说这个应用就叫做Demoapp,里面会有如下内容:



其中最核心的是templates,即模板化的K8S manifests文件,这里面会包括资源的定义,例如deployment、service等。现在我们create出来的是一个默认的、用一个nginx deployment去部署的应用。

它本质上就是一个Go的template模板。Helm在Go template模板的基础上,还会增加很多东西。如一些自定义的元数据信息、扩展的库以及一些类似于编程形式的工作流,例如条件语句、管道等等。这些东西都会使得我们的模板变得非常丰富。
有了模板,我们怎么把我们的配置融入进去呢?用的就是这个values文件。
这两部分内容其实就是chart的核心功能。





这个deployment,就是一个Go template的模板。里面可以定义一些预设的配置变量。这些变量就是从values文件中读取出来的。这样一来,我们就有了一个应用包的模板,可以用不同的配置将这个应用包部署在不同的环境中去。
除此之外,在Helm install/upgrade时候,可以使用不同的value。

配置选项:




```
$ helm install --set image.tag=latest ./demoapp
$ helm install -f stagingvalues.yaml ./demoapp
```

比如说你可以set某个单独的变量,你可以用整个File去做一个部署,它会用你现在的配置覆盖掉它的默认配置。因此我们可以在不同的团队之间,直接用不同的配置文件,并用同样的应用包去做应用管理。

Chart.yaml即chart的元数据,描述的就是这个chart包的信息。




另外还有一些文档的说明,例如NOTES.txt,一般放在templates里面,它是在你安装或者说你察看这个部署详情之时(helm status),自动列出来的。通常会放一些部署了的应用和如何访问等一些描述性的信息。



除了模板以外,Helm chart的另一个作用就是管理依赖。



比如说你部署一个Wordpress,它可以依赖一些数据库服务。你可以把数据库服务作为一个chart形式,放在一个依赖的目录下面。这样的话应用之间的依赖管理就可以做的很方便了。
假如现在已经创建了我们自己的应用包,想要有一个仓库去管理这个包,在团队之间共享应该怎么做?

chart的仓库其实就是一个HTTP服务器。只要你把你的chart以及它的索引文件放到上面,在Helm install的时候,就可以通过上面的路径去拿。

Helm工具本身也提供一个简单的指令,叫Helm serve,帮你去做一个开发调试用的仓库。

例如 https://example.com/charts 的仓库目录结构:



关于 Helm,社区版其实已经有了很多的应用包,一般放在K8S下面的一些项目中,比如安装Helm时候,它默认就有一个Stable的项目。里面会有各种各样的应用包。

Stable和incubator chart 仓库:https://github.com/kubernetes/charts

另外,社区版还会提供类似于Rancher Catalog应用商店的这样一个概念的UI,你可以在这上面做管理。它叫Monocular,即单筒望远镜的意思,这些项目的开发都非常的活跃,一直在随着K8S的迭代做着更新。

Monocular: chart的UI管理项目:https://github.com/kubernetes-helm/monocular



那么怎么去部署K8S版的应用商店呢?其实也非常简单。因为有了Helm之后,你只要使用Helm install这个Monocular,先把它的仓库加进来,再install一下,就可以把这个应用部署到你的K8S集群之中了。它其实也是利用了Helm Tiller去做部署。我们可以在上面去搜索一些chart,管理你的仓库,例如官方的stable,或者是incubator里面的一些项目。



你也可以管理一些已经部署的应用。比如说你要搜索一个应用,点一下部署,就可以把它部署上去了。不过这其中还有很多亟待完善的东西,比如这里的部署不能配置各种不同的参数,它只能输入namespace。其次,里面的一些管理依然存在局限性,比如不能很方便地在UI上做更新。

围绕Helm chart我们也会跟一些公有云厂商有相关的合作。因为Helm chart的好处就是:一个应用包可以在多个地方部署。比如公有云的服务,可以基于它去实现应用的编排和管理,把一个服务便利地提供给不同的用户。Rancher也会在2.0的应用商店中加入对helm chart的支持,希望帮助用户在方便利用已有模板的同时提供良好的体验。

在stable的仓库里面已经有很多chart,其实并不是特别完善,还有很多应用是可以补充和增强的。就我们的实践经验来说,什么都可以chart化,不管是分布式的数据库集群,还是并行计算框架,都可以以这样的形式在K8S上部署和管理起来。
另外一点就是Helm是插件化的,helm的插件有Helm-templates, helm-github,等等。
比如你在Helm install的时候,它可以调用插件去做扩展。它没有官方的仓库,但是已经有一些功能可用。其实是把Restless/release的信息以及你的chart信息以及Tiller的连接信息交给插件去处理。Helm本身不管插件是用什么形式去实现的,只要它是应用包,则对传入的这些参数做它自己的处理就行。

Helm的好处,大概就有这些:
•利用已有的Chart快速部署进行实验
•创建自定义Chart,方便地在团队间共享
•便于管理应用的生命周期
•便于应用的依赖管理和重用
•将K8S集群作为应用发布协作中心

二、Operator
我们接下来说说Operator。为什么讲Operator呢?Operator其实并不是一个工具,而是为了解决一个问题而存在的一个思路。什么问题?就是我们在管理应用时,会遇到无状态和有状态的应用。管理无状态的应用是相对来说比较简单的,但是有状态的应用则比较复杂。在Helm chart的stable仓库里面,很多数据库的chart其实是单节点的,因为分布式的数据库做起来会较为麻烦。

Operator的理念是希望注入领域知识,用软件管理复杂的应用。例如对于有状态应用来说,每一个东西都不一样,都可能需要你有专业的知识去处理。对于不同的数据库服务,扩容缩容以及备份等方式各有区别。能不能利用K8S便捷的特性去把这些复杂的东西简单化呢?这就是Operator想做的事情。
以无状态应用来说,把它做成一个Scale UP的话是比较简单的:扩充一下它的数量就行了。





接着在deployment或者是说ReplicaSet的controller中,会去判断它当前的状态,并向目标状态进行迁移。对有状态的应用来说,我们常常需要考虑很多复杂的事情,包括升级、配置更新、备份、灾难恢复、Scale调整数量等等,有时相当于将整个配置刷一遍,甚至可能要重启一些服务。

比如像Zookeeper315以前不能实时更新集群状态,想要扩容非常麻烦,可能需要把整个节点重启一轮。有些数据库可能方便一点,到master那里注册一下就好。因此每个服务都会有它自己的特点。
拿etcd来说,它是K8S里面主要的存储。
如果对它做一个Scale up的话,需要往集群中添加一些新节点的连接信息,从而获取到集群的不同Member的配置连接。然后用它的集群信息去启动一个新的etcd节点。

如果有了etcd Operator,会怎么样?

Operator其实是CoreOS布道的东西。CoreOS给社区出了几个开源的Operator,包括etcd,那么如何在这种情况下去扩容一个etcd集群?
首先可以以deployment的形式把etcd Operator部署到K8S中。
部署完这个Operator之后,想要部署一个etcd的集群,其实很方便。因为不需要再去管理这个集群的配置信息了,你只要告诉我,你需要多少的节点,你需要什么版本的etcd,然后创建这样一个自定义的资源,Operator会监听你的需求,帮你创建出配置信息来。

$ kubectl create –f etcd-cluster.yaml


要扩容的话也很简单,只要更新数量(比如从3改到5),再apply一下,它同样会监听这个自定义资源的变动,去做对应的更新。

$ kubectl apply -f upgrade-example.yaml


这样就相当于把以前需要运维人员去处理集群的一些工作全部都交付给Operator去完成了。
如何做到的呢?即应用了K8S的一个扩展性的API——CRD(在以前称为第三方资源)。

在部署了一个etcd Operator之后,通过kubernetes API去管理和维护目标的应用状态。本质上走的就是K8S里面的Controller的模式。K8S Controller会对它的resource做这样的一个管理:去监听或者是说检查它预期的状态,然后跟当前的状态作对比。如果其中它会有一些差异的话,它会去做对应的更新。

Kubernetes Controller 模式:



etcd的做法是在拉起一个etcd Operator的时候,创建一个叫etcd cluster的自定义资源,监听应用的变化。比如你的声明你的更新,它都会去产生对应的一个事件,去做对应的更新,将你的etcd集群维护在这样的状态。
除了etcd以外,社区比如还有普罗米修斯Operator都可以以这种方便的形式,去帮你管理一些有状态的应用。
值得一提的是,Rancher2.0广泛采用了Kubernetes-native的Controller模式,去管理应用负载乃至K8S集群,调侃地说,是个Kubernetes operator。

三、Helm和Operator的对比
这两个东西讲完了,我们来对比一下二者吧。

Operator本质上是针对特定的场景去做有状态服务,或者说针对拥有复杂应用的应用场景去简化其运维管理的工具。Helm的话,它其实是一个比较普适的工具,想法也很简单,就是把你的K8S资源模板化,方便共享,然后在不同的配置中重用。

其实Operator做的东西Helm大部分也可以做。用Operator去监控更新etcd的集群状态,也可以用定制的Chart做同样的事情。只不过你可能需要一些更复杂的处理而已,例如在etcd没有建立起来时候,你可能需要一些init Container去做配置的更新,去检查状态,然后把这个节点用对应的信息给拉起来。删除的时候,则加一些PostHook去做一些处理。所以说Helm是一个更加普适的工具。两者甚至可以结合使用,比如stable仓库里就有etcd-operator chart。
就个人理解来说,在K8S这个庞然大物之上,他们两者都诞生于简单但自然的想法,helm是为了配置分离,operator则是针对复杂应用的自动化管理。

我今天分享的内容就到这里,我们可以在QA环节继续交流。

QA环节
Q1:像Rancher有自带的应用商店Catalog,那Helm是相当于K8S的应用商店吗?
A1:是的,Rancher大概是在早期版本、Rancher 1.3开始支持Helm了。用户在Rancher部署K8S的时候,Rancher会把Helm工具都给装好给用户使用。现在的Rancher在K8S里面是没有应用商店的,我们就是考虑到Helm社区很活跃与成熟了,用户可以直接用Helm这个工具,所以K8S里面的应用商店其实是拿掉了的。Rancher 1.x版本,用户使用helm chart并没有cattle catalog那么好,不过2.0里这一点就极大改善了。

Q2:如何将本地的chart包push到远程仓库?
A2:chart repository就是普通的http web 服务器带特定的index文件,把chart包按对应格式传到host的目录就可以了,具体可以参考https://docs.helm.sh/developing_charts/#the-chart-repository-guide

Q3:想添加本地某个目录(包含index.yaml)作为私有仓库该怎么做?
A3:最简单的用helm提供的serve命令。

Q4:helm是一个图形化管理工具吗?
A4:不是图形化管理工具,但是有对应的ui项目。

Q5:helm架构中的tiller是指什么?
A5:tiller就是部署在k8s中的服务端,实际执行部署更新等操作,你用的helm binary是client端会向它发请求

Q6:helm目前国内使用不是很方便,目前所有的charts都是放在google服务器的, 国内用什么好用的repository么?
A6:可以翻墙或者自己搭,我没怎么了解过国内的源(捂脸)

Q7:所以operator是一种管理有状态应用的软件架构模式?
A7:通常用作管理有状态应用,就是利用k8s的crd扩展及声明式定义的方式做应用管理的模式。

Q8:operator业界有通用框架吗?
A8:在k8s的世界就是controller模式那一套,可以参考之前的一篇go-client相关的文章:http://mp.weixin.qq.com/s/MHjuS21iIyV99-o5hESWCw

如若转载,请注明出处谢谢!
微信号:RancherLabs

盘点那些你可能错过的CNCF优秀开源项目

Rancher 发表了文章 • 0 个评论 • 1294 次浏览 • 2018-03-07 08:53 • 来自相关话题

自2015年成立以来,云原生计算基金会(CNCF)已经成为开源生态系统中最重要的推动者之一,特别是当涉及到影响容器和其他“云原生”技术的工具时。CNCF成立的目的是促进和组织与大型行业趋势相关的项目,包括容器化、编排和微服务架构。自那以后,CNCF已经增加了1 ...查看全部
自2015年成立以来,云原生计算基金会(CNCF)已经成为开源生态系统中最重要的推动者之一,特别是当涉及到影响容器和其他“云原生”技术的工具时。CNCF成立的目的是促进和组织与大型行业趋势相关的项目,包括容器化、编排和微服务架构。自那以后,CNCF已经增加了10个开源项目。
即使您从未听说过CNCF,一定也听说过比它更受欢迎的项目之一:Kubernetes容器编排平台,但是CNCF比Kubernetes要大得多。如果您想要了解容器和云计算领域的重要发展,可以看看下文中介绍的CNCF生态系统中其他值得关注的重要项目。


LINKERD
第一个是Linkerd,一个基于微服务的原生云应用程序的开源“服务网格”项目。
Linkerd背后的想法是:微服务固然很好,但是只有当你有一个好方法来连接它们、形成完整的应用程序时,微服务的好处才能够体现。如若不然,你的微服务应用程序就会变成一个笨重的移动部件,它们彼此也不能很好地结合在一起。
Linkerd是一个开源项目,旨在通过提供开发人员所说的“service mesh(服务网格)”来解决这一挑战。Linkerd的服务网格提供了一个方便可靠的接口,不同的服务可以交互运行。除了通过为连接服务提供简单的方式和一致的抽象层来简化程序员的工作之外,Linkerd还具备可伸缩性、高可用性和安全性等特点。该项目由Buoyant监管,于2017年初加入CNCF。

FLUENTD
度量只是微服务应用程序可见性难题的一个方面。集中化的日志则是另一个。
随着应用程序的数量和公司规模的增长(尤其是越来越多的服务被容器化),在一个地方收集、分析和查询结构化日志是非常重要的。
这就是Fluentd的初衷。Fluentd是一个日志收集器(类似于logstorage),通过它可以对日志进行过滤、清洁和路由到各种目的地。与其他日志收集器一样,Fluentd可以与各种核心和第三方输入及输出插件(如Elasticsearch插件、S3插件等)一起使用。
Fluentd还具有一定的内存存储和可靠性。从多个主机到Fluentd、接着到Elasticsearch集群的rsyslog文件的日志路径极其简洁,这一简单的例子也充分证明了使用Fluentd的益处所在。

OPENTRACING
值得关注的第三个项目是分布式跟踪。随着单体应用程序被分解为各种更小的服务,自然会有越来越多的数据在服务中传输,从前端传输到后端,从一个服务传输到另一个服务。但是,当一个具有各种依赖关系的公共应用程序突然出现延迟时,会发生什么情况呢?这就是分布式跟踪的由来。其核心在于,跟踪是通过不同的请求调用、线程和流程来传播元数据,并最终基于此元数据构建一个图表。
OpenTracing是一种跟踪标准,它是为响应分布式跟踪领域长期存在的问题而创建的——即,当一个公司的堆栈可能由大量第三方软件、操作系统和自定义应用程序组成的时候,如何协调跟踪?OpenTracing,一种标准化的跟踪程式,就是这一难题的解决方案。该项目为跨越(即计时操作)管理和进程间传播,提供了的仪器API的标准化服务。因此,用户可以轻松地切换到跟踪库或集中式跟踪系统(如Zipkin、Dapper等),无须复杂的配置,免去了很多麻烦。

GPRC
到目前为止,我们已经知道了如何部署、调度和了解云中的微服务。但是他们之间的交流方式是什么呢?
让我们来看看“远程程序调用(RPC)”。
远程程序调用的概念已经存在了一段时间了,它指的是一种模式,在这种模式中,函数被称为远程调用,通常在系统中使用,而不是基于RESTful服务的CRUD模型。
但是,gRPC指的是谷歌实现的远程程序调用,它利用了http/2和协议缓冲区。与基于jsf的RPC相比,gRPC已经被证明在数量级上更快,这使得它成为大型分布式平台的优秀选择。事实上,etcd(来自CoreOS的流行键值存储)和谷歌自己的BigTable都是gRPC!

RKT
最后一个值得关注的项目是rkt(也称为Rocket),一个容器运行时。尽管Docker的containerd运行时可能是以推广容器概念的容器为目的的运行时,但是Docker仍然是编排生态系统中常用的运行时,因此我们相信RKT在后期会变得越来越受欢迎。
两者之间的差异也是显而易见的。虽然Docker已经选择了在集群中打包,并由一个守护进程和通过REST API与保护进程通信的可执行程序组成,但是RKT要简单得多。它由一个简单的命令行工具组成,当给定一个镜像、一个规范格式和一个镜像发现机制时,RKT就能运行一个容器。
使用RKT,用户可以在配置容器运行时时避免像systemd这样的问题。此外,RKT不仅可以运行App Container format中的镜像,还可以运行标准的Docker镜像。
结论
我们正在一步步更快地向微服务架构的世界迈进,与此同时,越来越多的开源项目涌现,以期为那些真正想要做到“云原生”的用户服务。CNCF有大量优秀却未必广为人知的项目,本文只涵盖了其中一部分,建议您也可以多了解其他的项目,为未来储备:https://www.cncf.io

作者简介
Sneha Inguva是一位热心的软件工程师,目前正在DigitalOcean研发软件开发工具。在过去的几年里,她在各种各样的初创公司里工作过,并且对折衷垂直领域(教育、3D打印和赌场等)的软件构建和部署拥有独特的视角。

原文:http://rancher.com/cncf-projects-may-missed/

微信号:RancherLabs

腾讯云微计算实践:从Serverless说起,谈谈边缘计算的未来

腾讯云技术社区 发表了文章 • 0 个评论 • 1771 次浏览 • 2018-02-27 16:03 • 来自相关话题

欢迎大家前往[云+社区][1],获取更多腾讯海量技术实践干货哦~ 作者:黄文俊,腾讯云高级产品经理,曾经历过企业级存储、企业级容器平台等产品的架构与开发,对容器、微服务、无服务器、DevOps等都有浓厚兴趣。 > 由 ...查看全部
欢迎大家前往[云+社区][1],获取更多腾讯海量技术实践干货哦~

作者:黄文俊,腾讯云高级产品经理,曾经历过企业级存储、企业级容器平台等产品的架构与开发,对容器、微服务、无服务器、DevOps等都有浓厚兴趣。
> 由 腾讯云serverless团队 发布在 云+社区



本文整理自1月20日腾讯云微服务架构交流会。

Serverless是一个比较新的概念,2017年开始在行业内兴起,边缘计算则是一个更新的技术。那么Serverless在边缘计算中能产生的什么样的效果、产品以及形态并推进出来在大家面前呢?今天来为大家分享一下。

首先讲讲Serverless是什么?

下面这张图可以很清晰的看到,Serverless从架构上可以分成两部分。

  • 一是Backend as a Service,后端即服务,腾讯云上目前已经提供很多这类产品,例如COS对象存储、CMQ消息队列、CDN内容分发、CDB云数据库、API网关,这些产品更多的是承载数据的存储。
  • 二是Function as a Service,函数即服务,也是Serverless比较核心的技术点,腾讯云云函数就属于这种。






从Serverless或者云函数来看,更多是对用户的计算进行托管。用户将代码和配置提交到云函数平台上,此处的代码是指用户的一份代码或者代码包,配置,一个是指本身对于函数运行环境的配置,使用的是哪种环境、所需的内存、超时时间等;另一个是触发器的配置。因为整个函数即服务的运行方式是触发式运行,触发就需要有一个事件来源,而事件来源是和腾讯云其他产品进行关联后而产生。例如COS对象存储产品,它的关联就在COS的存储桶中,当用户上传一张图片或者删除一张图片时,就会产生一个事件,这个事件会触发云函数的运行;例如和API网关的对接,也可以作为事件来源,在用户的HTTP请求到达网关之后,API网关会把该请求作为事件转发给云函数,触发云函数的运行,云函数拿到请求之后进行处理,生成响应给到用户。





上图左侧,是代码和配置提交到云函数平台进行保存,真正事件产生后,针对每一个事件都会拉起一个函数实例,实现触发式运行;真正事件来临时,用户函数才会运行,用户代码运行时才有云函数代码的数据运算和费用计算。

因为函数本身是托管型的,用户本身无法感知到实例在哪里运行。云函数平台背后有个大的计算资源池,用户实例触发之后,我们会从资源池中随机选取可运行的位置,把用户的函数实例在对应位置上跑起来。因此整个调度过程,或者事件来临之后的函数扩缩容过程,都是由平台进行的。对用户来说,调度的粒度更细了,而且调度也都托管给平台了。





而从整个的计算过程来说,为什么会有这种产品的出现?对于传统的数据存储过程来说,数据产生后,更多会先把数据进行缓存或者存储,如以对象存储文件的形式保存,或者数据库中以结构化形式存储下来,再进行分析应用。有了函数服务产品后,我们可以有很大的加速,可以在事件产生的时候就立刻对数据进行处理,因此就变成了先处理,再对结果进行保存使用的过程。


那么,还能不能缩短中间数据产生到数据处理的传递过程?

对于传统应用来说,数据在用户那里产生,传到云上进行处理,再进行相应的存储。这里说的缩短距离实际是把处理过程更加靠近用户,靠近用户就可以认为是边缘计算的过程。并且这里的靠近用户指的并不是加速网络速度,而是更多把计算下发,放到更靠近用户的位置。

之前无论使用容器也好,或者使用主机也好,运算能力都是在云上提供,而边缘计算要做的事情是把运算能力下发到云之外去。

边缘计算的理念,就是把计算能力下发更靠近真正的用户,更加靠近设备这一端。


为什么会有这种需求的产生?

随着互联网以及物联网的迅速发展,接入的用户越来越多,设备也越来越多,在这种情况下,产生的数据量也越来越多。无论是个人用户,还是物联网接入设备,每时每刻都在产生大量的数据。数据不断增多的情况下,也同时要求我们对于用户的响应、设备响应越来越快,本身设备的计算能力也要越来越强。

10年前的一台PC都比不上现在一台智能手机的处理能力,设备的计算能力在越来越强的情况下,实现了把计算能力下发到更加边缘的位置的能力。


云函数目前在做的探索,从两方面出发。一是物联网方向,物联网主要是和设备打交道,实现设备上的边缘计算;从云函数本身的特点来讲,它属于触发型运算,真正数据产生之后才会拉起运算。云函数交由平台托管的调度,可以把云函数调度到用户设备上去,二把云函数调度到CDN的节点上去,虽然CDN可以认为是云的一部分,但CDN本身已经很靠近用户,CDN节点实际上已经在云的边缘。


接下来给大家做一个和物联网相关的效果演示。

先简单介绍一下几款设备,第一个是树莓派,熟悉物联网的同学一般都了解;第二个是光感的传感器,可以感测环境光,从中读取到环境光的流明值;第三个是LED灯。


目前这个设备已经跑起来了,它所做的事情是当环境光足够亮的情况下,LED灯就会暗掉,当环境光足够暗的情况下,LED灯会亮起来。演示过程可以看到,当我把光感器遮盖的时候,LED灯有一个亮起来的动作。目前的环境光和背景足够亮,当我打开的时候,因为光足够亮,所以LED灯会灭掉。

针对这个代码我做一个解释。首先大家可以看到目前在树莓派上跑的一段函数,已经下到树莓派上跑了,在网上看到的是线上的代码。接下来我会对代码进行修改,从代码中大家可以看到,当从传感器中读出的流明值足够大的时候,GPIO做拉高或者拉低的动作,目前是正常的表现。

刚刚我完成了一个修改,现在我要把代码下发到仪器上运行,同时把这里拉起,查看数值是否正确。下面不断刷新的就是传感器出来的流明值,目前传感器已经变化了,因为大家可以看到这个数值已经超过了200,LED灯是亮着的,当我把感光器遮盖以后,LED灯变暗,这是通过代码把行为做了反转的变化。

我们在目前的调试过程中也会做实际的设备调试,这里演示的就是真正把云函数下放到物理设备上进行执行的效果。

接下来讲的是目前云函数和用户协同推进的AI能力,用户数据只要在云上利用CVM、GPU服务器、腾讯TML机器学习,进行AI训练,得出相应的训练后模型,再把模型和外围的导入代码进行打包,放入云函数,或者是带有GPU的云函数,就可以对外提供AI的推理能力。用户真正使用AI的时候,从外面送过来一段用户需要推理的语音、文本或图像,在云函数中拉起训练模型,就可以对这段数据进行推理。


AI能力表面上看起来和边缘计算没有关系,其实不然。如果本身已经在物联网的边缘设计上具有了云函数的执行能力,那么是不是可以进一步考虑把AI能力下发到设备上去的,比如我们在云中进行数据的收集和训练,生成模型之后,利用模型更新云上的函数,然后可以利用一键下发把这种能力下发到设备中,使设备具备更强的AI能力。

通过这种方式可以让更多的设备接入AI能力,比如让家里的摄象头直接识别人脸,认识你的家人,或者让更多的医疗设备直接对医疗检查结果做出判断,识别疾病类型等。这些都将会是后期持续和各个物联网厂商进行摸索,往前推进的过程。


另外一个角度来说,我们为什么做CDN的边缘计算?CDN本身是把数据放到边缘去的一个过程,而边缘计算是为了把计算放到边缘去。为了更快的响应用户的操作需求,对于边缘传上来的数据进行更快的处理,这也是云函数对于边缘的探索。

对于边缘计算来说,云函数要做到的就是用户在云中能完成函数的编写、管理,在所需的位置把云函数下放各个位置运行和使用。

云函数未来在边缘计算中还会有大量的探索机会,CDN厂商、物联网厂商、硬件厂商等都将会有持续不断的合作发展,去探索尝试将边缘的物联网能力、边缘的AI能力、边缘CDN能力落地。

Q&A

Q:腾讯云Serverless可以自己部署吗?

A:自己部署有分两种,一种是把云函数部署到设备上的能力,一种是Agent的部署。Agent本身是需要用户自行部署到用户自有的设备上去的。而今天演示用的是树莓派,Agent不局限于树莓派,它可以在更强的服务器中运行,比如可以用到设备的GPU、设备的存储、文件等进行分析计算。



Q:我们想在自己内部部署一个类似的Serverless,腾讯云可以支持吗?

A:您说的是私有化部署,云函数本身没有考虑,腾讯云云函数管理整体是在云上的,边缘计算提供更多的是边缘的调度和计算能力,函数在云上配置后,调度到设备上运行,云函数本身对于设备上的数据读取全部由自己控制,读取不用走网络,因为执行的代码包已经下发到设备上去了,体现的是让计算更加靠近数据的理念。



Q:如果提前设置好代码下发到设备上去,AI也可以断网吗?

A:对,代码运行在你的设备上。两种情况,一种是我刚才演示的物联网的边缘计算。本身的代码包装下发到设备之后,在设备上运行,断网没有关系。
> 云函数本身也提供AI能力,在云上提供,所以在云上运行。
> 对于AI,云上产品化的速度会更快,目前腾讯云已经在为部分客户进行支持,云上的相关操作说明后续也会提供出来,大家可以在线体验AI能力。



Q:针对IoT这块腾讯云发布了没有?

A:这个还没有发布,还在产品化,目前也是和一些客户协同推进这个能力,物联网设备各种各样,包括底层的硬件环境,比如树莓派的ARM,或者X86,或者mips等平台,对于Linux里的内核功能,文件系统的支持,对于存储、内存、CPU的要求也在整理中。



Q:云函数能够被用于传统应用吗?

A:云函数的特性因为本身是触发式运行,短暂运行的方式,所以和传统的很多开发单体的运行方式不太一样,更多是偏向于新业务开发,或者是小的新业务上线,或者急需要弹性应用能力的使用,传统的可以做改造,但是到时候需要提供一些改造的建议。
效率提升更多是在业务开发的速度上,实际上对于业务运行环境不用再过多做运维性的动作,对于扩缩容也不用考虑,业务开发之后就可以上线,运维交给平台,扩缩容能力也是交给平台,为用户减轻压力,业务用量上来之后怎么承载业务,怎么保证业务不崩溃,云函数已经解决了这个问题,本身的扩容可以理解为无限能力的扩容。



Q:Serverless在线能力有没有额外的规划?Serverless的程序和代码能不能访问云主机上面的接口?

A:目前有在做很多,包括边缘计算、CDN以及和腾讯云的各种云产品打通,Serverless本身最大的价值在于和各个云产品打通之后的效能,可以认为是各个云产品之间的黏合剂或者是轻量级计算的联合。而和后端的对接,包括数据库、CVM直接打通,更多是网络上的问题,即将会推出和VPC网络的打通,用户VPC业务可以用云函数直接访问。



相关阅读

[使用腾讯云“自定义监控”监控GPU使用率][2]
[如何在Python中从零开始实现随机森林][3]
[自然语言处理的神经网络模型初探][4]
***
此文已由作者授权云加社区发布,转载请注明[文章出处][5]


[1]: https://cloud.tencent.com/developer
[2]: https://cloud.tencent.com/developer/article/1043874
[3]: https://cloud.tencent.com/developer/article/1043093
[4]: https://cloud.tencent.com/developer/article/1036794
[5]: https://cloud.tencent.com/developer/article/1044457