为什么我们不能使用KUBERNETES 原

iptable的性能限制

kubernetes的服务发现到node创建启动，最终到提供服务，中间都离不开iptable的nat模块，在业务高访问量的情况下，这是无法满足性能要求的。

说明文档残缺

Kubernetes目前在快速迭代，国内可能最新的文档才使用0.6.2的版本，可是当下的版本都已经多了0.17.0了，中间有的服务的启动参数稍稍的发生了变化，但是仅凭-h参数打印出来的说明和官方的doc，这么抽象的东西，很难让人深入研究。

部署复杂

master需要启动至少四个服务apiserver  scheduler  controller-manager 和 etcd，如果要将这些组件应用到生产环境，你还需要考虑他们的高可用，而且这仅仅是一个master, slave的启动你还需要部署kubelet和proxy服务，这中间光启动需要开发的外部可访问端口就多达8个之多。

这还仅仅是最简单的部署方式，kuber还包含了一些其他cloud平台的支持，你可能要深入服务的代码深入的对其进行阉割以防止出现安全问题。

网络架构限制

我们的网络架构要求docker必须采用的网络模式为host模式，对于服务的前端需要keepalive+haproxy来对其做负载均衡和容灾，可是这些组件都难以和kuber很好的结合。apiserver的启动需要一组虚拟ip支持，这我们也难以办到。proxy需要的nat我们也不能提供。

联想到我们目前的情况，我又想起我们当时为什么要下力气弄docker，经理对我们说：“一切都要以解决问题为目标”

那我们当时需要解决的问题：1.解决发布效率底下，发布复杂混乱的问题，2.解决业务包的升级问题。3.解决业务包的软件环境和配置的管理更新问题   docker的出现为我们以版本方式管理软件环境提供了很强的支持，但是如何制作配套的管理系统呢？我们可能需要管理系统有强悍的‘软件升级’ 方便的业务部署  并且能很好的和现有的系统进行结合。到底哪种架构对于我来说是最合适的？