公有云上的容器实践分享

运维派——国内最大的IT运维社区,欢迎关注运维派微信公众号(ID: yunweipai),获取更多资讯

顾伟

本次分享介绍普元基于微服务架构,在公有云上的一次容器实践,包括如何选型,做了哪些技术验证,遇到了哪些问题,如何解决的。分享中还包括对于云平台本身高可靠、高性能、持续发布、服务注册发现等方面的设计方案,以及后续的发展愿景及规划,旨在与大家探讨一些关于Docker、Kubernetes、CoreOS、Hystrix等具体技术的实践经验,同时希望大家能给我们的平台设计提供更好的建议。

公有云上的容器实践分享

大家好,我是普元软件的顾伟,很高兴有机会与各位分享我们在云上的容器实践。

因为我们是从DevOps开始做起的,所以分享里会有DevOps的一些影子,大家自动过滤就好,不是今天的重点。

阿里云

主要分了四个部分和大家讨论:

  • 首先我们最终选择了阿里云,为什么是阿里云;
  • 接着是今天的核心部分,包括我们使用了什么技术,做了哪些关键设计;
  • 在公有云上用Docker不像私有云那样,很多问题需要自行解决甚至绕着解决;
  • 最后是总结以及目前我们平台的一个概览。

阿里云

选择阿里云从两方面来看,第一是我们用了多年,从体验上来评价,阿里云的几个主打服务(ECS、RDS、OSS、ODPS等)还是很不错的。

云服务商

第二个方面考虑的是匹配度的问题,其实做容器,最合适公有云上莫过于AWS和Azure,但由于国外厂商的原因,比如AWS在国内至今没有备案机房(北京那个一直被说是非法营运…);

而在国内,公有云是有不少,甚至还有不少本身就是容器方向的,但既然我们有自己的方向,那肯定要自己做才行,最好选一个有保证的,BAT绝对是首选。

公有云

那做容器,自然又有很多技术栈可选,所以说,以前架构师在做加法(产品集成),现在架构师是在做减法(从开源中选最合适的),我们定了三个原则:

  • 我们其实是公有云和私有云一起做的,用两套完全不一样的技术栈对我们来说显然成本太高,所有一致性很重要;
  • 我们是面向企业市场的,就目前的市场来看,VM模式仍是主流,何况我们还有传统IaaS产品(基于OpenStack的),所以还是要有一套兼顾容器与VM的模型;
  • 大家肯定都用了不少开源软件,最头疼的就是出了问题解决不了,比如以前用InfluxDB时,内存一大动不动就宕了,只能到处找方法,自己cover不住,所以如果决定用某项技术,一定要深入进去,跟社区,自己编译调整,有问题自己能处理。

技术选型与验证

在容器上我们看了很多技术栈,比如宿主机是用CentOS还是CoreOS还是Ubuntu还是其他,是否需要肉机模式,调度层用Kubernetes还是Mesos,容器是用rkt还是Docker,网络是平铺还是子网,用Flannel还是OVS,有或者用Pipeworks呢?

验证了很多,发现一个问题,貌似哪个技术对我们来说都可以,为什么?原因很简单,缺了DDD的理念,只从技术看,缺乏场景驱动;当然验证了很多是很有用的,至少我们有了一些数据,有了一定的技术积累,为后续选型提供了更充分的依据。

所以我们从设计开始着手,做了以下几件事:

容器

  • 首先是概念模型,熟悉Borg或Kubernetes的同学或多或少能看出来这张图的理念,我们其实用的就是Kubernetes;
  • 自底向上来看,底层是资源池,提供不同SLA的资源能力,紧接着是Namespace,这个是个可选的实体概念,可用于做租户隔离(当然下层也可以做,只是为了更进一步考虑,可以做逻辑隔离);
  • 在业务运行的概念中,四个实体都很关键,一般来说一个Process是一个原子能力,它有可以依赖其他的原子能力,多个能力汇聚在一起时,形成了Pod(也就是说Pod里是一组相关的能力);
  • 以一组相关的能力组成的业务为单位,这种业务可以支持多副本(或者叫集群),也就是图上的Replication,和传统的集群不一样的在于有多种模式,比如双主、主备等等;
  • 最终这些业务集群以一个统一的服务(Service)提供对外能力,下层集群实例的任何变更(如漂移、伸缩等),都不会影响service的属性,这样就做到了对上游服务的友好性;
  • 对于产品定义的模型,不是今天的重点,就先不提了。

9

