从零开始搭建Kubernetes+redis集群

最新推荐文章于 2024-04-23 08:51:41 发布

右归

最新推荐文章于 2024-04-23 08:51:41 发布

阅读量1k

点赞数

本文链接：https://blog.csdn.net/weixin_43808555/article/details/100308203

版权

下图为Redis集群的架构图，每个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简介
StatefulSet的概念非常重要，简单来说，其就是为了解决Pod重启、迁移后，Pod的IP、主机名等网络标识会改变而带来的问题。IP变化对于有状态的服务是难以接受的，如在Zookeeper集群的配置文件中，每个ZK节点都会记录其他节点的地址信息：

tickTime=2000
dataDir=/home/myname/zookeeper
clientPort=2181
initLimit=5
syncLimit=2
server.1=192.168.229.160:2888:3888
server.2=192.168.229.161:2888:3888
server.3=192.168.229.162:2888:3888

但若某个ZK节点的Pod重启后改变了IP，那么就会导致该节点脱离集群，而如果该配置文件中不使用IP而使用IP对应的域名，则可避免该问题：

server.1=zk-node1:2888:3888
server.2=zk-node2:2888:3888
server.3=zk-node3:2888:3888

也即是说，对于有状态服务，我们最好使用固定的网络标识（如域名信息）来标记节点，当然这也需要应用程序的支持（如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集群
1.创建NFS存储
创建NFS存储主要是为了给Redis提供稳定的后端存储，当Redis的Pod重启或迁移后，依然能获得原先的数据。这里，我们先要创建NFS，然后通过使用PV为Redis挂载一个远程的NFS路径。

安装NFS
由于硬件资源有限，我们可以在k8s-node2上搭建。执行如下命令安装NFS和rpcbind：

yum -y install nfs-utils rpcbind
其中，NFS依靠远程过程调用(RPC)在客户端和服务器端路由请求，因此需要安装rpcbind服务。

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

/usr/local/k8s/redis/pv1 *(rw,all_squash)
/usr/local/k8s/redis/pv2 *(rw,all_squash)
/usr/local/k8s/redis/pv3 *(rw,all_squash)
/usr/local/k8s/redis/pv4 *(rw,all_squash)
/usr/local/k8s/redis/pv5 *(rw,all_squash)
/usr/local/k8s/redis/pv6 *(rw,all_squash)

如上，rw表示读写权限；all_squash 表示客户机上的任何用户访问该共享目录时都映射成服务器上的匿名用户（默认为nfsnobody）；*表示任意主机都可以访问该共享目录，也可以填写指定主机地址，同时支持正则，如：

/root/share/ 192.168.1.20 (rw,all_squash)
/home/ljm/ *.gdfs.edu.cn (rw,all_squash)

由于我们打算创建一个6节点的Redis集群，所以共享了6个目录。当然，我们需要在k8s-node2上创建这些路径，并且为每个路径修改权限：

chmod 777 /usr/local/k8s/redis/pv*

这一步必不可少，否则挂载时会出现mount.nfs: access denied by server while mounting的权限错误。

接着，启动NFS和rpcbind服务：

systemctl start rpcbind
systemctl start nfs

我们在k8s-node1上测试一下，执行：

mount -t nfs 192.168.56.102:/usr/local/k8s/redis/pv1 /mnt

表示将k8s-node2上的共享目录/usr/local/k8s/redis/pv1映射为k8s-node1的/mnt目录，我们在/mnt中创建文件：

touch haha

既可以在k8s-node2上看到该文件：

[root@k8s-node2 redis]# ll pv1
总用量 0
-rw-r–r--. 1 nfsnobody nfsnobody 0 5月 2 21:35 haha
可以看到用户和组为nfsnobody。

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

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv1
spec:
  capacity:
    storage: 200M
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.56.102
    path: "/usr/local/k8s/redis/pv1"

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

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

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

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

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv6
spec:
  capacity:
    storage: 200M
  accessModes:
    - ReadWriteMany
  nfs:
    server: 192.168.56.102
    path: "/usr/local/k8s/redis/pv6"

如上，可以看到所有PV除了名称和挂载的路径外都基本一致。执行创建即可：

[root@k8s-node1 redis]# kubectl create -f 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

2.创建Configmap
这里，我们可以直接将Redis的配置文件转化为Configmap，这是一种更方便的配置读取方式。配置文件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
创建名为redis-conf的Configmap：

kubectl create configmap redis-conf --from-file=redis.conf
查看：

[root@k8s-node1 redis]# kubectl describe cm redis-conf
Name: redis-conf
Namespace: default
Labels:
Annotations:

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:
如上，redis.conf中的所有配置项都保存到redis-conf这个Configmap中。

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

apiVersion: v1
kind: Service
metadata:
name: redis-service
labels:
app: redis
spec:
ports:

