自拍偷在线精品自拍偷,亚洲欧美中文日韩v在线观看不卡

10+款Redis容器化技術(shù)選型對(duì)比,K8S并非萬(wàn)金油

存儲(chǔ) 存儲(chǔ)軟件 Redis
在容器化技術(shù)方面,其實(shí)歷史很久遠(yuǎn)了。雖然我們現(xiàn)在用的容器化技術(shù),或者說(shuō) k8s,還有云原生的概念是近幾年才火起來(lái)的,但是實(shí)際上就容器化技術(shù)的發(fā)展來(lái)說(shuō),其實(shí)是很早的了。

[[407932]]

今天將分享的內(nèi)容分為以下4個(gè)方面:

  • 一、緣起
  • 二、介紹多樣的容器化技術(shù)
  • 三、Redis介紹
  • 四、Redis容器化方案的對(duì)比

一、緣起

首先我們先聊一下為什么今天我會(huì)分享這個(gè)主題。我和朋友一起組織了一個(gè) Redis技術(shù)交流群,到現(xiàn)在已經(jīng)經(jīng)營(yíng)了6年左右的時(shí)間,其中某一天在群里有一個(gè)小伙伴就拋出來(lái)一個(gè)問(wèn)題:

他問(wèn)大家線上的Redis有沒(méi)有使用Docker安裝?Docker使用Host的網(wǎng)絡(luò)模式、磁盤(pán)使用本地掛載模式這種方案怎么樣?這里的話我們暫時(shí)先不說(shuō)這個(gè)方案如何,因?yàn)樵诮裉斓姆窒碇螅蚁嘈糯蠹覍?duì)于這個(gè)方案應(yīng)該會(huì)有一個(gè)更清晰的認(rèn)識(shí)和評(píng)價(jià)。

二、介紹多樣的容器化技術(shù)

1、chroot和jails

在容器化技術(shù)方面,其實(shí)歷史很久遠(yuǎn)了。雖然我們現(xiàn)在用的容器化技術(shù),或者說(shuō) k8s,還有云原生的概念是近幾年才火起來(lái)的,但是實(shí)際上就容器化技術(shù)的發(fā)展來(lái)說(shuō),其實(shí)是很早的了。比如說(shuō)最早的時(shí)候來(lái)自chroot,chroot大家可能都用過(guò),或者都有了解過(guò),在1979年的時(shí)候它是來(lái)自Unix,它主要的功能是可以修改進(jìn)程和子進(jìn)程的/。

通過(guò)使用chroot達(dá)到什么樣效果呢?使用chroot加某一個(gè)目錄,然后再啟動(dòng)一個(gè)進(jìn)程,那么這個(gè)進(jìn)程自己所看到的 /,就是我們平時(shí)所說(shuō)的 / 目錄,這個(gè) / 就會(huì)是我們剛才指定的文件夾,或者說(shuō)剛才指定的路徑。這樣子的話可以有效的保護(hù)我們操作系統(tǒng)上面的一些文件,或者說(shuō)權(quán)限和安全相關(guān)的東西。

在2000年的時(shí)候,出現(xiàn)了一個(gè)新的技術(shù),叫做jails,其實(shí)它已經(jīng)具備了sandbox,就是沙箱環(huán)境的雛形。使用jails的話,可以讓一個(gè)進(jìn)程或者說(shuō)創(chuàng)建的環(huán)境擁有獨(dú)立的網(wǎng)絡(luò)接口和IP地址,而當(dāng)我們提到使用jails的話,我們肯定會(huì)想到一個(gè)問(wèn)題,就是如果你有了獨(dú)立的網(wǎng)絡(luò)接口和IP地址,這樣的話就不能發(fā)原始的套接字,通常跟原始的套接字接觸得比較多的就是我們使用的Ping命令。默認(rèn)的情況下,這樣子是不允許使用原始的套接字的,而有自己的網(wǎng)絡(luò)接口和IP地址,這個(gè)感覺(jué)上就像是我們常用的虛擬機(jī)。

2、Linux VServer和OpenVZ

接下來(lái)在2001年的時(shí)候,在Linux社區(qū)當(dāng)中就出現(xiàn)了一個(gè)新的技術(shù)叫做Linux VServer。Linux VServer有時(shí)候可以簡(jiǎn)寫(xiě)成lvs,但是和我們平時(shí)用到的4層的代理lvs其實(shí)是不一樣的。它其實(shí)是對(duì)Linux內(nèi)核的一種Patch,它是需要修改Linux內(nèi)核,修改完成之后,我們可以讓它支持系統(tǒng)級(jí)的虛擬化,同時(shí)使用Linux VServer的話,它可以共享系統(tǒng)調(diào)用,它是沒(méi)有仿真開(kāi)銷的,也就是說(shuō)我們常用的一些系統(tǒng)調(diào)用、系統(tǒng)調(diào)用的一些函數(shù)都是可以共享的。

