365bet亚洲版登录-bet官网365入口

365bet亚洲版登录拥有超过百间客房,bet官网365入口的文化历经几十年的传承和积淀形成的核心内容获得业界广泛的认可,365bet亚洲版登录是目前信誉最高的娱乐场所,同国内外几百家网上内容供应商建立了合作关系。

从零开首搭建Kubernetes集群

上一文《从零开首搭建Kubernetes集群(五、搭建K8S Ingress)》重要介绍了如何在K8S上搭建Ingress,以及哪些通过Ingress访谈后端服务。本篇将介绍怎样在K8S上布置Redis集群。注意,这里所说的Redis 集群,指Redis Cluster而非Sentinel情势集群。

下图为Redis集群的架构图,每一种Master都得以具有四个Slave。当Master下线后,Redis集群会从多个Slave中选出出四个新的Master作为代表,而旧Master重新上线后成为新Master的Slave。

图片 1image.png

此番铺排重大依附该品种:

https://github.com/zuxqoj/kubernetes-redis-cluster

其含有了二种配备Redis集群的办法:

  • StatefulSet
  • Service&Deployment

三种格局春兰秋菊,对于像Redis、Mongodb、Zookeeper等有景况的劳动,使用StatefulSet是首荐办法。本文将首要介绍怎么样行使StatefulSet进行Redis集群的安顿。

StatefulSet的概念丰硕首要,轻易的话,其就是为了消除Pod重启、迁移后,Pod的IP、主机名等互连网标志会改造而带来的标题。IP变化对于有气象的劳务是难以承受的,如在Zookeeper集群的布署文件中,各类ZK节点都会记录别的节点的地址新闻:

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

但若某些ZK节点的Pod重启后改动了IP,那么就能够造成该节点脱离集群,而只要该配置文件中不利用IP而利用IP对应的域名,则可防止该难题:

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

相当于说,对于有情形服务,大家最棒利用一定的互联网标志来标识节点,当然那也亟需应用程序的援助(如Zookeeper就帮忙在配备文件中写入主机域名)。

StatefulSet基于Headless Service(即未有Cluster IP的瑟维斯)为Pod实现了平稳的互联网标识(富含Pod的hostname和DNS Records),在Pod重新调解后也维持不变。同一时间,结合PV/PVC,StatefulSet能够完成平稳的长久化存款和储蓄,固然Pod重新调解后,还能够访谈到原本的长久化数据。

下图为运用StatefulSet陈设Redis的架构,无论是Master如故Slave,都看成StatefulSet的二个别本,何况数据通过PV实行长久化,对外揭发为三个Service,接受顾客端央浼。

图片 2image.png

正文参照他事他说加以考察项指标README中,简单介绍了依附StatefulSet的Redis创立步骤:

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

此地,我们将参照如上手续,执行操作并详尽介绍Redis集群的配置进程。文中会波及到比很多K8S的定义,希望大家能提前理解学习。

始建NFS存款和储蓄主如若为了给Redis提供牢固的后端存款和储蓄,当Redis的Pod重启或搬迁后,依然能得到原先的数目。这里,我们先要创设NFS,然后通过利用PV为Redis挂载二个长距离的NFS路线。

安装NFS

出于硬件财富有限,我们得以在k8s-node2上搭建。推行如下命令安装NFS和rpcbind:

yum -y install nfs-utils rpcbind 

里头,NFS依赖远程进程调用在顾客端和服务器端路由诉求,因而须要安装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 rpcbindsystemctl 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

每五个Redis Pod都急需一个独自的PV来囤积本身的数据,由此得以成立二个pv.yaml文件,包含6个PV:

apiVersion: v1kind: PersistentVolumemetadata: name: nfs-pv1spec: capacity: storage: 200M accessModes: - ReadWriteMany nfs: server: 192.168.56.102 path: "/usr/local/k8s/redis/pv1"---apiVersion: v1kind: PersistentVolumemetadata: name: nfs-vp2spec: capacity: storage: 200M accessModes: - ReadWriteMany nfs: server: 192.168.56.102 path: "/usr/local/k8s/redis/pv2"---apiVersion: v1kind: PersistentVolumemetadata: name: nfs-pv3spec: capacity: storage: 200M accessModes: - ReadWriteMany nfs: server: 192.168.56.102 path: "/usr/local/k8s/redis/pv3"---apiVersion: v1kind: PersistentVolumemetadata: name: nfs-pv4spec: capacity: storage: 200M accessModes: - ReadWriteMany nfs: server: 192.168.56.102 path: "/usr/local/k8s/redis/pv4"---apiVersion: v1kind: PersistentVolumemetadata: name: nfs-pv5spec: capacity: storage: 200M accessModes: - ReadWriteMany nfs: server: 192.168.56.102 path: "/usr/local/k8s/redis/pv5"---apiVersion: v1kind: PersistentVolumemetadata: name: nfs-pv6spec: 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" createdpersistentvolume "nfs-pv2" createdpersistentvolume "nfs-pv3" createdpersistentvolume "nfs-pv4" createdpersistentvolume "nfs-pv5" createdpersistentvolume "nfs-pv6" created

此处,大家得以向来将Redis的布置文件转载为Configmap,这是一种更利于的配置读取格局。配置文件redis.conf如下:

appendonly yescluster-enabled yescluster-config-file /var/lib/redis/nodes.confcluster-node-timeout 5000dir /var/lib/redisport 6379

创造名称叫redis-conf的Configmap:

kubectl create configmap redis-conf --from-file=redis.conf

查看:

[root@k8s-node1 redis]# kubectl describe cm redis-confName: redis-confNamespace: defaultLabels: <none>Annotations: <none>Data====redis.conf:----appendonly yescluster-enabled yescluster-config-file /var/lib/redis/nodes.confcluster-node-timeout 5000dir /var/lib/redisport 6379Events: <none>

如上,redis.conf中的全体配置项都保存到redis-conf这个Configmap中。

Headless service是StatefulSet达成平安网络标记的功底,我们供给超前创制。策画文件headless-service.yml如下:

apiVersion: v1kind: Servicemetadata: name: redis-service labels: app: redisspec: 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-serviceNAME TYPE CLUSTER-IP EXTERNAL-IP PORT AGEredis-service ClusterIP None <none> 6379/TCP 53s

能够见见,服务名为redis-service,其CLUSTER-IPNone,表示那是一个“无头”服务。

创设好Headless service后,就能够利用StatefulSet创设Redis 集群节点,那也是本文的宗旨内容。大家先创设redis.yml文件:

apiVersion: apps/v1beta1kind: StatefulSetmetadata: name: redis-appspec: 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节点,其中3个将用以master,其余3个分级作为master的slave;Redis的配备通过volume将在此以前生成的redis-conf其一Configmap,挂载到了容器的/etc/redis/redis.conf;Redis的多寡存款和储蓄路径使用volumeClaimTemplates申明,其会绑定到大家原先开创的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名称)-$,如下图所示:

[root@k8s-node1 redis]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODEdns-test 0/1 Completed 0 52m 192.168.169.208 k8s-node2redis-app-0 1/1 Running 0 1h 192.168.169.207 k8s-node2redis-app-1 1/1 Running 0 1h 192.168.169.197 k8s-node2redis-app-2 1/1 Running 0 1h 192.168.169.198 k8s-node2redis-app-3 1/1 Running 0 1h 192.168.169.205 k8s-node2redis-app-4 1/1 Running 0 1h 192.168.169.200 k8s-node2redis-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域名,格式为$.$(service name).$(namespace).svc.cluster.local,也即是:

redis-app-0.redis-service.default.svc.cluster.localredis-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-serviceServer: 10.96.0.10Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.localName: redis-app-0.redis-serviceAddress 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的域名、S奥迪Q5V records、A record都不会变动。

其余能够窥见,大家前边创立的pv都被成功绑定了:

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

创立好6个Redis Pod后,大家还要求运用常用的Redis-tribe工具进行集群的开始化。

