微服务如何持续“无痛”演进?统一分布式配置中心不可或缺

dataman 发表了文章 • 0 个评论 • 283 次浏览 • 2018-04-11 15:33 • 来自相关话题

小数导读:


今天为大家分享,数人云3月31日Building Microservice NO.2北京站meetup上,晓阳老师为大家带来的关于《微服务配置中心架构解析》的实录分享。

今天讲的主题是微服务配置中心的架构解析。


微服务的前世今生

这段英文是2014年martin flower在微博上发的关于微服务的一个定义,我们在讲配置中心之前,先讲讲微服务,大概了解一下配置中心在微服务里到底是什么样的地位,处在哪一个环节上。


2014年算是微服务的元年,那年有几个比较大的事情,一个是微服务概念的提出,其次是Netflix的OSS框架经过实践之后终于落地,Pivotal公司将Netflix的OSS应用于Spring,成就了SpringCloud体系。

 
三四年过去以后,技术上也层出不穷,包括我们的docker等其它的,但是在这中间微服务配置中心这个概念始终是比较重要的。微服务从开发到最后配置上线,配置是很重要的。

 
再看第二页,它有一个Configuration repository,实际它并不是只在这有,因为微服务配置中心是从微服务的构建,包括它测试一直到它上线,始终贯穿在其中的。


这是我最近梳理的微服务基础架构,这里面大的模块主要有七个方面吧,包括服务的监控、服务的容错,以及后台服务等等。最中间的是配置服务,配置中心是属于运行时候支撑服务的。对于微服务系统来说是配置中心是不可或缺的重要组件。


在这里我们提出一个观点:“每一个大型的分布式微服务系统,都需要一个配置中心。”为什么呢?


做过单体应用系统的同学可能都会有比较直观的感受,那个时候系统里有配置文件,测试完之后要上线怎么办,把这个程序部署好,登陆到服务器上,手动的把配置文件里的内容改成正确的生产环境参数,就完成了单体应用系统的配置管理。


那么到了微服务里之后,这个状况就变了。首先微服务系统里的一个应用程序,我们可能会把它拆成很多个微服务;再加上它天然的分布式特性,每一个微服务可能会有很多的实例,分布在不同的服务器上,用户从测试环境或者是UIT环境验证完了以后要上生产,还需要靠我们运维人员挨个改配置吗?这是不太现实的。



一个系统是这样的,如果系统多了呢,这个问题就越发的明显。现在大家都在讲敏捷开发,为什么要用微服务,就是为了快速的迭代,快速的上线。这样的话,对于我们的运维人员来说,按照以前的方式改配置基本上是不可行了。如果系统规模比较大,像阿里有很多个数据中心,而且还要求异地多活怎么办?




我们就希望能够有这么一个集中化管理的配置中心,这样的话,用户通过配置中心管理控制台,能够把我所要的配置中心管理起来,它能够对应到下面所有的服务器上,所有微服务的每一个实例。当然它有一些要求,首先程序和配置要分离。




其次我们的配置是集中管理。后面我的程序包可以适应多个环境,SIT环境、UAT环境,从开发敏捷到最后上生产,包都是同一个包,它能适应多种环境,我们需要上线的时候改它的配置就行了,后面就有服务端口往下推配置,我的客户端可以拉配置,对一个配置中心来说,它可能是有历史版本的。你经常要多个版本,那么配置数据要持续化,对于所有配置的更改和下发,作为我们企业来讲,会有审计和管理的要求,还要考虑配置中心自己的数据要不要容灾,微服务的实例多了以后,我们还要考虑它的性能,考虑它的时效性。如果你的规模不大的话,配置中心是很容易实现的。但是如果你的规模大,很多的问题会暴露的比较明显。




下面来看一下业界微服务中心的发展现状,我个人觉得阿里Diamond是当之无愧的第一,不管是从应用规模还是数据体量来看都是如此,因为现在整个阿里系所有的系统都是通过他们的配置中心做配置管理,它应该是全世界最大的配置中心,但是这个好象没有开源。




开源我们了解一些,像spring-cloud-config,Netflix archaius,Ctrip apollo,Disconf,后面有一张片子对spring-cloud-config进行了详细说明。另外现在在公有云环境也有云化的配置服务,包括亚马逊的AWS-config,包括阿里的ACM。




这个是我们对开源的几个东西加上我们自己对这个配置中心有一个产品叫hawk,做了一些对比,因为各家的产品,从开源到现在,在不同的历史时期,因为技术在不断的往前发展,有一些方面是另外一些问题。并不是说有一个产品能够完全适应我们80-90%的需求。

Spring Cloud微服务配置中心

Hawk是我们从去年开始做的,它应该是比较贴合spring-cloud真实的环境,我们为什么要做配置中心?我们是一家做PaaS云的公司,在给客户实施云PaaS平台时候,就发现客户对配置中心有很强的需求,客户经常会问你们有没有相关的产品,或者别家有没有类似的产品。之前也考虑过引入一个三方的PaaS公司给客户去用。但是因为客户始终会有一些个性化的需求要重新实现,这个时候你去改别人的代码就会有各种问题,我们就想我们能不能自己做这个东西?




我们首先做了一些对比,这张表里的内容就是详细比对的结果,这里就不一一展开说明了。这张片子是spring-cloud-config配置中心的一个典型例子。大家可以看到,spring-cloud-config配置中心是存在git上的,配置数据改动以后,它实际上是通过spring-cloud-bus发业务消息让应用系统进行更新。




这张图比较清晰的描述了大概的流程:服务启动的时候,它需要从本地去拿config-server的地址,或者是通过注册中心拿这个地址。后面他会去调config-server里面的接口拿这个配置。如果git仓库有修改,POST请求configserver的/bus/refresh接口,config通过消息总线通知服务节点。服务节点接到通知后,重新到config获取新配置。




按照这种架构来看的话,spring-cloud-config并不是production ready的,在网络上也没有看到有谁真正拿这个spring-cloud-confif应用到他们的生产环境(包括老外)。




我们感觉云化微服务它就这么几个配置原则,第一要完全分离,你要部署的程序和相关对应的配置。程序包对于任何环境都是不可变的,我们可以通过环境变量或者是配置在程序启动的时候把配置注入进去。




这是在当时做hawk的时候,我们对微服务配置中心提出的功能性的需求,主要分三个,一个是按照技术功能,一个是按照管理功能,后面是加了一个集成,集成这一块主要是第三方的一些东西。




我们认为配置中心需要具有这么几个要素(当然不仅限于这几个要素)。前面提到的hawk数据要持久化存储,这个地方我们用的是mysql。可以横向扩展的缓存集群,我们用的是etcd。所有的配置,我要让它生效的时候,才会从mysql里拿出来,然后推到etcd。这样的话,所有的客户端实际上是从etcd拿这个配置信息。实际应用中,用户还可以去拉取,或者由服务端进行推送,这一块我们用client提供支撑。对于整个过程的管理,我们会提供一个UI-portal。这是我们认为配置中心必须要具备的几个比较大的要素,还有一些比较细的,片子里没有完全列完。




这是微服务配置中心的一个系统架构,像刚刚提到的,首先支持认证。这个在企业客户推的时候,企业客户一般都有自己的ldap。我们可以接他们的ldap,登陆到配置中心(hawk)做一些微服务管理的事情。




下面可以看到,控制台对应的是后台的Hawk sever,同时它还会接受调用,配置数据下发的时候,是从mysql关系型数据库拉出来,然后放到ETCD里,数据中心里所有的这些APP,或者是微服务实例,通过etcd把整个配置信息拉取到自己的运行环境里。如果做的更好一些的话,实际上在客户端还要具备一个缓存的功能,客户端拉取一次就有缓存,这样配置中心本身的健康状况对用户其他的服务是没有影响的。Configmap 和Secrets是k8s的概念,hawk给他们提供了管理界面,这是hawk与k8s平台结合使用的一个亮点。







这张片子描述了hawk的数据流程,就是我一个配置新建了以后,我会把它全量发布,实际上是它状态的一个变化。如果要回滚或者是修改,有一个历史版本。如果这条配置删掉的话,它会被删除。还有那些针对某些特定实例做灰度,这一部分修改了之后做灰度发布。这就是整个微服务配置中心数据状态的一个变化。




数人云微服务配置中心

数人云配置服务中心产品的名字叫hawk,它是基于Springcloud config打造,完全兼容Springcloud config API,配置更新通过GRPC双向流实时推送,采用ETCD作为配置数据的强一致性存储,另外还支持其他的企业管理需求,包括LDAP用户认证,授权管理等等,配置信息需要经过审批流程,才能下发到生产环境上去用。图的下方是OpenAPI和插件体系,目前主要是跟当当的sharding-jdbc做了一个集成。




配置中心不是只能用来去做程序的配置版,现在大家都在提治理,对于数据治理这一块,Hawk集成了sharding-jdbc,在应用程序运行期,可以支撑动态的分库分表。




我们的hawk里面的存储,首先是持久的数据,所有的数据都是存在service,发布可能是要跟etcd,上面会有一些Service,整个是一个high-level架构。




内部的架构大概是讲了一个流程,运维人员对配置数据做了修改并且发布之后,hawk把发布的数据推到可横向扩展的edct的集群里,这个主要是考虑到微服务规模会越来越大,需要edct有一个更高的并发管理,我们所有的第三方应用实际上是通过SDK去访问Hawk里面的数据,这也是一个更细化配置下来的,这就不展开说了。







这张图是hawk的领域模型,大家都知道,领域模型是在需求层面做分析用的,从图上可以看到,hawk需要支持不同环境的配置隔离、历史版本等等。







那么配置中心还能做什么?这里有两点,一是服务治理,二是数据治理,我们在这两个方面做了一些简单的尝试。因为配置中心每一个微服务用hawk提供的SDK去连接我们的HawkSever,可以把它本身注册到HowkSever上,这样的话,配置中心就可以承担服务治理中的ControlPlane的职责,它可以把服务治理相关的配置下发给实际的执行模块,比如dubbo,或者是SpringCloud集成的Netflix治理工具库(比如hystrix以及ribbon)。




数据治理主要是说在运行过程当中,对于动态的分库分表提供动态刷新和治理功能。因为目前只做了不到一年,很多功能现在不是特别的完美,后面我们还会继续完善这个东西。




最后提一下这个中心应该怎么部署,理论上来说,我可以只布一套hawk去管多个环境,实际情况是什么样呢?我们现在在客户现场实施云平台的时候发现,客户的开发环境和生产环境一般是物理隔离的,因为物理隔离了,所以一套配置中心就不能既支持开发环境,又支持生产环境,所以推荐的部署方式是这样:在开发测试环境里部署一套,在生产环境部署另外一套。生产环节里Hawk的用户是运维人员,开发环境里Hawk的用户是开发人员。

总结

今天主要分享的重点就是配置中心在微服务架构体系中的地位,其次是业界微服务配置中心发展情况,后面我们把数人云的hawk架构给大家做了一个简单的介绍。




拥抱配置中心,配置中心本身并没有多么高深的技术,但是在微服务这个领域不可或缺,谢谢大家。



PPT下载:

3月31日 数人云联合ServiceComb社区 Building Microservice NO.2北京站,嘉宾分享PPT,关注数人云公众号,后台回复331,即可获取下载链接~




添加小数微信:xiaoshu062


备注公司、姓名、职位

小数将拉您进入相应技术群





  查看全部
小数导读:


今天为大家分享,数人云3月31日Building Microservice NO.2北京站meetup上,晓阳老师为大家带来的关于《微服务配置中心架构解析》的实录分享。

今天讲的主题是微服务配置中心的架构解析。


微服务的前世今生

这段英文是2014年martin flower在微博上发的关于微服务的一个定义,我们在讲配置中心之前,先讲讲微服务,大概了解一下配置中心在微服务里到底是什么样的地位,处在哪一个环节上。


2014年算是微服务的元年,那年有几个比较大的事情,一个是微服务概念的提出,其次是Netflix的OSS框架经过实践之后终于落地,Pivotal公司将Netflix的OSS应用于Spring,成就了SpringCloud体系。

 
三四年过去以后,技术上也层出不穷,包括我们的docker等其它的,但是在这中间微服务配置中心这个概念始终是比较重要的。微服务从开发到最后配置上线,配置是很重要的。

 
再看第二页,它有一个Configuration repository,实际它并不是只在这有,因为微服务配置中心是从微服务的构建,包括它测试一直到它上线,始终贯穿在其中的。


这是我最近梳理的微服务基础架构,这里面大的模块主要有七个方面吧,包括服务的监控、服务的容错,以及后台服务等等。最中间的是配置服务,配置中心是属于运行时候支撑服务的。对于微服务系统来说是配置中心是不可或缺的重要组件。


在这里我们提出一个观点:“每一个大型的分布式微服务系统,都需要一个配置中心。”为什么呢?


做过单体应用系统的同学可能都会有比较直观的感受,那个时候系统里有配置文件,测试完之后要上线怎么办,把这个程序部署好,登陆到服务器上,手动的把配置文件里的内容改成正确的生产环境参数,就完成了单体应用系统的配置管理。


那么到了微服务里之后,这个状况就变了。首先微服务系统里的一个应用程序,我们可能会把它拆成很多个微服务;再加上它天然的分布式特性,每一个微服务可能会有很多的实例,分布在不同的服务器上,用户从测试环境或者是UIT环境验证完了以后要上生产,还需要靠我们运维人员挨个改配置吗?这是不太现实的。



一个系统是这样的,如果系统多了呢,这个问题就越发的明显。现在大家都在讲敏捷开发,为什么要用微服务,就是为了快速的迭代,快速的上线。这样的话,对于我们的运维人员来说,按照以前的方式改配置基本上是不可行了。如果系统规模比较大,像阿里有很多个数据中心,而且还要求异地多活怎么办?




我们就希望能够有这么一个集中化管理的配置中心,这样的话,用户通过配置中心管理控制台,能够把我所要的配置中心管理起来,它能够对应到下面所有的服务器上,所有微服务的每一个实例。当然它有一些要求,首先程序和配置要分离。




其次我们的配置是集中管理。后面我的程序包可以适应多个环境,SIT环境、UAT环境,从开发敏捷到最后上生产,包都是同一个包,它能适应多种环境,我们需要上线的时候改它的配置就行了,后面就有服务端口往下推配置,我的客户端可以拉配置,对一个配置中心来说,它可能是有历史版本的。你经常要多个版本,那么配置数据要持续化,对于所有配置的更改和下发,作为我们企业来讲,会有审计和管理的要求,还要考虑配置中心自己的数据要不要容灾,微服务的实例多了以后,我们还要考虑它的性能,考虑它的时效性。如果你的规模不大的话,配置中心是很容易实现的。但是如果你的规模大,很多的问题会暴露的比较明显。




下面来看一下业界微服务中心的发展现状,我个人觉得阿里Diamond是当之无愧的第一,不管是从应用规模还是数据体量来看都是如此,因为现在整个阿里系所有的系统都是通过他们的配置中心做配置管理,它应该是全世界最大的配置中心,但是这个好象没有开源。




开源我们了解一些,像spring-cloud-config,Netflix archaius,Ctrip apollo,Disconf,后面有一张片子对spring-cloud-config进行了详细说明。另外现在在公有云环境也有云化的配置服务,包括亚马逊的AWS-config,包括阿里的ACM。




这个是我们对开源的几个东西加上我们自己对这个配置中心有一个产品叫hawk,做了一些对比,因为各家的产品,从开源到现在,在不同的历史时期,因为技术在不断的往前发展,有一些方面是另外一些问题。并不是说有一个产品能够完全适应我们80-90%的需求。