在2005年的時(shí)候,出現(xiàn)的一個(gè)新的技術(shù)—OpenVZ。OpenVZ其實(shí)和Linux VServer有很大的相似點(diǎn),它也是對(duì)內(nèi)核的一種Patch,這兩種技術(shù)最大的變化就是它對(duì)Linux打了很多的Patch,加了很多新的功能,但是在2005年的時(shí)候,沒(méi)有把這些全部都合并到Linux的主干當(dāng)中,而且在使用OpenVZ的時(shí)候,它可以允許每個(gè)進(jìn)程可以有自己的/proc或者說(shuō)自己的/sys。

其實(shí)我們大家都知道在Linux當(dāng)中,比如說(shuō)啟動(dòng)一個(gè)進(jìn)程,你在他的/proc/self下面,你就可以看到進(jìn)程相關(guān)的信息。如果你有了自己獨(dú)立的/proc,其實(shí)你就可以達(dá)到和其他的進(jìn)程隔離開(kāi)的效果。

接下來(lái)另外一個(gè)顯著的特點(diǎn)就是它有獨(dú)立的users和groups,也就是說(shuō)你可以有獨(dú)立的用戶或者獨(dú)立的組,而且這個(gè)是可以和系統(tǒng)當(dāng)中其他的用戶或者組獨(dú)立開(kāi)的。

其次的話OpenVZ是有商業(yè)使用的,就是有很多國(guó)外的主機(jī)和各種VPS都是用OpenVZ這種技術(shù)方案。

3、namespace 和 cgroups

到了2002年的時(shí)候,新的技術(shù)是namespace。在Linux當(dāng)中我們有了新的技術(shù)叫做namespace,namespace可以達(dá)到進(jìn)程組內(nèi)的特定資源的隔離。因?yàn)槲覀兤綍r(shí)用到的namespace其實(shí)有很多種,比如說(shuō)有PID、net等,而且如果你不在相同的namespace下面的話,是看不到其他進(jìn)程特定的資源的。

到了2013年的時(shí)候,產(chǎn)生了一個(gè)新的namespace的特性,就是user namespace。其實(shí)當(dāng)有了user namespace,就和上文提到的OpenVZ實(shí)現(xiàn)的獨(dú)立用戶和組的功能是比較像的。

對(duì)于namespace的操作當(dāng)中,通常會(huì)有三種。

1)Clone

可以指定子進(jìn)程在什么namespace下面。

2)Unshare

它是與其他進(jìn)程不共享的,unshare再加一個(gè)-net,就可以與其他的進(jìn)程獨(dú)立開(kāi),不共享自己的net,不共享自己的網(wǎng)絡(luò)的namespace。

3)Setns

就是為進(jìn)程設(shè)置 namespace。

到了2008年,cgroups開(kāi)始被引入到Linux內(nèi)核當(dāng)中,它可以用于隔離進(jìn)程組的資源使用,比如說(shuō)可以隔離CPU、內(nèi)存、磁盤(pán),還有網(wǎng)絡(luò),尤其是他在2013年和user namespace進(jìn)行了一次組合之后,并且進(jìn)行了重新的設(shè)計(jì),這個(gè)時(shí)候,就變得更現(xiàn)代化了,就像我們現(xiàn)在經(jīng)常使用到的Docker的相關(guān)特性,其實(shí)都來(lái)自于這個(gè)時(shí)候。所以說(shuō)cgroups和namespace構(gòu)成現(xiàn)代容器技術(shù)的基礎(chǔ)。

4、LXC 和 CloudFoundry

在2008年的時(shí)候,新的一項(xiàng)技術(shù)叫做LXC, 我們也會(huì)叫他Linux Container(以下均簡(jiǎn)稱LXC)。上文我們提到了很多容器化的技術(shù),比如Linux VServer、OpenVZ,但是這些都是通過(guò)打Patch來(lái)實(shí)現(xiàn)的,而LXC是首個(gè)可以直接和上游的Linux內(nèi)核共同工作的。

LXC是可以支持特權(quán)容器的,意思就是說(shuō)可以在機(jī)器上面去做uid map、gid map,去做映射,而且不需要都拿root用戶去啟動(dòng),這樣子就具備了很大的便利性。而且這種方式可以讓你的被攻擊面大大縮小。LXC支持的這幾種比較常規(guī)的操作,就是LXC-start,可以用來(lái)啟動(dòng)container,LXC-attach就可以進(jìn)入container當(dāng)中。