那无论在容器还是VM模式下,可参考的部署架构就如上图所示,这里面有三个关键:

  • 网络,宿主机(ComputeNode)有自身的IP段,容器(p1、p2…)在自身的逻辑网里,而Service是虚IP;
  • 副本,通过状态维护,发现数量的变更,调度下一步动作;
  • 存储,对于有状态和无状态的服务,可选用不同方案,比如有状态可使用NFS、GlusterFS这些共享存储,而无状态的可用ISCSI这些非共享存储方案。

10

容器之间的调用我们使用了Flannel方案,这样就有了上述的4点,大家可以自行细看一下,倒没有太多特别的。

11

那对于容器间除了互通,还要有隔离能力,可通过宿主机、Namespace、逻辑子网、iptables等做不同的一些场景,针对不同场景完成隔离需求,Kubernetes最新版本还在做更细粒度的隔离,这个大家可以关注一下。

12

在微服务场景下,升级、回退,包括灰度这些能力要求越来越高,目前我们是以镜像版本作为原子粒度的,有几个注意点大家在设计时要注意下:

  • 原子化,制定最小粒度的可操作单元;
  • 标签设计,现在很多云服务商都提供这个能力,以AWS为代表,对外提供了自定义管理维度的途径,对内也通过标签能力给了批量、滚动升级回退的便捷;
  • 状态,部署虽然是原子化的,当过程状态是有变更的,原子部署过程中亦可做到挂起和唤醒 版本规范,这个是升级回退的重要点;
  • 路由,这个在金丝雀、灰度上尤为重要,目前我们采用了OpenResty,热更新路由策略,有一些小问题,后续有机会可细聊。

13

说实话,伸缩其实并没有外界传的那么神乎其神(至少我了解的现在就算是顶尖互联网公司都是事先预置和规划为主),有时候我甚至没觉得他有多重要,除非说在伸缩过程中,可以临时利用废弃机器,或者省下的机器可以真正关掉(比如省电)这些大规模场景下,我才觉得有点意义,可能我们做的比较小,或者企业都希望前期有规划可预期的原因吧。

而漂移反而是有实际作用的,比如合理的漂移可以减少网络链路,可以将不同需求的能力分到不同能力的资源上(优化),就拿优化来举例,目前我们做的比较简单,先查出符合要求的,再找更优的。

原则其实很简单,就是策略与权重的定义选择。

14

对于容器里跑的服务,由于现在的服务都拆的细,自然就多了,多了就有很多问题,比如监控,比如安全,这里我拿服务熔断与降级举例,当然这两个概念还不太一样(熔断是像股市那样,下游服务有问题了,通过熔断保证自身的可用性,而降级一般是现有资源瓶颈的情况下,优先保证核心服务,一般的服务直接降级处理):

设计时主要保持了三态,正常情况下,熔断器是关着的,下游出问题后,进入半开状态(所谓半开就是允许一部分流量继续去探测下游的健康型),再接着探测的那部分流量还是不行,就直接全开熔断器,否则也许好了,又可以关掉熔断器了。

当然,这里面还有很多指标要结合,比如MTTR,推荐大家关注Hystrix框架,个人感觉比Motan等要考虑的全很多。

容器

接着我们来说说过程中遇到的一些问题吧,之前也提过了,用公有云少不了要“受制于人”,不过这也是合理的。

比如我们用了CoreOS,几个月之前只有北京数据中心有,版本低,好不容易升上去了(记得要自己搭建升级服务器,这块要是大家有兴趣,可以下次交流),发现快照打不了,阿里云客服说是不支持升级(CoreOS不支持无缝升级,还有谁用CoreOS?),其实最终原因也蛮扯,有一个yunservice(姑且认为是阿里云的后门吧)搞的,大家不要看着没用就想关掉,我们就是工程师为了缩减和加固时弄出问题来了….

再比如我们用了VPC服务,因为EIP受限,导致service的public IP不够的问题,当然这个只能再省着点规划了……

公有云

这个时候还遇到了其他的问题,吐槽一下:尤其第一条,ACE下线,虽说和本次版本关联性不大,这是我13年在阿里云整整一年合作的基础产品,让我对阿里云的服务说下就下这种做法有点无语,所以后面调整了策略,只有阿里云的ECS、VPC,其他如OSS、RDS、MetaQ一概不用了,自己来弄。

公有云