Spring Cloud微服务配置中心

Hawk是我们从去年开始做的,它应该是比较贴合spring-cloud真实的环境,我们为什么要做配置中心?我们是一家做PaaS云的公司,在给客户实施云PaaS平台时候,就发现客户对配置中心有很强的需求,客户经常会问你们有没有相关的产品,或者别家有没有类似的产品。之前也考虑过引入一个三方的PaaS公司给客户去用。但是因为客户始终会有一些个性化的需求要重新实现,这个时候你去改别人的代码就会有各种问题,我们就想我们能不能自己做这个东西?




我们首先做了一些对比,这张表里的内容就是详细比对的结果,这里就不一一展开说明了。这张片子是spring-cloud-config配置中心的一个典型例子。大家可以看到,spring-cloud-config配置中心是存在git上的,配置数据改动以后,它实际上是通过spring-cloud-bus发业务消息让应用系统进行更新。




这张图比较清晰的描述了大概的流程:服务启动的时候,它需要从本地去拿config-server的地址,或者是通过注册中心拿这个地址。后面他会去调config-server里面的接口拿这个配置。如果git仓库有修改,POST请求configserver的/bus/refresh接口,config通过消息总线通知服务节点。服务节点接到通知后,重新到config获取新配置。




按照这种架构来看的话,spring-cloud-config并不是production ready的,在网络上也没有看到有谁真正拿这个spring-cloud-confif应用到他们的生产环境(包括老外)。




我们感觉云化微服务它就这么几个配置原则,第一要完全分离,你要部署的程序和相关对应的配置。程序包对于任何环境都是不可变的,我们可以通过环境变量或者是配置在程序启动的时候把配置注入进去。




这是在当时做hawk的时候,我们对微服务配置中心提出的功能性的需求,主要分三个,一个是按照技术功能,一个是按照管理功能,后面是加了一个集成,集成这一块主要是第三方的一些东西。




我们认为配置中心需要具有这么几个要素(当然不仅限于这几个要素)。前面提到的hawk数据要持久化存储,这个地方我们用的是mysql。可以横向扩展的缓存集群,我们用的是etcd。所有的配置,我要让它生效的时候,才会从mysql里拿出来,然后推到etcd。这样的话,所有的客户端实际上是从etcd拿这个配置信息。实际应用中,用户还可以去拉取,或者由服务端进行推送,这一块我们用client提供支撑。对于整个过程的管理,我们会提供一个UI-portal。这是我们认为配置中心必须要具备的几个比较大的要素,还有一些比较细的,片子里没有完全列完。




这是微服务配置中心的一个系统架构,像刚刚提到的,首先支持认证。这个在企业客户推的时候,企业客户一般都有自己的ldap。我们可以接他们的ldap,登陆到配置中心(hawk)做一些微服务管理的事情。




下面可以看到,控制台对应的是后台的Hawk sever,同时它还会接受调用,配置数据下发的时候,是从mysql关系型数据库拉出来,然后放到ETCD里,数据中心里所有的这些APP,或者是微服务实例,通过etcd把整个配置信息拉取到自己的运行环境里。如果做的更好一些的话,实际上在客户端还要具备一个缓存的功能,客户端拉取一次就有缓存,这样配置中心本身的健康状况对用户其他的服务是没有影响的。Configmap 和Secrets是k8s的概念,hawk给他们提供了管理界面,这是hawk与k8s平台结合使用的一个亮点。







这张片子描述了hawk的数据流程,就是我一个配置新建了以后,我会把它全量发布,实际上是它状态的一个变化。如果要回滚或者是修改,有一个历史版本。如果这条配置删掉的话,它会被删除。还有那些针对某些特定实例做灰度,这一部分修改了之后做灰度发布。这就是整个微服务配置中心数据状态的一个变化。




数人云微服务配置中心

数人云配置服务中心产品的名字叫hawk,它是基于Springcloud config打造,完全兼容Springcloud config API,配置更新通过GRPC双向流实时推送,采用ETCD作为配置数据的强一致性存储,另外还支持其他的企业管理需求,包括LDAP用户认证,授权管理等等,配置信息需要经过审批流程,才能下发到生产环境上去用。图的下方是OpenAPI和插件体系,目前主要是跟当当的sharding-jdbc做了一个集成。




配置中心不是只能用来去做程序的配置版,现在大家都在提治理,对于数据治理这一块,Hawk集成了sharding-jdbc,在应用程序运行期,可以支撑动态的分库分表。




我们的hawk里面的存储,首先是持久的数据,所有的数据都是存在service,发布可能是要跟etcd,上面会有一些Service,整个是一个high-level架构。




内部的架构大概是讲了一个流程,运维人员对配置数据做了修改并且发布之后,hawk把发布的数据推到可横向扩展的edct的集群里,这个主要是考虑到微服务规模会越来越大,需要edct有一个更高的并发管理,我们所有的第三方应用实际上是通过SDK去访问Hawk里面的数据,这也是一个更细化配置下来的,这就不展开说了。







这张图是hawk的领域模型,大家都知道,领域模型是在需求层面做分析用的,从图上可以看到,hawk需要支持不同环境的配置隔离、历史版本等等。







那么配置中心还能做什么?这里有两点,一是服务治理,二是数据治理,我们在这两个方面做了一些简单的尝试。因为配置中心每一个微服务用hawk提供的SDK去连接我们的HawkSever,可以把它本身注册到HowkSever上,这样的话,配置中心就可以承担服务治理中的ControlPlane的职责,它可以把服务治理相关的配置下发给实际的执行模块,比如dubbo,或者是SpringCloud集成的Netflix治理工具库(比如hystrix以及ribbon)。




数据治理主要是说在运行过程当中,对于动态的分库分表提供动态刷新和治理功能。因为目前只做了不到一年,很多功能现在不是特别的完美,后面我们还会继续完善这个东西。




最后提一下这个中心应该怎么部署,理论上来说,我可以只布一套hawk去管多个环境,实际情况是什么样呢?我们现在在客户现场实施云平台的时候发现,客户的开发环境和生产环境一般是物理隔离的,因为物理隔离了,所以一套配置中心就不能既支持开发环境,又支持生产环境,所以推荐的部署方式是这样:在开发测试环境里部署一套,在生产环境部署另外一套。生产环节里Hawk的用户是运维人员,开发环境里Hawk的用户是开发人员。

总结

今天主要分享的重点就是配置中心在微服务架构体系中的地位,其次是业界微服务配置中心发展情况,后面我们把数人云的hawk架构给大家做了一个简单的介绍。




拥抱配置中心,配置中心本身并没有多么高深的技术,但是在微服务这个领域不可或缺,谢谢大家。



PPT下载:

3月31日 数人云联合ServiceComb社区 Building Microservice NO.2北京站,嘉宾分享PPT,关注数人云公众号,后台回复331,即可获取下载链接~




添加小数微信:xiaoshu062


备注公司、姓名、职位

小数将拉您进入相应技术群





 

DevOps很难?这里有一份11大最流行的开源DevOps工具清单

dataman 发表了文章 • 0 个评论 • 241 次浏览 • 2018-04-11 15:31 • 来自相关话题

 
 

导读:
 
实施DevOps最佳实践的公司证明,它们在实现和设计IT工具和实践方面更加高效灵活,从而以更低的成本产生更高的收入。对于希望接受比特币等新发明的传统组织来说,采用DevOps工具提供了一致性、质量和效率。
 
开源DevOps工具被用来简化开发和部署过程。使用开源软件的好处是,它是通过增强的协作构建的,可以驱动创新,并增强处理市场和需求转变的灵活性。对代码的可见性有助于提高整体质量和安全性,并帮助公司防止厂商锁定专有供应商。
 
如果你希望加快已有应用,或刚刚开始使用DevOps,下面是11款开源DevOps工具值得考虑。
 
 Behat
Behat是一个用于自动测试业务所期望的PHP框架。它是一个行为驱动的PHP开源开发框架。该工具支持通过测试自动化,故意发现和持续通信提供重要的软件。
 
 Watir
Watir是一款Web应用程序跨平台开源测试工具。它是用于自动化Web浏览器的Ruby库的最灵活可靠的工具。像人一样,这个工具与浏览器通信,以便验证文本,填写表单并单击链接。
 
 Supergiant
Supergiant建立在Kubernetes之上,是一个用于容器管理的开源平台。它被用于Kubernetes在几分钟内部署在多个云上。SupergiantAPI用于简化生产部署。 借助Supergiant的打包算法,可以降低硬件成本,并且只需使用计算效率所需的硬件。
Ansible
Ansible自动执行与IT操作相关的各种常见任务,例如应用程序部署,配置管理和云配置。 它由Red Hat拥有。集成了许多其他著名的DevOps工具,包括Jenkins,JIRA,Git和其他许多工具。在GitHub上可以找到免费的开源版本。红帽提供三种付费版本 - 高级,标准和自助 - 价格根据所需的支持级别和生产节点数量而不同。
 
 Nagios
基础设施监控是一个有众多解决方案的领域,从Zabbix到Nagios到各种其他开源工具。尽管目前市场上有很多新的工具,Nagios是一个完善的监控解决方案,由于大量的贡献者社区为其创建插件,它非常高效。Nagios有能力在不同的可视化报告和展示中提供结果。
 SaltStack
SaltStack是Salt的付费企业版本。Salt是用于事件驱动编排,云控制,配置自动化和远程执行的高度灵活,功能强大且智能的开源软件。 它帮助DevOps公司编排有效的代码生产流程,并保持复杂的基础架构调整为最佳应用交付和业务服务。 Saltstack协调DevOps的价值链,帮助部署和配置动态应用程序。
 Chef
Chef可以使用单一工具管理传统和云环境。在保持高可用性的同时,Chef承诺加速云的采用。Chef开发工具包提供开发所需的工具,并在将变更部署到生产环境之前,在本地测试来自工作站的基础设施自动化代码。在Chef站点上,提供了许多技术资源和大量文档,其中包括旨在帮助组织过渡到DevOps并扩展其DevOps实现的各种资源。
 Docker
Docker的可移植性正在改变IT环境。可移植性通过其特殊的容器化技术实现的,这种技术经常在独立的设备中发现。它包了一个应用程序需要运行所需要的一切东西:库、系统工具、运行时等等。由于这个原因,应用程序可以以相同的方式运行,而不考虑它们的部署位置。被称为Docker Engine的是负责创建和运行Docker容器的工具。Docker Hub是基于云的服务应用程序,它包含了应用程序共享和工作流自动化的概念。
 Git
近年来,Git在管理源代码方面非常流行。它已经成为著名的用于托管开放源码项目的站点。由于处理合并和分支的方便性,从其他版本控制管理中脱颖而出。许多DevOps团队利用它来管理应用程序的源代码。它具有强大的拉请求和分叉特性。还包括与Jenkins链接的插件,以促进部署和集成。
 Hudson
Hudson是一个管理和监控持续测试和集成的工具。Hudson的关键特性包括对各种系统的支持,包括源代码管理、应用服务器、代码分析工具、测试框架、构建工具、测试失败的实时通知、变更集支持,以及易于安装和配置的过程。一个巨大的插件库可以进一步扩展它的功能。
 Puppet
不管它在哪里运行,Puppet都承诺了一种标准的操作和交付软件的方式。Puppet可以自动部署,以提高可审核性、可靠性和敏捷性。Puppet的产品在完整的软件交付生命周期中提供持续的自动化和交付。最新版本的Puppet提供了节点管理器和Puppet应用程序,可帮助处理大量动态的可变的系统。
结论
DevOps的世界充满了独特而优秀的开源工具。与以前相比,上述流行的DevOps工具可以有效地弥合开发和生产环境之间的差距。企业可以选择适合业务需求的工具,并且可以立即看到业务运营中的差异。而且,这些不同的DevOps工具不仅可以单独运行,还可以很好地协同工作。
 
原文链接:
11 Popular Open Source DevOpsTools Worth Knowing
https://devops.com/most-popular-open-source-devops-tools/?utm_source=tuicool&utm_medium=referral
  
 
相关阅读:
复杂性排第5,当红炸子鸡K8S对用户来说最大的槽点是啥?
天啦噜!看国外大神如何用Docker+Jenkins&CI/CD打造微服务架构?
远离神乎其神,从Uber微服务看最佳实践如何炼成?
换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?
kubernetes落地 |不捧不踩,国外公司向Kubernetes迁移实践
细数20年间开源带给世界的那些改变,及5大开源趋势预测
后Kubernetes时代,带你系统梳理K8S 12大关键特性
女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?
【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构
有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
 
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群
 

  查看全部
 
 

导读:
 
实施DevOps最佳实践的公司证明,它们在实现和设计IT工具和实践方面更加高效灵活,从而以更低的成本产生更高的收入。对于希望接受比特币等新发明的传统组织来说,采用DevOps工具提供了一致性、质量和效率。
 
开源DevOps工具被用来简化开发和部署过程。使用开源软件的好处是,它是通过增强的协作构建的,可以驱动创新,并增强处理市场和需求转变的灵活性。对代码的可见性有助于提高整体质量和安全性,并帮助公司防止厂商锁定专有供应商。
 
如果你希望加快已有应用,或刚刚开始使用DevOps,下面是11款开源DevOps工具值得考虑。
 
 Behat
Behat是一个用于自动测试业务所期望的PHP框架。它是一个行为驱动的PHP开源开发框架。该工具支持通过测试自动化,故意发现和持续通信提供重要的软件。
 
 Watir
Watir是一款Web应用程序跨平台开源测试工具。它是用于自动化Web浏览器的Ruby库的最灵活可靠的工具。像人一样,这个工具与浏览器通信,以便验证文本,填写表单并单击链接。
 
 Supergiant
Supergiant建立在Kubernetes之上,是一个用于容器管理的开源平台。它被用于Kubernetes在几分钟内部署在多个云上。SupergiantAPI用于简化生产部署。 借助Supergiant的打包算法,可以降低硬件成本,并且只需使用计算效率所需的硬件。
Ansible
Ansible自动执行与IT操作相关的各种常见任务,例如应用程序部署,配置管理和云配置。 它由Red Hat拥有。集成了许多其他著名的DevOps工具,包括Jenkins,JIRA,Git和其他许多工具。在GitHub上可以找到免费的开源版本。红帽提供三种付费版本 - 高级,标准和自助 - 价格根据所需的支持级别和生产节点数量而不同。
 
 Nagios
基础设施监控是一个有众多解决方案的领域,从Zabbix到Nagios到各种其他开源工具。尽管目前市场上有很多新的工具,Nagios是一个完善的监控解决方案,由于大量的贡献者社区为其创建插件,它非常高效。Nagios有能力在不同的可视化报告和展示中提供结果。
 SaltStack
SaltStack是Salt的付费企业版本。Salt是用于事件驱动编排,云控制,配置自动化和远程执行的高度灵活,功能强大且智能的开源软件。 它帮助DevOps公司编排有效的代码生产流程,并保持复杂的基础架构调整为最佳应用交付和业务服务。 Saltstack协调DevOps的价值链,帮助部署和配置动态应用程序。
 Chef
Chef可以使用单一工具管理传统和云环境。在保持高可用性的同时,Chef承诺加速云的采用。Chef开发工具包提供开发所需的工具,并在将变更部署到生产环境之前,在本地测试来自工作站的基础设施自动化代码。在Chef站点上,提供了许多技术资源和大量文档,其中包括旨在帮助组织过渡到DevOps并扩展其DevOps实现的各种资源。
 Docker
