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

最新推荐文章于 2025-11-03 10:55:43 发布

原创最新推荐文章于 2025-11-03 10:55:43 发布 · 1.5k 阅读

1 ·

CC 4.0 BY-SA版权

文章标签：

#redis #集群 #zookeeper #mongodb #rabbitmq

Kubernetes 专栏收录该内容

19 篇文章

订阅专栏

该博客详细介绍了如何在 Kubernetes 1.6 版本中部署 Redis 3.2、MongoDB 3.4、ZooKeeper 3.4.10 和 RabbitMQ 3.6.6 集群。文中还包含了对各个组件的持久化测试以及最终的总结分析。

mongo 3.4

k8s-mongo-ha，建议使用第二种方法
1、https://github.com/tarosky/k8s-mongo-ha
   rs.status()查看集群状态
   db.getMongo().setSlaveOk()设置从节点允许读
   需要持久化的目录/data
2、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、Deployment
https://github.com/binarin/rabbit-on-k8s-standalone
2、statefulset 
https://github.com/tianctrl/rabbitmq-cluster-helm

RabbitMQ是用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和manual
priority：可选参数，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 – 卷自动回收失败

总结

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