寫在前面

一般來(lái)說，REDIS部署有三種模式。

• 單實(shí)例模式，一般用于測(cè)試環(huán)境。
• 哨兵模式
• 集群模式

后兩者用于生產(chǎn)部署

• 哨兵模式

在redis3.0以前，要實(shí)現(xiàn)集群一般是借助哨兵sentinel工具來(lái)監(jiān)控master節(jié)點(diǎn)的狀態(tài)。

如果master節(jié)點(diǎn)異常，則會(huì)做主從切換，將某一臺(tái)slave作為master。

引入了哨兵節(jié)點(diǎn)，部署更復(fù)雜，維護(hù)成本也比較高，并且性能和高可用性等各方面表現(xiàn)一般。

• 集群模式

3.0 后推出的 Redis 分布式集群解決方案

主節(jié)點(diǎn)提供讀寫操作，從節(jié)點(diǎn)作為備用節(jié)點(diǎn)，不提供請(qǐng)求，只作為故障轉(zhuǎn)移使用

如果master節(jié)點(diǎn)異常，也是會(huì)自動(dòng)做主從切換，將slave切換為master。

總的來(lái)說，集群模式明顯優(yōu)于哨兵模式

那么今天我們就來(lái)講解下：k8s環(huán)境下，如何部署redis集群（三主三從）？

前置準(zhǔn)備

一、nfs安裝

• nfs

# 服務(wù)端
# 1.安裝
yum -y install nfs-utils # nfs文件系統(tǒng)
yum -y install rpcbind   # rpc協(xié)議
# 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.創(chuàng)建文件夾
mkdir -p /opt/nfs/pv{1..6}
# 4.更新配置并重啟nfs服務(wù)
exportfs -r  #更新配置
systemctl restart rpcbind
systemctl restart nfs
systemctl enable nfs  #開機(jī)啟動(dòng)
systemctl enable rpcbind
# 5.驗(yàn)證
showmount -e 192.168.4.xx #服務(wù)端驗(yàn)證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  #開機(jī)啟動(dòng)

這里說一下，為什么要安裝nfs？

是為了下面創(chuàng)建SC，PV做準(zhǔn)備，PV需要使用nfs服務(wù)器。

二、SC、PV 創(chuàng)建

2.1創(chuàng)建SC

StorageClass：簡(jiǎn)稱sc，存儲(chǔ)類，是k8s平臺(tái)為存儲(chǔ)提供商提供存儲(chǔ)接入的一種聲明。通過sc和相應(yīng)的存儲(chǔ)插件(csi)為容器應(yīng)用提供持久存儲(chǔ)卷的能力。

vi redis-sc.yaml

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: redis-sc
provisioner: nfs-storage

名稱為redis-sc

執(zhí)行創(chuàng)建sc：

kubectl apply -f redis-sc.yaml
> storageclass.storage.k8s.io/redis-sc created

通過kuboard查看：

2.2創(chuàng)建PV

PersistentVolume簡(jiǎn)稱pv，持久化存儲(chǔ)，是k8s為云原生應(yīng)用提供一種擁有獨(dú)立生命周期的、用戶可管理的存儲(chǔ)的抽象設(shè)計(jì)。

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，對(duì)應(yīng)的storageClassName為redis-sc，capacity容器200M，accessModes訪問模式可被多節(jié)點(diǎn)讀寫

對(duì)應(yīng)nfs服務(wù)器192.168.4.xx，對(duì)應(yīng)文件夾路徑/opt/nfs/pv1（對(duì)應(yīng)上面安裝nfs服務(wù)器）

以此類推，我們創(chuàng)建6個(gè)pv......

執(zhí)行創(chuàng)建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

這里說一下，為什么要?jiǎng)?chuàng)建SC，PV？

因?yàn)閞edis集群，最終需要對(duì)應(yīng)的文件有，redis.conf、nodes.conf、data

由此可見，這些文件每個(gè)節(jié)點(diǎn)，都得對(duì)應(yīng)有自己得文件夾。

當(dāng)然redis.conf可以是一個(gè)相同得，其他兩個(gè)，就肯定是不一樣得。

如果使用掛載文件夾即是 Volume 的情況部署一個(gè)pod，很明顯，是不能滿足的。

當(dāng)然，你部署多個(gè)不一樣的pod，也是可以做到，但是就得寫6個(gè)部署yaml文件，后期維護(hù)也很復(fù)雜。

最好的效果是，寫一個(gè)部署yaml文件，然后有6個(gè)replicas副本，就對(duì)應(yīng)了我們r(jià)edis集群（三主三從）。

那一個(gè)pod，再使用Volume掛載文件夾，這個(gè)只能是一個(gè)文件夾，是無(wú)法做到6個(gè)pod對(duì)應(yīng)不同的文件夾。

所以這里，就引出了SC、PV了。