到2011年的時(shí)候,CloudFoundry開(kāi)始出現(xiàn)了,他實(shí)際上是使用了LXC和 Warden這兩項(xiàng)技術(shù)的組合,在這個(gè)時(shí)候不得不提到的,就是他的技術(shù)架構(gòu)是CS的模式,也就是說(shuō)還有一個(gè)客戶端和server端,而 Warden容器,它通常是有兩層,一層是只讀os的,就是只讀的操作系統(tǒng)的文件系統(tǒng),另外一層是用于應(yīng)用程序和其依賴的非持久化的讀寫(xiě)層,就是這兩層的組合。

我們之前提到的技術(shù),大多數(shù)都是針對(duì)于某一臺(tái)機(jī)器的,就是對(duì)于單機(jī)的。CloudFoundry它最大的不同就是它可以管理跨計(jì)算機(jī)的容器集群,這其實(shí)就已經(jīng)有了現(xiàn)代容器技術(shù)的相關(guān)特性了。

5、LMCTFY和systemd-nspawn

在2013年的時(shí)候, Google開(kāi)源了自己的容器化的解決方案,叫做LMCTFY。這個(gè)方案是可以支持CPU、內(nèi)存還有設(shè)備的隔離。而且它是支持子容器的,可以讓?xiě)?yīng)用程序去感知到自己當(dāng)前是處在容器當(dāng)中的。另外還可以再為自己創(chuàng)建一個(gè)子容器,但是隨著2013年發(fā)展之后,它逐漸發(fā)現(xiàn)只依靠自己不停的做這些技術(shù),就相當(dāng)于單打獨(dú)斗,發(fā)展始終是有限的,所以它逐步的將自己的主要精力放在抽象和移植上,把自己的核心特性都移植到了libcontainer。而libcontainer之后就是Docker的運(yùn)行時(shí)的一個(gè)核心,再之后就是被Docker捐到了OCI,再然后就發(fā)展到了runC。這部分內(nèi)容我們稍后再詳細(xì)講解。

大家都知道服務(wù)器它肯定是有一個(gè) PID為1的進(jìn)程。就是它的初始進(jìn)程、守護(hù)進(jìn)程,而現(xiàn)代的操作系統(tǒng)的話,大多數(shù)大家都使用的是systemd,同樣systemd它也提供了一種容器化的解決方案,叫做 systemd-nspawn。這個(gè)技術(shù)的話,它是可以和systemd相關(guān)的工具鏈進(jìn)行結(jié)合的。

systemd除了有我們平時(shí)用到的systemctl之類的,還有systemd machine ctl,它可以去管理機(jī)器,這個(gè)機(jī)器支持兩種主要的接口,一種是管理容器相關(guān)的接口,另外一種是管理虛擬機(jī)相關(guān)的接口。

而我們通常來(lái)講,就是說(shuō)systemd提供的容器技術(shù)解決方案,它是允許我們通過(guò)machine ctl去容器去進(jìn)行交互的,比如說(shuō)你可以通過(guò)machine ctl start,去啟動(dòng)一個(gè)systemd支持的容器,或者通過(guò) machine ctl stop,去關(guān)掉它,而在這種技術(shù)下,它是支持資源還有網(wǎng)絡(luò)等隔離的,其實(shí)它最主要的是systemd ns,它其實(shí)是使用namespace去做隔離。對(duì)于資源方面是來(lái)自于systemd,systemd是可以使用cgroups去做資源隔離的,其實(shí)這也是這兩種兩種技術(shù)方案的組合。

6、Docker

而在2013年Docker也出現(xiàn)了。通常來(lái)講,Docker是容器時(shí)代的引領(lǐng)者,為什么這么說(shuō)呢?因?yàn)镈ocker在2013年出現(xiàn)的時(shí)候,他首先提到了標(biāo)準(zhǔn)化的部署單元,就是Docker image。同時(shí)它還推出了DockerHub,就是中央鏡像倉(cāng)庫(kù)。允許所有人通過(guò)DockerHub去下載預(yù)先已經(jīng)構(gòu)建好的Docker image,并且通過(guò)一行Docker run就可以啟動(dòng)這個(gè)容器。

在眾多使用起來(lái)比較繁瑣、比較復(fù)雜的技術(shù)下,Docker這時(shí)提出來(lái),你只需要一行Docker run,就可以啟動(dòng)一個(gè)容器,它大大簡(jiǎn)化了大家啟動(dòng)容器的復(fù)雜度,提升了便捷性。

所以Docker這項(xiàng)技術(shù)就開(kāi)始風(fēng)靡全球。而Docker它主要提供的一些功能是什么呢?比如說(shuō)資源的隔離和管理。而且Docker在0.9之前,它的容器運(yùn)行時(shí)是LXC,在0.9之后,他就開(kāi)始把LXC替換掉,替換成了libcontainer,而這個(gè)libcontainer其實(shí)就是我們?cè)谏衔奶岬降腉oogle的 LMCTFY。再之后libcontainer捐給了OCI。而那之后Docker現(xiàn)在的容器運(yùn)行時(shí)是什么呢?是containerd。containerd的更下層是runc,runc的核心其實(shí)就是libcontainer。

