订阅云计算RSS CSDN首页> 云计算

【微信分享】FIT2CLOUD徐桂林:容器云之Kubernetes应用与实践

发表于2015-11-04 14:55| 次阅读| 来源CSDN| 0 条评论| 作者魏伟

摘要:Kubernetes开源以来,受到了越来越多大型云计算厂商的青睐,包括如Microsoft、VMWare、Red Hat、CoreOS、Mesos等。随着Kubernetes社区及各大厂商的不断改进、发展,Kuberentes有望成为容器管理领域的领导者。

Kubernetes v1.0特性解析 Docker运行GUI软件的方法 微信群分享之后,11月4日晚,我们CSDN Container技术交流群又邀请到FIT2CLOUD负责公司的技术布道师徐桂林,他深入分享了容器云之Kubernetes应用与实践。


讲师简介:徐桂林,当前在FIT2CLOUD负责公司的技术布道和生态合作。在此之前先后供职于意法半导体、Autodesk和阿里云。徐桂林热衷于云计算(尤其是公有云IaaS平台),有过多年云计算生产环境工作经历,是较早在国内分享云计算实践经验的作者之一。


以下为演讲实录

首先,让我们从容器、容器云开始今天的分享。从去年年初开始,以 Docker为代表的容器技术快速火起来,以至于今天大家基本把容器等同于Docker(这次分享,我们姑且也这么“等于”一下)估计大家都听了很多Docker相关的分享、介绍,甚至都已经在生产上用上了Docker,所以这里我就不展开说Docker的细节。

但是,不同的人对于Docker带来的价值还有不同理解。我们认为Docker主要提供了两个方面重要价值:一个轻量级、可独立调度的运行环境以及一个标准的镜像模型。

如果观察现在容器相关的技术和产品基本也对应到这两点上。一部分容器技术与产品关注使用Docker来简化运行环境管理,打通从代码到容器镜像的整条链路。另一部分则关注如何更好的管理和编排容器运行时环境,让容器真正能够达到服务高可用、强弹性的业务场景。当然,还有连接两者的Docker Registry。

作为落地容器技术的一个重要产品方向就是“容器云”。一般来说,一个完整的容器云需要包括以上说到的三方面产品(镜像发布、镜像仓库和容器编排)。

说到“容器云”,就必然要联系到另一个云,即基础设施云(IaaS)。那这两者之间到底是什么关系?一般认为,“容器云”是一种特化(技术路线上)的平台云(PaaS),按照云计算普遍采纳的三层架构,其应该在IaaS之上。这也是我们今天要表达的第一个观点:我们认为只有运行在IaaS平台上的“容器云”才能够算真正意义上的容器云。直接运行在物理机以及虚拟化环境上的“容器云”则缺少底层基础设施弹性交付的能力,并不能拥有“云”最核心的优势:弹性交付,按需付费。当然,IaaS平台提供的丰富基础设施服务也为容器云的运营带来很多价值。例如,IaaS 提供的云磁盘,云存储可以作为 Kubernetes 中 pod 的存储的一个选择。区别于宿主机硬盘,云磁盘在数据可靠性要好非常多。  

类似与IaaS,容器云也可以有公有容器云、托管容器云或者私有容器云之分。但是无论那种形态,我们都认为其应该运行在某种IaaS层之上(可以是公有IaaS云:如青云),也可以是私有IaaS云(如OpenStack)。

在说完我们对于容器、容器云以及它和IaaS之间的关系后,这次分享重点想沟通关于容器编排这方面的工作。前面提到的另外两个容器方面工作(镜像发布、镜像仓库)我们也会很快涉及,不过今天就不展开讲了。

在容器编排和调度方面,主要需要解决的问题可以分成两类:一是承载容器运行的集群管理(包括,集群节点管理、服务负载均衡管理、名字服务管理、请求转发等),另外就是进行任务调度和资源管理(包括资源分配、容器伸缩、容错处理等)。

现在,最主流的容器编排和调度系统有三个分支:Cloud Foundry、Mesos和今天要讲的Kubernetes。在这三类中,Cloud Foundry和Mesos是在Docker之前就已经为大家所知,而Kubernetes则是由Google于去年六月开源出来的全新项目。目前,这三个项目在支持Docker编排调度上都还在快速发展阶段,到完全成型或者成熟阶段可能还要一点时间。但,在这三者之中我们非常看好Kubernetes未来的发展潜力。不过究其原因来看还真不仅仅是技术上的考量,具体如下:

1)Kubernetes是由Google发起并主导的项目,而Google应该是这个世界上最懂得容器运行的公司,Kubernetes就是参考、借鉴Google内部运营Brog的十几年经验设计而来的(具体细节可以参考Google今年发布的Brog论文)。