Docker的可移植性正在改变IT环境。可移植性通过其特殊的容器化技术实现的,这种技术经常在独立的设备中发现。它包了一个应用程序需要运行所需要的一切东西:库、系统工具、运行时等等。由于这个原因,应用程序可以以相同的方式运行,而不考虑它们的部署位置。被称为Docker Engine的是负责创建和运行Docker容器的工具。Docker Hub是基于云的服务应用程序,它包含了应用程序共享和工作流自动化的概念。
 Git
近年来,Git在管理源代码方面非常流行。它已经成为著名的用于托管开放源码项目的站点。由于处理合并和分支的方便性,从其他版本控制管理中脱颖而出。许多DevOps团队利用它来管理应用程序的源代码。它具有强大的拉请求和分叉特性。还包括与Jenkins链接的插件,以促进部署和集成。
 Hudson
Hudson是一个管理和监控持续测试和集成的工具。Hudson的关键特性包括对各种系统的支持,包括源代码管理、应用服务器、代码分析工具、测试框架、构建工具、测试失败的实时通知、变更集支持,以及易于安装和配置的过程。一个巨大的插件库可以进一步扩展它的功能。
 Puppet
不管它在哪里运行,Puppet都承诺了一种标准的操作和交付软件的方式。Puppet可以自动部署,以提高可审核性、可靠性和敏捷性。Puppet的产品在完整的软件交付生命周期中提供持续的自动化和交付。最新版本的Puppet提供了节点管理器和Puppet应用程序,可帮助处理大量动态的可变的系统。
结论
DevOps的世界充满了独特而优秀的开源工具。与以前相比,上述流行的DevOps工具可以有效地弥合开发和生产环境之间的差距。企业可以选择适合业务需求的工具,并且可以立即看到业务运营中的差异。而且,这些不同的DevOps工具不仅可以单独运行,还可以很好地协同工作。
 
原文链接:
11 Popular Open Source DevOpsTools Worth Knowing
https://devops.com/most-popular-open-source-devops-tools/?utm_source=tuicool&utm_medium=referral
  
 
相关阅读:
复杂性排第5,当红炸子鸡K8S对用户来说最大的槽点是啥?
天啦噜!看国外大神如何用Docker+Jenkins&CI/CD打造微服务架构?
远离神乎其神,从Uber微服务看最佳实践如何炼成?
换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?
kubernetes落地 |不捧不踩,国外公司向Kubernetes迁移实践
细数20年间开源带给世界的那些改变,及5大开源趋势预测
后Kubernetes时代,带你系统梳理K8S 12大关键特性
女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?
【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构
有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
 
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群
 

 

复杂性排第5,当红炸子鸡K8S对用户来说最大的槽点是啥?

dataman 发表了文章 • 0 个评论 • 200 次浏览 • 2018-03-29 10:44 • 来自相关话题

导读:

在使用或部署Kubernetes时,人们面临着非常多的问题。虽然Kubernetes所面临的一些挑战是独一无二的,但更多挑战都是典型的使用大量技术所带来的成长中的痛苦。最近CNCF主导了一项有关“Kubernetes生态系统状况”的一项调研,对于当红炸子鸡Kubernetes来说,哪些方面的挑战是最突出的?小数还另外翻译了K8S环境中4种最可能的威胁模型。

1

“Kubernetes生态系统状况”阐述了在选择容器编排解决方案时不同标准的重要性,以及阻碍Kubernetes采用的主要因素。与安全性或资源优化等标准相比,扩展性成为编排解决方案的基本要求。其中最大的挑战是,使用Kubernetes经常需要改变IT组织的几个部分的角色或职责。


CNCF最近的调查询问到人们在使用或部署容器时面临的挑战。在我们对数据的独立分析中,我们将答案发布在“Kubernetes Deployment & Security Patterns”一文中,并将焦点集中于使用Kubernetes管理容器的组织。这提供了一种方法来说明Kubernetes用户所面临的问题。
 


安全、存储、网络是最重要的挑战

研究结果表明,在对Kubernetes的普遍批评中,复杂性仅仅是排在第五位的挑战。领先的是与基础设施相关的挑战。在Kubernetes用户中,有46%的人提到了安全问题,网络和存储排在第二和第三位。

KubeCon +CloudNativeCon会议召集了采用者和技术专家,进一步推进云原生计算的教育和发展。供应商中立的技术有该领域专家和关键维护者的支持,比如Kubernetes, Prometheus, gRPC,Envoy,OpenTracing等等。

Twistlock利用先进的智能,机器学习功能以及自动策略创建和执行功能,保护当今应用程序免受未来的威胁。作为第一个端到端的容器安全解决方案,Twistlock是专门为交付现代安全性而构建的。

Alcide提供网络安全平台,专为由多个编排系统运营的容器、虚拟机和裸金属数据中心组合而设计。Alcide通过简化和自动控制为DevOps,安全和工程团队授权,以管理和保护不断发展的数据中心和混合云。

23%的人表示,基于负载的扩展部署是一个挑战。这意味着许多需求得到满足Kubernetes实际上是在帮助扩展它应该做的事情。在列表的底部,10%的问题得到了供应商的支持。很少有人抱怨Kubernetes支持供应商的原因之一是,许多部署并不依赖于供应商的分销。展望未来,提供高质量服务的可能性很大,因为CNCF最近推出了Kubernetes认证服务供应商计划,确保服务提供商达到一定的能力。








超过40%的人认为安全、网络和存储是与容器相关的挑战。



偏大型的组织有更多的挑战

和其他研究一样,我们发现较大的组织更倾向于将许多问题列为他们所关心的挑战。例如,1000名或更多员工的组织中,有55%的人认为安全是一个挑战,而不到100名员工的组织中只有39%的人这么认为。这种情况下,与可靠性等其他类别一样,大型企业的需求与小企业不同。


在其他领域,例如网络,与仅使用容器数量相比,IT基础设施(带宽和站点数量)的规模和广度可能会给Kubernetes带来更多独特的挑战。事实上,在拥有6个或6个以上集群的组织中,以网络作为挑战的比例从42%上升到53%。


一些挑战不符合上述模式。对于存储,一种解释是技术“问题”不是基于可扩展性的。在监管方面,中型企业更有可能面临挑战。正如我们之前在文章中提到的,对容器运营的监控,小企业通常不需要创建正式的监控流程,而大型企业则有资源来创建更健壮的、自定义的监视系统。被困在中间的是那些拥有100到999名员工的企业。







图1.8:在拥有1000名或更多员工的组织中,安全与网络更大可能被列为与容器相关的挑战。
 


本地部署 VS 云部署

影响组织与容器相关的挑战的另一个因素是,它们是否只将容器部署到公有云或在本地服务器上。在只使用本地服务器的容器中,存储是最常见的挑战。这是因为这些企业需要管理自己的存储基础设施,甚至可能由一支独立的IT团队来处理。








图1.9:54%仅供本地使用的容器用户面临存储挑战,而只有34%的公有云组织面临存储挑战。


对于只在公有云上使用容器的组织来说,监控和日志记录常常被认为是一个挑战。尽管云供应商应该支持可扩展性,但只有使用本地服务器才能使用容器的组织很难说扩展部署是一项挑战。


CNCF的调查还询问了几种类型的云原生基础设施和工具,其中一些是专门针对与Kubernetes合作的。本系列的下一篇文章将讨论Kubernetes用户用来解决他们面临的挑战的最常用工具。



2

4种Kubernetes威胁模型

在Kubernetes环境中,通常有四种类型的威胁,不管部署模型是什么(有一些边界情况例外):


1.旨在危害Kubernetes控制的外部攻击:所有连接系统均存在此威胁。在Kubernetes集群环境中,这代表攻击者获得对系统的访问权限,或者损害某些会影响系统安全的控制。

2.受影响的容器或节点:如果Kubernetes控制的环境中存在恶意容器或集群内的恶意节点,那么对其他节点或集群有什么影响?你能否在节点和集群内有效地包含“爆炸半径”?

3.妥协的凭证:当Kubernetes管理员的凭据被泄露时会发生什么情况?这对集群有多大影响?

4.滥用合法权限:当系统配置错误,缺乏控制或操作不严密时,可能会发生这种情况。

这些不同的威胁可能会导致大量妥协和不受欢迎的情况,包括特权提升,敏感数据泄露,运营折中或违反合规政策。

KubeCon + CloudNativeCon会议聚集了采用者和技术专家,进一步推动云原生计算的教育和发展。供应商中立的特色领域由领域专家和关键维护者的支持,如Kubernetes,Prometheus, gRPC,Envoy,OpenTracing等等。


引起相当多关注的攻击场景之一是“爆炸半径”——受损容器对同一节点上的其他容器会造成多大的损害,或者受损的节点会对集群的其余部分造成多大的损害? 对于Kubernetes部署的所有安全考虑都是基于这些威胁模型以及最小化“爆炸半径”的需要。
 


外部攻击

在Kubernetes环境中,外部可访问的组件将受到外部攻击。这些组件可以包括API服务器、kubelet和etcd。

为了减轻外部攻击的威胁,确保只有必要的Kubernetes服务被公开。始终执行身份验证并为任何公开的服务配置正确的网络安全策略。
 


妥协的容器

最终,Kubernetes管理在容器中运行的工作负载。如果一个容器被破坏,问题是容器是否可以升级权限来控制其他容器或集群。

Kubernetes的隔离机制,比如命名空间或网络分割,以及一些内置的os级控制,调节容器可以访问的内容,可以帮助限制受影响的容器的影响。另一个控制用户应该注意的是限制能够以特权模式运行的容器数量的能力——如果一个特权容器被破坏,它将会比普通的容器造成更多的伤害。


妥协的凭证

当合法的用户凭证被破坏时,系统中可能有恶意用户。因此,正确地规范和限制用户对集群资源的访问并密切监视用户操作是非常重要的。

为了减少恶意用户的影响,需要强制执行最小权限访问、基于角色的访问控制或其他细粒度访问控制。
 


滥用特权

如果系统配置不正确,可能导致滥用用户权限。例如,如果网络策略不限制pods或命名空间之间访问,用户可能能够读取其他命名空间的通信流,而这些命名空间最初不应访问。

防止滥用特权的主要防御措施是适当强化。确保所有系统组件(如容器,pod,命名空间和kubelets)都得到了强化,以显著降低特权滥用的可能性。


另一个重要的防御是授权控制。Kubernetes支持插件架构,它允许包含复杂的授权逻辑。正确设计和实施授权;这是反对特权滥用最有效的武器之一。



原文链接:

1、The TopChallenges Kubernetes Users Face with Deployment

https://thenewstack.io/top-cha ... ment/

2、4 Threat Models for Kubernetes Deployment Security

https://www.tuicool.com/articles/AfI7RbQ 



相关阅读:


天啦噜!看国外大神如何用Docker+Jenkins&CI/CD打造微服务架构?

远离神乎其神,从Uber微服务看最佳实践如何炼成?
换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
导读:

在使用或部署Kubernetes时,人们面临着非常多的问题。虽然Kubernetes所面临的一些挑战是独一无二的,但更多挑战都是典型的使用大量技术所带来的成长中的痛苦。最近CNCF主导了一项有关“Kubernetes生态系统状况”的一项调研,对于当红炸子鸡Kubernetes来说,哪些方面的挑战是最突出的?小数还另外翻译了K8S环境中4种最可能的威胁模型。

1

“Kubernetes生态系统状况”阐述了在选择容器编排解决方案时不同标准的重要性,以及阻碍Kubernetes采用的主要因素。与安全性或资源优化等标准相比,扩展性成为编排解决方案的基本要求。其中最大的挑战是,使用Kubernetes经常需要改变IT组织的几个部分的角色或职责。


CNCF最近的调查询问到人们在使用或部署容器时面临的挑战。在我们对数据的独立分析中,我们将答案发布在“Kubernetes Deployment & Security Patterns”一文中,并将焦点集中于使用Kubernetes管理容器的组织。这提供了一种方法来说明Kubernetes用户所面临的问题。
 


安全、存储、网络是最重要的挑战

研究结果表明,在对Kubernetes的普遍批评中,复杂性仅仅是排在第五位的挑战。领先的是与基础设施相关的挑战。在Kubernetes用户中,有46%的人提到了安全问题,网络和存储排在第二和第三位。

KubeCon +CloudNativeCon会议召集了采用者和技术专家,进一步推进云原生计算的教育和发展。供应商中立的技术有该领域专家和关键维护者的支持,比如Kubernetes, Prometheus, gRPC,Envoy,OpenTracing等等。

Twistlock利用先进的智能,机器学习功能以及自动策略创建和执行功能,保护当今应用程序免受未来的威胁。作为第一个端到端的容器安全解决方案,Twistlock是专门为交付现代安全性而构建的。

Alcide提供网络安全平台,专为由多个编排系统运营的容器、虚拟机和裸金属数据中心组合而设计。Alcide通过简化和自动控制为DevOps,安全和工程团队授权,以管理和保护不断发展的数据中心和混合云。

23%的人表示,基于负载的扩展部署是一个挑战。这意味着许多需求得到满足Kubernetes实际上是在帮助扩展它应该做的事情。在列表的底部,10%的问题得到了供应商的支持。很少有人抱怨Kubernetes支持供应商的原因之一是,许多部署并不依赖于供应商的分销。展望未来,提供高质量服务的可能性很大,因为CNCF最近推出了Kubernetes认证服务供应商计划,确保服务提供商达到一定的能力。


微信图片_20180329103703.jpg



超过40%的人认为安全、网络和存储是与容器相关的挑战。



偏大型的组织有更多的挑战

和其他研究一样,我们发现较大的组织更倾向于将许多问题列为他们所关心的挑战。例如,1000名或更多员工的组织中,有55%的人认为安全是一个挑战,而不到100名员工的组织中只有39%的人这么认为。这种情况下,与可靠性等其他类别一样,大型企业的需求与小企业不同。


在其他领域,例如网络,与仅使用容器数量相比,IT基础设施(带宽和站点数量)的规模和广度可能会给Kubernetes带来更多独特的挑战。事实上,在拥有6个或6个以上集群的组织中,以网络作为挑战的比例从42%上升到53%。


一些挑战不符合上述模式。对于存储,一种解释是技术“问题”不是基于可扩展性的。在监管方面,中型企业更有可能面临挑战。正如我们之前在文章中提到的,对容器运营的监控,小企业通常不需要创建正式的监控流程,而大型企业则有资源来创建更健壮的、自定义的监视系统。被困在中间的是那些拥有100到999名员工的企业。

微信图片_20180329103205.jpg



图1.8:在拥有1000名或更多员工的组织中,安全与网络更大可能被列为与容器相关的挑战。
 


本地部署 VS 云部署

影响组织与容器相关的挑战的另一个因素是,它们是否只将容器部署到公有云或在本地服务器上。在只使用本地服务器的容器中,存储是最常见的挑战。这是因为这些企业需要管理自己的存储基础设施,甚至可能由一支独立的IT团队来处理。


微信图片_20180329103226.jpg



图1.9:54%仅供本地使用的容器用户面临存储挑战,而只有34%的公有云组织面临存储挑战。


对于只在公有云上使用容器的组织来说,监控和日志记录常常被认为是一个挑战。尽管云供应商应该支持可扩展性,但只有使用本地服务器才能使用容器的组织很难说扩展部署是一项挑战。


