kubernetes1.6中redis-mong-zookeepe-rabbitmq集群部署

mongo 3.4

k8s-mongo-ha，建议使用第二种方法1、https://github.com/tarosky/k8s-mongo-ha   rs.status()查看集群状态   db.getMongo().setSlaveOk()设置从节点允许读   需要持久化的目录/data2、https://github.com/cvallance/mongo-k8s-sidecar   这种方法也比较好。9.18更新

redis 3.2

https://github.com/tarosky/k8s-redis-ha需要持久化目录/data，/opt

zookeeper 3.4.10

https://github.com/engapa/zookeeper-k8s-openshift持久化数据路径，详细步骤不再解释/opt/zookeeper/data/opt/zookeeper/data-log

rabbitmq 3.6.6

使用过两种安装方式1、Deploymenthttps://github.com/binarin/rabbit-on-k8s-standalone2、statefulset https://github.com/tianctrl/rabbitmq-cluster-helmRabbitMQ是用erlang开发的，集群非常方便，因为erlang天生就是一门分布式语言,但其本身并不支持负载均衡。Rabbit模式大概分为以下三种：单一模式、普通模式、镜像模式普通模式：默认的集群模式。对于Queue来说，消息实体只存在于其中一个节点，A、B两个节点仅有相同的元数据，即队列结构。当消息进入A节点的Queue中后，consumer从B节点拉取时，RabbitMQ会临时在A、B间进行消息传输，把A中的消息实体取出并经过B发送给consumer。所以consumer应尽量连接每一个节点，从中取消息。即对于同一个逻辑队列，要在多个节点建立物理Queue。否则无论consumer连A或B，出口总在A，会产生瓶颈。该模式存在一个问题就是当A节点故障后，B节点无法取到A节点中还未消费的消息实体。如果做了消息持久化，那么得等A节点恢复，然后才可被消费；如果没有持久化的话，然后就没有然后了……镜像模式：把需要的队列做成镜像队列，存在于多个节点，属于RabbitMQ的HA方案。该模式解决了上述问题，其实质和普通模式不同之处在于，消息实体会主动在镜像节点间同步，而不是在consumer取数据时临时拉取。该模式带来的副作用也很明显，除了降低系统性能外，如果镜像队列数量过多，加之大量的消息进入，集群内部的网络带宽将会被这种同步通讯大大消耗掉。所以在对可靠性要求较高的场合中适用镜像模式可以通过命令或控制台来创建策略# rabbitmqctl set_policy -p hrsystem ha-allqueue"^" '{"ha-mode":"all"}'这行命令在vhost名称为hrsystem创建了一个策略，策略名称为ha-allqueue,策略模式为 all 即复制到所有节点，包含新增节点，策略正则表达式为 “^” 表示所有匹配所有队列名称。控制台中添加Admin--Policy中添加RabbitMQ对于queue中的message的保存方式有两种方式：disc和ram。如果采用disc，则需要对exchange／queue／delivery mode都要设置成durable模式。Disc方式的好处是当RabbitMQ失效了，message仍然可以在重启之后恢复。而使用ram方式，RabbitMQ处理message的效率要高很多，ram和disc两种方式的效率比大概是3:1。所以如果在有其它HA手段保障的情况下，选用ram方式是可以提高消息队列的工作效率的。-p Vhost： 可选参数，针对指定vhost下的queue进行设置Name: policy的名称Pattern: queue的匹配模式(正则表达式)Definition：镜像定义，包括三个部分ha-mode, ha-params, ha-sync-mode    ha-mode:指明镜像队列的模式，有效值为 all/exactly/nodes        all：表示在集群中所有的节点上进行镜像        exactly：表示在指定个数的节点上进行镜像，节点的个数由ha-params指定        nodes：表示在指定的节点上进行镜像，节点名称通过ha-params指定    ha-params：ha-mode模式需要用到的参数    ha-sync-mode：进行队列中消息的同步方式，有效值为automatic和manualpriority：可选参数，policy的优先级相关变量RABBITMQ_LOG_BASE=/data/rabbitmq/log 日志目录RABBITMQ_PLUGINS_DIR=/data/rabbitmq/plugins 插件目录RABBITMQ_MNESIA_BASE=/data/rabbitmq/mnesia RABBITMQ_MNESIA_DIR创建策略  镜像模式命令：rabbitmqctl set_policy ha-all "^" '{'ha-mode":"all"}' 1、ha-all 是同步模式，指同步给所有节点，还有另外两种模式ha-exactly表示在指定个数的节点上进行镜像，节点的个数由ha-params指定，ha-nodes表示在指定的节点上进行镜像，节点名称通过ha-params指定；2、^是匹配所有节点。3、{“ha-mode”:”all”} 表示同步给所有，同步模式的不同，此参数也不同。

持久化测试

 使用动态pvc持久化数据，支持cephrbd，目前不支持cephfs 测试使用主机持久化，在创建statefulset的yaml文件中添加，持久化到主机上。根据创建statefulset而创建pv和pvc      volumeClaimTemplates:      - metadata:          name: datadir          annotations:            volume.alpha.kubernetes.io/storage-class: anything        spec:          accessModes: [ "ReadWriteOnce" ]          resources:            requests:              storage: 1Gi       - metadata:          name: datalogdir          annotations:            volume.alpha.kubernetes.io/storage-class: anything        spec:          accessModes: [ "ReadWriteOnce" ]          resources:            requests:              storage: 1Gi     如果出现错误：cannot find volume plugin for alpha provisioning    在文件中添加参数：/etc/kubernetes/manifests/kube-controller-manager.json     参数: --enable-hostpath-provisioner=true  statefulset： 　　　● 稳定的、唯一的网络标识。  　　　● 稳定的、持久化的存储。  　　　● 有序的、优雅的部署和扩展。  　　　● 有序的、优雅的删除和停止。  PV卷阶段状态： Available – 资源尚未被claim使用 Bound – 卷已经被绑定到claim了 Released – claim被删除，卷处于释放状态，但未被集群回收。 Failed – 卷自动回收失败

总结

总体部署比较简单，可能会遇到的问题就是权限问题了，出了问题看日志，解决起来比较简单。后边做测试补充