name: redis-port
port: 6379
clusterIP: None
selector:
app: redis
appCluster: redis-cluster
创建：

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

[root@k8s-node1 redis]# kubectl get svc redis-service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
redis-service ClusterIP None 6379/TCP 53s
可以看到，服务名称为redis-service，其CLUSTER-IP为None，表示这是一个“无头”服务。

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

apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
  name: redis-app
spec:
  serviceName: "redis-service"
  replicas: 6
  template:
    metadata:
      labels:
        app: redis
        appCluster: redis-cluster
    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

如上，总共创建了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会被依次命名为 $(s t a t e f u l s e t 名称) -$ (序号)，如下图所示：

[root@k8s-node1 redis]# kubectl get pods -o wide
NAME          READY     STATUS      RESTARTS   AGE       IP                NODE
dns-test      0/1       Completed   0          52m       192.168.169.208   k8s-node2
redis-app-0   1/1       Running     0          1h        192.168.169.207   k8s-node2
redis-app-1   1/1       Running     0          1h        192.168.169.197   k8s-node2
redis-app-2   1/1       Running     0          1h        192.168.169.198   k8s-node2
redis-app-3   1/1       Running     0          1h        192.168.169.205   k8s-node2
redis-app-4   1/1       Running     0          1h        192.168.169.200   k8s-node2
redis-app-5   1/1       Running     0          1h        192.168.169.201   k8s-node2

如上，可以看到这些Pods在部署时是以{0…N-1}的顺序依次创建的。注意，直到redis-app-0状态启动后达到Running状态之后，redis-app-1 才开始启动。

同时，每个Pod都会得到集群内的一个DNS域名，格式为 $(p o d n a m e) .$ (service name).$(namespace).svc.cluster.local，

也即是：

redis-app-0.redis-service.default.svc.cluster.local
redis-app-1.redis-service.default.svc.cluster.local
…以此类推…
在K8S集群内部，这些Pod就可以利用该域名互相通信。我们可以使用busybox镜像的nslookup检验这些域名：

[root@k8s-node1 ~]# kubectl run -i --tty --image busybox dns-test --restart=Never --rm /bin/sh 
If you don't see a command prompt, try pressing enter.
/ # nslookup redis-app-0.redis-service
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      redis-app-0.redis-service
Address 1: 192.168.169.207 redis-app-0.redis-service.default.svc.cluster.local

可以看到， redis-app-0的IP为192.168.169.207。当然，若Redis Pod迁移或是重启（我们可以手动删除掉一个Redis Pod来测试），则IP是会改变的，但Pod的域名、SRV records、A record都不会改变。

另外可以发现，我们之前创建的pv都被成功绑定了：

[root@k8s-node1 ~]# kubectl get pv
NAME      CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                            STORAGECLASS   REASON    AGE
nfs-pv1   200M       RWX            Retain           Bound     default/redis-data-redis-app-2                            1h
nfs-pv2   200M       RWX            Retain           Bound     default/redis-data-redis-app-3                            1h
nfs-pv3   200M       RWX            Retain           Bound     default/redis-data-redis-app-4                            1h
nfs-pv4   200M       RWX            Retain           Bound     default/redis-data-redis-app-5                            1h
nfs-pv5   200M       RWX            Retain           Bound     default/redis-data-redis-app-0                            1h
nfs-pv6   200M       RWX            Retain           Bound     default/redis-data-redis-app-1                            1h

5.初始化Redis集群
创建好6个Redis Pod后，我们还需要利用常用的Redis-tribe工具进行集群的初始化。
这里网上提到的另外创建一个ubuntu容器，安装Python环境，pip install redis后会自动生成一个redis-trib.py的脚本，然后redis-trib.py create 初始化集群，本人亲测不太好用，初始化过程总会报各种错误，然后还是采取的使用ruby脚本写的redis-trib.rb脚本。
创建容器：
在这里插入图片描述
镜像使用带ruby环境的centos，后续安装脚本会很方便

拷贝redis的源码包，解压，在src目录自带redis-trib.rb脚本

初始化过成功出现一直waiting for the cluster to join 状态，原因是没有开启各节点redis上的16379总线端口，平常在物理机环境安装redis的时候都是直接关闭防火墙和selinux，就不需要这个操作。

右归

关注

0
点赞
踩
5

收藏

觉得还不错? 一键收藏
0
评论
从零开始搭建Kubernetes+redis集群

下图为Redis集群的架构图，每个Master都可以拥有多个Slave。当Master下线后，Redis集群会从多个Slave中选举出一个新的Master作为替代，而旧Master重新上线后变成新Master的Slave。**二、准备操作**在这里插入代码片本次部署主要基于该项目：https://github.com/zuxqoj/kubernetes-redis-cluster其包...
复制链接

扫一扫