一个很关键的节点,万幸的是:最终我们还是跑起来了,几个关键步骤:

  • 系统升级,升级到991.0.0,这里面其他还好,关键是升级后重启时,网络起不来,只能手工先干了,谁让不支持自定义镜像呢,或者插入些前后脚本也好;
  • 外挂盘,这个倒还好,主要就是挂载+格式化,我们使用了高效云盘;
  • Kubernetes安装,一般来说有三种方式,命令型、服务型、容器型,在阿里云上想用容器型,还是要花很多功夫的,这个不细说问题了,最终我们用了前两种混合;
  • 安装完成后,少不了环境验证,尤其网络,毕竟不清楚阿里云底层网络结构,用了setup-network-enviroment辅助,还好没遇到大问题,容器间网络很快通了。

容器

当然,有些坑填了,有些坑绕了,我们也丧失了一些好的特性:比如用过AWS容器技术的同学应该清楚,Kubernetes和AWS的配合,和GCE一样天衣无缝,但是在阿里云上像DNS这些好特性可能就有些受限,还有数据库,虽然用容器跑了主主的MySQL,但我们做的离RDS还是有不少差距的。

容器

还有一些经验不足或时间不够导致的问题:

  • 比如说网络用了Flannel,这个组件的性能还有一定问题,还没有优化到最好;
  • 再比如我们使用了CPU超配,如果阿里云本身虚拟化层也用了,那可能就会有问题了。

20

今天的分享主要集中在Kubernetes这块了,其实我们还有很多技术栈的使用,比如Spring Boot、Ceph、ES、InfluxData、Swagger这些,下次有机会再聊,因为我们做的是DevOps,所以往上延伸的会多一些。

架构

这是现有平台架构如上图,大家参考即可,主要是围绕DevOps,元数据驱动、运营与遥测等设计的,可以简单浏览一下平台的截图:

22

公有云上的容器实践分享 公有云上的容器实践分享 公有云上的容器实践分享

当然还有很多缺失的工作,后续需要补充和演进:

  • 自动化能力还需提升,平台开发平台自身还没有完全做到,服务也不够丰富,还有要和阿里云再谈一谈(就是那些我们绕不过去的坑);
  • 监控和安全还要补一补,包括Metrics、log等,这期主做的是基于cAdvisor的容器监控和日志收集;
  • 客户个性化,现在的租户,在公有云上目前所拥有能力是一样的,还需更好的配置个性化,C2M。

没有一家能够解决所有问题,也希望有更多的合作商一起建立生态,共同提升云计算上下游能力。

Q&A

Q:请问你们是生产环境么,应用代码放容器里还是挂卷,镜像权限如何控制(比如测试和生产),代码测试后,上生产配置自动还是手动修改还是有配置中心呢?

A:您指的是源码还是编译后的产物,我们是编译后的产物是镜像,容器直接运行,测试和生产是隔离的,相当于我们管理了四套环境(开发、测试、预发、生产),介质是通过跳板机同步的,有统一的SCM做不同环境的配管。

Q:Kubernetes Master的高可用你们是怎么做的?

A:Master我觉得没必要做,宕了重启就行,没有损失,我们就是这么做的,只要保证etcd等高可用就行。

Q:从集群外部对Kubernetes的Service的访问是如何实现的?比如公网IP是怎么绑定给Service的?

A:Kubernetes发布成Service,是可以给定publicip的,这个时候你可以用公网IP作为网络池,内部有一层端口映射。

Q:Kubernetes现在自己还缺少可视化编排能力,那个UI也是以监控为主,你们实际使用中对Kubernetes可视化编排需求多吗,如果多的话目前怎么解决 ?

A:我们自己做了部分编排,编排不一定非得是图形化的,我们以表单为主,主要用于部署编排。

Q:阿里云上的容器能提供负载均衡嘛比如我有个宿主机挂了?

A:这个不是阿里云做,而是Kubernetes做的,Kubernetes有Replication的能力。

Q:这几天遇到个需求,用户想要通过VNC进入容器里安装他的应用,请问你们碰见过吗,网络方面怎么解决呢,需要将用户使用的容器配置上外网的IP,我们也用Flannel,但Flannel似乎不行吧?

A:这不是个好方式,这是把容器当虚机用,如果真要这么做,那Flannel就不要用了,直接端口映射或者Pipework,但真不建议,会丧失容器的好特性。

文章出处:Docker微信公众号

网友评论comments

发表评论

电子邮件地址不会被公开。 必填项已用*标注

暂无评论

Copyright © 2012-2017 YUNWEIPAI.COM - 运维派 - 粤ICP备14090526号-3
扫二维码
扫二维码
返回顶部