编者注:
本文基于上海容器大会现场演讲内容,立足于实战跟大家分享了新一代PaaS平台构建中遇到的问题、当下主流PaaS平台解析、企业交付经验及心得体会等。文章较长,分为上、下两个部分,本文为下篇。
前文阅读请点击:容器驱动的PaaS平台实现方案(上)
下面我花一点时间跟大家分享下比较干货的东西。比如说容器的网络,之前我们也听了一些专家谈到Flannel,Calico 等等,但是我不知道大家有没有注意到,国内外在谈容器网络的时候更多的时候会再谈Overlay网的构建,比如IPSec、VXLAN等等,都是标榜所谓的SDN思路,其实也就是隧道技术的构建。去年的时候我跟很多朋友去谈,大家都说很好啊很先进啊,但是今年再去谈的时候发现大家已经不感冒了。大家对容器已经有了深入的认识,已经开始考虑现实的问题。这里有几个故事分享给大家。
我们南区的一家银行客户,他们为什么会不喜欢Overlay呢,他们说的是因为网络团队不具备Troubleshooting Overlay网络的能力; 而北区一个银行客户,他们道理是说我们已经采用了其他SDN的解决方案,我不希望你在里面再打个洞。还有上海的一个客户,不喜欢任何形式的Overlay,因为它性能drop得很厉害。基于各方面的考虑,我发现越来越多的客户不喜欢用Overlay的容器网络。而我觉得最根本的原因,无论我们作为厂商跟客户交流还是客户自己去谈容器项目或者启动容器项目时,我想源动力更多的是来自于开发部门、运维部门,很少有网络部门牵头说我要弄容器。对于网络部门来说,当你去沟通需要搞什么容器或者更牛的技术的时候,他们的反馈会是只要不改变已有的网络你怎么搞都行,但是如果你想动我的网络我是不会同意的,所以我想这是个很现实的问题。我们的思路是说,Overlay网络很好,但是我们基于现实考虑,怎样构建一个跟传统IT网络相兼容的容器网络。
另外一方面是容器的存储,大家都在谈,容器最好应用在无数据状态的场景。但是如果大家对容器是非常有信心的态度的话,我相信早晚有一天我们所有的业务,包括我们所有的有状态应用或是无状态应用,都会跑在容器里面。或者说这些问题早晚有一天是要解决的。我们有容云内部有个项目,就是要解决好容器数据的问题。比如,是否可以由程序员来指出他的程序希望跑到什么类型存储上去,当应用部署到容器平台上的的时候,系统可以自动识别到由程序员提供的存储使用标签,比如说你希望把Application运行在IO性能很高的存储上,那我们的 存储控制器就能自动把 应用程序接驳到SSD这边来。如果我们看到你的数据标签是希望支持一个每天晚上12点的自动拍照,那我们的存储控制器会自动帮你做这些工作。现在我们在做这方面的工作的原因之一是,传统的storage方案都不是天然为Docker去开发的,这些storage都不是Native 的container storage。所以我们在做的就是从零开始构筑一个自己的存储体系,一个分布式存储,我们的分布式存储完全是根据Docker或者说容器云的场景来开发的。这个产品将在今年下半年发布。