而到了2014年的時(shí)候, Google發(fā)現(xiàn)大多數(shù)的容器化解決方案,其實(shí)都只提供了單機(jī)的解決方案,同時(shí)由于Docker也是CS架構(gòu)的,所以它需要有一個(gè)Docker demand,它是需要有守護(hù)進(jìn)程存在的,而這個(gè)守護(hù)進(jìn)程的話,是需要用root用戶去啟動(dòng)的,而root用戶啟動(dòng)的守護(hù)進(jìn)程,其實(shí)是增加了被攻擊面,所以 Docker的安全問(wèn)題也被很多人詬病。

在這個(gè)時(shí)候 Google就發(fā)現(xiàn)了這個(gè)點(diǎn),并且把自己的Borg系統(tǒng)去做了開(kāi)源,開(kāi)源版本就是Kubernetes。Google還聯(lián)合了一些公司,組建了一個(gè)云原生基金會(huì)(CNCF)。

7、Kubernetes

通常來(lái)講Kubernetes是云原生應(yīng)用的基石,也就是說(shuō)在Kubernetes出現(xiàn)之后,我們的云原生技術(shù)開(kāi)始逐步地發(fā)展起來(lái),逐步地引領(lǐng)了潮流,Kubernetes提供了一些主要的特性。

它可以支持比較靈活的調(diào)度、控制和管理,而這個(gè)調(diào)度程序的話,除了它默認(rèn)的以外,也可以比較方便的去對(duì)它做擴(kuò)展,比如說(shuō)我們可以自己去寫(xiě)自己的調(diào)度程序,或者說(shuō)親和性、反親和性,這些其實(shí)都是我們比較常用到的一些特性。

還有包括他提供的一些服務(wù),比如說(shuō)內(nèi)置的 DNS、kube-DNS或者說(shuō)現(xiàn)在的CoreDNS,通過(guò)域名的方式去做服務(wù)發(fā)現(xiàn),以及Kubernetes當(dāng)中有很多的控制器。它可以將集群的狀態(tài)調(diào)整至我們預(yù)期的狀態(tài),就比如說(shuō)有一個(gè)pod掛掉了,它可以自動(dòng)的把它再恢復(fù)到我們預(yù)期想要的樣子。

另外就是它支持豐富的資源種類,比如說(shuō)幾個(gè)主要的層級(jí),最小的是pod,再往上有deployment,或者有StatefulSets,類似于這樣子的資源。

最后一點(diǎn)是它讓我們更加喜歡它的因素,就是它有豐富的CRD的拓展,即可以通過(guò)自己去寫(xiě)一些自定義的資源,然后對(duì)它進(jìn)行擴(kuò)展,比如CRD。

8、更多的容器化技術(shù)

除了剛才我們提到的這些主要的技術(shù)以外,其實(shí)還有很多我們沒(méi)有提到的一些容器化的技術(shù),比如說(shuō)像runc,上文我們沒(méi)有太多的介紹,還有containerd。containerd其實(shí)也是Docker開(kāi)源出來(lái)的自己的核心,他的目標(biāo)是做一個(gè)標(biāo)準(zhǔn)化工業(yè)可用的容器運(yùn)行時(shí),還有CoreOS開(kāi)源出來(lái)的解決方案叫做rkt。而rkt瞄準(zhǔn)的點(diǎn)就是上文提到的Docker相關(guān)的安全問(wèn)題。但是rkt現(xiàn)在項(xiàng)目已經(jīng)終止了。

還有紅帽(Red Hat)開(kāi)源出來(lái)的 podman, podman是一種可以用它來(lái)啟動(dòng)容器,可以用它去管理容器,而且沒(méi)有守護(hù)進(jìn)程,所以就安全性來(lái)講的話,podman可以說(shuō)比Docker的安全性直觀上來(lái)看的話會(huì)好一些,但是它的便捷性來(lái)講的話,就要大打折扣了。比如說(shuō)容器的重啟、開(kāi)機(jī)起之類的,但是我們都是有一些不同的解決方案的。

在2017年的時(shí)候,這個(gè)時(shí)候有一個(gè) Kata Container,而這個(gè)Kata Container它有一段發(fā)展過(guò)程,最開(kāi)始是英特爾,英特爾在搞自己的容器運(yùn)行時(shí),還有一家初創(chuàng)公司叫做hyper.sh,這家公司也在搞自己的容器運(yùn)行時(shí),這兩家公司瞄準(zhǔn)的都是做更安全的容器,他們使用的底層的技術(shù)都是基于K8S。而之后這兩家公司做了合并,hyper.sh它開(kāi)源出來(lái)的一個(gè)解決方案是runv,被英特爾看上了之后就誕生了 Kata Container。在2018年的時(shí)候,AWS開(kāi)源出來(lái)自己的Firecracker。

