I.はじめに
アーキテクチャの原則：各マスターが複数のスレーブを持つことができます。ときにマスターオフライン、Redisのクラスタは、スレーブの新しいマスターになるために、バックラインの代替として複数のスレーブから新しいマスターを選出し、古いマスターます。
第二に、操作の準備
この展開のは、主にプロジェクトに基づいています。
https://github.com/zuxqoj/kubernetes-redis-cluster
これは、2つの展開Redisのクラスタの方法が含まれています。
StatefulSet
サービス＆展開
二つの方法がStatefulSetが好ましい方法で使用して、ステートフルとしてのRedis、MongoDBの、飼育係のようなサービスのために、長所と短所を持っています。この記事ではStatefulSet展開Redisのクラスタを使用する方法について説明します。
三、StatefulSetプロファイル
RC、展開、DaemonSetはステートレスサービスのためのものである、彼らはなど、オーダーの開始と停止、IPのポッド、名前を管理ランダムであるが、何がそれをStatefulSet？名前が示すように、状態の集合があり、あなたは、このようなので、上のMySQL、MongoDBのクラスターとなど、すべての状態のサービスを、管理する必要があります。
StatefulSetでの展開のバリエーションがGAバージョンv1.9デベロッパー版となっている本質的である、それは国家のサービスの問題を解決するために持っている、それは順序の開始と停止、ポッドポッドは一定の名前を持って管理し、StatefulSet中でネットワーク識別（ホスト名）と呼ばれるポッド名は、また、共有ストレージを使用する必要があります。
展開では、対応するサービスは、対応するStatefulSetに、ヘッドレスサービス、ヘッドレスサービス、すなわち、ヘッドレスサービスのサービスであり、サービスは、ヘッドレスを解析その名前が返され、クラスタIPを区別しないことですサービスのすべてに対応するポッドのエンドポイントの一覧。
また、基礎のヘッドレスサービスのStatefulSetは、各ポッドのDNSドメイン名を作成しているこのドメインのStatefulSet制御形式はコピーします。
$(podname).(headless server name)
FQDN： $(podname).(headless server name).namespace.svc.cluster.local
これは、状態サービスはもちろんのノードを、マークする（例えば、ドメイン情報など）当社の固定ネットワークアイデンティティを最大限に活用するために、これはまた、アプリケーション・サポート・プログラムを（飼育係は、設定ファイルにホストドメイン名をサポートするために書かれているなど）が必要です。
StatefulSetベースのヘッドレスサービス（サービスのつまりがないクラスタIP）は、ポッドが再スケジュール後も変わらない、（ポッドのホスト名とDNSレコードを含む）の安定ポッドのロゴを達成することです。一方で、と併せてPV / PVC、ポッド、オリジナルまたは永続的なデータへのアクセスを再スケジュールした後でも、安定した永続ストレージを実現するためにStatefulSet可能。
以下は、外国のサービスとして公開され、持続性のためのPVのいずれかを介して、使用RedisのStatefulSet展開アーキテクチャであるマスタまたはスレーブ、コピーStatefulSetの両方、およびデータ、クライアントの要求を受け入れます。
第四に、展開プロセス
のRedisのStatefulSetに基づいて作成するために、参照プロジェクト、手順を簡単に説明することにより本明細書にREADME：
1. NFSストレージ作成
作成PV 2.
PVCの作成3.
ConfigMapの作成4.
サービスレス5.作成
StatefulSet Redisの作成6.
7を初期化クラスタのRedis
ここでは、私は上記の手順、ハンズオンと細部への展開プロセスRedisのクラスタを参照します。本論文では、事前に私たちが知っていることを学ぶことができ、希望の多くの概念のK8Sを伴います
1. NFSストレージを作成
ポッドRedisの再起動または移行するときのRedisは、安定したバックエンドストレージを提供与える主にNFSストレージを作成するために、まだ元のデータを得ることができました。ここでは、NFSを作成し、PVを使用して、リモートNFSパスのRedisをマウントする必要があります。
NFSのインストール
yum -y install nfs-utils（主包提供文件系统）
yum -y install rpcbind（提供rpc协议）
次に、共有パスの必要性を設定し、/ etc / exportsファイルを追加します。
[root@ftp pv3]# cat /etc/exports
/usr/local/k8s/redis/pv1 192.168.0.0/24(rw,sync,no_root_squash)
/usr/local/k8s/redis/pv2 192.168.0.0/24(rw,sync,no_root_squash)
/usr/local/k8s/redis/pv3 192.168.0.0/24(rw,sync,no_root_squash)
/usr/local/k8s/redis/pv4 192.168.0.0/24(rw,sync,no_root_squash)
/usr/local/k8s/redis/pv5 192.168.0.0/24(rw,sync,no_root_squash)
/usr/local/k8s/redis/pv6 192.168.0.0/24(rw,sync,no_root_squash)
適切なディレクトリを作成します。
[root@ftp quizii]# mkdir -p /usr/local/k8s/redis/pv{1..6}
その後、NFSとrpcbindのサービスを開始します。
systemctl restart rpcbind
systemctl restart nfs
systemctl enable nfs
[root@ftp pv3]# exportfs -v
/usr/local/k8s/redis/pv1
192.168.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/usr/local/k8s/redis/pv2
192.168.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/usr/local/k8s/redis/pv3
192.168.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/usr/local/k8s/redis/pv4
192.168.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/usr/local/k8s/redis/pv5
192.168.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
/usr/local/k8s/redis/pv6
192.168.0.0/24(sync,wdelay,hide,no_subtree_check,sec=sys,rw,secure,no_root_squash,no_all_squash)
クライアント
yum -y install nfs-utils
ビューの共有ストレージ・エンド
[root@node2 ~]# showmount -e 192.168.0.222
Export list for 192.168.0.222:
/usr/local/k8s/redis/pv6 192.168.0.0/24
/usr/local/k8s/redis/pv5 192.168.0.0/24
/usr/local/k8s/redis/pv4 192.168.0.0/24
/usr/local/k8s/redis/pv3 192.168.0.0/24
/usr/local/k8s/redis/pv2 192.168.0.0/24
/usr/local/k8s/redis/pv1 192.168.0.0/24
PVを作成し
、それぞれのRedisポッドが自分のデータを格納するために別のPVを必要とするので、あなたは、6曲のPVが含まれているpv.yamlファイルを作成することができます。
[root@master redis]# cat pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv1
spec:
capacity:
storage: 200M
accessModes:
- ReadWriteMany
nfs:
server: 192.168.0.222
path: "/usr/local/k8s/redis/pv1"
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-vp2
spec:
capacity:
storage: 200M
accessModes:
- ReadWriteMany
nfs:
server: 192.168.0.222
path: "/usr/local/k8s/redis/pv2"
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv3
spec:
capacity:
storage: 200M
accessModes:
- ReadWriteMany
nfs:
server: 192.168.0.222
path: "/usr/local/k8s/redis/pv3"
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv4
spec:
capacity:
storage: 200M
accessModes:
- ReadWriteMany
nfs:
server: 192.168.0.222
path: "/usr/local/k8s/redis/pv4"
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv5
spec:
capacity:
storage: 200M
accessModes:
- ReadWriteMany
nfs:
server: 192.168.0.222
path: "/usr/local/k8s/redis/pv5"
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfs-pv6
spec:
capacity:
storage: 200M
accessModes:
- ReadWriteMany
nfs:
server: 192.168.0.222
path: "/usr/local/k8s/redis/pv6"
PVを見ることができるようにマウントの名前とパスを除くすべての基本的に同じです。実行するために作成されました：
[root@master 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を作成し
、ここで、私たちは直接Configmap用Redisのプロファイルを変換することができ、これは読んで設定するには、より便利な方法です。プロフィールredis.confは、以下の
[root@master redis]# cat 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
のConfigmapという名前のRedis-confの作成：
kubectl create configmap redis-conf --from-file=redis.conf
ビュー作成configmap：
[root@master redis]# 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にConfigmapに保存されredis.confすべての構成要素。
3.サービスヘッドレス作成
ヘッドレスサービスを基盤StatefulSet安定したネットワークのアイデンティティである、私たちは事前に作成する必要があります。以下のようにファイルのヘッドレス・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
appCluster: redis-cluster
初出：
kubectl create -f headless-service.yml
表示：
あなたは、これは「ヘッドレス」サービスであることを、Noneに、サービス名はRedisのサービスですが、そのCLUSTER-IPを見ることができます。
Redisのクラスタノードを作成します。4.
ヘッドレスサービスを作成した後、RedisのStatefulSetは、この記事の核心内容であるクラスタ・ノードを作成することができます。私たちは、redis.ymlファイルを作成します。
[root@master redis]# cat redis.yaml
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
上記のように、3つのマスターのために使用される6つのRedisの作成ノード（POD）の合計は、他の三つのスレーブマスタとして使用した。Redisの構成が以前にこのボリュームのRedis-confにConfigMapによって生成された、容器に取り付けられました我々は以前に作成したPVに特異的に結合volumeClaimTemplatesステートメントを使用して/etc/redis/redis.conf;Redisデータ・ストレージ・パス（すなわちPVC）、。
--Affinityは、更なる詳細については、公式ドキュメントを参照してください。重要な概念があります。podAntiAffinityは、サービス自体の安定性を向上させる、ポッドを決定し、ポッド、PODが異なるホストまたはドメイントポロジでサービスを分散させるために使用することができる同じトポロジードメインにデプロイすることができない抗親和性を、発現され、 。
そしてPreferredDuringSchedulingIgnoredDuringExecutionは、スケジューリングの際に、ルールが満たされない場合、PODは、対応するホストにスケジュールすることも、親和性または非アフィニティルールを満たすためにしようとする、と述べました。後に実行するプロセスでは、システムは、それらの規則を満たしているかどうかをチェックしません。
ここでは、スケジュールのMatchExpressionsしないようにしようとするRedisのポッドを提供してアプリにも再配布Redisのポッドは、ノードのRedisの上にすでに存在していると言うしないようにしようノードRedisの上で含まれています。我々は3つしかノードを持ち、そしてコピーは6を持っているので、PreferredDuringSchedulingIgnoredDuringExecutionによると、これらの豆は絞るものではないので、しかし、スクイズは〜より健康絞る
RedisのStatefulSetの、6ポッド私たちの世代のホスト名は、意志の規則に従って、さらに、それが順次指定され$(statefulset名称)-$(序号)、以下に示すとおり
[root@master redis]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE
redis-app-0 1/1 Running 0 2h 172.17.24.3 192.168.0.144 <none>
redis-app-1 1/1 Running 0 2h 172.17.63.8 192.168.0.148 <none>
redis-app-2 1/1 Running 0 2h 172.17.24.8 192.168.0.144 <none>
redis-app-3 1/1 Running 0 2h 172.17.63.9 192.168.0.148 <none>
redis-app-4 1/1 Running 0 2h 172.17.24.9 192.168.0.144 <none>
redis-app-5 1/1 Running 0 2h 172.17.63.10 192.168.0.148 <none>
これらのポッド展開シーケンスに見られるようである{0 ... N-1}を順次作成されます。Redisのアプリ-0を開始した後の状態の後の状態を実行達するまで、Redisのアプリ-1が開始されたことに注意してください。
同時に、各ポッドは形式で、クラスタ内の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
...以此类推...
ドメインポッドを使用することができ、クラスタ内のK8Sは、互いに通信します。私たちは、busyboxのミラーリングnslookupをテストこれらのドメインを使用することができます。
[root@master redis]# kubectl exec -ti busybox -- nslookup redis-app-0.redis-service
Server: 10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local
Name: redis-app-0.redis-service
Address 1: 172.17.24.3
あなたは、Redisのアプリ-0のIPが172.17.24.3で見ることができます。Redisのポッドの移行や再起動が（私たちは、Redisのポッドをテストするために手動で削除することができます）場合はもちろん、IPも変更されません（おそらく理由StatefulSetに基づいて）、ポッドドメイン、SRVレコード、レコードは変更されません。
また、見つけることができ、我々は以前に作成したPVが正常にバインドされました：
[root@master redis]# 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 3h
nfs-pv3 200M RWX Retain Bound default/redis-data-redis-app-4 3h
nfs-pv4 200M RWX Retain Bound default/redis-data-redis-app-5 3h
nfs-pv5 200M RWX Retain Bound default/redis-data-redis-app-1 3h
nfs-pv6 200M RWX Retain Bound default/redis-data-redis-app-0 3h
nfs-vp2 200M RWX Retain Bound default/redis-data-redis-app-3 3h
5.初期化Redisのクラスタ
あなたは6 Redisのポッドを作成したら、我々はまた、Redisの部族クラスタの初期化、共通のツールを使用する必要があります
Ubuntuは、コンテナの作成
Redisのクラスタに起因するを開始するために、すべてのノードの後に初期化する必要がありますが、初期化ロジックがStatefulsetで書かれている場合、それは非常に複雑で非効率的な動作です。ここで、私は学習の価値が元のプロジェクトのアイデアの著者を賞賛する必要があります。言い換えれば、我々はK8S上の追加の容器、専用のクラスタ管理制御内部K8S特定のサービスを作成することができます。
ここでは、Ubuntuは、あなたがコンテナにRedisの部族をインストールし、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
次に、クラスタの唯一のマスターノードを作成します。
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
第二に、それぞれがスレーブマスターを追加します
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のポッドのいずれかにそれをテストします。
[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>
また、あなたはまた、Redisの中のデータは、NFSにマウント表示することができます。
[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.にアクセスするためのサービスを作成し
、我々はStatefulSetヘッドレスサービスを実現するために作成したフロントではなく、サービスクラスタIPので、アクセスの外で使用することはできません。したがって、我々はまた、クラスタRedisのためのバランスのアクセスと負荷を提供することに専念してサービスを作成する必要があります。
[root@master 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
appCluster: redis-cluster
上記のように、サービス名redis-access-service、K8Sクラスタにさらさポート6379、およびだろうlabels nameにapp: redis、またはappCluster: redis-clusterポッドをロードバランシング。
あなたの後のビューを作成します。
[root@master redis]# 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 :6379Redisのクラスタにアクセスします。もちろん、テストを容易にするために、我々はまた、NodePortサービスを追加することができ、ここで詳細に説明していない、物理マシンにマッピングされます。
第五に、からテストマスタースイッチ
K8S上の建物そのままRedisのクラスタは、我々はその元の高可用性メカニズムが正常である最も懸念しています。ここでは、任意のような、切り替え機構をテストするために、ポッドからの主クラスタのマスターを選ぶことができますredis-app-0：
[root@master redis]# 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ビュー：
[root@master redis]# 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マスタとして、スレーブである172.17.63.9、すなわちredis-app-3。
私たちは、その後、手動で削除しますredis-app-0：
[root@master redis]# 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内部ビューを：
[root@master redis]# 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奴隷に、それは前のノードに従属する172.17.63.9、すなわちredis-app-3。