当前位置: > 其它学习 > Kubernetes >

k8s 部署 redis 集群

时间:2023-02-27 16:00来源:未知 作者:IT
部署一个多主多从的 redis 集群

准备

采用 StatefulSet 部署有状态服务

StatefulSet 介绍

StatefulSet 是 deployment 的一种变体。管理所有有状态的服务,拥有固定的 pod 名称,启停顺序,还需要用到共享存储。
deployment 对应的服务是 service

StatefulSet 对应的服务是 headless service,无头服务与 service 的区别是没有 Cluster IP,解析他的名称时返回改 headless service 对应的全部 pod 的 endpoint 列表。

此外 StatefulSet 在无头服务的基础上,为对应的所有 pod 创建了一个 DNS 域名,域名的格式为:

$(podname).(headless server name)  
FQDN: $(podname).(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,接受客户端请求

部署过程

基于 StatefulSet 的 Redis 创建步骤:

1. 创建 NFS 存储
2. 创建 PV
3. 创建 PVC
4. 创建 Configmap
5. 创建 headless 服务
6. 创建 Redis StatefulSet
7. 初始化 Redis 集群

1. 创建 NFS 存储

创建 NFS 存储主要是为了给 Redis 提供稳定的后端存储,当 Redis 的 Pod 重启或迁移后,依然能获得原先的数据。这里,我们先要创建 NFS,然后通过使用 PV 为 Redis 挂载一个远程的 NFS 路径。

安装 NFS
yum -y install nfs-utils(主包提供文件系统)
yum -y install rpcbind(提供rpc协议)
然后,新增 /etc/exports 文件,用于设置需要共享的路径:

cat > /etc/exports << EOF
/ssd/nfs/k8s/redis/pv1 192.168.10.0/24(rw,sync,no_root_squash)
/ssd/nfs/k8s/redis/pv2 192.168.10.0/24(rw,sync,no_root_squash)
/ssd/nfs/k8s/redis/pv3 192.168.10.0/24(rw,sync,no_root_squash)
/ssd/nfs/k8s/redis/pv4 192.168.10.0/24(rw,sync,no_root_squash)
/ssd/nfs/k8s/redis/pv5 192.168.10.0/24(rw,sync,no_root_squash)
/ssd/nfs/k8s/redis/pv6 192.168.10.0/24(rw,sync,no_root_squash)

EOF
创建相应目录

mkdir -p /ssd/nfs/k8s/redis/pv{1..6}


接着,启动 NFS 和 rpcbind 服务:

systemctl restart rpcbind

systemctl restart nfs

systemctl enable nfs

[root@itrainning-149 ~]# exportfs -v
/ssd/nfs/logdmtm
  192.168.10.75(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,all_squash)
/ssd/nfs/logdmtm
  192.168.10.7(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,all_squash)
/ssd/nfs/k8s/redis/pv1
  192.168.10.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/ssd/nfs/k8s/redis/pv2
  192.168.10.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/ssd/nfs/k8s/redis/pv3
  192.168.10.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/ssd/nfs/k8s/redis/pv4
  192.168.10.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/ssd/nfs/k8s/redis/pv5
  192.168.10.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/ssd/nfs/k8s/redis/pv6
  192.168.10.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/ssd/nfs/logmetlife
  <world>(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,root_squash,all_squash)
客户端

yum -y install nfs-utils
查看存储端共享

[root@work75 ~]# showmount -e 192.168.0.149
Export list for 192.168.0.149:
/ssd/nfs/logmetlife    *
/ssd/nfs/k8s/redis/pv6 192.168.10.0/24
/ssd/nfs/k8s/redis/pv5 192.168.10.0/24
/ssd/nfs/k8s/redis/pv4 192.168.10.0/24
/ssd/nfs/k8s/redis/pv3 192.168.10.0/24
/ssd/nfs/k8s/redis/pv2 192.168.10.0/24
/ssd/nfs/k8s/redis/pv1 192.168.10.0/24
/ssd/nfs/logdmtm       192.168.10.7,192.168.10.75

创建 PV
每一个 Redis Pod 都需要一个独立的 PV 来存储自己的数据,因此可以创建一个 pv.yaml 文件,包含 6 个 PV:

cat > pv.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv1
spec:
  capacity:
    storage: 200M
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.0.149
    path: "/ssd/nfs/k8s/redis/pv1"

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-vp2
spec:
  capacity:
    storage: 200M
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.0.149
    path: "/ssd/nfs/k8s/redis/pv2"

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv3
spec:
  capacity:
    storage: 200M
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.0.149
    path: "/ssd/nfs/k8s/redis/pv3"

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv4
spec:
  capacity:
    storage: 200M
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.0.149
    path: "/ssd/nfs/k8s/redis/pv4"

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv5
spec:
  capacity:
    storage: 200M
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.0.149
    path: "/ssd/nfs/k8s/redis/pv5"

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv6
spec:
  capacity:
    storage: 200M
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.0.149
    path: "/ssd/nfs/k8s/redis/pv6"
EOF
2. 创建 Configmap
这里,我们可以直接将 Redis 的配置文件转化为 Configmap,这是一种更方便的配置读取方式。配置文件 redis.conf 如下

cat > redis.conf << EOF

appendonly yes

cluster-enabled yes

cluster-config-file /var/lib/redis/nodes.conf

cluster-node-timeout 5000

dir /var/lib/redis

port 6379
EOF
创建名为 redis-conf 的 Configmap:

kubectl create configmap redis-conf --from-file=redis.conf
查看创建的 configmap:

kubectl describe cm redis-conf

Name:         redis-conf

Namespace:    default

Labels:       <none>

Annotations:  <none>

Data

====

redis.conf:

----

appendonly yes

cluster-enabled yes

cluster-config-file /var/lib/redis/nodes.conf

cluster-node-timeout 5000

dir /var/lib/redis

port 6379

Events:  <none>
如上,redis.conf 中的所有配置项都保存到 redis-conf 这个 Configmap 中。


3. 创建 Headless service

Headless service 是 StatefulSet 实现稳定网络标识的基础,我们需要提前创建。准备文件 headless-service.yml 如下:


[root@master redis]# cat headless-service.yaml

apiVersion: v1

kind: Service

metadata:

  name: redis-service

  labels:

    app: redis

spec:

  ports:

  - name: redis-port

    port: 6379

  clusterIP: None

  selector:

    app: redis
创建:

kubectl create -f headless-service.yml
查看:



4. 创建 Redis 集群节点
创建好 Headless service 后,就可以利用 StatefulSet 创建 Redis 集群节点,这也是本文的核心内容。我们先创建 redis.yml 文件:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis-app
spec:
  serviceName: "redis-service"
  replicas: 6
  template:
    metadata:
      labels:
        app: redis
    spec:
      terminationGracePeriodSeconds: 20
      affinity:
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: app
                  operator: In
                  values:
                  - redis
              topologyKey: kubernetes.io/hostname
      containers:
      - name: redis
        image: redis
        command:
          - "redis-server"
        args:
          - "/etc/redis/redis.conf"
          - "--protected-mode"
          - "no"
        resources:
          requests:
            cpu: "100m"
            memory: "100Mi"
        ports:
            - name: redis
              containerPort: 6379
              protocol: "TCP"
            - name: cluster
              containerPort: 16379
              protocol: "TCP"
        volumeMounts:
          - name: "redis-conf"
            mountPath: "/etc/redis"
          - name: "redis-data"
            mountPath: "/var/lib/redis"
      volumes:
      - name: "redis-conf"
        configMap:
          name: "redis-conf"
          items:
            - key: "redis.conf"
              path: "redis.conf"
  volumeClaimTemplates:
  - metadata:
      name: redis-data
    spec:
      accessModes: [ "ReadWriteMany" ]
      resources:
        requests:
          storage: 200M
  selector:
    matchLabels:
      app: redis
如上,总共创建了 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 ,也即是:


redis-app-0.redis-service.default.svc.cluster.local

redis-app-1.redis-service.default.svc.cluster.local

...以此类推...
可以看到, 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 集群,执行:

kubectl run -it ubuntu --image=ubuntu --restart=Never /bin/bash
我们使用阿里云的 Ubuntu 源,执行:

root@ubuntu:/# cat > /etc/apt/sources.list << EOF

deb http://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiverse

deb-src http://mirrors.aliyun.com/ubuntu/ bionic main restricted universe multiverse

deb http://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiverse

deb-src http://mirrors.aliyun.com/ubuntu/ bionic-security main restricted universe multiverse

deb http://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiverse

deb-src http://mirrors.aliyun.com/ubuntu/ bionic-updates main restricted universe multiverse

deb http://mirrors.aliyun.com/ubuntu/ bionic-proposed main restricted universe multiverse

deb-src http://mirrors.aliyun.com/ubuntu/ bionic-proposed main restricted universe multiverse

 

deb http://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse

deb-src http://mirrors.aliyun.com/ubuntu/ bionic-backports main restricted universe multiverse

> EOF
成功后,原项目要求执行如下命令安装基本的软件环境:

apt-get update

apt-get install -y vim wget python2.7 python-pip redis-tools dnsutils
初始化集群
首先,我们需要安装redis-trib:

pip install redis-trib==0.5.1
然后,创建只有 Master 节点的集群:

redis-trib.py create \

  `dig +short redis-app-0.redis-service.default.svc.cluster.local`:6379 \

  `dig +short redis-app-1.redis-service.default.svc.cluster.local`:6379 \

  `dig +short redis-app-2.redis-service.default.svc.cluster.local`:6379
其次,为每个 Master 添加 Slave

redis-trib.py replicate \

  --master-addr `dig +short redis-app-0.redis-service.default.svc.cluster.local`:6379 \

  --slave-addr `dig +short redis-app-3.redis-service.default.svc.cluster.local`:6379

redis-trib.py replicate \

  --master-addr `dig +short redis-app-1.redis-service.default.svc.cluster.local`:6379 \

  --slave-addr `dig +short redis-app-4.redis-service.default.svc.cluster.local`:6379

redis-trib.py replicate \

  --master-addr `dig +short redis-app-2.redis-service.default.svc.cluster.local`:6379 \

  --slave-addr `dig +short redis-app-5.redis-service.default.svc.cluster.local`:6379
至此,我们的 Redis 集群就真正创建完毕了,连到任意一个 Redis Pod 中检验一下:

[root@master redis]# kubectl exec -it redis-app-2 /bin/bash

root@redis-app-2:/data# /usr/local/bin/redis-cli -c

127.0.0.1:6379> cluster nodes

5d3e77f6131c6f272576530b23d1cd7592942eec 172.17.24.3:6379@16379 master - 0 1559628533000 1 connected 0-5461

a4b529c40a920da314c6c93d17dc603625d6412c 172.17.63.10:6379@16379 master - 0 1559628531670 6 connected 10923-16383

368971dc8916611a86577a8726e4f1f3a69c5eb7 172.17.24.9:6379@16379 slave 0025e6140f85cb243c60c214467b7e77bf819ae3 0 1559628533672 4 connected

0025e6140f85cb243c60c214467b7e77bf819ae3 172.17.63.8:6379@16379 master - 0 1559628533000 2 connected 5462-10922

6d5ee94b78b279e7d3c77a55437695662e8c039e 172.17.24.8:6379@16379 myself,slave a4b529c40a920da314c6c93d17dc603625d6412c 0 1559628532000 5 connected

2eb3e06ce914e0e285d6284c4df32573e318bc01 172.17.63.9:6379@16379 slave 5d3e77f6131c6f272576530b23d1cd7592942eec 0 1559628533000 3 connected

127.0.0.1:6379> cluster info

cluster_state:ok

cluster_slots_assigned:16384

cluster_slots_ok:16384

cluster_slots_pfail:0

cluster_slots_fail:0

cluster_known_nodes:6

cluster_size:3

cluster_current_epoch:6

cluster_my_epoch:6

cluster_stats_messages_ping_sent:14910

cluster_stats_messages_pong_sent:15139

cluster_stats_messages_sent:30049

cluster_stats_messages_ping_received:15139

cluster_stats_messages_pong_received:14910

cluster_stats_messages_received:30049

127.0.0.1:6379>
另外,还可以在 NFS 上查看 Redis 挂载的数据:

[root@ftp pv3]# ll /usr/local/k8s/redis/pv3

total 12

-rw-r--r-- 1 root root  92 Jun  4 11:36 appendonly.aof

-rw-r--r-- 1 root root 175 Jun  4 11:36 dump.rdb

-rw-r--r-- 1 root root 794 Jun  4 11:49 nodes.conf
6. 创建用于访问 Service
前面我们创建了用于实现 StatefulSet 的 Headless Service,但该 Service 没有 Cluster Ip,因此不能用于外界访问。所以,我们还需要创建一个 Service,专用于为 Redis 集群提供访问和负载均衡:

cat redis-access-service.yaml

apiVersion: v1

kind: Service

metadata:

  name: redis-access-service

  labels:

    app: redis

spec:

  ports:

  - name: redis-port

    protocol: "TCP"

    port: 6379

    targetPort: 6379

  selector:

    app: redis
如上,该 Service 名称为 redis-access-service,在 K8S 集群中暴露 6379 端口,并且会对 labels name 为 app: redis 或 appCluster: redis-cluster 的 pod 进行负载均衡。

创建后查看:

kubectl get svc redis-access-service -o wide

NAME                   TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE       SELECTOR

redis-access-service   ClusterIP   10.0.0.64    <none>        6379/TCP   2h        app=redis,appCluster=redis-cluster
如上,在 K8S 集群中,所有应用都可以通过 10.0.0.64 :6379 来访问 Redis 集群。当然,为了方便测试,我们也可以为 Service 添加一个 NodePort 映射到物理机上,这里不再详细介绍。


五、测试主从切换

在 K8S 上搭建完好 Redis 集群后,我们最关心的就是其原有的高可用机制是否正常。这里,我们可以任意挑选一个 Master 的 Pod 来测试集群的主从切换机制,如 redis-app-0:


kubectl get pods redis-app-0 -o wide

NAME          READY     STATUS    RESTARTS   AGE       IP            NODE            NOMINATED NODE

redis-app-1   1/1       Running   0          3h        172.17.24.3   192.168.0.144   <none>

进入redis-app-0查看:

kubectl exec -it redis-app-0 /bin/bash

root@redis-app-0:/data# /usr/local/bin/redis-cli -c

127.0.0.1:6379> role

1) "master"