這兩項(xiàng)技術(shù)和我們上文提到的機(jī)器上的容器化技術(shù)其實(shí)大有不同,因?yàn)樗牡讓悠鋵?shí)相當(dāng)于是虛擬機(jī),而我們通常來(lái)講,都認(rèn)為它是輕量級(jí)虛擬機(jī)的一種容器化的技術(shù)。以上就是關(guān)于多樣的容器化技術(shù)的介紹。

三、Redis介紹

接下來(lái)進(jìn)入關(guān)于Redis相關(guān)的介紹,以下是從Redis的官網(wǎng)上面摘抄的一段介紹。

1、Redis使用的主要場(chǎng)景

其實(shí)Redis現(xiàn)在是使用最廣泛的一種KV型數(shù)據(jù)庫(kù)。而我們?cè)谑褂盟臅r(shí)候,主要的使用場(chǎng)景可能有以下幾種:

  • 把它當(dāng)緩存使用,把它放在數(shù)據(jù)庫(kù)之前,把它當(dāng)做緩存去使用。
  • 把它當(dāng)DB來(lái)用,這種就是需要把真正的拿它來(lái)存數(shù)據(jù)做持久化。
  • 做消息隊(duì)列,它支持的數(shù)據(jù)類型也比較多,這里就不再做介紹了。

2、Redis的特點(diǎn)

  • 它是一個(gè)單線程的模型,它其實(shí)是可以有多個(gè)線程的,但是它的worker線程只有一個(gè),在Redis6.0開(kāi)始,它支持了io多線程,但io多線程只是可以有多線程去處理有網(wǎng)絡(luò)相關(guān)的部分,實(shí)際上你真正去處理數(shù)據(jù)還是單線程,所以整體而言,我們?nèi)匀话阉凶鰡尉€程模型。
  • Redis的數(shù)據(jù)其實(shí)都在內(nèi)存里頭,它是一個(gè)內(nèi)存型的數(shù)據(jù)庫(kù)。
  • 與HA相關(guān), Redis想要做HA,我們以前在做 Redis的HA主要靠Redis sentinel,而后面在Redis出來(lái)cluster之后,我們主要靠Redis cluster去做HA,這是兩種主要HA的解決方案。

四、Redis容器化方案的對(duì)比

當(dāng)我們提到做 Redis運(yùn)維相關(guān)的時(shí)候,我們有哪些需要考慮的點(diǎn):

  • 部署,如何快速的部署,如何能夠快速的部署,而且還要去管理監(jiān)聽(tīng)的端口,讓端口不起沖突,還有日志和持久化文件之類的,這部分都屬于部署相關(guān)的內(nèi)容;
  • 擴(kuò)/縮容,也是我們經(jīng)常會(huì)遇到的問(wèn)題;
  • 監(jiān)控和報(bào)警;
  • 故障和恢復(fù)。

以上都是我們最關(guān)注的幾個(gè)方面。我接下來(lái)就對(duì)這幾個(gè)方面去做一些介紹。

1、部署

當(dāng)我們提到去做單機(jī)多實(shí)例的時(shí)候,Redis作單機(jī)多實(shí)例去部署的時(shí)候,首先第一點(diǎn)就是我們希望能夠有進(jìn)程級(jí)別的資源隔離,我們某一個(gè)節(jié)點(diǎn)上面所有部署的Redis實(shí)例,可以有自己的資源,可以不受別的實(shí)例的影響,這就是對(duì)于進(jìn)程級(jí)別的資源隔離。

進(jìn)程級(jí)別的資源隔離,它其實(shí)主要分為兩個(gè)方面,一方面是CPU,另一方面是內(nèi)存,其次的話我們希望在單機(jī)上面我們也可以有自己的端口管理,或者說(shuō)我們可以有獨(dú)立的網(wǎng)絡(luò)資源隔離的相關(guān)的技術(shù)。

在這種情況下,首先我們提到說(shuō)進(jìn)程級(jí)別的資源隔離,我們介紹了那么多的容器化相關(guān)技術(shù),我們已經(jīng)知道了,支持進(jìn)程級(jí)別的資源隔離的話,有最簡(jiǎn)單的一種方案就是用cgroups,如果想要去做網(wǎng)絡(luò)資源隔離的話,我們有namespace,也就是說(shuō)所有支持cgroups和 namespace的這種計(jì)劃的解決方案,都可以滿足我們這個(gè)地方的需求。