CNCF的调查还询问了几种类型的云原生基础设施和工具,其中一些是专门针对与Kubernetes合作的。本系列的下一篇文章将讨论Kubernetes用户用来解决他们面临的挑战的最常用工具。



2

4种Kubernetes威胁模型

在Kubernetes环境中,通常有四种类型的威胁,不管部署模型是什么(有一些边界情况例外):


1.旨在危害Kubernetes控制的外部攻击:所有连接系统均存在此威胁。在Kubernetes集群环境中,这代表攻击者获得对系统的访问权限,或者损害某些会影响系统安全的控制。

2.受影响的容器或节点:如果Kubernetes控制的环境中存在恶意容器或集群内的恶意节点,那么对其他节点或集群有什么影响?你能否在节点和集群内有效地包含“爆炸半径”?

3.妥协的凭证:当Kubernetes管理员的凭据被泄露时会发生什么情况?这对集群有多大影响?

4.滥用合法权限:当系统配置错误,缺乏控制或操作不严密时,可能会发生这种情况。

这些不同的威胁可能会导致大量妥协和不受欢迎的情况,包括特权提升,敏感数据泄露,运营折中或违反合规政策。

KubeCon + CloudNativeCon会议聚集了采用者和技术专家,进一步推动云原生计算的教育和发展。供应商中立的特色领域由领域专家和关键维护者的支持,如Kubernetes,Prometheus, gRPC,Envoy,OpenTracing等等。


引起相当多关注的攻击场景之一是“爆炸半径”——受损容器对同一节点上的其他容器会造成多大的损害,或者受损的节点会对集群的其余部分造成多大的损害? 对于Kubernetes部署的所有安全考虑都是基于这些威胁模型以及最小化“爆炸半径”的需要。
 


外部攻击

在Kubernetes环境中,外部可访问的组件将受到外部攻击。这些组件可以包括API服务器、kubelet和etcd。

为了减轻外部攻击的威胁,确保只有必要的Kubernetes服务被公开。始终执行身份验证并为任何公开的服务配置正确的网络安全策略。
 


妥协的容器

最终,Kubernetes管理在容器中运行的工作负载。如果一个容器被破坏,问题是容器是否可以升级权限来控制其他容器或集群。

Kubernetes的隔离机制,比如命名空间或网络分割,以及一些内置的os级控制,调节容器可以访问的内容,可以帮助限制受影响的容器的影响。另一个控制用户应该注意的是限制能够以特权模式运行的容器数量的能力——如果一个特权容器被破坏,它将会比普通的容器造成更多的伤害。


妥协的凭证

当合法的用户凭证被破坏时,系统中可能有恶意用户。因此,正确地规范和限制用户对集群资源的访问并密切监视用户操作是非常重要的。

为了减少恶意用户的影响,需要强制执行最小权限访问、基于角色的访问控制或其他细粒度访问控制。
 


滥用特权

如果系统配置不正确,可能导致滥用用户权限。例如,如果网络策略不限制pods或命名空间之间访问,用户可能能够读取其他命名空间的通信流,而这些命名空间最初不应访问。

防止滥用特权的主要防御措施是适当强化。确保所有系统组件(如容器,pod,命名空间和kubelets)都得到了强化,以显著降低特权滥用的可能性。


另一个重要的防御是授权控制。Kubernetes支持插件架构,它允许包含复杂的授权逻辑。正确设计和实施授权;这是反对特权滥用最有效的武器之一。



原文链接:

1、The TopChallenges Kubernetes Users Face with Deployment

https://thenewstack.io/top-cha ... ment/

2、4 Threat Models for Kubernetes Deployment Security

https://www.tuicool.com/articles/AfI7RbQ 



相关阅读:


天啦噜!看国外大神如何用Docker+Jenkins&CI/CD打造微服务架构?

远离神乎其神,从Uber微服务看最佳实践如何炼成?
换个姿势学习Kubernetes运营,如何5个月在生产环境构建K8S?



添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

marathon如何绑定内网ip

回复

冰羽... 发起了问题 • 1 人关注 • 0 个回复 • 232 次浏览 • 2018-03-23 11:39 • 来自相关话题

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

杨y 发表了文章 • 0 个评论 • 321 次浏览 • 2018-03-21 11:33 • 来自相关话题

在分布式系统上管理服务是运维团队面临的最困难的问题之一。在生产中突破新软件并学习如何可靠地运营是非常重要的。本文是一则实例,讲述为什么学习运营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很重要,以及为什么很难。本文是关于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”?


112.jpg




战略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'。我们选择简单的作业,是因为希望测试集群的调度和编排能力,而不是集群的总计算能力。



113.jpg



测试集群无法处理每分钟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指标发布到我们的监控系统中。



111.jpg



例如,以下是过去一小时内集群中未决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落地 |不捧不踩,国外公司向Kubernetes迁移实践

dataman 发表了文章 • 0 个评论 • 238 次浏览 • 2018-03-16 10:50 • 来自相关话题

导读:

Kubernetes一骑绝尘开挂来,那么企业应该开始向Kubernetes迁移吗?什么情况下真正的接受它?一些技术前沿公司先行一步的实践恐怕最有说服力和参考价值。本文即是一则很好的参考。



1

Kubernetes如今风靡一时,它是庞大的云原生运动中的一部分。所有主要的云提供商都将其作为部署云原生应用的解决方案。就在几个星期前,AWS重新推出了EKS(Amazon Elastic Container Service for Kubernetes),这是一个完全托管的Kubernetes集群。

这是一个巨大的进步,因为AWS是最大的公有云提供商,大多数Kubernetes的部署都在AWS上。官方kops工具用于部署和管理Kubernetes集群,目前已准备就绪。随着Kubernetes越来越受欢迎,企业正在努力接受它,希望借助Kubernetes解决许多常见问题。

那么,企业真的应该开始向Kubernetes迁移吗?什么情况下真正的接受它?本篇文章,将试图回答这个问题,并给出迁移到K8S和云原生的一些挑战和建议。


The Problem 问题

今年早些时候,我们开始对Sematext云进行容器化部署,这看起来似乎非常简单。企业所要做的就是将所有应用程序打包,为其资源(如部署、服务等)创建一些Kubernetes配置,然后即可进行操作。然而,并不是那么容易。

问题主要在于,用于管理发布过程的所有东西都不适合云原生模式。企业的应用程序不是云原生的,就无法使用CI/CD部署管道,运行状况检查或使用监视工具来记录日志、指标和警报。企业的应用程序可能非常静态且部署复杂。这种复杂性不会随着迁移到Kubernetes而消失,只会让事情变得更糟。云原生意味着将操作系统从应用程序中解耦出来,这就是容器正在做的事情。

在软件行业的演进中,首先是瀑布流,然后是敏捷,如今有了DevOps管理。这是一个非常重要的难题,这里没有规则可循。每个团队使用最适合他们的方式,如果你想坚持现有的常规,没什么问题,请照常做。只需要确保你的日常工作适用于云原生,这意味着需要做出一些改变。要切换整个团队来接受DevOps原则并不容易,需要一些时间做准备。


The Solution解决方案

这不是一个需要盲目跟随的解决方案。它给出一个想法,并解释可能遇到的过程和问题。

第一步,首先对所有未使用的组件进行清理。软件在开发了几年之后,会变得非常复杂,因为总有更重要的事情要做——新功能、新产品修复等等。

其次,对Kubernetes readiness and liveness probes进行健康检查,这点不难。花费时间管理配置才是最难的部分。我的建议是利用配置地图(config maps)和secrets ,远离环境变量。你可以使用其中一部分,但不要仅使用环境变量来进行整个配置管理。应用程序应该充分发挥Kubernetes的潜力。


Kubernetes应用程序正在使用服务进行通信。在Kubernetes中有不同类型的服务,并将它们视为负载均衡器。定义的服务名称是你的端点http://service_name:port。如果正在使用有状态应用程序,会希望使用 headless services,能够访问特定的Pod。Kubernetes的服务也在某种程度上解决了服务发现问题。如果你已经使用了Consul之类的服务发现,恭喜你!可以坚持下去,并将它部署在Kubernetes上。

从Kubernetes的角度来看,在无状态应用程序下,应用程序容易扩展。使用部署作为资源,这种类型的服务还可以管理简单的升级-滚动更新。当然,你的应用程序需要在没有任何问题的情况下处理扩展,并且需要一些代码更改来实现它。

主要问题在于有状态的应用程序,如数据库。Kubernetes为这类应用程序提供了一种StatefulSet资源,但不知道在添加新节点或出现故障时,特定的应用程序应该如何反应,这是运维人员在管理时通常要做的事情。不过,编写Kubernetes的操作符不是多么困难的事情。

简而言之,操作符是Kubernetes custom resource definition(即CRD),可以自行编写或使用现有的。我们使用的是 Elastic search Operator,很乐意为这个项目做出贡献。我已经提出了一些pull requests。

你可能已经开始把所有的片段连接起来了。有两种计算资源:请求,它在一个节点上指定最小数量的空闲资源,用于Kubernetes调度程序运行特定的Pod,以及限制,这是Pod可以使用的最大计算资源数量。这一点非常重要,特别是对于Java应用程序来说。对于Java应用,还需要根据heap memory需求调整限制。根据对Docker CPU和内存限制的了解,我的建议是使用Java version 8u131或更新版本。

给你的应用标上标签——当需要监控容器和应用程序时,这真的很有用,而元数据信息通常就是如何通过选择器连接不同的资源。例如,部署和服务。

当开始编写Kubernetes配置文件时,你会觉得很好,并且认为维护不是什么大问题。但是,在尝试实现部署管道时,你会发现使用一堆配置文件是一个非常糟糕的想法。这时Helm可以拯救,Helm是一个用于打包Kubernetes应用程序的工具,我强烈推荐使用它来部署管道。诸如支持多种环境、依赖关系、版本控制、回滚和不同hooks(考虑DB迁移)就足够描述Helm的所有优点了。坏消息是你需要学习另一种工具,但它很容易学,值得你花时间。

企业不需要多个集群来搭建不同的环境,只需使用不同的Kubernetes命名空间。例如,为了创建一个新环境,只需要创建一个单独的命名空间,完成测试后把它删除,节省了大量时间和资金。但是,不要忘记安全。Kubectl就像集群中的根用户。让每个人都访问kubectl可能不是一个好主意。有时,创建一个全新的集群比管理RBAC更好,而这可能非常复杂。尽管如此,还是强烈建议使用RBAC。


那么,企业将如何为容器镜像、Helm packages等提供版本呢?这取决于自己的选择。最常用的方法是提交ID给镜像打标签,然后release tag。此时,需要将Docker镜像存储到某个地方,即私人或公共注册中心。我的建议是使用DockerHub。这或许是最具成本效益的。如果解决了所有问题,那么需要创建一个部署管道。企业可以使用Jenkins来部署所有内容,并将其作为DevOps的主要工具之一。

The Conclusion 结论

最近,人们关注的焦点是云原生,而并非仅仅Kubernetes本身。Kubernetes只是一个工具,我们向Kubernetes迁移Sematext云和Sematext的工作正在进行中。需要把它看作一个过程,这不是一项一次性的工作,也从来没有完全完成。

迁移到云原生和Kubernetes的过程,既困难又费时,但对企业的公司文化和软件非常有益。扩展不再是问题,基础设施只是代码和软件问题。拥抱Kubernetes,但要准备好面对挑战。




2

Kubernetes可以在任一环境下部署

在开始进行云原生开发和部署时,来看看Kubernetes所扮演的角色,以及如何从编排中获得更多的功能。

容器提供了将应用程序及其依赖与操作系统分离的能力。通过与虚拟机镜像不同的方式打包操作系统,容器节省了大量系统资源:计算、内存和磁盘空间。容器也更快地下载、更新、部署和迭代。因此,在技术领域,容器已经引起了一场小型革命,并被谷歌、微软和亚马逊等公司采用。


容器的小型革命也带来了激烈的竞争,以满足编排和管理的需要。Kubernetes,谷歌的开源容器编排工具,已经成为领先的解决方案(替代方案有有亚马逊ECS和DockerSwarm等),归功于三个主要原因:


云原生设计:支持部署和运行下一代应用程序。

开源特性:快速创新,避免厂商锁定。

可移植性:在任何地方部署,无论是在云中、on-premise、还是虚拟机中等等。

下图显示了Kubernetes在云原生部署中所扮演的角色:






Kubernetes容器编排

Kubernetes可以部署和管理容器应用,其中包括NGINX、MySQL、Apache和其他许多应用程序。它可以为容器提供布局、缩放、复制、监视和其他功能。


一旦选择了容器编排平台,下一步就是部署Kubernetes。如前所述,Kubernetes是一个可移植的解决方案。因为Kubernetes使用相同的镜像和配置,它在笔记本电脑上、云里、或在本地所使用的方式完全相同。

Kubernetes-as-a-Service

这些解决方案提供了在各种基础设施中部署Kubernetes的能力:公有云或内部部署。为Kubernetes集群选择这种方法的优势包括:

1.通过KaaS供应商进行升级、监控和支持。

2.轻松扩展混合云或多云环境。

3.多集群的单一窗格视图。

4.高可用性,多主Kubernetes集群,根据工作负载自动扩缩。

5.通用企业集成,如SSO /独立命名空间; 以及通过Helm图表部署应用程序的能力。

6.集群联合,提供跨多个云或数据中心的真正无缝混合环境。






Kubernetes-as-a-Service(Kubernetes即服务)


Kubernetes即服务的例子包括Platform9和StackPoint.io。


托管的基础设施

谷歌云平台和Microsoft Azure分别通过谷歌容器引擎(GKE)和Azure容器服务(ACS)提供Kubernetes。容器放置在公有云中可以快速启动,但是现在企业的数据将留存在网络防火墙之外。


谷歌GKE领导着其他公有云供应商。谷歌通过一个名为Borg的集群管理器,广泛地将容器用于内部项目,并拥有超过十年的开发经验(来源: TheNextPlatform)。相比之下,微软的ACS是一个更年轻的产品,Kubernetes支持仅在2017年2月才被引入。


然而,ACS提供了灵活性:用户可以选择容器编排平台(Kubernetes, Docker Swarm, DCOS),以及选择除了Linux以外,在Windows中部署容器化的应用程序的选项。如下所示,GKE和ACS完全基于公有云,Kubernetes服务和基础设施由托管提供商部署和管理。






Hosted Infrastructure for Kubernetes



本地部署

Minikube是在本地部署Kubernetes最流行的方式。它支持各种虚拟化管理程序,包括VirtualBox、VMware Fusion、KVM、xhyve和OSs,包括OSX、Windows和Linux。下面的插图进一步描述了Minikube的部署:


部署与Minikube

如上所示,用户使用Minikube CLI和Kubernetes的原生CLI Kubectl与笔记本电脑部署进行交互。 Minikube CLI可用于在虚拟机上启动,停止,删除,获取状态以及执行其他操作。一旦Minikube虚拟机启动,Kubectl CLI将在Kubernetes群集上执行操作。 以下命令启动现有的Minikube虚拟机并创建NGINX Kubernetes部署:#  minikube start
# cat > example.yaml<<EOF
apiVersion: apps/v1beta1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx
       ports:
       - containerPort: 80
EOF
# kubectl create -f example.yaml(手动往下翻)


原文链接:

1、Embracing Kubernetes Successfully

https://sematext.com/blog/embr ... ully/

2、Deploy Kubernetes Anywhere

https://dzone.com/articles/dep ... where


推荐活动:

数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站--3月31日,北京站开始报名啦!本期主题为《微服务,从架构到发布》依旧大咖汇集,点击最下方的“链接”快来报名~




相关阅读:

后Kubernetes时代,带你系统梳理K8S 12大关键特性

女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
  查看全部
导读:

Kubernetes一骑绝尘开挂来,那么企业应该开始向Kubernetes迁移吗?什么情况下真正的接受它?一些技术前沿公司先行一步的实践恐怕最有说服力和参考价值。本文即是一则很好的参考。



1

Kubernetes如今风靡一时,它是庞大的云原生运动中的一部分。所有主要的云提供商都将其作为部署云原生应用的解决方案。就在几个星期前,AWS重新推出了EKS(Amazon Elastic Container Service for Kubernetes),这是一个完全托管的Kubernetes集群。

这是一个巨大的进步,因为AWS是最大的公有云提供商,大多数Kubernetes的部署都在AWS上。官方kops工具用于部署和管理Kubernetes集群,目前已准备就绪。随着Kubernetes越来越受欢迎,企业正在努力接受它,希望借助Kubernetes解决许多常见问题。

那么,企业真的应该开始向Kubernetes迁移吗?什么情况下真正的接受它?本篇文章,将试图回答这个问题,并给出迁移到K8S和云原生的一些挑战和建议。


The Problem 问题

今年早些时候,我们开始对Sematext云进行容器化部署,这看起来似乎非常简单。企业所要做的就是将所有应用程序打包,为其资源(如部署、服务等)创建一些Kubernetes配置,然后即可进行操作。然而,并不是那么容易。

问题主要在于,用于管理发布过程的所有东西都不适合云原生模式。企业的应用程序不是云原生的,就无法使用CI/CD部署管道,运行状况检查或使用监视工具来记录日志、指标和警报。企业的应用程序可能非常静态且部署复杂。这种复杂性不会随着迁移到Kubernetes而消失,只会让事情变得更糟。云原生意味着将操作系统从应用程序中解耦出来,这就是容器正在做的事情。

在软件行业的演进中,首先是瀑布流,然后是敏捷,如今有了DevOps管理。这是一个非常重要的难题,这里没有规则可循。每个团队使用最适合他们的方式,如果你想坚持现有的常规,没什么问题,请照常做。只需要确保你的日常工作适用于云原生,这意味着需要做出一些改变。要切换整个团队来接受DevOps原则并不容易,需要一些时间做准备。


The Solution解决方案

这不是一个需要盲目跟随的解决方案。它给出一个想法,并解释可能遇到的过程和问题。

第一步,首先对所有未使用的组件进行清理。软件在开发了几年之后,会变得非常复杂,因为总有更重要的事情要做——新功能、新产品修复等等。

其次,对Kubernetes readiness and liveness probes进行健康检查,这点不难。花费时间管理配置才是最难的部分。我的建议是利用配置地图(config maps)和secrets ,远离环境变量。你可以使用其中一部分,但不要仅使用环境变量来进行整个配置管理。应用程序应该充分发挥Kubernetes的潜力。


Kubernetes应用程序正在使用服务进行通信。在Kubernetes中有不同类型的服务,并将它们视为负载均衡器。定义的服务名称是你的端点http://service_name:port。如果正在使用有状态应用程序,会希望使用 headless services,能够访问特定的Pod。Kubernetes的服务也在某种程度上解决了服务发现问题。如果你已经使用了Consul之类的服务发现,恭喜你!可以坚持下去,并将它部署在Kubernetes上。

从Kubernetes的角度来看,在无状态应用程序下,应用程序容易扩展。使用部署作为资源,这种类型的服务还可以管理简单的升级-滚动更新。当然,你的应用程序需要在没有任何问题的情况下处理扩展,并且需要一些代码更改来实现它。

主要问题在于有状态的应用程序,如数据库。Kubernetes为这类应用程序提供了一种StatefulSet资源,但不知道在添加新节点或出现故障时,特定的应用程序应该如何反应,这是运维人员在管理时通常要做的事情。不过,编写Kubernetes的操作符不是多么困难的事情。

简而言之,操作符是Kubernetes custom resource definition(即CRD),可以自行编写或使用现有的。我们使用的是 Elastic search Operator,很乐意为这个项目做出贡献。我已经提出了一些pull requests。

你可能已经开始把所有的片段连接起来了。有两种计算资源:请求,它在一个节点上指定最小数量的空闲资源,用于Kubernetes调度程序运行特定的Pod,以及限制,这是Pod可以使用的最大计算资源数量。这一点非常重要,特别是对于Java应用程序来说。对于Java应用,还需要根据heap memory需求调整限制。根据对Docker CPU和内存限制的了解,我的建议是使用Java version 8u131或更新版本。

给你的应用标上标签——当需要监控容器和应用程序时,这真的很有用,而元数据信息通常就是如何通过选择器连接不同的资源。例如,部署和服务。

当开始编写Kubernetes配置文件时,你会觉得很好,并且认为维护不是什么大问题。但是,在尝试实现部署管道时,你会发现使用一堆配置文件是一个非常糟糕的想法。这时Helm可以拯救,Helm是一个用于打包Kubernetes应用程序的工具,我强烈推荐使用它来部署管道。诸如支持多种环境、依赖关系、版本控制、回滚和不同hooks(考虑DB迁移)就足够描述Helm的所有优点了。坏消息是你需要学习另一种工具,但它很容易学,值得你花时间。

企业不需要多个集群来搭建不同的环境,只需使用不同的Kubernetes命名空间。例如,为了创建一个新环境,只需要创建一个单独的命名空间,完成测试后把它删除,节省了大量时间和资金。但是,不要忘记安全。Kubectl就像集群中的根用户。让每个人都访问kubectl可能不是一个好主意。有时,创建一个全新的集群比管理RBAC更好,而这可能非常复杂。尽管如此,还是强烈建议使用RBAC。


那么,企业将如何为容器镜像、Helm packages等提供版本呢?这取决于自己的选择。最常用的方法是提交ID给镜像打标签,然后release tag。此时,需要将Docker镜像存储到某个地方,即私人或公共注册中心。我的建议是使用DockerHub。这或许是最具成本效益的。如果解决了所有问题,那么需要创建一个部署管道。企业可以使用Jenkins来部署所有内容,并将其作为DevOps的主要工具之一。

The Conclusion 结论

最近,人们关注的焦点是云原生,而并非仅仅Kubernetes本身。Kubernetes只是一个工具,我们向Kubernetes迁移Sematext云和Sematext的工作正在进行中。需要把它看作一个过程,这不是一项一次性的工作,也从来没有完全完成。

迁移到云原生和Kubernetes的过程,既困难又费时,但对企业的公司文化和软件非常有益。扩展不再是问题,基础设施只是代码和软件问题。拥抱Kubernetes,但要准备好面对挑战。




2

Kubernetes可以在任一环境下部署

在开始进行云原生开发和部署时,来看看Kubernetes所扮演的角色,以及如何从编排中获得更多的功能。

容器提供了将应用程序及其依赖与操作系统分离的能力。通过与虚拟机镜像不同的方式打包操作系统,容器节省了大量系统资源:计算、内存和磁盘空间。容器也更快地下载、更新、部署和迭代。因此,在技术领域,容器已经引起了一场小型革命,并被谷歌、微软和亚马逊等公司采用。


容器的小型革命也带来了激烈的竞争,以满足编排和管理的需要。Kubernetes,谷歌的开源容器编排工具,已经成为领先的解决方案(替代方案有有亚马逊ECS和DockerSwarm等),归功于三个主要原因:


云原生设计:支持部署和运行下一代应用程序。

开源特性:快速创新,避免厂商锁定。

可移植性:在任何地方部署,无论是在云中、on-premise、还是虚拟机中等等。

下图显示了Kubernetes在云原生部署中所扮演的角色:

微信图片_20180316102623.jpg


Kubernetes容器编排

Kubernetes可以部署和管理容器应用,其中包括NGINX、MySQL、Apache和其他许多应用程序。它可以为容器提供布局、缩放、复制、监视和其他功能。


一旦选择了容器编排平台,下一步就是部署Kubernetes。如前所述,Kubernetes是一个可移植的解决方案。因为Kubernetes使用相同的镜像和配置,它在笔记本电脑上、云里、或在本地所使用的方式完全相同。

Kubernetes-as-a-Service

这些解决方案提供了在各种基础设施中部署Kubernetes的能力:公有云或内部部署。为Kubernetes集群选择这种方法的优势包括:

1.通过KaaS供应商进行升级、监控和支持。

2.轻松扩展混合云或多云环境。

3.多集群的单一窗格视图。

4.高可用性,多主Kubernetes集群,根据工作负载自动扩缩。

5.通用企业集成,如SSO /独立命名空间; 以及通过Helm图表部署应用程序的能力。

6.集群联合,提供跨多个云或数据中心的真正无缝混合环境。

微信图片_20180316102658.jpg


Kubernetes-as-a-Service(Kubernetes即服务)


Kubernetes即服务的例子包括Platform9和StackPoint.io。


托管的基础设施

谷歌云平台和Microsoft Azure分别通过谷歌容器引擎(GKE)和Azure容器服务(ACS)提供Kubernetes。容器放置在公有云中可以快速启动,但是现在企业的数据将留存在网络防火墙之外。


谷歌GKE领导着其他公有云供应商。谷歌通过一个名为Borg的集群管理器,广泛地将容器用于内部项目,并拥有超过十年的开发经验(来源: TheNextPlatform)。相比之下,微软的ACS是一个更年轻的产品,Kubernetes支持仅在2017年2月才被引入。


然而,ACS提供了灵活性:用户可以选择容器编排平台(Kubernetes, Docker Swarm, DCOS),以及选择除了Linux以外,在Windows中部署容器化的应用程序的选项。如下所示,GKE和ACS完全基于公有云,Kubernetes服务和基础设施由托管提供商部署和管理。

微信图片_20180316102938.jpg


Hosted Infrastructure for Kubernetes



本地部署

Minikube是在本地部署Kubernetes最流行的方式。它支持各种虚拟化管理程序,包括VirtualBox、VMware Fusion、KVM、xhyve和OSs,包括OSX、Windows和Linux。下面的插图进一步描述了Minikube的部署:


部署与Minikube

如上所示,用户使用Minikube CLI和Kubernetes的原生CLI Kubectl与笔记本电脑部署进行交互。 Minikube CLI可用于在虚拟机上启动,停止,删除,获取状态以及执行其他操作。一旦Minikube虚拟机启动,Kubectl CLI将在Kubernetes群集上执行操作。 以下命令启动现有的Minikube虚拟机并创建NGINX Kubernetes部署:#  minikube start
# cat > example.yaml<<EOF
apiVersion: apps/v1beta1
kind: Deployment
metadata:
 name: nginx-deployment
spec:
 replicas: 1
 template:
   metadata:
     labels:
       app: nginx
   spec:
     containers:
     - name: nginx
       image: nginx
       ports:
       - containerPort: 80
EOF
# kubectl create -f example.yaml(手动往下翻)


原文链接:

1、Embracing Kubernetes Successfully

https://sematext.com/blog/embr ... ully/

2、Deploy Kubernetes Anywhere

https://dzone.com/articles/dep ... where


推荐活动:

数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站--3月31日,北京站开始报名啦!本期主题为《微服务,从架构到发布》依旧大咖汇集,点击最下方的“链接”快来报名~




相关阅读:

后Kubernetes时代,带你系统梳理K8S 12大关键特性

女神特辑 | 关于DevOps和职场,4位DevOps领域杰出女性都关注些啥?

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
 

后Kubernetes时代,带你系统梳理K8S 12大关键特性

dataman 发表了文章 • 0 个评论 • 254 次浏览 • 2018-03-13 10:38 • 来自相关话题

导读:

Kubernetes如今风靡一时,所有主要的云服务提供商都将其作为部署云原生应用的解决方案。Kubernetes有哪些显著的特性和工具优势,让企业开始接受它?本文作者给出了系统的梳理。
 
 “Action without orchestration is burn out; orchestration w/o action is management.”  
 
没有编排的行动是完蛋的,没有行动的编排是管理,行动加上编排是领导。
[b]                                                            ― Orrin Woodward”[/b]
 
Kubernetes是一种优化资源利用率的抽象概念,它允许跨节点集群高效地进行应用程序分发。   
 
 
Kubernetes,舵手 !

Kubernetes是一个希腊语单词,意思是“舵手”。
 
它是一个由谷歌开始的开源项目,从Borg衍生而来,在谷歌内部使用了好几年,现在用于容器管理。目前由CNCF托管。
 
Kubernetes(缩写为K8S)是一种抽象,它通过容器来优化CPU和内存等资源的利用率,从而可以跨多个节点高效地进行应用程序分发。K8S可以在裸金属或任何云基础设施提供商的任何地方运行。这个新工具是云无关的,聚焦于在基础设施内部部署和调度容器,而不是直接利用节点/主机。
 
K8S提供的一些平台特性是:
使用pod进行容器分组自愈自动伸缩DNS管理负载均衡滚动更新或回滚
资源监控和日志记录
  
 
Kubernetes 架构






Kubernetes集群由主节点和一组worker/从属节点组成。
 
Kubernetes的主节点组成部分是:
API服务器(API Server):用户通过Rest操作或kubectl cli与manifestyaml交互。它用于所有与API对象相关的操作,如pod创建,它是在etcd中存储所需状态的唯一组件。
 
调度器(Scheduler):用户使用kubectl cli向API服务器发出一个命令来创建pod。在执行此操作之后,调度程序根据资源需求将pods分配给可用节点。
 
控制器管理器(Controller Manager):控制器管理器基于集群状态对资源进行操作,并根据清单yaml进行更改,将当前状态应用程序达到所需状态。换句话说,控制器管理器可以将实际状态与所需的状态进行协调。在控制器管理器中有多个专用的控制器,以便简化集群管理。例如,节点控制器检查是否有当前正在运行的节点停机,并采取纠正措施,而复制控制器确保在节点中实际运行所需的pod数量。
 
etcd:所有关于集群状态的配置信息都以key/value对的形式存储在etcd中,这个组件由CoreOS实现。这些状态显示了集群中包含的节点和需要在其中运行的pods。
 
插件(Addons):为了将服务器DNS记录添加到Kubernetes,我们需要一个集群DNS 插件。该插件有助于扩展与Kubernetes集群或节点相关的功能。还有许多其他的插件,比如用于日志记录的fluntd、基于角色访问的rbac等等。
 
安装在Kubernetes节点中的组件是:
Docker: Docker守护进程在每个节点中运行。如果容器镜像不存在,那么它将从docker注册中提取并运行。
 
Kubelet: Kubelet节点代理定期检查容器内容器的健康状况。此外,它还确保按manifest安装卷,并下载运行容器所需的敏感信息。它还将节点链接到API服务器。
 
Kube-proxy: Kube-proxy在每个节点上运行,以便在pod中进行负载分配,并为外部主机提供可用的服务。它使用iptable规则或轮询调度来将请求转发到正确的容器。
 
对于高可用和容错的Kubernetes生产和部署,需要多个主节点和一个单独的etcd集群。如果运行了三个API服务器,则需要一个网络负载平衡器来正确地将负载分配到服务器。唯一剩下的问题是需要三个角色来管理控制器管理器和调度器以维护集群状态和分配节点。为了更高效、更可靠地执行它,只有一个参与者应该执行实际的更改,但是在机器宕机的情况下仍然需要其他实例。为了解决这个问题,我们可以在API中使用lease-lock 来执行主选,而使用它的标志是leader- elect。
 
Kubernetes通过以下任一种方式实现从Pod到Pod的联网:
 
1)第2层(切换解决方案)
2)第3层(桥接解决方案)
3) overlay解决方案(weave andflannel)

它们允许在集群中进行Pod和Pod之间的通信,并为每个Pod提供唯一的IP地址。
 

Kubernetes关键特性
 
Pod: Collection of Containers容器集
 






pod是K8S中的一个部署单元,它有一个单独的IP地址。在它内部,Pause容器通过持有一个网络的名称空间、端口和ip地址来处理网络,而这个地址又被pod中的所有容器使用。
 
ReplicationController
 





ReplicationController确保在给定的时间内启动和运行所需的容器数量。Pod模板用于定义容器镜像标识符、端口和标签。使用liveness probes,它可以自动治愈pods,并按照期望的状态维持pods数量。也可以通过使用kubectl来手动控制副本计数。

 
存储管理
 
Pods本质是短暂的——任何储存在pod或容器中的信息都会丢失。为了存储数据,一个持久的系统是必需的,即使在一个pod被杀死或重新调度之后,如Amazon Elastic Block Storage (EBS),谷歌GCE PD,或一个分布式文件系统,如网络文件系统(NFS)或Gluster文件系统(GFS)。
 
资源监控
 






监控是成功运行基础设施的关键之一,它是可靠性等级的基础。Heapster是一个从kubelet收集指标的插件,与cAdvisor集成。cAdvisor用于收集与运行容器的CPU、内存、I/O和网络统计数据相关的指标。由Heapster收集的数据存储在influx DB中,并使用Grafana在UI中显示。还有其他可使用的接收器,如Kafka或Elastic Search,可以用于存储数据并显示在用户界面中。

 
健康检查
 
kubernetes的健康检查由kubelet代理完成。它分为liveness 和 readiness probes两种。
 
处理程序主要有三种类型:
 ExecAction:执行Shell命令,如果生成的退出代码为0,则意味着实例是健康的。在任何其他情况下,实例不健康。TCPAction: Kubelet将尝试连接到指定的端口,如果它建立到给定socket的连接,诊断成功。HTTPGetAction:基于应用程序公开的HTTP端点,kubelet对指定路径上的容器IP地址执行HTTP GET请求,如果返回200到300个响应代码,诊断就成功了。
 
每个probe通常有三个结果:
成功:容器通过诊断。
失败:容器未通过诊断。
未知:诊断失败,不要采取任何行动。

水平自动伸缩功能
 






 
自动伸缩使用基于负载的计算资源。K8S scale pod自动使用Horizontal Pod Autoscaler对象,从Heapster获取度量数据,并相应地减少或增加pod的数量。例如,如果自动伸缩是基于内存利用率,那么控制器就会开始在pod中观察内存使用情况,并根据容量对该副本计数进行扩展。
 
服务发现
 
Kubernetes pods是短暂的,ReplicationController 在任何节点上动态创建它们,因此在集群中发现服务是一个挑战。服务需要发现一个IP地址和动态的端口,以便在集群中进行通信。
 
有两种主要的方法来找到它——环境变量(Environment variables)和DNS。
 
更可取的是基于DNS的服务发现,它可以作为集群附加组件使用。跟踪集群中的新服务,并为每个服务创建一组DNS记录。
 

网络
 
要完全管理集群,必须正确设置网络,并解决三个网络问题:

1.容器到容器的通信:pods通过本地主机通信,并使用Pause容器网络名称空间,解决这个问题。
2.Pod-to-Pod通信:由软件定义的网络解决,如上面架构图所示。
3.外部到pod通信:由服务覆盖。

Kubernetes提供了广泛的网络选择。现在还支持容器网络接口(CNI)插件,这是容器的通用插件架构。目前支持多种编排工具,如Kubernetes、Mesos和CloudFoundry。
 
有各种覆盖插件:
1.Flannel来自CoreOS,是一个非常简单的etcd后端覆盖网络。它创建了另一个虚拟的、可路由的IP / Pod网络,运行在底层网络之上;ergo,称为覆盖网络。在这个覆盖网络中,每个Pod将被分配一个IP地址,并且会直接使用它们的IP进行通信。
2.Weave通过CNI插件提供与Kubernetes兼容的覆盖网络。
 
服务
Kubernetes服务是一种抽象,它将通信路由到一组pod,以提供一个微服务。Kube-proxy在每个节点上运行,并通过设置一组iptable规则来管理服务。
 
设立服务的模式有三种:
1.ClusterIP(只提供内部访问)
2.NodePort(需要在端口上打开防火墙;不建议公开访问)3.负载均衡器(由AWS或GKE等公有云供应商拥有)
 
ConfigMap和Secret
 
ConfigMap使注入基于环境的配置成为可能,同时使容器镜像在多个环境中保持一致。这些可以通过安装卷或环境变量(environment variables)来注入,并将这些值存储在key/value格式中。
 
Secrets用于存储敏感数据,如密码、OAuth令牌等。
 
滚动部署和回滚
 
部署对象持有一个或多个副本集,以支持回滚机制。换句话说,每次更改部署配置时都会创建一个新的副本集,并保留以前的版本,以便有回滚选项。只有一个副本集将在特定时间处于活动状态。
 
对于滚动部署,需要的策略类型是RollingUpdate和minReadySecs,它指定应用程序为服务流量所花费的时间。如果在应用程序pod还没有准备好时,将其保持默认状态,它将不可用。这个动作可以通过以下命令来完成:
 






 
或者,
 
通过替换部署yaml文件中的内容并运行以下命令:






如果新版本不像预期的那样,那么可以通过运行以下命令回滚到以前的版本:
 






如果所需版本是前一版本以外的版本,则运行:
 





 Logging记录
 
要监视应用程序的行为,必须检查日志——每个pod生成多个日志。要开始在仪表板UI中搜索日志,必须有一些机制收集并将它们聚合到一个日志查看器中。为了说明这一点,Fluentd是一个开源工具,也是CNCF的一部分,与 Elastic Search 和 Kibana 完美结合。
 
 
原文链接:Kubernetes: Twelve Key Features
https://dzone.com/articles/kubernetes-twelve-key-features
 
 
推荐活动:
数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站--3月31日,[b]北京站开始报名啦![/b]本期主题为《微服务,从架构到发布》依旧大咖汇集,点击链接快来报名~
 
 
相关阅读:
​【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构
有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群 查看全部


0.jpg


导读:

Kubernetes如今风靡一时,所有主要的云服务提供商都将其作为部署云原生应用的解决方案。Kubernetes有哪些显著的特性和工具优势,让企业开始接受它?本文作者给出了系统的梳理。
 
 “Action without orchestration is burn out; orchestration w/o action is management.”  
 
没有编排的行动是完蛋的,没有行动的编排是管理,行动加上编排是领导。
[b]                                                            ― Orrin Woodward”[/b]
 
Kubernetes是一种优化资源利用率的抽象概念,它允许跨节点集群高效地进行应用程序分发。   
 
 
Kubernetes,舵手 !

Kubernetes是一个希腊语单词,意思是“舵手”。
 
它是一个由谷歌开始的开源项目,从Borg衍生而来,在谷歌内部使用了好几年,现在用于容器管理。目前由CNCF托管。
 
Kubernetes(缩写为K8S)是一种抽象,它通过容器来优化CPU和内存等资源的利用率,从而可以跨多个节点高效地进行应用程序分发。K8S可以在裸金属或任何云基础设施提供商的任何地方运行。这个新工具是云无关的,聚焦于在基础设施内部部署和调度容器,而不是直接利用节点/主机。
 
K8S提供的一些平台特性是:
  • 使用pod进行容器分组
  • 自愈
  • 自动伸缩
  • DNS管理
  • 负载均衡
  • 滚动更新或回滚

  • 资源监控和日志记录

  
 
Kubernetes 架构

11.jpg


Kubernetes集群由主节点和一组worker/从属节点组成。
 
Kubernetes的主节点组成部分是:
  • API服务器(API Server)用户通过Rest操作或kubectl cli与manifestyaml交互。它用于所有与API对象相关的操作,如pod创建,它是在etcd中存储所需状态的唯一组件。

 
  • 调度器(Scheduler):用户使用kubectl cli向API服务器发出一个命令来创建pod。在执行此操作之后,调度程序根据资源需求将pods分配给可用节点。

 
  • 控制器管理器(Controller Manager):控制器管理器基于集群状态对资源进行操作,并根据清单yaml进行更改,将当前状态应用程序达到所需状态。换句话说,控制器管理器可以将实际状态与所需的状态进行协调。在控制器管理器中有多个专用的控制器,以便简化集群管理。例如,节点控制器检查是否有当前正在运行的节点停机,并采取纠正措施,而复制控制器确保在节点中实际运行所需的pod数量。

 
  • etcd:所有关于集群状态的配置信息都以key/value对的形式存储在etcd中,这个组件由CoreOS实现。这些状态显示了集群中包含的节点和需要在其中运行的pods。

 
  • 插件(Addons):为了将服务器DNS记录添加到Kubernetes,我们需要一个集群DNS 插件。该插件有助于扩展与Kubernetes集群或节点相关的功能。还有许多其他的插件,比如用于日志记录的fluntd、基于角色访问的rbac等等。

 
安装在Kubernetes节点中的组件是:
  • Docker: Docker守护进程在每个节点中运行。如果容器镜像不存在,那么它将从docker注册中提取并运行。

 
  • Kubelet: Kubelet节点代理定期检查容器内容器的健康状况。此外,它还确保按manifest安装卷,并下载运行容器所需的敏感信息。它还将节点链接到API服务器。

 
  • Kube-proxy: Kube-proxy在每个节点上运行,以便在pod中进行负载分配,并为外部主机提供可用的服务。它使用iptable规则或轮询调度来将请求转发到正确的容器。

 
对于高可用和容错的Kubernetes生产和部署,需要多个主节点和一个单独的etcd集群。如果运行了三个API服务器,则需要一个网络负载平衡器来正确地将负载分配到服务器。唯一剩下的问题是需要三个角色来管理控制器管理器和调度器以维护集群状态和分配节点。为了更高效、更可靠地执行它,只有一个参与者应该执行实际的更改,但是在机器宕机的情况下仍然需要其他实例。为了解决这个问题,我们可以在API中使用lease-lock 来执行主选,而使用它的标志是leader- elect。
 
Kubernetes通过以下任一种方式实现从Pod到Pod的联网:
 
1)第2层(切换解决方案)
2)第3层(桥接解决方案)
3) overlay解决方案(weave andflannel)

它们允许在集群中进行Pod和Pod之间的通信,并为每个Pod提供唯一的IP地址。
 

Kubernetes关键特性
 
Pod: Collection of Containers容器集
 
5.jpg



pod是K8S中的一个部署单元,它有一个单独的IP地址。在它内部,Pause容器通过持有一个网络的名称空间、端口和ip地址来处理网络,而这个地址又被pod中的所有容器使用。
 
ReplicationController
 
6.jpg


ReplicationController确保在给定的时间内启动和运行所需的容器数量。Pod模板用于定义容器镜像标识符、端口和标签。使用liveness probes,它可以自动治愈pods,并按照期望的状态维持pods数量。也可以通过使用kubectl来手动控制副本计数。

 
存储管理
 
Pods本质是短暂的——任何储存在pod或容器中的信息都会丢失。为了存储数据,一个持久的系统是必需的,即使在一个pod被杀死或重新调度之后,如Amazon Elastic Block Storage (EBS),谷歌GCE PD,或一个分布式文件系统,如网络文件系统(NFS)或Gluster文件系统(GFS)。
 
资源监控
 

12.jpg


监控是成功运行基础设施的关键之一,它是可靠性等级的基础。Heapster是一个从kubelet收集指标的插件,与cAdvisor集成。cAdvisor用于收集与运行容器的CPU、内存、I/O和网络统计数据相关的指标。由Heapster收集的数据存储在influx DB中,并使用Grafana在UI中显示。还有其他可使用的接收器,如Kafka或Elastic Search,可以用于存储数据并显示在用户界面中。

 
健康检查
 
kubernetes的健康检查由kubelet代理完成。它分为liveness 和 readiness probes两种。
 
处理程序主要有三种类型:
 ExecAction:执行Shell命令,如果生成的退出代码为0,则意味着实例是健康的。在任何其他情况下,实例不健康。TCPAction: Kubelet将尝试连接到指定的端口,如果它建立到给定socket的连接,诊断成功。HTTPGetAction:基于应用程序公开的HTTP端点,kubelet对指定路径上的容器IP地址执行HTTP GET请求,如果返回200到300个响应代码,诊断就成功了。
 
每个probe通常有三个结果:
成功:容器通过诊断。
失败:容器未通过诊断。
未知:诊断失败,不要采取任何行动。

水平自动伸缩功能
 

12.jpg


 
自动伸缩使用基于负载的计算资源。K8S scale pod自动使用Horizontal Pod Autoscaler对象,从Heapster获取度量数据,并相应地减少或增加pod的数量。例如,如果自动伸缩是基于内存利用率,那么控制器就会开始在pod中观察内存使用情况,并根据容量对该副本计数进行扩展。
 
服务发现
 
Kubernetes pods是短暂的,ReplicationController 在任何节点上动态创建它们,因此在集群中发现服务是一个挑战。服务需要发现一个IP地址和动态的端口,以便在集群中进行通信。
 
有两种主要的方法来找到它——环境变量(Environment variables)和DNS。
 
更可取的是基于DNS的服务发现,它可以作为集群附加组件使用。跟踪集群中的新服务,并为每个服务创建一组DNS记录。
 

网络
 
要完全管理集群,必须正确设置网络,并解决三个网络问题:

1.容器到容器的通信:pods通过本地主机通信,并使用Pause容器网络名称空间,解决这个问题。
2.Pod-to-Pod通信:由软件定义的网络解决,如上面架构图所示。
3.外部到pod通信:由服务覆盖。

Kubernetes提供了广泛的网络选择。现在还支持容器网络接口(CNI)插件,这是容器的通用插件架构。目前支持多种编排工具,如Kubernetes、Mesos和CloudFoundry。
 
有各种覆盖插件:
1.Flannel来自CoreOS,是一个非常简单的etcd后端覆盖网络。它创建了另一个虚拟的、可路由的IP / Pod网络,运行在底层网络之上;ergo,称为覆盖网络。在这个覆盖网络中,每个Pod将被分配一个IP地址,并且会直接使用它们的IP进行通信。
2.Weave通过CNI插件提供与Kubernetes兼容的覆盖网络。
 
服务
Kubernetes服务是一种抽象,它将通信路由到一组pod,以提供一个微服务。Kube-proxy在每个节点上运行,并通过设置一组iptable规则来管理服务。
 
设立服务的模式有三种:
1.ClusterIP(只提供内部访问)
2.NodePort(需要在端口上打开防火墙;不建议公开访问)3.负载均衡器(由AWS或GKE等公有云供应商拥有)
 
ConfigMap和Secret
 
ConfigMap使注入基于环境的配置成为可能,同时使容器镜像在多个环境中保持一致。这些可以通过安装卷或环境变量(environment variables)来注入,并将这些值存储在key/value格式中。
 
Secrets用于存储敏感数据,如密码、OAuth令牌等。
 
滚动部署和回滚
 
部署对象持有一个或多个副本集,以支持回滚机制。换句话说,每次更改部署配置时都会创建一个新的副本集,并保留以前的版本,以便有回滚选项。只有一个副本集将在特定时间处于活动状态。
 