2) (integer) 13370

3) 1) 1) "172.17.63.9"

      2) "6379"

      3) "13370"

127.0.0.1:6379>
如上可以看到,app-0 为 master,slave 为 172.17.63.9 即 redis-app-3。

接着,我们手动删除 redis-app-0:

kubectl delete pod redis-app-0

pod "redis-app-0" deleted

[root@master redis]#  kubectl get pod redis-app-0 -o wide

NAME          READY     STATUS    RESTARTS   AGE       IP            NODE            NOMINATED NODE

redis-app-0   1/1       Running   0          4m        172.17.24.3   192.168.0.144   <none>
我们再进入redis-app-0内部查看:

kubectl exec -it redis-app-0 /bin/bash

root@redis-app-0:/data# /usr/local/bin/redis-cli -c

127.0.0.1:6379> role

1) "slave"

2) "172.17.63.9"

3) (integer) 6379

4) "connected"

5) (integer) 13958
如上,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 文件:


[root@k8s-node2 ~]# cat /usr/local/k8s/redis/pv1/nodes.conf 96689f2018089173e528d3a71c4ef10af68ee462 192.168.169.209:6379@16379 slave d884c4971de9748f99b10d14678d864187a9e5d3 0 1526460952651 4 connected237d46046d9b75a6822f02523ab894928e2300e6 192.168.169.200:6379@16379 slave c15f378a604ee5b200f06cc23e9371cbc04f4559 0 1526460952651 1 connected

