Part2-CloudInfrastructure:Kubernetes

从Openstack 到Docker/Kubernetes的迁移

从Openstack到Kubernetes的决策，其实也没有那么一蹴而就；我们在14年中 PaaS 团队开始持续集成的工作的时候，就决定，基于 Docker 来做持续集成，一方面先蹚一 下 水， 先积累一部分经验， 也需要有人先去踩坑 ； 一方面看上去持续集成 用 Docker 相对于VM 的确是一个 好的多 的解决方案 ；所以实际上把有限的资源并行投入做了两件事情：基于Docker/Kube的持续集成，和基于Openstack的IaaS平台； 不能把团队已经搞了一年多的 Openstack 放掉， 因为 不管怎么样，开发测试环境还是需要 Openstack 的vm环境的 ，而且当时也不是完全确定Docker一定会是行业趋势 ；

最早的持续集成的环境，我们就是采用完全原生的 Kubernetes 解决方案，基本上直接沿用了kubeproxy（完全内包含的）和flannel网络，主要的精力在做外部业务流程，和Kube本身的熟悉，和应用的Docker化支持和迁移（这个耗费了我们PaaS团队50%的总体精力）；

一方面Kubernetes/Docker社区的发展，一方面从逻辑上来讲，Docker的确比 Openstack  要轻量的多，也包含了镜像发布这个更加完美的解决方案，overhead也比VM低很多，kube不仅仅解决了provision的问题，也极大的解决了provision，auto-scaling和deploy一致性的问题，以及可以比较容易的进行auto-scaling，相比 Openstack ，流程简单太多了；整体生产环境的一致性问题，和开发测试环境之间的一致性问题，都得到了极好的解决；鉴于对技术本身的评估分析，社区的发展方向和已有Kube环境的熟悉，以及在Openstack推生产碰到的非技术阻力，我们决定开始更大的投入Kubernetes,把私有云的Foundation切换成基于Docker-Kubernetes的解决方案；

向Kubernetes迁移的进展和计划

一个是需要保证Docker的稳定性和可监控性；

一个是 Kubernetes 集群的网络设置；

一个是需要保证Kubernetes control plane的稳定性，kube扩展性暂时不在主要考虑范围内；

一个是持续集成扩展到持续部署到测试环境的流程；

一个side project:Database on Docker swarm集群的建设

 Docker的稳定性推进

Docker其实 一开始就没有太多问题，在初步决定推Kubernetes解决方案做为云平台的整体解决方案的时候，我们已经在持续集成环境里面测试了接近大半年，解决了一部分问题,也逐步熟悉了Docker本身； 基本上做的，就是一个是梳理了网上能够看得到的主要的Docker的问题并且进行了 监控和 规避，一个是进行了详尽的性能和压力测试 和主机层面的优化 ，一个是详细测试了Docker的磁盘IO和CPU和内存的隔离性；以及在宿主机上反复创建和销毁Docker有无异常等各种可能问题的测试； 另外一个是确保就算Docker Daemon挂掉，Docker instance还可以正常运行；通过另外一个side project database on docker swarm我们也生产验证了在大压力环境下，Docker的稳定性； 单机只要不是 Linux Kernel出现大的bug，一般不会出现大规模问题, Linux Kernel在Openstack & DB on Docker的实际运行下还是表现淡定；

Kubernetes集群的网络方案的确定

最早在PaaS CI环境里面，我们用的是flannel网络+kubeproxy；也碰到一些小问题，但是基本上还可以解决后work ok，一方面毕竟规模很小，一方面是一个完全self-contained 系统；在讨论用Kubernetes作为整体云平台解决方案的时候，我们着重看几点：

1.  一定要确保网络层面没有问题，不能出现时断时续的丢包，不稳定情况； 稳定性大大于灵活性和功能性要求；

2.  和现有的基于物理机的应用服务器网络要互通互联（Kube环境内Docker App和外面物理机的App需要相互调用）；

3.  容器网络和宿主机管理网络隔离；

4.  团队有较强的把控力和社区较为活跃；

5.  最大化利用已有的经验和解决方案的积累；

鉴于上面的几点要求，我们比较快的决定，采用ovs + contiv netmaster/netplugin的解决方案；较好的集成了原来 O penstack的网络解决方案(OVS)和DB Docker Swarm上面的解决方案(Contiv Netmaster/Netplugin)；在kubeproxy这边，我们一早就决定，抛弃kubeproxy（一个是基于对大规模部署的kubeproxy的iptables维护的担心，一个是物理机和Docker的互联需求），采用公司内部的统一LVS接入方案(我们的运维和DBA团队分别独立开发了LVS/Haproxy的管理系统)；

从物理机到 VM 或者到Docker，总体会造成VM/Docker数量比原来物理机多很多，一个会带来IP分配和交换机ARP表的压力，一个是过多APP Server对后端数据库/Cache的连接池的压力；各自有各自的解决方法；

Kubernetes 管理节点的可用性和扩展性

我们没有过多担心管理节点的扩展性，我们认为在可以预见的将来我们单集群不会出过1000个物理机，真有需求也可以通过多个kube cluster的方式来推进； 等我们需要担心管理节点的扩展性需求的时候，我们早已经积累了足够多的资源和经验，社区的进展应该也已经解决了这个问题了；

管理节点的可用性其实比较简单，类似 O penstack的haproxy配置多个节点可以解决足够多的性能和稳定性问题；etcd采用三个节点的ssd配置可以解决绝大部分的问题；

Side Project：Database on Docker Swarm的集群建设

http://blog.sina.com.cn/s/blog_53ca4b7d0102ywq8.html