我正在参与「启航计划」
写在前面
一般来说,REDIS布置有三种形式。
- 单实例形式,一般用于测试环境。
- 岗兵形式
- 集群形式
后两者用于生产布置
岗兵形式
在redis3.0曾经,要完成集群一般是凭借岗兵sentinel工具来监控master节点的状况。
如果master节点反常,则会做主从切换,将某一台slave作为master。
引入了岗兵节点,布置更杂乱,保护本钱也比较高,而且功能和高可用性等各方面体现一般。
集群形式
3.0 后推出的 Redis 分布式集群解决方案
主节点供给读写操作,从节点作为备用节点,不供给恳求,只作为故障转移运用
如果master节点反常,也是会自动做主从切换,将slave切换为master。
总的来说,集群形式
显着优于岗兵形式
那么今日咱们就来讲解下:k8s环境下,如何布置redis集群(三主三从)?
前置预备
一、nfs装置
- nfs
# 服务端
# 1.装置
yum -y install nfs-utils # nfs文件系统
yum -y install rpcbind # rpc协议
# 2.装备(需求同享的文件夹)
vi /etc/exports
/opt/nfs/pv1 *(rw,sync,no_subtree_check,no_root_squash)
/opt/nfs/pv2 *(rw,sync,no_subtree_check,no_root_squash)
/opt/nfs/pv3 *(rw,sync,no_subtree_check,no_root_squash)
/opt/nfs/pv4 *(rw,sync,no_subtree_check,no_root_squash)
/opt/nfs/pv5 *(rw,sync,no_subtree_check,no_root_squash)
/opt/nfs/pv6 *(rw,sync,no_subtree_check,no_root_squash)
# 3.创立文件夹
mkdir -p /opt/nfs/pv{1..6}
# 4.更新装备并重启nfs服务
exportfs -r #更新装备
systemctl restart rpcbind
systemctl restart nfs
systemctl enable nfs #开机发动
systemctl enable rpcbind
# 5.验证
showmount -e 192.168.4.xx #服务端验证NFS同享
> Export list for 192.168.4.xx:
/opt/nfs/pv6 *
/opt/nfs/pv5 *
/opt/nfs/pv4 *
/opt/nfs/pv3 *
/opt/nfs/pv2 *
/opt/nfs/pv1 *
rpcinfo -p #检查端口
# 客户端
yum -y install nfs-utils
systemctl restart nfs
systemctl enable nfs #开机发动
这儿说一下,为什么要装置nfs?
是为了下面创立SC,PV做预备,PV需求运用nfs服务器。
二、SC、PV 创立
2.1创立SC
StorageClass:简称sc,存储类,是k8s平台为存储供给商供给存储接入的一种声明。经过sc和相应的存储插件(csi)为容器运用供给耐久存储卷的能力。
vi redis-sc.yaml
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: redis-sc
provisioner: nfs-storage
称号为
redis-sc
履行创立sc:
kubectl apply -f redis-sc.yaml
> storageclass.storage.k8s.io/redis-sc created
经过kuboard检查:
2.2创立PV
PersistentVolume简称pv,耐久化存储,是k8s为云原生运用供给一种具有独立生命周期的、用户可办理的存储的抽象设计。
vi redis-pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv1
spec:
storageClassName: redis-sc
capacity:
storage: 200M
accessModes:
- ReadWriteMany
nfs:
server: 192.168.4.xx
path: "/opt/nfs/pv1"
称号为
nfs-pv1
,对应的storageClassName为redis-sc
,capacity容器200M,accessModes拜访形式可被多节点读写对应nfs服务器
192.168.4.xx
,对应文件夹路径/opt/nfs/pv1
(对应上面装置nfs服务器)以此类推,咱们创立6个pv……
履行创立sc:
kubectl apply -f redis-pv.yaml
> persistentvolume/nfs-pv1 created
persistentvolume/nfs-pv2 created
persistentvolume/nfs-pv3 created
persistentvolume/nfs-pv4 created
persistentvolume/nfs-pv5 created
persistentvolume/nfs-pv6 created
经过kuboard检查:
经过kubectl检查:kubectl get sc
、kubectl get pv
这儿说一下,为什么要创立SC,PV?
由于redis集群,终究需求对应的文件有,redis.conf
、nodes.conf
、data
由此可见,这些文件每个节点,都得对应有自己得文件夹。
当然redis.conf
可所以一个相同得,其他两个,就肯定是不一样得。
如果运用挂载文件夹便是 Volume
的状况布置一个pod,很显着,是不能满足的。
当然,你布置多个不一样的pod,也是能够做到,但是就得写6个布置yaml文件,后期保护也很杂乱。
最好的作用是,写一个布置yaml文件,然后有6个replicas副本,就对应了咱们redis集群(三主三从)。
那一个pod,再运用Volume
挂载文件夹,这个只能是一个文件夹,是无法做到6个pod对应不同的文件夹。
所以这儿,就引出了SC
、PV
了。
运用SC
、PV
就能够完成,这6个pod发动,就对应上咱们创立的6个PV
,那就完成了redis.conf
、nodes.conf
、data
,这三个文件,寄存的路径,便是不一样的路径了。
哈哈,说了,那么多,不知道,咱们明不了解,不了解的能够持续往下看,或者自己布置实操一下,估量你就能了解,为啥要这么干了?
三、redis集群搭建
RC、Deployment、DaemonSet都是面向无状况的服务,它们所办理的Pod的IP、名字,启停顺序等都是随机的,而StatefulSet是什么?顾名思义,有状况的调集,办理一切有状况的服务,比如MySQL、MongoDB集群等。
StatefulSet本质上是Deployment的一种变体,在v1.9版别中已成为GA版别,它为了解决有状况服务的问题,它所办理的Pod具有固定的Pod称号
,启停顺序
,在StatefulSet中,Pod名字称为网络标识
(hostname),还必须要用到同享存储。
在Deployment中,与之对应的服务是service,而在StatefulSet中与之对应的headless service,headless service,即无头服务,与service的差异便是它没有Cluster IP,解析它的称号时将回来该Headless Service对应的悉数Pod的Endpoint列表。
除此之外,StatefulSet在Headless Service的根底上又为StatefulSet控制的每个Pod副本创立了一个DNS域名,这个域名的格局为:
$(pod.name).$(headless server.name).${namespace}.svc.cluster.local
也便是说,关于有状况服务,咱们最好运用固定的网络标识(如域名信息)来符号节点,当然这也需求运用程序的支撑(如Zookeeper就支撑在装备文件中写入主机域名)。
StatefulSet根据Headless Service(即没有Cluster IP的Service)为Pod完成了安稳的网络标志(包括Pod的hostname和DNS Records),在Pod从头调度后也保持不变。一起,结合PV/PVC,StatefulSet能够完成安稳的耐久化存储,就算Pod从头调度后,仍是能拜访到原先的耐久化数据。
以下为运用StatefulSet布置Redis的架构,无论是Master仍是Slave,都作为StatefulSet的一个副本,而且数据经过PV进行耐久化,对外露出为一个Service,承受客户端恳求。
3.1创立headless服务
Headless service是StatefulSet完成安稳网络标识的根底。
vi redis-hs.yaml
---
apiVersion: v1
kind: Service
metadata:
labels:
k8s.kuboard.cn/layer: db
k8s.kuboard.cn/name: redis
name: redis-hs
namespace: jxbp
spec:
ports:
- name: nnbary
port: 6379
protocol: TCP
targetPort: 6379
selector:
k8s.kuboard.cn/layer: db
k8s.kuboard.cn/name: redis
clusterIP: None
命名空间为:
jxbp
,称号为:redis-hs
履行:
kubectl apply -f redis-hs.yaml
> service/redis-hs created
网络拜访:pod称号.headless称号.namespace称号.svc.cluster.local
即:pod称号.redis-hs.jxbp.svc.cluster.local
3.2创立redis对应pod集群
创立好Headless service后,就能够使用StatefulSet创立Redis 集群节点,这也是本文的核心内容。
vi redis.yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: redis
namespace: jxbp
labels:
k8s.kuboard.cn/layer: db
k8s.kuboard.cn/name: redis
spec:
replicas: 6
selector:
matchLabels:
k8s.kuboard.cn/layer: db
k8s.kuboard.cn/name: redis
serviceName: redis
template:
metadata:
labels:
k8s.kuboard.cn/layer: db
k8s.kuboard.cn/name: redis
spec:
terminationGracePeriodSeconds: 20
containers:
- name: redis
image: 192.168.4.xx/jxbp/redis:6.2.6
ports:
- name: redis
containerPort: 6379
protocol: "TCP"
- name: cluster
containerPort: 16379
protocol: "TCP"
volumeMounts:
- name: "redis-conf"
mountPath: "/etc/redis/redis.conf"
- name: "redis-data"
mountPath: "/data"
volumes:
- name: "redis-conf"
hostPath:
path: "/opt/redis/conf/redis.conf"
type: FileOrCreate
volumeClaimTemplates:
- metadata:
name: redis-data
spec:
accessModes: [ "ReadWriteMany" ]
resources:
requests:
storage: 200M
storageClassName: redis-sc
称号为:
redis
,对应的镜像为:redis:6.2.6
,挂载的文件:宿主机的
/opt/redis/conf/redis.conf
到redis容器的/etc/redis/redis.conf
(redis.conf装备文件如下所示)PVC存储卷声明模板
volumeClaimTemplates
,指定了称号为redis-sc
的SC(storageClassName)由于之前SC绑定了PV,所以这儿的PVC和PV,就能一 一对应绑定上了。
PV和PVC的联系,是一 一绑定的。如果这儿不指定SC,那就会导致,PVC绑定PV,是一个混乱的进程,随机绑定PV了。
- redis.conf
# 一般装备
bind 0.0.0.0
port 6379
daemonize no
requirepass jxbd
# 集群装备
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
履行:
kubectl apply -f redis.yaml
由上操作,咱们现已创立好redis的6个副本了。
由于k8s布置redis集群的篇幅,有点长,剩余的内容,就留着下次共享了。
好了,以上便是我个人的实操了。
个人了解,可能也不行全面,班门弄斧了。
好了,今日就先到这儿了!!!^_^
如果觉得有收成的,帮忙点赞、谈论、收藏
一下呗!!!