返回 登录
0

Docker 与 K8s 在企业基础设施服务的应用

阅读1425

一、新时代——即基于容器的云时代的来临

下面出场的是容器时代的两大主角——Docker和Kubernetes,未来相当长的时间里,容器时代的种种爱恨情仇,都将在这两大主角之间展开。

图片描述

先看下Docker:

图片描述

Docker刚刚三岁半,虽出身草莽,但早已显露王者风范,据说Docker开源之后,很多VMware的老员工就开始找工作了~

再来看下Kubernetes:

图片描述

Kubernetes不到两岁半,系出名门,脱胎于Google Borg,出道以来吊打各路高手,俨然一位不可一世的富二代!

面世不过两三年的开源项目,就取得了如此广泛的关注度和实际应用,回顾历史,这样的项目屈指可数,那么这种状况的原因又是什么呢?或者说,他们带来了哪些独特的价值呢?

在很多技术资料里,在提到容器的价值的时候,都会出现如下两张图:左边是拿容器和虚拟机的层次结构做对比,说容器是个分层更少、更加轻量的虚拟化工具;右边是拿容器和虚拟机的性能做对比,说容器是个性能更好的虚拟化工具。

图片描述

那么容器的价值就仅仅是轻量和高性能吗?这显然很不充分,因为容器相对虚拟机的性能提升,最多也就是百分之几十的样子,在IT界,不带来十倍以上的性能提升,是很难被赋予颠覆者地位的。仅仅百分之几十的提升,会迅速被摩尔定律抹平,长期看不值一提。

那么容器的最大价值到底是什么?为了说明这个问题,我们来回顾下基础设施层多年以来的苦苦挣扎~

二、提升抽象层级是基础设施的宿命

不知道各位有没有了解过OASIS指定的TOSCA规范,一个面向云应用拓扑和编排的规范,这个规范的工作已经开始了五年多,我本人也是委员,之前的规范工作主要围绕虚拟机展开,看下这页PPT的左图,TOSCA通过Node Type描述节点(这里可以简单的认为就是一个虚拟机镜像)的属性和对外接口,通过Relationship Type描述描述节点之间的关系,通过Plan描述部署流程等等……这些共同组成了一个Service Template。

图片描述

我在这里提这个五年前出现的规范的目的是:在这一波容器浪潮出现之前,业界就已经在如何利用虚拟机更好的管理应用的问题上探索多年了。

就好像一个运维人员,不会满足仅仅维护一下服务器,会希望往上层走,创造更大的价值一样~

之前业界也出现过一些基于类似理念的商业产品。

比如Oracle的Virtual Assembly Builder:

图片描述

比如VMware的vRealize Automation:

图片描述

这些产品都能利用虚拟机很方便的编排出一些典型的应用拓扑。

可是却很少有人用,我想群里的大部分朋友可能都没用过。

原因是什么呢?

图片描述

这张图我在之前的PPT里也出现过,又放在这里的意思是:

中间2013年的这种多层架构,相对比较简单,使用脚本部署就已经比较高效了,很少有企业会因为这个事情去采购昂贵的商业软件,而且这些商业软件也没有为部署之外的运维流程带来太多的便捷性。

右边2016年的这种分布式架构,是现阶段的趋势,这种架构给部署和运维都带来了极大的困难,这些昂贵的商业软件也无从处理。

我想这就是原因和尴尬之处吧!

图片描述

所以说,天堂向左,虚机向右,通过虚拟机来解决分布式系统的部署和运维问题,已经被业界的多年努力验证为此路不通,而这些挤压已久的需求,在容器上找到了突破口。

这就是容器最核心的价值。

三、Docker和Kubernetes实现基础设施的多年梦想

我们来看一下Docker和Kubernetes如何实现基础设施的多年梦想。

图片描述

Docker,真正的实现了Infrastructure as Code,Infrastructure as Code作为一个Buzz Word已被炒作了多年,以前只是Infrastructure提供一些API,供上层调用,可是仅仅提供了API,还不能说是Code,Code是可以Compile、可以Link的,而Docker实现了这些。

图片描述

把Docker编译好、链接好的镜像发布到Kubernetes的集群里,Kubernetes就接管了应用的大部分运维工作,kubernetes会负责处理应用的高可用和自动伸缩,对应用的任何一次变更,小到修改一个参数,大到一次全面的升级,都会被Kubernetes纳入版本控制,就像管理代码一样~

可以看到,Docker和Kubernetes联手解决了分布式系统运维的大量问题,但是这远远不是问题的全部。

如果基于Docker和Kubernetes打造一个DevOps平台,还面临着很多问题:

图片描述

四、我们的进一步工作

现有的开发、集成、测试、运维工具大多为单体应用设计,难以处理微服务带来的复杂度。

所以我们针对这个问题升级了我们原有的产品。

图片描述

我们使用元数据治理产品对微服务进行全生命周期的管理,使整个研发和交付流程更加顺畅。

图片描述

我们开发了全新的工作空间,降低了团队间的协作成本。

图片描述

我们还做了很多很多,这里不一一列举,总而言之,我们通过精益运营建立了一个数字化企业云平台。

图片描述

说到这里,各位有没有觉得,基于容器的云平台有一种发展方向,就是成为一个更全面的应用服务器,这里的更全面指支持大规模集群环境、更多类型的应用、并更加完整的覆盖软件的生命周期。

但是我们这几年经常听到这句话:

图片描述

应用服务器已死。

举例来说,基于JAVA的应用服务器,有资源隔离差(JVM缺乏CPU、内存、IO的资源控制能力)、与应用紧耦合(应用服务器需要为应用做出针对性的配置)、依赖管理能力弱(库版本冲突、只能管理Java世界的依赖)、持续集成/部署困难(应用服务器无法参与持续集成、部署应用服务器本身比部署应用复杂的多)等诸多问题,而这些问题在分布式、碎片化的软件环境下,变得日趋严重,所以传统的应用服务器面临了快速的衰败。

但是这些问题总要有个新平台去解决,只是目前旧王已死,新王未立。

在上一页PPT中我们可以看到,容器镜像就像一个包含了运行环境依赖的WAR包,基于容器的云平台也将提供类似消息引擎、JNDI、安全服务、Workload管理、Job管理等能力,而且这些能力将为更多类型的软件提供服务。

最后我们畅想一下未来:

图片描述

如果像Gartner所说,未来所有的公司都将是IT公司,那么必然不是每个公司都像现在的大型互联网公司一样,在IT的各个技术领域雇佣大量的专业人员,一些共性的需求必将剥离出来,由专门的公司提供解决方案,历史是螺旋上升的,社会分工将被再次重建。

作者博客:http://blog.csdn.net/xn_sung

普元云计算专区:http://primeton.csdn.net/m/zone/primeton/index#

普元公众号:

图片描述

评论