Redis-Cluster-Operator容器化平臺方案

RedisClusterOperator容器化平臺方案

【導讀】對于RedisCluster的容器化，民生銀行已做了先期的探索和使用，但是，在RedisPaas使用過程中，出現(xiàn)了一些問題，本文對此進行分析，并討論使用Operator的解決方案，希望能為同行進行RedisCluster容器化提供參考。對于RedisCluster的容器化，我行已在RedisPaas中做了先期的探索和使用。在RedisPaas中實現(xiàn)了Redis哨兵模式、集群模式的容器化部署，結(jié)合IPAAS使得項目可依據(jù)自身需要自助申請并實時交付。但是，在RedisPaas使用過程中，出現(xiàn)了RedisCluster主從Pod被調(diào)度在同一節(jié)點，RedisMaster節(jié)點所在的容器發(fā)生重啟導致數(shù)據(jù)丟失的問題，而且在功能上難以支持Redis集群擴縮容、主從節(jié)點差異化配置、定時持久化等需求。本文針對RedisCluster容器化遇到的問題進行分析，并討論使用Operator的解決方案。RedisCluster容器化問題RedisCluster主從分布RedisCluster從節(jié)點除了分擔主節(jié)點的讀壓力，也是Redis高可用性重要的一部分。Redis作為一個內(nèi)存數(shù)據(jù)庫，為了保證高性能不會實時將數(shù)據(jù)刷盤進行持久化存儲，所以Redis節(jié)點宕機可能會造成數(shù)據(jù)丟失。在集群模式中，分片中的從節(jié)點不僅可以分擔主節(jié)點的讀壓力，而且也具有保證數(shù)據(jù)完整性的重要作用。所以在容器化部署時，同一分片的主從節(jié)點Pod不能調(diào)度在同一K8S節(jié)點，防止由于K8S節(jié)點宕機分片整體下線導致數(shù)據(jù)丟失。Kubernets中可以使用Pod反親和性配置，將同一類型的Pod分散在不同的節(jié)點。下面yaml配置定義所有符合Redis標簽的Pod以軟反親和性的方式分布部署在不同的節(jié)點上。spec:

affinity:

podAntiAffinity:

preferredDuringSchedulingIgnoredDuringExecution:

-

podAffinityTerm:

labelSelector:

matchLabels:

REDIS_POD_LABEL:

REDIS_POD_VALUE

topologyKey:

kubernetes.io/hostname先期RedisPaas中，同一項目的所有RedisPod由一個Statefulset管理，對同一Statefulset中所有Pod配置反親和性。在實際使用中發(fā)現(xiàn)，這種配置方法在項目RedisPod比較多或者容器平臺節(jié)點比較少的情景下，會出現(xiàn)同一分片的主從Pod被調(diào)度在同一主機節(jié)點的情況。在RedisClusterOperator的設(shè)計中，將每一個RedisCluster每個分片部署成一個Statefulset并在Statefulset內(nèi)配置Pod反親和性，這種部署方法能很好的保證RedisCluster分片主從Pod處于不同節(jié)點。RedisMaster容器快重啟在容器環(huán)境中部署的RedisCluster，數(shù)據(jù)丟失除了可能發(fā)生在主從節(jié)點同時下線的情況外，還存在另外一種情景。RedisCluster中，Master節(jié)點下線必須經(jīng)過cluster-node-timeout時間才會啟動failover機制。在容器環(huán)境中，如果主節(jié)點所在的容器由于某種原因被殺死，再被Kubernetes自動拉起，這個時間非常短暫以至于集群不會啟動failover流程。但在這種情況下，Redis進程下線又上線原先內(nèi)存中的數(shù)據(jù)會被全部清空，Slave節(jié)點不執(zhí)行failover流程繼續(xù)同步Master會導致整個分片數(shù)據(jù)丟失。該種情況某種意義上可以看作是Kubernetes的高可用機制和RedisCluster的發(fā)生了沖突。在設(shè)計Operator方案時，為避免類似情況的發(fā)生，我們需要明確Kubernetes、Operator和Redis在整個方案中的作用，劃定Kuberentes、Operator和RedisCluster的功能邊界：Kubernetes和Operator不去介入RedisCluster的高可用機制，若有沖突以RedisCluster的為準Redis容器啟動和Redis進程啟動相分離，Kubernetes只負責為Redis分配資源，Operator監(jiān)聽Redis容器啟動情況并在合適的時機啟動Redis進程，將Redis加入集群在先前RedisPaas中，Redis進程隨容器啟動而啟動，Redis進程自動讀取本地nodes.conf文件重新回到集群。在Operator中，需要監(jiān)聽Redis容器啟動，對節(jié)點加入集群的時機做把控：Case1：分片中有Master節(jié)點，則啟動容器Redis進程加入集群Case2：分片中無Master節(jié)點，但有Slave節(jié)點，則等待Redis高可用機制提升Slave為Master，然后依Case1操作Case3：分片中沒有節(jié)點。該種情況下，為保持集群的完整性，可以待所有分片包含的容器啟動后，根據(jù)各容器持久化的nodes.conf文件，選出clusterepoch最大的首先啟動其Redis進程，然后其余Redis進程依照前兩種情況啟動前兩種情況可以保證Redis的數(shù)據(jù)安全，第三種情況由于分片全部下線，若沒有在退出時對數(shù)據(jù)進行持久化保存則無法保證數(shù)據(jù)完整。除此之外，還有一種極壞的情況——RedisCluster中存活的Master不足一半，此時RedisCluster的failover機制已無法正常運行。此種情況可參照上述第三種情況處理，在該種情況下可能需要執(zhí)行clusterfailovertakeover命令才能使集群恢復正常，Operator不做高危險操作，此時由運維人員手工介入處理。Redis服務對外暴露容器化環(huán)境不同于物理環(huán)境或者虛擬機環(huán)境，容器環(huán)境的容器IP不固定，而且容器平臺使用overlay網(wǎng)絡，網(wǎng)絡IP對集群外不可見。在這種情景下，若應用與Redis同集群部署，可以使用為RedisCluster建立的Service來訪問，但是如果有集群外訪問的需求，該種方式則不能滿足。對此，需要為每個單獨的RedisPod建立NodePort型的Service，并且在Redis中增加如下配置：cluster-announce-port