再有一種方案就是虛擬化的方案,也就是我們上文提到比如說(shuō)Kata Container,Kata Container這種基于虛擬化的方式,因?yàn)樘摂M化的方案其實(shí)大家都有所接觸,大家都知道就是虛擬化的這種技術(shù),其實(shí)默認(rèn)情況下,剛開(kāi)始全部都做隔離。

所以對(duì)于部署而言,如果你使用的是比如說(shuō)像Docker,比如說(shuō)你想使用的像 systemd-nspawn這些它都可以既用到cgroups,又用到了 namespace,是都可以去用的,只不過(guò)是你需要考慮一些便捷性,比如說(shuō)你如果是使用Docker的話,進(jìn)行一個(gè)Docker命令跑過(guò)去,然后只要讓它映射到不同的端口,其實(shí)就結(jié)束了。

如果你使用是systemd-nspawn,這樣子的話,你需要去寫(xiě)一些配置文件。如果你要是去用一些虛擬化的解決方案的話,同樣的也需要去準(zhǔn)備一些鏡像。

2、擴(kuò)/縮容

關(guān)于擴(kuò)/縮容,其實(shí)會(huì)有兩種最主要的場(chǎng)景,一種場(chǎng)景就是單實(shí)例 maxmemory 調(diào)整,就是我們最大內(nèi)存的調(diào)整。還有一種是對(duì)于我們的集群化的集群解決方案,就是Redis Cluster。對(duì)于這種集群規(guī)模,我們有擴(kuò)/縮容的話,會(huì)有兩方面的變化。

一方面是 Node,就是我們的節(jié)點(diǎn)的變更,如果會(huì)新增節(jié)點(diǎn),也可能會(huì)去移除節(jié)點(diǎn)。

另外一種就是Slot的變更,就是希望把我的 slot 去做一些遷移,當(dāng)然這些和Node節(jié)點(diǎn)會(huì)是相關(guān)的,因?yàn)楫?dāng)我們?nèi)プ鰯U(kuò)容的時(shí)候,我們把Redis Cluster當(dāng)中的一些Node節(jié)點(diǎn)增多,增多了之后,就可以不給他分配Slot,或者說(shuō)我想要讓某些Slot集中到某些節(jié)點(diǎn)上面,其實(shí)這些需求也是同樣存在的。

那我們來(lái)看一下,如果你當(dāng)時(shí)想要去做maxmemory的調(diào)整,如果我們是前提已經(jīng)做了容器化,想通過(guò) cgroups去對(duì)它做資源的限制,就需要有一個(gè)可以支持動(dòng)態(tài)調(diào)整 cgroups配額的解決方案。

比如說(shuō)我們用到Docker update,它是可以直接修改某個(gè)實(shí)例,或者說(shuō)其中的某一個(gè)容器的cgroups資源的一些限制,比如說(shuō)我們可以Docker update,給它指定新的內(nèi)存,可以限制它最大可用內(nèi)存,當(dāng)你把它的可用內(nèi)存數(shù)調(diào)大,接下來(lái)你就可以對(duì)實(shí)例去調(diào)整它的 maxmemory ,也就是說(shuō)對(duì)于單實(shí)例 maxmemory,其實(shí)最主要的就是需要有cgroups的技術(shù),向cgroups的技術(shù)提供一些支持。

對(duì)于集群節(jié)點(diǎn)的變更的話,這個(gè)部分稍后再做詳細(xì)介紹。

3、監(jiān)控報(bào)警

第三點(diǎn)就是監(jiān)控報(bào)警,不管是使用物理機(jī)也好,或者使用云環(huán)境也好,或者使用任何解決方案都好,監(jiān)控報(bào)警我們最想要得到的效果就是,它可以自動(dòng)發(fā)現(xiàn)。

我們希望當(dāng)啟動(dòng)一個(gè)實(shí)例之后,我們就可以立馬知道這個(gè)實(shí)例A他已經(jīng)起來(lái)了,并且知道他的狀態(tài)是什么,而監(jiān)控報(bào)警的話,這部分其實(shí)是不依賴于特定的容器化技術(shù)的,就即使是在純粹的物理機(jī)上部署,也可以通過(guò)一些解決方案自動(dòng)的發(fā)現(xiàn)它,自動(dòng)的把它注冊(cè)到我們的監(jiān)控系統(tǒng)當(dāng)中去,所以它是屬于監(jiān)控報(bào)警的這部分,其實(shí)它是不依賴于特定的容器技術(shù)的,但唯一的一個(gè)問(wèn)題就是說(shuō)假如說(shuō)使用了容器化的方案,可以讓常用的 Redis exporter,配合Prometheus去做監(jiān)控,可以讓 Redis exporter和 Redis server,這兩個(gè)進(jìn)程可以處于同一個(gè)網(wǎng)絡(luò)的命名空間。

如果他們兩個(gè)處于同一個(gè)網(wǎng)絡(luò)的命名空間的話,可以直接通過(guò)127.0.0.1:6379,然后直接去聯(lián)通它,如果我們使用的是k8s的話,可以直接把它倆放到一個(gè)pod當(dāng)中,但是這些都無(wú)關(guān)緊要,因?yàn)樗遣灰蕾囉谔囟ǖ娜萜骰夹g(shù)的,你可以使用任何你想要用的技術(shù),都可以去做監(jiān)控和報(bào)警。

4、故障恢復(fù)

最后我們提到的部分是故障和恢復(fù)。在這個(gè)部分我認(rèn)為最主要的有三個(gè)方面:

  • 第一個(gè)是實(shí)例的重啟。

有可能在某些情況下,某些場(chǎng)景下,你的實(shí)例在運(yùn)行過(guò)程當(dāng)中它可能會(huì)宕掉,如果你想讓他自動(dòng)重啟的話,你需要有一個(gè)進(jìn)程管理的工具。對(duì)于我們而言,上文我們提到了systemd,systemd是可以支持對(duì)于某一個(gè)進(jìn)程的自動(dòng)拉起的,還可以支持進(jìn)程掛掉之后自動(dòng)拉起, 可以 restart,或者你使用Docker,它也有一個(gè)restart policy,可以指定他為 always或者指定為on-failure,然后讓它在掛掉的時(shí)候再把它給拉起來(lái)。

如果你使用的是k8s,那么就更簡(jiǎn)單了,可以自動(dòng)拉起來(lái)。

  • 第二個(gè)是主從切換。

主從切換相對(duì)來(lái)說(shuō)是一個(gè)常態(tài),但在這里我也把它列到故障恢復(fù)當(dāng)中,是因?yàn)榭赡茉谥鲝那袚Q的過(guò)程當(dāng)中,有可能你的集群狀況已經(jīng)不健康了,是會(huì)有這種情況存在的。那主從切換的時(shí)候我們需要做什么?第一方面,需要讓他能夠有數(shù)據(jù)的持久化,另一方面在主從切換的時(shí)候,有可能會(huì)遇到一種情況,就是資源不夠,導(dǎo)致主從切換失敗,在這種情況下,其實(shí)和我們上文前面提到的擴(kuò)/縮容其實(shí)是相關(guān)的,所以在這種情況下就必須得給他加資源,而最好的辦法是可以自動(dòng)給他加資源。

在k8s當(dāng)中,想要讓它自動(dòng)加資源,我們通常會(huì)給他設(shè)置它的request和limit,就是資源的配額,希望它能自動(dòng)的加起來(lái),我們通常把他叫做vpa。

  • 第三個(gè)是數(shù)據(jù)恢復(fù)。

通常來(lái)講,比如說(shuō)我們開(kāi)了 RDB和AOF,而且希望我們的數(shù)據(jù)可以保存下來(lái),以便于在我們數(shù)據(jù)恢復(fù)的時(shí)候可以直接開(kāi)始使用。所以數(shù)據(jù)持久化也是一方面。

我們?nèi)プ鋈萜骰臅r(shí)候,我們需要考慮哪些點(diǎn)?如果說(shuō)你是使用Docker的話,你需要去掛一個(gè)券,然后你可以把這個(gè)數(shù)據(jù)去做持久化,比如說(shuō)你使用systemd-nspawn也需要有一個(gè)文件目錄去把這個(gè)數(shù)據(jù)做持續(xù)化。

如果你使用的是k8s的話,在掛券的時(shí)候,你會(huì)有各種各樣的選擇,比如說(shuō)你可以去掛 ceph的RDB、s3或者一個(gè)本地的某一個(gè)文件目錄。但是為了更高的可靠性,可能會(huì)使用副本數(shù)更多的分布式存儲(chǔ)。

5、Node節(jié)點(diǎn)變更

接下來(lái),我們來(lái)聊一下上文我們?cè)谔岬椒?wù)擴(kuò)/縮容的時(shí)候,提到的關(guān)于Node節(jié)點(diǎn)變更,比如說(shuō)我想要讓我的某一個(gè)Redis cluster,去擴(kuò)充一些節(jié)點(diǎn),擴(kuò)充節(jié)點(diǎn)的時(shí)候,那就意味著你必須能夠加入集群,能夠和集群正常通信,這才說(shuō)明你真正的加入到了集群當(dāng)中。

而我們也知道在Redis cluster當(dāng)中,你要去做集群,最大的一個(gè)問(wèn)題就是k8s,k8s當(dāng)中做服務(wù)發(fā)現(xiàn)其實(shí)它都是大多數(shù)通過(guò)一個(gè)域名,而我們的Redis當(dāng)中,比如說(shuō)我們的NodeIP,它其實(shí)只支持IP,它并不支持我們的域名。