2)Kubernetes这个项目上Google是投入了重兵。如分布式系统设计中的基础性理论--CAP--的提出者Eric Brewer就是Kubernetes项目中的重要决策人。另外,Google的云战略在其公司整体战略的重要性已经大幅提高。而Google在BigTable上吃过亏:作为NoSQL的最早实践者,由于未亲自上阵,使得Hbase成为了事实上的工业标准,等Google Cloud自己需要开放NoSQL服务时还得支持他们认为设计并不好的HBase接口。所以,这次在容器编排调度上不希望再次重复同样的故事,决定亲自上阵。同时,基于Kubernetes的Google Container Service服务也是Google云有可能弯道超车AWS的一个机会。

3)Kubernetes的另外一位大玩家就是Redhat。至于是Google主动邀请Redhat加入,还是Redhat主动要求加入这一点我无从得知。但是,最终Redhat是全情投入了。下图就是Kubernetes过去一年多Contribution的公司分布,其中Google和Redhat是绝对的主力。


Redhat现在是把Kubernetes作为其下一代PaaS云平台(OpenShift)的核心组件。最近发布的OpenShift V3主打的就是基于Kubernetes的容器云平台。

在过去一年多时间里,Kubernetes项目的活跃度非常好。根据Github项目首页显示,其提交次数超过两万次。超过一万次的Star也说明其在社区上的关注度也是非常高的。

说了这么多关于Kubernetes的好话,那我们来看看其具体能力吧。这里直接引用Kubernetes官方文档的总结。从用户角度看,Kubernetes能带给用户的包括:

  在线的应用伸缩能力;

  无缝的应用更新能力;

  充分的资源利用能力;

顺便插开一句,如果把这三点对应到IaaS平台带给用户的核心价值,你会发现他们竟然非常一致(只是在不同层面来提供这些能力)。优秀的IaaS平台(尤其是公有IaaS平台)提供的服务一定需要做到“强弹性”、“热升级”和“高资源利用率”。强弹性需要靠庞大的资源池保证,热升级需要优秀的设计架构和强大的运维能力保证,高资源利用率则是公有云最终能否赚钱的核心能力。所以,从这个角度看,Kubernetes的设计目标就是为大规模运营容器云所准备的,也是Google有勇气使用其作为Google Container Service服务的原因所在。

为达到上面这些能力,我们看Kubernetes是如何设计架构。首先,Kubernetes整个架构图如下:


Kuberenetes是典型的Master-Slave架构,其中包括如下这些关键组件:

  ClusterKubernetes维护一个集群,Docker的containers都运行其上。并且,这个集群可以运维在任何云及Bare Metal物理机上。

  MasterMaster节点包含apiserver,controller-manager,sheduler等核心组件(常常也将etcd部署于其中)。

  NodeKubernetes采用Master-Slaves方式部署,单独一台Slave机器称为一个Node(以前叫 Minion)。

  PodsKubernetes最小管理单位,用于控制创建、重启、伸缩一组功能相近,共享磁盘的Docker容器。虽然Pod可以单独创建使用,但是推荐通过Replication Controller管理。

  Replication controllers(RC):管理其下控制的Pods的生命周期,保证指定数量(replicas)的Pods正常运行。

  Service:可用作服务发现,类似于Loadbalancer,通过Selectors为一组Pods提供对外的接口。

  LabelsK/V键值对,用来标记Kubernetes组件的类别关系(例如标记一组Pods是frontServices,另一组是backServices)。Labels对于Kubernetes的伸缩调度非常重要。

Pod是Kubernetes中的核心观念,它提供了一种管理Docker实例的新结构,把一组功能接近、需要相互直接通讯和共享磁盘的Docker实例组合起来管理,而Kubernetes的调度机制也是基于pod,完成整个应用的弹性伸缩能力。

Kubernetes在设计上可以适配各种基础设施形态。但是,如前所述,我们认为IaaS平台才是部署Kubernetes集群的最理想环境。在国内多个公有云IaaS环境内,我们选择了青云作为Kubernetes入门实践的环境,这其中的原因包括:

  从安全角度看,类似Kubernetes这类的PaaS应该是部署在VPC内。青云VPC在国内是独树一帜,特别适合用来部署Kubernetes这种分布式应用。

  从部署管理角度看,青云提供的“userdata”和“metadata”功能在自动初始化云主机上非常有用,可以简化整个部署过程。

  从成本和灵活性角度看,青云的按秒计费,资源快速响应是非常有吸引力的。这点以我们自身为例:一年多以来我们已经在青云上面创建了超过1万五千台虚机,花费仅在1000多。

从前面关于Kubernetes集群的介绍可以了解到,整个集群部署还是有不少的工作量,尤其是需要完整的发挥出来Kubernetes+IaaS带来的弹性伸缩能力,并提供广泛的日常宿主机管理功能。所以,我们使用FIT2CLOUD来管理Kubernetes集群下面使用的IaaS平台资源,并在其上完成集群的自动化部署,统一监控,Kuberenetes集群自身升级等工作。

从目标用户视角看,Kubernetes集群(容器云)的使用者是应用开发人员,或者准确的讲是基于Docker容器的微服务开发者,而FIT2CLOUD和QingCloud的使用者是Kubernetes集群(容器云)运维和系统管理员。下图描述了Kubernetes、QingCloud、FIT2CLOUD三者及其使用者之间的关系:


如果你对于整个部署和实践的过程非常感兴趣,可以参考我们的在线博客文章:http://blog.fit2cloud.com/2015/10/11/fit2cloud-kubernetes-qingcloud.html。按照其中的详细介绍一步步完成整个过程。整个实践过程只需要拥有青云公有云帐号并开通FIT2CLOUD在线版就可以完成,尝试门槛非常低。

可能会有不少了解Kubernetes的人会奇怪为啥使用FIT2CLOUD在青云上部署一个Kuberenetes这么“复杂”。尽管现在是做一个Kuberenetes入门实践的演示,但是我们仍然希望能够完整的展示在IaaS平台上运行Kuberenetes集群需要涉及的很多方面工作(尤其是和IaaS平台在弹性伸缩能力的打通、对于日常运维Kuberenetes集群的支撑、自动化部署集群的需求等方面)。例如,在我们示例的结尾就会演示kubernetes集群在遇到突发高负载的情况下如何借助FIT2CLOUD自动向IaaS请求更多资源,自动完成部署操作,自动加入集群并承载溢出负载的场景。这个场景再次说明了Kubernetes运行在IaaS平台上的重要性,同时也展示了FIT2CLOUD在粘合IaaS层和容器云PaaS层的作用。

当然,这个例子也说明了FIT2CLOUD在以kubernetes为代表的容器云技术栈中的定位。具体如下图所示:


这也是我们今天要表达的第二个观点:我们认为在IaaS和PaaS容器云之间还需要一层Management & Enabling平台,而FIT2CLOUD则就是定位于这一层平台。

当然,目前的示例还是有一些明显的不足之处需要改进。主要包括如下两点:

1)当前的Kubernetes集群仍然是单Master节点,并且保存所有集群状态信息的etcd也是部署在该台Master节点上。这个还需要等待Kubernetes能够在Master的HA上解决问题才能够搞定。目前这个已经在Proposal阶段(https://github.com/kubernetes/kubernetes/blob/master/docs/proposals/high-availability.md)

2)当前部署方式仍然对于Master和Slave节点的顺序关系有要求(需要先启动Master节点,再启动Slave节点)。

在这个入门实践中,IaaS层管理以及Kubernetes集群自身的部署、运维工作都可以通过FIT2CLOUD控制台完成。但是对于Kubernetes自身的管理工作还是离不开Kubernetes的命令行工具:kubectl。大家可以到Kubernetes官网下载、安装该命令行工具,从而可以远程操作Kubernetes集群。当然,FIT2CLOUD也提供执行脚本的能力,通过其直接在Kuberenetes的Master节点(该节点已经被FIT2CLOUD管理)执行kubectl命令,完成相关管理操作。

最后,总结一下本次分享,包括如下几个部分:

1) 首先介绍了容器、容器云以及和IaaS的关系,提出我们关于容器云的第一个观点,即只有运行在IaaS之上的容器云才是真正意义上的容器云。

2)其次说明我们在容器编排和调度技术选型方面的观点,认为kubernetes未来会有很大发展潜力。

3)然后介绍了Kubernetes的基本架构,功能特征等方面知识,方便大家对其有基本了解。

4)最后介绍了如何利用FIT2CLOUD在青云上快速部署Kubernetes集群,并阐述了我们的第二个观点:在IaaS和容器云PaaS之间仍然需要一层,而FIT2CLOUD则定位于此。

QA

问:微软的windows server 2016称支持docker,这对容器生态圈有何影响 ? 另外,我是先接触的容器,再接触的kvm,我感觉容器比KVM弱很多,特别是KVM技术引领了芯片的设计和优化很多年。所以 我想问一下,docker未来与KVM是什么个关系?

徐桂林:这个影响短时间不会太大。但是其潜在影响会慢慢出来,即使在今天,服务端基于Windows堆栈的市场占有率任然》30%,Windows支持Docker是其在服务端市场自救的一个重要举措,让Windows用户有继续留下来的理由。但是需要注意Microsoft公司策略在新CEO上台后有很大变化。最明显的就是“Windows Azure” 命名成为“Microsoft Azure”,这其中滋味相信大家都懂的。

我这里补充一点:很多人一听Docker运行在IaaS的VM中觉得很奇怪,Docker诞生的时候不是说要解决VM虚拟化过重的问题嘛,怎么又跑到VM内部Run了。首先,无论是KVM,还是其他虚拟化技术。它的业务价值在于解决计算资源灵活交付的问题。而Docker为代表的容器技术到目前还没有办法达到KVM级别的资源交付能力,更多是定位在资源调度和利用层。就如我前面所述,我们认为未来相当长的时间内,两者仍然会各自为阵。及KVM完成资源虚拟化交付给Docker为主的容器云充分使用

参与方式

1. 微信:CSDN Container用户群,你可以扫描下方微信二维码,由工作人员拉入

2. QQ:加入CSDN Docker技术交流QQ群,群号:470410322 。分享内容会同步直播



0
0