对于滚动部署,需要的策略类型是RollingUpdate和minReadySecs,它指定应用程序为服务流量所花费的时间。如果在应用程序pod还没有准备好时,将其保持默认状态,它将不可用。这个动作可以通过以下命令来完成:
 

7.jpg


 
或者,
 
通过替换部署yaml文件中的内容并运行以下命令:

8.jpg


如果新版本不像预期的那样,那么可以通过运行以下命令回滚到以前的版本:
 

9.jpg


如果所需版本是前一版本以外的版本,则运行:
 
10.jpg


 Logging记录
 
要监视应用程序的行为,必须检查日志——每个pod生成多个日志。要开始在仪表板UI中搜索日志,必须有一些机制收集并将它们聚合到一个日志查看器中。为了说明这一点,Fluentd是一个开源工具,也是CNCF的一部分,与 Elastic Search 和 Kibana 完美结合。
 
 
原文链接:Kubernetes: Twelve Key Features
https://dzone.com/articles/kubernetes-twelve-key-features
 
 
推荐活动:
数人云联合ServiceComb、ServiceMesh社区举办的 Building Microservice Meetup系列活动第2站--3月31日,[b]北京站开始报名啦![/b]本期主题为微服务,从架构到发布》依旧大咖汇集,点击链接快来报名~
 
 
相关阅读:
​【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构
有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求
 
添加小数微信:xiaoshu062
备注公司、姓名、职位
小数将拉您进入相应技术群

市场经理和产品经理的区别在哪里,区别大不大?

回复

小筱筱 发起了问题 • 1 人关注 • 0 个回复 • 448 次浏览 • 2018-03-12 18:03 • 来自相关话题

【详解】以银行零售业务为例,一个案例说清楚可视化微服务架构

dataman 发表了文章 • 0 个评论 • 208 次浏览 • 2018-03-08 10:27 • 来自相关话题

Part 1: API设计和策略

软件系统的复杂性是一个很痛苦的问题,而且无法避免。Fred Brooks将复杂性描述为,软件系统解决业务问题所固有的本质复杂性,以及实施该解决方案所带来的偶发复杂性。

随着与采用“API优先”工程实践和微服务架构的组织进行更密切的合作,我发现这种描述越来越有用。首先,通过这种方式分离复杂性,它允许架构师和工程师专注于最小化系统的偶发复杂性。

与微服务相关的技术创新有很大帮助:容器,自动化工具和API管理平台。但我真正喜欢这种复杂性划分的原因是,它帮助我们认清一个事实:任何技术都不能降低系统的本质复杂性。

“开发软件产品的许多经典问题源于这种本质的复杂性,其非线性随着规模的增加而增加。” – 出自Fred Brooks著《No Silver Bullet—Essence & Accident in Software Engineering》

但是,我们能做的至少是理解和记录一个系统的本质复杂性。对于大多数技术人员来说,有效完成这一任务很重要,因为系统的本质复杂性不包括解决方案中使用的底层技术。

系统本质复杂性定义的本质要素是系统执行的任务和功能,以及执行所需的对象和交互。为了优化这种定义的认知负荷,将此定义表达为视觉模型也是很自然的。即使在可视化的情况下,软件架构师仍然努力保持模型中的元素不受技术限制,并且保持一致。

Eric Evans的领域驱动设计(Domain-Driven Design ,DDD)方法论突出的原因是,它提供了一种可视化定义软件系统本质复杂性的方法。特别是,显示域,子域,有界上下文及其相互关系的上下文映射,与我见过的以有效方式说明本质复杂性的任何方法都非常接近。 UML意在提供一种用于定义与技术无关的应用程序描述的手段,但它的许多模型自然偏向于面向对象的根源。事实上,如果你深入DDD工具箱,我认为你会遇到同样的偏见。

我在定义一个互连微服务系统时,使用了DDD上下文映射的派生。将在未来的文章中详细介绍这种方法。







示例上下文映射

为什么理解和记录软件系统的本质复杂性很重要,这与微服务有什么关系?随着微服务系统的发展和演变,其许多好处来自于服务本身的凝聚力。PhilCalçado在他的博客文章“微服务与分布式对象的第一定律(Microservices & the First Law of Distributed Objects)”中强调了这一需求。凝聚力是确定服务边界的产物,这是模拟系统本质复杂性的必要步骤。

有趣的是,与Brooks所描述的复杂性似乎是矛盾的,微服务系统的技术无关上下文映射在某种程度上与它的实现的拓扑结构是同构的,远远超过一整套单体应用的拓扑。这可能是一个巧合,也表明我们正在采用这种微服务架构方法。


Part 2:设计微服务系统

最近我一直在与许多大型组织合作,帮助他们理解并实现Web API和微服务体系结构的价值。在这项工作中,我看到这些组织一直在努力于,如何定义企业里微服务之间的最佳边界。这是一个已知的问题,但没有解决。虽然关于凝聚式服务(cohesive services)的价值和有界上下文已经写了很多,但如何实际识别这些内容似乎没有指导意义。

这个问题的一个原因是,试图确定服务边界的人是技术人员,他们天生就在寻找技术解决方案,但是定义凝聚力和能力一致性的服务边界(cohesive, capability-aligned service boundaries)却需要领域专家。从根本上说,这应该是一种建模练习,它独立于任何技术的覆盖。然而,即使那些有意识地采用了技术无关建模方法的组织,也一直在努力定义服务边界。

发生这种情况的部分原因是,最流行的软件建模方法往往存在实施偏差。例如,领域驱动设计(DDD)倾向于面向对象的编程,而UML偏向数据建模的角度。除此之外,业界还没有就如何直观地描绘微服务系统模型达成共识,诸如应该描述哪些组件,应该如何表示关系,应该使用什么术语,更不用说这其中的任何工具。

不过,所有的希望都不会丢失。 DDD的一些概念,最明显的是“有界上下文”( bounded contexts)的概念,已经获得了普及,并启动了关于服务边界定义的行业对话。重要的是,DDD方法论中更高层次的抽象,包括域,子域,有界上下文,聚合(aggregates),上下文映射,都是技术不可知和模型为中心的。

理解系统的方法是关注组件之间的关系,如果想要一个微服务系统的基本表示,不需要比上下文映射更深入。因此,也许我们可以使用DDD上下文映射作为可视化微服务系统的起点。

即使在上下文映射层面,大型组织的完整服务系统也是不可理解的。因此,为了使上下文映射有用,为上下文映射本身设置上下文非常重要。这种上下文可以是特定整体应用程序的分解,或特定计划的服务交互。连贯地构建一个大型组织的微服务系统的唯一方法就是,逐条地,上下文地进行。


微服务上下文映射示例

来看一个例子。一家大型零售银行希望引入以客户为中心的服务,以实现留住客户的战略目标。它希望提供一种新的以客户为中心的支付解决方案,允许客户根据他们与银行的关系(他们的账户,投资,资产,交互模式)进行购买,而不是将授权决策基于一个特定帐户。

零售银行业务本身就是一个复杂的业务领域。客户,产品和服务渠道(分支机构,网上银行,销售点)等实体之间存在相互关系,以及与财务透明度和数据隐私相关的强制性规定。因此,尽管这种新的支付服务背后的想法很直观,但它却呈现出一个复杂的问题空间。那么从哪里开始呢?

继DDD方法松散之后,我们可以首先将零售银行业务领域划分为子域。作为一个起点,并遵循康威法则的必然性,可以从组成零售银行的组织单位开始,并与以客户为中心的支付解决方案相关。这些是:

这些子域可以通过以下方式进行可视化描述:






这给了我们一个考虑如何分类创建以客户为中心的支付解决方案服务的起点。自助银行和客户与卡片管理子域名突出显示,因为它们已被确定为解决方案的关键子域名。使用DDD的“语言边界”概念,显然有一些有界上下文出现在子域中。

在自助银行内部,有两种截然不同的有界上下文。网上银行渠道与手机银行渠道有共同的语言,他们都提供个性化的客户体验,而支持移动渠道的应用程序则是由网络渠道构建和共享组件。我们将这种情况称为context Online Banking。另一方面,销售点具有独特的语言,更多地集中在设备管理和商家关系上。我们将称之为销售点(context Point of Sale)。

客户与卡片管理甚至更加分散。核心客户信息,包括银行客户的权威列表,他们的联系信息和产品库,形成了一个独特的词汇表,我们称之为客户信息有界的上下文。另一种不同的语言被用来描述卡功能,这主要与支付活动有关。这是“消费者支付和交易”上下文。最后,还有一个客户身份上下文专注于客户安全和访问控制。

产品子域名对于此付款解决方案并不重要,但值得注意的是零售贷款和贷款子域划分为单独的PLC账户和信用卡上下文。完整的相关有界上下文如下所示:






在确定了有界上下文之后,现在可以考虑顾客将在其中使用哪些服务。如前所述,网上银行有两种服务消费者:网上银行web App和手机银行App。新的支付解决方案也将通过销售点的POS网络收到的消息请求所消耗。

客户身份上下文必须提供客户身份验证服务,以确保只有合适的请求者才能访问新的付款服务。客户信息背景包含客户和产品持有人之间的交叉参考,因此需要核心客户信息服务来为新的支付解决方案提供这些数据。

除此之外,跟踪客户财务活动,与其产品持有相关的财务事件,将有助于做出授权决策。因此,客户活动分析服务可以在客户信息上下文中创建。

消费者支付和交易环境是为新的以客户为中心的支付解决方案建立核心服务的场所。首先,客户需要注册新产品并设置其帐户和产品偏好。为此,引入了以客户为中心的支付管理服务。

对于非功能性原因(例如性能,安全性和可用性),我们将创建一个单独的授权支付服务,称为以客户为中心的支付授权服务。最后,由于向客户帐户发布交易可以晚于授权决定发布,因此我们将创建与授权服务分离的交易发布服务(Transaction Posting Service)。


对于产品子域,我们只会在每个有界的上下文中引用单个同名服务。例如,存款账户上下文只包含一个存款账户服务。整个服务系统现在看起来像这样:






这个设计过程的最后一步是注释将发生在服务之间的交互。事实上,人们可能想要模拟有界上下文之间的相互作用,以便梳理出单个服务,但为了覆盖视觉效果,我们将最后描述这一步骤。在这个阶段举例说明所有可能的交互会造成视觉混淆,因此只会关注一些能够帮助理解系统如何运作的关键信息。这里有些例子:
 
客户使用网上银行Web应用程序通过以客户为中心的支付管理服务,注册并设置新支付解决方案的偏好;

以客户为中心的支付管理服务从客户信息服务中检索客户的产品组合;

客户活动分析服务使用来自产品系统的信息构建客户财务状况;

客户通过移动银行应用程序执行以客户为中心的支付,该应用程序称为以客户为中心的支付授权服务;

以客户为中心的支付授权服务,依次使用来自以客户为中心的支付管理服务和客户活动分析服务的信息构建授权配置文件;
 
一旦获得授权,支付将被转发至交易发布服务完成,然后调用相应的产品服务;

关于微服务系统有几点需要注意。首先,不要假定在为最终用户活动提供服务时,这些交互中的每一个都会实时发生。例如,尽管以客户为中心的授权服务需要来自其他一些服务的信息,但可以使用基于事件的方法结合缓存来确保其处理是独立的,以便实时服务客户的授权请求。

其次,可以在有界上下文之间建立防腐层(ACL),以提供松散的语义耦合。最后,虽然这是一个相当复杂的图片,但没有实现细节。换句话说,这种模式可以使用许多不同的技术来实现,包括语言,主机环境和网络协议。

最终的上下文映射(包括交互)如下所示:






最终,此系统设计过程的目的是,帮助企业如何在复杂解决方案中定义微服务的服务边界进行最佳猜测。希望这里的方法既能为服务建立一个良好的初始模型,又能更容易地重新绘制服务边界。


Part 3:微服务设计画布

微服务有自身的起源,通常从现有单体应用程序中涌现出来,以满足眼前的需求。提高交付速度的愿望推动了微服务的采用,开发人员通常采取“代码优先,问题排后”的方法,并重复实现有用的结果。这可行,但它是最佳的吗?回答这个问题会带来另一个问题:在开发微服务之前应该考虑哪些设计因素?正如软件架构师Simon Brown所说,“前期做大设计是愚蠢的,但没有前期的设计更愚蠢。”

借鉴精益画布(lean canvas )方法设计商业模型,介绍一下微服务设计画布。这个画布是一个工具,可以帮助企业在构建服务之前捕获服务中最重要的前端属性。画布采用了一种外部方法,它可以很好地将您的界面与其底层实现松散耦合。






你可以先在底部框中填写服务的自由格式“说明”。从这里开始,你应该完成“消费者任务”框,记录服务消费者需要执行的任务。列举服务的消费者以及他们需要执行的任务有助于明确服务的目的,并提供设计界面所需的材料输入。这些信息可以帮助填写“界面”框。在这里,消费者任务可以细分为与服务接口的特定交互。根据模式(查询,命令,事件)对交互进行分类,将有助于形成底层服务实现,并最终推动API的设计。

除了服务的任务和交互之外,还必须考虑服务的非功能方面。可以使用“质量(Qualities)”框来确定服务属性,例如可用性和性能级别,可扩展性方法和安全性期望。这将有助于消费者进一步了解服务,并影响其实施。总而言之,消费者的任务,界面和品质定义了服务的“表面”。这对系统的设计至关重要,因为它捕获了系统中其他利益相关者所需的最重要的信息。

在表面之下,还有一些关键的考虑因素。 “逻辑/规则”和“数据”框为服务设计人员提供了一个位置,以记录这些领域的关键因素。抵制在这个阶段太深的诱惑。没有必要为服务的工作编写一个完整的内部系统设计,但是可能需要感觉独特和支持表面属性所需的项目。最后,应列出服务“依赖关系”,以便调出服务需要的任务。对于具有相当数量业务逻辑的任务繁重的微服务,需要与更多面向数据的服务进行交互是很自然的。但是,本着微服务架构的精神,目标是最大限度地减少这些依赖关系。

来看几个示例画布。首先是以客户为中心的支付管理服务画布:






请注意,该服务看起来好像在交互中很直接,并且与其数据相对独立。 从非功能角度来看,这不是关键任务,也不需要最高级别的事务完整性。 因此,它的实现可能相当简单。

接下来是以客户为中心的支付授权服务的画布:






这项服务有一些更复杂的考虑因素。首先,它预计将是高容量和低延迟。这对服务的工程设计产生了明确的影响,需要复杂的授权信息缓存。其次,由于它的交互涉及金钱的流动,交易完整性和审计至关重要。最后,有一些事件交互意味着接口将超越典型的RESTful API。事实上,看到这些非功能性差异就清楚地说明,为什么将以客户为中心的支付解决方案的授权和管理功能,分解为单独的服务是一个很好的设计决策。在系统视图和服务视图之间迭代将有助于定义服务边界。

希望这个微服务设计画布可以成为着手微服务部署的企业的有用工具。它清楚地与API设计联系在一起。

作者:Matt McLarty

原文链接:

1、Visualizing Microservices: API Design and Strategy

https://dzone.com/articles/vis ... ategy

2、Visualizing Microservices: Designing a Microservice System

https://dzone.com/articles/vis ... rvice

3、Visualizing Microservices: The Microservice Design Canvas

https://dzone.com/articles/vis ... esign



相关阅读:
2018最难招聘的11类IT人员

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


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部
Part 1: API设计和策略

软件系统的复杂性是一个很痛苦的问题,而且无法避免。Fred Brooks将复杂性描述为,软件系统解决业务问题所固有的本质复杂性,以及实施该解决方案所带来的偶发复杂性。

随着与采用“API优先”工程实践和微服务架构的组织进行更密切的合作,我发现这种描述越来越有用。首先,通过这种方式分离复杂性,它允许架构师和工程师专注于最小化系统的偶发复杂性。

与微服务相关的技术创新有很大帮助:容器,自动化工具和API管理平台。但我真正喜欢这种复杂性划分的原因是,它帮助我们认清一个事实:任何技术都不能降低系统的本质复杂性。

“开发软件产品的许多经典问题源于这种本质的复杂性,其非线性随着规模的增加而增加。” – 出自Fred Brooks著《No Silver Bullet—Essence & Accident in Software Engineering》

但是,我们能做的至少是理解和记录一个系统的本质复杂性。对于大多数技术人员来说,有效完成这一任务很重要,因为系统的本质复杂性不包括解决方案中使用的底层技术。

系统本质复杂性定义的本质要素是系统执行的任务和功能,以及执行所需的对象和交互。为了优化这种定义的认知负荷,将此定义表达为视觉模型也是很自然的。即使在可视化的情况下,软件架构师仍然努力保持模型中的元素不受技术限制,并且保持一致。

Eric Evans的领域驱动设计(Domain-Driven Design ,DDD)方法论突出的原因是,它提供了一种可视化定义软件系统本质复杂性的方法。特别是,显示域,子域,有界上下文及其相互关系的上下文映射,与我见过的以有效方式说明本质复杂性的任何方法都非常接近。 UML意在提供一种用于定义与技术无关的应用程序描述的手段,但它的许多模型自然偏向于面向对象的根源。事实上,如果你深入DDD工具箱,我认为你会遇到同样的偏见。

我在定义一个互连微服务系统时,使用了DDD上下文映射的派生。将在未来的文章中详细介绍这种方法。


0.jpg


示例上下文映射

为什么理解和记录软件系统的本质复杂性很重要,这与微服务有什么关系?随着微服务系统的发展和演变,其许多好处来自于服务本身的凝聚力。PhilCalçado在他的博客文章“微服务与分布式对象的第一定律(Microservices & the First Law of Distributed Objects)”中强调了这一需求。凝聚力是确定服务边界的产物,这是模拟系统本质复杂性的必要步骤。

有趣的是,与Brooks所描述的复杂性似乎是矛盾的,微服务系统的技术无关上下文映射在某种程度上与它的实现的拓扑结构是同构的,远远超过一整套单体应用的拓扑。这可能是一个巧合,也表明我们正在采用这种微服务架构方法。


Part 2:设计微服务系统

最近我一直在与许多大型组织合作,帮助他们理解并实现Web API和微服务体系结构的价值。在这项工作中,我看到这些组织一直在努力于,如何定义企业里微服务之间的最佳边界。这是一个已知的问题,但没有解决。虽然关于凝聚式服务(cohesive services)的价值和有界上下文已经写了很多,但如何实际识别这些内容似乎没有指导意义。

这个问题的一个原因是,试图确定服务边界的人是技术人员,他们天生就在寻找技术解决方案,但是定义凝聚力和能力一致性的服务边界(cohesive, capability-aligned service boundaries)却需要领域专家。从根本上说,这应该是一种建模练习,它独立于任何技术的覆盖。然而,即使那些有意识地采用了技术无关建模方法的组织,也一直在努力定义服务边界。

发生这种情况的部分原因是,最流行的软件建模方法往往存在实施偏差。例如,领域驱动设计(DDD)倾向于面向对象的编程,而UML偏向数据建模的角度。除此之外,业界还没有就如何直观地描绘微服务系统模型达成共识,诸如应该描述哪些组件,应该如何表示关系,应该使用什么术语,更不用说这其中的任何工具。

不过,所有的希望都不会丢失。 DDD的一些概念,最明显的是“有界上下文”( bounded contexts)的概念,已经获得了普及,并启动了关于服务边界定义的行业对话。重要的是,DDD方法论中更高层次的抽象,包括域,子域,有界上下文,聚合(aggregates),上下文映射,都是技术不可知和模型为中心的。

理解系统的方法是关注组件之间的关系,如果想要一个微服务系统的基本表示,不需要比上下文映射更深入。因此,也许我们可以使用DDD上下文映射作为可视化微服务系统的起点。

即使在上下文映射层面,大型组织的完整服务系统也是不可理解的。因此,为了使上下文映射有用,为上下文映射本身设置上下文非常重要。这种上下文可以是特定整体应用程序的分解,或特定计划的服务交互。连贯地构建一个大型组织的微服务系统的唯一方法就是,逐条地,上下文地进行。


微服务上下文映射示例

来看一个例子。一家大型零售银行希望引入以客户为中心的服务,以实现留住客户的战略目标。它希望提供一种新的以客户为中心的支付解决方案,允许客户根据他们与银行的关系(他们的账户,投资,资产,交互模式)进行购买,而不是将授权决策基于一个特定帐户。

零售银行业务本身就是一个复杂的业务领域。客户,产品和服务渠道(分支机构,网上银行,销售点)等实体之间存在相互关系,以及与财务透明度和数据隐私相关的强制性规定。因此,尽管这种新的支付服务背后的想法很直观,但它却呈现出一个复杂的问题空间。那么从哪里开始呢?

继DDD方法松散之后,我们可以首先将零售银行业务领域划分为子域。作为一个起点,并遵循康威法则的必然性,可以从组成零售银行的组织单位开始,并与以客户为中心的支付解决方案相关。这些是:

这些子域可以通过以下方式进行可视化描述:

1.jpg


这给了我们一个考虑如何分类创建以客户为中心的支付解决方案服务的起点。自助银行和客户与卡片管理子域名突出显示,因为它们已被确定为解决方案的关键子域名。使用DDD的“语言边界”概念,显然有一些有界上下文出现在子域中。

在自助银行内部,有两种截然不同的有界上下文。网上银行渠道与手机银行渠道有共同的语言,他们都提供个性化的客户体验,而支持移动渠道的应用程序则是由网络渠道构建和共享组件。我们将这种情况称为context Online Banking。另一方面,销售点具有独特的语言,更多地集中在设备管理和商家关系上。我们将称之为销售点(context Point of Sale)。

客户与卡片管理甚至更加分散。核心客户信息,包括银行客户的权威列表,他们的联系信息和产品库,形成了一个独特的词汇表,我们称之为客户信息有界的上下文。另一种不同的语言被用来描述卡功能,这主要与支付活动有关。这是“消费者支付和交易”上下文。最后,还有一个客户身份上下文专注于客户安全和访问控制。

产品子域名对于此付款解决方案并不重要,但值得注意的是零售贷款和贷款子域划分为单独的PLC账户和信用卡上下文。完整的相关有界上下文如下所示:

2.jpg


在确定了有界上下文之后,现在可以考虑顾客将在其中使用哪些服务。如前所述,网上银行有两种服务消费者:网上银行web App和手机银行App。新的支付解决方案也将通过销售点的POS网络收到的消息请求所消耗。

客户身份上下文必须提供客户身份验证服务,以确保只有合适的请求者才能访问新的付款服务。客户信息背景包含客户和产品持有人之间的交叉参考,因此需要核心客户信息服务来为新的支付解决方案提供这些数据。

除此之外,跟踪客户财务活动,与其产品持有相关的财务事件,将有助于做出授权决策。因此,客户活动分析服务可以在客户信息上下文中创建。

消费者支付和交易环境是为新的以客户为中心的支付解决方案建立核心服务的场所。首先,客户需要注册新产品并设置其帐户和产品偏好。为此,引入了以客户为中心的支付管理服务。

对于非功能性原因(例如性能,安全性和可用性),我们将创建一个单独的授权支付服务,称为以客户为中心的支付授权服务。最后,由于向客户帐户发布交易可以晚于授权决定发布,因此我们将创建与授权服务分离的交易发布服务(Transaction Posting Service)。


对于产品子域,我们只会在每个有界的上下文中引用单个同名服务。例如,存款账户上下文只包含一个存款账户服务。整个服务系统现在看起来像这样:

3.jpg


这个设计过程的最后一步是注释将发生在服务之间的交互。事实上,人们可能想要模拟有界上下文之间的相互作用,以便梳理出单个服务,但为了覆盖视觉效果,我们将最后描述这一步骤。在这个阶段举例说明所有可能的交互会造成视觉混淆,因此只会关注一些能够帮助理解系统如何运作的关键信息。这里有些例子:
 
客户使用网上银行Web应用程序通过以客户为中心的支付管理服务,注册并设置新支付解决方案的偏好;

以客户为中心的支付管理服务从客户信息服务中检索客户的产品组合;

客户活动分析服务使用来自产品系统的信息构建客户财务状况;

客户通过移动银行应用程序执行以客户为中心的支付,该应用程序称为以客户为中心的支付授权服务;

以客户为中心的支付授权服务,依次使用来自以客户为中心的支付管理服务和客户活动分析服务的信息构建授权配置文件;
 
一旦获得授权,支付将被转发至交易发布服务完成,然后调用相应的产品服务;

关于微服务系统有几点需要注意。首先,不要假定在为最终用户活动提供服务时,这些交互中的每一个都会实时发生。例如,尽管以客户为中心的授权服务需要来自其他一些服务的信息,但可以使用基于事件的方法结合缓存来确保其处理是独立的,以便实时服务客户的授权请求。

其次,可以在有界上下文之间建立防腐层(ACL),以提供松散的语义耦合。最后,虽然这是一个相当复杂的图片,但没有实现细节。换句话说,这种模式可以使用许多不同的技术来实现,包括语言,主机环境和网络协议。

最终的上下文映射(包括交互)如下所示:

4.jpg


最终,此系统设计过程的目的是,帮助企业如何在复杂解决方案中定义微服务的服务边界进行最佳猜测。希望这里的方法既能为服务建立一个良好的初始模型,又能更容易地重新绘制服务边界。


Part 3:微服务设计画布

微服务有自身的起源,通常从现有单体应用程序中涌现出来,以满足眼前的需求。提高交付速度的愿望推动了微服务的采用,开发人员通常采取“代码优先,问题排后”的方法,并重复实现有用的结果。这可行,但它是最佳的吗?回答这个问题会带来另一个问题:在开发微服务之前应该考虑哪些设计因素?正如软件架构师Simon Brown所说,“前期做大设计是愚蠢的,但没有前期的设计更愚蠢。”

借鉴精益画布(lean canvas )方法设计商业模型,介绍一下微服务设计画布。这个画布是一个工具,可以帮助企业在构建服务之前捕获服务中最重要的前端属性。画布采用了一种外部方法,它可以很好地将您的界面与其底层实现松散耦合。

5.jpg


你可以先在底部框中填写服务的自由格式“说明”。从这里开始,你应该完成“消费者任务”框,记录服务消费者需要执行的任务。列举服务的消费者以及他们需要执行的任务有助于明确服务的目的,并提供设计界面所需的材料输入。这些信息可以帮助填写“界面”框。在这里,消费者任务可以细分为与服务接口的特定交互。根据模式(查询,命令,事件)对交互进行分类,将有助于形成底层服务实现,并最终推动API的设计。

除了服务的任务和交互之外,还必须考虑服务的非功能方面。可以使用“质量(Qualities)”框来确定服务属性,例如可用性和性能级别,可扩展性方法和安全性期望。这将有助于消费者进一步了解服务,并影响其实施。总而言之,消费者的任务,界面和品质定义了服务的“表面”。这对系统的设计至关重要,因为它捕获了系统中其他利益相关者所需的最重要的信息。

在表面之下,还有一些关键的考虑因素。 “逻辑/规则”和“数据”框为服务设计人员提供了一个位置,以记录这些领域的关键因素。抵制在这个阶段太深的诱惑。没有必要为服务的工作编写一个完整的内部系统设计,但是可能需要感觉独特和支持表面属性所需的项目。最后,应列出服务“依赖关系”,以便调出服务需要的任务。对于具有相当数量业务逻辑的任务繁重的微服务,需要与更多面向数据的服务进行交互是很自然的。但是,本着微服务架构的精神,目标是最大限度地减少这些依赖关系。

来看几个示例画布。首先是以客户为中心的支付管理服务画布:

6.jpg


请注意,该服务看起来好像在交互中很直接,并且与其数据相对独立。 从非功能角度来看,这不是关键任务,也不需要最高级别的事务完整性。 因此,它的实现可能相当简单。

接下来是以客户为中心的支付授权服务的画布:

7.jpg


这项服务有一些更复杂的考虑因素。首先,它预计将是高容量和低延迟。这对服务的工程设计产生了明确的影响,需要复杂的授权信息缓存。其次,由于它的交互涉及金钱的流动,交易完整性和审计至关重要。最后,有一些事件交互意味着接口将超越典型的RESTful API。事实上,看到这些非功能性差异就清楚地说明,为什么将以客户为中心的支付解决方案的授权和管理功能,分解为单独的服务是一个很好的设计决策。在系统视图和服务视图之间迭代将有助于定义服务边界。

希望这个微服务设计画布可以成为着手微服务部署的企业的有用工具。它清楚地与API设计联系在一起。

作者:Matt McLarty

原文链接:

1、Visualizing Microservices: API Design and Strategy

https://dzone.com/articles/vis ... ategy

2、Visualizing Microservices: Designing a Microservice System

https://dzone.com/articles/vis ... rvice

3、Visualizing Microservices: The Microservice Design Canvas

https://dzone.com/articles/vis ... esign



相关阅读:
2018最难招聘的11类IT人员

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


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群

有趣 | 马斯洛理论告诉你,Kubernetes可以满足微服务的这15大需求

dataman 发表了文章 • 0 个评论 • 218 次浏览 • 2018-03-06 10:13 • 来自相关话题

 导读:

本来隶属于心理学上的马斯洛需求理论,被一些领域活学活用,深入浅出地阐释出层次结构和递进关系。本文作者就把微服务做了如此类比,非常有趣。同时,给予Kubernetes高度肯定和赞赏,指出它会成为实际的操作系统,获得众多供应商支持。

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






马斯洛需求层次



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

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






微服务的需求层次结构

一旦列出了微服务的主要问题(对每个人来说可能会有不同的顺序),就会发现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/introdu ... uffer

2、CloudBees:9 things you need to know about Kubernetes

http://www.computerweekly.com/ ... erral



相关阅读:

2018最难招聘的11类IT人员

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

“天生一对”的容器+微服务,能躲开微服务悖论陷阱吗?


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群 查看全部

微信图片_20180306100355.jpg

 导读:

本来隶属于心理学上的马斯洛需求理论,被一些领域活学活用,深入浅出地阐释出层次结构和递进关系。本文作者就把微服务做了如此类比,非常有趣。同时,给予Kubernetes高度肯定和赞赏,指出它会成为实际的操作系统,获得众多供应商支持。

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

1.jpg


马斯洛需求层次



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

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

2.jpg


微服务的需求层次结构

一旦列出了微服务的主要问题(对每个人来说可能会有不同的顺序),就会发现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/introdu ... uffer

2、CloudBees:9 things you need to know about Kubernetes

http://www.computerweekly.com/ ... erral



相关阅读:

2018最难招聘的11类IT人员

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

“天生一对”的容器+微服务,能躲开微服务悖论陷阱吗?


添加小数微信:xiaoshu062

备注公司、姓名、职位

小数将拉您进入相应技术群