Redisクラスタ を OpenShift on IBM Cloud にデプロイした結果

OpenShift 3.11 が IBM Cloud の東京リージョンで利用できるようになったので、早速、試してみた結果である。
これは「[Redisクラスタをマルチゾーン上のKubernetesで構築する時の考慮点](https://qiita.com/MahoTakara/items/dece9d0d4fd4094a3bc4?fbclid=IwAR0Zpk-FP-_Kpu7pOQUmwkaNmNeGzcsUXxFyMNyye_mk84hrFroKuu46Vno)」で構築したRedisクラスタと同じマニフェストを使って、OpenShift on IBM Cloud で再構築したものである。

ここでは、IBM Cloud の OpenShift を「IKS-OS」と表し、従来からのCNCFのコードにIBMが機能を追加したKubernetesを「IKS-K8s」と表して区別する。


**IKSは、Kubernetesクラスターを作成する際にPure Kubernetes か OpenShiftを選べる**
![K8s_and_OS.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42829/aa47f12a-beb4-4ced-983b-974fdc3c5177.png)
(2019年8月7日現在)



## ブラウザ画面のガイドに従って、OpenShiftのクラスタを起動

https://cloud.ibm.com/ の左上のハンバーガーメニューから Kubernetesを選んで、クラスタを作成する。 入り口によって、途中、画面の表示が少し違うが、最終的にはIKS-K8sとIKS-OSのクラスタは、同じIKSクラスタのリストの中で管理される。


以下のIKS-OSのクラスタ作成のパラメータで、東京リージョンの３つのゾーンに各1つのワーカーノードが起動する。なお、ワーカーノードは選択可能な最小（最安）のノードである。


* プランの選択: 標準
* クラスターのタイプおよびバージョン: OpenShift, バージョン3.11
* 環境の選択: クラシック・インフラストラクチャー
* クラスター名: oc2
* リソース・グループ: default
* リージョン: Asia Pacific
* 可用性: 複数ゾーン
* メトロ: Tokyo
* ワーカーゾーン: TOK02,TOK04,TOK05
* マスター・サービス・エンドポイント: パブリック・エンドポイントのみ
* フレーバー: 4 vCPUs 16GB RAM （一番安いタイプ）
* ワーカーノード: 1

入力の確認が終わったら、「クラスターの作成」をクリックして、プロビジョニングを開始する。

次はプロビジョニング中の画面で、OpenShiftのクラスタのデプロイ進行中の画面である。IKS-K8sとIKS-OSについて、一つのリストで確認できる。 共にワーカーノードやネットワーク基盤は、同じなので、ワーカーノードに付与されるラベルなども同じである。

![IKS-Cluster-List.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/42829/1c9e61f5-8ca8-6029-37ba-b39925ed44fe.png)


## OpenShift CLI をダウンロードして、実行形式のファイルを /usr/local/bin などに置く

前述のIKSクラスターのリストが表示されたページからOpenShiftのクラスタ名をクリックして「概要ページ」を表示する。次に「アクセス」タブに切り替えると、OpenShift CLI のダウンロードとインストールなどのガイドが表示される。これらを参考にして、ocコマンド、kubecltコマンドをダウンロードして、K8sクラスタへアクセスできるようにする。 


## OpenShift のバージョンの確認

ocコマンドで、IKS-OSのバージョンを表示すると、OpennShiftは v3.11であり、Kubernetesは、v1.11 であった。少し古いバージョンだが、その内、OpenShift4が利用できるようなると思う。 Red Hatからは、既にアナウンス済み。

~~~
$ ./oc version
oc v3.11.0+0cbc58b
kubernetes v1.11.0+d4cacc0
features: Basic-Auth

Server https://c100-e.jp-tok.containers.cloud.ibm.com:31303
openshift v3.11.129
kubernetes v1.11.0+d4cacc0
~~~

IBM Cloud に対しては、本年秋に OpenShift バージョン4.1.3 をリリースといったRed Hatのアナウンスもあったが、バージョン3で、前倒してリリースされたと思われる。



## OpenShift CLI でログイン 

IBM Cloud Kubernetes サービスのページ右上のドロップダウン・メニューから「Copy Login Command」をクリックする。これによってコピーされたコマンドをご使用のローカル端末に貼り付ける。

~~~
oc login https://c100-e.jp-tok.containers.cloud.ibm.com:31303 --token=****
~~~

これで、OpenShift独自の ocコマンドと OpenShift拡張を含む kubectlコマンドが利用できる。


## OpenShift クラスタノード

ocコマンドでログインした後は、CNCFからダウンロードした kubectl コマンドでも操作可能になる。
もちろん、ocコマンドと一緒にダウンロードした kubectl コマンドも利用できる。 

~~~
$ kubectl get node
NAME            STATUS   ROLES           AGE   VERSION
10.192.57.169   Ready    compute,infra   1h    v1.11.0+d4cacc0
10.193.10.30    Ready    compute,infra   1h    v1.11.0+d4cacc0
10.212.5.229    Ready    compute,infra   1h    v1.11.0+d4cacc0
~~~

kubectlコマンで、ノードに付与されるラベルを確認した。
その結果、IKS-OSのラベルは、IKS-K8sクラスタに付与されるラベルと、ほとんど同じであった。

~~~
$ kubectl get node 10.192.57.169 --show-labels
NAME            STATUS   ROLES           AGE   VERSION           LABELS
10.192.57.169   Ready    compute,infra   1h    v1.11.0+d4cacc0   arch=amd64,beta.kubernetes.io/arch=amd64,beta.kubernetes.io/instance-type=b3c.4x16.encrypted,beta.kubernetes.io/os=linux,failure-domain.beta.kubernetes.io/region=jp-tok,failure-domain.beta.kubernetes.io/zone=tok04,ibm-cloud.kubernetes.io/encrypted-docker-data=true,ibm-cloud.kubernetes.io/iaas-provider=softlayer,ibm-cloud.kubernetes.io/machine-type=b3c.4x16.encrypted,ibm-cloud.kubernetes.io/os=REDHAT_7_64,ibm-cloud.kubernetes.io/sgx-enabled=false,ibm-cloud.kubernetes.io/worker-pool-id=bl41kgpt0avcc1hclqvg-94ad437,ibm-cloud.kubernetes.io/worker-pool-name=default,ibm-cloud.kubernetes.io/worker-version=3.11.129_1518_openshift,kubernetes.io/hostname=10.192.57.169,node-role.kubernetes.io/compute=true,node-role.kubernetes.io/infra=true,privateVLAN=2678050,publicVLAN=2678048
~~~

## Redisクラスタのデプロイ

Redisクラスタのマニフェストは、https://github.com/takara9/redis-cluster/tree/master/iks-mzr-tok-multi-pod に置いてある。ocコマンドでも良いが、kubectlコマンドで、マニフェストを順番に適用していく。

~~~
# コンフィグマップとサービスをデプロイ
$ kubectl apply -f redis-configmap.yml
configmap/redis-cluster created
$ kubectl apply -f redis-service.yml
service/redis-cluster created

# Redisクラスタの ２つのゾーンにデプロイする 
$ kubectl apply -f redis-cluster-mzr-1m.yml  # ゾーン tok05
statefulset.apps/redis-cluster-1 created
$ kubectl apply -f redis-cluster-mzr-2m.yml  # ゾーン tok04
statefulset.apps/redis-cluster-2 created
~~~

次は、デプロイしたステートフルセット・コントローラーと、それから起動されたポッドのリストである。

~~~
$ kubectl get sts
NAME              DESIRED   CURRENT   AGE
redis-cluster-1   3         3         8m
redis-cluster-2   3         3         8m

$ kubectl get po -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE        
docker-registry-687f78dcbc-j9bg2    1/1     Running   0          34m   172.30.12.82     10.212.5.229
docker-registry-687f78dcbc-rc5rq    1/1     Running   0          34m   172.30.12.83     10.212.5.229
redis-cluster-1-0                   1/1     Running   0          8m    172.30.25.76     10.193.10.30
redis-cluster-1-1                   1/1     Running   0          5m    172.30.25.77     10.193.10.30
redis-cluster-1-2                   1/1     Running   0          3m    172.30.25.78     10.193.10.30
redis-cluster-2-0                   1/1     Running   0          8m    172.30.225.140   10.192.57.169
redis-cluster-2-1                   1/1     Running   0          5m    172.30.225.141   10.192.57.169
redis-cluster-2-2                   1/1     Running   0          3m    172.30.225.142   10.192.57.169 
registry-console-68f6b4d97d-ldx28   1/1     Running   0          18m   172.30.25.72     10.193.10.30
router-6c87d74c7-cx8h7              1/1     Running   0          24m   172.30.25.67     10.193.10.30
router-6c87d74c7-wmd48              1/1     Running   0          23m   172.30.225.132   10.192.57.169
~~~

永続ボリューム要求を確認すると、IKS-K8sでは、ファイルストレージがマウントされていたが、IKS-OSでは、ブロックストレージがマウントされた。しかし、最小サイズは、エンデュランス・ストレージの最小サイズと同じ20GBであり、マニフェストに、最小サイズより小さな値を設定しても、切り上げられる。

~~~
$ kubectl get pvc
NAME                     STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
data-redis-cluster-1-0   Bound    pvc-5efec0e9-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   9m
data-redis-cluster-1-1   Bound    pvc-d10c1e03-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   5m
data-redis-cluster-1-2   Bound    pvc-2a08d554-b77e-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   3m
data-redis-cluster-2-0   Bound    pvc-61ed461c-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   8m
data-redis-cluster-2-1   Bound    pvc-d31ce74f-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   5m
data-redis-cluster-2-2   Bound    pvc-2d2a63fc-b77e-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   3m
registry-backing         Bound    pvc-d3f12c0b-b779-11e9-8384-926f70939424   20Gi       RWX            ibmc-file-bronze    34m
~~~

ストレージクラスをリストすると、IKS-OSでは、最初からブロックストレージのストレージクラスが作られていることが解った。

~~~
$ kubectl get sc
NAME                          PROVISIONER         AGE
default                       ibm.io/ibmc-file    42m
ibmc-block-bronze (default)   ibm.io/ibmc-block   42m
ibmc-block-custom             ibm.io/ibmc-block   42m
ibmc-block-gold               ibm.io/ibmc-block   42m
ibmc-block-retain-bronze      ibm.io/ibmc-block   42m
ibmc-block-retain-custom      ibm.io/ibmc-block   42m
ibmc-block-retain-gold        ibm.io/ibmc-block   42m
ibmc-block-retain-silver      ibm.io/ibmc-block   42m
ibmc-block-silver             ibm.io/ibmc-block   42m
ibmc-file-bronze              ibm.io/ibmc-file    42m
ibmc-file-custom              ibm.io/ibmc-file    42m
ibmc-file-gold                ibm.io/ibmc-file    42m
ibmc-file-retain-bronze       ibm.io/ibmc-file    42m
ibmc-file-retain-custom       ibm.io/ibmc-file    42m
ibmc-file-retain-gold         ibm.io/ibmc-file    42m
ibmc-file-retain-silver       ibm.io/ibmc-file    42m
ibmc-file-silver              ibm.io/ibmc-file    42m
~~~



## Redisクラスタのセットアップ

Redisのポッドの一つで、コマンドを実行して、レプリカ数=1 のRedisクラスタを構成する。

~~~
$ kubectl exec -it redis-cluster-1-0 -- redis-cli --cluster create --cluster-replicas 1 $(kubectl get pods -l 'app=redis-cluster' -o jsonpath='{range.items[*]}{.status.podIP}:6379 ')
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 172.30.225.141:6379 to 172.30.25.76:6379
Adding replica 172.30.225.142:6379 to 172.30.25.77:6379
Adding replica 172.30.225.140:6379 to 172.30.25.78:6379
<中略>
>>> Check slots coverage...
[OK] All 16384 slots covered.
~~~


これにより、Redisクラスタのノードに、Redisマスターとスレーブが構成された。

~~~
$ kubectl exec redis-cluster-1-0 -- redis-cli -c cluster nodes 
80793e3e94ae6c6104c0640d6d18e6f4651a9ba2 172.30.225.141:6379@16379 slave af19887c54c6fb939f8933ee52dcdd57b291b445 0 1565009196000 5 connected
62bcb121ed1d4985023eaef668794d20f9d13c60 172.30.225.140:6379@16379 slave a1126752c3d832ec244e3823324080f79529f805 0 1565009196000 4 connected
9df2f8604a47edabe5d38e908fadcb600021442a 172.30.225.142:6379@16379 slave 34bbfdcd3b15e3c008d161be59c968f4825b0bc6 0 1565009197628 6 connected
a1126752c3d832ec244e3823324080f79529f805 172.30.25.78:6379@16379 master - 0 1565009197000 3 connected 10923-16383
34bbfdcd3b15e3c008d161be59c968f4825b0bc6 172.30.25.77:6379@16379 master - 0 1565009198629 2 connected 5461-10922
af19887c54c6fb939f8933ee52dcdd57b291b445 172.30.25.76:6379@16379 myself,master - 0 1565009198000 1 connected 0-5460
~~~

3番目のゾーンに、ステートフルセットをデプロイする。

~~~
$ kubectl apply -f redis-cluster-mzr-3m.yml
statefulset.apps/redis-cluster-3 created
~~~

次のリストのNODE列は、K8sノードの名前であり、IKS-K8sとIKS-OSは同じように、プライベートIPアドレスが付与されている。
OpenShiftには、Dockerレジストリとそのコンソール、そして、ルーターのポッドが起動していることが読み取れる。

~~~
$ kubectl get po -o wide
NAME                                READY   STATUS    RESTARTS   AGE   IP               NODE        
docker-registry-687f78dcbc-j9bg2    1/1     Running   0          46m   172.30.12.82     10.212.5.229
docker-registry-687f78dcbc-rc5rq    1/1     Running   0          46m   172.30.12.83     10.212.5.229
redis-cluster-1-0                   1/1     Running   0          21m   172.30.25.76     10.193.10.30
redis-cluster-1-1                   1/1     Running   0          18m   172.30.25.77     10.193.10.30
redis-cluster-1-2                   1/1     Running   0          15m   172.30.25.78     10.193.10.30
redis-cluster-2-0                   1/1     Running   0          21m   172.30.225.140   10.192.57.169
redis-cluster-2-1                   1/1     Running   0          18m   172.30.225.141   10.192.57.169
redis-cluster-2-2                   1/1     Running   0          15m   172.30.225.142   10.192.57.169
redis-cluster-3-0                   1/1     Running   0          8m    172.30.12.87     10.212.5.229
redis-cluster-3-1                   1/1     Running   0          4m    172.30.12.88     10.212.5.229
redis-cluster-3-2                   0/1     Running   0          2m    172.30.12.89     10.212.5.229
registry-console-68f6b4d97d-ldx28   1/1     Running   0          31m   172.30.25.72     10.193.10.30
router-6c87d74c7-cx8h7              1/1     Running   0          36m   172.30.25.67     10.193.10.30
router-6c87d74c7-wmd48              1/1     Running   0          35m   172.30.225.132   10.192.57.169
~~~


3番目のゾーンのポッドに、Redisスレーブを設定する。

~~~
$ kubectl exec redis-cluster-1-0 -- redis-cli --cluster add-node --cluster-slave --cluster-master-id af19887c54c6fb939f8933ee52dcdd57b291b445 $(kubectl get pod redis-cluster-3-0 -o jsonpath='{.status.podIP}'):6379  $(kubectl get pod redis-cluster-1-0 -o jsonpath='{.status.podIP}'):6379
>>> Adding node 172.30.12.87:6379 to cluster 172.30.25.76:6379
>>> Performing Cluster Check (using node 172.30.25.76:6379)
>>> Configure node as replica of 172.30.25.76:6379.
<中略>
[OK] New node added correctly.
~~~

~~~
$ kubectl exec redis-cluster-1-0 -- redis-cli --cluster add-node --cluster-slave --cluster-master-id 34bbfdcd3b15e3c008d161be59c968f4825b0bc6 $(kubectl get pod redis-cluster-3-1 -o jsonpath='{.status.podIP}'):6379  $(kubectl get pod redis-cluster-1-0 -o jsonpath='{.status.podIP}'):6379
>>> Adding node 172.30.12.88:6379 to cluster 172.30.25.76:6379
>>> Performing Cluster Check (using node 172.30.25.76:6379)
<中略>
[OK] New node added correctly.
~~~

~~~
$ kubectl exec redis-cluster-1-0 -- redis-cli --cluster add-node --cluster-slave --cluster-master-id a1126752c3d832ec244e3823324080f79529f805 $(kubectl get pod redis-cluster-3-2 -o jsonpath='{.status.podIP}'):6379  $(kubectl get pod redis-cluster-1-0 -o jsonpath='{.status.podIP}'):6379
>>> Adding node 172.30.12.89:6379 to cluster 172.30.25.76:6379
>>> Performing Cluster Check (using node 172.30.25.76:6379)
<中略>
[OK] New node added correctly.
~~~


スレーブが追加され、機能していることを確認する。この時点は、一番目のゾーンにRedisマスターが集中している。

~~~
$ kubectl exec redis-cluster-1-0 -- redis-cli -c cluster nodes
750622a1530ba5863bbd741a76be315056aaf4f5 172.30.12.87:6379@16379 slave af19887c54c6fb939f8933ee52dcdd57b291b445 0 1565010049287 1 connected
80793e3e94ae6c6104c0640d6d18e6f4651a9ba2 172.30.225.141:6379@16379 slave af19887c54c6fb939f8933ee52dcdd57b291b445 0 1565010046778 5 connected
62bcb121ed1d4985023eaef668794d20f9d13c60 172.30.225.140:6379@16379 slave a1126752c3d832ec244e3823324080f79529f805 0 1565010044000 4 connected
9df2f8604a47edabe5d38e908fadcb600021442a 172.30.225.142:6379@16379 slave 34bbfdcd3b15e3c008d161be59c968f4825b0bc6 0 1565010047000 6 connected
13c6f1ba8b6704ecf2757ce0b356c3a3cb1d835d 172.30.12.88:6379@16379 slave 34bbfdcd3b15e3c008d161be59c968f4825b0bc6 0 1565010048284 2 connected
4adaf2831b39f6cea0aaee0af1d3a8aa0b8e397f 172.30.12.89:6379@16379 slave a1126752c3d832ec244e3823324080f79529f805 0 1565010045000 3 connected
a1126752c3d832ec244e3823324080f79529f805 172.30.25.78:6379@16379 master - 0 1565010047278 3 connected 10923-16383
34bbfdcd3b15e3c008d161be59c968f4825b0bc6 172.30.25.77:6379@16379 master - 0 1565010047000 2 connected 5461-10922
af19887c54c6fb939f8933ee52dcdd57b291b445 172.30.25.76:6379@16379 myself,master - 0 1565010046000 1 connected 0-5460
~~~

Redisマスターの位置を調整して、3つのゾーンに分散させる。

~~~
$ kubectl exec -it redis-cluster-2-1 -- redis-cli -c cluster failover 
OK
$ kubectl exec -it redis-cluster-3-2 -- redis-cli -c cluster failover 
OK
~~~

Redisマスターが3つのゾーンに分散したことを確認する。IPアドレスからポッドが特定でき、そのゾーンを辿ることができる。下記の結果から、それぞれのゾーンにRedisマスターが配置されたことが、読み取れる。

~~~
$ kubectl exec -it redis-cluster-1-0 -- redis-cli -c cluster nodes
750622a1530ba5863bbd741a76be315056aaf4f5 172.30.12.87:6379@16379 slave 80793e3e94ae6c6104c0640d6d18e6f4651a9ba2 0 1565010143000 7 connected
80793e3e94ae6c6104c0640d6d18e6f4651a9ba2 172.30.225.141:6379@16379 master - 0 1565010142000 7 connected 0-5460
62bcb121ed1d4985023eaef668794d20f9d13c60 172.30.225.140:6379@16379 slave 4adaf2831b39f6cea0aaee0af1d3a8aa0b8e397f 0 1565010146650 8 connected
9df2f8604a47edabe5d38e908fadcb600021442a 172.30.225.142:6379@16379 slave 34bbfdcd3b15e3c008d161be59c968f4825b0bc6 0 1565010144645 6 connected
13c6f1ba8b6704ecf2757ce0b356c3a3cb1d835d 172.30.12.88:6379@16379 slave 34bbfdcd3b15e3c008d161be59c968f4825b0bc6 0 1565010144000 2 connected
4adaf2831b39f6cea0aaee0af1d3a8aa0b8e397f 172.30.12.89:6379@16379 master - 0 1565010140625 8 connected 10923-16383
a1126752c3d832ec244e3823324080f79529f805 172.30.25.78:6379@16379 slave 4adaf2831b39f6cea0aaee0af1d3a8aa0b8e397f 0 1565010145645 8 connected
34bbfdcd3b15e3c008d161be59c968f4825b0bc6 172.30.25.77:6379@16379 master - 0 1565010145000 2 connected 5461-10922
af19887c54c6fb939f8933ee52dcdd57b291b445 172.30.25.76:6379@16379 myself,slave 80793e3e94ae6c6104c0640d6d18e6f4651a9ba2 0 1565010144000 1 connected
~~~


Redisクラスタの稼働を、redis-cli コマンドを実行してチェックする。 「cluster_state:ok」から正常に稼働していることが確認できる。

~~~
$ kubectl exec -it redis-cluster-1-0 -- redis-cli -c cluster info
cluster_state:ok
cluster_slots_assigned:16384
cluster_slots_ok:16384
cluster_slots_pfail:0
cluster_slots_fail:0
cluster_known_nodes:9
cluster_size:3
<以下省略>
~~~


## OpenShift の ocコマンドの利用

もちろん、ocコマンドによるK8sクラスタの操作もできる。
ocコマンドは、kubectlと同じ操作で利用でき、さらに、OpenShiftの独自機能を使う拡張が施されてる。

~~~
$ ./oc get sts
NAME              DESIRED   CURRENT   AGE
redis-cluster-1   3         3         30m
redis-cluster-2   3         3         29m
redis-cluster-3   3         3         16m

$ ./oc get svc
NAME               TYPE           CLUSTER-IP       EXTERNAL-IP      PORT(S)                      AGE
docker-registry    ClusterIP      172.21.147.71    <none>           5000/TCP                     55m
kubernetes         ClusterIP      172.21.0.1       <none>           443/TCP,53/UDP,53/TCP        59m
redis-cluster      ClusterIP      None             <none>           6379/TCP,16379/TCP           30m
registry-console   ClusterIP      172.21.148.163   <none>           9000/TCP                     55m
router             LoadBalancer   172.21.149.76    165.***.**.***   80:32354/TCP,443:30652/TCP   55m

$ ./oc get pvc
NAME                     STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS        AGE
data-redis-cluster-1-0   Bound     pvc-5efec0e9-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   30m
data-redis-cluster-1-1   Bound     pvc-d10c1e03-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   27m
data-redis-cluster-1-2   Bound     pvc-2a08d554-b77e-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   24m
data-redis-cluster-2-0   Bound     pvc-61ed461c-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   30m
data-redis-cluster-2-1   Bound     pvc-d31ce74f-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   26m
data-redis-cluster-2-2   Bound     pvc-2d2a63fc-b77e-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   24m
data-redis-cluster-3-0   Bound     pvc-356e5fd5-b77f-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   17m
data-redis-cluster-3-1   Bound     pvc-a7327507-b77f-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   13m
data-redis-cluster-3-2   Bound     pvc-067a7880-b780-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            ibmc-block-bronze   11m
registry-backing         Bound     pvc-d3f12c0b-b779-11e9-8384-926f70939424   20Gi       RWX            ibmc-file-bronze    55m

$ ./oc get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS    CLAIM                            STORAGECLASS       REASON    AGE
pvc-067a7880-b780-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-3-2                                10m
pvc-2a08d554-b77e-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-1-2                                23m
pvc-2d2a63fc-b77e-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-2-2                                23m
pvc-356e5fd5-b77f-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-3-0                                16m
pvc-5efec0e9-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-1-0                                29m
pvc-61ed461c-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-2-0                                29m
pvc-a7327507-b77f-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-3-1                                13m
pvc-d10c1e03-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-1-1                                26m
pvc-d31ce74f-b77d-11e9-9e19-be7a4f7a6dc0   20Gi       RWO            Delete           Bound     default/data-redis-cluster-2-1                                26m
pvc-d3f12c0b-b779-11e9-8384-926f70939424   20Gi       RWX            Delete           Bound     default/registry-backing         ibmc-file-bronze             45m
~~~


## Redisクラスタへのデータ書込みと読出しのテスト

Redisクライアントのポッドを起動して、Redisクラスタのサービスを指定して、データの書込みと読出しを実行した。問題なく動作した。

~~~
$ kubectl run redis-cli --image redis --restart=Never
pod/redis-cli created

$ kubectl exec -it redis-cli -- bash
root@redis-cli:/data# redis-cli -c -h redis-cluster -p 6379
redis-cluster:6379> set key-a 1001
-> Redirected to slot [6672] located at 172.30.25.77:6379
OK
172.30.25.77:6379> set key-b 2042
OK
172.30.25.77:6379> set key-c 3408
-> Redirected to slot [14930] located at 172.30.12.89:6379
OK
172.30.12.89:6379> get key-a
-> Redirected to slot [6672] located at 172.30.25.77:6379
"1001"
172.30.25.77:6379> get key-b
"2042"
172.30.25.77:6379> get key-c
-> Redirected to slot [14930] located at 172.30.12.89:6379
"3408"
~~~

## ibmcloud ks コマンド

従来のibmcloud コマンドを利用して、IaaS部分の操作は可能である。しかし、IKS-OSクラスタにログインするには、oc login を実行しなければならない。

~~~
$ ibmclolud ks clusters
OK
名前   ID                                 状態     ワーカー   ロケーション   バージョン                リソース・グループ名   Provider   
iks1   d5361e9e1b0e40e099ecd7fe02a71d64   normal   2        Tokyo        1.12.10_1560*             default           classic   
iks7   bl2p9f7t003ua6f4ku7g               normal   3        Tokyo        1.13.8_1529               default           classic   
jk1    ac86d529194f4f2d857d163e82afa2bf   normal   2        Tokyo        1.12.10_1560*             default           classic   
os1    bl3uq30t0dfr6b74a1t0               normal   2        Tokyo        3.11.129_1517_openshift   default           classic   
~~~


## まとめ

今回は、OpenShift らしい機能は、全く利用せず、Kubernetesとして利用できることの確認に留まってしまったが、同じように使えることが解った。解ったポイントを以下に列挙する。

* 東京リージョンの OpenShift on IBM Cloudで、3ゾーンを使って、高可用性のRedisクラスタを構築することができた。
* IKS-K8s のマニフェストを、無修正でそのまま、IKS-OSに適用して、Redisクラスタ を構築できた。
* OpenShiftのバージョンは、現在最新の v4 ではなく v3 である。v4のリリースはアナウンスされているので今後に期待する。
* OpenShift 独自拡張コマンド oc の他に、CNCFが配布する kubectl コマンドでも操作可能であった。
* IKS-OSは、従来のIKS-K8sと同じ実行基盤が利用されており、K8sノードに仮想マシン、ベアメタルマシン、永続ボリュームが利用される。
* 永続ボリュームのストレージクラスは、最初からブロックストレージがインストールされており、アクセスモードにRWOを指定すると、ブロックストレージがプロビジョニンングされた。
* IKS-OSはエントリー構成のスペックが高いので応じてコストも高くなる。よって、小規模の場合は、従来のIKS-K8sが良いと思われる。

これから、ALBやLBと組み合わせ、Operatorの利用など、色々試して見たい。