REDIS_SERVICE-NODEPORT

cluster-announce-bus-port

GOSSIP-NODEPORT

cluster-announce-ip

HOSTIPRedisClusterOperatorOperator的核心是CRD(CustomResourceDefinition)和自定義Controller。在項目中，我們使用Kubebuilder進行RedisClusterOperator開發(fā)，項目整體結(jié)構(gòu)如下所示：底層使用Kubebuilder生成的Operator框架，根據(jù)資源定義生成CRD模板、并且完成與容器集群交互、監(jiān)聽資源變動等功能。左邊RedisCluster資源定義部分根據(jù)需求定義資源實體右邊為Controller部分，對資源實例進行解析和操作RedisClusterCRD建立RedisClusterCRD資源，首先將RedisCluster的需求進行抽象，如下所示：spec:

masterSize:

3

clusterReplicas:

2

exposeService:

true

image:

redis:6.0.4

dbSize:

4Gi該spec描述了部署一個RedisCluster的基本需求，包含分片數(shù)、每個分片從副本數(shù)量、是否需要集群外訪問、使用的Redis鏡像版本和每個Redis節(jié)點的最大內(nèi)存大小。然后，我們使用CRD將該需求定義擴展到Kubernetes，成為Kubernetes支持的資源：apiVersion:

apiextensions.k8s.io/v1beta1

kind:

CustomResourceDefinition

metadata:

name:

spec:

group:

version:

v1alpha1

names:

kind:

RedisCluster

listKind:

RedisClusterList

plural:

redisclusters

singular:

rediscluster

scope:

Namespaced該yaml文件定義了Kubernetes支持的一個資源，資源的Group是，Version是v1alpha1，Kind是RedisCluster。接下來就可以使用如下yaml在Kubernetes中創(chuàng)建RedisCluster資源的實例：apiVersion:

/v1alpha1

kind:

RedisCluster

metadata:

name:

demorediscluster

namespace:

redispaas

spec:

...RedisClusterController在Kubernetes中注冊了種類為RedisCluster的資源后，可以使用kubectlapply/create命令在容器集群中創(chuàng)建RedisCluster的實例。此時，容器集群僅僅做到了“認識”該資源，而對該資源的spec內(nèi)容的解析和實際的管理需要開發(fā)Controller。Operator的理念是將專業(yè)領(lǐng)域知識注入Kubernetes。在RedisClusterOperator中，Controller通過協(xié)調(diào)操作Redis和Kubernetes完成Redis集群的創(chuàng)建和維持。如上圖所示，Controller部分包含兩層：組件管理層。該部分使用Redis和Kubernetes客戶端，分別完成對Redis集群的管理和對Kubernetes原生資源的操縱，并形成調(diào)用接口在組件管理層上，根據(jù)不同的需求和資源狀態(tài)，組合調(diào)用Redis和Kubernetes管理接口，實現(xiàn)功能需求Controller操作本質(zhì)上是一個狀態(tài)機操作，整體操作流程如下所示:對于一個三分片、每個分片一個Slave的RedisCluster需求，Cont