c15f378a604ee5b200f06cc23e9371cbc04f4559 192.168.169.197:6379@16379 master - 0 1526460952651 1 connected 10923-16383d884c4971de9748f99b10d14678d864187a9e5d3 192.168.169.205:6379@16379 master - 0 1526460952651 4 connected 5462-10922c3b4ae23c80ffe31b7b34ef29dd6f8d73beaf85f 192.168.169.198:6379@16379 myself,slave c8a8f70b4c29333de6039c47b2f3453ed11fb5c2 0 1526460952565 3 connected

c8a8f70b4c29333de6039c47b2f3453ed11fb5c2 192.168.169.201:6379@16379 master - 0 1526460952651 6 connected 0-5461vars currentEpoch 6 lastVoteEpoch 4
如上,第一列为 NodeId,稳定不变;第二列为 IP 和端口信息,可能会改变。

这里,我们介绍 NodeId 的两种使用场景:

当某个 Slave Pod 断线重连后 IP 改变,但是 Master 发现其 NodeId 依旧, 就认为该 Slave 还是之前的 Slave。

当某个 Master Pod 下线后,集群在其 Slave 中选举重新的 Master。待旧 Master 上线后,集群发现其 NodeId 依旧,会让旧 Master 变成新 Master 的 slave。——————————————————————————————————————————————————

原文链接:https://blog.csdn.net/liangkaiping0525/article/details/125636431 (责任编辑:IT)
------分隔线----------------------------