OpenShift 3.11 が IBM Cloud の東京リージョンで利用できるようになったので、早速、試してみた結果である。
これは「Redisクラスタをマルチゾーン上のKubernetesで構築する時の考慮点」で構築したRedisクラスタと同じマニフェストを使って、OpenShift on IBM Cloud で再構築したものである。
ここでは、IBM Cloud の OpenShift を「IKS-OS」と表し、従来からのCNCFのコードにIBMが機能を追加したKubernetesを「IKS-K8s」と表して区別する。
IKSは、Kubernetesクラスターを作成する際にPure Kubernetes か OpenShiftを選べる
(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について、一つのリストで確認できる。 共にワーカーノードやネットワーク基盤は、同じなので、ワーカーノードに付与されるラベルなども同じである。
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の利用など、色々試して見たい。