创建Ubuntu容器

鉴于Redis集群必得在享有节点运行后本领打开伊始化,而一旦将起首化逻辑写入Statefulset中,则是一件特别复杂並且不算的一颦一笑。这里,自身不得不表彰一下原项目作者的思绪,值得学习。也正是说,我们得以在K8S上创办一个外加的器皿,特地用来开展K8S集群内部有些服务的管控。

这里,大家特意开发银行三个Ubuntu的容器,能够在该容器中安装Redis-tribe,进而起先化Redis集群,实行:

kubectl run -i --tty ubuntu --image=ubuntu --restart=Never /bin/bash

打响后,我们得以进去ubuntu容器中,原项目需求执行如下命令安装基本的软件条件:

apt-get updateapt-get install -y vim wget python2.7 python-pip redis-tools dnsutils

而是,要求静心的是,在我们天朝,试行上述命令前须要提前做一件必备的办事——换源,不然你通晓。大家运用阿里云的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

源修改达成后,就能够推行下面的七个指令。

最初化集群

率先,大家必要安装redis-trib

pip install redis-trib

然后,创立唯有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

如上,命令dig +short redis-app-0.redis-service.default.svc.cluster.local用来将Pod的域名转化为IP,那是因为redis-trib不帮助域名来创建集群。

其次,为每个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`:6379redis-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`:6379redis-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@k8s-node1 ~]# kubectl exec -it redis-app-2 /bin/bashroot@redis-app-2:/data# /usr/local/bin/redis-cli -c127.0.0.1:6379> cluster nodesc15f378a604ee5b200f06cc23e9371cbc04f4559 192.168.169.197:6379@16379 master - 0 1526454835084 1 connected 10923-1638396689f2018089173e528d3a71c4ef10af68ee462 192.168.169.204:6379@16379 slave d884c4971de9748f99b10d14678d864187a9e5d3 0 1526454836491 4 connectedd884c4971de9748f99b10d14678d864187a9e5d3 192.168.169.199:6379@16379 master - 0 1526454835487 4 connected 5462-10922c3b4ae23c80ffe31b7b34ef29dd6f8d73beaf85f 192.168.169.198:6379@16379 myself,master - 0 1526454835000 3 connected 0-5461c8a8f70b4c29333de6039c47b2f3453ed11fb5c2 192.168.169.201:6379@16379 slave c3b4ae23c80ffe31b7b34ef29dd6f8d73beaf85f 0 1526454836000 3 connected237d46046d9b75a6822f02523ab894928e2300e6 192.168.169.200:6379@16379 slave c15f378a604ee5b200f06cc23e9371cbc04f4559 0 1526454835000 1 connected127.0.0.1:6379> cluster infocluster_state:okcluster_slots_assigned:16384cluster_slots_ok:16384cluster_slots_pfail:0cluster_slots_fail:0cluster_known_nodes:6cluster_size:3cluster_current_epoch:4...省略...

除此以外,仍是能够在NFS上查看Redis挂载的多少:

[root@k8s-node2 ~]# ll /usr/local/k8s/redis/pv3/总用量 8-rw-r--r--. 1 nfsnobody nfsnobody 0 5月 16 15:07 appendonly.aof-rw-r--r--. 1 nfsnobody nfsnobody 175 5月 16 15:07 dump.rdb-rw-r--r--. 1 nfsnobody nfsnobody 817 5月 16 16:55 nodes.conf

前方大家成立了用来落实StatefulSet的Headless Service,但该Service未有Cluster Ip,因而无法用于外部访谈。所以,大家还供给创建三个Service,专项使用于为Redis集群提供访谈和负载均:

piVersion: v1kind: Servicemetadata: name: redis-access-service labels: app: redisspec: ports: - name: redis-port protocol: "TCP" port: 6379 targetPort: 6379 selector: app: redis appCluster: redis-cluster

如上,该Service名称为 redis-access-service,在K8S集群中揭露6379端口,并且会对labels nameapp: redisappCluster: redis-cluster的pod进行负荷均衡。

开创后翻看:

[root@k8s-node1 redis]# kubectl get svc redis-access-service -o wideNAME TYPE CLUSTER-IP EXTERNAL-IP PORT AGE SELECTORredis-access-service ClusterIP 10.105.11.209 <none> 6379/TCP 41m app=redis,appCluster=redis-cluster

如上,在K8S集群中,全数应用都得以由此10.105.11.209:6379来访谈Redis集群。当然,为了便于测量检验,大家也得以为Service增加叁个NodePort映射到物理机上,这里不再详细介绍。

在K8S上搭建完好Redis集群后,我们最关注的正是其原本的高可用机制是或不是正规。这里,大家能够自由采取二个Master的Pod来测量检验集群的中坚切换机制,如redis-app-2

[root@k8s-node1 redis]# kubectl get pods redis-app-2 -o wideNAME READY STATUS RESTARTS AGE IP NODEredis-app-2 1/1 Running 0 2h 192.168.169.198 k8s-node2

进入redis-app-2查看:

[root@k8s-node1 redis]# kubectl exec -it redis-app-2 /bin/bashroot@redis-app-2:/data# /usr/local/bin/redis-cli -c127.0.0.1:6379> role1) "master"2)  86663) 1) 1) "192.168.169.201" 2) "6379" 3) "8666"127.0.0.1:6379>

如上能够见见,其为master,slave为192.168.169.201即redis-app-5`。

紧接着,我们手动删除redis-app-2

[root@k8s-node1 redis]# kubectl delete pods redis-app-2pod "redis-app-2" deleted[root@k8s-node1 redis]# kubectl get pods redis-app-2 -o wideNAME READY STATUS RESTARTS AGE IP NODEredis-app-2 1/1 Running 0 20s 192.168.169.210 k8s-node2

如上,IP改变为192.168.169.210。大家再进来redis-app-2内部查看:

[root@k8s-node1 redis]# kubectl exec -it redis-app-2 /bin/bashroot@redis-app-2:/data# /usr/local/bin/redis-cli -c127.0.0.1:6379> role1) "slave"2) "192.168.169.201"3)  63794) "connected"5)  8960127.0.0.1:6379>

如上,redis-app-2化为了slave,附属于它前边的从节点192.168.169.201redis-app-5

由来,大家恐怕会疑心,前边讲了那般多如同并从未反映出StatefulSet的机能,其提供的安定标记redis-app-*仅在开头化集群的时候利用,而后续Redis Pod的通讯或安排文件中并未动用该标记。我想说,是的,本文使用StatefulSet安顿Redis确实尚未突显出其优势,还不及介绍Zookeeper集群来的明明,可是没什么,学到知识就好。

那为什么未有动用稳固的评释,Redis Pod也能健康开展故障转移呢?那事关了Redis本人的体制。因为,Redis集群中每一种节点都有投机的NodeId(保存在自动生成的nodes.conf中),况且该NodeId不会随着IP的变化和变化,这实在也是一种恒久的网络标识。约等于说,即便有些Redis Pod重启了,该Pod依旧会加载保存的NodeId来维系自身的身份。大家得以在NFS上查看redis-app-1nodes.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 connectedc15f378a604ee5b200f06cc23e9371cbc04f4559 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 connectedc8a8f70b4c29333de6039c47b2f3453ed11fb5c2 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。

对此那三种现象,大家有意思味的话仍是能够活动测验,注意要观看Redis的日记。

到现在,大家的Redis集群就搭建完结了。假设我们有意思味,能够尝试利用Service合营Deployment形式来安顿Redis集群,该格局相对来讲更易于了然。下一章节《从零早先搭建Kubernetes集群(七、如何监察和控制K8S集群的日记)》,敬请期望。

自家水平有限,难免有错误或遗漏之处,望我们指正和谅解,应接商酌留言。

应接关心自小编微信公众号:

图片 3爱你之心.jpg

本文由365bet亚洲版登录发布于计算机网络,转载请注明出处:从零开首搭建Kubernetes集群

您可能还会对下面的文章感兴趣: