|
部署一个多主多从的 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) |