使用SC、PV就可以實(shí)現(xiàn)，這6個(gè)pod啟動(dòng)，就對(duì)應(yīng)上我們創(chuàng)建的6個(gè)PV，那就實(shí)現(xiàn)了redis.conf、nodes.conf、data，這三個(gè)文件，存放的路徑，就是不一樣的路徑了。

哈哈，說了，那么多，不知道，大家明不明白，不明白的可以繼續(xù)往下看，或者自己部署實(shí)操一下，估計(jì)你就能明白，為啥要這么干了？

三、redis集群搭建

RC、Deployment、DaemonSet都是面向無(wú)狀態(tài)的服務(wù)，它們所管理的Pod的IP、名字，啟停順序等都是隨機(jī)的，而StatefulSet是什么？顧名思義，有狀態(tài)的集合，管理所有有狀態(tài)的服務(wù)，比如MySQL、MongoDB集群等。

StatefulSet本質(zhì)上是Deployment的一種變體，在v1.9版本中已成為GA版本，它為了解決有狀態(tài)服務(wù)的問題，它所管理的Pod擁有固定的Pod名稱，啟停順序，在StatefulSet中，Pod名字稱為網(wǎng)絡(luò)標(biāo)識(shí)(hostname)，還必須要用到共享存儲(chǔ)。

在Deployment中，與之對(duì)應(yīng)的服務(wù)是service，而在StatefulSet中與之對(duì)應(yīng)的headless service，headless service，即無(wú)頭服務(wù)，與service的區(qū)別就是它沒有Cluster IP，解析它的名稱時(shí)將返回該Headless Service對(duì)應(yīng)的全部Pod的Endpoint列表。

除此之外，StatefulSet在Headless Service的基礎(chǔ)上又為StatefulSet控制的每個(gè)Pod副本創(chuàng)建了一個(gè)DNS域名，這個(gè)域名的格式為：

$(pod.name).$(headless server.name).${namespace}.svc.cluster.local

也即是說，對(duì)于有狀態(tài)服務(wù)，我們最好使用固定的網(wǎng)絡(luò)標(biāo)識(shí)（如域名信息）來(lái)標(biāo)記節(jié)點(diǎn)，當(dāng)然這也需要應(yīng)用程序的支持（如Zookeeper就支持在配置文件中寫入主機(jī)域名）。

StatefulSet基于Headless Service（即沒有Cluster IP的Service）為Pod實(shí)現(xiàn)了穩(wěn)定的網(wǎng)絡(luò)標(biāo)志（包括Pod的hostname和DNS Records），在Pod重新調(diào)度后也保持不變。同時(shí)，結(jié)合PV/PVC，StatefulSet可以實(shí)現(xiàn)穩(wěn)定的持久化存儲(chǔ)，就算Pod重新調(diào)度后，還是能訪問到原先的持久化數(shù)據(jù)。

以下為使用StatefulSet部署Redis的架構(gòu)，無(wú)論是Master還是Slave，都作為StatefulSet的一個(gè)副本，并且數(shù)據(jù)通過PV進(jìn)行持久化，對(duì)外暴露為一個(gè)Service，接受客戶端請(qǐng)求。

3.1創(chuàng)建headless服務(wù)

Headless service是StatefulSet實(shí)現(xiàn)穩(wěn)定網(wǎng)絡(luò)標(biāo)識(shí)的基礎(chǔ)。

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

執(zhí)行：

kubectl apply -f redis-hs.yaml
> service/redis-hs created

網(wǎng)絡(luò)訪問：pod名稱.headless名稱.namespace名稱.svc.cluster.local

即：pod名稱.redis-hs.jxbp.svc.cluster.local

3.2創(chuàng)建redis對(duì)應(yīng)pod集群

創(chuàng)建好Headless service后，就可以利用StatefulSet創(chuàng)建Redis 集群節(jié)點(diǎn)，這也是本文的核心內(nèi)容。

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，對(duì)應(yīng)的鏡像為：redis:6.2.6，

掛載的文件：宿主機(jī)的/opt/redis/conf/redis.conf到redis容器的/etc/redis/redis.conf（redis.conf配置文件如下所示）

PVC存儲(chǔ)卷聲明模板volumeClaimTemplates，指定了名稱為redis-sc的SC（storageClassName）

由于之前SC綁定了PV，所以這里的PVC和PV，就能一 一對(duì)應(yīng)綁定上了。

PV和PVC的關(guān)系，是一 一綁定的。如果這里不指定SC，那就會(huì)導(dǎo)致，PVC綁定PV，是一個(gè)混亂的過程，隨機(jī)綁定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

執(zhí)行：

kubectl apply -f redis.yaml

由上操作，我們已經(jīng)創(chuàng)建好redis的6個(gè)副本了。

因?yàn)閗8s部署redis集群的篇幅，有點(diǎn)長(zhǎng)

以上就是k8s部署redis集群實(shí)現(xiàn)過程實(shí)例詳解的詳細(xì)內(nèi)容，更多關(guān)于k8s部署redis集群的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！

最新評(píng)論