数人云

数人云

从Uber微服务看最佳实践如何炼成?

Dataman数人科技 发表了文章 • 0 个评论 • 1664 次浏览 • 2018-03-29 01:33 • 来自相关话题

导读: Uber成长非常迅速,工程师团队快速扩充,据说Uber有2000名工程师,8000个代码仓库,部署了1000多个微服务。微服务架构是Uber应对技术团队快速增长,功能快速上线很出色的解决方案。本文偏向微服务的入门篇,以Uber微服务为例, ...查看全部
导读:
Uber成长非常迅速,工程师团队快速扩充,据说Uber有2000名工程师,8000个代码仓库,部署了1000多个微服务。微服务架构是Uber应对技术团队快速增长,功能快速上线很出色的解决方案。本文偏向微服务的入门篇,以Uber微服务为例,进行了深入浅出的讲解。
微服务特性
对于微服务没有适当的定义,你可以说它是一个框架,由小型的、独立的可部署的服务组成,执行不同的操作。

微服务专注于单个业务领域,可以作为完全独立的可部署服务,并在不同的技术栈上实现它们。


6.png




单体架构和微服务架构区别

在使用微服务构建自己的应用程序之前,需要清楚地了解应用程序的范围和功能。


1.png




微服务特性

解耦 - 系统内的服务在很大程度上是解耦的。因此,整个应用程序可以轻松构建,更改和缩放
组件化 - 微服务被视为独立的组件,可以轻松替换和升级
业务能力 - 微服务非常简单,专注于单一功能
自治 - 开发人员和团队可以独立工作,从而提高速度
持续交付 - 通过软件创建,测试和批准的系统自动化,允许软件的频繁发布
责任 - 微服务不像项目那样专注于应用程序。相反,他们将应用程序视为他们负责的产品
分散治理 - 重点在于使用正确的工具来完成正确的作业。这意味着没有标准化模式或任何技术模式。开发人员可以自由选择最有用的工具来解决他们的问题
敏捷 - 微服务支持敏捷开发。任何新功能都可以快速开发并再次丢弃

微服务优势

2.png



独立开发 - 所有微服务都可以根据各自的功能轻松开发
独立部署 - 基于各自的服务,可以单独部署在任何应用程序中
故障隔离 - 即使应用程序的一项服务不起作用,系统仍会继续运行
混合技术堆栈 - 可以使用不同的语言和技术来构建同一应用程序的不同服务
细粒度缩放 - 各个组件可根据需要进行扩展,无需将所有组件扩展到一起
微服务设计最佳实践
在当今世界,复杂性已经渗透到产品中。微服务架构能够更好地保持团队的规模和功能。

以下是微服务设计的最佳实践:


3.png




现在,让我们来看一个用例来更好地理解微服务。
案例:购物车应用程序
当打开购物车应用程序时,你看到的只是一个网站。但是,在幕后,购物车应用程序有接受支付服务、顾客服务等等。

假设开发人员已经在一个整体框架中进行了创建。如下图:

4.png




购物车应用程序的整体框架

所有功能都放在一个代码库中,并在一个底层数据库下。

现在,假设市场上出现了一个新品牌,开发人员希望将这个品牌的所有细节都放在这个应用程序中。

他们不仅要重新为新标签提供服务,还必须重新构建完整的系统并进行相应部署。

为了应对这种挑战,开发人员决定将其应用程序从单体架构转移到微服务。如下图:

5.png



购物车应用程序的微服务架构

这意味着开发人员不必创建Web微服务,逻辑微服务或数据库微服务。相反,他们为搜索,推荐,客户服务等创建单独的微服务。

这种应用架构不仅有助于开发人员克服以前架构面临的挑战,还有助于轻松构建,部署和扩展购物车应用程序。

微服务设计指南

作为开发人员,决定构建应用程序时,要将各个域分离,并在功能上明确。
设计的每一个微服务都只专注于应用中的一个服务。
确保设计的应用程序使每个服务都可以单独部署。
确保微服务之间的通信是通过无状态服务器完成的。
每一项服务都可以被推进到更小的服务中,拥有自己的微服务。

在设计微服务时,已经了解了基本的指导方针,现在来了解一下微服务的架构。

微服务架构是如何工作的?

一个典型的微服务架构(MSA)应该包括以下组件:
1.客户端
2.身份提供者
3.API网关
4.消息格式
5.数据库
6.静态内容
7.管理
8.服务发现
如下图:


7.png



微服务架构
这个架构看起来有点复杂,让我们来简化一下。

1、客户端

架构始于不同类型的客户端,从不同的设备尝试执行各种管理功能,如搜索、构建、配置等。

2、身份提供者

这些来自客户端的请求将传递给身份提供者,这些提供者对客户端的请求进行身份验证,并将请求传递给API网关。然后,请求通过定义良好的API网关与内部服务通信。

3、API网关

由于客户端不直接调用服务,因此API网关作为客户端将请求转发到适当的微服务的切入点。

使用API网关的优点包括:

•所有服务都可以在客户端不知情的情况下进行更新。
•服务也可以使用非网络友好的消息传递协议。
•API网关可执行跨切割功能,如提供安全性、负载均衡等。

在接收到客户端的请求后,内部架构由微服务组成,这些微服务通过消息相互通信来处理客户端请求。

4、消息格式

有两种类型的消息通过它们进行通信:

•同步消息:在客户端等待服务响应的情况下,微服务通常倾向于使用REST (Representational State Transfer),因为它依赖于无状态、客户端服务器和HTTP协议。这个协议被用作一个分布式环境,每个功能都用一个资源来表示,以执行操作。

•异步消息:在客户端不等待服务响应的情况下,微服务通常倾向于使用AMQP、STOMP、MQTT等协议。这些协议在这种类型的通信中使用,因为消息的性质被定义,这些消息在实现之间可以互操作。

下一个问题是,使用微服务的应用程序如何处理数据?

5、数据处理

每个微服务都拥有一个专有数据库来捕获它们的数据并实现相应的业务功能。此外,微服务的数据库只通过其服务API进行更新。参考下图:


8.png



微服务处理数据演示

微服务提供的服务被转发到任何支持不同技术栈的进程间通信的远程服务。

6、静态内容

在微服务内部进行通信后,将静态内容部署到基于云的存储服务,通过内容交付网络(CDN)直接将其交付给客户端。

除了上述组件,还有一些其他组件出现在典型的微服务架构中。

7、管理

该组件负责平衡节点上的服务和故障识别。

8、服务发现

用作微服务的指南,以找到它们之间的通信路由,由它维护节点所在的服务列表。

现在来看看这个架构的优缺点,以更好地理解何时使用这种架构。

11.png



下面来比较一下UBER之前和现在的架构。
Uber微服务案例
Uber之前的架构

像许多初创公司一样,UBER在开始之初在单一城市运营,为单一产品打造了单体架构。当时有一个代码库似乎被清理了,并解决了UBER的核心业务问题。然而,随着UBER在全球范围内扩张,它们在可扩展性和持续集成方面面临各种各样的问题。


9.png


UBER的单体架构

上图描述了UBER之前的架构。

与乘客和司机连接的REST API。
三种不同的适配器与API一起使用,当预定出租车时,执行诸如账单、付款、发送电子邮件/消息等操作。
MySQL数据库存储所有数据。

因此,可以发现这里所有的特性,比如乘客管理、计费、通知功能、支付、行程管理和驱动管理都是在一个框架内完成的。

问题陈述

当Uber开始在世界范围扩张时,这种框架引入了各种各样的挑战。以下是一些突出的挑战。

所有的功能都必须重新构建、部署和测试,以更新单一功能。
在单个存储库中修复bug变得非常困难,因为开发人员不得不一次又一次地修改代码。
在全球范围内引入新功能的同时,要将这些特性进行扩展是相当困难的。

解决方案

为了避免此类问题,Uber决定改变自己的架构,效仿亚马逊(Amazon)、Netflix、Twitter等其他超级增长公司。因此,Uber决定将其整体架构拆分为多个代码库,以形成一个微服务架构。

参考下面的图表,看看Uber的微服务架构。


10.png



Uber的微服务架构

我们在这里看到的主要变化是引入了API网关,所有的司机和乘客都是通过这个网关连接的。从API网关,所有的内部点都连接在一起,如乘客管理、司机管理、行程管理等。
每个单元是单独的可部署单元,执行单独的功能。例如:如果你想在账单微服务中更改任何内容,那么只需部署账单微服务,而不必部署其他服务。
所有的功能都是单独扩展的,即每个特征之间的相互依赖被移除。

例如,我们都知道,搜索出租车的人数比预订出租车和付款的人要多。这就得到了一个推论:在乘客管理微服务上工作的流程的数量超过了处理支付的流程的数量。

通过这种方式,Uber将其架构从单一业务转移到微服务中获益。


原文链接:
1、What Is Microservices – Introduction To MicroserviceArchitecture
https://www.edureka.co/blog/what-is-microservices/
2、Microservice Architecture – Learn, Build and Deploy Microservices
https://www.edureka.co/blog/microservice-architecture/

换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?

Dataman数人科技 发表了文章 • 0 个评论 • 1620 次浏览 • 2018-03-21 14:32 • 来自相关话题

在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营Kubernetes很重要,以及为什么很难。本文是关于Kubernetes bug导致的一小时中断故障的事后剖析。 ...查看全部
在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营Kubernetes很重要,以及为什么很难。本文是关于Kubernetes bug导致的一小时中断故障的事后剖析。

为什么选择在Kubernetes之上构建?如何将Kubernetes集成到现有基础设施中?本文作者给出的方法是建立 (和改进) 对Kubernetes集群的可靠性的信任,以及构建在Kubernetes之上的抽象。
我们最近在Kubernetes之上构建了一个分布式的cron作业调度系统,这是一个令人兴奋的容器编排的新平台。Kubernetes现在非常流行,并且有许多令人兴奋的承诺:最令人兴奋的是,程序员不需要知道或关心他们的应用程序运行的是什么机器。
什么是Kubernetes?
Kubernetes是一个分布式系统,用于调度程序在集群中运行。你可以告诉Kubernetes运行一个程序的5个副本,它将在工作节点上动态调度它们。容器自动调度以增加利用率,节省资金,强大的deployment primitives允许逐步推出新的代码,安全上下文和网络策略允许企业以安全的方式运行多租户的工作负载。

Kubernetes有很多不同类型的调度能力。它可以调度长时间运行的HTTP服务、在集群中每台机器上运行的daemonsets、每小时运行的cron作业等等。
为什么是Kubernetes?
每个基础设施项目都是从业务需求开始的,我们的目标是提高现有分布式cron作业系统的可靠性和安全性。我们的要求是:

建立和运营一支小团队(只有2人在项目中全职工作)。
在20台机器上可靠地安排大约500个不同的cron作业。

我们决定在Kubernetes之上建立的几个原因:

希望构建一个现有的开源项目。
kubernetes包含一个分布式cron作业调度器,不必自己编写。
kubernetes是一个非常活跃的项目,经常接受捐赠。
kubernetes是用Go写的,很容易学。几乎所有Kubernetes的bug都是由团队中没有经验的程序员做的。

如果我们能够成功地运营Kubernetes,可以在未来的Kubernetes上构建,例如,目前正在开发基于kubernet的系统来训练机器学习模型。

我们以前使用Chronos作为cron作业调度系统,但它不再是满足可靠性要求,而且大部分都没有维护(在过去9个月中1次提交, 最后一次合并请求的时间是2016年3月))Chronos未维护的,我们认为不值得继续投资改善现有的集群。

如果你正考虑Kubernetes,请记住:不要仅仅因为其他公司在使用Kubernetes而使用它。建立一个可靠的集群需要花费大量的时间,使用它的业务案例并不是很突出。把你的时间用在聪明的方法上。
可靠性是什么意思?
说到运营服务,“可靠”这个词本身并没有什么意义。要讨论可靠性,首先需要建立一个SLO(服务级别目标)。

我们有三个主要目标:

99.99%的cron作业应该在预定运行时间的20分钟内开始运行。20分钟是一个很宽的窗口,但是我们采访了内部客户,没有人要求更高的精确度。
Jobs应该运行99.99%的时间(不被终止)。
向Kubernetes的迁移不会导致任何面向客户的事件。

这意味着:

Kubernetes API的短暂停机时间是可以接受的(如果停机10分钟,只要在5分钟内恢复即可)。
调度错误(cron作业运行完全丢失并且根本无法运行)是不可接受的。我们非常重视安排错误报告。
要谨慎对待pod evictions 和安全终止实例,以免作业过于频繁地终止。
需要一个好的迁移计划。
建立一个Kubernetes集群
我们建立第一个Kubernetes集群的基本方法是从零开始构建集群,而不是使用kubeadm或kops之类的工具。使用Puppet(常用的配置管理工具)调配了配置。从头开始构建很好,原因有两个:能够深入地集成Kubernetes在架构中,并且深入理解其内部。

我们希望将Kubernetes整合到现有的基础架构中。与现有系统无缝集成,以便进行日志记录,证书管理,加密,网络安全,监控,AWS实例管理,部署,数据库代理,内部DNS服务器,配置管理以及更多。整合所有这些系统有时需要一点创造力,但总体上比试图让kubeadm / kops成为我们想要的更容易。

在信任并了解如何操作这些现有系统后,我们希望继续在新的Kubernetes群集中使用。例如,安全证书管理是一个非常棘手的问题,已经有办法颁发和管理证书。通过适当的整合,我们避免了为Kubernetes创建新的CA。

准确了解设置的参数是如何影响Kubernetes设置的。例如,在配置用于身份验证的证书/CAs时,使用了超过12个参数。了解这些参数有助于在遇到身份验证问题时更容易调试设置。
对Kubernetes建立信心
在Kubernetes之初,团队中没有人使用过Kubernetes。如何从“没有人用过Kubernetes”到“我们有信心在生产中运行Kubernetes”?



战略0:与其他公司交谈

我们向其他公司询问了Kubernetes的经历。 他们都以不同的方式或在不同的环境中使用Kubernetes(运行HTTP服务,裸机,Google Kubernetes引擎等)。

在谈到Kubernetes这样庞大而复杂的系统时,重要的是认真思考自己的用例,做自己的实验,建立对自己环境的信心,并做出决定。 例如,你不该读这篇博客文章并得出结论:“Stripe正在成功使用Kubernetes,所以它也适用于我们!”

以下是我们在与几家运营Kubernetes集群的公司沟通后后学到的:

优先考虑企业etcd集群的可靠性(etcd是存储所有Kubernetes集群状态的地方)。
某些Kubernetes功能比其他功能更稳定,因此请小心Alpha功能。一些公司只有在稳定后才能使用稳定特性(例如,如果某个功能在1.8版本中保持稳定,则在使用它之前会等待1.9或1.10)。
考虑使用托管的Kubernetes系统,如GKE / AKS / EKS。从头开始建立高可用性Kubernetes系统是一项巨大的工作。 AWS在此项目中没有托管的Kubernetes服务,所以这不适合我们。
注意由覆盖网络/软件定义网络引入的额外网络延迟。

策略1:阅读代码。

我们计划很大程度上依赖于Kubernetes的一个组件,即cronjob控制器。这个组件当时处于alpha阶段,这让我们有点担心。我们在一个测试集群中尝试了它,但是如何判断它在生产中是否适合我们呢?

值得庆幸的是,所有cronjob控制器的核心功能只有400行Go。通过源代码快速读取显示:

cron作业控制器是一个无状态的服务(与其他Kubernetes组件一样,除了etcd)。
每10秒钟,这个控制器调用syncAll函数:go wait.Until(jm.syncAll,10 * time.Second,stopCh)
syncAll函数从Kubernetes API中获取所有cron作业,遍历该列表,确定下一步应该运行哪些作业,然后启动这些作业。

核心逻辑似乎相对容易理解。更重要的是,如果在这个控制器中有一个bug,它可能是我们可以修复的东西。

策略2:做负载测试

在开始认真构建集群之前,我们做了一些负载测试。我们并不担心Kubernetes集群能够处理多少节点(计划部署大约20个节点),但是确实想让某些Kubernetes能够处理我们希望运行的那么多的cron作业(大约每分钟50个)。

在一个3节点集群中运行了测试,创建了1000个cron作业,每个任务每分钟运行一次。这些工作中的每一个都简单地运行bash -c 'echo hello world'。我们选择简单的作业,是因为希望测试集群的调度和编排能力,而不是集群的总计算能力。

测试集群无法处理每分钟1000个cron作业。每个节点每秒最多只能启动一个pod,而集群能够每分钟运行200个cron作业。由于我们只希望每分钟运行大约50个cron作业,所以我们认为这些限制不是阻碍因素。

策略3:优先构建和测试高可用性etcd集群。

在设置Kubernetes时,最重要的事情之一就是运行etcd。Etcd是Kubernetes集群的核心,它是存储集群中所有数据的地方。除了etcd之外,其他一切都是无状态的。如果etcd没有运行,不能对Kubernetes集群进行任何更改(尽管现有的服务将继续运行!)

这张图显示了etcd是Kubernetes集群的核心——API服务器是etcd前面的无状态REST/认证端点,然后其他组件通过API服务器与etcd对话。 在运行时,有两个要点需要牢记:

设置复制,这样集群不会死如果你失去了一个节点。我们现在有三个etcd副本。
确保足够的I / O带宽。我们的etcd版本有一个问题,一个具有高fsync延迟的节点可能触发连续的leader elections,导致集群无法使用。通过确保所有节点的I/O带宽都比etcd的写入数量多,从而弥补了这一点。



设置复制不是一个设置-忘记操作。我们仔细地测试后发现可能会丢失一个etcd节点,并且集群优雅地恢复了。

以下是为建立etcd集群所做的一些工作:

设置复制
监控etcd服务是可用的
写一些简单的工具,以便轻松创建新的etcd节点,并加入到集群当中
编写一些简单的工具,以便我们可以轻松创建新的etcd节点并将它们加入到群集中
补丁etcd的高集成,这样我们可以在生产环境中运行超过1个 etcd集群
测试从一个etcd备份中恢复
测试可以在不停机情况下重建整个集群

很高兴很早就做了这个测试。某个周五的早晨,在我们的生产集群中,一个etcd节点停止了对ping的响应。我们得到了警报,终止了节点,带来了一个新的节点,加入到集群中,同时Kubernetes继续运行。

策略4:逐步将工作迁移到Kubernetes

我们的目标之一是将工作迁移到Kubernetes而不造成任何中断。成功进行生产迁移的秘诀不是避免犯错(这是不可能的),而是设计你的迁移以减少错误的影响。

我们很幸运有多种职位可以迁移到新集群,所以可以迁移一些低影响的工作岗位,接受一两次失败。

在开始迁移之前,构建了易于使用的工具,如果有必要,可以在不到五分钟的时间内在旧系统和新系统之间来回移动作业。这种简单的工具减少了错误的影响 - 如果迁移一个没有计划的依赖的工作,没有什么大不了的!可以将其移回原处,解决问题,然后再试。

以下是我们采用的整体迁移策略:

根据他们的重要程度大致排序
将一些重复的工作迁移到Kubernetes。如果发现新的情况,快速回滚,修复问题,然后重试。

策略5:调查 Kubernetes bug 并修复它们

我们在项目开始时制定了一个规则:如果Kubernetes做了一些意外的事情,必须调查,找出原因,并提出补救措施。

调查每个问题都很耗时,但很重要。如果只是简单地将Kubernetes的”古怪行为”看作是复杂的分布式系统的功能,我们担心,因为它们会被调用导致产生bug集群。

在使用了这种方法之后,我们发现并且修复了Kubernetes的几个bug。

以下是测试中发现的一些问题:

名称超过52个字符的Cronjob无法安排作业。
Pods有时会永远停留在挂起状态。
调度程序会每3个小时崩溃一次。
Flannel的hostgw后端没有替换过时的路由表项

修复这些bug让我们对Kubernetes项目的使用感觉好得多——不仅它运行得比较好,而且也接受补丁并有一个良好的PR审查过程。

Kubernetes有bug,像所有的软件一样。特别是,我们非常频繁地使用调度器(cron作业总是在创建新的pods),而调度器使用缓存有时会导致bug、回退和崩溃。缓存是困难的!但是代码库是可接近的,我们已经能够处理遇到的bug。

值得一提的是,Kubernetes的pod驱逐逻辑。Kubernetes有一个称为节点控制器的组件,它负责将pod驱逐出去,如果节点没有响应,则将它们移到另一个节点。allnodes会暂时无响应(例如,由于网络或配置问题),在这种情况下,Kubernetes可以终止集群中的所有pod。

如果运行的是大型Kubernetes集群,请仔细阅读节点控制器文档,仔细地考虑设置,并进行广泛测试。每次通过创建网络分区测试对这些设置的配置更改(例如,pod-驱逐超时),就会发生令人惊讶的事情。最好在测试中发现这些意外,而不是在生产中发现。

策略6:有意引起Kubernetes集群问题

之前讨论过在Stripe中进行游戏日练习。这个想法是要想出你最终会在生产中发生的情况,然后在生产中故意造成这些情况,从而确保能够处理它们。

在集群上进行了几次练习之后,经常发现诸如监视或配置错误等问题。很高兴在早期发现这些问题,而不是六个月后突然发现。

以下是运行的一些比赛日练习:

终止Kubernetes API服务器
终止所有Kubernetes API服务器并将其恢复(这非常有效)
终止etcd节点
从API服务器中关闭Kubernetes集群中的工作节点(以便它们无法通信)。这导致节点上的所有pods被迁移到其他节点。

很高兴看到Kubernetes如何应对我们投入的大量干扰。 Kubernetes的设计是为了适应错误 - 它有存储所有状态的etcd集群,一个只是该数据库的REST接口的API服务器,以及一个协调所有集群管理的无状态控制器集合。

如果任何Kubernetes核心组件(API服务器,控制器管理器或调度程序)被中断或重新启动,一旦它们出现,它们将从etcd读取相关状态并继续无缝运行。这是我们希望的事情之一,而且在实践中实际运作良好。

以下是测试中发现的一些问题:

“没有得到paged,来修复监控。“
“当销毁API服务器实例并将其恢复后,需要人工干预。最好解决这个问题。“
“有时执行etcd故障转移时,API服务器会启动超时请求,直至重新启动。”

在运行这些测试后,针对发现的问题开发了补救措施:改进了监控,发现了固定配置问题,并提交了Kubernetes bug。
使cron作业易于使用
简单地探讨一下我们是如何使基于kubernetes的系统易于使用的。

最初的目标是设计一个运行cron作业的系统,团队有信心运营和维护。一旦建立了对Kubernetes的信心,就需要工程师们轻松地配置和增加新的cron作业。我们开发了一个简单的YAML配置格式,这样用户就不需要了解Kubernetes的内部结构来使用这个系统。这是我们开发的格式:

name: job-name-here
kubernetes:
schedule: '15 /2 '
command:
  • ruby
  • "/path/to/script.rb"
resources:
requests:
cpu: 0.1
memory: 128M
limits:
memory: 1024M

没有做什么特别的事情——我们编写了一个简单的程序,将这种格式转换为Kubernetes cron作业配置,将其应用于kubectl。

我们还编写了一个测试套件,以确保作业名称不会太长,并且所有名称都是惟一的。我们目前不使用cgroups来强化对大多数作业的内存限制,但计划将来推出。

我们的简单格式易于使用,而且由于自动生成了来自相同格式的Chronos和Kubernetes cron作业定义,所以在两个系统之间迁移作业非常简单。这是使我们的增量迁移工作良好的关键部分。将作业迁移到Kubernetes时,可以用一个简单的三行配置更改,在不到十分钟的时间内将其移回。
监控Kubernetes
监测Kubernetes集群的内部状态非常令人愉悦。我们使用kube-state-metrics软件包进行监测,并使用一个名为veneurl - Prometheus的小型Go程序来获取Prometheus的度量标准,将它们作为statsd指标发布到我们的监控系统中。

例如,以下是过去一小时内集群中未决Pod的数量图表。Pending意味着等待分配一个工作节点来运行。可以看到上午11点的数字峰值,很多cron作业在每小时的第0分钟运行。

还有一个监视器,用于检查有没有任何Pod在Pending状态中卡住 - 每个Pod在5分钟内开始在worker节点上运行,否则会收到警报。
Kubernetes未来计划
设置Kubernetes,到顺畅地运行生产代码并将所有cron作业迁移到新集群,花了五个月的时间,三位工程师全职工作。我们投资学习Kubernetes的一个重要原因是希望能够在Stripe中更广泛地使用Kubernetes。

以下是适用于运行Kubernetes(或任何其他复杂分布式系统)的原则:

为企业的Kubernetes项目,以及所有基础设施项目,定义清晰的商业原因。了解业务案例和用户的需求使项目变得更加容易。
积极削减范围。避免使用许多Kubernetes的基本特性来简化集群。这让我们可以更快速地发送消息,例如,由于pod-to-pod联网不是我们项目的必需条件,可以关闭节点之间的所有网络连接,并将Kubernetes的网络安全性推迟。

花大量时间学习如何正确地运营Kubernetes集群。仔细测试边界情况。分布式系统非常复杂,有很多潜在的问题。以前面的例子为例:如果节点控制器由于配置与API服务器失去联系,那么它可以杀死集群中的所有pods。学习Kubernetes在每次配置更改后的表现如何,需要时间和精心的关注。

通过专注于这些原则,我们已经有信心在生产中使用Kubernetes。我们将继续开发Kubernetes的使用,例如,我们正在关注AWS EKS的发布。我们正在完成另一个系统的工作,训练机器学习模型,并且正在探索将一些HTTP服务迁移到Kubernetes。随着我们继续在生产中运行Kubernetes时,我们计划对开源项目做出贡献。



原文作者:Julia Evans
原文链接:
Learning to operate Kubernetes reliably
https://stripe.com/blog/operating-kubernetes

马斯洛理论告诉你,Kubernetes可以满足微服务的这些需求

Dataman数人科技 发表了文章 • 0 个评论 • 1170 次浏览 • 2018-03-06 15:02 • 来自相关话题

需求层次理论是由心理学家艾伯特·马斯洛设计的,它是一种解释人类动机的心理学理论,它由多层次的人类需求模型组成,通常被描述成金字塔内的等级层次。马斯洛使用诸如生理、安全、归属感和爱、尊重、自我实现和自我超越等来描述人类动机通常所经历的阶段。作为人类,首先需要满足 ...查看全部
需求层次理论是由心理学家艾伯特·马斯洛设计的,它是一种解释人类动机的心理学理论,它由多层次的人类需求模型组成,通常被描述成金字塔内的等级层次。马斯洛使用诸如生理、安全、归属感和爱、尊重、自我实现和自我超越等来描述人类动机通常所经历的阶段。作为人类,首先需要满足我们的基本需求,然后是心理上的需求,只有这样我们才能想到自尊和实现全部的潜能:


102.png



马斯洛需求层次

一、Kubernetes能满足微服务的马斯洛需求

这种描述需求的方法非常重要,已经应用于许多其他领域,如员工敬业度、云计算、软件开发、DevOps等等。所以对于微服务来说也同样适用,为了微服务的成功,清晰的需求列表必须满足。List如下:


103.png



微服务的需求层次结构

一旦列出了微服务的主要问题(对每个人来说可能会有不同的顺序),就会发现Kubernetes容器编排引擎确实能够很好地覆盖这些需求中的很大一部分。我把Kubernetes也添加到图中。

首先,对于基础层,需要一些计算资源,并且理想的情况下,拥有一个由基础设施服务云提供商管理的可伸缩的标准操作环境。其他先决条件是,自动化的CI/CD流程和工件注册表,Kubernetes可以帮助我们运行和管理。我们仍然需要一些专门的软件,比如构建的Jenkins,以及工件存储库,比如按需 Sonatype Nexus for Docker和Maven for Docker Hub。

Kubernetes可以帮助管理多个隔离环境(名称空间)、管理资源(配额和限制)、存储分配(持久卷)、执行部署和回滚(部署)、自动调度(调度)、服务发现和负载平衡(服务)、弹性和容错(pod健康检查)。

对于某些需求,我们还需要一些额外的工具,如Docker或rkt用于容器实现,应用程序内的弹性库(如Netflix的Hystrix)与Kubernetes弹性特性相结合。然后,Kubernetes可以管理应用程序配置,并帮助运行最好的集中式日志记录、度量收集和跟踪软件,随着服务数量的增加,这些也变得非常重要。

根据微服务的性质,企业有一些特定的需求。对于API驱动的微服务,需要专门的API管理解决方案,也可以处理服务安全性(Kubernetes没有提供)。但是Kubernetes可以轻松地帮助企业运行有状态的服务(有状态的设置)、批处理作业(job)和调度作业(cron job)。

通过一个平台提供的所有这些特性,用户可以执行一些更智能的活动,如应用程序和基础设施自动伸缩和自修复,通过自动放置、自动重启、自动复制、自动伸缩。

对于Kubernetes所满足的所有这些需求,团队所剩下的就是精简开发流程,拥抱DevOps文化以实现快速交付,并在组织层面达到反脆弱性。

二、关于Kubernetes你需要知道的8件事

这是《计算机周刊》与 Carlos Sanchez 的问答环节,Sanchez 是 CloudBees 的工程师,CloudBees是持续交付和集成软件服务的提供商。其中开源持续集成工具Jenkins,是CloudBees服务的重点。

《计算机周刊》的开源内部人士(Computer Weekly Open Source Insider,简称:CWOSI)提出了8个与Kubernetes最相关的问题,试图揭开这个问题的核心,因为2017年Kubernetes经历了知名度的大幅提升。

CWOSI #1:对于那些不了解Kubernetes的人,你如何总结和定义这项技术?

Sanchez: Kubernetes是一个开源平台,旨在自动化容器的部署、缩放和操作。它是一种允许在大规模集群上运行容器的技术。它支持跨大型数据中心的隔离应用程序的执行。

CWOSI #2:为什么Kubernetes会在你的观点中出现——为什么我们需要它?

Sanchez: Docker确实成功地制造了容器。事实上,谷歌已经运行了很多年几十亿的容器。Kubernetes从谷歌的经验中得出了这种规模的容器运行,导致谷歌将这项技术引入开源世界,从而使其他人更容易地管理容器。

至于为什么我们需要Kubernetes,这是因为对于大型和小型的组织来说,容器变得越来越重要,授权开发团队在大规模的分布式环境中运行,以便在DevOps和持续交付实践中更快地交付软件。在这种情况下,任何能够简化容器的有效操作和管理的东西都将受到企业的热烈欢迎。

CWOSI #3:Kubernetes本质上是开源的,但是有多少开发人员在为一项本质上是基础设施的技术贡献代码呢?

Sanchez:总的来说,有超过1400名贡献者。谷歌、红帽和微软都被包括在其中。最近,亚马逊和阿里巴巴已经成为参与这项技术的几家最大的公司。CNCF管理整个技术。

CWOSI #4:容器化技术是否最终意味着每个单独的组件在验证其目的和最终交付特定的产出或功能的方面更负责?

Sanchez:容器通常与微服务体系架构相关联。每个组件都期望完成一个特定的协议。这些组件有一个目的,它们有由这个协议和API标记的输入和输出。他们必须能够履行他们的职责。它们应该是独立的,并在体系结构中发挥特定的作用,其中有成百上千种服务共存。

CWOSI # 5:什么时候不需要Kubernetes…当企业不需要大规模或跨多个机器的时候吗?

Sanchez:Kubernetes是一个复杂的系统。如果企业有规模来证明部署的合理性,那么采用这种技术是有意义的。例如,如果只使用一两台虚拟机,或者没有任何更高的要求,企业可能不需要Kubernetes ,Docker自己就足够了。也就是说,谷歌或Azure提供的当前云服务让我们很容易从Kubernetes和大规模开始。

CWOSI #6:能给我们解释一下Kubernetes pod吗?

Sanchez:Kubernetes pod实际上是一组在同一个主机上运行的容器。这些容器具有一定的特点。例如,它们共享相同的网络空间和资源。真正的Kubernetes pod是由需要共存的容器组成的。

CWOSI #7:让Kubernetes出错,并把错误的实施组合在一起有多容易?

Sanchez:这又回到了安装上——这是一个复杂的软件,需要专门的专业知识。这就是人们使用谷歌Kubernetes引擎或Azure容器服务的原因。

也就是说,有越来越多的工具,无论是开源的还是商业的,比如kops、kube-aws或者kubeadm都可以帮助执行正确的安装。如果您不使用其中一个安装程序来简化安装,那么在此过程中可能会犯错误。

CWOSI #8:在你看来,Kubernetes在接下来的几年中会如何发展?

Sanchez:将会有越来越多的Kubernetes产品从不同的供应商进入市场,不仅仅是云提供商,还有操作系统提供商。Kubernetes将成为集群的实际操作系统。另外,Kubernetes将会发展成为一套标准API,允许企业运行集群架构。

我们看到云提供商正在破坏基础设施,这样企业就可以运行Kubernetes,而无需运行服务器。因此,我们将看到供应商提供Kubernetes作为服务,企业将能够在云中运行容器,而不必担心机器。AWS已经宣布了提供这一服务的意向,这一趋势将继续在其他供应商中施行。


原文链接:

1、Kubernetes and theMicroservices Hierarchy of Needs
https://thenewstack.io/introducing-microservices-hierarchy-needs/?utm_content=bufferba844&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

2、CloudBees:9 things you need to know about Kubernetes
http://www.computerweekly.com/blog/Open-Source-Insider/CloudBees-9-things-you-need-to-know-about-Kubernetes?utm_source=tuicool&utm_medium=referral

悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系

Dataman数人科技 发表了文章 • 0 个评论 • 1231 次浏览 • 2018-03-01 11:26 • 来自相关话题

Datawire团队最近的一次交流,是关于“PaaS”这一术语的真正含义,以及它与开发人员体验(DevEx)和工作流之间的关系,带来了许多可以分享的内部对话。从和客户一起工作,到会议上与人的聊天中,我感觉到,其他团队对于部署应用程序时“平台”和工作流之间的关系 ...查看全部

Datawire团队最近的一次交流,是关于“PaaS”这一术语的真正含义,以及它与开发人员体验(DevEx)和工作流之间的关系,带来了许多可以分享的内部对话。从和客户一起工作,到会议上与人的聊天中,我感觉到,其他团队对于部署应用程序时“平台”和工作流之间的关系也有些不确定,我希望以建设性的方式,能提供一些清晰的认知,或者至少能够学到一些东西。

基础设施、平台、工作流三者缺一不可
Daniel Bryant是一名独立的技术顾问,专注于通过价值流识别、管道的创建和有效的测试策略实施,来实现组织内的持续交付。Daniel的技术专长在于DevOps工具、云/容器平台和微服务实现。他还参与了几个开源项目,为InfoQ、O 'Reilly和Voxxed撰稿,并定期出席OSCON、QCon和JavaOne等国际会议。

从基本原则开始说起,所有基于web的软件开发都涉及到三层:

基础设施:这一层提供原始计算资源的抽象,如裸金属、vm、操作系统、网络、存储等,这些资源最终将负责处理与应用程序相关的代码和数据。这里避免使用“物理”这个术语,因为尽管所有的东西最终都是在硬件上运行的,但是我们越来越多地看到基础设施的抽象转移到软件定义的所有东西(Software-Defined-Everything,SDx)。

平台:这一层提供了粗粒度的系统级构建块,它可能是运行时特定的,比如一个集成的JVM或CLR的计算实例,还有数据存储、中间件、IAM、审计等等。值得一提的是,相信你总是将应用程序部署到某种形式的平台上,即使没有有意识地组装它。

工作流:这一层是如何设计、构建、测试、部署、运营应用程序的总和。每个开发人员都有一个工作流(即使它是隐性的),从个人的独立网站构建者,到一个在复杂的企业系统中工作的数千人团队。

当我和朋友和客户谈论这个模型时,我通常会就概念和结构达成某种形式的协议。当开始讨论这些概念之间的耦合时,特别是与PaaS有关时,分歧就开始了。
这些是你正在寻找的平台
我经常听到“PaaS有一个内置的工作流程”,或者“如果你正在运行一个PaaS,那么你不需要知道基础设施。”我并不特别同意这些说法,并且在努力建立共同的理解。PaaS经历了几代模式的发展:

第一代:Heroku和它的朋友们。这种类型的PaaS隐藏了底层云基础设施(通过可部署的slugs和“Dynos”),并提出了非常有见地的工作流程,与平台耦合。对于简单的单体Ruby应用程序,这非常棒,可以在几分钟内熟练部署工作流程,并且所有知识都可以转移到下一个项目复用。

第二代:Cloud Foundry(DEA版)和它的朋友们。这种类型的PaaS可以部署在企业的基础设施上,并且带来企业自己的buildpacks和运行时。工作流仍然集成在一起,但是该平台开始通过上下文路径路由(context path routing )等概念启用多服务应用程序(和工作流程)。

第三代:Cloud Foundry(Diego版)以及当前版本的Google App Engine和AWS Elastic Beanstalk(两者分别从第一代和第二代PaaS演变而来)。这些PaaS对基础架构的依赖更低,企业可以携带自己的容器,并且文档清楚了解运行时和计算环境的限制。这里的工作流程正在转向支持分布式系统(微服务),并鼓励开发人员从目前“推荐的做法”中构建自己的持续交付管道的工作流程,可能使用Concourse或Spinnaker等工具。

第四代:Kubernetes,Docker Swarm,Mesos,HashiCorp Nomad,AWS ECS等等(我明白这些并不是真正的PaaS)。这种类型的平台基础设施是不可知的。谁没有参加过会议并且看到Kubernetes在Raspberry Pi集群上运行?而且总是接触到构成集群的底层计算和网络基础设施(AWS Fargate例外)。也可以部署任何类型的容器或流程。这个平台出现了构建“云原生”应用的愿望,这些应用程序本质上是分布式的。这里的“最佳实践”工作流程尚未定义,或者更准确地说,目前仍与技术协同发展 - 并且我们正在对CI / CD进行最新的了解并改进。

因此,这是一个有趣的开源和商业工具正在出现的领域:想一下Datawire的Forge和Telepresence 工作流工具,Ambassador的交通转移/部署,Weaveworks的Flux和Scope,Heptio和Bitnami的ksonnet,微软的Draft 和 Helm,Containous traefik负载均衡器/ API网关。

我相信平台与工作流程耦合之间产生了混淆,因为很多企业部署了粗粒度(单体?)风格的应用程序,其中工作流与平台紧密结合。即第一代和第二代PaaS,或者工作流松散耦合,但定义明确,我们没有注意到这种摩擦 - 即在传统基础架构或第三代PaaS上构建和部署特定语言的组件。

第四代平台面临挑战,技术仍在成熟,架构及相关组织最佳实践也在共同发展中--分别考虑微服务和无服务器,以及 inverse Conway maneuver。业务对速度,稳定性和可见性的压力也越来越大,这通常是通过将业务流程(形成跨职能业务部门)分解并将决策权下放给一线工作团队来实现的。这以商业运动为代表,例如 holacracies 和 Teal organizations。

回顾上面的软件开发层面,需要指出的一个关键点是,基础设施和平台正在变得越来越分散和分离,但它们是通过集中化的力量实现的 - 例如基础设施中的AWS,以及平台中的Kubernetes(Apps SIG)社区,它定义了常用的协议,标准和接口。工作流程也变得分散,但我认为现在还没有集中的力量,即一种通用的描述性语言,一套工具和预定义(可插入)的工作流程步骤。

构建(Snowflake)定制工作流程
随着拥抱Kubernetes的组织越来越多,团队创建定制的开发者体验工作流程,通常在单个组织内的团队中存在差异,导致解决方案很脆弱,以及有限的共享学习。这些团队试图将他们的工作流程编写成最终在Kubernetes之上建立一个平台。部署到平台上至关重要,但平台和工作流的概念应该分开考虑和设计。紧密耦合平台和工作流程会导致不灵活的开发人员工作流程。

相信Kubernetes的“平台”在2018年已经变得越来越清晰。Kubernetes本身已经很好地成熟了,而Envoy,Conduit和Cilium等公司的服务网格正在填补平台的一些缺失的部分。但是,围绕开发人员的体验还有很多想法需要去做。我们看到Weaveworks GitOps和Atlassian BDDA(Build-Diff,Deploy-Apply)等方法论中将最佳实践编纂在内,相信在应用程序开发(AppDev)领域会出现类似的东西。

Kubernetes可能会接管应用程序的整个生命周期
今天形成了Kubernetes无处不在的云原生景观。三家主要云提供商,AWS、Google和微软Azure都支持Kubernetes,甚至Docker和Cloud Foundry也在使用它。

是什么使Kubernetes独一无二?传统意义上,通常是开源技术创造了商品化的产品替代主流闭源技术。 但Kubernetes一直是个例外。 “Linux是UNIX的竞争者,Apache web服务器是Apache IIS的竞争对手。那么谁是Kubernetes的竞争对手?并没有与之竞争的闭源产品,”CoreOS首席技术官兼联合创始人Brandon Philips 说。

实质上,Kubernetes在与人们创建的所有脚本进行竞争,以将他们在笔记本电脑上开发的源代码部署到生产环境中。有成千上万的方法可以做到这一点:CI / CD工作流程,bash脚本,配置管理工具等。为了获得生产所需的所有东西,数周的开发一直是个痛苦的周期。这就是Kubernetes来拯救的地方。它通过创建 API 来缩短这个周期,提供了适用于任何类型的一致性和可重复性。

“这是Kubernetes的重点,”Philips表示,“随着时间的推移,我们可能会接管应用程序的整个生命周期,从idea到监控到应用程序工作流程,到最终退出应用程序。我们已经看到用户在扩展Kubernetes api。Philips认为,这将继续,“天空是我们所依赖的抽象的极限。 “看看它在未来几年的发展将会很有趣。”



原文链接:
1、Kubernetes and PaaS: The Force of DeveloperExperience and Workflow
https://thenewstack.io/kubernetes-paas-force-developer-experience-workflow/
2、Over Time, Kubernetes May Take Over theEntire Lifecycle of Applications
https://thenewstack.io/time-kubernetes-may-take-entire-lifecycle-applications/

看好还是看衰?8位业界大咖这么看Serverless的2018

Dataman数人科技 发表了文章 • 0 个评论 • 1138 次浏览 • 2018-02-24 10:35 • 来自相关话题

导读: Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖 ...查看全部
导读:

Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖研究了Serverless14个月,优缺全体现!,再比如,容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事。今天这篇主要由8位业内意见领袖谈2018Serverless的去向。
2.jpg

在所谓的无服务器IT系统中,数据工作负载是如何处理的?

亚马逊的AWS Lambda是无服务器计算最大、最著名的例子,它的未来对很多IT人来说是非常诱人的。Lambda是由 Amazon开发的一个事件驱动的计算平台,当特定事件发生时,它会自动触发或执行代码。Lambda只在需要时执行代码,并自动伸缩,为企业处理一些数据流程和应用程序,提供潜在的成本节约和灵活性。

Amazon 在2014年发布了Lambda,作为企业在云中运行代码的“无服务器”平台,不需要物理服务器,也不需要在企业端提供或管理任何服务器。


1、Serverless无服务器是未来的潮流

在应用程序代码方面,AWS支持Node.js、Java、c#和现在的Python,只要开发人员在其中一种语言中编写代码,代码就可以在Lambda运行环境中运行,并利用Lambda资源。

亚马逊并不是唯一的FaaS供应商,其他还包括谷歌云,微软Azure,IBM OpenWhisk和开源项目Iron.io,以及Webtask。

无服务器的工作负载生产仍然处于初级阶段,但如果IT界的各种预言者都是正确的,那么它将很快在我们眼前成长起来。

以下是一些来自行业专家对serverless未来的展望:

>>>>Sumo Logic (相扑逻辑):无服务器计算可能是继容器之后的未来

AWS的采用率几乎翻了一番,从2016年的12%上升到2017年的23%。serverless的整个想法是,它通过完全跳过容器和DevOps将微服务转移到未来。事实上,有四分之一的开发人员已经在使用serverless,这对于遵循应用程序架构和采用的人来说是一种强烈的信号。IT领导者已经在谈论DevOps,但是serverless将它带到一个全新的世界“NoOps”——在没有基础设施的情况下,应用程序在云中运行。


>>>>Avere Systems技术总监Dan Nydick : 我们将看到更多serverless技术和托管服务

企业经常花费大量的时间和精力来管理计算基础设施,这不是他们任务和使命的核心任务。公有云的好处之一是,将应用程序迁移到云上之后,企业不再需要管理这些基础设施。云供应商提供了越来越高水平的管理服务,允许客户专注于自身业务,而不必被虚拟机、web服务器或数据库管理分散注意力。

我们将看到更多使用托管的、可伸缩的web服务(如谷歌 App Engine和AWS Beanstalk)和无服务器技术(如AWS Lambda和谷歌CloudFunctions),作为管理和部署复杂企业应用程序的更经济的方式。

“我们预计云供应商将继续向更高级别的托管服务发展,例如完全分布式数据库管理(谷歌Cloud Spanner),以及第三方出售托管在公有云(Azure Managed Apps)中的应用程序的新能力。”


>>>>Atlassian平台负责人Steve Deasy:2018将如何改变软件的构建方式

“随着来自主要云供应商的支持,无服务器的框架将会受到欢迎。”此外,数据驱动的应用程序将继续受到欢迎,而对工程师需求的支持也将以工具、基础设施和争论(wrangling)的形式出现。在《Mortal Kombat》中提到,Kubernetes将给现有的平台带来致命的灾难。


>>>>Evident.io公司CEO Tim Prendergast和客户解决方案副总裁John Martinez:容器和无服务器计算增加,它们会带来安全问题。

“2018年,公司将采用云计算的方式,传统的基于主机的操作系统将变得无关紧要,或者需要重新设计。”从安全的角度来看,没有人真正准备好保护所有这些容器和功能计算,但是人们还是采用了它。


>>>>Contino公司主席Jason McDonald:无服务器采用将继续增加其影响。

“Serverless将从云产业的小角落转移到聚光灯下,因为它解决了IT三个关键领域的管理:速度、成本和风险。事实上,亚马逊推出AWS Fargate,这是一种创新,它通过删除服务器,消除运行ECS集群所需的基础设施管理,从而极大地改变了容器的演化。

目前,至少有一家美国主要银行正在运行企业级应用程序,这是一个基于Lambda的专职基础架构,可解决成本和规模问题。未来将会有越来越多类似这样的故事,基于云的堆栈越来越多地迁移到无服务器架构中。


>>>>OVH US公司技术布道者和首席系统工程师 Paul Stephenson: 无服务器计算解决哪些用例将会更清晰。

“这项技术目前非常具有探索性,事件驱动的技术仍在继续。”很高兴看到这一领域发生的一切, 因为IT做的任何事情都可以提高企业业绩表现,同时保持相同或较低的风险状况,这将推动企业进行调研和投资。”


>>>>Data Expedition CEO Seth Noble: 2018年,Serverless将与其他技术整合

云供应商给客户和第三方留下了许多关键的云迁移元素。这为一些关键领域(如数据输入、数据组织和应用部署)带来了隐形成本。2018年,我们将会看到更多客户要求实际的解决方案,如真正的网络加速,缩小对象存储和文件存储之间的差距,以及更好的工具来集成基于无服务器的应用程序和无服务器服务。


>>>>Platform9 CEO Sirish Raghuram: Kubernetes将会在AWS Lambda无服务器部署中变得更有影响力。

Kubernetes不仅可以让云更容易交叉使用,还可以降低云提供的其他高价值应用服务的价值。比如Lambda,用于无服务器计算。有很多开源的替代方案,比如Fission,开源并运行在任何Kubernetes集群上,提供了相同的价值主张。这仅仅是一个例子,说明云提供商自身原生服务的价值可能会发生级联变化,还会发生在Kubernetes生态系统中可用的应用服务范围内。“



2、7大提供FaaS的开源无服务器框架

随着虚拟化技术的发展,企业开始意识到物理硬件的利用率越来越高。随着云计算的发展,企业开始逐渐将虚拟机用于即付即用的服务中,AWS在2014年推出了Lambda服务,引入了云计算的新范例,如今已经成为通常所说的无服务器计算。在无服务器模式中,企业将功能作为服务付费,而不需要为永远在线的状态虚拟机付费。AWS lambda开创了serverless,现在有多个开源项目构建可用于多重部署的无服务器框架:

1.Apache Openwhisk

IBM启动了apache openwhisk项目,现在它是IBMCloud Functions服务的基础。

2.Fission uses kubernetes for serverless
由云服务供应商Platform9领导的开源Fission项目是一个基于Kubernetes的无服务器框架。”Fission是开放源代码项目,旨在成为lambda事实上的开源替代品,”Madhura Maskasky,PLatform9的联合创始人,在2017年1月采访时对eWEEK说。

3.IronFunctions
IronFunctions是一种以Go语言编写的FaaS平台。功能是任何云计算,包括公有云、私有云和混合云提供开源无服务器计算平台。

4.Fn project backed by Oracle
2017年10月甲骨文公司宣布开源Fn项目,为apache许可的无服务器项目。

5.OpenFaas
OpenFaas 是一种能够使docker或者kubernetes都变成无服务器的开源项目,是一种FaaS框架。

6.Kubeless
开源框架Kubeless是由2017年3月被Bitnami收购的软件供应商Skippbox开发的。
kubeless是一个kubernetes本地无服务器框架,具有符合AWS Lambda CLI的命令行界面(CLI)

7.Riff
在最新的开源无服务器框架中,Riff项目得到了关键支持,并且是即将到来的Pivotal Function Service(PFS)的基础。


>>>>调查显示企业不断从私有云转向公有云
一项对300名IT专业人员的调查显示,公有云系统将继续快速增长,因为企业将把他们的本地数据中心资产转移到云平台。

Serverless这种新兴的云计算服务交付模式为开发人员和管理人员带了很多好处。它提供了合适的灵活性和控制性级别。Serverless架构正在彻底改变软件开发和部署流程。


原文链接:
1、Predictions 2018: Why Serverless Processing May Be Wave of the Future
http://www.eweek.com/innovation/predictions-2018-why-serverless-processing-may-be-wave-of-the-future
2、7 Open-Source Serverless Frameworks Providing Functions as a Service
http://www.eweek.com/cloud/7-open-source-serverless-frameworks-providing-functions-as-a-service

基于容器生态扩张的DevSecOps为啥引关注?

Dataman数人科技 发表了文章 • 0 个评论 • 1135 次浏览 • 2018-02-08 10:26 • 来自相关话题

DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。 像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒 ...查看全部
DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。

像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒作和盗用。但是这个术语对拥抱DevOps文化的IT领导者以及实现其承诺的实践和工具而言,具有真正的意义。

DevSecOps什么意思?

Datic公司首席技术官兼共同创始人RobertReeves说:“DevSecOps是开发,安全和运维的组合。它提醒我们,对于应用程序来说,安全和创建、部署到生产上同样重要。”

向非技术人员解释DevSecOps的一个简单方法:它有意识地更早地将安全性融入到开发过程中。

红帽安全战略家Kirsten Newcomer 最近告诉我们: “历史上,安全团队从开发团队中分离出来,每个团队都在不同的IT领域拥有深厚的专业知识 。“其实不需要这样。关心安全的企业也非常关心通过软件快速交付业务价值的能力,这些企业正在寻找方法,将安全性留在应用开发生命周期内。通过在整个CI / CD中集成安全实践,工具和自动化来采用DevSecOps。”

她说:“为了做到这一点,他们正在整合团队。安全专业人员将从应用开发团队一直嵌入到生产部署中。” “双方都看到了价值,每个团队都拓展了他们的技能和知识基础,成为更有价值的技术专家。正确的DevOps或DevSecOps ,提高IT安全性。”

IT团队的任务是更快,更频繁地交付服务。DevOps成为一个很好的推动因素,部分原因是它可以消除开发和运营团队之间的一些传统冲突,Ops通常在部署之前被排除在外,而Dev将其代码丢在无形的墙上,从来不进行二次管理,更没有任何的基础设施维护责任。说得委婉一些,在数字化时代,这种孤立的做法会产生问题。按照Reeves的说法,如果安全是孤立的,也会存在类似的问题。

Reeves说:“我们采用DevOps,它被证明可以通过扫除开发与运维之间的障碍来提高IT的性能。“就像不应该等到部署周期结束才开始运维一样,也不应该等到最后才考虑安全问题。”
DevSecOps为什么会出现?

将DevSecOps看作是另一个流行语是一种诱惑,但对于安全意识强的IT领导者来说,这是一个实质性的概念。安全必须是软件开发流程中的“一等公民”,而并非最终步骤部署,或者更糟糕,只有在发生实际的安全事件后才受到重视。

SumoLogic公司安全与合规副总裁George Gerchow表示:“DevSecOps不仅仅是一个流行词,由于诸多原因它是IT的当前和未来状态。“最重要的好处是能够将安全性融入到开发和运营流程中,为实现敏捷性和创新提供保障。”

此外,在场景中出现的DevSecOps可能是DevOps自身正在成熟并深入挖掘IT内部的另一个标志。

“企业DevOps文化意味着开发人员能够以更快的速度向生产环境提供功能和更新,特别是当自组织团队更加乐于协作和衡量结果。”CYBRIC首席技术官兼联合创始人Mike Kail说。

在采用DevOps的同时,保持原有的安全实践的团队和公司会遇到更多的管理安全风险的痛苦,因为DevOps团队会部署地更快、更频繁。
手动测试安全方法逐渐落后
“目前,手动测试安全方法逐渐落后,利用自动化和协作将安全测试转移到软件开发生命周期,从而推动DevSecOps文化,这是IT领导者提高整体弹性和交付安全保证的唯一路径。”凯尔说。

(早期)对安全性测试的改变也让开发人员受益:在开发新服务或部署更新服务之前,他们并没有发现代码中的明显漏洞,而是经常在开发的早期阶段发现并解决潜在的问题,几乎没有安全人员的介入。

SAS首席信息安全官Brian Wilson表示:“正确的做法是,DevSecOps可以将安全性纳入开发生命周期,使开发人员能够更快,更方便地保护应用程序,不会造成安全干扰。

Wilson将静态(SAST)和源代码分析(SCA)工具集成到团队的持续交付中,帮助开发人员在代码中对潜在问题,以及第三方依赖的漏洞进行反馈。

Wilson说:“开发人员可以主动、反复地缓解app的安全问题,并重新进行安全扫描,无需安全人员参与。DevSecOps还可以帮助开发团队简化更新和修补程序。

DevSecOps并不意味着企业不再需要安全专家,就像DevOps并不意味着企业不再需要基础架构专家一样。它只是有助于减少瑕疵进入生产的可能性,或减缓部署。
DevSecOps遭遇的危机

来自Sumo Logic公司的Gerchow分享了DevSecOps文化的实例:当最近的Meltdown和Spectre消息出现时,团队的DevSecOps方法能够迅速做出响应,以减轻风险,而对内外部客户没有任何明显的干扰。 对云原生和受高度监管的公司来说非常重要。

第一步,Gerchow的小型安全团队(具备开发技能)能够通过Slack与其主要云供应商之一合作,确保基础设施在24小时内完全修补好。

“然后,我的团队立即开始了OS级别的修复,不需要给终端用户停机时间,也无需请求工程师,那样意味着要等待长时间的变更管理流程。所有这些变化都是通过Slack打开自动化Jira tickets进行的,并通过日志和分析解决方案进行监控,“Gerchow解释说。

这听起来像DevOps文化,正确的人员、流程和工具组合相匹配,但它明确地将安全作为该文化和组合的一部分。

Gerchow说:“在传统环境下,停机需要花费数周或数月的时间,因为开发、运营和安全这三项功能都是孤立的。凭借DevSecOps流程和理念,终端用户可以通过简单的沟通和当天的修复获得无缝的体验。”

02
2018DevSecOps三大预测

2018年企业的DevSecOps将迎来一些真正的变革。

对于DevSecOps来说,2017年是美好的一年,DevSecOps从一个半朦胧的概念演变成可行的企业功能。

容器和容器市场的迅速扩张在很大程度上推动了这一演变,容器市场本质上与DevOps和DevSecOps相互交织在一起。一般来说,快速增长和创新往往比科学更能预测趋势,但我仍然愿意尝试一下。

从Docker Hub和成熟的容器生态系统中获取了超过120亿张图片,就企业的DevSecOps而言,我们几乎看不到冰山的一角。不过,相信在2018年,我们将看到:基础变革的开始。我认为它会是这样的:

>>>1.企业领导者和IT利益相关者意识到DevSecOps正在改进DevOps
DevOps将开发团队和运维团队聚在一起,它推动协作文化不足为奇。加入安全举措可能听起来很简单,但多年来,安全问题一直是事后的事情,导致企业文化容易使安全团队与其他IT团队形成对立,包括开发团队。



但是事情发生了变化。

在雅虎亏损3.5亿美元的商业环境下,暴露了其脆弱的安全状况,企业领导者将网络安全看作是一个运维sinkhole的时代已经结束。加强网络安全现在是企业的当务之急。但这种转变需要时间才能重新回到IT文化中。

DevOps和DevSecOps的崛起无疑为重塑应用程序安全性创造了一个难得且令人兴奋的机会,但是DevOps可能会导致转变速度发生变化。DevOps团队和应用程序架构师每天都能够认识到安全的重要性,并欢迎安全团队的加入,但他们之间仍然存在需要磨合的鸿沟。

为正确实施DevSecOps,安全团队需要与DevOps团队保持一致,企业领导者需要为此打造空间和预算。到2019年,希望企业领导人能够意识到推动一个重要的、合法的安全胜利的机会。

>>>2.成功的组织模式将会出现,最可能的是,安全与DevOps团队之间的紧密协作。



虽然该预测并不特别具有启发性,但是相关的。了解DevSecOps需要来自安全和DevOps团队的平等协作,快速跟踪标准蓝图或实施模型,将DevSecOps集成(并最终自动化)到CI / CD进程中。

虽然不同企业有不同的需求,但大多数公司都使用相同的技术工具,特别是在使用容器的情况下。这就为统一的标准化提供了条件。此外,容器的开源特性可以促进相关信息的共享和标准开发。

到目前为止,由于DevOps团队拥有开发流程,他们一直在安全方面处于领先地位。然而,我认为,DevSecOps需要由安全团队领导, 他们是负责企业安全和风险的人,当安全事故发生时,他们会被解雇或被迫离开。

2018年,安全团队需要加强并展示团队的价值和技能。将安全性融入到IT结构中,而不是在网络安全问题成为事实之后才想起。现在我们有机会来实现这一目标。

>>>3.安全团队仍然要缓慢适应DevOps的现实



过去,企业安全团队通常在不重视或不了解安全需要的文化中运营。难怪今天的电商环境是大多数企业相对容易被破坏的环境。

强大的安全性不仅仅是外围的防火墙。尽管许多安全专家可能最终会看到这种转变,但可能不像DevOps团队所期望的那样灵活。当谈到容器(通常是appsec)时,即使是最有才华和最优秀的安全专家也会面临学习的瓶颈。更不用说已经被充分证明的网络安全技能短缺的现状。

虽然这些因素可能在短期内降低安全对DevOps和 DevSecOps的支持,但是我认为DevSecOps是解决技能短缺问题的一部分。将安全集成到应用程序交付过程中,并将其自动化比用回溯方法更有效率和更具成本效益,可以解决在部署应用程序之前解决安全漏洞。安全专业人士可以通过开放的态度,以新的方式发挥他们的才能,从而获得很多收益。

2018年希望这个故事有一个快乐的结局。

原文链接:
1、3 predictions for devsecops in 2018
https://www.infoworld.com/article/3243155/devops/3-predictions-for-devsecops-in-2018.html
2、 Why DevSecOps matters to IT leaders
https://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders

PPT | 从架构到组件,深挖istio如何连接、管理和保护微服务2.0?

Dataman数人科技 发表了文章 • 0 个评论 • 1506 次浏览 • 2018-02-07 18:53 • 来自相关话题

2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。 ...查看全部

2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。

数人云Meetup每月一期,欢迎大家来面基、学习。本文为中兴通讯资深研发教练&系统架构师张晔分享的“微服务2.0:istio架构纵览”现场演讲实录。


近几年我一直从事于微服务系统的设计以及实现方面的工作,属于微服务架构一线实践者。之前做过一些单体系统的微服务改造,在微服务拆分、治理等方面都有一定的经验。

本人比较特殊一点的经历是既做过 IT 领域的微服务,也做过 CT(通讯领域)的微服务,微服务架构在这两个领域的具体形态和要求是不太一样的,但其中一些思想是互通且是很有借鉴意义的。今天主要介绍一下关于微服务的最新发展动态,以及最近谷歌推出的 Istio平台架构。

今天介绍的主题包含:服务治理、服务网格、Istio架构,以及 Istio 相应的系统组成。


一、分布式计算的八个谬论


彼得多维奇多年前提出的分布式计算的八个谬论,对于开发人员来说他们往往会忽视这八条。这八条基本上都和网络相关,例如在发起一个网络请求时,会不断地做一些尝试等待,来保障消息投递的有效性。

微服务是一个更为复杂的分布式系统,之前 SOA 或者B/S,CS 架构,它的颗粒度会更粗一点,但是如果采用微服务,它的颗粒度是更细的。在马丁·富勒博客《微服务的先决条件是什么》一文中提到一条,你必须要成为“高个子”,想成为“高个子”其实并不简单,很多公司,它们都是为了成为“高个子”,做了很多框架、平台。



二、服务治理

1
微服务治理的技术点


要成为“高个子”需要对微服务进行哪些改造,这里是相关服务治理的技术点,其中只是一部分,和服务网格比较相关的技术点,包含服务发现、负载均衡、请求路由、认证与授权、可观测性,还有健康检查、容错等。目前主流的解决方案有众所周知的 Spring Cloud, Dubbo 等,这些都是提供库来把服务治理相关的内容打包,供具体的业务去调用。


2
库或框架的问题

但是库和框架会存在一些问题:

1、学习成本。多一个库对于开发人员而言,意味着要多学一些东西,并且在业务开发过程中,还会受到库或者框架的制约。

2、对业务代码的侵入性。例如用 Spring Cloud 会在代码里面加很多额外的内容,比如每个请求里面加一个注解来表达想引用服务治理的某些功能。

3、基础库的维护、升级和下线。如果是以库的方式来提升到服务里面,库的维护、升级、下线就会造成整个服务的维护、升级、下线。

4、不同语言和技术栈。在提出微服务概念时,它的一个重要好处就是可以使用不同的技术栈来开发微服务,但如果受到框架制约,只能用这个语言,这是我们比较头痛的事情,无法发挥微服务跨语言的能力。

这些问题其实是有严重程度的,从上往下越来越让开发人员觉得不舒服。理想中的服务治理方案是什么?可以先畅想一下,整个服务治理相关的东西,应该是和业务逻辑完全隔离的,并且服务和服务之间的交互是不会考虑服务治理这块内容,最好对于业务开发来说是不可见的。

这时候怎么去做呢?就引出了容器经典部署模式——Sidecar。


3
Sidecar模式


Sidecar 模式通常是和容器一起使用,如果不和容器一起使用也没关系,那就是两个独立的进程,如果和容器使用的话,就基于容器为单位。Sidecar模式是物理隔离的,并且与语言无关。因为是两个独立的东西,可以独立发布,和微服务理念一样。另外它们是部署在同一个 Host 上面,所以资源之间可以做到相互访问,并且因为在一起所以通信延迟也不会太明显。和业务无关的功能都可以放上去,形成多个 Sidecar。今天 Sidecar 主要是把一些服务治理相关的东西放在里面,做软件设计上的思想就是分离关注点。


基于 Sidecar 模式做服务治理,之后形成连接的具体状况,如图,对于服务A来说,服务A是不知道和 Sidecar 进行通信,服务A还是向服务B发消息,照常调用通信接口,但是消息可能会被 Sidecar 捕获到,然后通过Sidecar 进行转发。


三、服务网格

从整个系统来看,如果以 Sidecar 方式来部署服务治理以及服务的话,最终形成的系统如图。能看到通过 Sidecar 进行相互连接,形成一个网络,这也是服务网格名字的由来。每一个节点上面都相当于具体的网格,和多年之前提的网格计算有点类似。



服务网格如果站在更抽象的层次来看是什么样子?把服务治理相关的东西抽象来看的话,服务网格也算是一种基础设施,它和具体的业务无关。不管是 PaaS 的发展,还是服务网格的发展,都是将与业务无关的内容的共同点提取出来,然后形成独立的一套平台或者方案。另外,服务网格之间要形成可靠传递,刚才提到的重试等功能都应该具备。

服务网格是轻量级的网络代理,不能太重,不能喧兵夺主,服务才是整个系统中最重要的东西,而这些基础设施并不应该取代服务最重要的价值地位。

更关键的一点是要对应用程序透明。对于服务而言是看不到 Sidecar、看不到代理的,服务如果要发消息出去,它知道是发给这个代理的,那对于我们的业务来说同样也是一种污染。服务网格最终不再强调代理作为单独的组件,不再孤立的来看代理,而是从全局的角度来看待代理所形成的网络。


1
服务网格定义


服务网格的定义是 Willian Morgan 提出来的,他是最早做服务网格的人。如图,文字加粗的是服务网格一些关键技术点。右边图是最新发展的服务网格,在最上层还会加一个控制面板,通过控制面板来管理这些代理,这些代理是需要被管理的。如果我们的运维环境没有控制面板,可能就没办法运维了。


2
服务网格的基本构成


服务网格必须要具备数据面板和控制面板,如果新开发一个服务网格只有数据面板,它肯定不是一个完整的服务网格。

数据面板是用来接收系统中的每一个包或者请求,提供服务发现、健康检查等服务治理相关的,都是由数据面板来完成。数据面板的一些典型代表有 Linked、Envoy、和 Nginx 公司开发的 Nginmesh,以及硬件服务的代理厂商F5开发的 Aspen Mesh。目前主要的、成熟的是 Linked 和 Envoy,这两者都在生产环境上面真实部署过,实战过。而且Linked的采用会更广泛一些,因为它出现的时间最早。

对于控制面板来说,是为了在网格中运营的数据面板提供策略和配置,负责一些管理工作,它不会接收系统中的任何包或者请求。这里的包和请求应该是业务相关的包和请求,和具体的业务是完全没关系的。本来做微服务应该做去中心化的事情,但是又有一个控制点在那里,要强调的是那个控制点和具体的业务没什么关系。控制面板的典型代表,包括 Istio、Conduit、Nleson、SmartStack,目前最新的是 Istio 和 Conduit。


3
数据面板对比


左边是 Linked(Scala编写),右边是 Envoy(C++编写),它们最大的区别就是实现语言的区别。同时,Linkerd 和 Envoy 都是在生产环境已经验证过的两个系统,功能上都没问题,都比较强大,它们唯一的区别就是对于硬件资源的要求,Linked 是非常高的,它可能就会造成喧兵夺主的感觉,所以目前 Envoy 在这块是比较火的,Envoy 是由C++开发的。

4
控制面板对比


两个最新的控制面板,一个是 Istio,是由 Google、IBM、Lyft 开发的,而 Conduit 是由 Buoyant 公司开发的,跟刚才所说的性能不太好的数据面板Linkerd是同一家公司,Buoyant 在 Linkerd 之后又重新开发了 Conduit,专门来解决性能上的问题,所以在性能上面来看,Conduit 的性能指标已经出来了,就是微秒级,并且是P99延迟。但是 Istio 的性能指标现在还没出来,还在功能开发阶段。因为 Istio 需要实现的功能比较多,要支持各种各样的平台和过滤,Istio 整个架构非常灵活,所以 Istio 整个量级是比较重量的,但是 Conduit 只支持 K8S,Conduit 的原则是怎么快怎么来。

从编程语言上来说,控制面板 Istio 和 Conduit 都是使用Go语言,但是在数据面板上 Istio 是使用C++,Conduit 使用 Rust,可以看出来这两个语言都是那种比较高效的,在数据面板上面必须要使用高效的语言来完成。



四、Istio架构

一句话定义 Istio:一个用来连接、管理和保护微服务的开放平台。刚才也说了 Istio 是 Google 开发的,所以 Istio 今后的趋势肯定是会越来越火的,并且目前 K8S 已经把它集成到里面了,做成一个可选的组件。

对于连接而言,Istio 它主要包含弹性、服务发现、负载均衡,管理是流量控制、策略增强,监控也有,并且安全这块 Istio 也是有考虑,Istio 是端到端的身份验证和授权,等一下会详细的介绍。

Istio的关键特性:

1、智能路由和负载均衡。这里的智能路由和负载均衡是属于比较高级的,不是像传统简单的随机负载均衡,而是可以基于一些数据包内部的内容来进行负载均衡。

2、跨语言和平台的弹性。对于平台来说 Istio 是支持各种各样的平台,并且能支持A/B测试,金丝雀发布,并使用蓝绿部署运维上的一些高级功能。

3、全面策略执行。Istio 有一个组件是专门负责保障策略能够通过一个组件下发到具体的数据面板。

4、遥测和上报。即具体的测量以及流量的监控等。


这个就是 Istio 整个的系统架构,如图,上面是控制面板,下面是很多数据 Envoy,很多个代理,形成一个数据面板。后面我们会对单个进行详细介绍。


这是在 K8S 下面 Istio 部署的示意图,可以看到它们之间最关键的东西是所有服务和组件都会有一个代理,这代理是必备的,包括控制面板都会有代理。没有画的有两个东西,一个是 Ingress,一个是初始化器,初始化器主要是做代理注入。它们之间相互的交互都是通过加密,由TLS协议来完成。


五、Istio组件

1
数据面板Envoy


介绍一下 Istio 的核心组件,首先是 Istio 的数据面板 Envoy。

Envoy 的目标是透明地处理集群内服务间、从服务到外部服务之间的出入口流量。Envoy 是用C++编写的,高并行、非阻塞。并且是可装卸的L3/4过滤器,以及L7的过滤器,最终会形成一个过滤链来对流量进行管理或者控制,Envoy 是通过 xDS 动态配置来进行接口提供。

下面就是一些固有的功能,服务发现、健康检查。Envoy 的健康检查也做的颗粒度比较细,包含主动健康检查和被动健康检查。主动健康检查像常规的健康检查,主动地发一个健康检查的接口调用请求,查询一下。被动的是通过对其他服务的一些请求,从一些返回值进行健康检查。当然还包含高级的负载均衡,监控、跟踪这些功能。

Envoy最关键的三个点:

高性能。一直在强调的是数据面板必须要高性能,因为是要和业务服务部署在一起的。
可扩展。
可配置。具有动态配置的特性。


Envoy 是如何做到高性能的?


Envoy 的线程模型分为三类线程,如果做过C++开发,这种单进程多线程的架构是很常见的。Envoy 分为主线程、工作线程、文件刷新线程,其中主线程就是负责工作线程和文件刷新线程的管理和调度。而工作线程主要负责监听、过滤和转发,工作线程里面会包含一个监听器,如果收到一个请求之后会通过刚才所介绍的过滤链来进行数据过滤。前面两个都是非阻塞的,唯一一个阻塞的是这种 IO 操作的,会不断地把内存里面一些缓存进行落盘。



服务网格所强调的另外一个功能,是动态配置不用重启,实际上是重启的,它会启动一个新的进程,然后在这进程之上进行新的策略,还有一些初始化,这时候再请求监听,之前那个进程的 socket 副本。当老的关闭链接以及退出之后,它才会接收新的,这时候就实现了对用户没有感知的重启。

这就是它的 xDS,如图,可以看到它的密度是非常细的,


终端发现服务(EDS),实际上就是服务的发现服务;
集群发现服务(CDS)是为了发现集群;
路由发现服务(RDS)是为了对路由进行一些处理;
监听器(LDS)来动态地添加、更新、删除监听器,包括过滤链的一些管理、维护。
另外还有刚才说到的健康检查(HDS),
还有聚合(ADS)是对于监控指标进行聚合的接口;
另外一个密钥发现(KDS)是和安全相关的。

首先,如果来了一个请求,会到刚才所说的工作线程里面去,工作线程会有监听器,收到之后进行一些处理,然后要往外发,这时会调用路由的发现功能,然后再找到相应的集群,再通过这个集群找到相应的服务,一层一层的往下面调用。


2
控制面板Pilot

接下来介绍的是控制面板的三大组件,第一个就是 Pilot。


Pilot 是运行时的代理配置,刚才所说的 xDS,就是用 Pilot 来进行调用,负责把相应的一些策略,失败恢复的特性派发下去。Pilot 是负责管理所有的这些代理,代理和管理就通过 Pilot 来完成,是平台无关的一个拓扑模型。目前主要支持的是 K8S。


Pilot 是一层抽象的独立于底层平台的模型,因为这里有个代理,对于多平台或多样性的管理架构,即适配器的架构。平台特定的适配器负责适当填充这些规范,要通过具体平台的适配器形成一些规范,和通用的模型结合,生成必须要往 Envoy 下发的数据,并且配置、推送都是由 Pilot 来完成的。


Pilot 的整个服务发现和负载均衡,如图,Pilot 是Kubernetes DNS提供的域名进行访问,首先调用 Service B 的url,这时候 Envoy 会进行截获并处理,处理完之后会找到相应的负载均衡的池子挑选一个进行流量下发。Pilot 目前支持的这种负载均衡的方法,规划了很多种。但目前只实现了三种,前两种还是随机和轮循,多了一个最小请求的负载均衡算法。它能找到这些 Pilot 里面哪个被调用的最少,然后进行调用。

Pilot 的一些规则配置,可以看到基本是负责规则的管理以及下发。

路由规则。
目的地策略。主要包含负载均衡的算法,以及对于负载均衡算法抽象的策略预演。
出站规则。

把这些规则分了三类,好处是对这三类都会生成一些模板。


流量的拆分可以看到是基于标签的流量拆分,这里配置的如版本,环境,环境类型,它根据这个规则来进行流量的派发。比如说99%都发给之前版本,新版本先1%先测一下,类似于A/B测试。



另外一个比较高级的是基于内容,因为它是L7的这种过滤,可以基于内容来过滤,并且支持表达式,这种将iPhone的流量全部导到新的服务里面去,并且有标签,版本必须得是金丝雀版本。


3
混合器Mixer


Mixer 是在应用代码和基础架构之间提供一个中间层,来隔离 Enovy 和后台基础设施,这里的后台是指 Promethus,ELK 这些。

Mixer 有三个核心特性:

先决条件检查。负责白名单以及 ACL检测;
配额管理。负责这种使用频率上的控制;
遥测报告。

总共分为两类,在生成配置模板的时候它是有两类的,第一类就是负责检查check,第二类就是负责报告reporter。



Mixer 是采用通用的插件模型以实现高扩展性,插件被称为适配器。运维人员下发一些配置到这里面,这些模板又是由模板开发人员进行开发的,Istio提供了很多通用性的模板,上面简单地改造一下就能做出一个模板来。适配器也有很多种,各种后台、平台的都有。

Mixer 是抽象了不同后端的策略,遥测系统的细节,它就对这两个东西进行了抽象,形成了一套抽象的东西。



刚才介绍过适配器,再来介绍一下处理器,它是配置好的适配器,由运维人员进行配置,之后形成最终的处理器,负责真正往后台发东西。

它封装了与后端接口所需的逻辑,指定了配置规格,以及适配器。如果要在后台进行消息交互的话,所需要的操作参数在这里也会定义。而右边就是两个模板,第一个模板是 Prometheus,它是一个处理器,下面是它的一些指标。另外一个是白名单检查的模板,提供URL,以及它请求的接口返回值。



刚才介绍了整个通路是怎么打通的,包括适配器和处理器都是为了干这个事情,这个通路怎么建立?接下来要介绍的是这个参数怎么生成,它是请求属性到一个模板的映射结果。

Mixer 会收到 Envoy 发过来的很多属性(请求),请求里面包含的数据都称之为属性。通过它的模板来生成相应的具体参数,这边也是刚才两个例子里面对应的模板。上面是度量指标采集用的,下面是白名单。



这里有个遥测报告的示例,当收到一个请求之后会发生什么。它会以属性的形式,这边有个 Zipk,就直接上报了,这是因为 Envoy 原生的就支持Zipk。Envoy 支持后端监控的东西,就是 Zipk,所以它可以直接发给它。其他的需要通过 Mixer 来进行转发。




首先它收到这个属性之后,会把这个属性生成具体的实例。根据运维人员提供的配置,Mixer 将生成的数据分发到一组适配器,适配器要根据运维人员的配置来生成具体的数据,之后就可以把刚才所生成的实例往下发了。发到后端后可以进行进一步的分析和处理。

4
密钥管理


最后要介绍的就是安全相关的,Certificate Authority 这块,这是整个密钥管理的示意图,可以看到服务和 Envoy 是通过 TCP 进行交互的,但是Envoy 和 Envoy 之间是通过 MTIS 进行加密,是双向的 TIS 加密。它的好处是,会在内部的每一个服务节点之间做加密,当然这是可选的,根据性能的需求来进行选择。

密钥管理分为四个步骤,这四步就是四个特性,第一,通过服务帐户生成的密钥和证书,然后再将密钥和证书部署到 Envoy上,它还支持周期性的对这证书进行更新,另外还支持撤销的功能。


这是它的两种部署方式,一种 K8S 的部署方式,另外如果是虚拟机,它会单独有一个节点代理,通过节点代理来发出签名请求给CA,CA再生成密钥和证书给代理,代理再来负责部署到 Envoy上。



具体的运行时它们都有各自的证书,开始进行双向的 TIS,这时候会到名字信息里面去查询,后端有没有权限访问,如果有的话就往下,没有就结束了。



第三步,如果收到一个客户端的请求,会去 Mixer 里面判断一下,它是白名单上的一个判断或者是不是黑名单上的一个判断,会影响“握手”的成功与否。最终它们就形成了安全交互的通道。



谢谢大家,今天我们主要给大家介绍一下 Istio 是什么,大家有初步的认识,并且对它里面比较关键的技术进行了介绍。


六、Q&A

Q1:现在有这么个项目,您怎么看像这种项目的发展?第二个问题,你们中心现在在做,您也分析的挺深入,未来是什么计划,会和paas有融合吗?

A1:先回答第一个问题,我们可以看到不管是数据面板还是控制面板都会有很多个,但是控制面板,谷歌和IBM,刚才所说的是由三个公司来开发的,谷歌、IBM,还有Lyft,那个公司类似于滴滴那种业务的公司,它们负责Envoy的开发,数据面板是它们公司来负责。我们可以看出来它们是有点分离的感觉,对于谷歌或者IBM来说它们更关注的是控制面板,并且在控制面板和数据面板之间的接口设计的非常好,设计了一套通用的接口。它们最终是分为两个方向发展,但是都可以通过同一套标准集成起来。

第二个问题,首先公司内部都在采用微服务,对于Istio至少要到1.0之后才会在内部环境使用,如果没问题才会逐渐往真正的对外业务使用它,包含通讯里面都可能会用它。但是对于CT领域来说的话,用这个可能代价就需要好好地评估一下了。因为性能上的问题,它毕竟还是多了一跳。如果两个服务之间的交互就相当于多了两跳,对于通信这种实时性要求非常高的领域可能会存在问题。我们也会开发自己的一套侵入式框架,可以参考Envoy的实现。


Q2:我们现在游戏项目里面刚好也用到它。但是它有个问题,用的感觉有点大材小用,我们用它做调用链关系分析,因为我们集群开发很多游戏,每个游戏有个pilot,但是如果出了问题我不知道,那它里面的一个插片自动生成,它只能识别K8集群里面pod。如果我们想用它把K8S的集群和非K8S的集群调用,并且全部进行连接起来的话,它是否支持?
A2:我觉得它现在由于所处在初级阶段所以暂时不支持是正常的,但它后续的发展肯定会支持,因为它们整个设计的目标就是为了达到这种服务粒度,而不仅限于K8S pod这种管理粒度。


Q3:我有一个关于sidecar的问题,如果作为一个客户端去请求的时候应该要引流引到sidecar上面,它引流是怎么引的?如果直接转过去的话又怎么去识别目标的服务到底是什么样的?它调用的是什么服务,后端可以路由到几个上?

A3:这个信息都是由刚才所说的pilot来负责收集,它会把这些信息下发到Envoy上,所以它在做路由算法的时候会访问,来获取它可以访问到哪些服务,它会把服务的信息找到,包括它能访问的服务池包含哪些内容,然后再通过策略进行控制。

它是会反向再去K8S里面找到的,并不是完全Envoy自己来负责,这些信息都是由pilot来给它,拿到这些信息再做处理,最终还是会和平台结合到一起。它有一个假设,所有的平台都会实现这种服务发现的接口,并且会从服务发现的接口拿到一些必要的信息,包含你刚才说的,会转成相应的IP。


关注数人云公众号,后台回复“127”即可获取本次演讲PPT。

PPT下载 | 亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?

Dataman数人科技 发表了文章 • 0 个评论 • 1167 次浏览 • 2018-02-02 14:39 • 来自相关话题

2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。 ...查看全部
2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。

数人云Meetup每月一期,欢迎大家来面基、学习。本文为vivo云计算架构师袁乐林分享的“vivo云服务容器化实践”现场演讲实录。


今天讲的内容主要是介绍技术背景,产品的技术架构,我们关键技术的实践,前车之鉴,以及对下一代云服务架构的设想。


技术背景

vivo这些年的业务增长非常快,用户数已经上亿,服务器到了万级,业务域好几百,后端系统的复杂度在迅速攀升,不光是运维方面、架构体系复杂度也非常高,vivo技术架构也是到了破茧化蝶的时候。

我们做过容器、虚拟机与物理机性能对比测试。上面这张图是当时做的性能测试架构图。得出了一些测试结论:
1.容器化app(4c8g)在性能上略优于非容器化app测试指标
2.容器化app(32c64g)性能相较于裸跑同物理机有近4%左右性能损耗,其中TPS有3.85%损耗,平均响应时间3.95%(1毫秒)的增加,对业务请求无影响。
3.容器化app在12h的稳定性测试中表现正常
4.容器化app在cpu相对配额,cpu绑定以及绝对配额场景下,业务性能CPU相对配额 > CPU绑定 > 绝对配额。
5.容器化app在组部件异常,单计算节点,控制异常场景下,容器运行正常。
综上所述,容器化app性能上接近物理机,在多测试场景下,表现相对稳定可靠。同时,对计算密集型app,相对权重配额能实现CPU资源利用率最大化。


vivo容器化云服务框架

正是因为这个性能测试数据的支撑,就有了vivo容器化云服务框架,我们给它取名 Kiver,提供轻量级、高可靠的容器化生产方案。


在这个框架之上vivo一共有八个云服务,按照后来统计数据来看,MySQL加上其他两个服务占到80%的比例,这也非常符合“二八”原则。


vivo整个云服务容器化产品的架构,左边是运维自动化的工具集,比如日志、监控等,日志在业界应用非常广泛,我们用采集容器的数据、容器的监控指标。

这里有两个日志,上面是中间件的业务日志平台,所有业务基于中间件日志规范,输出日志后都会送到这里面收集起来,但是这个业务日志平台功能目前比较薄弱,对新增加的一些组件,比如ECTD等不支持。vivo又引入了现在容器领域比较常见的日志方案EFK,今后会规划把两个日志整合到一起。

vivo在运维方面做了一些工具,如 vivo MachineCtl和 KiverCtl,两个工具主要实现宿主机的自动化,简单来说可以把宿主机操作系统自动化地装起来,装完之后变成Kiver的计算节点或者控制节点。还有KiverPerfermance,是我们内嵌的一个小的性能测试插件。

再来看右边,是vivo的基础设施,物理机和交换机,网络设备和防火墙等,上面是Docker,Docker容器虚拟化技术把物理机上面的相关资源虚拟化用起来。

右边有 Ceph 块存储,实现数据备份,上面是vivo自研的DevOps平台,做了调度框架,右边是用harbor做的镜像仓库,再往上就是云服务Portal,前面所说的那些云服务,同时也可以跑长生命周期应用。
宿主机自动化实践


下面我们讲一下vivo的实践。现在物理机一旦上了规模之后,装操作系统就成为一件大事,我们提供了 vivoMachineCtl,这个工具是一个命令行给运维人员使用,可以实现宿主机集中化的参数配置和自动化。

利用 vivoMachineCtl,首先和物理机管理卡做一个交互,交互之后拿到物理机的MAC地址,这里有个BMC,也有厂商叫iDrac卡,它可以取得这台服务器网卡的MAC地址,创建以MAC地址命名的Bootfile,指明现在需要装什么操作系统,和其他一些参数。再进一步给它一个ipmi消息对服务器复位,然后服务器开始重启。

重启之后,服务器第一次会发dhcp请求,拿到IP地址,之后会走一个pxe的协议,拿到bootfile,下载Bootfile所指明的小系统和内存文件系统文件下来,加载到物理机中,然后开始进行操作系统安装。这就是操作系统安装的过程。操作系统安装完成之后,把安装类和文件系统切换成正在启动的文件系统,在post阶段到集中化的配置中心,把相关的配置拉下来,包括IP地址,主机名和网关等信息,这是宿主机的自动化部署。


KiverCtl实际上就是把操作系统的宿主机变成计算节点或者控制节点。计算节点有如下几个功能:第一,基本的包安装,第二,Docker、Netplugin初始化,启动kiver-guard/flume/cadvisor容器,完成日志和监控指标的采集。

控制节点上面有Etcd和Netmaster,也会可选地把Prometheus/alertmanager/grafana/启动起来。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的转变。


业务日志集成到日志平台实践

这是vivo日志采集的实践,在宿主机上做日志分区,容器运行起来之后挂这个目录,每个容器起来之后会创建一个自己的文件目录。外面有kiver-guard,用来侦听内核文件系统的新日志文件创建的通知。

根据通知会创建软件链接,链接到上一级Flume监控的日志目录,由Flume推到kafka。大数据平台会来消费这里的数据,业务日志平台也会消费这个数据,然后持久化到ES里,最后由中间件日志平台来实现对日志的检索和展示。


为什么要这么做?当时用的flume版本不支持自动收集递归子目录下日志新增内容的收集,完整的文件可以收集进去,但是日志文件在递归子目录下有不停地追加是输不进去的。

kiver-guard本身也是一个容器,它起来之后把宿主机日志目录挂上去,在容器里面侦听日志目录下的create事件。

不管这些日志路径有多深或者在哪里,都可以链接出来。做链接的时候有一点需要注意,要确保链接过来之后文件名称是唯一的。有些容器被删除了,或者日志被轮转删除了,同样也会针对Delete事件,侦测到delete是件之后删除上层flume监控日志路径的对应链接。


基础组件日志收集实践

基础组件日志采用Etcd、Ceph、CentOS、Netmaster等一些网上比较热门的EFK组件,开箱即用。
监控与告警实践


这是监控和告警实践,在容器领域比较常见,vivo采用的是Promethus和Alertmanager。Promethus采用双节点,双拉(拉两遍),两个Promethus之间没有做主从,为了解决高可用问题,挂了一个另外一个还在。

之后接短信邮件中心,后面接Grafana作为监控面板,前面用了telegraf。我们做的东西不仅仅有容器,还有其他的组件像Ceph。我们用Cadvisor收集容器监控指标。

我们对集群健康做监控,也对集群资源使用情况进行监控,集群的健康性采用telegraf可以调用外部shell脚本的特性。我们在控制节点写了脚本,用来检查Etcd的健康情况,也和各个节点进行通讯,检查各个节点是不是健康。之后会返回数值,给出集群健康状态码。


这个就是前面讲的自定义的一些监控指标,这是集群的健康检查,这是集群的资源利用率,大致两条数据链进来。一个脚本由telegraf去拉,推到Prometheus里面,最后展现在Grafana上面。另一个,由DevOps框架把数据写到Mysql里面,再由Grafana定义Mysql的软件源。

这边拉出来的自定义的健康指标支持返回码,这个返回码需要翻译成文字,实际上Grafana已经具备这个特性,我们可以去做一个映射,比如1代表监控,2代表网络问题等等,它可以自动翻译来。
数据持久化实践


说到云服务大家都会关注这个问题,数据怎么做到持久化,做到不丢。容器启动的时候会挂在宿主机上面的一个数据目录,和日志类似,有容器的启动进程,直接写脚本也可以,创造二级目录。

用主机名,是在容器默认的主机名,就是它的默认ID号。如果这个ID已经存在就不用创建,说明容器是起用一个旧的容器,最后建立软链接到数据目录。这样确保每个容器日志数据都持久化到宿主机,还可以确保容器重启后数据不丢。

第二,数据本身有一个单独的备份系统,它会每天晚上凌晨2点跑一遍,把Mysql数据推到Ceph块存储当中,实现数据的可靠性。
集群可靠性实践


这是容器集群可靠性实践,最典型的是三个副本,副本能够实现数据和服务的可靠性。


失效重试,在集群各节点提供一个crontab定时任务,每隔一段时间探测一次docker服务进程健康状况,若不健康,则拉起Docker服务进程。同时我们开启了docker的Restartalways选项,确保容器服务异常退出后,能被重新拉起来。


关于隔离,首先是分区隔离,宿主机业务日志目录/app/log独立分区,避免日志量过大时侵占宿主机系统分区或者业务分区磁盘。


第二,资源隔离,flume当时是跑进程的,我们做的第一件事情是进行容器化,之后做配额,限制能使用的资源使用量,避免大日志传输时侵占宿主机过多资源。

第三,故障隔离,开启dockerlive-restore选项,保障docker服务进程不影响容器服务。
前车之辙


我们犯过一些错误,不负责物理机运营的童鞋可能感受不明显。如果磁盘引导分区被破坏,就可能导致操作系统被重装,这个问题是很严重的。原因也很简单,服务器一般有多引导的选项,比如磁盘、网络、CD,一般在顺序上磁盘第一,网络第二。

但如果磁盘引导分区坏了,服务器会认为没有操作系统,然后就从第二个上引导。这时候不幸的事情是,在你的网络环境里如果之前刚好装过操作系统,采用了第三方开源的部署服务器,而没有把之前的文件删掉,那么它就会把那些操作重新装上。

解决办法很简单,我们提供了定时任务,对两个小时前创建的引导文件,能看见它的创建时间、访问时间,并进行强制性删除。


第二个前车之辙,在收集Ceph日志时碰到困难,当时是用fluent-plugin-ceph插件来做。具体的情况是,第一,官方配置文档不正确,因为提交者没按官方文档格式编码,导致看到的配置是一行,拿回来根本不知道怎么办。第二,它和td-agent1.0 版本不兼容。摸索出的解决方法就是图片上显示的办法。


下一代云服务架构

这是我们下一代云服务架构,与上一代的主要区别在于,把编排框架换成了Kubernetes。目前AI这块已经用起来了,AI部分在线上大概有一百台物理机,跑Job任务,短任务每天可以跑到三万个,一次性可以调动3000个容器,未来会把这个些换成Kubnernetes,包括我们的AI、云服务都会跑在Kubernetes上。
XaaS on Kubernetes

如果把云服务跑到Kubernetes上,第一个要做的事情,可能会采用ceph块存储做后面的数据和数据持久化。目前vivo已经有了数据ceph块存储,但功能还不强大。第二,要解决pod漂移调度问题,如果不用ceph块存储,pod失效调度到其他节点上有问题,调过去没用的,没有数据。
第三,也是最常见的一个,固定POD IP,看到网上有人讨论这个事情,觉得容器坏了,没必要把容器固定起来,因为有违微服务的原则。这种观点不太对,有一些场景,比如在vivo的企业IT架构里面,很多东西都跟IP挂钩,比如安全策略,它不是跟域名挂钩,而是PODIP挂钩,交换机、防火墙等很多的配置都跟这个相关。所以vivo要干的很重要的事情,就是把POD IP固定。
目前业界对这块也有一些实践,比如京东最近有这方面的分享,把PODIP放在一个APP的IP 小池子里面,小池子里面还有IP的话,就从小池子里拿,没有的话就从大池子里去申请。

在微信公众号后台回复“127”,即可获取本次演讲PPT《vivo云服务容器化实践》。
点击数人云阅读更多技术干货

这款分布式配置中心,会是微服务的降维打击利器吗?

Dataman数人科技 发表了文章 • 0 个评论 • 1409 次浏览 • 2018-01-25 15:39 • 来自相关话题

本文来自1月18日数人云资深工程师在IT大咖说平台的线上直播分享。 今天主要探讨这几方面: 一、配置中心的定位 二、云化的微服务对于配置中心的要求 三、微服务配置 ...查看全部
本文来自1月18日数人云资深工程师在IT大咖说平台的线上直播分享。

今天主要探讨这几方面:
一、配置中心的定位

二、云化的微服务对于配置中心的要求

三、微服务配置原则

四、数人云分布式配置中心整体架构


应DevOps和微服务而生的配置中心

首先想跟大家分享一下,为什么会有配置中心的存在?在我早期从事软件开发时,是没有配置中心,也没有微服务的。

以前每次系统发布,无论是大改动,还是很小很小的改动,都必须经历发布的过程。这个改动有时候小到,只是修改了某个配置文件的某个字段,也必须要重新打包,重新部署。

而且,在企业里开发和运维的人员,往往不是同一个群组。部署时,开发人员需要为运维人员准备部署文档。这个过程中,经常会由于沟通协调不到位,无法第一时间预测到所有问题,导致在正式上线时,被用户第一时间察觉到上线出了问题,或者部署不正确等,导致一些非常严重的后果。

随着时间的推移,软件工程界出现了新的名词--DevOps。开发和运维人员共同协作进行产品的部署上线。在DevOps时代,如何将概念通过一些IT的手段转化为直接的生产力。因为每次发布改动越大,发布的频率越高,系统的风险就越大。

所以业界急需一种技术手段,来协助开发、部署和运维三方面的人员,在不断的迭代过程中,减少这种风险。配置能不能是一种动态的配置?而不再需要去做一些静态配置。基于这种业界的风险,就有了去做配置中心的冲动。于是,市面上出现了分布式的配置中心。

无论是分布式的配置中心,还是普通配置中心,它到底在配置什么东西?如果把时间往前推一段,通过SSH登陆服务器修改配置的那个时代,配置中心的作用其实不大。

到了2010年之后,业界出现了微服务,分布式的配置中心才正式地光明正大的走向舞台。为什么呢?因为要结合分布式配置中心+微服务,才能真正实现我们所理解的DevOps。


微服务配置原则

Heroku创始人AdamWiggins发布了一个“十二要素应用宣言(TheTwelve-Factor App)”,为构建使用标准化流程自动配置,服务界限清晰,可移植性高,基于云计算平台,可扩展的服务配置提供了方法论:

1.配置是可分离的,可从微服务中抽离出来,任何的配置修改不需要动一行代码。

2.配置应该是中央的 通过统一的中央配置平台去配置管理不同的微服务

3.配置中心必须必须可靠切稳定地提供配置服务。

4.配置是可追溯的,任何的配置历史都是可追溯,被管理且可用。

在云服务时代,对微服务做配置,对它有什么样的要求呢? 首先必须基于镜像管理部署,有自己相应独立的配置,而且程序包不可以因为环境的改变而更改。也就是说,它是独立于环境的不可变的程序包。

其次所有的微服务通过环境变量或者配置存储时,在启动的那一刻,就可以做配置,也可以通过动态的修改实时生效。 微服务启动时配置 一个微服务从打包、上线、部署,打包以后,会在启动阶段从配置Configuration Repository 里面拉取它的配置,通过注册与发现,注册在注册中心里,在启动时,把服务中心的配置拉取到本地,成为应用的一部分。

并且在服务运行过程中,实时动态监听配置的变更,达到有新的配置时马上下发到微服务,使配置有实时生效的效果。

配置中心的定位

有了以上这种业务需求,到底要做一个怎样的配置中心?数人云认为,这个配置中心必须有一致性的K-V存储中心,K-V存储就是说,一个K对应一个V,而且这种存储必须持久化、可追溯。 它必须是可以集中统一配置,实时推送,以及马上生效。

所有配置都必须实现灰度更新与回滚。所谓灰度发布,是说一个微服务集群里面,比如有个订单系统,做了一些配置上的更新。想在小范围探讨一下,实验一下这个配置对业务有怎样的影响,这时就用到灰度更新这个概念。

灰度更新是说,通过Data center或静态IP,指定某个配置只对某几个IP,或者Datacenter里面的某个服务生效,其他的不在这个范围内的服务,不会受到影响。观察效果,如果OK,就把这个整体配置全面推送到所有的微服务。如果效果不满意,就把配置回滚到原来的状态。

全量更新,灰度更新,或者回滚,必须是可在任何时候查看,在某一个任意的时刻,回滚到某一个历史点的配置。 最后一个是要有多集群的启动,所谓多集群的启动就是,我们把配置存储的时候,必须存储在一个多集群的环境里面,以达到物理隔离的目的。

另外还有一些原则,业务无关性、 Open API、配置生效监控。就是说配置中心必须提供API给第三方的系统来使用。配置的生效监控是,必须实时知道,有哪些服务拉取了配置,是否已经生效,或者这个配置的效果如何? 配置中心的支撑体系 第一种运维管理体系类似于偏静态类的配置,在启动时通过配置文件直接拉取读业务。

另外一种是开发管理体系,偏动态管理,代表的是一种程序或者在运行过程中,通过实时的变更配置内容而实时生效,达到的一种效果。

一个健全的配置中心应该支持这两种运维体系。 配置中心的微服务兼容 配置中心必须对现有主流的一些开发框架有API方面的兼容。数人云在做配置中心时,很难预估第三方来调用服务时,到底搭配在什么样的开发框架上?通常来说,配置中心不可能兼容市面上所有的东西,数人云选择重要的框架来做深度兼容。

首先,对Spring Cloud,阿里的Dubbo这些常规的第三方云服务框架做了API方面的兼容。目前来说,至少要支持SpringCloud、Dubbo、Nginx、Tomcat、Logback等各方面的配置。 这种配置各有各的特性,所以我们就挑选了一些有经典案例的,通用性的东西来做配置的集成,比如原生支持SpringBoot、Spring Cloud,集成支持k8s,就是k8s容器。

数人云hawk分布式统一配置中心

数人云分布式统一配置中心,取名Hawk。Hawk基于ETCD打造,主要解决把开发人员从复杂的业务流程和烦琐的配置中解脱出来,让开发人员只关注自己的业务代码,把运维、配置这些剥离出去。同时降低服务部署、发布过程中的风险。 基于微服务体系理念打造的分布式统一配置中心Hawk支持多种类型配置:如Spring Cloud、 Dubbo、Kubernetes Configmap、Logback、Linux Environment,具有完善的配置管理流程、配置实施推送、支持多集群多环境、多版本控制,更提供配置细粒度的管理如灰度管理、任意版本重置等丰富功能。 整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及业务对平台的耦合。相应的管理流程也规范了配置的使用,降低配置带来的发布错误等。

功能特性

对比主流框架,数人云HAWK有如下一些重要的功能特性: 支持配置实时推送以及实时生效,在程序的运行过程中,不能说把服务停下来才能更新,必须实时配置,实时生效。 支持多版本管理,配置不管哪个版本,都可以随时查看、查阅以及激活历史的版本,并做发布。 支持多集群环境,多环境配置。通过数据库或者后端存储,以达到支持SIT、UAT环境的体系。

优美的监控台,提供多维度Dashboard以及监控视图,支持配置灰度和回滚。 支持数据全局备份和回复,进一步提升配置数据的容灾能力。 提供OpenAPI,支持多系统集成的便利手段,支持配置应急预案处理。 配置流程管理,完善的配置流程管理,确保配置下发前必须获得确认和授权。 认证与授权,提供LDAP集成,以及多角色权限管理。 支持操作审计,确保配置操作有据可查。 支持多种配置文件,Spring Cloud Config、Dubbo、Logback、Nginx、LinuxEnvironment、Tomcat。

支持Spring Cloud服务治理配置和管控,支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。 无缝集成Kubernetes的Configmap以及Secrets,并提供增强的企业管理流程。 Hawk整体架构 首先接入第一层是网关,整体的存储通过Hawk Server,下发到ETCD集群,ETCD集群再同步到K8S容器运行的平台。 刚才有同学说Hawk跟阿波罗有相似的地方。在研究对比时,我们觉得阿波罗出于业务需求,有一些比较复杂的地方,决定把流程简化。

先从数据迁移的状态简化成简单的几部分。比如新建一个配置,要么配置就被删除了,直接一步到位。如果没有这样做,就面临几种情况,这个配置是否要小范围的去做一些试探性的发布,这种情况可以走灰度发布,状态变成灰度中,配置不允许更改。要么就是两条路走,全量发布到所有服务上。要么就是放弃灰度回到之前的状态,放弃灰度后会去到已修改的状态。

另外一种情况,新建一个配置,直接全量发布,状态变成已发布状态,这时候是可更改的。但是每一次的更改,还是会回到原来那个状态。这个更改要做灰度吗?还是做发布?还是对发布有点后悔,不打算更改了?这时,从历史版本里面找一个合适的版本,激活,然后再做一次发布,通过几个简单的回路,涵盖了大部分的业务场景。 配置数据状态变迁 Hawk Portal是主体的配置界面,用户在界面上对配置进行输入、增删、改查的管理。这些资料会有两份,一份做通过Mysql做本地存储,另一份通过Hawk Server直接同步到ETCD。

由于HAWK Server是同步到ETCD里面,也就是说ETCD相当于另外一个数据库,这当中不存在数据之间的互相抄送,从而减低丢失数据的风险。持久化,是说研发和运维在后台做数据迁移,或者数据监控时更有把握,更方便。 数人云HAWK其实有两个ETCD,一个ETCD是做注册发现的,Hawk Server、Hawk Portal都会注册在里面,作为相关的组件。类比Spring Cloud Eureka,Eureka是注册在Eureka Server里面的一个内存列表,集群里面所有Server共享这个内存信息。这个过程数人云做了简化,所有信息全部注册在ETCD里面。

ECTD集群由于是共享的,组件的状态和一致性得到保障。Portal和Server之间不再通过Portal注册在Server并通过心跳来维持关系而是通过共享持久化的ETCD,保证数据在任意时刻所看到的状态都是一致的,从而保证了服务的注册,以及服务发现的稳定性。

Hawk和Eureka 选择的路径不一样。Eureka是比较重量级的,HAWK则简化了这个配置,简化这种代码的复杂性,重点提高系统的完整性,打造系统闭环,通过一些相对简单的方法,提高服务的稳定性。 配置一旦通过Hawk Portal潜入本地数据库,微服务的注册服务是怎么实现配置呢?当Portal写入配置到本地数据库时,同时也会通过服务Sever去同步到ETCD,ETCD里面存储的信息,是一个持久化的数据。

通过Server实时从ETCD拉取配置,有时是运行的时候拉取,有时是启动时拉取。启动时拉取有两种策略,启动的时候拉取配置,存储到本地作为静态文件的配置,运行时候拉取,动态的变更实时生效。

在Web层其实也有一些问题需要解决,比如,因为我们不是一个开发框架,是奔着一个开源系统的方向去,所以要解决服务跟浏览器之间的授权。 数人云现在的做法是在本土数据库存储一些用户的信息,但是并没有采用传统意义上的建Session来做验证和授权,而是通过动态下发JWT的形式,每一个请求动态下发,根据我个人用户的一些信息生成,每次的请求一来一去都有交换新的Token,每个Token实时生效并有续约的功能,来代替传统意义上的Session。 配置中心集成第三方框架与类库 Hawk有一个第三方类库集成,操作流程是这样的:操作者通过UI调用HAWK后端的portal,通过Hawk Server把配置写入ETCD。另外一些运营者和开发人员所持有的第三方服务,通过集成Hawk Client来读取配置。 Hawk也有新的迭代,跟Sharding-JDBC做了集成,JDBC 2.0的一些趋势跟HAWK系统做了深度集成。服务通过实时读取配置中心配置实现动态更改分库分表的策略。

Q&A Q1:实时更改分布分表策略?
A1:可以,Sharding JDBC 2.0就是重点实现这个功能,这也是Hawk与Sharding JDBC深度合作的成果

Q2:历史数据怎么办?
A2:历史的数据其实都是持久化存储的。如果有一天要回到某个历史版本,可以随时通过调取已发布的历史。Hawk有一个版面叫发布历史。这里,每一个配置都有配置历史可追寻,可以随时查看或激活某个版本。激活的时候,需要用户去选择要做一个全链发布还灰度发布,还是说什么都不做。

Q3:是否支持ServiceMesh?
A3:目前来说ServiceMesh还是一个比较新的东西。如果ServiceMesh是独立配置的话,其实可以支持到。但是ServiceMesh有非常多的特性,还不敢说100%可以支持得到。其实数人云也在做ServiceMesh相关的项目,就是说它以后还是有非常大的可能,还是要集成ServiceMesh配置中心里面做一个闭环。目前这个版本支持一些比较轻量的配置。 ServiceMesh中文网微信公众号(ID:servicemesh),大量Istio、Conduit官方文档翻译版和技术干货文章,欢迎关注。

Q4:开发环境和生产环境用哪一步骤?
A4:SIT和UI其实可以部署在一起,通过存储隔离来做到。但是,不建议生产也部署在一起,生产还是建议独立部署。生产还是物理隔离是最好的方案。

Q5:配置中心和服务中心是不是两个系统?
A5:目前来说是两个系统,但是现在的想法是暂时的。现在的想法是是不是把配置中心再扩大一点,不叫配置中心了,而是叫比如微服务服务平台。服务平台里把配置中心跟注册中心都作为一个组件融入进去,把一些跟业务无关的东西抽离出来,搭载一些公共的平台上,以组件的形式去融入到这个平台里面去。

Q6:开源有本地缓存吗?
A6:目前来说没有本地缓存,是直接获取ETCD的东西,所以它是实时的,但是注册中心里面会加入缓存。

Q7:一般哪些信息通过配置中心配置?
A7:非业务的东西,比如平时开发一个系统,或者开发一个第三方系统,我们都有所有的配置文件,比如数据库的连接,跟治理相关的东西,或者一些国外的引用,都可以通过配置中心来配置,并且这种配置不仅仅是在页面上的配置,有一个插件给它,启动之后直接把这些配置导入到配置中心里面去,还可以通过启动的时候把这种配置下发到本地,形成一个本地的静态配置。

Q8:server如果断开怎么处理?
A8:因为Server是多Server集群的,如果断开了并不是说通过指定IP地址去访问这个Server,而是通过注册与发现去访问这个Server,如果Server断开了,其实也就是说他们之间没有心跳了,他们就会尝试去ETCD里面请求一个新的连接,而这个连接也会通过注册与发现,会发现其他的Server,这样的话他们就会连接。

docker + kubernetes=共生?相爱相杀?

Dataman数人科技 发表了文章 • 0 个评论 • 5211 次浏览 • 2018-01-23 10:38 • 来自相关话题

2017年的云计算市场,有一个领域获得了空前的关注 -- Kubernetes。 Kubernetes可以追溯到2014年,当时Google公开发布了该项目的开源代码。2017年,Kubernetes广受欢迎,几乎所有的主要IT供应商都支持这个平台。 ...查看全部
2017年的云计算市场,有一个领域获得了空前的关注 -- Kubernetes。 Kubernetes可以追溯到2014年,当时Google公开发布了该项目的开源代码。2017年,Kubernetes广受欢迎,几乎所有的主要IT供应商都支持这个平台。

小数今天推送的这篇文章,为您揭示Kubernetes与Docker容器之间是怎样的关系?对企业客户又意味着什么?



Kubernetes是一个开源项目,提供容器编排,部署和管理功能。自 2015 年 7月以来,它一直是由Linux基金会下的云原生计算基金会(CNCF)运营。尽管Kubernetes不再只是Google的一个项目,Google仍然贡献了远大于比其他任何机构的代码量。

将AIX应用程序迁移到云的最佳实践
Kubernetes 2017年如此耀眼,2018年Kubernetes将继续成为一支重要的力量。要理解这点,首先要认识到这项技术和云计算的完美契合之处。

在过去三,四年中,越来越多的企业选择使用Docker容器来部署云工作负载。Docker容器提供的既是运行容器化应用程序的运行时,也是封装和交付容器应用的格式。容器提供了直接在虚拟机管理程序内部改善可移植性和效率的承诺。

随着容器使用量的增长,需要对容器集群进行编排,调度和控制。这就是Kubernetes适合的地方。Kubernetes提供了大规模运行容器的编排系统和管理平台。还提供了一系列API抽象,使其他技术可以插入,使平台具有很强的可扩展性,并且能够支持各种不同的供应商部署用例。

比其核心编排能力更重要的是,Kubernetes在2017年成为实现多云世界的事实平台。虽然AWS在2017年继续主导公有云,但企业仍然希望能够在多个云上部署和运行应用程序。

容器提供了运行应用程序的基本包装,可以在任何支持容器的云上部署。有了Kubernetes,就有了一个平台,可以帮助企业在运行Kubernetes的云或本地部署管理容器的部署和编排。

云中的Kubernetes
一颗种子总会发芽,结出硕果。在作为开源技术的短短3年时间里,Kubernetes成为基于容器的工作负载的默认编排引擎。虽然捐赠的是1.0版本,但是谷歌在大规模运行容器方面有十年的研究和经验。

Google是否在内部使用Kubernetes?来自Kubernetes博客:“Google上的许多开发人员都是以前在Borg项目上的开发人员。我们已经将Borg的最佳创意融入了Kubernetes,并试图解决用户在多年来与Borg确定的一些痛点。”

谷歌在一些内部项目中使用Kubernetes的声音很清晰,且很快就会改变一些现有的关键产品。即使未来需要更好的展示,Kubernetes也可以轻松定制 – 最大的好处是可以根据需要将自定义组件与现有组件进行混合和匹配。

以下是Google在过去几年 Kubernetes 的搜索量增长情况:


01.png



Google在Kubernetes上运行的Linux容器(LXC)并不是那么容易处理,而且需要掌握更多的专业知识。

2017年初,Kubernetes 只支持谷歌云平台(GCP)和谷歌Kubernetes引擎(GKE),但是在一年中,扩展到包括所有三家主要的公有云供应商。

二月份,微软正式加入支持Kubernetes的行列,宣布 Azure容器服务支持Kubernetes。去年11月,Kubernetes在亚马逊弹性容器服务(Amazon EKS)首次亮相。

除了公有云支持外,CNCF在9月份还宣布了Kubernetes认证服务提供商计划。该计划现在有25个合作伙伴公司开发和销售自己的Kubernetes发行版并提供管理服务。为了确保不同Kubernetes供应商和平台之间的互操作性,CNCF于2017年11月推出了认证Kubernetes计划,目前拥有42个成员公司。

Docker
Kubernetes部署大多使用Docker作为默认的容器引擎,除此之外还有CoreOS的rkt等。就其本身而言,Docker有一个叫做Swarm的自身的编排系统,首次亮相于2014年12月。

在许多企业的容器部署中,多数情况是Docker容器引擎正在被使用,Kubernetes被选择作为编排工具,而不是Swarm。10月17日,在与Kubernetes进行了三年的市场竞争之后,Docker Inc.宣布也将支持Kubernetes。

要清楚的是,Docker公司并没有放弃自己的Swarm容器编排系统; 相反,它同时支持Swarm和Kubernetes,让企业可以选择想要使用的平台。

在接受eWEEK 视频采访时,Docker首席执行官史蒂夫·辛格(Steve Singh)解释了为什么选择拥抱Kubernetes。Singh说:“Kubernetes为我们所做的事情是消除了任何潜在的混乱和冲突。我们有爱Kubernetes的客户,也有爱Docker Swarm的客户,不应该强迫客户在两者之间做出选择,而是让他们选择想要使用他们的东西。 ”

Kubernetes之前的Docker 让容器变得更酷,更易用。由Docker公司推出的Docker 在LXC功能的扩展之外,增加了多种功能。包括跨机器的可移植部署,版本控制,组件重用以及现在的 Docker Hub ,它提供了“开发测试流水线自动化,100,000个免费应用程序,公共和私有注册中心”。

以下是Google for Docker搜索量增长的图表:


02.png


Kubernetes 1.9和超越
2017年,Kubernetes更新了四个主要版本,增加了新的特性和功能。第一个主要版本是3月27日推出的Kubernetes 1.6,带来了新的可扩展性和稳定性功能。Kubernetes 1.7于6月29日发布,提供了帮助管理和保护容器基础设施的新功能。第三个版本是1.8更新,于9月28日推出,并支持基于角色的访问控制(Role-Based Access Control,RBAC)。

Kubernetes 1.9是2017年的最后一次重大更新,于12月15日正式推出。Kubernetes 1.9的亮点是Apps Workloads API,它为 Kubernetes 中长时间运行无状态和有状态工作负载提供了基础。

这是Kubernetes转型的一年,2017开源的努力始于一家公有云供应商,终于年底支持所有三家主要的公有云提供商。该项目也从Docker竞争对手的角色转到被Docker拥抱。多云的承诺长久以来只是一个承诺。作为一个可以在任何公有云提供商上启用容器应用程序工作负载的抽象层,随着Kubernetes 2017年的兴起,2018多云承诺将成为现实。

二、

Kubernetes正在巩固自己作为事实上的容器编排引擎的地位,而Docker帮助实现了这一点。尽管Docker一直是领先的容器技术,但容器编排市场还没这么清晰。2017年末,随着包括Docker在内的主要云平台提供商支持Kubernetes和一些令人惊讶的CNCF成员资格的增加,这种情况发生了变化。

正确的时机

“时机就是一切”,对于Kubernetes来说,这似乎是正确的。通过让容器更易用,Docker正在推动Kubernetes的发展。事实上,它已经成为每个公司发展的共生关系 。使用Kubernetes的人越多,使用Docker的也会越多,反之亦然。

根据 Portworx2017年度容器采购调查 (2017年2月至3月完成),有两项统计数据显示:
“对于拥有超过5000名员工的公司,Kubernetes的使用率为48%,主要编排工具占33%。”
“79%的样本选择Docker作为主要容器技术。”

为了进一步加持 Kubernetes 领导者地位,大型云计算和软件供应商们纷纷加入,以支持Docker容器的工作负载。

Kubernetes商业化产品

自从开源以来,Kubernetes有很多商业化产品,在过去的几个月,这个list上取得了重大且令人印象深刻的突破。

以Google(Google ContainerEngine),Red Hat(OpenShift),CoreOS(Tectonic),Canonical和 Apprenda 为长期商业供应商(长期以月计)。微软和VMware也已经提供了对Kubernetes的支持,最近已经全面all-in 推出。

2017 Kubernetes 得胜之年

2017年下半年,主要云服务商将Kubernetes添加到其核心产品中。值得注意的公告包括:
亚马逊网络服务(AWS)于八月份以白金会员 (最高级别) 加入了CNCF。虽然AWS加入CNCF与 Kubernetes 没有直接关系,但AWS拥有大量客户在运行容器和Kubernetes。

之后,10月份,Cloud Foundry基金会宣布了由Kubernetes提供支持的Cloud Foundry Container Runtime(CFCR),而Pivotal Cloud Foundry(与VMware合作 )则 于10月份在VMworld 宣布了Pivotal Container Service(PKS)。Pivotal和VMware都作为CNCF的白金会员注册; 再次,可用的最高水平。

VMware正在与Kubernetes合作的事实是一个明确的信号,Kubernetes和容器希望保持相关性。许多人质疑容器和云计算是否会取代虚拟机。虽然专家认为他们在企业中存在共存的空间,但可以看看VMware这位虚拟化之王的明显转变。

在十月之后,Microsoft 将 Azure容器服务 (ACS)更名 为AKS,K代表Kubernetes。这与他们以前的观点有很大的转变,即 ACS的好处之一是它支持多种编排工具 。

即使是Docker Inc.也已经屈服,最近在其Docker企业版框架中添加了本地Kubernetes支持。这对Kubernetes来说是一个重大的胜利,并将推动Docker自己的编排平台Docker Swarm的未来发展。

Docker甚至委托独立基准测试来对比Swarm和Kubernetes 。两者肯定都有用例,但Kubernetes得到Google支持的事实是经过了战斗性测试的(还记得 PokémonGO吗 ? ),并且拥有巨大的社区支持,企业把它看作标准的容器编排引擎。

这对企业意味着什么?

Kubernetes和Docker一直在坚持。随着公司迁移到云端,他们会发现他们有一些需求PaaS或IaaS最适合,还有一些其他需求容器(有些人称之为CaaS)会更适合。

为了享受到上云带来的好处,企业正在转向DevOps和云原生开发。采用DevOps时,企业开始使用运行在容器中的微服务,将应用程序构建为独立的组件。这些团队将会变得更小( 亚马逊CTO Werner Vogels 创造了“双比萨团队”(two-pizza team)一词),并且能够独立于应用的其他组件更新其“服务”的功能。

通过将开发工作分解为专注于解耦服务的小型团队,企业可以扩展开发工作,并更快地为客户/用户提供价值。现在,已然不是每六个月更新一次的代码库,而是按需随时进行更新。

自动化是复杂的抽象,为了使这项工作自动化,提供一个简单,可重复的方式来安全地交付和部署软件,团队会更频繁地执行。

技术的抽象和多样使监控成为难题的重要部分。企业拥有数千个独立移动的部件,其中许多可能显示为传统监控解决方案的黑盒子。随着企业迈向云原生,越来越多的应用程序正在云中运行,专门设计并运行良好的监控方法至关重要。

2018年将发生什么?Kubernetes给业务需求和企业客户能够带来的改变已经明晰,作为构建和运行云原生应用的平台乘胜追击,能够在多大比例的企业实现软着陆呢?大概套用那句老话是最准确的:前途是光明的,道路是曲折的。


原文链接:
1、2018 is the year of Kubernetes – with some help from Docker
https://www.tuicool.com/articles/QBFjAf6
2、2017 Year in Review: Kubernetes Enables a Multi-Cloud World
http://www.eweek.com/cloud/2017-year-in-review-kubernetes-enables-a-multi-cloud-world

DockOne微信分享(一一三):从一个实际案例来谈容器落地的问题

Dataman数人科技 发表了文章 • 0 个评论 • 3792 次浏览 • 2017-04-06 21:35 • 来自相关话题

【编者的话】容器是这两年最热的一个话题,去年大家都在谈Mesos、Kubernetes、Swarm,究竟哪家的挖掘技术强,今年容器技术的进一步普及,更多的人更关心容器技术如何落地,下面我们就基于一个实际的案例来聊一下容器落地遇到的问题。 ...查看全部
【编者的话】容器是这两年最热的一个话题,去年大家都在谈Mesos、Kubernetes、Swarm,究竟哪家的挖掘技术强,今年容器技术的进一步普及,更多的人更关心容器技术如何落地,下面我们就基于一个实际的案例来聊一下容器落地遇到的问题。

【深圳站|3天烧脑式Kubernetes训练营】培训内容包括:Kubernetes概述和架构、部署和核心机制分析、进阶篇——Kubernetes调工作原理及源码分析等。

背景:某银行数据中心计划搭建一个基于容器的PaaS平台
#持续集成
持续集成是容器一个绕不过去的话题,无论哪家容器厂商都一定会谈到,数人云关于持续集成,最开始用的是drone,一个小众的持续集成工具,将drone内置在平台上,通过平台的持续集成功能可以方便的实现持续集成的配置和管理。
##drone 的坑
一开始我们觉得这是一个很好的工具,但是后来发现其实没有想象中的那么美好,它的问题:

  • 对SVN的支持不好
  • 容易出问题,因为数人云平台所有的组件都是容器化的,所以若使用drone,则需要使用docker-in-docker技术,但是该技术已经是一个不再被维护的技术了,所以继续使用的风险很大。
##Jenkins是个好工具Jenkins是一个好工具,功能强大且稳定,基于Jenkins实现的持续集成基本没有花费什么开发的时间,通过脚本将代码构建和平台连接在一起即可轻松实现CI/CD。##总结往往用户需要的并不是那些看起来很酷的功能,真正需要的是能够实际解决问题的方案,即使这个方案很low。#配置管理在我看来,容器是一个革命性的产物,改变了软件交付的方式,它开箱即用的特性消灭了程序员常说的一句话 “在我这里运行时正常的啊!”; 它快速部署,环境无关的特性帮助运维人员提高了工作效率,但是任何事情都有其两面性,它的开箱即用,环境无关带来好处的同时,也带来了问题——配置文件。##传统应用在容器时代面临的第一个问题一般而言,每个程序都会有一个或多个配置文件,里边记录着DB地址、账号、密码、缓存地址等信息,在容器时代之前,应用程序一般的流转方式是“从开发->测试->生产”:
  • 开发同学交付一个编译之后的二进制文件,源文件(解释执行)或者代码仓库中某一个tag,同时附带一个release notes;
  • 测试同学拿到开发同学交付的内容后,就将其部署在自己的测试环境中,如果release notes中说明了有配置信息需要更新或依赖文件版本需要升级,会依照文件进行调整;
  • 如果测试通过,确定可以投产,那么就将其交付给运维同学进行生产部署。
此时有一个问题,开发、测试、运维每个环节都会自己维护配置文件,如果使用了容器,那么配置文件管理就是很麻烦的问题了,因为配置文件被放到了容器里,若想修改配置文件就不是那么简单的事情了,所以这就是传统应用在容器化时面临的第一个问题,当然这个问题也不是不能解决,一般而言,有以下几种解决方案:
  • 挂盘,将配置文件放到外部存储中,然后将该目录挂到容器中;
  • 生成新的镜像,基于Docker文件系统的特性,使用测试环境的配置文件覆盖开发环境的镜像,从而得到测试环境的镜像,同理,使用生产环境的配置文件覆盖开发环境的配置文件得到生产环境的镜像,使用该方案会导致每个环境都有一个镜像。
##容器时代配置管理的正确打开方式以上分析了传统应用容器化基本都会遇到的一个问题,而且也没有给出很好的解决方案,下面我们来谈下容器化时代配置管理的正确打开方式。其实通过上面问题的描述,我们可以很容易的找到问题的根本原因:配置文件本身是一个本地存储状态,要对其做无状态改造,对于配置管理的无状态改造一般是通过配置中心来完成的,即应用通过配置中心获取配置信息,无需读取本地配置文件,但是这个问题更麻烦,要解决这个问题需要首先解决两个问题:
  • 要先有个配置中心
  • 要改代码,使其可以适配配置中心
随着容器的普及,未来配置中心肯定会逐渐成为程序的标配。##最终选择的解决方案关于容器时代配置文件的问题,上边大概提到了3种方案,在最终落地的时候选择的是哪一种呢?答案是第二种——生成新的镜像。这是一个很low的方案,为什么没有选择另外两种呢? 我们来解释下原因:
  • 方案一[挂盘], 这个方案会给容器产生另外一个状态,外部文件,不符合cloud 的思想,pass;
  • 方案三[配置中心],成本太高,周期太长,而且需要改代码,往往之前的应用已经被维护了很多年,修改其配置接口,风险太大。
##总结虽然这个选择从技术上来看很low,但是个人认为,使用一个不太优雅的方案帮助一个新技术快速落地,然后推动其快速前进,比一直纠结于方案是否高大上,是否优雅等,而导致新的技术一直被悬在空中更好,就像大家一直在争论Mesos、Kubernetes、Swarm究竟哪个更好,现在也没有一个结论,与其争论这么多虚的,不如仔细想一下自己的问题是什么,究竟哪个技术更适合自己。#日志目前使用ELK作为日志方案。##传统应用的坑一般而言,传统的应用都是把日志写到一个指定的路径下,然后通过Logstash采集日志并送入Elasticsearch进行存储,但是这种应用如果直接容器化之后就会带来一个问题——应用的日志文件应该如何存储。
  • 方案一:放到容器里
  • 方案二:挂盘,写到外部存储上
两种方案都有一些问题:
  • 放到容器里,逻辑上最简单,不需要做任何改动,但是它的问题是,怎么从容器中把日志取出来。
  • 通过挂盘,把容器日志写到外部存储,然后沿用传统的Logstash + ES 的方式处理日志,听起来很美好,但是如何建立容器和日志的对应关系?
##容器时代日志的正确打开方式按照之前的惯例,我们先提出在容器时代,日志的正确处理方式,如果应用使用Docker进行交付,不建议写日志文件,直接将日志写入标准输出即可,然后Logstash通过Docker的log-driver捕获日志,这样日志文件既不需要落盘,也使日志文件摆脱了状态,可以更容易的横向扩缩。##最终选择的解决方案最终我们实现的是方案三,因为用户在我们的建议下,选择了将日志输出到标准输出。##新的问题写日志的目的是为了看的,这是一个无比正确的废话,但是如何实时的看到需要的日志却成了我们面临的一个新问题。在容器时代之前,我们一般是通过tail来实时的看日志或者通过Kibana来分析日志。在容器的时代,通过Kibana看日志的方式没什么变化,但是看实时日志就有了一些问题,在用户采取了我们的建议将日志写入标准输出后可以比较优雅的处理日志了,但是另外一个问题出现了,实时日志没有了,因为日志已经被log-driver收走了,怎么办?虽然依然可以从ES中找到日志,但是由于ELK本身的机制,不能通过ELK看到实时日志。##新的解决办法新的问题,需要新的办法来解决,如何解决,其实说穿了也简单,实现了一个log-agent的功能,可以将日志送到两个地方,Logstash和实时日志。##总结事情就是这样,我们以为解决了一个问题的时候,往往一个新的问题又摆在前面,像容器落地这种事情,对传统应用的整体工作方式和流程都有很大的冲击,所以一定也会遇到同等规模的问题需要解决。#监控银行对监控是非常重视的,尤其是运维部门,所以为了满足客户的需求,我们实现了:
  • 平台自身监控
  • 宿主机监控
  • 中间件监控
监控本身是我们平台很重要的一个部分,但是在实际实施过程中发现,客户其实不是很在意做的监控页面,仪表盘等监控数据,他们自身有健全的监控平台,其实我们需要做的事情就是将我们的数据吐到他的平台上即可。## 总结世事难料,你永远不知道下一块巧克力什么味道,这个我们自身投入了很大精力和时间来实现的功能在用户那里就变成了一个对接的任务。#弹性扩缩弹性扩缩一直是容器厂家喜欢谈的一个口号,曾经有一度我们认为基于Docker的特性来实行弹性扩缩是一件很容易的事情,但是后来发现,这里其实有一个大坑。##扩很容易,缩很难弹性扩容是一件比较容易的事情,我们只要对接监控数据,然后配置一些规则,即可触发应用容器个数增加,实现扩容,但是缩容就会面临几个问题:
  • 什么时候缩容?
  • 如何安全的缩容?
什么时候缩容,这个问题相对来说还不是特别麻烦,可以设定一个指标,比如CPU,内存,IO等指标来触发缩容,这里只要做一些带有缓冲的规则,避免由于规则简单而导致的扩缩抖动即可。如何安全的缩容相当麻烦,缩容在本质上是要停掉一些容器的,如何判断这个容器是可以停止的,如果一个容器没有流量了,那么应该是可以被停止的,如何让一个容器的流量停止?可以通过前端负载进行控制,不往这个容器分发流量,那么前端的负载是如何判断应该如何往后端分发流量呢?这个有多重因素:
  • 自身算法
  • 应用程序本身是有状态的,需要保持会话

从以上简单的分析中我们可以发现,缩容不是简单的条件符合了就可以做的事情,要想在不影响业务的情况下实现缩容,是一件非常麻烦的事情,它与平台架构,运行的程序的业务逻辑有很深的耦合。
## 总结
要实现自动的扩缩容,不是一件简单的事情,而是一个系统的工程。

以上内容是基于数人云在某银行实施过程中总结出来的一些感悟,如果能给大家一些帮助,我们非常高兴,如果有问题,请指出来,我们共同提高,Docker到现在大概有3年多的历史,个人看来它距离真正落地还有很大一段路程要走,我们必须不停的摸索。
#Q&A
Q:我想问一下,日志打两份的话具体是怎么实现的呢,用到了哪些技术或现有的工具呢?

A:我们自己实现了一个log-agent, 然后log-agent 可以实现这个功能。



Q:如果应用有自己的写的日志,如log4j的,输出不到标准输出,还怎么处理?

A:log4j貌似是可通过配置输出到标准输出的,另外如果有些应用不能输出到标准输出的,可以配置日志文件路径,我们会去读文件。



Q:缩容的产生条件是否有比较好的解决方案,比如根据CPU、内存甚至业务规则多维度的进行考察?

A:缩容很容易,但是麻烦的是如何安全的缩容,我理解这个环节其实是跟应用的逻辑有直接关系的,如果应用是一个无状态的应用,那么缩容非常简单,只需要在前端控制流量,然后停止容器即可,但是如果是有状态的应用,那么就有可能对用户造成影响。



Q:配置管理这块,不断的覆盖会增加镜像体积,如何最大化减少镜像大小呢?

A:首先,一个镜像最多被覆盖2,3次,测试镜像一次,生产镜像一次,而且配置文件一般是很小的,几乎对镜像大小没有影响。



Q:测试环境配置文件覆盖开发环境镜像,是只用测试环境的docket file 吗? 如果每天打版,会很麻烦吗?

A:通过覆盖测试文件来解决环境问题,只是一个思路,不一定非要使用开发测试环境的信息,这个可以具体情况具体分析。



Q:log-agent具体实现呢,日志直接打给log-agent还是log-agent读取本地日志文件呢?或者说log-agent读取标准输出的内容呢?

A:log-agent可以通过Docker的log-driver获取标准输出的日志,同时也可以直接读取日志文件的日志。



Q:配置ENV化完全可以由运维来实现,容器的启动交由脚本来执行,然后在脚本中来读取所有的ENV并修改应用,完成后再启动应用,这样就只需要来维护脚本了。

A:是个好主意,但是我们当时考虑配置文件覆盖这个方案的时候,是基于开发人员不对代码做任何修改的思路来考虑的。



Q:容器生命周期很短?如何做到动态监控?你们具体监控了哪些重要指标?谢谢。

A:我们监控用的是Prometheus方案,监控做了 主机,容器,中间件 几个大的范围。



以上内容根据2017年4月6日晚微信群分享内容整理。分享人陈俊凯,数人云资深架构师。最早在爱立信做 CDMA 核心网开发,随后负责腾讯 C++ 后台开发,对 Docker,Mesos 有所研究,熟悉和热爱云计算、分布式、SDN 等领域相关技术。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

DockOne微信分享(一零七):SRE工程实践——基于时间序列存储数据的报警

Dataman数人科技 发表了文章 • 0 个评论 • 4279 次浏览 • 2017-02-22 17:12 • 来自相关话题

【编者的话】构建智能运维平台,运行监控和故障报警是两个绕不过去的重要部分。本次分享主要是介绍引入SRE理念后的基于时间序列数据存储的报警工程实践。 #SRE报警介绍 今天我分享的主题是SRE基于时间序列数据的报警实践,既然是基于时间序列 ...查看全部
【编者的话】构建智能运维平台,运行监控和故障报警是两个绕不过去的重要部分。本次分享主要是介绍引入SRE理念后的基于时间序列数据存储的报警工程实践。
#SRE报警介绍
今天我分享的主题是SRE基于时间序列数据的报警实践,既然是基于时间序列。

首先,我先简单介绍一下什么是时间序列数据。

时间序列(time series)数据是一系列有序的数据。通常是等时间间隔的采样数据。时间序列存储最简单的定义就是数据格式里包含timestamp字段的数据。时间序列数据在查询时,对于时间序列总是会带上一个时间范围去过滤数据。同时查询的结果里也总是会包含timestamp字段。

监控数据大量呈现为时间序列数据特征,所以,为了应对复杂的监控数据格式,在每一份数据中加上时间字段。区别于传统的关系型数据库,时间序列数据的存储、查询和展现进行了专门的优化,从而获得极高的数据压缩能力、极优的查询性能,特别契合需要处理海量时间序列数据的物联网应用场景。

Google的监控系统经过10年的发展,经历了从传统的探针模型、图形化趋势展示的模型到现在基于时间序列数据信息进行监控报警的新模型。这个模型将收集时间序列信息作为监控系统的首要任务,同时发展了一种时间序列信息操作语言,通过使用该语言将数据转化为图标和报警取代了以前的探针脚本。

监控和报警是密不可分的两个部分,之前我们公司的CTO肖德时曾经做过关于基于时间序列数据监控实践的分享,在本次分享中就不重复介绍前面的监控部分,感兴趣的同学可以去看看老肖的文章

运维团队通过监控系统了解应用服务的运行时状态,保障服务的可用性和稳定性。监控系统也通常会提供Dashboard展示服务运行的指标数据,虽然各种折线图看着很有趣,但是监控系统最有价值的体现,是当服务出现异常或指标值超过设定的阀值,运维团队收到报警消息,及时介入并恢复服务到正常状态的时候。

SRE团队认为监控系统不应该依赖人来分析报警信息,应该由系统自动分析,发出的报警要有可操作性,目标是解决某种已经发生的问题,或者是避免发生的问题。
#监控与报警
监控与报警可以让系统在发生故障或临近发生故障时主动通知我们。当系统无法自动修复某个问题时,需要一个人来调查这项警报,以决定目前是否存在真实故障,采取一定方法缓解故障,分析故障现象,最终找出导致故障的原因。监控系统应该从两个方面提供故障的信息,即现象和原因。
##黑盒监控与白盒监控
黑盒监控: 通过测试某种外部用户可见的系统行为进行监控。这是面向现象的监控,提供的是正在发生的问题,并向员工发出紧急警报。对于还没有发生,但是即将发生的问题,黑盒监控无能为力。

白盒监控依靠系统内部暴露的一些性能指标进行监控。包括日志分析,Java虚拟机提供的监控接口,或者一个列出内部统计数据的HTTP接口进行监控。白盒监控能够通过分析系统内部信息的指标值,可以检测到即将发生的问题。白盒监控有时是面向现象的,有时是面向原因的,这个取决于白盒监控提供的信息。

Google的SRE大量依赖于白盒监控。
##设置报警的几个原则
通常情况下,我们不应该仅仅因为“某个东西看起来有点问题”就发出警报。

紧急警报的处理会占用员工宝贵的时间,如果该员工在工作时间段,该报警的处理会打断他原本的工作流程。如果该员工在家,紧急警报的处理会影响他的个人生活。频繁的报警会让员工进入“狼来了”效应,怀疑警报的有效性和忽略报警,甚至错过了真实发生的故障。

设置报警规则的原则:

  • 发出的警报必须是真实的,紧急的,重要的,可操作的。
  • 报警规则要展示你的服务正在出现的问题或即将出现的问题。
  • 清晰的问题分类,基本功能是否可用;响应时间;数据是否正确等。
  • 对故障现象报警,并提供尽可能详细的细节和原因,不要直接对原因报警。
#基于时间序列数据进行有效报警传统的监控,通过在服务器上运行脚本,存储返回值进行图形化展示,并检查返回值判断是否报警。Google内部使用Borgmon做为监控报警平台。在Google之外,我们可以使用Prometheus作为基于时间序列数据监控报警的工具,进而实践SRE提供的白盒监控理念。监控报警平台架构图:
Dockerone_图1.png
##监控报警组件
  • cAdvisro为用户提供理解容器运行时的资源使用和性能特征的工具。cAdvisor作为一个后台运行的程序,收集,聚合,处理并导出容器运行时的信息。
Link: https://github.com/google/cadvisor
  • Prometheus是SoundCloud开发的开源的系统监控报警工具集。Prometheus从cAdvisor的HTTP接口采集容器运行时的信息,保存在内部的存储里,利用PromQL对时序数据进行查询展示和设置报警。报警信息推送到Alertmanager。
Link: https://prometheus.io/
  • Alertmanager处理由Prometheus服务发送过来的报警,进行去重,分组,路由,静默和降噪等操作。
Link: https://prometheus.io/docs/alerting/alertmanager/
  • Alerta是一个用户友好的报警可视化展示工具,用于展示和管理从Alertmanager推送过来的报警数据。
Link:http://alerta.io/

##搭建测试环境
为了方便测试,我们在测试服务器上用容器运行以上组件,测试服务器地址192.168.1.188。

1. 启动两个Nginx容器,并分配不同的label标识一个属于Dev组的应用,一个属于Ops组的应用。
2. 启动cAdvisor容器,端口映射8080。
3. 启动Alertmanager容器,端口映射9093,配置文件中指定Alerta的地址作为Webhook的通知地址。
4. 启动Prometheus容器,端口映射9090,CMD指定“-alertmanager.url”地址为Alertmanager的地址。
5. 启动MongoDB作为alerta的数据库
6. 启动Alerta,端口映射为8181

容器运行截图:
Dockerone_图2.png

##应用指标收集
cAdvisor原生提供http接口暴露Prometheus需要收集的metrics,我们访问http://192.168.1.188:8080/metrics。
Dockerone_图3.png

在Prometheus的配置文件里配置cAdvisor的地址作为target地址,可以在Prometheus的Web页面查看Targets的状态。
Dockerone_图4.png

在Prometheus的Graph页面,可以对收集的数据进行查询和图形化展示。
Dockerone_图5.png

Dockerone_图6.png

##报警规则配置
我们针对容器应用的CPU使用率配置报警规则,规则如下:
Dockerone_图7.png

图中分别针对dev组和ops组设置了应用容器的报警规则,报警规则的格式:

* “Alert”是报警规则的名字,名字间不能有空格,可以用下划线链接;
* “IF”是数据的查询表达式,截图中的语句内容查询指标“container_cpu_usage_seconds_total”,label “container_label_dataman_service”等于“web”,label “container_label_dataman_group” 等于“dev”,用函数irate()计算指标在上一个5分钟内每秒钟CPU使用时间的差值的比率。简单点说计算了CPU占用时间的百分比。这里两个报警规则中的表达式有点区别,是为了区分两个组的应用。
* “FOR”是报警状态持续超过1分钟后,将报警由状态“PENDING”改为“FIRING”,报警将交给Alertmanager处理。
* “LABELS”为自定义数据,我们在这里指定了报警的级别和显示“IF”中表达式的值。
* “ANNOTATIONS”为自定义数据,我们在这里提供报警的现象和原因介绍。

##触发报警
我们用stress对两个容器的CPU进行加压,使得容器的CPU使用率超过报警的阀值。在Prometheus的页面我们看到了产生的报警。
Dockerone_图8.png

在Alertmanager页面看到从Prometheus发过来的报警。
Dockerone_图9.png

可以看到Alertmanager还把报警消息推送给了alerta。
##报警消息展示
Alerta对接收到的报警进行保存并展示。
Dockerone_图10.png

选择某条报警信息,可以进入详情,在详情页可以对报警进行Ack,关闭等操作。
Dockerone_图11.png

报警结束后,可以在alerta中查看报警的历史,即处于关闭状态的报警。
Dockerone_图12.png

#结束语
这里我们简要的介绍了下如何运用cAdvisor,Prometheus,Alertmanager和Alerta实现Google SRE中介绍的基于时序数据的报警实践,针对性能指标的报警只是最基础的报警方式,我们后续还会介绍如何配置和采集应用的内部数据指标,并进行监控报警的配置。应用系统的监控是一个复杂的过程,需要不断的调整以应对服务的运行状况和服务质量,也需要我们不断的吸取SRE的运维理念并在实践中落地。SRE可以说是DevOps在运维方面的具体实现,它既包括了理念、文化也包括了像监控报警这样具体的运维和工程实践。现在国内越来越多的企业开始关注SRE如何在整个生命周期为项目提供持续性支持。但是如何能够让SRE理念在本土落地,如何寻找到适合企业自身的SRE之路,数人云也在不断摸索并持续将现有的经验分享给大家,期望大家都能共同汲取SRE的营养以不断提升企业的运维和工程实践的水平。谢谢!
#Q&A
Q:告警信息收到后,系统有没有能力自动解决告警报告的问题?还是需要人工解决问题?谢谢

A:这个要分情况,好的机制是报警应该发出的是新的问题,然后通过反馈机制,让同类的问题不再发生,或者由监控系统自身解决。



Q:InfluxDB系列方案是否有考虑,Grafana 最新版也有了很好的告警机制,是否有尝试?

A:曾经考虑并实践过InfluxDB的TICK组合方案,非常方便可以实现数据收集存储处理展示的完整流程。通过对比,我们发现Prometheus更符合Google SRE对于监控的理念,自身社区也非常活跃,就转向Prometheus的方案了。Grafana实现了强大的可视化配置报警规则的功能,对于原本只做为展示的工具,是很好的增强,这个对我们的启发也很大,也在学习中。



Q:报警规则配置是什么语法,是否可以可视化?

A:Prometheus是在配置文件中描述报警规则。可以自己动手实现可视化。



Q:数据量庞大的情况怎么解决,比如说万台机器,500个指标数据等 一分钟一个点 60243050010000 的数据量,如何保存,如何快速查询数据。 需要什么样的架构和硬件?

A:简单回答,Prometheus可以通过分组支持大规模的集群,但是达到某个确定的规模,那就需要实践给出答案了。



Q:请问在监控报警方面有没有考虑或实践过智能预警,比如基于历史监控数据,通过机器学习,实现提前预警等?

A:这个不是SRE推荐的方式,报警应该简单,高级的功能会模糊真实的意图。



Q:请问基于此方案部署的主机和容器规模有多大,基于什么频率进行监控收集?

A:本次分享的是测试环境,规模不大。Prometheus定时从cAdvisor收集数据,抓取频率5s。



Q:cAdvisor采集数据的性能表现怎么样,占用主机的资源大嘛?

A:性能表现优异,担心占用资源,可以在启动容器时进行资源限制。



Q:APP自身业务逻辑需要监控的数据,比如Counter,Gauge等,传统用Zabbix等可以进行数据采集。我明白cAdvisor是对Container进行数据采集。但是有没有可能把APP自身的监控和Container的监控结合?

A:后续话题,我们会实践有关应用的监控报警。Prometheus的逻辑是定时从exporter抓取数据,然后对存储的时序数据,通过PromQL进行查询和分析,所以是可以实现APP自身的监控和容器监控的结合的。



以上内容根据2017年2月21日晚微信群分享内容整理。分享人窦中强,数人云研发工程师。多年运维开发经验,熟悉配置管理,持续集成等相关技术和实践,目前负责数人云平台监控报警组件的研发工作。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

DockOne微信分享(八十五):Docker存储方式选型建议

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

【编者的话】Docker存储方式提供管理分层镜像和容器的可读写层的具体实现。最初Docker仅能在支持AUFS文件系统的Ubuntu 发行版上运行,但是由于AUFS未能加入Linux内核,为了寻求兼容性、扩展性,Docker在内部通过GraphDriver机制 ...查看全部
【编者的话】Docker存储方式提供管理分层镜像和容器的可读写层的具体实现。最初Docker仅能在支持AUFS文件系统的Ubuntu 发行版上运行,但是由于AUFS未能加入Linux内核,为了寻求兼容性、扩展性,Docker在内部通过GraphDriver机制这种可扩展的 方式来实现对不同文件系统的支持。本次分享通过一次客户实施案例深入的看看Docker的几种存储方式,并给出一些技术选型的建议。

Docker存储方式:

  1. AUFS的介绍及分析
  2. Device mapper的介绍及分析
  3. OverlayFS的介绍及分析
  4. Btrfs的介绍及分析
  5. ZFS的介绍及分析

#第一部分 问题诊断
事情从一次实施项目说起,我们需要帮助客户将他们的应用容器化并在数人云平台上发布此应用。客户的应用是传统WAS应用。应用是通过WAS console界面进行手工部署,暂时无法通过Dockerfile进行自动化应用部署,最后的镜像是通过Docker commit完成。镜像启动执行命令是startwas.sh,并通过tail将应用日志输出到标准输出。 启动容器,WAS Server启动失败,错误日志如下:
Picture1.jpg

WAS Server标准日志文件startServer.log和native_stderr.log都没有更加详细的错误信息。最后功夫不负有心人, 在configuration目录下找到可以定位的错误信息 =_=!:
Picture2.jpg

文件访问IO异常,查看相应目录文件的属性:
Picture3.jpg

到现在为止,可以初步判断是Docker存储方式(storage drive)在镜像容器分层管理上的问题。

当前宿主机是CentOS 7.2,内核3.10.0。并且查看当前宿主机信息是Docker 1.12.0,存储方式是Overlay,宿主机的文件系统是XFS:
Picture4.jpg

为了验证我们的推断,我们做了如下几方面的尝试:

尝试1:使用数据卷挂载的方式,挂载整个washome目录。(数据卷是Docker宿主机的目录或文件,通过mount的方式加载到容器里,不受存储驱动的控制。)重新制作镜像启动容器,WAS Server能正常启动。

尝试2:改变Docker engine的存储方式,改成Device mapper,重新拉取镜像,并启动容器,WAS Server能正常启动。

那么这个问题是普遍问题吗?

尝试3:在其他的宿主机上,启动原镜像,这个问题是无法复现的。

经过多次测试发现在相同内核、系统版本、Docker版本有些机器有问题有些机器没有问题,最终发现是CentOS提供的新文件系统XFS和Overlay兼容问题导致。同时,我们从Docker社区找到相关问题的issue报告:https://github.com/docker/docker/issues/9572 这个问题的修复在内核 4.4.6以上。综上所述,我们得到了一个结论,这个问题的根本原因是overlayFS在xfs上出现了兼容性的问题。

事情的起因到此为止,下面让我们深入的看看Docker的几种存储方式,并给出一些技术选型的建议。
#第二部分 概述
Docker在启动容器的时候,需要创建文件系统,为rootfs提供挂载点。最底层的引导文件系统bootfs主要包含bootloader和kernel,bootloader主要是引导加载kernel,当kernel被加载到内存中后 bootfs就被umount了。 rootfs包含的就是典型 Linux 系统中的/dev,/proc,/bin,/etc等标准目录和文件。

Docker模型的核心部分是有效利用分层镜像机制,镜像可以通过分层来进行继承,基于基础镜像(没有父镜像),可以制作各种具体的应用镜像。Docker 1.10引入新的可寻址存储模型,使用安全内容哈希代替随机的UUID管理镜像。同时,Docker提供了迁移工具,将已经存在的镜像迁移到新模型上。不同 Docker容器就可以共享一些基础的文件系统层,同时再加上自己独有的可读写层,大大提高了存储的效率。其中主要的机制就是分层模型和将不同目录挂载到同一个虚拟文件系统。
sharing-layers.jpg

Docker存储方式提供管理分层镜像和容器的可读写层的具体实现。最初Docker仅能在支持AUFS文件系统的Ubuntu发行版上运行,但是由于AUFS未能加入Linux内核,为了寻求兼容性、扩展性,Docker在内部通过graphdriver机制这种可扩展的方式来实现对不同文件系统的支持。

Docker有如下几种不同的drivers:

  • AUFS
  • Device mapper
  • Btrfs
  • OverlayFS
  • ZFS
#第三部分 方案分析##AUFSAUFS(AnotherUnionFS)是一种Union FS,是文件级的存储驱动。所谓 UnionFS 就是把不同物理位置的目录合并mount到同一个目录中。简单来说就是支持将不同目录挂载到同一个虚拟文件系统下的文件系统。这种文件系统可以一层一层地叠加修改文件。无论底下有多少层都是只读的,只有最上层的文件系统是可写的。当需要修改一个文件时,AUFS创建该文件的一个副本,使用CoW将文件从只读层复制到可写层进行修改,结果也保存在可写层。在Docker中,底下的只读层就是image,可写层就是Container。结构如下图所示:
aufs_layers.jpg
例子运行一个实例应用是删除一个文件/etc/shadow,看AUFS的结果:
# docker run centos rm /etc/shadow # ls -la /var/lib/docker/aufs/diff/$(docker ps --no-trunc -lq)/etc
total 8drwxr-xr-x 2 root root 4096 Sep  2 18:35 .drwxr-xr-x 5 root root 4096 Sep  2 18:35 ..-r--r--r-- 2 root root    0 Sep  2 18:35 .wh.shadow
目录结构
  • 容器挂载点(只有容器运行时才被加载)
/var/lib/docker/aufs/mnt/$CONTAINER_ID/
  • 分支(和镜像不同的文件,只读活着读写)
/var/lib/docker/aufs/diff/$CONTAINER_OR_IMAGE_ID/
  • 镜像索引表(每个镜像引用镜像名)
/var/lib/docker/aufs/layers/
其他AUFS 文件系统可使用的磁盘空间大小
# df -h /var/lib/docker/Filesystem      Size  Used Avail Use% Mounted on/dev/vda1        20G  4.0G   15G  22% /
系统挂载方式启动的Docker
docker psCONTAINER ID        IMAGE                        COMMAND                CREATED             STATUS              PORTS                      NAMES3f2e9de1d9d5        mesos/bamboo:v0.1c           "/usr/bin/bamboo-hap   5 days ago          Up 5 days                                      mesos-20150825-162813-1248613158-5050-1-S0.88c909bc-6301-423a-8283-5456435f12d3dc9a7b000300        mesos/nginx:base             "/bin/sh -c nginx"     7 days ago          Up 7 days           0.0.0.0:31967->80/tcp      mesos-20150825-162813-1248613158-5050-1-S0.42667cb2-1134-4b1a-b11d-3c565d4de4181b466b5ad049        mesos/marathon:omega.v0.1    "/usr/bin/dataman_ma   7 days ago          Up 16 hours                                    dataman-marathon0a01eb99c9e7        mesos/nginx:base             "/bin/sh -c nginx"     7 days ago          Up 7 days           0.0.0.0:31587->80/tcp      mesos-20150825-162813-1248613158-5050-1-S0.4f525828-1217-4b3d-a169-bc0eb901eef1c2fb2e8bd482        mesos/dns:v0.1c              "/usr/bin/dataman_me   7 days ago          Up 7 days                                      mesos-20150825-162813-1248613158-5050-1-S0.82d500eb-c3f0-4a00-9f7b-767260d1ee9adf102527214d        mesos/zookeeper:omega.v0.1   "/data/run/dataman_z   8 days ago          Up 8 days                                      dataman-zookeeperb076a43693c1        mesos/slave:omega.v0.1       "/usr/sbin/mesos-sla   8 days ago          Up 8 days                                      dataman-slavee32e9fc9a788        mesos/master:omega.v0.1      "/usr/sbin/mesos-mas   8 days ago          Up 8 days                                      dataman-masterc8454c90664e        shadowsocks_server           "/usr/local/bin/ssse   9 days ago          Up 9 days           0.0.0.0:57980->57980/tcp   shadowsocks6dcd5bd46348        registry:v0.1                "docker-registry"      9 days ago          Up 9 days           0.0.0.0:5000->5000/tcp     dataman-registry
对照系统挂载点
grep aufs /proc/mounts/dev/mapper/ubuntu--vg-root /var/lib/docker/aufs ext4 rw,relatime,errors=remount-ro,data=ordered 0 0none /var/lib/docker/aufs/mnt/6dcd5bd463482edf33dc1b0324cf2ba4511c038350e745b195065522edbffb48 aufs rw,relatime,si=d9c018051ec07f56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/c8454c90664e9a2a2abbccbe31a588a1f4a5835b5741a8913df68a9e27783170 aufs rw,relatime,si=d9c018051ba00f56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/e32e9fc9a788e73fc7efc0111d7e02e538830234377d09b54ffc67363b408fca aufs rw,relatime,si=d9c018051b336f56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/b076a43693c1d5899cda7ef8244f3d7bc1d102179bc6f5cd295f2d70307e2c24 aufs rw,relatime,si=d9c018051bfecf56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/df102527214d5886505889b74c07fda5d10b10a4b46c6dab3669dcbf095b4154 aufs rw,relatime,si=d9c01807933e1f56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/c2fb2e8bd4822234633d6fd813bf9b24f9658d8d97319b1180cb119ca5ba654c aufs rw,relatime,si=d9c01806c735ff56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/0a01eb99c9e702ebf82f30ad351d5a5a283326388cd41978cab3f5c5b7528d94 aufs rw,relatime,si=d9c018051bfebf56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/1b466b5ad049d6a1747d837482264e66a87871658c1738dfd8cac80b7ddcf146 aufs rw,relatime,si=d9c018052b2b1f56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/dc9a7b000300a36c170e4e6ce77b5aac1069b2c38f424142045a5ae418164241 aufs rw,relatime,si=d9c01806d9ddff56,dio,dirperm1 0 0none /var/lib/docker/aufs/mnt/3f2e9de1d9d51919e1b6505fd7d3f11452c5f00f17816b61e6f6e97c6648b1ab aufs rw,relatime,si=d9c01806c708ff56,dio,dirperm1 0 0
分析[list=1]
  • 虽然AUFS是Docker第一版支持的存储方式,但到现在还没有加入内核主线( CentOS无法直接使用)。
  • 从原理分析看,AUFS mount()方法很快,所以创建容器很快;读写访问都具有本机效率;顺序读写和随机读写的性能大于KVM;并且Docker的AUFS可以有效的使用存储和内存 。
  • AUFS性能稳定,并且有大量生产部署及丰富的社区支持。
  • 不支持rename系统调用,执行“copy”和“unlink”时,会导致失败。
  • 当写入大文件的时候(比如日志或者数据库等)动态mount多目录路径的问题,导致branch越多,查找文件的性能也就越慢。(解决办法:重要数据直接使用 -v 参数挂载。)
  • ##Device mapperDevice mapper是Linux内核2.6.9后支持的,提供的一种从逻辑设备到物理设备的映射框架机制,在该机制下,用户可以很方便的根据自己的需要制定实现存储资源的管理策略。Docker的Device mapper利用Thin provisioning snapshot管理镜像和容器。Thin-provisioning SnapshotSnapshot是Lvm提供的一种特性,它可以在不中断服务运行的情况下为the origin(original device)创建一个虚拟快照(Snapshot)。Thin-Provisioning是一项利用虚拟化方法减少物理存储部署的技术。Thin-provisioning Snapshot是结合Thin-Provisioning和Snapshoting两种技术,允许多个虚拟设备同时挂载到一个数据卷以达到数据共享的目的。Thin-Provisioning Snapshot的特点如下:[list=1]
  • 可以将不同的snaptshot挂载到同一个the origin上,节省了磁盘空间。
  • 当多个Snapshot挂载到了同一个the origin上,并在the origin上发生写操作时,将会触发COW操作。这样不会降低效率。
  • Thin-Provisioning Snapshot支持递归操作,即一个Snapshot可以作为另一个Snapshot的the origin,且没有深度限制。
  • 在Snapshot上可以创建一个逻辑卷,这个逻辑卷在实际写操作(COW,Snapshot写操作)发生之前是不占用磁盘空间的。
  • 相比AUFS和OverlayFS是文件级存储,Device mapper是块级存储,所有的操作都是直接对块进行操作,而不是文件。Device mapper驱动会先在块设备上创建一个资源池,然后在资源池上创建一个带有文件系统的基本设备,所有镜像都是这个基本设备的快照,而容器则是镜像的快照。所以在容器里看到文件系统是资源池上基本设备的文件系统的快照,并没有为容器分配空间。当要写入一个新文件时,在容器的镜像内为其分配新的块并写入数据,这个叫用时分配。当要修改已有文件时,再使用CoW为容器快照分配块空间,将要修改的数据复制到在容器快照中新的块里再进行修改。Device mapper 驱动默认会创建一个100G的文件包含镜像和容器。每一个容器被限制在10G大小的卷内,可以自己配置调整。结构如下图所示:
    6.jpg
    可以通过"docker info"或通过dmsetup ls获取想要的更多信息。查看Docker的Device mapper的信息:
    7.png
    分析[list=1]
  • Device mapper文件系统兼容性比较好,并且存储为一个文件,减少了inode消耗。
  • 每次一个容器写数据都是一个新块,块必须从池中分配,真正写的时候是稀松文件,虽然它的利用率很高,但性能不好,因为额外增加了VFS开销。
  • 每个容器都有自己的块设备时,它们是真正的磁盘存储,所以当启动N个容器时,它都会从磁盘加载N次到内存中,消耗内存大。
  • Docker的Device mapper默认模式是loop-lvm,性能达不到生产要求。在生产环境推荐direct-lvm模式直接写原块设备,性能好。
  • ##OverlayFSOverlay是Linux内核3.18后支持的,也是一种Union FS,和AUFS的多层不同的是Overlay只有两层:一个Upper文件系统和一个Lower文件系统,分别代表Docker的镜像层和容器层。当需要修改一个文件时,使用CoW将文件从只读的Lower复制到可写的Upper进行修改,结果也保存在Upper层。在Docker中,底下的只读层就是image,可写层就是Container。结构如下图所示:
    8.jpg
    分析[list=1]
  • 从kernel 3.18进入主流Linux内核。设计简单,速度快,比AUFS和Device mapper速度快。在某些情况下,也比Btrfs速度快。是Docker存储方式选择的未来。因为OverlayFS只有两层,不是多层,所以OverlayFS “copy-up”操作快于AUFS。以此可以减少操作延时。
  • OverlayFS支持页缓存共享,多个容器访问同一个文件能共享一个页缓存,以此提高内存使用。
  • OverlayFS消耗inode,随着镜像和容器增加,inode会遇到瓶颈。Overlay2能解决这个问题。在Overlay下,为了解决inode问题,可以考虑将/var/lib/docker挂在单独的文件系统上,或者增加系统inode设置。
  • 有兼容性问题。open(2)只完成部分POSIX标准,OverlayFS的某些操作不符合POSIX标准。例如: 调用fd1=open("foo", O_RDONLY) ,然后调用fd2=open("foo", O_RDWR) 应用期望fd1 和fd2是同一个文件。然后由于复制操作发生在第一个open(2)操作后,所以认为是两个不同的文件。
  • 不支持rename系统调用,执行“copy”和“unlink”时,将导致失败。
  • ##BtrfsBtrfs被称为下一代写时复制文件系统,并入Linux内核,也是文件级级存储,但可以像Device mapper一直接操作底层设备。Btrfs利用 Subvolumes和Snapshots管理镜像容器分层。Btrfs把文件系统的一部分配置为一个完整的子文件系统,称之为Subvolume,Snapshot是Subvolumn的实时读写拷贝,chunk是分配单位,通常是1GB。那么采用 Subvolume,一个大的文件系统可以被划分为多个子文件系统,这些子文件系统共享底层的设备空间,在需要磁盘空间时便从底层设备中分配,类似应用程序调用 malloc()分配内存一样。为了灵活利用设备空间,Btrfs 将磁盘空间划分为多个chunk 。每个chunk可以使用不同的磁盘空间分配策略。比如某些chunk只存放metadata,某些chunk只存放数据。这种模型有很多优点,比如Btrfs支持动态添加设备。用户在系统中增加新的磁盘之后,可以使用Btrfs的命令将该设备添加到文件系统中。Btrfs把一个大的文件系统当成一个资源池,配置成多个完整的子文件系统,还可以往资源池里加新的子文件系统,而基础镜像则是子文件系统的快照,每个子镜像和容器都有自己的快照,这些快照则都是subvolume的快照。
    9.jpg
    分析[list=1]
  • Btrfs是替换Device mapper的下一代文件系统, 很多功能还在开发阶段,还没有发布正式版本,相比EXT4或其它更成熟的文件系统,它在技术方面的优势包括丰富的特征,如:支持子卷、快照、文件系统内置压缩和内置RAID支持等。
  • 不支持页缓存共享,N个容器访问相同的文件需要缓存N次。不适合高密度容器场景。
  • 当前Btrfs版本使用“small writes”,导致性能问题。并且需要使用Btrfs原生命令btrfs filesys show替代df。
  • Btrfs使用“journaling”写数据到磁盘,这将影响顺序写的性能。
  • Btrfs文件系统会有碎片,导致性能问题。当前Btrfs版本,能通过mount时指定autodefrag 做检测随机写和碎片整理。
  • ##ZFSZFS文件系统是一个革命性的全新的文件系统,它从根本上改变了文件系统的管理方式,ZFS 完全抛弃了“卷管理”,不再创建虚拟的卷,而是把所有设备集中到一个存储池中来进行管理,用“存储池”的概念来管理物理存储空间。过去,文件系统都是构建在物理设备之上的。为了管理这些物理设备,并为数据提供冗余,“卷管理”的概念提供了一个单设备的映像。而ZFS创建在虚拟的,被称为“zpools”的存储池之上。每个存储池由若干虚拟设备(virtual devices,vdevs)组成。这些虚拟设备可以是原始磁盘,也可能是一个RAID1镜像设备,或是非标准RAID等级的多磁盘组。于是zpool上的文件系统可以使用这些虚拟设备的总存储容量。Docker的ZFS利用snapshots和clones,它们是ZFS的实时拷贝,snapshots是只读的,clones是读写的,clones从snapshot创建。下面看一下在Docker里ZFS的使用。首先从zpool里分配一个ZFS文件系统给镜像的基础层,而其他镜像层则是这个ZFS文件系统快照的克隆,快照是只读的,而克隆是可写的,当容器启动时则在镜像的最顶层生成一个可写层。如下图所示:
    10.jpg
    分析[list=1]
  • ZFS同 Btrfs类似是下一代文件系统。ZFS在Linux(ZoL)port是成熟的,但不推荐在生产环境上使用Docker的 ZFS存储方式,除非你有ZFS文件系统的经验。
  • 警惕ZFS内存问题,因为,ZFS最初是为了有大量内存的Sun Solaris服务器而设计 。
  • ZFS的“deduplication”特性,因为占用大量内存,推荐关掉。但如果使用SAN,NAS或者其他硬盘RAID技术,可以继续使用此特性。
  • ZFS caching特性适合高密度场景。
  • ZFS的128K块写,intent log及延迟写可以减少碎片产生。
  • 和ZFS FUSE实现对比,推荐使用Linux原生ZFS驱动。
  • #第四部分 总结另外,下图列出Docker各种存储方式的优点缺点:
    12.png
    以上是五种Docker存储方式的介绍及分析,以此为理论依据,选择自己的Docker存储方式。同时可以做一些验证测试:如IO性能测试,以此确定适合自己应用场景的存储方式。同时,有两点值得提出:[list=1]
  • 使用SSD(Solid State Devices)存储,提高性能。
  • 考虑使用数据卷挂载提高性能。

  • 以上内容根据2016年9月29日晚微信群分享内容整理。分享人范彬,数人云架构师,曾在惠普CMS研发中心及毕益辉WebLogic组工作多年,在Java,J2EE,SOA,企业应用等方面的研发工作 中积累了丰富的经验。对 Docker,Mesos 有所研究,熟悉和热爱云计算、分布式等领域相关技术。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

    DockOne微信分享(六十八):应用容器env化实战

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

    【编者的话】随着Docker技术的火热发展, Docker在代码构建发布中扮演着越来越重要的角色。Docker让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到流行的Linux机器上。Docker非常适用于如下场景: ...查看全部
    【编者的话】随着Docker技术的火热发展, Docker在代码构建发布中扮演着越来越重要的角色。Docker让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到流行的Linux机器上。Docker非常适用于如下场景:

    • 应用容器的自动化打包和发布;
    • 自动化测试和持续集成、发布;
    这次主要和大家聊聊应用容器在配置管理中遇到的问题。首先是介绍现有容器常用的配置文件加载方式,接下来重点介绍数人云组件在自动化打包和发布遇到的问题和解决方法。#现有的主要Docker加载配置的方式首先简单介绍下现有容器的加载配置文件的方式。
    • 挂载宿主机配置文件的方式
    通过docker run -v 参数将宿主机上的配置文件挂载到容器指定目录中如:
    docker run -v /myredis/conf/redis.conf:/usr/local/etc/redis/redis.conf --name myredis redis redis-server /usr/local/etc/redis/redis.conf
    这种方式对于单实例应用比较方便。
    • 下载配置中心文件的方式
    这种方法首先需要建立配置中心,例如用Nginx等Web服务组件,提前将配置文件放在指定目录,在Dokcerfile entrypoint中拉取配置中心文件的脚本,之后容器启动就自动拉取配置中心的配置。
    • 通过环境变量传入到容器中
    通过docker run -e 参数将将环境变量传入到容器如:
    docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:5.6
    #应用容器的自动化打包和发布中遇到的问题数人云组件采用微服务架构,将服务拆分,分别采用相对独立的服务对各方面进行管理,彼此之间使用统一的接口来进行交流,架构变得复杂,但优势非常明显。为了保证高可用,这些容器一般都运行在多个VM上,服务实例前是一层诸如HAPROXY的负载均衡器,它们负责在各个实例间分发请求。数人云分测试、演示、生产三种环境进行持续集成、发布,同时数人云组件通过Docker+Mesos+Marathon进行应用容器的封装下发和管理。首先说下我们容器发布遇到的问题——配置文件多,如何进行统一的管理?我们由于采用微服务架构,就产生了各个模块的配置,导致配置文件过多;其次数人云的三套环境,如MySQL等基础组件IP、Port等配置不同,导致配置成倍增加;最后采用高可用架构,也造成了配置文件的增多。 下面是数人云Mesos系统架构流程图:
    1.png
    Marathon、Jenkins作为Framework注册在mesos-master上,动态调度mesos-slave资源。
    • Marathon负责应用的发布
    • Jenkins负责代码打包、镜像构建
    Mesos Framework截图如下:
    2.png
    若单纯-v的挂载方式需提前将配置文件放在mesos-slave所在的宿主机上,新加slave时也需进行相同的操作,且当配置文件需要更新时,需更新每台mesos-slave宿主机上的配置文件,这显然不够灵活,所以我们刚开始采用应用容器启动下载配置中心文件的方式。早期的配置中心,如下图所示:
    3.png
    此时存在的问题有:
    • 因为是多种环境,虽然把这些配置都在Configserver上集中配置,但是需要手动修改这些配置。手动修改容易出错,例如Dev更新了一个服务,可能过了一周才会更新到生产环境。那个时候再去修改生产就很容易出错,导致无法运行。
    • 如果配置发生了Bug需要回滚,手动修改也是不合适的。
    我们进行了改进,引进Jenkins后工作流程如下图:
    4.png
    我们用Jenkins把它们整体串起来,我们的第一个工作是把所有的配置文件抽象化,各种环境的文件抽象出来一个模板,放在GitLab上。它的数据是放在数据库里面,这样组合起来是一个完整的配置文件。各个环境的值是不一样的。 我们的运维平台触发Jenkins,Jenkins去调度我们的ConfigCenter API,它传入两个参数,一个是需要更新的环境,另一个是更新哪个服务。之后API去做对比,从数据库去读现有的配置文件的模板Tag,再去读新模板的Tag进行对比。如果这个文件需要更新,把它从数据库拉过来,数据做匹配,渲染成我们最终的配置文件,再传到Gitlab上。剩下的通过Jenkins 触发 Configserver去调Gitlab下载最新的配置文件到Configserver服务器,Jenkins再去调用Marathon去重启服务,服务就会成功更新配置文件。 这很好解决了配置文件对应文件,但还是存在以下一些问题:
    • 配置格式不统一,配置有env 、congfig.js 、.yaml 、.xml 等配置文件,各种配置文件需要在应用容器发布前进行替换,当新增配置文件项时,需重新编写模版,替换匹配内容较为繁琐。
    • Marathon发布应用采用了配置文件的方式,在Marathon界面看不到配置文件的内容,需后台查看,增加了运维复杂度。
    后来我们对应用进行env化改造,统一配置文件格式,且配置通过变量传递给Marathon,使得所有配置在Marathon界面上可见 。以下是具体的工作,我们对开发进行了规约。#产品模块GitHub目录规约结构除了代码和产品开发的一些文件外,还需要规约一下目录结构:
    module_name -              |               - deploy -                        |                        - env                          |                        - deploy-marathon.sh                        |                        - compile.sh               |                - dockerfiles -                             |                             - Dockerfile_compile_env                             |                             - Dockerfile_runtime
    在GitHub中更新env文件,这个由开发提供维护,里面有对应env文件如下图:
    5.png
    改进后具体的流程图如下:
    6.png
    以上主要对配置文件进行env化,减少配置替换复杂度,将配置存在于Marathon发布脚本中。更新后产生的marathon applist:
    7.png
    单个应用容器配置:
    8.png
    • 采用env化有助于配置文件的统一维护和管理,新版Marathon很好的支持了应用的更新和回滚,除去了容器启动对静态配置文件的依赖,使应用容器更新发布、回滚更加方便。从界面上可以看到所有容器配置信息,使排错管理也变得方便。
    • 线下数人云企业版组件采用和线上相同的镜像和env变量,通过API获取对应版本的envfile和Docker镜像,之后将所有配置文件抽离到一个配置文件中,实施的同事只需修改这张配置文件,从而省去修改其他配置文件的步骤,使得实施过程更加简单。

    以上就是数人云组件配置管理碰到的问题,以及env化解决方式,欢迎大家提出宝贵意见。
    #Q&A

    Q:Mesos运行一个任务,如果发现该任务运行过程中需要加大资源,Mesos如何做到对任务资源的弹性扩容?如果采用Docker的话,是新建更多的Docker容器还是直接扩大现有Docker的大小?

    A:一般是扩展更多的Docker容器个数,除非是某个任务有最小资源要求,才要扩大单个Docker的大小。



    Q:开发人员使用的本地环境变量如何管理?例如一个应用,有数据库,有搜索引擎,还有两个Java APP,不同开发可能需要嗯环境不同,例如我是搜索功能的开发,需要链接公共的数据库,而有些开发需要自己有数据库,搜索引擎却需要链接公共的。这种配置,如何管理?

    A:这种最好将数据库环境变了进行区分,配置两个或多个类似环境变量。



    Q:请问MySQL数据库怎么随Docker迁移?备份和恢复有什么好的建议吗?

    A:MySQL现在是固定主机主从同步,没有对MySQL做迁移,我们的数据现在备份是定时全备份,正在尝试使用MariaDB集群Galera Cluster ,但还没有上生产,当然有共享存储的话就最好不过啦。



    Q:请问线上服务更新war包,如何能使对外服务不间断吗?

    A:数人云目前采用代码版本和镜像版本统一,对外服务不间断,数人云目前的做法是对应用进行无状态改造,后通过marathon put更新容器。



    Q:请问 配置文件的话生产环境和开发环境怎么区分?

    A:生产环境和测试环境都是隔离的,配置文件配置不同的参数即可。



    Q:请问对类似Java应用jdbc、spring.xml等配置文件如何管理?

    A:XML配置 通过sed替换传入的环境变量。



    Q:生产上配置项变更怎么操作?

    A:生产配置的值需要修改时 ,在configcenter页面中修改,再触发Jenkins更新配置文件的job, 生产新的配置文件 ,再调用marathon API 更新task进行更新。



    Q:业务的配置是和环境配置放在一起的么?

    A:是的,都是通过envfile进行统一的。



    Q:请问你们针对应用弹性扩展是自感应的吗?如果是,请问是基于什么策略做的,监控报警还是什么?

    A:数人云是通过监控报警触发弹性扩展的,如监控接口返回的时间,容器内存使用率等。



    Q:请问你们对环境变量是采用什么样的管理方法?有相应的命名规范吗?环境变量多了,会出现管理方面的问题吧。

    A:环境变量键值由开发维护,运维需要提前了解新增环境变量,目前在配置中心里维护,容器环境变量变量命名规范很重要,我们目前采用服务名+需连接的组件名+属性 进行命名的,且环境变量全部大写。



    以上内容根据2016年7月14日晚微信群分享内容整理。分享人方志浩,92年的程序猿,毕业之后一直在数人云,对 Docker 和 Mesos 有深入研究,目前做数人云平台打包部署以及部分客户项目实施工作,喜欢在实践中尝试新事物并总结。 DockOne每周都会组织定向的技术分享,欢迎感兴趣的同学加微信:liyingjiesz,进群参与,您有想听的话题或者想分享的话题都可以给我们留言。

    如何利用Mesos与Marathon最大程度发掘AWS公有云潜能

    Dataman数人科技 发表了文章 • 1 个评论 • 5146 次浏览 • 2015-11-21 20:59 • 来自相关话题

    【编者的话】Mesos往往以其在大规模生产环境下的成熟案例为大家所熟知。但其实Mesos对于互联网初创企业也是非常有用的。最显著的一点就是:从一开始就使用基于Mesos的云操作系统,让一套IT构架就能支撑不同阶段业务的飞速发展。并让技术人员更关注业务,而不是把 ...查看全部
    【编者的话】Mesos往往以其在大规模生产环境下的成熟案例为大家所熟知。但其实Mesos对于互联网初创企业也是非常有用的。最显著的一点就是:从一开始就使用基于Mesos的云操作系统,让一套IT构架就能支撑不同阶段业务的飞速发展。并让技术人员更关注业务,而不是把精力花在服务器配置上。借用Rahman的一句话,"只要大家拥有一台以上的服务器,都有理由来尝试云操作系统。"

    美国初创公司Mattermark采用Mesos技术

    Mattermark是一家专门面向私营企业交付数据的高人气初创企业。作为初创公司,其IT基础设施规模还是相对较小的。不过正是凭借着这种初创特质,其也得以顺利摆脱了众多规模更大且更为成熟的企业所难以解决的运营效率低下难题。与众多大型企业一样,Mattermark公司同样使用Apache Mesos以及Marathon框架来解决自身面对的独特问题。

    这家诞生刚刚两年的年轻公司,仅仅运行着一些Amazon Web Services实例,存储着GB级别大小的数据,却认为他们的IT架构已经变得不可为继,会在不远的将来影响业务的发展。在这方面,最突出的实际难题就是数据处理任务,特别是Mattermark在日常运营当中不可避免的大量数据挖掘、机器学习以及索引工作——过去,这些工作一直在以缺乏充分理论指导的随意方式进行。

    “我们拥有大量运行着重要工作内容的EC2实例,但没人了解其具体运行机制,”Mattermark公司机器学习工程师Samiur Rahman解释称。“这确实非常麻烦。”

    该公司的管理层意识到,要想真正为各私营企业客户提供可靠的数据源,必须要对现有运营机制进行整顿。“我们很清楚,未来的一到两年内公司规模会出现持续扩张,”Rahman表示。“所以我们要么继续安于现有环境并不断加以构建,要么就像其它企业那样全盘淘汰现有设施并直接向现代基础设施转移。”

    利用Mesos进行基础设施调度

    Mattermark公司在几个月之前决定利用Mesos对自身基础设施进行重新设计,而且同时针对新系统提供了几项必须能够实现的特殊要求:

    * 需要在开发人员与公司AWS实例之间建立一套抽象层。
    * 能够将任务分发至不同的AWS实例当中。
    * 能够根据特定任务的实际需要为其分配对应资源。
    * 面向任务调度实现高度细化的控制机制。
    * 对资源进行隔离以避免相邻实例争夺资源的问题。

    该公司目前在Mesos之上运行有Chronos与Marathon,而此举已经带来了理想的回报。Mattermark公司如今能够以受控方式对批量任务进行调度,同时以智能化方式将不同类型的任务运行在同一资源池中,从而提高AWS的资源利用率。举例来讲,其能够将多个低资源型网页获取任务与其它内存与CPU使用率较高的机器学习任务运行在同一个实例当中。

    “能够切实完成此类资源分配(即允许这些工作负载在同一资源之上共存)的解决方案非常重要,”Rahman指出。如此一来,Mattermark公司不仅能够通过一套可靠的方式实现任务流程自动化,同时也能够在工作效果不变的前提下减少AWS实例使用量并由此降低使用成本。

    相较于以往的服务器监控最佳实践,即企业需要从起始阶段就要考虑到资源占用率趋近100%时的应对措施,“我们的监控机制有所不同,因为如今80%到90%才是理想的资源利用率,”他解释道。“这意味着我们能够更加充分地利用已有资源。”

    尽管Mattermark公司目前仍有一部分工作负载运行在由Elastic Load Balancer支持的AWS裸机实例当中(即非Mesos工作节点),但Rahman强调称那些需要高可用性保障的任务已经运行在Mesos-Marathon环境之内。随着Mattermark公司不断推出新的工作负载与任务类型,其也将全部由新系统负责承载。

    “我们致力于让各类工作负载与任务运行在Mesos当中,”他指出。而且由于Mattermark公司已经开始广泛利用预配置Docker容器作为应用程序运行环境,其目前能够以相对简单的方式完成各类进程由纯AWS实例迁移至运行在AWS实例之上的Mesos集群中的工作。

    以“积极态度”迎接大数据挑战

    不过就Mattermark公司的情况而言,Mesos的真正价值在于允许其保持基础设施规模与业务发展同步扩张——反之亦然。换言之,让IT资源随着业务的发展而平滑增加,这样既不会让IT架构成为业务发展的瓶颈,也不会因需要预留大量IT资源而造成浪费。

    尽管目前规模仅为150 GB的MySQL数据库很难被定义为“大数据”,但Rahman表示Mattermark公司计划在未来几年当中对其规模进行显著拓展。而其中最突出的理由就是,Mattermark公司的从业时间越长,其需要在数据库内为每家企业客户保存的数据量也就越大。

    但从更具战略意义的角度出发,Mattermark公司希望能够将其数据库涵盖能力由100万家企业扩展到全球范围内的数亿家企业。随着企业客户数量的增长,其当然也希望为每位客户提供更加丰富的数据类型——包括员工数量、网站流量、融资信息、相关新闻以及社交媒体关注度等等。

    “我们的业务规模取决于我们实现数据更新的速度以及将更多企业客户纳入数据库的能力,”Rahman指出。

    在他看来,Mesos能够从多个角度带来助益,使得Mattermark公司更为轻松地引入各类必要的新型数据处理技术,包括Kafka以及Spark等,并在运行大规模处理任务时快速添加对应容量。总而言之,该公司在基础设施与任务之间的契合度方面投入的精力越少,那么其专注于在正确时间对正确数据进行访问、分析以及交付的能力也就越强。

    初创公司也要勇于尝试Mesos或数据中心操作系统

    着眼于未来,Rahman表示他希望看到Mattermark公司将运营体系由开源Mesos迁移至Mesosphere数据中心操作系统(国内的朋友可以选择数人云哦),这在很大程度上意味着摆脱软件组件更新以及漏洞修复等工作带来的困扰。尽管目前尚在对DCOS的Early Access版本进行早期实验,但他已经可以在30分钟之内设置起一套以往通常需要数个星期才能搭建完成的系统。

    “初创企业应该了解DCOS,因为它能够让运营工作变得更为轻松,”他解释称。另外,初创企业不必因为的自己运营规模并不像Yelp、苹果或者是Twitter那么庞大,而害怕尝试DCOS或者是开源Mesos组件。

    “Mesos天然具备的开发者自由空间与良好运营效率让我们从系统重新设计当中获得了切实回报,”Rahman总结称。“只要大家拥有一台以上的服务器,都有理由在这方面做出尝试。”
    “我们希望运营体系能够时刻为规模伸缩做好准备,从而帮助我们获取更多数据并从其中发掘出更多有价值信息,”Rahman表示。“另外,我们也希望能够继续保持向客户交付数据的速度。”

    转自:如何利用Mesos与Marathon最大程度发掘AWS公有云潜能

    英文原文:https://mesosphere.com/blog/2015/10/27/mattermark-mesos-aws/

    美国电信巨头Verizon基于Mesos和容器的实践经验

    Dataman数人科技 发表了文章 • 0 个评论 • 6436 次浏览 • 2015-09-08 18:43 • 来自相关话题

    【编者的话】本文主要介绍了电信巨头Verizon是如何通过使用Mesos和容器技术,将其原来的数据中心变成自动化、高利用率、高运营效率的现代化数据中心。据称其数据中心的资源利用率可以提高到50%~60%,并且现场演示了在72秒内部署50000个Docker容器 ...查看全部
    【编者的话】本文主要介绍了电信巨头Verizon是如何通过使用Mesos和容器技术,将其原来的数据中心变成自动化、高利用率、高运营效率的现代化数据中心。据称其数据中心的资源利用率可以提高到50%~60%,并且现场演示了在72秒内部署50000个Docker容器,使得应用集群部署的效率至少提高了一个数量级。
    verizon.png

    # Verizon选择Mesos技术的来龙去脉
    世界上的互联网巨头们(Google、Facebook)已经在过去的十年中将其基础构架搭建为统一的整体,并不断提高其数据中心的运行效率。正是有了这样的刺激,商业上的创新才会被激发出来。

    即使是像Verizon这样,虽然它的通信和服务器托管部门对于管理海量的服务器、存储和网络并不陌生(更不用提保障其运行),也逐渐认识到建造一个更自动化的数据中心比一个更大的要好。

    大概一年多以前,我们看到了源自于搜索引擎巨头Google的大型基础架构的集群管理工具和容器技术。Verizon Labs作为价值1270亿的通信巨头Verizon的研发中心,并不仅仅是对新的集群管理工具感兴趣。Larry Rau,Verizon Labs的技术总监,被公司选出来负责建立一个与时俱进的基础架构。通过大量的调研和测试,Verizon Labs最终选择了Mesos集群管理和应用框架,并开始在上面推出和运行多种类型的服务。

    电信公司在技术领域是一个保守和激进的综合体,他们一直都是这样。因为在互联网巨头出现之前,电话通信交换网络及其计费系统已经承担了这个星球上最大的任务量。(这就是为什么C语言编译器和UNIX操作系统都诞生在AT&T贝尔实验室)历史上,电信公司总是对网络技术过度雕琢,以确保整个网络的高可用。这其实占据了大量的资金,并产生了许多闲置——低利用率的计算和存储资源,最终带来了整个运营的低效率。为了改变这种现状,Verizon选择了Docker容器技术以及用来管理Docker容器及服务器集群的Mesos技术。

    我们最终建立起了一种以Linux为核心,加上由遍布数据中心的普通服务器构成的技术栈。所有这些服务器都大同小异,这样就可以节约整体的硬件和维护成本。



    Rau 在Verizon Labs的新产品小组工作。这个小组的使命就是找出更好的基础设施架构来支撑Verizon网络上的数以万计的工作任务。在智能手机和平板电脑的时代,电信公司不再仅仅是提供语音和数据服务,他们还提供面向用户的应用托管业务,以及一些Verizon内部服务——用来管理用户和他们托管的应用。正如你所预料的,这些应用的重要性一点都不比传统的通信业务差。Rau告诉我们,Verizon需要像其他那些互联网巨头一样动态的去缩放他们的一些应用,所以基础架构必须要做出改变了。

    Rau说到“我发现我们现在的做法还是很传统的电信运营商做法:你创建一个应用,估算其规模,申请一堆的服务器,在数据中心找一个地方,花费大量的时间把这个应用安装部署好。并且每次更新这个应用时,你都会遇到一堆的问题和麻烦。我们认为我们现在必须改变这些做法了,我们需要更快速的行动,自动调整容量,降低我们的运营成本,并增加我们整体的系统投资回报率,而不是运行着一个个的计算资源孤岛”。

    这些经验教训是每一个数据中心管理员最终都会领悟到的,但这并不意味着我们找一个更好的集群管理工具就够了。就算是Mesos,或者Mesosphere所说的数据中心操作系统这样,在一个集群里以一种安全的方式运行多个工作任务,也还是不够的。一旦你开始考虑如何管理应用,你就需要考虑如何提供隔离能力,如何进行软件打包,如何为这些应用分配资源,这个时候你就需要容器技术了。

    “我们沿着这个思路,最终发现我们必须把整个数据中心作为一个整体的硬件资源池来看”Rau说“我们希望部署应用后,系统会自动找到合适的地方来运行这些应用,这个概念就是将整个数据中心当做一台电脑来看。这使得我们继续思考,我们到底想如何构建我们的应用呢?对就是使用容器技术。我们希望通过容器来构建我们的应用,并将其直接运行在我们的裸机硬件资源上。这些因为是Verizon内部数据中心上运行的自有应用,我们并不需要像公有云一样使用虚拟化技术来提供一些多租户环境。对这些做智能管理的需求将我们引到了Apache Mesos这个开源技术。我们最终建立起了一种以Linux为核心,由普通服务器组成的数据中心。这样就可以节约整体的硬件和维护成本。”

    Verizon 最终打造的系统就好像Google创建的Borg集群系统一样。Google在十年前就开始在他们自己的Linux操作系统上部署容器了,并通过Borg来管理这些容器。

    “我们想做的就是一个类似Google的模式。像Google一样建设基础设施架构,创建自己的系统,并让开发者将自己的应用部署在这些系统上。”Rau 说到 “最终我们就是建立了一个资源池,并将这个资源池作为一个整体来看待。同时也可以让我们更快的去部署应用。我们不用再去关心硬件或数据中心的机柜了。我们开发一个应用,运行它就可以了。我们可以做更多的创新,尝试更多的东西,并让部署更快一些。能做到这些,完全是因为你再不需要去做一个18个月的项目,花费大量的资金,仅仅是推出这个应用或服务,并猜测它是如何运作的。现在我们仅仅需要尝试一个服务,看它是如何发展的,并根据其发展情况,再通过平台扩展这个应用。一旦我们我们部署并运行一个应用,我们也可以很快的去更新它。”
    # Verizon 能节省多少时间和金钱?
    就像你猜到的一样,Verizon 不会透露使用Mesos和Docker技术将会获得多大的预期收益。不过Rau表示,根据一些传闻和使用类似平台的人所说的情况来看,效果会是非常显著的。

    硬件方面Verizon会节省大量的成本。现在应用部署的方式是这样的,业务线想要推出一些新的服务,需要先做一个三年期的计划,并尽其所能的猜测他们的业务峰值是在什么时间点,因什么而起的。因为是电信级业务,你必须为这个应用建立冗余的基础架构。更进一步,还需要建立基于地理位置的冗余架构,从而让这个应用能够达到5个9的高可用性。这就意味着Verizon需要在一个服务刚刚推出时就购买大量的硬件,以便支撑未来这个业务有可能达到的规模。我们猜想,Google在90年代到00年代爆发式增长期间,也同样遇到了这些问题,并在交了这些学费后,最终创造出了LXC容器和Borg系统。

    "当Verizon推出一个新业务时,因为我们有集群闲置资源,我们就不需要立即给这个新业务一个三年预期规模的相关资源。这可以让我们根据所有应用的运营情况来增加我们的硬件投入,我们可以按季度扩展我们的集群规模。这种方法还可以使我们的计划更具体和有效。这是因为我们可以参考集群的历史数据,看我们具体有哪些应用上云,或者从云上下线了,从而将硬件采购做的更好,更加合理。"

    最终我们就是建立了一个资源池,并将它作为一个整体来看待,同时也可以让我们更快的去部署应用。我们不用再去关心硬件或数据中心的机柜了。我们开发一个应用,然后运行它就可以了。我们可以做更多的创新,尝试更多的东西,并让部署更快一些。而不再需要去做一个18个月的项目,花费大量的资金,仅仅是推出这个应用或服务,并猜测它是如何运作的。



    这正是Google们所做的事情。为成百上千个单独运行在独立的主机或小集群上的协调分配资源是非常困难的,与其相比,将大量的任务在一个集群里面协调资源就要容易的多了。此外,提高一个大规模集群的资源利用率要比提高好几个小规模集群的资源利用率要容易的多。这就是Google他们学到的教训,这也就是为什么他们尽可能的使用同样的硬件和软件的构建集群的原因。

    虽然人们不讨论其具体细节,我们知道企业级数据中心的服务器资源利用率一般是在10%~20%之间。通过使用虚拟化技术和容器技术,公司可以将不同的多个工作任务运行在同一个机器上,这样就有可能将服务器的资源利用率提高到50%~60%。Rau说这是他们跑出来的数字。

    Mesosphere声称DCOS可以将整个集群的资源利用率提高2~3倍,一些情况下甚至可以提高5倍。当你运行着数万台,甚至数十万台服务器时,这些就是惊人的数字了。这意味着公司可以部署更多的基础设施来提高其应用的底层资源,并且规范服务器的类型和规格。另外,Mesos最终可以具备超购的能力,可以将资源利用率提升的更高。感谢Quasar项目。这意味着一些客户甚至可以在不给集群带来太多问题的情况下,将资源利用率提升至75%~80%。

    Lau没有透露Verizon的硬件计划,但他表示他们的目标是效仿互联网巨头并得到由"廉价的、单一的硬件设备组成的数据中心" 。这并不意味着我们必须让服务器、存储和交换机都遵循由Facebook在五年前建立的 Open Compute Project。好比是服务器厂商专门为Google们所设计的产品,Dell期望通过上周宣布的“可扩展的数据中心解决方案部门”来将这些定制硬件卖给类似Verizon这样的客户。虽然Mesos已经部署在了一些已有的机器上,但Verizon的想法是在新的硬件上为新任务建立Mesos集群。过几年老的系统从原有硬件集群上退役后,这些硬件集群将被升级,最终Mesos将接管一切。

    采用Mesos技术不仅仅是节约了硬件资源,也同时节约了大量的时间。最近在西雅图召开的MesosCon上,Verizon像大家展示了他们是如何在72秒内创建50000个Docker容器。(数人科技在infoQ主办的容器大会上,演示了如何在数人云上在数十秒内启动运行10000个Docker容器)Verizon相信这样的速度,自动化管理容器和底层集群,可以让应用部署的速度提高一个数量级。

    Verizon计划今年就在其Mesos集群上运行一些服务。第一批将被迁移到Mesos集群上的服务包括无线网络支撑系统和一些移动应用的后台,以及FiOS网络支撑系统(光纤到户)。Mesos也将用来支持IoT服务,包括多媒体服务、视频流媒体服务等等。Verizon还计划将其Hadoop和Spark分析任务从他们的专属集群上迁移到Mesos集群。
    # Verizon的具体容器技术选型
    系统采用的容器技术,Verizon预计会选择Docker,而不是Kubernetes(Google开源)的Podding方案。Verizon计划采用Mesos自带的容器功能和Docker Daemons 来管理用容器进行打包部署的应用软件。Verizon也查看了CoreOS和rkt容器,以及它的Tectonic 容器管理系统(基于Kubernetes)。Verizon可能也会在某些场景下使用rkt容器,甚至是Linux的LXC容器。

    "容器技术是非常成熟的,他已经存在了很长时间,Docker让容器技术更加易用了。我认为打包的形式让你可以将应用作为一个整体来看待" Rau 在谈Docker格式的容器技术 "Mesos有其自己的容器,他可以使用Linux容器,他们的namespaces,和contral group并与Docker守护进程通信,发布任务,这就是我们现在所做的方式。我并不是说我们会仅仅只使用Docker,但事实上Docker镜像格式和标准,已经成为了关键性的组件"

    另外,Kubernetes可以作为一个框架运行在Mesos之上,所以Verizon如果需要的话,也有可能使用Kubernetes。

    原文链接:Verizon Satisfies Google Envy With Mesos (翻译:郭卿)

    ============================================
    译者介绍
    郭卿,数人科技市场负责人,毕业于北京理工大学计算机系,专注于Mesos技术在企业的应用和推广。


    720.png

    我在Mesos上运行Docker容器的经验

    Dataman数人科技 发表了文章 • 2 个评论 • 5998 次浏览 • 2015-07-07 15:52 • 来自相关话题

    【编者的话】下面的这篇博客出自John Omernik之手,他是Big Data Analytics的Data Enthusiast和VP,还是Zions Bank的Fraud Center of Excellence的经理,Zions Bank是家顶级的金融 ...查看全部
    【编者的话】下面的这篇博客出自John Omernik之手,他是Big Data Analytics的Data Enthusiast和VP,还是Zions Bank的Fraud Center of Excellence的经理,Zions Bank是家顶级的金融服务公司。在这篇博客中,作者分享了他是怎么利用新技术如Mesos和Docker来使用MapR文件系统的,并编写了一个可以简化流程的脚本。
    #我的技术栈
    正如在此博客中我所写到的,我想和你分享我如何在一个单集群中使用Docker容器来运行分析作业。我们在Zions研究这个技术(当然,我也会在家运行它),该技术是在MapR平台和[MapR-FS][2]之上运行的Apache Mesos。我的目标是尝试构建一个无处不在的计算平台。为了分析,我运行了Spark和[Myriad]。我用Myriad来运行MapReduce作业。我将Kafka和Storm同时运行于Mesos,与MapR文件系统一起使用,或跟当前环境协同使用。
    apache-mesos-logo.jpg

    当在Mesos上运行Docker容器时,MapR会提供了极大的帮助。有一个例子是我在Docker内部运行的服务,这个服务是Hive metastore服务。因为Hive metastore需要一个关系型数据库来持久化表的元数据,其需要我同时部署一个MySQL服务实例。我在一个基于Mesos的Docker内通过Marathon来发布该实例,而不是在集群之外的独立服务器上部署MySQL。由于MySQL存储的数据非常重要,我想确认如果容器崩溃或其宿主机死掉,Marathon是否可以创建新的容器并接管其离线的所有完好的数据。MapR-FS的NFS功能可以很容易实现这点,因为它有随机读写的能力并且能为一个数据库维持负载的高性能。
    #利用MapR文件系统
    一个需要我解决的问题是当一个MySQL数据库被启用,需要对数据库文件进行独占访问。我想要预防另一个Docker容器的意外启动,而产生对数据库文件的访问,这是因为如果你想要你的数据库文件保持完整性,那么有两个MySQL实例访问相同的文件将不是一个好事。所以我对这个问题进行了深入研究,并同Ted Dunning和Keys Botzum在MapR上开始了研究,我请教他们,“我如何使用一个锁?” 尽管从传统的Unix角度看,MapR NFS不支持锁定,但MapR却支持启用锁定的文件系统标准,这种锁定是通过创建目录和新建文件来启用。

    听取了他们的建议,我写了一个脚本,实现了锁定模式,这种模式允许可靠的持久性数据存储。这就意味着别人也可以从中获得好处,所以我将该脚本分享于此。

    这里分为两部分,第一部分是,“我想lock文件并且让其成为独占式的”。这里并不支持,但另一方面,MapR却支持 semantics,它能够创建一个目录并且是唯一一个能够创建该目录的,这也是我在该脚本中所使用的。我想能够创建一些东西,这样我的Docker容器可以检测到并且说,“有其他人正在使用这个数据,我需要关闭。”我的脚本可以阻止拥有两个不同的MySQL实例或Hive Metastore在我的集群之上运行,但我仍然有能力在我的集群的任意节点运行MySQL。这里对其运行在哪没有任何限制。 Mesos社区尝试去解决该问题,其中一种方式是将数据持久化到不同的框架上——所以你可以使用该数据块——并且包含在未来的版本中。但MapR拥有高性能的文件系统,而且在我的所有节点上都可用,因此我想更好的利用它。
    #为Docker容器处理文件系统锁而写的代码
    基本上讲,这段代码就像一个垫片,我调用该代码而不是启用我期望在Mesos中直接启用的任何进程,该代码会检测每个我设定的特定目录。例如,如果是MySQL或Minecraft Docker容器,它会针对每个容器检测一个单独的地址。我的Minecraft服务器在MapR-FS中有一个地址;这正是其检测并决定是否它可以在该目录上拥用一个独占锁并运行。如果它不能够这样做——它发现有些进程也对该目录上锁,它会知晓它不能够运行并关掉该容器。这就保证了我不会有多于一个的 相同类型的Docker容器。我不想两个Minecraft服务器运行,因为他们将工作在相同的数据之上,因而导致文件损坏。

    这里是我为Docker容器处理文件系统锁而写的代码:
     #!/bin/bash

    #The location the lock will be attempted in
    LOCKROOT="/minecraft/lock"
    LOCKDIRNAME="lock"
    LOCKFILENAME="mylock.lck"

    #This is the command to run if we get the lock.
    RUNCMD="./start.sh"

    #Number of seconds to consider the Lock stale, this could be application dependent.
    LOCKTIMEOUT=60
    SLEEPLOOP=30

    LOCKDIR=${LOCKROOT}/${LOCKDIRNAME}
    LOCKFILE=${LOCKDIR}/${LOCKFILENAME}

    if mkdir "${LOCKDIR}" &>/dev/null; then
    echo "No Lockdir. Our lock"
    # This means we created the dir!
    # The lock is ours
    # Run a sleep loop that puts the file in the directory
    while true; do date +%s > $LOCKFILE ; sleep $SLEEPLOOP; done &
    #Now run the real shell scrip
    $RUNCMD
    else
    #Pause to allow another lock to start
    sleep 1
    if [ -e "$LOCKFILE" ]; then
    echo "lock dir and lock file Checking Stats"
    CURTIME=`date +%s`
    FILETIME=`cat $LOCKFILE`
    DIFFTIME=$(($CURTIME-$FILETIME))
    echo "Filetime $FILETIME"
    echo "Curtime $CURTIME"
    echo "Difftime $DIFFTIME"

    if [ "$DIFFTIME" -gt "$LOCKTIMEOUT" ]; then
    echo "Time is greater then Timeout We are taking Lock"
    # We should take the lock! First we remove the current directory because we want to be atomic
    rm -rf $LOCKDIR
    if mkdir "${LOCKDIR}" &>/dev/null; then
    while true; do date +%s > $LOCKFILE ; sleep $SLEEPLOOP; done &
    $RUNCMD
    else
    echo "Cannot Establish Lock file"
    exit 1
    fi
    else
    # The lock is not ours.
    echo "Cannot Estblish Lock file - Active "
    exit 1
    fi
    else
    # We get to be the locker. However, we need to delete the directory and recreate so we can be all atomic about
    rm -rf $LOCKDIR
    if mkdir "${LOCKDIR}" &>/dev/null; then
    while true; do date +%s > $LOCKFILE ; sleep $SLEEPLOOP; done &
    $RUNCMD
    else
    echo "Cannot Establish Lock file - Issue"
    exit 1
    fi
    fi
    fi
    #End

    #在MapR上运行开源软件:支持的非常好
    有些人可能会因为使用一个“混合体”如MapR而担忧。我的意思是你想要运行的大部分工具都将成为开源软件,当然文件系统不会。这正是对开源社区一些人的挑战,因为有些人会想,“我想运行Spark;我想运行如Mesos这样的程序,如果我同时想运行其他的程序如MapR,谁会给我提供支持?谁会帮助我让它运行起来?如果我在标准的Apache HDFS上运行, 从社区的角度上来讲,很多人将会获得帮助。”这正是人们的恐惧之一(当开源与闭源捆绑使用)。

    但我所发现的例子是,MapR可通过资源如answers.mapr.com,也可以通过直接交互与社区很好地融合,如果这里有些事情我不能解决是因为我所需要的代码不存在,MapR总是乐于和我一起工作并帮助我了解将会发生什么。
    #给那些想在MapR之上运行Mesos和Docker的人们一些建议
    最开始确定给予MapR大量的资源,然后把剩下的资源给Mesos。当前, 我倾向于“一半一半”,因为我没有官方安装包,我仅仅是安装了MapR和Mesos,然后讲,“不错,一起运行的很好。”事情已经运作良好,但是我可以直观看到冲突,这取决于我如何调用资源。MapR正在解决某些问题,在不久的将来他们尝试动态的在MapR和Mesos之间合理利用资源。
    #其他在MapR上使用Mesos的有趣项目
    我可以在这里很容易的讲出针对一些科目的议题!我目前所做的与其相关的一些东西非常有趣——在集群上从运行MySQL数据库到运行我孩子的Minecraft服务器,我可以做任何事情。我发现了一件非常神奇的事情——它真的可以做任何事情。我的孩子们非常喜欢它。在VM中运行Minecraft服务器和在集群中的Docker里运行之间没有任何问题。所有的Minecarft世界的数据是通过NFS服务保存于MapR-FS。对于我来说,其真正解决了一个问题,因为MapR能够做到其他技术做不到的一些事情。我不知道HDFS上的文件如何做的随机读写;我并不知道如何在HDFS中运行Minecraft——但我能够用MapR-FS来实现。

    正如我所提到的,我正在通过Mesos,使我个人的家庭网络运行于MapR上,因为这里有很多有趣的方式来使用它。当然,很少有人会做该层面的集成。我这样做了,是因为这可以让我了解MapR和Mesos是如何一起工作的。同时,我使用一个开源的基于linux的DVR,叫做[MythTV][4],它可以让你能够录 TV。 我现在将它运行在一个VM里,并且我的目标是尝试将它运行于我的集群中的Docker里,仅仅是尝试看我是否能够实现。

    我非常享受使用技术比如基于MapR的Mesos和Docker,并且我期望你会发现我为持久化Docker存储而写的这段代码非常有用。

    原文连接:My Experience with Running Docker Containers on Mesos(翻译:张明峰 审校:魏小红)

    ================================================
    译者介绍
    张明锋,数人科技资深DevOps,infrastructure工程师。专注于分布式系统和IDC(系统,网络,存储等)架构。对系统、数据库、网络、存储有深刻了解。日常开发使用Golang、C、C++、Python、Shell。

    [1]: https://www.mapr.com/sites/default/files/styles/320x218/public/apache-mesos-logo.jpg?itok=rg3H_5Lx
    [2]: https://www.mapr.com/blog/comparing-mapr-fs-and-hdfs-nfs-and-snapshots
    [3]: http://www.apache-myriad.org/
    [4]: https://www.mythtv.org/


    720.png

    实录分享 | Mesos PMC 带你回顾 Mesos 2016

    回复

    Dataman数人科技 发起了问题 • 2 人关注 • 0 个回复 • 3325 次浏览 • 2017-02-04 18:35 • 来自相关话题

    数人云容器管理工具 Crane 现已开源

    回复

    icebolt 回复了问题 • 6 人关注 • 4 个回复 • 3232 次浏览 • 2016-12-03 15:26 • 来自相关话题

    Docker对话Swarm,诚邀教官检阅新兵Crane,体验有奖

    回复

    starjason 回复了问题 • 6 人关注 • 6 个回复 • 3734 次浏览 • 2016-09-08 10:46 • 来自相关话题

    【小数乱弹】十多年了,有人终于迎来了春天

    回复

    Dataman数人科技 发起了问题 • 1 人关注 • 0 个回复 • 2598 次浏览 • 2016-07-08 15:55 • 来自相关话题

    从Uber微服务看最佳实践如何炼成?

    Dataman数人科技 发表了文章 • 0 个评论 • 1664 次浏览 • 2018-03-29 01:33 • 来自相关话题

    导读: Uber成长非常迅速,工程师团队快速扩充,据说Uber有2000名工程师,8000个代码仓库,部署了1000多个微服务。微服务架构是Uber应对技术团队快速增长,功能快速上线很出色的解决方案。本文偏向微服务的入门篇,以Uber微服务为例, ...查看全部
    导读:
    Uber成长非常迅速,工程师团队快速扩充,据说Uber有2000名工程师,8000个代码仓库,部署了1000多个微服务。微服务架构是Uber应对技术团队快速增长,功能快速上线很出色的解决方案。本文偏向微服务的入门篇,以Uber微服务为例,进行了深入浅出的讲解。
    微服务特性
    对于微服务没有适当的定义,你可以说它是一个框架,由小型的、独立的可部署的服务组成,执行不同的操作。

    微服务专注于单个业务领域,可以作为完全独立的可部署服务,并在不同的技术栈上实现它们。


    6.png




    单体架构和微服务架构区别

    在使用微服务构建自己的应用程序之前,需要清楚地了解应用程序的范围和功能。


    1.png




    微服务特性

    解耦 - 系统内的服务在很大程度上是解耦的。因此,整个应用程序可以轻松构建,更改和缩放
    组件化 - 微服务被视为独立的组件,可以轻松替换和升级
    业务能力 - 微服务非常简单,专注于单一功能
    自治 - 开发人员和团队可以独立工作,从而提高速度
    持续交付 - 通过软件创建,测试和批准的系统自动化,允许软件的频繁发布
    责任 - 微服务不像项目那样专注于应用程序。相反,他们将应用程序视为他们负责的产品
    分散治理 - 重点在于使用正确的工具来完成正确的作业。这意味着没有标准化模式或任何技术模式。开发人员可以自由选择最有用的工具来解决他们的问题
    敏捷 - 微服务支持敏捷开发。任何新功能都可以快速开发并再次丢弃

    微服务优势

    2.png



    独立开发 - 所有微服务都可以根据各自的功能轻松开发
    独立部署 - 基于各自的服务,可以单独部署在任何应用程序中
    故障隔离 - 即使应用程序的一项服务不起作用,系统仍会继续运行
    混合技术堆栈 - 可以使用不同的语言和技术来构建同一应用程序的不同服务
    细粒度缩放 - 各个组件可根据需要进行扩展,无需将所有组件扩展到一起
    微服务设计最佳实践
    在当今世界,复杂性已经渗透到产品中。微服务架构能够更好地保持团队的规模和功能。

    以下是微服务设计的最佳实践:


    3.png




    现在,让我们来看一个用例来更好地理解微服务。
    案例:购物车应用程序
    当打开购物车应用程序时,你看到的只是一个网站。但是,在幕后,购物车应用程序有接受支付服务、顾客服务等等。

    假设开发人员已经在一个整体框架中进行了创建。如下图:

    4.png




    购物车应用程序的整体框架

    所有功能都放在一个代码库中,并在一个底层数据库下。

    现在,假设市场上出现了一个新品牌,开发人员希望将这个品牌的所有细节都放在这个应用程序中。

    他们不仅要重新为新标签提供服务,还必须重新构建完整的系统并进行相应部署。

    为了应对这种挑战,开发人员决定将其应用程序从单体架构转移到微服务。如下图:

    5.png



    购物车应用程序的微服务架构

    这意味着开发人员不必创建Web微服务,逻辑微服务或数据库微服务。相反,他们为搜索,推荐,客户服务等创建单独的微服务。

    这种应用架构不仅有助于开发人员克服以前架构面临的挑战,还有助于轻松构建,部署和扩展购物车应用程序。

    微服务设计指南

    作为开发人员,决定构建应用程序时,要将各个域分离,并在功能上明确。
    设计的每一个微服务都只专注于应用中的一个服务。
    确保设计的应用程序使每个服务都可以单独部署。
    确保微服务之间的通信是通过无状态服务器完成的。
    每一项服务都可以被推进到更小的服务中,拥有自己的微服务。

    在设计微服务时,已经了解了基本的指导方针,现在来了解一下微服务的架构。

    微服务架构是如何工作的?

    一个典型的微服务架构(MSA)应该包括以下组件:
    1.客户端
    2.身份提供者
    3.API网关
    4.消息格式
    5.数据库
    6.静态内容
    7.管理
    8.服务发现
    如下图:


    7.png



    微服务架构
    这个架构看起来有点复杂,让我们来简化一下。

    1、客户端

    架构始于不同类型的客户端,从不同的设备尝试执行各种管理功能,如搜索、构建、配置等。

    2、身份提供者

    这些来自客户端的请求将传递给身份提供者,这些提供者对客户端的请求进行身份验证,并将请求传递给API网关。然后,请求通过定义良好的API网关与内部服务通信。

    3、API网关

    由于客户端不直接调用服务,因此API网关作为客户端将请求转发到适当的微服务的切入点。

    使用API网关的优点包括:

    •所有服务都可以在客户端不知情的情况下进行更新。
    •服务也可以使用非网络友好的消息传递协议。
    •API网关可执行跨切割功能,如提供安全性、负载均衡等。

    在接收到客户端的请求后,内部架构由微服务组成,这些微服务通过消息相互通信来处理客户端请求。

    4、消息格式

    有两种类型的消息通过它们进行通信:

    •同步消息:在客户端等待服务响应的情况下,微服务通常倾向于使用REST (Representational State Transfer),因为它依赖于无状态、客户端服务器和HTTP协议。这个协议被用作一个分布式环境,每个功能都用一个资源来表示,以执行操作。

    •异步消息:在客户端不等待服务响应的情况下,微服务通常倾向于使用AMQP、STOMP、MQTT等协议。这些协议在这种类型的通信中使用,因为消息的性质被定义,这些消息在实现之间可以互操作。

    下一个问题是,使用微服务的应用程序如何处理数据?

    5、数据处理

    每个微服务都拥有一个专有数据库来捕获它们的数据并实现相应的业务功能。此外,微服务的数据库只通过其服务API进行更新。参考下图:


    8.png



    微服务处理数据演示

    微服务提供的服务被转发到任何支持不同技术栈的进程间通信的远程服务。

    6、静态内容

    在微服务内部进行通信后,将静态内容部署到基于云的存储服务,通过内容交付网络(CDN)直接将其交付给客户端。

    除了上述组件,还有一些其他组件出现在典型的微服务架构中。

    7、管理

    该组件负责平衡节点上的服务和故障识别。

    8、服务发现

    用作微服务的指南,以找到它们之间的通信路由,由它维护节点所在的服务列表。

    现在来看看这个架构的优缺点,以更好地理解何时使用这种架构。

    11.png



    下面来比较一下UBER之前和现在的架构。
    Uber微服务案例
    Uber之前的架构

    像许多初创公司一样,UBER在开始之初在单一城市运营,为单一产品打造了单体架构。当时有一个代码库似乎被清理了,并解决了UBER的核心业务问题。然而,随着UBER在全球范围内扩张,它们在可扩展性和持续集成方面面临各种各样的问题。


    9.png


    UBER的单体架构

    上图描述了UBER之前的架构。

    与乘客和司机连接的REST API。
    三种不同的适配器与API一起使用,当预定出租车时,执行诸如账单、付款、发送电子邮件/消息等操作。
    MySQL数据库存储所有数据。

    因此,可以发现这里所有的特性,比如乘客管理、计费、通知功能、支付、行程管理和驱动管理都是在一个框架内完成的。

    问题陈述

    当Uber开始在世界范围扩张时,这种框架引入了各种各样的挑战。以下是一些突出的挑战。

    所有的功能都必须重新构建、部署和测试,以更新单一功能。
    在单个存储库中修复bug变得非常困难,因为开发人员不得不一次又一次地修改代码。
    在全球范围内引入新功能的同时,要将这些特性进行扩展是相当困难的。

    解决方案

    为了避免此类问题,Uber决定改变自己的架构,效仿亚马逊(Amazon)、Netflix、Twitter等其他超级增长公司。因此,Uber决定将其整体架构拆分为多个代码库,以形成一个微服务架构。

    参考下面的图表,看看Uber的微服务架构。


    10.png



    Uber的微服务架构

    我们在这里看到的主要变化是引入了API网关,所有的司机和乘客都是通过这个网关连接的。从API网关,所有的内部点都连接在一起,如乘客管理、司机管理、行程管理等。
    每个单元是单独的可部署单元,执行单独的功能。例如:如果你想在账单微服务中更改任何内容,那么只需部署账单微服务,而不必部署其他服务。
    所有的功能都是单独扩展的,即每个特征之间的相互依赖被移除。

    例如,我们都知道,搜索出租车的人数比预订出租车和付款的人要多。这就得到了一个推论:在乘客管理微服务上工作的流程的数量超过了处理支付的流程的数量。

    通过这种方式,Uber将其架构从单一业务转移到微服务中获益。


    原文链接:
    1、What Is Microservices – Introduction To MicroserviceArchitecture
    https://www.edureka.co/blog/what-is-microservices/
    2、Microservice Architecture – Learn, Build and Deploy Microservices
    https://www.edureka.co/blog/microservice-architecture/

    换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?

    Dataman数人科技 发表了文章 • 0 个评论 • 1620 次浏览 • 2018-03-21 14:32 • 来自相关话题

    在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营Kubernetes很重要,以及为什么很难。本文是关于Kubernetes bug导致的一小时中断故障的事后剖析。 ...查看全部
    在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营Kubernetes很重要,以及为什么很难。本文是关于Kubernetes bug导致的一小时中断故障的事后剖析。

    为什么选择在Kubernetes之上构建?如何将Kubernetes集成到现有基础设施中?本文作者给出的方法是建立 (和改进) 对Kubernetes集群的可靠性的信任,以及构建在Kubernetes之上的抽象。
    我们最近在Kubernetes之上构建了一个分布式的cron作业调度系统,这是一个令人兴奋的容器编排的新平台。Kubernetes现在非常流行,并且有许多令人兴奋的承诺:最令人兴奋的是,程序员不需要知道或关心他们的应用程序运行的是什么机器。
    什么是Kubernetes?
    Kubernetes是一个分布式系统,用于调度程序在集群中运行。你可以告诉Kubernetes运行一个程序的5个副本,它将在工作节点上动态调度它们。容器自动调度以增加利用率,节省资金,强大的deployment primitives允许逐步推出新的代码,安全上下文和网络策略允许企业以安全的方式运行多租户的工作负载。

    Kubernetes有很多不同类型的调度能力。它可以调度长时间运行的HTTP服务、在集群中每台机器上运行的daemonsets、每小时运行的cron作业等等。
    为什么是Kubernetes?
    每个基础设施项目都是从业务需求开始的,我们的目标是提高现有分布式cron作业系统的可靠性和安全性。我们的要求是:

    建立和运营一支小团队(只有2人在项目中全职工作)。
    在20台机器上可靠地安排大约500个不同的cron作业。

    我们决定在Kubernetes之上建立的几个原因:

    希望构建一个现有的开源项目。
    kubernetes包含一个分布式cron作业调度器,不必自己编写。
    kubernetes是一个非常活跃的项目,经常接受捐赠。
    kubernetes是用Go写的,很容易学。几乎所有Kubernetes的bug都是由团队中没有经验的程序员做的。

    如果我们能够成功地运营Kubernetes,可以在未来的Kubernetes上构建,例如,目前正在开发基于kubernet的系统来训练机器学习模型。

    我们以前使用Chronos作为cron作业调度系统,但它不再是满足可靠性要求,而且大部分都没有维护(在过去9个月中1次提交, 最后一次合并请求的时间是2016年3月))Chronos未维护的,我们认为不值得继续投资改善现有的集群。

    如果你正考虑Kubernetes,请记住:不要仅仅因为其他公司在使用Kubernetes而使用它。建立一个可靠的集群需要花费大量的时间,使用它的业务案例并不是很突出。把你的时间用在聪明的方法上。
    可靠性是什么意思?
    说到运营服务,“可靠”这个词本身并没有什么意义。要讨论可靠性,首先需要建立一个SLO(服务级别目标)。

    我们有三个主要目标:

    99.99%的cron作业应该在预定运行时间的20分钟内开始运行。20分钟是一个很宽的窗口,但是我们采访了内部客户,没有人要求更高的精确度。
    Jobs应该运行99.99%的时间(不被终止)。
    向Kubernetes的迁移不会导致任何面向客户的事件。

    这意味着:

    Kubernetes API的短暂停机时间是可以接受的(如果停机10分钟,只要在5分钟内恢复即可)。
    调度错误(cron作业运行完全丢失并且根本无法运行)是不可接受的。我们非常重视安排错误报告。
    要谨慎对待pod evictions 和安全终止实例,以免作业过于频繁地终止。
    需要一个好的迁移计划。
    建立一个Kubernetes集群
    我们建立第一个Kubernetes集群的基本方法是从零开始构建集群,而不是使用kubeadm或kops之类的工具。使用Puppet(常用的配置管理工具)调配了配置。从头开始构建很好,原因有两个:能够深入地集成Kubernetes在架构中,并且深入理解其内部。

    我们希望将Kubernetes整合到现有的基础架构中。与现有系统无缝集成,以便进行日志记录,证书管理,加密,网络安全,监控,AWS实例管理,部署,数据库代理,内部DNS服务器,配置管理以及更多。整合所有这些系统有时需要一点创造力,但总体上比试图让kubeadm / kops成为我们想要的更容易。

    在信任并了解如何操作这些现有系统后,我们希望继续在新的Kubernetes群集中使用。例如,安全证书管理是一个非常棘手的问题,已经有办法颁发和管理证书。通过适当的整合,我们避免了为Kubernetes创建新的CA。

    准确了解设置的参数是如何影响Kubernetes设置的。例如,在配置用于身份验证的证书/CAs时,使用了超过12个参数。了解这些参数有助于在遇到身份验证问题时更容易调试设置。
    对Kubernetes建立信心
    在Kubernetes之初,团队中没有人使用过Kubernetes。如何从“没有人用过Kubernetes”到“我们有信心在生产中运行Kubernetes”?



    战略0:与其他公司交谈

    我们向其他公司询问了Kubernetes的经历。 他们都以不同的方式或在不同的环境中使用Kubernetes(运行HTTP服务,裸机,Google Kubernetes引擎等)。

    在谈到Kubernetes这样庞大而复杂的系统时,重要的是认真思考自己的用例,做自己的实验,建立对自己环境的信心,并做出决定。 例如,你不该读这篇博客文章并得出结论:“Stripe正在成功使用Kubernetes,所以它也适用于我们!”

    以下是我们在与几家运营Kubernetes集群的公司沟通后后学到的:

    优先考虑企业etcd集群的可靠性(etcd是存储所有Kubernetes集群状态的地方)。
    某些Kubernetes功能比其他功能更稳定,因此请小心Alpha功能。一些公司只有在稳定后才能使用稳定特性(例如,如果某个功能在1.8版本中保持稳定,则在使用它之前会等待1.9或1.10)。
    考虑使用托管的Kubernetes系统,如GKE / AKS / EKS。从头开始建立高可用性Kubernetes系统是一项巨大的工作。 AWS在此项目中没有托管的Kubernetes服务,所以这不适合我们。
    注意由覆盖网络/软件定义网络引入的额外网络延迟。

    策略1:阅读代码。

    我们计划很大程度上依赖于Kubernetes的一个组件,即cronjob控制器。这个组件当时处于alpha阶段,这让我们有点担心。我们在一个测试集群中尝试了它,但是如何判断它在生产中是否适合我们呢?

    值得庆幸的是,所有cronjob控制器的核心功能只有400行Go。通过源代码快速读取显示:

    cron作业控制器是一个无状态的服务(与其他Kubernetes组件一样,除了etcd)。
    每10秒钟,这个控制器调用syncAll函数:go wait.Until(jm.syncAll,10 * time.Second,stopCh)
    syncAll函数从Kubernetes API中获取所有cron作业,遍历该列表,确定下一步应该运行哪些作业,然后启动这些作业。

    核心逻辑似乎相对容易理解。更重要的是,如果在这个控制器中有一个bug,它可能是我们可以修复的东西。

    策略2:做负载测试

    在开始认真构建集群之前,我们做了一些负载测试。我们并不担心Kubernetes集群能够处理多少节点(计划部署大约20个节点),但是确实想让某些Kubernetes能够处理我们希望运行的那么多的cron作业(大约每分钟50个)。

    在一个3节点集群中运行了测试,创建了1000个cron作业,每个任务每分钟运行一次。这些工作中的每一个都简单地运行bash -c 'echo hello world'。我们选择简单的作业,是因为希望测试集群的调度和编排能力,而不是集群的总计算能力。

    测试集群无法处理每分钟1000个cron作业。每个节点每秒最多只能启动一个pod,而集群能够每分钟运行200个cron作业。由于我们只希望每分钟运行大约50个cron作业,所以我们认为这些限制不是阻碍因素。

    策略3:优先构建和测试高可用性etcd集群。

    在设置Kubernetes时,最重要的事情之一就是运行etcd。Etcd是Kubernetes集群的核心,它是存储集群中所有数据的地方。除了etcd之外,其他一切都是无状态的。如果etcd没有运行,不能对Kubernetes集群进行任何更改(尽管现有的服务将继续运行!)

    这张图显示了etcd是Kubernetes集群的核心——API服务器是etcd前面的无状态REST/认证端点,然后其他组件通过API服务器与etcd对话。 在运行时,有两个要点需要牢记:

    设置复制,这样集群不会死如果你失去了一个节点。我们现在有三个etcd副本。
    确保足够的I / O带宽。我们的etcd版本有一个问题,一个具有高fsync延迟的节点可能触发连续的leader elections,导致集群无法使用。通过确保所有节点的I/O带宽都比etcd的写入数量多,从而弥补了这一点。



    设置复制不是一个设置-忘记操作。我们仔细地测试后发现可能会丢失一个etcd节点,并且集群优雅地恢复了。

    以下是为建立etcd集群所做的一些工作:

    设置复制
    监控etcd服务是可用的
    写一些简单的工具,以便轻松创建新的etcd节点,并加入到集群当中
    编写一些简单的工具,以便我们可以轻松创建新的etcd节点并将它们加入到群集中
    补丁etcd的高集成,这样我们可以在生产环境中运行超过1个 etcd集群
    测试从一个etcd备份中恢复
    测试可以在不停机情况下重建整个集群

    很高兴很早就做了这个测试。某个周五的早晨,在我们的生产集群中,一个etcd节点停止了对ping的响应。我们得到了警报,终止了节点,带来了一个新的节点,加入到集群中,同时Kubernetes继续运行。

    策略4:逐步将工作迁移到Kubernetes

    我们的目标之一是将工作迁移到Kubernetes而不造成任何中断。成功进行生产迁移的秘诀不是避免犯错(这是不可能的),而是设计你的迁移以减少错误的影响。

    我们很幸运有多种职位可以迁移到新集群,所以可以迁移一些低影响的工作岗位,接受一两次失败。

    在开始迁移之前,构建了易于使用的工具,如果有必要,可以在不到五分钟的时间内在旧系统和新系统之间来回移动作业。这种简单的工具减少了错误的影响 - 如果迁移一个没有计划的依赖的工作,没有什么大不了的!可以将其移回原处,解决问题,然后再试。

    以下是我们采用的整体迁移策略:

    根据他们的重要程度大致排序
    将一些重复的工作迁移到Kubernetes。如果发现新的情况,快速回滚,修复问题,然后重试。

    策略5:调查 Kubernetes bug 并修复它们

    我们在项目开始时制定了一个规则:如果Kubernetes做了一些意外的事情,必须调查,找出原因,并提出补救措施。

    调查每个问题都很耗时,但很重要。如果只是简单地将Kubernetes的”古怪行为”看作是复杂的分布式系统的功能,我们担心,因为它们会被调用导致产生bug集群。

    在使用了这种方法之后,我们发现并且修复了Kubernetes的几个bug。

    以下是测试中发现的一些问题:

    名称超过52个字符的Cronjob无法安排作业。
    Pods有时会永远停留在挂起状态。
    调度程序会每3个小时崩溃一次。
    Flannel的hostgw后端没有替换过时的路由表项

    修复这些bug让我们对Kubernetes项目的使用感觉好得多——不仅它运行得比较好,而且也接受补丁并有一个良好的PR审查过程。

    Kubernetes有bug,像所有的软件一样。特别是,我们非常频繁地使用调度器(cron作业总是在创建新的pods),而调度器使用缓存有时会导致bug、回退和崩溃。缓存是困难的!但是代码库是可接近的,我们已经能够处理遇到的bug。

    值得一提的是,Kubernetes的pod驱逐逻辑。Kubernetes有一个称为节点控制器的组件,它负责将pod驱逐出去,如果节点没有响应,则将它们移到另一个节点。allnodes会暂时无响应(例如,由于网络或配置问题),在这种情况下,Kubernetes可以终止集群中的所有pod。

    如果运行的是大型Kubernetes集群,请仔细阅读节点控制器文档,仔细地考虑设置,并进行广泛测试。每次通过创建网络分区测试对这些设置的配置更改(例如,pod-驱逐超时),就会发生令人惊讶的事情。最好在测试中发现这些意外,而不是在生产中发现。

    策略6:有意引起Kubernetes集群问题

    之前讨论过在Stripe中进行游戏日练习。这个想法是要想出你最终会在生产中发生的情况,然后在生产中故意造成这些情况,从而确保能够处理它们。

    在集群上进行了几次练习之后,经常发现诸如监视或配置错误等问题。很高兴在早期发现这些问题,而不是六个月后突然发现。

    以下是运行的一些比赛日练习:

    终止Kubernetes API服务器
    终止所有Kubernetes API服务器并将其恢复(这非常有效)
    终止etcd节点
    从API服务器中关闭Kubernetes集群中的工作节点(以便它们无法通信)。这导致节点上的所有pods被迁移到其他节点。

    很高兴看到Kubernetes如何应对我们投入的大量干扰。 Kubernetes的设计是为了适应错误 - 它有存储所有状态的etcd集群,一个只是该数据库的REST接口的API服务器,以及一个协调所有集群管理的无状态控制器集合。

    如果任何Kubernetes核心组件(API服务器,控制器管理器或调度程序)被中断或重新启动,一旦它们出现,它们将从etcd读取相关状态并继续无缝运行。这是我们希望的事情之一,而且在实践中实际运作良好。

    以下是测试中发现的一些问题:

    “没有得到paged,来修复监控。“
    “当销毁API服务器实例并将其恢复后,需要人工干预。最好解决这个问题。“
    “有时执行etcd故障转移时,API服务器会启动超时请求,直至重新启动。”

    在运行这些测试后,针对发现的问题开发了补救措施:改进了监控,发现了固定配置问题,并提交了Kubernetes bug。
    使cron作业易于使用
    简单地探讨一下我们是如何使基于kubernetes的系统易于使用的。

    最初的目标是设计一个运行cron作业的系统,团队有信心运营和维护。一旦建立了对Kubernetes的信心,就需要工程师们轻松地配置和增加新的cron作业。我们开发了一个简单的YAML配置格式,这样用户就不需要了解Kubernetes的内部结构来使用这个系统。这是我们开发的格式:

    name: job-name-here
    kubernetes:
    schedule: '15 /2 '
    command:
    • ruby
    • "/path/to/script.rb"
    resources:
    requests:
    cpu: 0.1
    memory: 128M
    limits:
    memory: 1024M

    没有做什么特别的事情——我们编写了一个简单的程序,将这种格式转换为Kubernetes cron作业配置,将其应用于kubectl。

    我们还编写了一个测试套件,以确保作业名称不会太长,并且所有名称都是惟一的。我们目前不使用cgroups来强化对大多数作业的内存限制,但计划将来推出。

    我们的简单格式易于使用,而且由于自动生成了来自相同格式的Chronos和Kubernetes cron作业定义,所以在两个系统之间迁移作业非常简单。这是使我们的增量迁移工作良好的关键部分。将作业迁移到Kubernetes时,可以用一个简单的三行配置更改,在不到十分钟的时间内将其移回。
    监控Kubernetes
    监测Kubernetes集群的内部状态非常令人愉悦。我们使用kube-state-metrics软件包进行监测,并使用一个名为veneurl - Prometheus的小型Go程序来获取Prometheus的度量标准,将它们作为statsd指标发布到我们的监控系统中。

    例如,以下是过去一小时内集群中未决Pod的数量图表。Pending意味着等待分配一个工作节点来运行。可以看到上午11点的数字峰值,很多cron作业在每小时的第0分钟运行。

    还有一个监视器,用于检查有没有任何Pod在Pending状态中卡住 - 每个Pod在5分钟内开始在worker节点上运行,否则会收到警报。
    Kubernetes未来计划
    设置Kubernetes,到顺畅地运行生产代码并将所有cron作业迁移到新集群,花了五个月的时间,三位工程师全职工作。我们投资学习Kubernetes的一个重要原因是希望能够在Stripe中更广泛地使用Kubernetes。

    以下是适用于运行Kubernetes(或任何其他复杂分布式系统)的原则:

    为企业的Kubernetes项目,以及所有基础设施项目,定义清晰的商业原因。了解业务案例和用户的需求使项目变得更加容易。
    积极削减范围。避免使用许多Kubernetes的基本特性来简化集群。这让我们可以更快速地发送消息,例如,由于pod-to-pod联网不是我们项目的必需条件,可以关闭节点之间的所有网络连接,并将Kubernetes的网络安全性推迟。

    花大量时间学习如何正确地运营Kubernetes集群。仔细测试边界情况。分布式系统非常复杂,有很多潜在的问题。以前面的例子为例:如果节点控制器由于配置与API服务器失去联系,那么它可以杀死集群中的所有pods。学习Kubernetes在每次配置更改后的表现如何,需要时间和精心的关注。

    通过专注于这些原则,我们已经有信心在生产中使用Kubernetes。我们将继续开发Kubernetes的使用,例如,我们正在关注AWS EKS的发布。我们正在完成另一个系统的工作,训练机器学习模型,并且正在探索将一些HTTP服务迁移到Kubernetes。随着我们继续在生产中运行Kubernetes时,我们计划对开源项目做出贡献。



    原文作者:Julia Evans
    原文链接:
    Learning to operate Kubernetes reliably
    https://stripe.com/blog/operating-kubernetes

    马斯洛理论告诉你,Kubernetes可以满足微服务的这些需求

    Dataman数人科技 发表了文章 • 0 个评论 • 1170 次浏览 • 2018-03-06 15:02 • 来自相关话题

    需求层次理论是由心理学家艾伯特·马斯洛设计的,它是一种解释人类动机的心理学理论,它由多层次的人类需求模型组成,通常被描述成金字塔内的等级层次。马斯洛使用诸如生理、安全、归属感和爱、尊重、自我实现和自我超越等来描述人类动机通常所经历的阶段。作为人类,首先需要满足 ...查看全部
    需求层次理论是由心理学家艾伯特·马斯洛设计的,它是一种解释人类动机的心理学理论,它由多层次的人类需求模型组成,通常被描述成金字塔内的等级层次。马斯洛使用诸如生理、安全、归属感和爱、尊重、自我实现和自我超越等来描述人类动机通常所经历的阶段。作为人类,首先需要满足我们的基本需求,然后是心理上的需求,只有这样我们才能想到自尊和实现全部的潜能:


    102.png



    马斯洛需求层次

    一、Kubernetes能满足微服务的马斯洛需求

    这种描述需求的方法非常重要,已经应用于许多其他领域,如员工敬业度、云计算、软件开发、DevOps等等。所以对于微服务来说也同样适用,为了微服务的成功,清晰的需求列表必须满足。List如下:


    103.png



    微服务的需求层次结构

    一旦列出了微服务的主要问题(对每个人来说可能会有不同的顺序),就会发现Kubernetes容器编排引擎确实能够很好地覆盖这些需求中的很大一部分。我把Kubernetes也添加到图中。

    首先,对于基础层,需要一些计算资源,并且理想的情况下,拥有一个由基础设施服务云提供商管理的可伸缩的标准操作环境。其他先决条件是,自动化的CI/CD流程和工件注册表,Kubernetes可以帮助我们运行和管理。我们仍然需要一些专门的软件,比如构建的Jenkins,以及工件存储库,比如按需 Sonatype Nexus for Docker和Maven for Docker Hub。

    Kubernetes可以帮助管理多个隔离环境(名称空间)、管理资源(配额和限制)、存储分配(持久卷)、执行部署和回滚(部署)、自动调度(调度)、服务发现和负载平衡(服务)、弹性和容错(pod健康检查)。

    对于某些需求,我们还需要一些额外的工具,如Docker或rkt用于容器实现,应用程序内的弹性库(如Netflix的Hystrix)与Kubernetes弹性特性相结合。然后,Kubernetes可以管理应用程序配置,并帮助运行最好的集中式日志记录、度量收集和跟踪软件,随着服务数量的增加,这些也变得非常重要。

    根据微服务的性质,企业有一些特定的需求。对于API驱动的微服务,需要专门的API管理解决方案,也可以处理服务安全性(Kubernetes没有提供)。但是Kubernetes可以轻松地帮助企业运行有状态的服务(有状态的设置)、批处理作业(job)和调度作业(cron job)。

    通过一个平台提供的所有这些特性,用户可以执行一些更智能的活动,如应用程序和基础设施自动伸缩和自修复,通过自动放置、自动重启、自动复制、自动伸缩。

    对于Kubernetes所满足的所有这些需求,团队所剩下的就是精简开发流程,拥抱DevOps文化以实现快速交付,并在组织层面达到反脆弱性。

    二、关于Kubernetes你需要知道的8件事

    这是《计算机周刊》与 Carlos Sanchez 的问答环节,Sanchez 是 CloudBees 的工程师,CloudBees是持续交付和集成软件服务的提供商。其中开源持续集成工具Jenkins,是CloudBees服务的重点。

    《计算机周刊》的开源内部人士(Computer Weekly Open Source Insider,简称:CWOSI)提出了8个与Kubernetes最相关的问题,试图揭开这个问题的核心,因为2017年Kubernetes经历了知名度的大幅提升。

    CWOSI #1:对于那些不了解Kubernetes的人,你如何总结和定义这项技术?

    Sanchez: Kubernetes是一个开源平台,旨在自动化容器的部署、缩放和操作。它是一种允许在大规模集群上运行容器的技术。它支持跨大型数据中心的隔离应用程序的执行。

    CWOSI #2:为什么Kubernetes会在你的观点中出现——为什么我们需要它?

    Sanchez: Docker确实成功地制造了容器。事实上,谷歌已经运行了很多年几十亿的容器。Kubernetes从谷歌的经验中得出了这种规模的容器运行,导致谷歌将这项技术引入开源世界,从而使其他人更容易地管理容器。

    至于为什么我们需要Kubernetes,这是因为对于大型和小型的组织来说,容器变得越来越重要,授权开发团队在大规模的分布式环境中运行,以便在DevOps和持续交付实践中更快地交付软件。在这种情况下,任何能够简化容器的有效操作和管理的东西都将受到企业的热烈欢迎。

    CWOSI #3:Kubernetes本质上是开源的,但是有多少开发人员在为一项本质上是基础设施的技术贡献代码呢?

    Sanchez:总的来说,有超过1400名贡献者。谷歌、红帽和微软都被包括在其中。最近,亚马逊和阿里巴巴已经成为参与这项技术的几家最大的公司。CNCF管理整个技术。

    CWOSI #4:容器化技术是否最终意味着每个单独的组件在验证其目的和最终交付特定的产出或功能的方面更负责?

    Sanchez:容器通常与微服务体系架构相关联。每个组件都期望完成一个特定的协议。这些组件有一个目的,它们有由这个协议和API标记的输入和输出。他们必须能够履行他们的职责。它们应该是独立的,并在体系结构中发挥特定的作用,其中有成百上千种服务共存。

    CWOSI # 5:什么时候不需要Kubernetes…当企业不需要大规模或跨多个机器的时候吗?

    Sanchez:Kubernetes是一个复杂的系统。如果企业有规模来证明部署的合理性,那么采用这种技术是有意义的。例如,如果只使用一两台虚拟机,或者没有任何更高的要求,企业可能不需要Kubernetes ,Docker自己就足够了。也就是说,谷歌或Azure提供的当前云服务让我们很容易从Kubernetes和大规模开始。

    CWOSI #6:能给我们解释一下Kubernetes pod吗?

    Sanchez:Kubernetes pod实际上是一组在同一个主机上运行的容器。这些容器具有一定的特点。例如,它们共享相同的网络空间和资源。真正的Kubernetes pod是由需要共存的容器组成的。

    CWOSI #7:让Kubernetes出错,并把错误的实施组合在一起有多容易?

    Sanchez:这又回到了安装上——这是一个复杂的软件,需要专门的专业知识。这就是人们使用谷歌Kubernetes引擎或Azure容器服务的原因。

    也就是说,有越来越多的工具,无论是开源的还是商业的,比如kops、kube-aws或者kubeadm都可以帮助执行正确的安装。如果您不使用其中一个安装程序来简化安装,那么在此过程中可能会犯错误。

    CWOSI #8:在你看来,Kubernetes在接下来的几年中会如何发展?

    Sanchez:将会有越来越多的Kubernetes产品从不同的供应商进入市场,不仅仅是云提供商,还有操作系统提供商。Kubernetes将成为集群的实际操作系统。另外,Kubernetes将会发展成为一套标准API,允许企业运行集群架构。

    我们看到云提供商正在破坏基础设施,这样企业就可以运行Kubernetes,而无需运行服务器。因此,我们将看到供应商提供Kubernetes作为服务,企业将能够在云中运行容器,而不必担心机器。AWS已经宣布了提供这一服务的意向,这一趋势将继续在其他供应商中施行。


    原文链接:

    1、Kubernetes and theMicroservices Hierarchy of Needs
    https://thenewstack.io/introducing-microservices-hierarchy-needs/?utm_content=bufferba844&utm_medium=social&utm_source=twitter.com&utm_campaign=buffer

    2、CloudBees:9 things you need to know about Kubernetes
    http://www.computerweekly.com/blog/Open-Source-Insider/CloudBees-9-things-you-need-to-know-about-Kubernetes?utm_source=tuicool&utm_medium=referral

    悉数四代PaaS发展,一文理顺基础设施、平台和工作流之间的关系

    Dataman数人科技 发表了文章 • 0 个评论 • 1231 次浏览 • 2018-03-01 11:26 • 来自相关话题

    Datawire团队最近的一次交流,是关于“PaaS”这一术语的真正含义,以及它与开发人员体验(DevEx)和工作流之间的关系,带来了许多可以分享的内部对话。从和客户一起工作,到会议上与人的聊天中,我感觉到,其他团队对于部署应用程序时“平台”和工作流之间的关系 ...查看全部

    Datawire团队最近的一次交流,是关于“PaaS”这一术语的真正含义,以及它与开发人员体验(DevEx)和工作流之间的关系,带来了许多可以分享的内部对话。从和客户一起工作,到会议上与人的聊天中,我感觉到,其他团队对于部署应用程序时“平台”和工作流之间的关系也有些不确定,我希望以建设性的方式,能提供一些清晰的认知,或者至少能够学到一些东西。

    基础设施、平台、工作流三者缺一不可
    Daniel Bryant是一名独立的技术顾问,专注于通过价值流识别、管道的创建和有效的测试策略实施,来实现组织内的持续交付。Daniel的技术专长在于DevOps工具、云/容器平台和微服务实现。他还参与了几个开源项目,为InfoQ、O 'Reilly和Voxxed撰稿,并定期出席OSCON、QCon和JavaOne等国际会议。

    从基本原则开始说起,所有基于web的软件开发都涉及到三层:

    基础设施:这一层提供原始计算资源的抽象,如裸金属、vm、操作系统、网络、存储等,这些资源最终将负责处理与应用程序相关的代码和数据。这里避免使用“物理”这个术语,因为尽管所有的东西最终都是在硬件上运行的,但是我们越来越多地看到基础设施的抽象转移到软件定义的所有东西(Software-Defined-Everything,SDx)。

    平台:这一层提供了粗粒度的系统级构建块,它可能是运行时特定的,比如一个集成的JVM或CLR的计算实例,还有数据存储、中间件、IAM、审计等等。值得一提的是,相信你总是将应用程序部署到某种形式的平台上,即使没有有意识地组装它。

    工作流:这一层是如何设计、构建、测试、部署、运营应用程序的总和。每个开发人员都有一个工作流(即使它是隐性的),从个人的独立网站构建者,到一个在复杂的企业系统中工作的数千人团队。

    当我和朋友和客户谈论这个模型时,我通常会就概念和结构达成某种形式的协议。当开始讨论这些概念之间的耦合时,特别是与PaaS有关时,分歧就开始了。
    这些是你正在寻找的平台
    我经常听到“PaaS有一个内置的工作流程”,或者“如果你正在运行一个PaaS,那么你不需要知道基础设施。”我并不特别同意这些说法,并且在努力建立共同的理解。PaaS经历了几代模式的发展:

    第一代:Heroku和它的朋友们。这种类型的PaaS隐藏了底层云基础设施(通过可部署的slugs和“Dynos”),并提出了非常有见地的工作流程,与平台耦合。对于简单的单体Ruby应用程序,这非常棒,可以在几分钟内熟练部署工作流程,并且所有知识都可以转移到下一个项目复用。

    第二代:Cloud Foundry(DEA版)和它的朋友们。这种类型的PaaS可以部署在企业的基础设施上,并且带来企业自己的buildpacks和运行时。工作流仍然集成在一起,但是该平台开始通过上下文路径路由(context path routing )等概念启用多服务应用程序(和工作流程)。

    第三代:Cloud Foundry(Diego版)以及当前版本的Google App Engine和AWS Elastic Beanstalk(两者分别从第一代和第二代PaaS演变而来)。这些PaaS对基础架构的依赖更低,企业可以携带自己的容器,并且文档清楚了解运行时和计算环境的限制。这里的工作流程正在转向支持分布式系统(微服务),并鼓励开发人员从目前“推荐的做法”中构建自己的持续交付管道的工作流程,可能使用Concourse或Spinnaker等工具。

    第四代:Kubernetes,Docker Swarm,Mesos,HashiCorp Nomad,AWS ECS等等(我明白这些并不是真正的PaaS)。这种类型的平台基础设施是不可知的。谁没有参加过会议并且看到Kubernetes在Raspberry Pi集群上运行?而且总是接触到构成集群的底层计算和网络基础设施(AWS Fargate例外)。也可以部署任何类型的容器或流程。这个平台出现了构建“云原生”应用的愿望,这些应用程序本质上是分布式的。这里的“最佳实践”工作流程尚未定义,或者更准确地说,目前仍与技术协同发展 - 并且我们正在对CI / CD进行最新的了解并改进。

    因此,这是一个有趣的开源和商业工具正在出现的领域:想一下Datawire的Forge和Telepresence 工作流工具,Ambassador的交通转移/部署,Weaveworks的Flux和Scope,Heptio和Bitnami的ksonnet,微软的Draft 和 Helm,Containous traefik负载均衡器/ API网关。

    我相信平台与工作流程耦合之间产生了混淆,因为很多企业部署了粗粒度(单体?)风格的应用程序,其中工作流与平台紧密结合。即第一代和第二代PaaS,或者工作流松散耦合,但定义明确,我们没有注意到这种摩擦 - 即在传统基础架构或第三代PaaS上构建和部署特定语言的组件。

    第四代平台面临挑战,技术仍在成熟,架构及相关组织最佳实践也在共同发展中--分别考虑微服务和无服务器,以及 inverse Conway maneuver。业务对速度,稳定性和可见性的压力也越来越大,这通常是通过将业务流程(形成跨职能业务部门)分解并将决策权下放给一线工作团队来实现的。这以商业运动为代表,例如 holacracies 和 Teal organizations。

    回顾上面的软件开发层面,需要指出的一个关键点是,基础设施和平台正在变得越来越分散和分离,但它们是通过集中化的力量实现的 - 例如基础设施中的AWS,以及平台中的Kubernetes(Apps SIG)社区,它定义了常用的协议,标准和接口。工作流程也变得分散,但我认为现在还没有集中的力量,即一种通用的描述性语言,一套工具和预定义(可插入)的工作流程步骤。

    构建(Snowflake)定制工作流程
    随着拥抱Kubernetes的组织越来越多,团队创建定制的开发者体验工作流程,通常在单个组织内的团队中存在差异,导致解决方案很脆弱,以及有限的共享学习。这些团队试图将他们的工作流程编写成最终在Kubernetes之上建立一个平台。部署到平台上至关重要,但平台和工作流的概念应该分开考虑和设计。紧密耦合平台和工作流程会导致不灵活的开发人员工作流程。

    相信Kubernetes的“平台”在2018年已经变得越来越清晰。Kubernetes本身已经很好地成熟了,而Envoy,Conduit和Cilium等公司的服务网格正在填补平台的一些缺失的部分。但是,围绕开发人员的体验还有很多想法需要去做。我们看到Weaveworks GitOps和Atlassian BDDA(Build-Diff,Deploy-Apply)等方法论中将最佳实践编纂在内,相信在应用程序开发(AppDev)领域会出现类似的东西。

    Kubernetes可能会接管应用程序的整个生命周期
    今天形成了Kubernetes无处不在的云原生景观。三家主要云提供商,AWS、Google和微软Azure都支持Kubernetes,甚至Docker和Cloud Foundry也在使用它。

    是什么使Kubernetes独一无二?传统意义上,通常是开源技术创造了商品化的产品替代主流闭源技术。 但Kubernetes一直是个例外。 “Linux是UNIX的竞争者,Apache web服务器是Apache IIS的竞争对手。那么谁是Kubernetes的竞争对手?并没有与之竞争的闭源产品,”CoreOS首席技术官兼联合创始人Brandon Philips 说。

    实质上,Kubernetes在与人们创建的所有脚本进行竞争,以将他们在笔记本电脑上开发的源代码部署到生产环境中。有成千上万的方法可以做到这一点:CI / CD工作流程,bash脚本,配置管理工具等。为了获得生产所需的所有东西,数周的开发一直是个痛苦的周期。这就是Kubernetes来拯救的地方。它通过创建 API 来缩短这个周期,提供了适用于任何类型的一致性和可重复性。

    “这是Kubernetes的重点,”Philips表示,“随着时间的推移,我们可能会接管应用程序的整个生命周期,从idea到监控到应用程序工作流程,到最终退出应用程序。我们已经看到用户在扩展Kubernetes api。Philips认为,这将继续,“天空是我们所依赖的抽象的极限。 “看看它在未来几年的发展将会很有趣。”



    原文链接:
    1、Kubernetes and PaaS: The Force of DeveloperExperience and Workflow
    https://thenewstack.io/kubernetes-paas-force-developer-experience-workflow/
    2、Over Time, Kubernetes May Take Over theEntire Lifecycle of Applications
    https://thenewstack.io/time-kubernetes-may-take-entire-lifecycle-applications/

    看好还是看衰?8位业界大咖这么看Serverless的2018

    Dataman数人科技 发表了文章 • 0 个评论 • 1138 次浏览 • 2018-02-24 10:35 • 来自相关话题

    导读: Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖 ...查看全部
    导读:

    Serverless,也称为FaaS(功能即服务),它并不意味着没有服务器在执行繁重的任务 ;而是用户看不到或者不必维护服务器,并且不关心它所在的世界。小数之前跟大家分享过多次Serverless的话题,比如,思考+案例,大咖研究了Serverless14个月,优缺全体现!,再比如,容器之后的下一个明星,关于无服务器(Serverless)架构你要搞懂的8件事。今天这篇主要由8位业内意见领袖谈2018Serverless的去向。
    2.jpg

    在所谓的无服务器IT系统中,数据工作负载是如何处理的?

    亚马逊的AWS Lambda是无服务器计算最大、最著名的例子,它的未来对很多IT人来说是非常诱人的。Lambda是由 Amazon开发的一个事件驱动的计算平台,当特定事件发生时,它会自动触发或执行代码。Lambda只在需要时执行代码,并自动伸缩,为企业处理一些数据流程和应用程序,提供潜在的成本节约和灵活性。

    Amazon 在2014年发布了Lambda,作为企业在云中运行代码的“无服务器”平台,不需要物理服务器,也不需要在企业端提供或管理任何服务器。


    1、Serverless无服务器是未来的潮流

    在应用程序代码方面,AWS支持Node.js、Java、c#和现在的Python,只要开发人员在其中一种语言中编写代码,代码就可以在Lambda运行环境中运行,并利用Lambda资源。

    亚马逊并不是唯一的FaaS供应商,其他还包括谷歌云,微软Azure,IBM OpenWhisk和开源项目Iron.io,以及Webtask。

    无服务器的工作负载生产仍然处于初级阶段,但如果IT界的各种预言者都是正确的,那么它将很快在我们眼前成长起来。

    以下是一些来自行业专家对serverless未来的展望:

    >>>>Sumo Logic (相扑逻辑):无服务器计算可能是继容器之后的未来

    AWS的采用率几乎翻了一番,从2016年的12%上升到2017年的23%。serverless的整个想法是,它通过完全跳过容器和DevOps将微服务转移到未来。事实上,有四分之一的开发人员已经在使用serverless,这对于遵循应用程序架构和采用的人来说是一种强烈的信号。IT领导者已经在谈论DevOps,但是serverless将它带到一个全新的世界“NoOps”——在没有基础设施的情况下,应用程序在云中运行。


    >>>>Avere Systems技术总监Dan Nydick : 我们将看到更多serverless技术和托管服务

    企业经常花费大量的时间和精力来管理计算基础设施,这不是他们任务和使命的核心任务。公有云的好处之一是,将应用程序迁移到云上之后,企业不再需要管理这些基础设施。云供应商提供了越来越高水平的管理服务,允许客户专注于自身业务,而不必被虚拟机、web服务器或数据库管理分散注意力。

    我们将看到更多使用托管的、可伸缩的web服务(如谷歌 App Engine和AWS Beanstalk)和无服务器技术(如AWS Lambda和谷歌CloudFunctions),作为管理和部署复杂企业应用程序的更经济的方式。

    “我们预计云供应商将继续向更高级别的托管服务发展,例如完全分布式数据库管理(谷歌Cloud Spanner),以及第三方出售托管在公有云(Azure Managed Apps)中的应用程序的新能力。”


    >>>>Atlassian平台负责人Steve Deasy:2018将如何改变软件的构建方式

    “随着来自主要云供应商的支持,无服务器的框架将会受到欢迎。”此外,数据驱动的应用程序将继续受到欢迎,而对工程师需求的支持也将以工具、基础设施和争论(wrangling)的形式出现。在《Mortal Kombat》中提到,Kubernetes将给现有的平台带来致命的灾难。


    >>>>Evident.io公司CEO Tim Prendergast和客户解决方案副总裁John Martinez:容器和无服务器计算增加,它们会带来安全问题。

    “2018年,公司将采用云计算的方式,传统的基于主机的操作系统将变得无关紧要,或者需要重新设计。”从安全的角度来看,没有人真正准备好保护所有这些容器和功能计算,但是人们还是采用了它。


    >>>>Contino公司主席Jason McDonald:无服务器采用将继续增加其影响。

    “Serverless将从云产业的小角落转移到聚光灯下,因为它解决了IT三个关键领域的管理:速度、成本和风险。事实上,亚马逊推出AWS Fargate,这是一种创新,它通过删除服务器,消除运行ECS集群所需的基础设施管理,从而极大地改变了容器的演化。

    目前,至少有一家美国主要银行正在运行企业级应用程序,这是一个基于Lambda的专职基础架构,可解决成本和规模问题。未来将会有越来越多类似这样的故事,基于云的堆栈越来越多地迁移到无服务器架构中。


    >>>>OVH US公司技术布道者和首席系统工程师 Paul Stephenson: 无服务器计算解决哪些用例将会更清晰。

    “这项技术目前非常具有探索性,事件驱动的技术仍在继续。”很高兴看到这一领域发生的一切, 因为IT做的任何事情都可以提高企业业绩表现,同时保持相同或较低的风险状况,这将推动企业进行调研和投资。”


    >>>>Data Expedition CEO Seth Noble: 2018年,Serverless将与其他技术整合

    云供应商给客户和第三方留下了许多关键的云迁移元素。这为一些关键领域(如数据输入、数据组织和应用部署)带来了隐形成本。2018年,我们将会看到更多客户要求实际的解决方案,如真正的网络加速,缩小对象存储和文件存储之间的差距,以及更好的工具来集成基于无服务器的应用程序和无服务器服务。


    >>>>Platform9 CEO Sirish Raghuram: Kubernetes将会在AWS Lambda无服务器部署中变得更有影响力。

    Kubernetes不仅可以让云更容易交叉使用,还可以降低云提供的其他高价值应用服务的价值。比如Lambda,用于无服务器计算。有很多开源的替代方案,比如Fission,开源并运行在任何Kubernetes集群上,提供了相同的价值主张。这仅仅是一个例子,说明云提供商自身原生服务的价值可能会发生级联变化,还会发生在Kubernetes生态系统中可用的应用服务范围内。“



    2、7大提供FaaS的开源无服务器框架

    随着虚拟化技术的发展,企业开始意识到物理硬件的利用率越来越高。随着云计算的发展,企业开始逐渐将虚拟机用于即付即用的服务中,AWS在2014年推出了Lambda服务,引入了云计算的新范例,如今已经成为通常所说的无服务器计算。在无服务器模式中,企业将功能作为服务付费,而不需要为永远在线的状态虚拟机付费。AWS lambda开创了serverless,现在有多个开源项目构建可用于多重部署的无服务器框架:

    1.Apache Openwhisk

    IBM启动了apache openwhisk项目,现在它是IBMCloud Functions服务的基础。

    2.Fission uses kubernetes for serverless
    由云服务供应商Platform9领导的开源Fission项目是一个基于Kubernetes的无服务器框架。”Fission是开放源代码项目,旨在成为lambda事实上的开源替代品,”Madhura Maskasky,PLatform9的联合创始人,在2017年1月采访时对eWEEK说。

    3.IronFunctions
    IronFunctions是一种以Go语言编写的FaaS平台。功能是任何云计算,包括公有云、私有云和混合云提供开源无服务器计算平台。

    4.Fn project backed by Oracle
    2017年10月甲骨文公司宣布开源Fn项目,为apache许可的无服务器项目。

    5.OpenFaas
    OpenFaas 是一种能够使docker或者kubernetes都变成无服务器的开源项目,是一种FaaS框架。

    6.Kubeless
    开源框架Kubeless是由2017年3月被Bitnami收购的软件供应商Skippbox开发的。
    kubeless是一个kubernetes本地无服务器框架,具有符合AWS Lambda CLI的命令行界面(CLI)

    7.Riff
    在最新的开源无服务器框架中,Riff项目得到了关键支持,并且是即将到来的Pivotal Function Service(PFS)的基础。


    >>>>调查显示企业不断从私有云转向公有云
    一项对300名IT专业人员的调查显示,公有云系统将继续快速增长,因为企业将把他们的本地数据中心资产转移到云平台。

    Serverless这种新兴的云计算服务交付模式为开发人员和管理人员带了很多好处。它提供了合适的灵活性和控制性级别。Serverless架构正在彻底改变软件开发和部署流程。


    原文链接:
    1、Predictions 2018: Why Serverless Processing May Be Wave of the Future
    http://www.eweek.com/innovation/predictions-2018-why-serverless-processing-may-be-wave-of-the-future
    2、7 Open-Source Serverless Frameworks Providing Functions as a Service
    http://www.eweek.com/cloud/7-open-source-serverless-frameworks-providing-functions-as-a-service

    基于容器生态扩张的DevSecOps为啥引关注?

    Dataman数人科技 发表了文章 • 0 个评论 • 1135 次浏览 • 2018-02-08 10:26 • 来自相关话题

    DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。 像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒 ...查看全部
    DevSecOps可能不是一个优雅的术语,但其结果是有吸引力的: 在开发的早期带来更强大的安全性。DevOps最终是要建立更好的软件,也意味着更安全的软件。

    像任何IT术语一样,DevSecOps--由DevOps衍生而来,很容易被炒作和盗用。但是这个术语对拥抱DevOps文化的IT领导者以及实现其承诺的实践和工具而言,具有真正的意义。

    DevSecOps什么意思?

    Datic公司首席技术官兼共同创始人RobertReeves说:“DevSecOps是开发,安全和运维的组合。它提醒我们,对于应用程序来说,安全和创建、部署到生产上同样重要。”

    向非技术人员解释DevSecOps的一个简单方法:它有意识地更早地将安全性融入到开发过程中。

    红帽安全战略家Kirsten Newcomer 最近告诉我们: “历史上,安全团队从开发团队中分离出来,每个团队都在不同的IT领域拥有深厚的专业知识 。“其实不需要这样。关心安全的企业也非常关心通过软件快速交付业务价值的能力,这些企业正在寻找方法,将安全性留在应用开发生命周期内。通过在整个CI / CD中集成安全实践,工具和自动化来采用DevSecOps。”

    她说:“为了做到这一点,他们正在整合团队。安全专业人员将从应用开发团队一直嵌入到生产部署中。” “双方都看到了价值,每个团队都拓展了他们的技能和知识基础,成为更有价值的技术专家。正确的DevOps或DevSecOps ,提高IT安全性。”

    IT团队的任务是更快,更频繁地交付服务。DevOps成为一个很好的推动因素,部分原因是它可以消除开发和运营团队之间的一些传统冲突,Ops通常在部署之前被排除在外,而Dev将其代码丢在无形的墙上,从来不进行二次管理,更没有任何的基础设施维护责任。说得委婉一些,在数字化时代,这种孤立的做法会产生问题。按照Reeves的说法,如果安全是孤立的,也会存在类似的问题。

    Reeves说:“我们采用DevOps,它被证明可以通过扫除开发与运维之间的障碍来提高IT的性能。“就像不应该等到部署周期结束才开始运维一样,也不应该等到最后才考虑安全问题。”
    DevSecOps为什么会出现?

    将DevSecOps看作是另一个流行语是一种诱惑,但对于安全意识强的IT领导者来说,这是一个实质性的概念。安全必须是软件开发流程中的“一等公民”,而并非最终步骤部署,或者更糟糕,只有在发生实际的安全事件后才受到重视。

    SumoLogic公司安全与合规副总裁George Gerchow表示:“DevSecOps不仅仅是一个流行词,由于诸多原因它是IT的当前和未来状态。“最重要的好处是能够将安全性融入到开发和运营流程中,为实现敏捷性和创新提供保障。”

    此外,在场景中出现的DevSecOps可能是DevOps自身正在成熟并深入挖掘IT内部的另一个标志。

    “企业DevOps文化意味着开发人员能够以更快的速度向生产环境提供功能和更新,特别是当自组织团队更加乐于协作和衡量结果。”CYBRIC首席技术官兼联合创始人Mike Kail说。

    在采用DevOps的同时,保持原有的安全实践的团队和公司会遇到更多的管理安全风险的痛苦,因为DevOps团队会部署地更快、更频繁。
    手动测试安全方法逐渐落后
    “目前,手动测试安全方法逐渐落后,利用自动化和协作将安全测试转移到软件开发生命周期,从而推动DevSecOps文化,这是IT领导者提高整体弹性和交付安全保证的唯一路径。”凯尔说。

    (早期)对安全性测试的改变也让开发人员受益:在开发新服务或部署更新服务之前,他们并没有发现代码中的明显漏洞,而是经常在开发的早期阶段发现并解决潜在的问题,几乎没有安全人员的介入。

    SAS首席信息安全官Brian Wilson表示:“正确的做法是,DevSecOps可以将安全性纳入开发生命周期,使开发人员能够更快,更方便地保护应用程序,不会造成安全干扰。

    Wilson将静态(SAST)和源代码分析(SCA)工具集成到团队的持续交付中,帮助开发人员在代码中对潜在问题,以及第三方依赖的漏洞进行反馈。

    Wilson说:“开发人员可以主动、反复地缓解app的安全问题,并重新进行安全扫描,无需安全人员参与。DevSecOps还可以帮助开发团队简化更新和修补程序。

    DevSecOps并不意味着企业不再需要安全专家,就像DevOps并不意味着企业不再需要基础架构专家一样。它只是有助于减少瑕疵进入生产的可能性,或减缓部署。
    DevSecOps遭遇的危机

    来自Sumo Logic公司的Gerchow分享了DevSecOps文化的实例:当最近的Meltdown和Spectre消息出现时,团队的DevSecOps方法能够迅速做出响应,以减轻风险,而对内外部客户没有任何明显的干扰。 对云原生和受高度监管的公司来说非常重要。

    第一步,Gerchow的小型安全团队(具备开发技能)能够通过Slack与其主要云供应商之一合作,确保基础设施在24小时内完全修补好。

    “然后,我的团队立即开始了OS级别的修复,不需要给终端用户停机时间,也无需请求工程师,那样意味着要等待长时间的变更管理流程。所有这些变化都是通过Slack打开自动化Jira tickets进行的,并通过日志和分析解决方案进行监控,“Gerchow解释说。

    这听起来像DevOps文化,正确的人员、流程和工具组合相匹配,但它明确地将安全作为该文化和组合的一部分。

    Gerchow说:“在传统环境下,停机需要花费数周或数月的时间,因为开发、运营和安全这三项功能都是孤立的。凭借DevSecOps流程和理念,终端用户可以通过简单的沟通和当天的修复获得无缝的体验。”

    02
    2018DevSecOps三大预测

    2018年企业的DevSecOps将迎来一些真正的变革。

    对于DevSecOps来说,2017年是美好的一年,DevSecOps从一个半朦胧的概念演变成可行的企业功能。

    容器和容器市场的迅速扩张在很大程度上推动了这一演变,容器市场本质上与DevOps和DevSecOps相互交织在一起。一般来说,快速增长和创新往往比科学更能预测趋势,但我仍然愿意尝试一下。

    从Docker Hub和成熟的容器生态系统中获取了超过120亿张图片,就企业的DevSecOps而言,我们几乎看不到冰山的一角。不过,相信在2018年,我们将看到:基础变革的开始。我认为它会是这样的:

    >>>1.企业领导者和IT利益相关者意识到DevSecOps正在改进DevOps
    DevOps将开发团队和运维团队聚在一起,它推动协作文化不足为奇。加入安全举措可能听起来很简单,但多年来,安全问题一直是事后的事情,导致企业文化容易使安全团队与其他IT团队形成对立,包括开发团队。



    但是事情发生了变化。

    在雅虎亏损3.5亿美元的商业环境下,暴露了其脆弱的安全状况,企业领导者将网络安全看作是一个运维sinkhole的时代已经结束。加强网络安全现在是企业的当务之急。但这种转变需要时间才能重新回到IT文化中。

    DevOps和DevSecOps的崛起无疑为重塑应用程序安全性创造了一个难得且令人兴奋的机会,但是DevOps可能会导致转变速度发生变化。DevOps团队和应用程序架构师每天都能够认识到安全的重要性,并欢迎安全团队的加入,但他们之间仍然存在需要磨合的鸿沟。

    为正确实施DevSecOps,安全团队需要与DevOps团队保持一致,企业领导者需要为此打造空间和预算。到2019年,希望企业领导人能够意识到推动一个重要的、合法的安全胜利的机会。

    >>>2.成功的组织模式将会出现,最可能的是,安全与DevOps团队之间的紧密协作。



    虽然该预测并不特别具有启发性,但是相关的。了解DevSecOps需要来自安全和DevOps团队的平等协作,快速跟踪标准蓝图或实施模型,将DevSecOps集成(并最终自动化)到CI / CD进程中。

    虽然不同企业有不同的需求,但大多数公司都使用相同的技术工具,特别是在使用容器的情况下。这就为统一的标准化提供了条件。此外,容器的开源特性可以促进相关信息的共享和标准开发。

    到目前为止,由于DevOps团队拥有开发流程,他们一直在安全方面处于领先地位。然而,我认为,DevSecOps需要由安全团队领导, 他们是负责企业安全和风险的人,当安全事故发生时,他们会被解雇或被迫离开。

    2018年,安全团队需要加强并展示团队的价值和技能。将安全性融入到IT结构中,而不是在网络安全问题成为事实之后才想起。现在我们有机会来实现这一目标。

    >>>3.安全团队仍然要缓慢适应DevOps的现实



    过去,企业安全团队通常在不重视或不了解安全需要的文化中运营。难怪今天的电商环境是大多数企业相对容易被破坏的环境。

    强大的安全性不仅仅是外围的防火墙。尽管许多安全专家可能最终会看到这种转变,但可能不像DevOps团队所期望的那样灵活。当谈到容器(通常是appsec)时,即使是最有才华和最优秀的安全专家也会面临学习的瓶颈。更不用说已经被充分证明的网络安全技能短缺的现状。

    虽然这些因素可能在短期内降低安全对DevOps和 DevSecOps的支持,但是我认为DevSecOps是解决技能短缺问题的一部分。将安全集成到应用程序交付过程中,并将其自动化比用回溯方法更有效率和更具成本效益,可以解决在部署应用程序之前解决安全漏洞。安全专业人士可以通过开放的态度,以新的方式发挥他们的才能,从而获得很多收益。

    2018年希望这个故事有一个快乐的结局。

    原文链接:
    1、3 predictions for devsecops in 2018
    https://www.infoworld.com/article/3243155/devops/3-predictions-for-devsecops-in-2018.html
    2、 Why DevSecOps matters to IT leaders
    https://enterprisersproject.com/article/2018/1/why-devsecops-matters-it-leaders

    PPT | 从架构到组件,深挖istio如何连接、管理和保护微服务2.0?

    Dataman数人科技 发表了文章 • 0 个评论 • 1506 次浏览 • 2018-02-07 18:53 • 来自相关话题

    2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。 ...查看全部

    2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。

    数人云Meetup每月一期,欢迎大家来面基、学习。本文为中兴通讯资深研发教练&系统架构师张晔分享的“微服务2.0:istio架构纵览”现场演讲实录。


    近几年我一直从事于微服务系统的设计以及实现方面的工作,属于微服务架构一线实践者。之前做过一些单体系统的微服务改造,在微服务拆分、治理等方面都有一定的经验。

    本人比较特殊一点的经历是既做过 IT 领域的微服务,也做过 CT(通讯领域)的微服务,微服务架构在这两个领域的具体形态和要求是不太一样的,但其中一些思想是互通且是很有借鉴意义的。今天主要介绍一下关于微服务的最新发展动态,以及最近谷歌推出的 Istio平台架构。

    今天介绍的主题包含:服务治理、服务网格、Istio架构,以及 Istio 相应的系统组成。


    一、分布式计算的八个谬论


    彼得多维奇多年前提出的分布式计算的八个谬论,对于开发人员来说他们往往会忽视这八条。这八条基本上都和网络相关,例如在发起一个网络请求时,会不断地做一些尝试等待,来保障消息投递的有效性。

    微服务是一个更为复杂的分布式系统,之前 SOA 或者B/S,CS 架构,它的颗粒度会更粗一点,但是如果采用微服务,它的颗粒度是更细的。在马丁·富勒博客《微服务的先决条件是什么》一文中提到一条,你必须要成为“高个子”,想成为“高个子”其实并不简单,很多公司,它们都是为了成为“高个子”,做了很多框架、平台。



    二、服务治理

    1
    微服务治理的技术点


    要成为“高个子”需要对微服务进行哪些改造,这里是相关服务治理的技术点,其中只是一部分,和服务网格比较相关的技术点,包含服务发现、负载均衡、请求路由、认证与授权、可观测性,还有健康检查、容错等。目前主流的解决方案有众所周知的 Spring Cloud, Dubbo 等,这些都是提供库来把服务治理相关的内容打包,供具体的业务去调用。


    2
    库或框架的问题

    但是库和框架会存在一些问题:

    1、学习成本。多一个库对于开发人员而言,意味着要多学一些东西,并且在业务开发过程中,还会受到库或者框架的制约。

    2、对业务代码的侵入性。例如用 Spring Cloud 会在代码里面加很多额外的内容,比如每个请求里面加一个注解来表达想引用服务治理的某些功能。

    3、基础库的维护、升级和下线。如果是以库的方式来提升到服务里面,库的维护、升级、下线就会造成整个服务的维护、升级、下线。

    4、不同语言和技术栈。在提出微服务概念时,它的一个重要好处就是可以使用不同的技术栈来开发微服务,但如果受到框架制约,只能用这个语言,这是我们比较头痛的事情,无法发挥微服务跨语言的能力。

    这些问题其实是有严重程度的,从上往下越来越让开发人员觉得不舒服。理想中的服务治理方案是什么?可以先畅想一下,整个服务治理相关的东西,应该是和业务逻辑完全隔离的,并且服务和服务之间的交互是不会考虑服务治理这块内容,最好对于业务开发来说是不可见的。

    这时候怎么去做呢?就引出了容器经典部署模式——Sidecar。


    3
    Sidecar模式


    Sidecar 模式通常是和容器一起使用,如果不和容器一起使用也没关系,那就是两个独立的进程,如果和容器使用的话,就基于容器为单位。Sidecar模式是物理隔离的,并且与语言无关。因为是两个独立的东西,可以独立发布,和微服务理念一样。另外它们是部署在同一个 Host 上面,所以资源之间可以做到相互访问,并且因为在一起所以通信延迟也不会太明显。和业务无关的功能都可以放上去,形成多个 Sidecar。今天 Sidecar 主要是把一些服务治理相关的东西放在里面,做软件设计上的思想就是分离关注点。


    基于 Sidecar 模式做服务治理,之后形成连接的具体状况,如图,对于服务A来说,服务A是不知道和 Sidecar 进行通信,服务A还是向服务B发消息,照常调用通信接口,但是消息可能会被 Sidecar 捕获到,然后通过Sidecar 进行转发。


    三、服务网格

    从整个系统来看,如果以 Sidecar 方式来部署服务治理以及服务的话,最终形成的系统如图。能看到通过 Sidecar 进行相互连接,形成一个网络,这也是服务网格名字的由来。每一个节点上面都相当于具体的网格,和多年之前提的网格计算有点类似。



    服务网格如果站在更抽象的层次来看是什么样子?把服务治理相关的东西抽象来看的话,服务网格也算是一种基础设施,它和具体的业务无关。不管是 PaaS 的发展,还是服务网格的发展,都是将与业务无关的内容的共同点提取出来,然后形成独立的一套平台或者方案。另外,服务网格之间要形成可靠传递,刚才提到的重试等功能都应该具备。

    服务网格是轻量级的网络代理,不能太重,不能喧兵夺主,服务才是整个系统中最重要的东西,而这些基础设施并不应该取代服务最重要的价值地位。

    更关键的一点是要对应用程序透明。对于服务而言是看不到 Sidecar、看不到代理的,服务如果要发消息出去,它知道是发给这个代理的,那对于我们的业务来说同样也是一种污染。服务网格最终不再强调代理作为单独的组件,不再孤立的来看代理,而是从全局的角度来看待代理所形成的网络。


    1
    服务网格定义


    服务网格的定义是 Willian Morgan 提出来的,他是最早做服务网格的人。如图,文字加粗的是服务网格一些关键技术点。右边图是最新发展的服务网格,在最上层还会加一个控制面板,通过控制面板来管理这些代理,这些代理是需要被管理的。如果我们的运维环境没有控制面板,可能就没办法运维了。


    2
    服务网格的基本构成


    服务网格必须要具备数据面板和控制面板,如果新开发一个服务网格只有数据面板,它肯定不是一个完整的服务网格。

    数据面板是用来接收系统中的每一个包或者请求,提供服务发现、健康检查等服务治理相关的,都是由数据面板来完成。数据面板的一些典型代表有 Linked、Envoy、和 Nginx 公司开发的 Nginmesh,以及硬件服务的代理厂商F5开发的 Aspen Mesh。目前主要的、成熟的是 Linked 和 Envoy,这两者都在生产环境上面真实部署过,实战过。而且Linked的采用会更广泛一些,因为它出现的时间最早。

    对于控制面板来说,是为了在网格中运营的数据面板提供策略和配置,负责一些管理工作,它不会接收系统中的任何包或者请求。这里的包和请求应该是业务相关的包和请求,和具体的业务是完全没关系的。本来做微服务应该做去中心化的事情,但是又有一个控制点在那里,要强调的是那个控制点和具体的业务没什么关系。控制面板的典型代表,包括 Istio、Conduit、Nleson、SmartStack,目前最新的是 Istio 和 Conduit。


    3
    数据面板对比


    左边是 Linked(Scala编写),右边是 Envoy(C++编写),它们最大的区别就是实现语言的区别。同时,Linkerd 和 Envoy 都是在生产环境已经验证过的两个系统,功能上都没问题,都比较强大,它们唯一的区别就是对于硬件资源的要求,Linked 是非常高的,它可能就会造成喧兵夺主的感觉,所以目前 Envoy 在这块是比较火的,Envoy 是由C++开发的。

    4
    控制面板对比


    两个最新的控制面板,一个是 Istio,是由 Google、IBM、Lyft 开发的,而 Conduit 是由 Buoyant 公司开发的,跟刚才所说的性能不太好的数据面板Linkerd是同一家公司,Buoyant 在 Linkerd 之后又重新开发了 Conduit,专门来解决性能上的问题,所以在性能上面来看,Conduit 的性能指标已经出来了,就是微秒级,并且是P99延迟。但是 Istio 的性能指标现在还没出来,还在功能开发阶段。因为 Istio 需要实现的功能比较多,要支持各种各样的平台和过滤,Istio 整个架构非常灵活,所以 Istio 整个量级是比较重量的,但是 Conduit 只支持 K8S,Conduit 的原则是怎么快怎么来。

    从编程语言上来说,控制面板 Istio 和 Conduit 都是使用Go语言,但是在数据面板上 Istio 是使用C++,Conduit 使用 Rust,可以看出来这两个语言都是那种比较高效的,在数据面板上面必须要使用高效的语言来完成。



    四、Istio架构

    一句话定义 Istio:一个用来连接、管理和保护微服务的开放平台。刚才也说了 Istio 是 Google 开发的,所以 Istio 今后的趋势肯定是会越来越火的,并且目前 K8S 已经把它集成到里面了,做成一个可选的组件。

    对于连接而言,Istio 它主要包含弹性、服务发现、负载均衡,管理是流量控制、策略增强,监控也有,并且安全这块 Istio 也是有考虑,Istio 是端到端的身份验证和授权,等一下会详细的介绍。

    Istio的关键特性:

    1、智能路由和负载均衡。这里的智能路由和负载均衡是属于比较高级的,不是像传统简单的随机负载均衡,而是可以基于一些数据包内部的内容来进行负载均衡。

    2、跨语言和平台的弹性。对于平台来说 Istio 是支持各种各样的平台,并且能支持A/B测试,金丝雀发布,并使用蓝绿部署运维上的一些高级功能。

    3、全面策略执行。Istio 有一个组件是专门负责保障策略能够通过一个组件下发到具体的数据面板。

    4、遥测和上报。即具体的测量以及流量的监控等。


    这个就是 Istio 整个的系统架构,如图,上面是控制面板,下面是很多数据 Envoy,很多个代理,形成一个数据面板。后面我们会对单个进行详细介绍。


    这是在 K8S 下面 Istio 部署的示意图,可以看到它们之间最关键的东西是所有服务和组件都会有一个代理,这代理是必备的,包括控制面板都会有代理。没有画的有两个东西,一个是 Ingress,一个是初始化器,初始化器主要是做代理注入。它们之间相互的交互都是通过加密,由TLS协议来完成。


    五、Istio组件

    1
    数据面板Envoy


    介绍一下 Istio 的核心组件,首先是 Istio 的数据面板 Envoy。

    Envoy 的目标是透明地处理集群内服务间、从服务到外部服务之间的出入口流量。Envoy 是用C++编写的,高并行、非阻塞。并且是可装卸的L3/4过滤器,以及L7的过滤器,最终会形成一个过滤链来对流量进行管理或者控制,Envoy 是通过 xDS 动态配置来进行接口提供。

    下面就是一些固有的功能,服务发现、健康检查。Envoy 的健康检查也做的颗粒度比较细,包含主动健康检查和被动健康检查。主动健康检查像常规的健康检查,主动地发一个健康检查的接口调用请求,查询一下。被动的是通过对其他服务的一些请求,从一些返回值进行健康检查。当然还包含高级的负载均衡,监控、跟踪这些功能。

    Envoy最关键的三个点:

    高性能。一直在强调的是数据面板必须要高性能,因为是要和业务服务部署在一起的。
    可扩展。
    可配置。具有动态配置的特性。


    Envoy 是如何做到高性能的?


    Envoy 的线程模型分为三类线程,如果做过C++开发,这种单进程多线程的架构是很常见的。Envoy 分为主线程、工作线程、文件刷新线程,其中主线程就是负责工作线程和文件刷新线程的管理和调度。而工作线程主要负责监听、过滤和转发,工作线程里面会包含一个监听器,如果收到一个请求之后会通过刚才所介绍的过滤链来进行数据过滤。前面两个都是非阻塞的,唯一一个阻塞的是这种 IO 操作的,会不断地把内存里面一些缓存进行落盘。



    服务网格所强调的另外一个功能,是动态配置不用重启,实际上是重启的,它会启动一个新的进程,然后在这进程之上进行新的策略,还有一些初始化,这时候再请求监听,之前那个进程的 socket 副本。当老的关闭链接以及退出之后,它才会接收新的,这时候就实现了对用户没有感知的重启。

    这就是它的 xDS,如图,可以看到它的密度是非常细的,


    终端发现服务(EDS),实际上就是服务的发现服务;
    集群发现服务(CDS)是为了发现集群;
    路由发现服务(RDS)是为了对路由进行一些处理;
    监听器(LDS)来动态地添加、更新、删除监听器,包括过滤链的一些管理、维护。
    另外还有刚才说到的健康检查(HDS),
    还有聚合(ADS)是对于监控指标进行聚合的接口;
    另外一个密钥发现(KDS)是和安全相关的。

    首先,如果来了一个请求,会到刚才所说的工作线程里面去,工作线程会有监听器,收到之后进行一些处理,然后要往外发,这时会调用路由的发现功能,然后再找到相应的集群,再通过这个集群找到相应的服务,一层一层的往下面调用。


    2
    控制面板Pilot

    接下来介绍的是控制面板的三大组件,第一个就是 Pilot。


    Pilot 是运行时的代理配置,刚才所说的 xDS,就是用 Pilot 来进行调用,负责把相应的一些策略,失败恢复的特性派发下去。Pilot 是负责管理所有的这些代理,代理和管理就通过 Pilot 来完成,是平台无关的一个拓扑模型。目前主要支持的是 K8S。


    Pilot 是一层抽象的独立于底层平台的模型,因为这里有个代理,对于多平台或多样性的管理架构,即适配器的架构。平台特定的适配器负责适当填充这些规范,要通过具体平台的适配器形成一些规范,和通用的模型结合,生成必须要往 Envoy 下发的数据,并且配置、推送都是由 Pilot 来完成的。


    Pilot 的整个服务发现和负载均衡,如图,Pilot 是Kubernetes DNS提供的域名进行访问,首先调用 Service B 的url,这时候 Envoy 会进行截获并处理,处理完之后会找到相应的负载均衡的池子挑选一个进行流量下发。Pilot 目前支持的这种负载均衡的方法,规划了很多种。但目前只实现了三种,前两种还是随机和轮循,多了一个最小请求的负载均衡算法。它能找到这些 Pilot 里面哪个被调用的最少,然后进行调用。

    Pilot 的一些规则配置,可以看到基本是负责规则的管理以及下发。

    路由规则。
    目的地策略。主要包含负载均衡的算法,以及对于负载均衡算法抽象的策略预演。
    出站规则。

    把这些规则分了三类,好处是对这三类都会生成一些模板。


    流量的拆分可以看到是基于标签的流量拆分,这里配置的如版本,环境,环境类型,它根据这个规则来进行流量的派发。比如说99%都发给之前版本,新版本先1%先测一下,类似于A/B测试。



    另外一个比较高级的是基于内容,因为它是L7的这种过滤,可以基于内容来过滤,并且支持表达式,这种将iPhone的流量全部导到新的服务里面去,并且有标签,版本必须得是金丝雀版本。


    3
    混合器Mixer


    Mixer 是在应用代码和基础架构之间提供一个中间层,来隔离 Enovy 和后台基础设施,这里的后台是指 Promethus,ELK 这些。

    Mixer 有三个核心特性:

    先决条件检查。负责白名单以及 ACL检测;
    配额管理。负责这种使用频率上的控制;
    遥测报告。

    总共分为两类,在生成配置模板的时候它是有两类的,第一类就是负责检查check,第二类就是负责报告reporter。



    Mixer 是采用通用的插件模型以实现高扩展性,插件被称为适配器。运维人员下发一些配置到这里面,这些模板又是由模板开发人员进行开发的,Istio提供了很多通用性的模板,上面简单地改造一下就能做出一个模板来。适配器也有很多种,各种后台、平台的都有。

    Mixer 是抽象了不同后端的策略,遥测系统的细节,它就对这两个东西进行了抽象,形成了一套抽象的东西。



    刚才介绍过适配器,再来介绍一下处理器,它是配置好的适配器,由运维人员进行配置,之后形成最终的处理器,负责真正往后台发东西。

    它封装了与后端接口所需的逻辑,指定了配置规格,以及适配器。如果要在后台进行消息交互的话,所需要的操作参数在这里也会定义。而右边就是两个模板,第一个模板是 Prometheus,它是一个处理器,下面是它的一些指标。另外一个是白名单检查的模板,提供URL,以及它请求的接口返回值。



    刚才介绍了整个通路是怎么打通的,包括适配器和处理器都是为了干这个事情,这个通路怎么建立?接下来要介绍的是这个参数怎么生成,它是请求属性到一个模板的映射结果。

    Mixer 会收到 Envoy 发过来的很多属性(请求),请求里面包含的数据都称之为属性。通过它的模板来生成相应的具体参数,这边也是刚才两个例子里面对应的模板。上面是度量指标采集用的,下面是白名单。



    这里有个遥测报告的示例,当收到一个请求之后会发生什么。它会以属性的形式,这边有个 Zipk,就直接上报了,这是因为 Envoy 原生的就支持Zipk。Envoy 支持后端监控的东西,就是 Zipk,所以它可以直接发给它。其他的需要通过 Mixer 来进行转发。




    首先它收到这个属性之后,会把这个属性生成具体的实例。根据运维人员提供的配置,Mixer 将生成的数据分发到一组适配器,适配器要根据运维人员的配置来生成具体的数据,之后就可以把刚才所生成的实例往下发了。发到后端后可以进行进一步的分析和处理。

    4
    密钥管理


    最后要介绍的就是安全相关的,Certificate Authority 这块,这是整个密钥管理的示意图,可以看到服务和 Envoy 是通过 TCP 进行交互的,但是Envoy 和 Envoy 之间是通过 MTIS 进行加密,是双向的 TIS 加密。它的好处是,会在内部的每一个服务节点之间做加密,当然这是可选的,根据性能的需求来进行选择。

    密钥管理分为四个步骤,这四步就是四个特性,第一,通过服务帐户生成的密钥和证书,然后再将密钥和证书部署到 Envoy上,它还支持周期性的对这证书进行更新,另外还支持撤销的功能。


    这是它的两种部署方式,一种 K8S 的部署方式,另外如果是虚拟机,它会单独有一个节点代理,通过节点代理来发出签名请求给CA,CA再生成密钥和证书给代理,代理再来负责部署到 Envoy上。



    具体的运行时它们都有各自的证书,开始进行双向的 TIS,这时候会到名字信息里面去查询,后端有没有权限访问,如果有的话就往下,没有就结束了。



    第三步,如果收到一个客户端的请求,会去 Mixer 里面判断一下,它是白名单上的一个判断或者是不是黑名单上的一个判断,会影响“握手”的成功与否。最终它们就形成了安全交互的通道。



    谢谢大家,今天我们主要给大家介绍一下 Istio 是什么,大家有初步的认识,并且对它里面比较关键的技术进行了介绍。


    六、Q&A

    Q1:现在有这么个项目,您怎么看像这种项目的发展?第二个问题,你们中心现在在做,您也分析的挺深入,未来是什么计划,会和paas有融合吗?

    A1:先回答第一个问题,我们可以看到不管是数据面板还是控制面板都会有很多个,但是控制面板,谷歌和IBM,刚才所说的是由三个公司来开发的,谷歌、IBM,还有Lyft,那个公司类似于滴滴那种业务的公司,它们负责Envoy的开发,数据面板是它们公司来负责。我们可以看出来它们是有点分离的感觉,对于谷歌或者IBM来说它们更关注的是控制面板,并且在控制面板和数据面板之间的接口设计的非常好,设计了一套通用的接口。它们最终是分为两个方向发展,但是都可以通过同一套标准集成起来。

    第二个问题,首先公司内部都在采用微服务,对于Istio至少要到1.0之后才会在内部环境使用,如果没问题才会逐渐往真正的对外业务使用它,包含通讯里面都可能会用它。但是对于CT领域来说的话,用这个可能代价就需要好好地评估一下了。因为性能上的问题,它毕竟还是多了一跳。如果两个服务之间的交互就相当于多了两跳,对于通信这种实时性要求非常高的领域可能会存在问题。我们也会开发自己的一套侵入式框架,可以参考Envoy的实现。


    Q2:我们现在游戏项目里面刚好也用到它。但是它有个问题,用的感觉有点大材小用,我们用它做调用链关系分析,因为我们集群开发很多游戏,每个游戏有个pilot,但是如果出了问题我不知道,那它里面的一个插片自动生成,它只能识别K8集群里面pod。如果我们想用它把K8S的集群和非K8S的集群调用,并且全部进行连接起来的话,它是否支持?
    A2:我觉得它现在由于所处在初级阶段所以暂时不支持是正常的,但它后续的发展肯定会支持,因为它们整个设计的目标就是为了达到这种服务粒度,而不仅限于K8S pod这种管理粒度。


    Q3:我有一个关于sidecar的问题,如果作为一个客户端去请求的时候应该要引流引到sidecar上面,它引流是怎么引的?如果直接转过去的话又怎么去识别目标的服务到底是什么样的?它调用的是什么服务,后端可以路由到几个上?

    A3:这个信息都是由刚才所说的pilot来负责收集,它会把这些信息下发到Envoy上,所以它在做路由算法的时候会访问,来获取它可以访问到哪些服务,它会把服务的信息找到,包括它能访问的服务池包含哪些内容,然后再通过策略进行控制。

    它是会反向再去K8S里面找到的,并不是完全Envoy自己来负责,这些信息都是由pilot来给它,拿到这些信息再做处理,最终还是会和平台结合到一起。它有一个假设,所有的平台都会实现这种服务发现的接口,并且会从服务发现的接口拿到一些必要的信息,包含你刚才说的,会转成相应的IP。


    关注数人云公众号,后台回复“127”即可获取本次演讲PPT。

    PPT下载 | 亿级用户万台服务器背后,vivo云服务容器化如何破茧化蝶?

    Dataman数人科技 发表了文章 • 0 个评论 • 1167 次浏览 • 2018-02-02 14:39 • 来自相关话题

    2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。 ...查看全部
    2018年数人云Meetup第一站,联合vivo在深圳举办 Building Microservice 系列活动第一期。本次技术沙龙vivo、中兴通讯、华为、数人云共同派出技术大咖,为开发者们带来有关微服务、容器化、配置中心、服务网格等领域的实战与干货分享。

    数人云Meetup每月一期,欢迎大家来面基、学习。本文为vivo云计算架构师袁乐林分享的“vivo云服务容器化实践”现场演讲实录。


    今天讲的内容主要是介绍技术背景,产品的技术架构,我们关键技术的实践,前车之鉴,以及对下一代云服务架构的设想。


    技术背景

    vivo这些年的业务增长非常快,用户数已经上亿,服务器到了万级,业务域好几百,后端系统的复杂度在迅速攀升,不光是运维方面、架构体系复杂度也非常高,vivo技术架构也是到了破茧化蝶的时候。

    我们做过容器、虚拟机与物理机性能对比测试。上面这张图是当时做的性能测试架构图。得出了一些测试结论:
    1.容器化app(4c8g)在性能上略优于非容器化app测试指标
    2.容器化app(32c64g)性能相较于裸跑同物理机有近4%左右性能损耗,其中TPS有3.85%损耗,平均响应时间3.95%(1毫秒)的增加,对业务请求无影响。
    3.容器化app在12h的稳定性测试中表现正常
    4.容器化app在cpu相对配额,cpu绑定以及绝对配额场景下,业务性能CPU相对配额 > CPU绑定 > 绝对配额。
    5.容器化app在组部件异常,单计算节点,控制异常场景下,容器运行正常。
    综上所述,容器化app性能上接近物理机,在多测试场景下,表现相对稳定可靠。同时,对计算密集型app,相对权重配额能实现CPU资源利用率最大化。


    vivo容器化云服务框架

    正是因为这个性能测试数据的支撑,就有了vivo容器化云服务框架,我们给它取名 Kiver,提供轻量级、高可靠的容器化生产方案。


    在这个框架之上vivo一共有八个云服务,按照后来统计数据来看,MySQL加上其他两个服务占到80%的比例,这也非常符合“二八”原则。


    vivo整个云服务容器化产品的架构,左边是运维自动化的工具集,比如日志、监控等,日志在业界应用非常广泛,我们用采集容器的数据、容器的监控指标。

    这里有两个日志,上面是中间件的业务日志平台,所有业务基于中间件日志规范,输出日志后都会送到这里面收集起来,但是这个业务日志平台功能目前比较薄弱,对新增加的一些组件,比如ECTD等不支持。vivo又引入了现在容器领域比较常见的日志方案EFK,今后会规划把两个日志整合到一起。

    vivo在运维方面做了一些工具,如 vivo MachineCtl和 KiverCtl,两个工具主要实现宿主机的自动化,简单来说可以把宿主机操作系统自动化地装起来,装完之后变成Kiver的计算节点或者控制节点。还有KiverPerfermance,是我们内嵌的一个小的性能测试插件。

    再来看右边,是vivo的基础设施,物理机和交换机,网络设备和防火墙等,上面是Docker,Docker容器虚拟化技术把物理机上面的相关资源虚拟化用起来。

    右边有 Ceph 块存储,实现数据备份,上面是vivo自研的DevOps平台,做了调度框架,右边是用harbor做的镜像仓库,再往上就是云服务Portal,前面所说的那些云服务,同时也可以跑长生命周期应用。
    宿主机自动化实践


    下面我们讲一下vivo的实践。现在物理机一旦上了规模之后,装操作系统就成为一件大事,我们提供了 vivoMachineCtl,这个工具是一个命令行给运维人员使用,可以实现宿主机集中化的参数配置和自动化。

    利用 vivoMachineCtl,首先和物理机管理卡做一个交互,交互之后拿到物理机的MAC地址,这里有个BMC,也有厂商叫iDrac卡,它可以取得这台服务器网卡的MAC地址,创建以MAC地址命名的Bootfile,指明现在需要装什么操作系统,和其他一些参数。再进一步给它一个ipmi消息对服务器复位,然后服务器开始重启。

    重启之后,服务器第一次会发dhcp请求,拿到IP地址,之后会走一个pxe的协议,拿到bootfile,下载Bootfile所指明的小系统和内存文件系统文件下来,加载到物理机中,然后开始进行操作系统安装。这就是操作系统安装的过程。操作系统安装完成之后,把安装类和文件系统切换成正在启动的文件系统,在post阶段到集中化的配置中心,把相关的配置拉下来,包括IP地址,主机名和网关等信息,这是宿主机的自动化部署。


    KiverCtl实际上就是把操作系统的宿主机变成计算节点或者控制节点。计算节点有如下几个功能:第一,基本的包安装,第二,Docker、Netplugin初始化,启动kiver-guard/flume/cadvisor容器,完成日志和监控指标的采集。

    控制节点上面有Etcd和Netmaster,也会可选地把Prometheus/alertmanager/grafana/启动起来。vivoMachineCtl和KiverCtl实现了云服务器节点从物理机到宿主机的转变。


    业务日志集成到日志平台实践

    这是vivo日志采集的实践,在宿主机上做日志分区,容器运行起来之后挂这个目录,每个容器起来之后会创建一个自己的文件目录。外面有kiver-guard,用来侦听内核文件系统的新日志文件创建的通知。

    根据通知会创建软件链接,链接到上一级Flume监控的日志目录,由Flume推到kafka。大数据平台会来消费这里的数据,业务日志平台也会消费这个数据,然后持久化到ES里,最后由中间件日志平台来实现对日志的检索和展示。


    为什么要这么做?当时用的flume版本不支持自动收集递归子目录下日志新增内容的收集,完整的文件可以收集进去,但是日志文件在递归子目录下有不停地追加是输不进去的。

    kiver-guard本身也是一个容器,它起来之后把宿主机日志目录挂上去,在容器里面侦听日志目录下的create事件。

    不管这些日志路径有多深或者在哪里,都可以链接出来。做链接的时候有一点需要注意,要确保链接过来之后文件名称是唯一的。有些容器被删除了,或者日志被轮转删除了,同样也会针对Delete事件,侦测到delete是件之后删除上层flume监控日志路径的对应链接。


    基础组件日志收集实践

    基础组件日志采用Etcd、Ceph、CentOS、Netmaster等一些网上比较热门的EFK组件,开箱即用。
    监控与告警实践


    这是监控和告警实践,在容器领域比较常见,vivo采用的是Promethus和Alertmanager。Promethus采用双节点,双拉(拉两遍),两个Promethus之间没有做主从,为了解决高可用问题,挂了一个另外一个还在。

    之后接短信邮件中心,后面接Grafana作为监控面板,前面用了telegraf。我们做的东西不仅仅有容器,还有其他的组件像Ceph。我们用Cadvisor收集容器监控指标。

    我们对集群健康做监控,也对集群资源使用情况进行监控,集群的健康性采用telegraf可以调用外部shell脚本的特性。我们在控制节点写了脚本,用来检查Etcd的健康情况,也和各个节点进行通讯,检查各个节点是不是健康。之后会返回数值,给出集群健康状态码。


    这个就是前面讲的自定义的一些监控指标,这是集群的健康检查,这是集群的资源利用率,大致两条数据链进来。一个脚本由telegraf去拉,推到Prometheus里面,最后展现在Grafana上面。另一个,由DevOps框架把数据写到Mysql里面,再由Grafana定义Mysql的软件源。

    这边拉出来的自定义的健康指标支持返回码,这个返回码需要翻译成文字,实际上Grafana已经具备这个特性,我们可以去做一个映射,比如1代表监控,2代表网络问题等等,它可以自动翻译来。
    数据持久化实践


    说到云服务大家都会关注这个问题,数据怎么做到持久化,做到不丢。容器启动的时候会挂在宿主机上面的一个数据目录,和日志类似,有容器的启动进程,直接写脚本也可以,创造二级目录。

    用主机名,是在容器默认的主机名,就是它的默认ID号。如果这个ID已经存在就不用创建,说明容器是起用一个旧的容器,最后建立软链接到数据目录。这样确保每个容器日志数据都持久化到宿主机,还可以确保容器重启后数据不丢。

    第二,数据本身有一个单独的备份系统,它会每天晚上凌晨2点跑一遍,把Mysql数据推到Ceph块存储当中,实现数据的可靠性。
    集群可靠性实践


    这是容器集群可靠性实践,最典型的是三个副本,副本能够实现数据和服务的可靠性。


    失效重试,在集群各节点提供一个crontab定时任务,每隔一段时间探测一次docker服务进程健康状况,若不健康,则拉起Docker服务进程。同时我们开启了docker的Restartalways选项,确保容器服务异常退出后,能被重新拉起来。


    关于隔离,首先是分区隔离,宿主机业务日志目录/app/log独立分区,避免日志量过大时侵占宿主机系统分区或者业务分区磁盘。


    第二,资源隔离,flume当时是跑进程的,我们做的第一件事情是进行容器化,之后做配额,限制能使用的资源使用量,避免大日志传输时侵占宿主机过多资源。

    第三,故障隔离,开启dockerlive-restore选项,保障docker服务进程不影响容器服务。
    前车之辙


    我们犯过一些错误,不负责物理机运营的童鞋可能感受不明显。如果磁盘引导分区被破坏,就可能导致操作系统被重装,这个问题是很严重的。原因也很简单,服务器一般有多引导的选项,比如磁盘、网络、CD,一般在顺序上磁盘第一,网络第二。

    但如果磁盘引导分区坏了,服务器会认为没有操作系统,然后就从第二个上引导。这时候不幸的事情是,在你的网络环境里如果之前刚好装过操作系统,采用了第三方开源的部署服务器,而没有把之前的文件删掉,那么它就会把那些操作重新装上。

    解决办法很简单,我们提供了定时任务,对两个小时前创建的引导文件,能看见它的创建时间、访问时间,并进行强制性删除。


    第二个前车之辙,在收集Ceph日志时碰到困难,当时是用fluent-plugin-ceph插件来做。具体的情况是,第一,官方配置文档不正确,因为提交者没按官方文档格式编码,导致看到的配置是一行,拿回来根本不知道怎么办。第二,它和td-agent1.0 版本不兼容。摸索出的解决方法就是图片上显示的办法。


    下一代云服务架构

    这是我们下一代云服务架构,与上一代的主要区别在于,把编排框架换成了Kubernetes。目前AI这块已经用起来了,AI部分在线上大概有一百台物理机,跑Job任务,短任务每天可以跑到三万个,一次性可以调动3000个容器,未来会把这个些换成Kubnernetes,包括我们的AI、云服务都会跑在Kubernetes上。
    XaaS on Kubernetes

    如果把云服务跑到Kubernetes上,第一个要做的事情,可能会采用ceph块存储做后面的数据和数据持久化。目前vivo已经有了数据ceph块存储,但功能还不强大。第二,要解决pod漂移调度问题,如果不用ceph块存储,pod失效调度到其他节点上有问题,调过去没用的,没有数据。
    第三,也是最常见的一个,固定POD IP,看到网上有人讨论这个事情,觉得容器坏了,没必要把容器固定起来,因为有违微服务的原则。这种观点不太对,有一些场景,比如在vivo的企业IT架构里面,很多东西都跟IP挂钩,比如安全策略,它不是跟域名挂钩,而是PODIP挂钩,交换机、防火墙等很多的配置都跟这个相关。所以vivo要干的很重要的事情,就是把POD IP固定。
    目前业界对这块也有一些实践,比如京东最近有这方面的分享,把PODIP放在一个APP的IP 小池子里面,小池子里面还有IP的话,就从小池子里拿,没有的话就从大池子里去申请。

    在微信公众号后台回复“127”,即可获取本次演讲PPT《vivo云服务容器化实践》。
    点击数人云阅读更多技术干货

    这款分布式配置中心,会是微服务的降维打击利器吗?

    Dataman数人科技 发表了文章 • 0 个评论 • 1409 次浏览 • 2018-01-25 15:39 • 来自相关话题

    本文来自1月18日数人云资深工程师在IT大咖说平台的线上直播分享。 今天主要探讨这几方面: 一、配置中心的定位 二、云化的微服务对于配置中心的要求 三、微服务配置 ...查看全部
    本文来自1月18日数人云资深工程师在IT大咖说平台的线上直播分享。

    今天主要探讨这几方面:
    一、配置中心的定位

    二、云化的微服务对于配置中心的要求

    三、微服务配置原则

    四、数人云分布式配置中心整体架构


    应DevOps和微服务而生的配置中心

    首先想跟大家分享一下,为什么会有配置中心的存在?在我早期从事软件开发时,是没有配置中心,也没有微服务的。

    以前每次系统发布,无论是大改动,还是很小很小的改动,都必须经历发布的过程。这个改动有时候小到,只是修改了某个配置文件的某个字段,也必须要重新打包,重新部署。

    而且,在企业里开发和运维的人员,往往不是同一个群组。部署时,开发人员需要为运维人员准备部署文档。这个过程中,经常会由于沟通协调不到位,无法第一时间预测到所有问题,导致在正式上线时,被用户第一时间察觉到上线出了问题,或者部署不正确等,导致一些非常严重的后果。

    随着时间的推移,软件工程界出现了新的名词--DevOps。开发和运维人员共同协作进行产品的部署上线。在DevOps时代,如何将概念通过一些IT的手段转化为直接的生产力。因为每次发布改动越大,发布的频率越高,系统的风险就越大。

    所以业界急需一种技术手段,来协助开发、部署和运维三方面的人员,在不断的迭代过程中,减少这种风险。配置能不能是一种动态的配置?而不再需要去做一些静态配置。基于这种业界的风险,就有了去做配置中心的冲动。于是,市面上出现了分布式的配置中心。

    无论是分布式的配置中心,还是普通配置中心,它到底在配置什么东西?如果把时间往前推一段,通过SSH登陆服务器修改配置的那个时代,配置中心的作用其实不大。

    到了2010年之后,业界出现了微服务,分布式的配置中心才正式地光明正大的走向舞台。为什么呢?因为要结合分布式配置中心+微服务,才能真正实现我们所理解的DevOps。


    微服务配置原则

    Heroku创始人AdamWiggins发布了一个“十二要素应用宣言(TheTwelve-Factor App)”,为构建使用标准化流程自动配置,服务界限清晰,可移植性高,基于云计算平台,可扩展的服务配置提供了方法论:

    1.配置是可分离的,可从微服务中抽离出来,任何的配置修改不需要动一行代码。

    2.配置应该是中央的 通过统一的中央配置平台去配置管理不同的微服务

    3.配置中心必须必须可靠切稳定地提供配置服务。

    4.配置是可追溯的,任何的配置历史都是可追溯,被管理且可用。

    在云服务时代,对微服务做配置,对它有什么样的要求呢? 首先必须基于镜像管理部署,有自己相应独立的配置,而且程序包不可以因为环境的改变而更改。也就是说,它是独立于环境的不可变的程序包。

    其次所有的微服务通过环境变量或者配置存储时,在启动的那一刻,就可以做配置,也可以通过动态的修改实时生效。 微服务启动时配置 一个微服务从打包、上线、部署,打包以后,会在启动阶段从配置Configuration Repository 里面拉取它的配置,通过注册与发现,注册在注册中心里,在启动时,把服务中心的配置拉取到本地,成为应用的一部分。

    并且在服务运行过程中,实时动态监听配置的变更,达到有新的配置时马上下发到微服务,使配置有实时生效的效果。

    配置中心的定位

    有了以上这种业务需求,到底要做一个怎样的配置中心?数人云认为,这个配置中心必须有一致性的K-V存储中心,K-V存储就是说,一个K对应一个V,而且这种存储必须持久化、可追溯。 它必须是可以集中统一配置,实时推送,以及马上生效。

    所有配置都必须实现灰度更新与回滚。所谓灰度发布,是说一个微服务集群里面,比如有个订单系统,做了一些配置上的更新。想在小范围探讨一下,实验一下这个配置对业务有怎样的影响,这时就用到灰度更新这个概念。

    灰度更新是说,通过Data center或静态IP,指定某个配置只对某几个IP,或者Datacenter里面的某个服务生效,其他的不在这个范围内的服务,不会受到影响。观察效果,如果OK,就把这个整体配置全面推送到所有的微服务。如果效果不满意,就把配置回滚到原来的状态。

    全量更新,灰度更新,或者回滚,必须是可在任何时候查看,在某一个任意的时刻,回滚到某一个历史点的配置。 最后一个是要有多集群的启动,所谓多集群的启动就是,我们把配置存储的时候,必须存储在一个多集群的环境里面,以达到物理隔离的目的。

    另外还有一些原则,业务无关性、 Open API、配置生效监控。就是说配置中心必须提供API给第三方的系统来使用。配置的生效监控是,必须实时知道,有哪些服务拉取了配置,是否已经生效,或者这个配置的效果如何? 配置中心的支撑体系 第一种运维管理体系类似于偏静态类的配置,在启动时通过配置文件直接拉取读业务。

    另外一种是开发管理体系,偏动态管理,代表的是一种程序或者在运行过程中,通过实时的变更配置内容而实时生效,达到的一种效果。

    一个健全的配置中心应该支持这两种运维体系。 配置中心的微服务兼容 配置中心必须对现有主流的一些开发框架有API方面的兼容。数人云在做配置中心时,很难预估第三方来调用服务时,到底搭配在什么样的开发框架上?通常来说,配置中心不可能兼容市面上所有的东西,数人云选择重要的框架来做深度兼容。

    首先,对Spring Cloud,阿里的Dubbo这些常规的第三方云服务框架做了API方面的兼容。目前来说,至少要支持SpringCloud、Dubbo、Nginx、Tomcat、Logback等各方面的配置。 这种配置各有各的特性,所以我们就挑选了一些有经典案例的,通用性的东西来做配置的集成,比如原生支持SpringBoot、Spring Cloud,集成支持k8s,就是k8s容器。

    数人云hawk分布式统一配置中心

    数人云分布式统一配置中心,取名Hawk。Hawk基于ETCD打造,主要解决把开发人员从复杂的业务流程和烦琐的配置中解脱出来,让开发人员只关注自己的业务代码,把运维、配置这些剥离出去。同时降低服务部署、发布过程中的风险。 基于微服务体系理念打造的分布式统一配置中心Hawk支持多种类型配置:如Spring Cloud、 Dubbo、Kubernetes Configmap、Logback、Linux Environment,具有完善的配置管理流程、配置实施推送、支持多集群多环境、多版本控制,更提供配置细粒度的管理如灰度管理、任意版本重置等丰富功能。 整个体系兼容开源社区的Spring Cloud Config以及Kubernetes的Configmap,极大降低使用者的学习门槛以及业务对平台的耦合。相应的管理流程也规范了配置的使用,降低配置带来的发布错误等。

    功能特性

    对比主流框架,数人云HAWK有如下一些重要的功能特性: 支持配置实时推送以及实时生效,在程序的运行过程中,不能说把服务停下来才能更新,必须实时配置,实时生效。 支持多版本管理,配置不管哪个版本,都可以随时查看、查阅以及激活历史的版本,并做发布。 支持多集群环境,多环境配置。通过数据库或者后端存储,以达到支持SIT、UAT环境的体系。

    优美的监控台,提供多维度Dashboard以及监控视图,支持配置灰度和回滚。 支持数据全局备份和回复,进一步提升配置数据的容灾能力。 提供OpenAPI,支持多系统集成的便利手段,支持配置应急预案处理。 配置流程管理,完善的配置流程管理,确保配置下发前必须获得确认和授权。 认证与授权,提供LDAP集成,以及多角色权限管理。 支持操作审计,确保配置操作有据可查。 支持多种配置文件,Spring Cloud Config、Dubbo、Logback、Nginx、LinuxEnvironment、Tomcat。

    支持Spring Cloud服务治理配置和管控,支持Spring Cloud自有的Hystrix的微服务治理如熔断、Fallback等等。 无缝集成Kubernetes的Configmap以及Secrets,并提供增强的企业管理流程。 Hawk整体架构 首先接入第一层是网关,整体的存储通过Hawk Server,下发到ETCD集群,ETCD集群再同步到K8S容器运行的平台。 刚才有同学说Hawk跟阿波罗有相似的地方。在研究对比时,我们觉得阿波罗出于业务需求,有一些比较复杂的地方,决定把流程简化。

    先从数据迁移的状态简化成简单的几部分。比如新建一个配置,要么配置就被删除了,直接一步到位。如果没有这样做,就面临几种情况,这个配置是否要小范围的去做一些试探性的发布,这种情况可以走灰度发布,状态变成灰度中,配置不允许更改。要么就是两条路走,全量发布到所有服务上。要么就是放弃灰度回到之前的状态,放弃灰度后会去到已修改的状态。

    另外一种情况,新建一个配置,直接全量发布,状态变成已发布状态,这时候是可更改的。但是每一次的更改,还是会回到原来那个状态。这个更改要做灰度吗?还是做发布?还是对发布有点后悔,不打算更改了?这时,从历史版本里面找一个合适的版本,激活,然后再做一次发布,通过几个简单的回路,涵盖了大部分的业务场景。 配置数据状态变迁 Hawk Portal是主体的配置界面,用户在界面上对配置进行输入、增删、改查的管理。这些资料会有两份,一份做通过Mysql做本地存储,另一份通过Hawk Server直接同步到ETCD。

    由于HAWK Server是同步到ETCD里面,也就是说ETCD相当于另外一个数据库,这当中不存在数据之间的互相抄送,从而减低丢失数据的风险。持久化,是说研发和运维在后台做数据迁移,或者数据监控时更有把握,更方便。 数人云HAWK其实有两个ETCD,一个ETCD是做注册发现的,Hawk Server、Hawk Portal都会注册在里面,作为相关的组件。类比Spring Cloud Eureka,Eureka是注册在Eureka Server里面的一个内存列表,集群里面所有Server共享这个内存信息。这个过程数人云做了简化,所有信息全部注册在ETCD里面。

    ECTD集群由于是共享的,组件的状态和一致性得到保障。Portal和Server之间不再通过Portal注册在Server并通过心跳来维持关系而是通过共享持久化的ETCD,保证数据在任意时刻所看到的状态都是一致的,从而保证了服务的注册,以及服务发现的稳定性。

    Hawk和Eureka 选择的路径不一样。Eureka是比较重量级的,HAWK则简化了这个配置,简化这种代码的复杂性,重点提高系统的完整性,打造系统闭环,通过一些相对简单的方法,提高服务的稳定性。 配置一旦通过Hawk Portal潜入本地数据库,微服务的注册服务是怎么实现配置呢?当Portal写入配置到本地数据库时,同时也会通过服务Sever去同步到ETCD,ETCD里面存储的信息,是一个持久化的数据。

    通过Server实时从ETCD拉取配置,有时是运行的时候拉取,有时是启动时拉取。启动时拉取有两种策略,启动的时候拉取配置,存储到本地作为静态文件的配置,运行时候拉取,动态的变更实时生效。

    在Web层其实也有一些问题需要解决,比如,因为我们不是一个开发框架,是奔着一个开源系统的方向去,所以要解决服务跟浏览器之间的授权。 数人云现在的做法是在本土数据库存储一些用户的信息,但是并没有采用传统意义上的建Session来做验证和授权,而是通过动态下发JWT的形式,每一个请求动态下发,根据我个人用户的一些信息生成,每次的请求一来一去都有交换新的Token,每个Token实时生效并有续约的功能,来代替传统意义上的Session。 配置中心集成第三方框架与类库 Hawk有一个第三方类库集成,操作流程是这样的:操作者通过UI调用HAWK后端的portal,通过Hawk Server把配置写入ETCD。另外一些运营者和开发人员所持有的第三方服务,通过集成Hawk Client来读取配置。 Hawk也有新的迭代,跟Sharding-JDBC做了集成,JDBC 2.0的一些趋势跟HAWK系统做了深度集成。服务通过实时读取配置中心配置实现动态更改分库分表的策略。

    Q&A Q1:实时更改分布分表策略?
    A1:可以,Sharding JDBC 2.0就是重点实现这个功能,这也是Hawk与Sharding JDBC深度合作的成果

    Q2:历史数据怎么办?
    A2:历史的数据其实都是持久化存储的。如果有一天要回到某个历史版本,可以随时通过调取已发布的历史。Hawk有一个版面叫发布历史。这里,每一个配置都有配置历史可追寻,可以随时查看或激活某个版本。激活的时候,需要用户去选择要做一个全链发布还灰度发布,还是说什么都不做。

    Q3:是否支持ServiceMesh?
    A3:目前来说ServiceMesh还是一个比较新的东西。如果ServiceMesh是独立配置的话,其实可以支持到。但是ServiceMesh有非常多的特性,还不敢说100%可以支持得到。其实数人云也在做ServiceMesh相关的项目,就是说它以后还是有非常大的可能,还是要集成ServiceMesh配置中心里面做一个闭环。目前这个版本支持一些比较轻量的配置。 ServiceMesh中文网微信公众号(ID:servicemesh),大量Istio、Conduit官方文档翻译版和技术干货文章,欢迎关注。

    Q4:开发环境和生产环境用哪一步骤?
    A4:SIT和UI其实可以部署在一起,通过存储隔离来做到。但是,不建议生产也部署在一起,生产还是建议独立部署。生产还是物理隔离是最好的方案。

    Q5:配置中心和服务中心是不是两个系统?
    A5:目前来说是两个系统,但是现在的想法是暂时的。现在的想法是是不是把配置中心再扩大一点,不叫配置中心了,而是叫比如微服务服务平台。服务平台里把配置中心跟注册中心都作为一个组件融入进去,把一些跟业务无关的东西抽离出来,搭载一些公共的平台上,以组件的形式去融入到这个平台里面去。

    Q6:开源有本地缓存吗?
    A6:目前来说没有本地缓存,是直接获取ETCD的东西,所以它是实时的,但是注册中心里面会加入缓存。

    Q7:一般哪些信息通过配置中心配置?
    A7:非业务的东西,比如平时开发一个系统,或者开发一个第三方系统,我们都有所有的配置文件,比如数据库的连接,跟治理相关的东西,或者一些国外的引用,都可以通过配置中心来配置,并且这种配置不仅仅是在页面上的配置,有一个插件给它,启动之后直接把这些配置导入到配置中心里面去,还可以通过启动的时候把这种配置下发到本地,形成一个本地的静态配置。

    Q8:server如果断开怎么处理?
    A8:因为Server是多Server集群的,如果断开了并不是说通过指定IP地址去访问这个Server,而是通过注册与发现去访问这个Server,如果Server断开了,其实也就是说他们之间没有心跳了,他们就会尝试去ETCD里面请求一个新的连接,而这个连接也会通过注册与发现,会发现其他的Server,这样的话他们就会连接。

    docker + kubernetes=共生?相爱相杀?

    Dataman数人科技 发表了文章 • 0 个评论 • 5211 次浏览 • 2018-01-23 10:38 • 来自相关话题

    2017年的云计算市场,有一个领域获得了空前的关注 -- Kubernetes。 Kubernetes可以追溯到2014年,当时Google公开发布了该项目的开源代码。2017年,Kubernetes广受欢迎,几乎所有的主要IT供应商都支持这个平台。 ...查看全部
    2017年的云计算市场,有一个领域获得了空前的关注 -- Kubernetes。 Kubernetes可以追溯到2014年,当时Google公开发布了该项目的开源代码。2017年,Kubernetes广受欢迎,几乎所有的主要IT供应商都支持这个平台。

    小数今天推送的这篇文章,为您揭示Kubernetes与Docker容器之间是怎样的关系?对企业客户又意味着什么?



    Kubernetes是一个开源项目,提供容器编排,部署和管理功能。自 2015 年 7月以来,它一直是由Linux基金会下的云原生计算基金会(CNCF)运营。尽管Kubernetes不再只是Google的一个项目,Google仍然贡献了远大于比其他任何机构的代码量。

    将AIX应用程序迁移到云的最佳实践
    Kubernetes 2017年如此耀眼,2018年Kubernetes将继续成为一支重要的力量。要理解这点,首先要认识到这项技术和云计算的完美契合之处。

    在过去三,四年中,越来越多的企业选择使用Docker容器来部署云工作负载。Docker容器提供的既是运行容器化应用程序的运行时,也是封装和交付容器应用的格式。容器提供了直接在虚拟机管理程序内部改善可移植性和效率的承诺。

    随着容器使用量的增长,需要对容器集群进行编排,调度和控制。这就是Kubernetes适合的地方。Kubernetes提供了大规模运行容器的编排系统和管理平台。还提供了一系列API抽象,使其他技术可以插入,使平台具有很强的可扩展性,并且能够支持各种不同的供应商部署用例。

    比其核心编排能力更重要的是,Kubernetes在2017年成为实现多云世界的事实平台。虽然AWS在2017年继续主导公有云,但企业仍然希望能够在多个云上部署和运行应用程序。

    容器提供了运行应用程序的基本包装,可以在任何支持容器的云上部署。有了Kubernetes,就有了一个平台,可以帮助企业在运行Kubernetes的云或本地部署管理容器的部署和编排。

    云中的Kubernetes
    一颗种子总会发芽,结出硕果。在作为开源技术的短短3年时间里,Kubernetes成为基于容器的工作负载的默认编排引擎。虽然捐赠的是1.0版本,但是谷歌在大规模运行容器方面有十年的研究和经验。

    Google是否在内部使用Kubernetes?来自Kubernetes博客:“Google上的许多开发人员都是以前在Borg项目上的开发人员。我们已经将Borg的最佳创意融入了Kubernetes,并试图解决用户在多年来与Borg确定的一些痛点。”

    谷歌在一些内部项目中使用Kubernetes的声音很清晰,且很快就会改变一些现有的关键产品。即使未来需要更好的展示,Kubernetes也可以轻松定制 – 最大的好处是可以根据需要将自定义组件与现有组件进行混合和匹配。

    以下是Google在过去几年 Kubernetes 的搜索量增长情况:


    01.png



    Google在Kubernetes上运行的Linux容器(LXC)并不是那么容易处理,而且需要掌握更多的专业知识。

    2017年初,Kubernetes 只支持谷歌云平台(GCP)和谷歌Kubernetes引擎(GKE),但是在一年中,扩展到包括所有三家主要的公有云供应商。

    二月份,微软正式加入支持Kubernetes的行列,宣布 Azure容器服务支持Kubernetes。去年11月,Kubernetes在亚马逊弹性容器服务(Amazon EKS)首次亮相。

    除了公有云支持外,CNCF在9月份还宣布了Kubernetes认证服务提供商计划。该计划现在有25个合作伙伴公司开发和销售自己的Kubernetes发行版并提供管理服务。为了确保不同Kubernetes供应商和平台之间的互操作性,CNCF于2017年11月推出了认证Kubernetes计划,目前拥有42个成员公司。

    Docker
    Kubernetes部署大多使用Docker作为默认的容器引擎,除此之外还有CoreOS的rkt等。就其本身而言,Docker有一个叫做Swarm的自身的编排系统,首次亮相于2014年12月。

    在许多企业的容器部署中,多数情况是Docker容器引擎正在被使用,Kubernetes被选择作为编排工具,而不是Swarm。10月17日,在与Kubernetes进行了三年的市场竞争之后,Docker Inc.宣布也将支持Kubernetes。

    要清楚的是,Docker公司并没有放弃自己的Swarm容器编排系统; 相反,它同时支持Swarm和Kubernetes,让企业可以选择想要使用的平台。

    在接受eWEEK 视频采访时,Docker首席执行官史蒂夫·辛格(Steve Singh)解释了为什么选择拥抱Kubernetes。Singh说:“Kubernetes为我们所做的事情是消除了任何潜在的混乱和冲突。我们有爱Kubernetes的客户,也有爱Docker Swarm的客户,不应该强迫客户在两者之间做出选择,而是让他们选择想要使用他们的东西。 ”

    Kubernetes之前的Docker 让容器变得更酷,更易用。由Docker公司推出的Docker 在LXC功能的扩展之外,增加了多种功能。包括跨机器的可移植部署,版本控制,组件重用以及现在的 Docker Hub ,它提供了“开发测试流水线自动化,100,000个免费应用程序,公共和私有注册中心”。

    以下是Google for Docker搜索量增长的图表:


    02.png


    Kubernetes 1.9和超越
    2017年,Kubernetes更新了四个主要版本,增加了新的特性和功能。第一个主要版本是3月27日推出的Kubernetes 1.6,带来了新的可扩展性和稳定性功能。Kubernetes 1.7于6月29日发布,提供了帮助管理和保护容器基础设施的新功能。第三个版本是1.8更新,于9月28日推出,并支持基于角色的访问控制(Role-Based Access Control,RBAC)。

    Kubernetes 1.9是2017年的最后一次重大更新,于12月15日正式推出。Kubernetes 1.9的亮点是Apps Workloads API,它为 Kubernetes 中长时间运行无状态和有状态工作负载提供了基础。

    这是Kubernetes转型的一年,2017开源的努力始于一家公有云供应商,终于年底支持所有三家主要的公有云提供商。该项目也从Docker竞争对手的角色转到被Docker拥抱。多云的承诺长久以来只是一个承诺。作为一个可以在任何公有云提供商上启用容器应用程序工作负载的抽象层,随着Kubernetes 2017年的兴起,2018多云承诺将成为现实。

    二、

    Kubernetes正在巩固自己作为事实上的容器编排引擎的地位,而Docker帮助实现了这一点。尽管Docker一直是领先的容器技术,但容器编排市场还没这么清晰。2017年末,随着包括Docker在内的主要云平台提供商支持Kubernetes和一些令人惊讶的CNCF成员资格的增加,这种情况发生了变化。

    正确的时机

    “时机就是一切”,对于Kubernetes来说,这似乎是正确的。通过让容器更易用,Docker正在推动Kubernetes的发展。事实上,它已经成为每个公司发展的共生关系 。使用Kubernetes的人越多,使用Docker的也会越多,反之亦然。

    根据 Portworx2017年度容器采购调查 (2017年2月至3月完成),有两项统计数据显示:
    “对于拥有超过5000名员工的公司,Kubernetes的使用率为48%,主要编排工具占33%。”
    “79%的样本选择Docker作为主要容器技术。”

    为了进一步加持 Kubernetes 领导者地位,大型云计算和软件供应商们纷纷加入,以支持Docker容器的工作负载。

    Kubernetes商业化产品

    自从开源以来,Kubernetes有很多商业化产品,在过去的几个月,这个list上取得了重大且令人印象深刻的突破。

    以Google(Google ContainerEngine),Red Hat(OpenShift),CoreOS(Tectonic),Canonical和 Apprenda 为长期商业供应商(长期以月计)。微软和VMware也已经提供了对Kubernetes的支持,最近已经全面all-in 推出。

    2017 Kubernetes 得胜之年

    2017年下半年,主要云服务商将Kubernetes添加到其核心产品中。值得注意的公告包括:
    亚马逊网络服务(AWS)于八月份以白金会员 (最高级别) 加入了CNCF。虽然AWS加入CNCF与 Kubernetes 没有直接关系,但AWS拥有大量客户在运行容器和Kubernetes。

    之后,10月份,Cloud Foundry基金会宣布了由Kubernetes提供支持的Cloud Foundry Container Runtime(CFCR),而Pivotal Cloud Foundry(与VMware合作 )则 于10月份在VMworld 宣布了Pivotal Container Service(PKS)。Pivotal和VMware都作为CNCF的白金会员注册; 再次,可用的最高水平。

    VMware正在与Kubernetes合作的事实是一个明确的信号,Kubernetes和容器希望保持相关性。许多人质疑容器和云计算是否会取代虚拟机。虽然专家认为他们在企业中存在共存的空间,但可以看看VMware这位虚拟化之王的明显转变。

    在十月之后,Microsoft 将 Azure容器服务 (ACS)更名 为AKS,K代表Kubernetes。这与他们以前的观点有很大的转变,即 ACS的好处之一是它支持多种编排工具 。

    即使是Docker Inc.也已经屈服,最近在其Docker企业版框架中添加了本地Kubernetes支持。这对Kubernetes来说是一个重大的胜利,并将推动Docker自己的编排平台Docker Swarm的未来发展。

    Docker甚至委托独立基准测试来对比Swarm和Kubernetes 。两者肯定都有用例,但Kubernetes得到Google支持的事实是经过了战斗性测试的(还记得 PokémonGO吗 ? ),并且拥有巨大的社区支持,企业把它看作标准的容器编排引擎。

    这对企业意味着什么?

    Kubernetes和Docker一直在坚持。随着公司迁移到云端,他们会发现他们有一些需求PaaS或IaaS最适合,还有一些其他需求容器(有些人称之为CaaS)会更适合。

    为了享受到上云带来的好处,企业正在转向DevOps和云原生开发。采用DevOps时,企业开始使用运行在容器中的微服务,将应用程序构建为独立的组件。这些团队将会变得更小( 亚马逊CTO Werner Vogels 创造了“双比萨团队”(two-pizza team)一词),并且能够独立于应用的其他组件更新其“服务”的功能。

    通过将开发工作分解为专注于解耦服务的小型团队,企业可以扩展开发工作,并更快地为客户/用户提供价值。现在,已然不是每六个月更新一次的代码库,而是按需随时进行更新。

    自动化是复杂的抽象,为了使这项工作自动化,提供一个简单,可重复的方式来安全地交付和部署软件,团队会更频繁地执行。

    技术的抽象和多样使监控成为难题的重要部分。企业拥有数千个独立移动的部件,其中许多可能显示为传统监控解决方案的黑盒子。随着企业迈向云原生,越来越多的应用程序正在云中运行,专门设计并运行良好的监控方法至关重要。

    2018年将发生什么?Kubernetes给业务需求和企业客户能够带来的改变已经明晰,作为构建和运行云原生应用的平台乘胜追击,能够在多大比例的企业实现软着陆呢?大概套用那句老话是最准确的:前途是光明的,道路是曲折的。


    原文链接:
    1、2018 is the year of Kubernetes – with some help from Docker
    https://www.tuicool.com/articles/QBFjAf6
    2、2017 Year in Review: Kubernetes Enables a Multi-Cloud World
    http://www.eweek.com/cloud/2017-year-in-review-kubernetes-enables-a-multi-cloud-world
    数人云是国内第一款企业级云操作系统,基于Mesos的容器生产环境。可以让用户像用一台电脑一样使用整个集群,在云端一键安装Docker,Spark,Hadoop等各种应用,并保障应用的稳定高效运行。