本文讲的是DockOne微信分享（六十五）：公有云上的容器实践分享【编者的话】本次分享介绍普元基于微服务架构，在公有云上的一次容器实践，包括如何选型，做了哪些技术验证，遇到了哪些问题，如何解决的。分享中还包括对于云平台本身高可靠、高性能、持续发布、服务注册发现等方面的设计方案，以及后续的发展愿景及规划，旨在与大家探讨一些关于Docker、Kubernetes、CoreOS、Hystrix等具体技术的实践经验，同时希望大家能给我们的平台设计提供更好的建议。
大家好，我是普元软件的顾伟，很高兴有机会与各位分享我们在云上的容器实践。
因为我们是从DevOps开始做起的，所以分享里会有DevOps的一些影子，大家自动过滤就好，不是今天的重点。
主要分了四个部分和大家讨论：
选择阿里云从两方面来看，第一是我们用了多年，从体验上来评价，阿里云的几个主打服务（ECS、RDS、OSS、ODPS等）还是很不错的。
第二个方面考虑的是匹配度的问题，其实做容器，最合适公有云上莫过于AWS和Azure，但由于国外厂商的原因，比如AWS在国内至今没有备案机房（北京那个一直被说是非法营运…）；
而在国内，公有云是有不少，甚至还有不少本身就是容器方向的，但既然我们有自己的方向，那肯定要自己做才行，最好选一个有保证的，BAT绝对是首选。
那做容器，自然又有很多技术栈可选，所以说，以前架构师在做加法（产品集成），现在架构师是在做减法（从开源中选最合适的），我们定了三个原则：
在容器上我们看了很多技术栈，比如宿主机是用CentOS还是CoreOS还是Ubuntu还是其他，是否需要肉机模式，调度层用Kubernetes还是Mesos，容器是用rkt还是Docker，网络是平铺还是子网，用Flannel还是OVS，有或者用Pipeworks呢？
验证了很多，发现一个问题，貌似哪个技术对我们来说都可以，为什么？原因很简单，缺了DDD的理念，只从技术看，缺乏场景驱动；当然验证了很多是很有用的，至少我们有了一些数据，有了一定的技术积累，为后续选型提供了更充分的依据。
所以我们从设计开始着手，做了以下几件事：
那无论在容器还是VM模式下，可参考的部署架构就如上图所示，这里面有三个关键：
容器之间的调用我们使用了Flannel方案，这样就有了上述的4点，大家可以自行细看一下，倒没有太多特别的。
那对于容器间除了互通，还要有隔离能力，可通过宿主机、Namespace、逻辑子网、iptables等做不同的一些场景，针对不同场景完成隔离需求，Kubernetes最新版本还在做更细粒度的隔离，这个大家可以关注一下。
在微服务场景下，升级、回退，包括灰度这些能力要求越来越高，目前我们是以镜像版本作为原子粒度的，有几个注意点大家在设计时要注意下：
说实话，伸缩其实并没有外界传的那么神乎其神（至少我了解的现在就算是顶尖互联网公司都是事先预置和规划为主），有时候我甚至没觉得他有多重要，除非说在伸缩过程中，可以临时利用废弃机器，或者省下的机器可以真正关掉（比如省电）这些大规模场景下，我才觉得有点意义，可能我们做的比较小，或者企业都希望前期有规划可预期的原因吧。
而漂移反而是有实际作用的，比如合理的漂移可以减少网络链路，可以将不同需求的能力分到不同能力的资源上（优化），就拿优化来举例，目前我们做的比较简单，先查出符合要求的，再找更优的。
原则其实很简单，就是策略与权重的定义选择。
对于容器里跑的服务，由于现在的服务都拆的细，自然就多了，多了就有很多问题，比如监控，比如安全，这里我拿服务熔断与降级举例，当然这两个概念还不太一样（熔断是像股市那样，下游服务有问题了，通过熔断保证自身的可用性，而降级一般是现有资源瓶颈的情况下，优先保证核心服务，一般的服务直接降级处理）：
设计时主要保持了三态，正常情况下，熔断器是关着的，下游出问题后，进入半开状态（所谓半开就是允许一部分流量继续去探测下游的健康型），再接着探测的那部分流量还是不行，就直接全开熔断器，否则也许好了，又可以关掉熔断器了。
当然，这里面还有很多指标要结合，比如MTTR，推荐大家关注Hystrix框架，个人感觉比Motan等要考虑的全很多。
接着我们来说说过程中遇到的一些问题吧，之前也提过了，用公有云少不了要“受制于人”，不过这也是合理的。
比如我们用了CoreOS，几个月之前只有北京数据中心有，版本低，好不容易升上去了（记得要自己搭建升级服务器，这块要是大家有兴趣，可以下次交流），发现快照打不了，阿里云客服说是不支持升级（CoreOS不支持无缝升级，还有谁用CoreOS？），其实最终原因也蛮扯，有一个yunservice（姑且认为是阿里云的后门吧）搞的，大家不要看着没用就想关掉，我们就是工程师为了缩减和加固时弄出问题来了....
再比如我们用了VPC服务，因为EIP受限，导致service的public IP不够的问题，当然这个只能再省着点规划了......
这个时候还遇到了其他的问题，吐槽一下：尤其第一条，ACE下线，虽说和本次版本关联性不大，这是我13年在阿里云整整一年合作的基础产品，让我对阿里云的服务说下就下这种做法有点无语，所以后面调整了策略，只有阿里云的ECS、VPC，其他如OSS、RDS、MetaQ一概不用了，自己来弄。
一个很关键的节点，万幸的是：最终我们还是跑起来了，几个关键步骤：
当然，有些坑填了，有些坑绕了，我们也丧失了一些好的特性：比如用过AWS容器技术的同学应该清楚，Kubernetes和AWS的配合，和GCE一样天衣无缝，但是在阿里云上像DNS这些好特性可能就有些受限，还有数据库，虽然用容器跑了主主的MySQL，但我们做的离RDS还是有不少差距的。
还有一些经验不足或时间不够导致的问题：
今天的分享主要集中在Kubernetes这块了，其实我们还有很多技术栈的使用，比如Spring Boot、Ceph、ES、InfluxData、Swagger这些，下次有机会再聊，因为我们做的是DevOps，所以往上延伸的会多一些。
这是现有平台架构如上图，大家参考即可，主要是围绕devops，元数据驱动、运营与遥测等设计的，可以简单浏览一下平台的截图：
当然还有很多缺失的工作，后续需要补充和演进：
没有一家能够解决所有问题，也希望有更多的合作商一起建立生态，共同提升云计算上下游能力。
大家好，我是普元软件的顾伟，很高兴有机会与各位分享我们在云上的容器实践。
因为我们是从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的属性，这样就做到了对上游服务的友好性；
- 对于产品定义的模型，不是今天的重点，就先不提了。
那无论在容器还是VM模式下，可参考的部署架构就如上图所示，这里面有三个关键：
- 网络，宿主机（ComputeNode）有自身的IP段，容器（p1、p2...）在自身的逻辑网里，而Service是虚IP；
- 副本，通过状态维护，发现数量的变更，调度下一步动作；
- 存储，对于有状态和无状态的服务，可选用不同方案，比如有状态可使用NFS、GlusterFS这些共享存储，而无状态的可用ISCSI这些非共享存储方案。
容器之间的调用我们使用了Flannel方案，这样就有了上述的4点，大家可以自行细看一下，倒没有太多特别的。
那对于容器间除了互通，还要有隔离能力，可通过宿主机、Namespace、逻辑子网、iptables等做不同的一些场景，针对不同场景完成隔离需求，Kubernetes最新版本还在做更细粒度的隔离，这个大家可以关注一下。
在微服务场景下，升级、回退，包括灰度这些能力要求越来越高，目前我们是以镜像版本作为原子粒度的，有几个注意点大家在设计时要注意下：
- 原子化，制定最小粒度的可操作单元；
- 标签设计，现在很多云服务商都提供这个能力，以AWS为代表，对外提供了自定义管理维度的途径，对内也通过标签能力给了批量、滚动升级回退的便捷；
- 状态，部署虽然是原子化的，当过程状态是有变更的，原子部署过程中亦可做到挂起和唤醒 版本规范，这个是升级回退的重要点；
- 路由，这个在金丝雀、灰度上尤为重要，目前我们采用了OpenResty，热更新路由策略，有一些小问题，后续有机会可细聊。
说实话，伸缩其实并没有外界传的那么神乎其神（至少我了解的现在就算是顶尖互联网公司都是事先预置和规划为主），有时候我甚至没觉得他有多重要，除非说在伸缩过程中，可以临时利用废弃机器，或者省下的机器可以真正关掉（比如省电）这些大规模场景下，我才觉得有点意义，可能我们做的比较小，或者企业都希望前期有规划可预期的原因吧。
而漂移反而是有实际作用的，比如合理的漂移可以减少网络链路，可以将不同需求的能力分到不同能力的资源上（优化），就拿优化来举例，目前我们做的比较简单，先查出符合要求的，再找更优的。
原则其实很简单，就是策略与权重的定义选择。
对于容器里跑的服务，由于现在的服务都拆的细，自然就多了，多了就有很多问题，比如监控，比如安全，这里我拿服务熔断与降级举例，当然这两个概念还不太一样（熔断是像股市那样，下游服务有问题了，通过熔断保证自身的可用性，而降级一般是现有资源瓶颈的情况下，优先保证核心服务，一般的服务直接降级处理）：
设计时主要保持了三态，正常情况下，熔断器是关着的，下游出问题后，进入半开状态（所谓半开就是允许一部分流量继续去探测下游的健康型），再接着探测的那部分流量还是不行，就直接全开熔断器，否则也许好了，又可以关掉熔断器了。
当然，这里面还有很多指标要结合，比如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超配，如果阿里云本身虚拟化层也用了，那可能就会有问题了。
今天的分享主要集中在Kubernetes这块了，其实我们还有很多技术栈的使用，比如Spring Boot、Ceph、ES、InfluxData、Swagger这些，下次有机会再聊，因为我们做的是DevOps，所以往上延伸的会多一些。
这是现有平台架构如上图，大家参考即可，主要是围绕devops，元数据驱动、运营与遥测等设计的，可以简单浏览一下平台的截图：
当然还有很多缺失的工作，后续需要补充和演进：
- 自动化能力还需提升，平台开发平台自身还没有完全做到，服务也不够丰富，还有要和阿里云再谈一谈（就是那些我们绕不过去的坑）；
- 监控和安全还要补一补，包括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，但真不建议，会丧失容器的好特性。
以上内容根据2016年6月28日晚微信群分享内容整理。分享人顾伟，毕业于东南大学，10年工作经验，现任普元公司主任架构师；先后参与和带领了华为BME，中信银行CBJUP，工商银行CTP，中航信RI，阿里云ACE，普元云计算平台，普元The Platform等大型项目的交付；长期致力于IT技术研究、产品设计、架构咨询等工作，擅长Web、OSGI、CI/CD、服务治理、云计算等领域技术，对DevOps、自动化运维、微服务架构有着浓厚的兴趣。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
原文发布时间为：2016-06-28
本文作者：顾伟
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：DockOne微信分享（六十五）：公有云上的容器实践分享
