本文讲的是DockOne微信分享（七十五）：应用容器化之Kubernetes实践【编者的话】本次分享主要以ZooKeeper、Redis、Kafka、MongoDB等应用容器化在Kubernetes平台上面实践。从计算、网络、存储方面解析应用在集成中的问题，以及部分传统应用在容器化过程中设计的应用二次开发等问题。首先介绍应用Docker化的需求和局限、接着介绍基础平台，整体环境包括Kubernetes和ECP，然后介绍具体应用如ZooKeeper在集成中的实践，最后介绍部分开源应用在容器化过程中设计到的二次开发。
容器是一种轻量级的虚拟化技术，拥有持续集成、版本控制、可移植性、隔离性和安全性等优点，越来越多的应用跑在容器里面。但也有其缺陷，并不是所有场景都适合如高性能计算，已经满负荷运行的应用没有必要虚拟化，一些对IO等运行环境要求比较高应用不适合容器化如Oracle数据库。
容器给应用程序提供了一个独立的运行环境，并不是像虚拟机那样提供一套完整的操作系统，这是容器和虚拟机最大的区别，所以在用户在使用虚拟化如KVM、Vmware时候很少会担心到应用能不能跑到虚拟机里面，通常只是针对虚拟化环境做性能调优，如KVM的CPU绑定、内存气球以及巨型页等。但应用Docker化更加复杂，除了解决虚拟机存在的计算、存储、网络以外问题，还需要解决Docker自身的问题，如：Docker相对与虚拟机的脆弱性、应用程序依赖的系统调用在Docker中没有做限制，还有Docker镜像制作以及应用Docker化之后日志和性能采集等问题。
Docker通过cgroup限制CPU和内存的使用，CPU限定通常是设置权重，并不能让一个容器获得确定1Ghz的CPU，当然你也可以使用cpuset绑定到指定的物理核上，内存使用中不仅要设置内存大小还要限定交换分区的大小，这点很重要，譬如MongoDB在内存不足时大量使用交换分区。
Docker相对短暂的生命周期决定了不会使用持久存储，容器挂了，存储的数据也会相应的丢失。如果数据需要持久化如MySQL的DBData数据，则需要把数据输出到外部的存储设备上，可以通过挂载NFS或者GlusterFS或者AWS存储等，在Kubernetes的PV的后端存储已经可以支持上述文件系统。用户也可以根据不同存储去实现Docker volume plugin，比较流行有Rancher/Convoy和Flocker，后者支持数据迁移，这为容器的迁移奠定了数据基础。
容器应用之间相互依赖：Web应用访问数据库，API接口调用等，所以网络必须能够互通并且支持多租户隔离，当前Docker网络有两大阵营，CNM和CNI。其中Calico可以算是脚踏两只船的，它可以与Kubernetes集成，相比Overlay网络在网络传输过程还是有明显优势的，如下图所示，减少了包封装提高了网络传输和包处理效率。
Docker OVS SDN的方式达到容器和容器以及容器和主机之间的网络互通也是非常好的设计思想，通过实现Docker的Network Drivers接口将容器挂到OVS上，通过ryu、Floodlight或者OpenDaylight等SDN控制器动态下发流表的达到网络互通；再结合iptables实现网络隔离。如果想实现大二层跨机房网络互通，可以集合Vxlan等Overlay技术。
天云skyform ECP平台是基于Kubernetes Calico的容器管理平台，具有日志采集分析、性能监控、镜像管理等一套完整的容器管理平台。上面介绍了Docker相关的一些相关知识，下面介绍具体的应用在Kubernetes平台上的集成。我把应用集成难度分三个等级：最容易是应用本身具有服务发现机制如Dubbo，天然的支持自动扩缩容，那么在Kubernetes集成将会变的非常简单；大部分应用属于需要修改配置就能在容器里面运行，最困难的是需要对应用进行二次开发或者对平台二次开发的应用。
ZooKeeper
ZooKeeper是一个高性能、高可用的分布式协调服务。整个ZooKeeper集群的对外提供2181服务端口，节点之间数据同步和选主分别使用的2888和3888端口。每一个ZooKeeper节点都需要个其他节点通信，所以都需要一个固定的IP地址，通过Kubernetes服务提供的虚IP（如果使用集群内已经部署DNS则配置域名即可）互相通信，结构如下图所示：
Yaml文件如下
存储使用nfs共享存储，这样ZooKeeper容器重建后就能恢复数据。
Kafka
Kafka是由LinkedIn开发的一个分布式的消息系统，使用Scala编写，它以可水平扩展和高吞吐率而被广泛使用。目前越来越多的开源分布式处理系统如Cloudera、Apache Storm、Spark都支持与Kafka集成。整个结构图如下所示：
Yaml文件如下，这里面有三个地方需要注意：
- 每一个Kafka的broker都有一个集群内唯一的broker_id，所以不能把整个Kafka集群放到一个RC里面，而必须通过不同RC去分别定义每一个broker；
- Kafka依赖ZooKeeper，在这里我们通过环境变量的方式将域名传递到容器内；
- 这里没有配置Kafka的持久化存储，因为每个Topic包含一个或多个partition，如果单个broker宕调不会影响集群，并且当broker重建后会自动同步数据，速度非常快。
Redis
Redis是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。Redis容器测试过程中，有几点性能问题需要注意，第一是Redis最大内存，如果不设置可能会出现将内存耗尽的现象，第二是数据ttl时间设定以及清理keys策略，这些都是为了避免内存不足时使用交换分区导致性能下降，第三是数据持久化使用RBD，相对于较大文件aof持久化，RBD更适合快照恢复。如果是业务量不大的场景可以使用redis主从结构，如下图所示：
Resis Master的Yaml文件如下，其中为了数据的迁移恢复和重建使用Glusterfs存储，当然你也可以换成其他存储，单个主从集群可能无法承载过多的请求，可以通过当前比较成熟的一个方案Twemproxy，通过代理实现数据分片，也能达到一个不错的效果：
当前我们正在测试的是Redis 3.x的集群功能，每一个Redis都是一个service（slave默认不接受读写，需要执行readonly才能读），省去proxy代理提高效率。这个集群方案通过redis-trib.rb的create子命令构建， 在客户端配置所有service地址就可以操作集群里面的数据，但整个操作过程有两个地方必须通过手工完成，尚待完善：
- 整个集群创建redis-trib.rb是通过手动完成，没有服务发现和自动化；
- 增加加点必须手动执行redis-trib.rb reshard分配slot。
MongoDB
MongoDB是由C 语言编写的，是一个基于分布式文件存储的开源数据库系统。MongoDB已经不推荐使用主从，集群可以选择副本集或者分片。下图展示的每一个MongoDB对外是一个service，组成副本集的集群，类似mongodb这种对磁盘IO要求比较高的可以使用SSD加速，通过标签选择创建到有SSD机器上面提高性能。
如果是MongoDB的分片集群，结构如下所示：
每一个configsvr配置服务和Mongos路由服务都是通过service提供固定的访问接口。mongos通过configsvr域名配置。通过服务发现的脚本动态配置将副本集转成分片，这个分片的功能测试已经通过，但性能测试还在进行中。
上面一些应用都是通过容器外部传递配置参数或者启动脚本修改应用的配置，但有的应用通过这种方式是无法完成的，必须通过对应用或者对平台的改造才能完成，譬如IBM的任务调度平台OpenLava，它通过/proc/meminfo和/proc/cpuinfo获取内存和CPU，Docker这部分通过是挂载的主机proc文件系统，导致应用在容器内读取是主机的CPU和内存，此时通过修改OpenLava代码使其从/sys/fs/cgroup/cpu/cpu.shares 获取CPU核数从/sys/fs/cgroup/memory/memory.limit_in_byte获取内存值，有的应用（多个pod）之间需要共享IPC，这部分功能Kubernetes是没有的，需要通过平台改造去达到应用需求，还有应用需要根据IO去调度，这些都是我们ECP平台基于Kubernetes添加的功能。
Q&A
Q：请问在Kubernetes架构下 搭建分布式服务框架如Dubbo 需要将主机地址和暴露端口注册到ZooKeeper上，这个主机地址和暴露的端口你们是怎么处理的，即容器内的应用如何获取Docker宿主机地址？
A：Dubbo服务不需要暴露主机的IP和地址，只需要知道容器地址即可。这些服务都是注册到ZooKeeper上面，通过ZooKeeper完成服务发现，Kubernetes能够根据暴露端口进行调度,当然有些应用要求容器能获取到宿主机的IP地址，这块我们对Kubernetes做了一些修改，可以动态注入诸如宿主机IP，宿主机主机名信息到容器的环境变量中。
Q：ECP的定位和解决目标相比较目前大家在用传统的云平台解决方案来讲下？
A：ECP产品定位是一套完整的容器解决方案，从容器生命周期管理，资源监控到日志分析处理，相比与云平台解决方案管理的对象不再是虚拟机，而是容器，面向的对象是服务。
Q：关于容器本身的资源性能监控，是用的cAdvisor+Heapster吗，如何能保持pod重启（重启后pod名称变化）后的数据连续性，谢谢。
A：资源监控用的不是Heapster，ECP的资源监控是用cAdvisor+我们自己研发的采集Agent+Ceilometer+MongoDB+HBase等技术。复用了我们在做CMP产品时的技术，rc中的pod重建后会重命名，这块对于单一pod数据的连续性还没有考虑，我们是把rc当做一个整体考虑的 。
Q：你们对外服务的负载均衡如何做的？是直接用Kubernetes的service吗？
A：对外负载均衡现阶段用的是Kubernetes的service，考虑到iptables带来的性能损耗，后续我们会考虑使用别的方案，在集群内部直接把流量转发到对于的pod上。
Q：请问Kubernetes容器和在其中运行的应用程序监控是如何做的？能介绍下吗？谢谢！
A：ECP的资源监控是用cAdvisor+我们自己研发的采集Agent+Ceilometer+MongoDB+HBase等技术。复用了我们在做CMP产品时的技术。简单来说就是用cAdvisor采集原始数据，然后通过Ceilometer持久化，提供实时数据查询、告警等功能。数据会定期转存到hbase做历史数据分析。
Q：请问，有基于Kubernetes的多租户和用户配额开源实现嘛？
A:现在开源的方案比较少，我们的ECP产品是结合Keystone实现的多租户管理以及租户的配额管理。
以上内容根据2016年8月9日晚微信群分享内容整理。分享人陈晓宇，北京天云融创软件技术有限公司，研发工程师，多年云计算以及分布式系统开发经验，对CloudStack、OpenStack等云管理系统有深入了解。长期致力于应用Docker化、Docker集群化方案的设计与研发。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesz，进群参与，您有想听的话题或者想分享的话题都可以给我们留言。
原文发布时间为：2016-08-11
本文作者：陈晓宇
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：DockOne微信分享（七十五）：应用容器化之Kubernetes实践
