一、前言

架構原理：每個master都可以擁有多個slave。當master下線后，redis集群會從多個slave中選舉出一個新的master作為替代，而舊master重新上線后變成新master的slave。

二、準備操作

本次部署主要基于該項目：https://github.com/zuxqoj/kubernetes-redis-cluster

其包含了兩種部署redis集群的方式：

• statefulset
• service&deployment

兩種方式各有優劣，對于像redis、mongodb、zookeeper等有狀態的服務，使用statefulset是首選方式。本文將主要介紹如何使用statefulset進行redis集群的部署。

三、statefulset簡介

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域名，這個域名的格式為：

也即是說，對于有狀態服務，我們最好使用固定的網絡標識（如域名信息）來標記節點，當然這也需要應用程序的支持（如zookeeper就支持在配置文件中寫入主機域名）。
statefulset基于headless service（即沒有cluster ip的service）為pod實現了穩定的網絡標志（包括pod的hostname和dns records），在pod重新調度后也保持不變。同時，結合pv/pvc，statefulset可以實現穩定的持久化存儲，就算pod重新調度后，還是能訪問到原先的持久化數據。
以下為使用statefulset部署redis的架構，無論是master還是slave，都作為statefulset的一個副本，并且數據通過pv進行持久化，對外暴露為一個service，接受客戶端請求。

四、部署過程

本文參考項目的readme中，簡要介紹了基于statefulset的redis創建步驟：

1.創建nfs存儲
2.創建pv
3.創建pvc
4.創建configmap
5.創建headless服務
6.創建redis statefulset
7.初始化redis集群

這里，我將參考如上步驟，實踐操作并詳細介紹redis集群的部署過程。文中會涉及到很多k8s的概念，希望大家能提前了解學習

1.創建nfs存儲

創建nfs存儲主要是為了給redis提供穩定的后端存儲，當redis的pod重啟或遷移后，依然能獲得原先的數據。這里，我們先要創建nfs，然后通過使用pv為redis掛載一個遠程的nfs路徑。

安裝nfs

然后，新增/etc/exports文件，用于設置需要共享的路徑：

創建相應目錄

接著，啟動nfs和rpcbind服務：

客戶端

查看存儲端共享

創建pv
每一個redis pod都需要一個獨立的pv來存儲自己的數據，因此可以創建一個pv.yaml文件，包含6個pv：

如上，可以看到所有pv除了名稱和掛載的路徑外都基本一致。執行創建即可：

2.創建configmap

這里，我們可以直接將redis的配置文件轉化為configmap，這是一種更方便的配置讀取方式。配置文件redis.conf如下

創建名為redis-conf的configmap：

查看創建的configmap:

如上，redis.conf中的所有配置項都保存到redis-conf這個configmap中。

3.創建headless service

headless service是statefulset實現穩定網絡標識的基礎，我們需要提前創建。準備文件headless-service.yml如下：

創建：

查看：

可以看到，服務名稱為redis-service，其cluster-ip為none，表示這是一個“無頭”服務。

4.創建redis 集群節點

創建好headless service后，就可以利用statefulset創建redis 集群節點，這也是本文的核心內容。我們先創建redis.yml文件：

如上，總共創建了6個redis節點(pod)，其中3個將用于master，另外3個分別作為master的slave；redis的配置通過volume將之前生成的redis-conf這個configmap，掛載到了容器的/etc/redis/redis.conf；redis的數據存儲路徑使用volumeclaimtemplates聲明（也就是pvc），其會綁定到我們先前創建的pv上。

這里有一個關鍵概念——affinity，請參考官方文檔詳細了解。其中，podantiaffinity表示反親和性，其決定了某個pod不可以和哪些pod部署在同一拓撲域，可以用于將一個服務的pod分散在不同的主機或者拓撲域中，提高服務本身的穩定性。
而preferredduringschedulingignoredduringexecution 則表示，在調度期間盡量滿足親和性或者反親和性規則，如果不能滿足規則，pod也有可能被調度到對應的主機上。在之后的運行過程中，系統不會再檢查這些規則是否滿足。

在這里，matchexpressions規定了redis pod要盡量不要調度到包含app為redis的node上，也即是說已經存在redis的node上盡量不要再分配redis pod了。但是，由于我們只有三個node，而副本有6個，因此根據

preferredduringschedulingignoredduringexecution，這些豌豆不得不得擠一擠，擠擠更健康~