所以如果說(shuō)Node節(jié)點(diǎn)變更,需要做的事情就是允許我們動(dòng)態(tài)地去把NodeIP寫(xiě)到我們的集群配置當(dāng)中。

如果想要讓它有一個(gè)完整的生命周期,以下截圖是來(lái)自于一個(gè)叫Kubedb的operator,在下圖中可以看到,Redis這個(gè)地方提供了最主要的三個(gè)部分:

  • PVCs,PVCs就是做數(shù)據(jù)的持久化。
  • Services,Services就是做服務(wù)發(fā)現(xiàn)。
  • StatefulSets,StatefulSets其實(shí)就是k8s當(dāng)中的一種資源,而這資源它對(duì)于我們的有狀態(tài)應(yīng)用會(huì)更友好一些。

其實(shí)在整個(gè)內(nèi)容當(dāng)中還有一點(diǎn)沒(méi)有介紹的是什么呢?就是Redis背后的公司叫做Redis Labs,它提供了一種商業(yè)化的方案,就是Redis Enterprise一種解決方案。其實(shí)也是在k8s的解決方案之上的,也是用了Redis operator。他的方案和Kubedb這種方案基本類似,因?yàn)楹诵倪€都是用的StatefulSets,然后再加上自己的Controller,去完成這個(gè)事情。

五、總結(jié)

我們來(lái)看一下今天的總結(jié)。如果是我們單機(jī)使用的話,我們可以交給Docker或者其他支持cgroups或者namespace資源管理的工具。因?yàn)楫?dāng)你使用了cgroups、namespace的話,你可以做到資源的隔離,可以避免網(wǎng)絡(luò)的端口的沖突之類的事情都可以實(shí)現(xiàn)。

而如果是像我在上文提到的小伙伴提到的那個(gè)問(wèn)題:他打算使用主機(jī)的網(wǎng)絡(luò),僅僅是想讓Docker去做一個(gè)進(jìn)程管理,而且你也不希望引入新的內(nèi)容。那么systemd或者systemd-nspawn都是可以考慮的,因?yàn)檫@也是容器化的解決方案。

如果是在復(fù)雜場(chǎng)景下的調(diào)度和管理的話,比如想要有很大的規(guī)模,并且想要有更靈活的調(diào)度和管理,我推薦你使用的是Kubernetes operator,比如說(shuō)Kubedb,其實(shí)也是一種解決方案。如果你的場(chǎng)景沒(méi)有那么復(fù)雜,比較簡(jiǎn)單,其實(shí)原生的Kubernetes StatefulSets稍微做一些調(diào)整和修改,也是可以滿足你的需求。

以上就是我今天分享的主要內(nèi)容了,感謝大家的參與。

[[407935]]

張晉濤,負(fù)責(zé)DevOps的實(shí)踐和落地,推進(jìn)容器化技術(shù)落地和運(yùn)維自動(dòng)化等。

參與了眾多知名開(kāi)源項(xiàng)目,對(duì)Docker、Kubernetes及相關(guān)生態(tài)有大量生產(chǎn)實(shí)踐和深入源碼的研究。

 

 

責(zé)任編輯:武曉燕 來(lái)源: dbaplus社群
相關(guān)推薦

2021-06-29 15:39:16

容器技術(shù)Redis

2023-10-24 08:01:38

String傳統(tǒng)

2020-04-28 17:13:12

箭頭函數(shù)ES6函數(shù)

2020-11-02 17:34:22

數(shù)據(jù)分析人工智能技術(shù)

2023-06-30 07:19:25

電源供電顯卡

2024-12-26 09:58:18

2025-04-24 08:25:00

2021-12-15 10:20:08

緩存架構(gòu)開(kāi)發(fā)

2021-01-28 14:41:08

麥肯錫數(shù)字化項(xiàng)目

2013-02-22 09:43:41

面向?qū)ο?/a>面向?qū)ο缶幊?/a>

2018-07-01 08:34:09

緩存數(shù)據(jù)服務(wù)

2023-07-04 07:30:03

容器Pod組件

2022-06-07 17:01:31

UI框架前端

2021-11-08 11:21:18

redis 淘汰算法

2017-09-04 16:20:38

Linuxshell命令

2023-08-01 16:21:44

模型AI

2022-06-30 10:22:26

K8s可觀測(cè)Prometheus

2021-11-29 13:13:57

網(wǎng)絡(luò)虛擬化容器

2022-04-22 13:32:01

K8s容器引擎架構(gòu)

2022-01-02 08:42:50

架構(gòu)部署容器
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)