另外，根據statefulset的規則，我們生成的redis的6個pod的hostname會被依次命名為 $(statefulset名稱)-$(序號) 如下圖所示：

如上，可以看到這些pods在部署時是以{0…n-1}的順序依次創建的。注意，直到redis-app-0狀態啟動后達到running狀態之后，redis-app-1 才開始啟動。
同時，每個pod都會得到集群內的一個dns域名，格式為$(podname).$(service name).$(namespace).svc.cluster.local ，也即是：

在k8s集群內部，這些pod就可以利用該域名互相通信。我們可以使用busybox鏡像的nslookup檢驗這些域名：

可以看到， redis-app-0的ip為172.17.24.3。當然，若redis pod遷移或是重啟（我們可以手動刪除掉一個redis pod來測試），ip是會改變的，但是pod的域名、srv records、a record都不會改變。

另外可以發現，我們之前創建的pv都被成功綁定了：

5.初始化redis集群

創建好6個redis pod后，我們還需要利用常用的redis-tribe工具進行集群的初始化

創建ubuntu容器
由于redis集群必須在所有節點啟動后才能進行初始化，而如果將初始化邏輯寫入statefulset中，則是一件非常復雜而且低效的行為。這里，本人不得不稱贊一下原項目作者的思路，值得學習。也就是說，我們可以在k8s上創建一個額外的容器，專門用于進行k8s集群內部某些服務的管理控制。
這里，我們專門啟動一個ubuntu的容器，可以在該容器中安裝redis-tribe，進而初始化redis集群，執行：

我們使用阿里云的ubuntu源，執行：

成功后，原項目要求執行如下命令安裝基本的軟件環境：

初始化集群
首先，我們需要安裝redis-trib：

然后，創建只有master節點的集群：

其次，為每個master添加slave

至此，我們的redis集群就真正創建完畢了，連到任意一個redis pod中檢驗一下：

另外，還可以在nfs上查看redis掛載的數據：

6.創建用于訪問service

前面我們創建了用于實現statefulset的headless service，但該service沒有cluster ip，因此不能用于外界訪問。所以，我們還需要創建一個service，專用于為redis集群提供訪問和負載均衡：

如上，該service名稱為 redis-access-service，在k8s集群中暴露6379端口，并且會對labels name為app: redis或appcluster: redis-cluster的pod進行負載均衡。

創建后查看：

如上，在k8s集群中，所有應用都可以通過10.0.0.64 :6379來訪問redis集群。當然，為了方便測試，我們也可以為service添加一個nodeport映射到物理機上，這里不再詳細介紹。

五、測試主從切換

在k8s上搭建完好redis集群后，我們最關心的就是其原有的高可用機制是否正常。這里，我們可以任意挑選一個master的pod來測試集群的主從切換機制，如redis-app-0：

進入redis-app-0查看：

如上可以看到，app-0為master，slave為172.17.63.9即redis-app-3。

接著，我們手動刪除redis-app-0：

我們再進入redis-app-0內部查看：

如上，redis-app-0變成了slave，從屬于它之前的從節點172.17.63.9即redis-app-3。

六、疑問

至此，大家可能會疑惑，那為什么沒有使用穩定的標志，redis pod也能正常進行故障轉移呢？這涉及了redis本身的機制。因為，redis集群中每個節點都有自己的nodeid（保存在自動生成的nodes.conf中），并且該nodeid不會隨著ip的變化和變化，這其實也是一種固定的網絡標志。也就是說，就算某個redis pod重啟了，該pod依然會加載保存的nodeid來維持自己的身份。我們可以在nfs上查看redis-app-1的nodes.conf文件：

如上，第一列為nodeid，穩定不變；第二列為ip和端口信息，可能會改變。

這里，我們介紹nodeid的兩種使用場景：

當某個slave pod斷線重連后ip改變，但是master發現其nodeid依舊， 就認為該slave還是之前的slave。

當某個master pod下線后，集群在其slave中選舉重新的master。待舊master上線后，集群發現其nodeid依舊，會讓舊master變成新master的slave。

對于這兩種場景，大家有興趣的話還可以自行測試，注意要觀察redis的日志。

到此這篇關于在k8s上部署redis集群的方法步驟的文章就介紹到這了,更多相關k8s部署redis集群內容請搜索服務器之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持服務器之家！