id:s-oomori です。
「OKE（Oracle Container Engine for Kubernetes）でJMeterクラスター環境構築」の第３回になります。
※第一回はこちら
今回は前回OKEで構築したJMeterクラスターの環境に対して、スケールしたりpodを操作してみたいと思います。
また、執筆中にOCIのUIが日本語化対応したので、画面キャプチャーは日本語版でご紹介します。
本記事の目次
発表資料
- 今回のブログ内容では資料中の図が参考になりますので、参照しながら進めるとより理解し易いと思います。
- 最後の2枚の背景が半透明にならない。。。（実際は半透明です） speakerdeck.com
参考にしたサイトは以下になります。
blog.kubernauts.io
前提
-
作業端末でkuberctlコマンド等のK8sを扱うに当たって必要なコマンドを導入しておく。
※私はMac Bookで実装。別途専用Linuxを立ち上げると自分のPCに余計なツールを導入する必要がなくなります。 -
OCIのCLIを導入しておく。
※導入方法はCloudiiブログでもUPしてますので参考にしてください。
Oracle Cloud Infrastructure CLIの導入 - Cloudii blogとOracle Cloud Infrastructure CLIの導入 (後編：環境設定) - Cloudii blog -
OCIのService Limitを解除しておく。
※1リージョンあたりのCompute同時構築数が制限されているので、検証でも増やしておくことを推奨します。
※Computeのシェープ種類も用途に酔っては解除してください。
※解除方法はOCI Web上から英語文で申請すれば解除してくれます。または、SRからの解除申請も可能です。 -
推奨：OCIでOKE用のCompartmentを作成しておく。また、必要に応じて、権限等のセキュリティ周りも設定しておく。
※今回は、「test-container」というCompatmentを事前に作成しておいたので、このCompartmentを利用します。 -
今回は「us-Phoenix-1」リージョンを使います。
-
私が少し手を加えた「jmxファイル」と「grafanaテンプレート」はこちらを利用ください。
podを増やす
第２回でのイメージ図は下図のようになってます。 
#pod情報の確認 $ kubectl -n k8s get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE influxdb-jmeter-f899f8948-958l9 1/1 Running 0 47d 10.244.2.4 10.0.12.2 jmeter-grafana-5dc58ddb59-vj8th 1/1 Running 0 47d 10.244.1.5 10.0.11.2 jmeter-master-66cb9c8bfb-4zl6b 1/1 Running 0 47d 10.244.1.4 10.0.11.2 jmeter-slaves-6d5b7d457c-7v57d 1/1 Running 0 6s 10.244.2.110 10.0.12.2 jmeter-slaves-6d5b7d457c-fn4lv 1/1 Running 0 6s 10.244.1.109 10.0.11.2
今回はJMeter Slaveのpodを3つ増やしてみます。
※下図のイメージになります。 
１．第２回でgit cloneしたフォルダーに移動し、slavesのyamlファイルを編集します。
#git cloneしたフォルダーに移動 $ cd jmeter-kubernetes #Slaveのyamlファイルを編集 $ vi jmeter_slaves_deploy.yaml #「replicas」の値を２→５に変更（3つ追加） apiVersion: apps/v1beta2 kind: Deployment metadata: name: jmeter-slaves labels: jmeter_mode: slave spec: replicas: 2 → 5
２．Slaveを再デプロイします。
#Slaveの再デプロイ ※数秒で完了します。 $ kubectl -n k8s apply -f jmeter_slaves_deploy.yaml deployment.apps "jmeter-slaves" configured
３．podの情報を確認し、jmeter-slavesのpodが5つでデプロイされたことを確認する。
#pod情報の取得 ※数秒で追加されRunningで稼働していることが確認できます。 $ kubectl -n k8s get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE influxdb-jmeter-f899f8948-958l9 1/1 Running 0 47d 10.244.2.4 10.0.12.2 jmeter-grafana-5dc58ddb59-vj8th 1/1 Running 0 47d 10.244.1.5 10.0.11.2 jmeter-master-66cb9c8bfb-4zl6b 1/1 Running 0 47d 10.244.1.4 10.0.11.2 jmeter-slaves-6d5b7d457c-64q5v 1/1 Running 0 6s 10.244.0.110 10.0.10.2 jmeter-slaves-6d5b7d457c-7v57d 1/1 Running 0 2m 10.244.2.110 10.0.12.2 jmeter-slaves-6d5b7d457c-fn4lv 1/1 Running 0 2m 10.244.1.109 10.0.11.2 jmeter-slaves-6d5b7d457c-gxvxz 1/1 Running 0 6s 10.244.2.111 10.0.12.2 jmeter-slaves-6d5b7d457c-rmhc6 1/1 Running 0 6s 10.244.0.111 10.0.10.2
podを減らす
今回は先程増やしたJMeter Slaveのpodを3つ減らしてみます。
１．slavesのyamlファイルを編集します。
#git cloneしたフォルダーに移動 $ cd jmeter-kubernetes #Slaveのyamlファイルを編集 $ vi jmeter_slaves_deploy.yaml #「replicas」の値を５→２に変更（3つ減らす） apiVersion: apps/v1beta2 kind: Deployment metadata: name: jmeter-slaves labels: jmeter_mode: slave spec: replicas: 5 → 2
２．Slaveを再デプロイします。
#Slaveの再デプロイ ※今回も数秒で完了します。 $ kubectl -n k8s apply -f jmeter_slaves_deploy.yaml deployment.apps "jmeter-slaves" configured
３．podの情報を確認し、jmeter-slavesのpodが2つRunmingで先程追加した3つがTerminateされていることを確認。
#pod情報の取得 ※Terminatingも早ければ数秒で完了するので表示されない場合もあります。 $ kubectl -n k8s get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE influxdb-jmeter-f899f8948-958l9 1/1 Running 0 47d 10.244.2.4 10.0.12.2 jmeter-grafana-5dc58ddb59-vj8th 1/1 Running 0 47d 10.244.1.5 10.0.11.2 jmeter-master-66cb9c8bfb-4zl6b 1/1 Running 0 47d 10.244.1.4 10.0.11.2 jmeter-slaves-6d5b7d457c-64q5v 1/1 Terminating 0 9m 10.244.0.110 10.0.10.2 jmeter-slaves-6d5b7d457c-7v57d 1/1 Running 0 11m 10.244.2.110 10.0.12.2 jmeter-slaves-6d5b7d457c-fn4lv 1/1 Running 0 11m 10.244.1.109 10.0.11.2 jmeter-slaves-6d5b7d457c-gxvxz 1/1 Terminating 0 9m 10.244.2.111 10.0.12.2 jmeter-slaves-6d5b7d457c-rmhc6 1/1 Terminating 0 9m 10.244.0.111 10.0.10.2
ノードを増やす
今回はノードを増やしてみます。
現在3つのノードで稼働してますが、下図の通り1ADあたり1ノードを追加して合計6ノードにスケールアップします。
OKEの強いところの一つだと思っていて、GUIで簡単にスケールすることが可能です。
#現在のノード情報を確認 $ kubectl -n k8s get node NAME STATUS ROLES AGE VERSION 10.0.10.2 Ready node 49d v1.12.6 10.0.11.2 Ready node 49d v1.12.6 10.0.12.2 Ready node 49d v1.12.6
１．OCIのOKE管理画面を開き、Node Pools項目の「アクション」を選択し、「スケール」を選択します。 
２．ノード・プールのスケーリング画面の、サブネット当たりの数量を「１」→「２」に変更し、「スケール」を選択します。 
３．しばらくすると、下図のとおりノードがCREATINGとなり追加されます。 
※コンピュートのインスタンス画面を確認すると、３インスタンスがプロビジョニング中というのが確認できます。 
４．ノードが全てACTIVEになれば追加完了です。
#ノード情報を確認 $ kubectl -n k8s get node NAME STATUS ROLES AGE VERSION 10.0.10.2 Ready node 49d v1.12.6 10.0.10.4 Ready node 56s v1.12.6 10.0.11.2 Ready node 49d v1.12.6 10.0.11.4 Ready node 1m v1.12.6 10.0.12.2 Ready node 49d v1.12.6 10.0.12.4 Ready node 1m v1.12.6
ノード障害した場合
OKEというよりはK8sの動きになりますが、今回はあるノードが負荷等で障害（ダウン）となってしまった場合を想定した動きを見てみます。
イメージは下図の通りで、podが稼働しているノードをシャットダウンして仮障害の状況を作ります。
#現在のpod情報を確認 ※podが稼働しているノードIPを確認 $ kubectl -n k8s get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE influxdb-jmeter-f899f8948-958l9 1/1 Running 0 48d 10.244.2.4 10.0.12.2 jmeter-grafana-5dc58ddb59-vj8th 1/1 Running 0 48d 10.244.1.5 10.0.11.2 jmeter-master-66cb9c8bfb-4zl6b 1/1 Running 0 48d 10.244.1.4 10.0.11.2 jmeter-slaves-6d5b7d457c-7v57d 1/1 Running 0 1d 10.244.2.110 10.0.12.2 jmeter-slaves-6d5b7d457c-fn4lv 1/1 Running 0 1d 10.244.1.109 10.0.11.2
１．「10.0.12.2」ノードをシャットダウンする。
※このノードで稼働しているpodはinfluxdb-jmeterとjmeter-slavesの2つ 
２．ノード状態を確認する。
#シャットダウンしたノードが「NotReady」となる。 $ kubectl -n k8s get node NAME STATUS ROLES AGE VERSION 10.0.10.2 Ready node 49d v1.12.6 10.0.10.4 Ready node 38m v1.12.6 10.0.11.2 Ready node 49d v1.12.6 10.0.11.4 Ready node 38m v1.12.6 10.0.12.2 NotReady node 49d v1.12.6 10.0.12.4 Ready node 38m v1.12.6
３．pod状態を確認する。
#pod状態確認すると、podの中身が稼働していないとノード稼働停止を検知してpodは移動しないようです。 $ kubectl -n k8s get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE influxdb-jmeter-f899f8948-958l9 1/1 Running 0 48d 10.244.2.4 10.0.12.2 jmeter-grafana-5dc58ddb59-vj8th 1/1 Running 0 48d 10.244.1.5 10.0.11.2 jmeter-master-66cb9c8bfb-4zl6b 1/1 Running 0 48d 10.244.1.4 10.0.11.2 jmeter-slaves-6d5b7d457c-7v57d 1/1 Running 0 1d 10.244.2.110 10.0.12.2 jmeter-slaves-6d5b7d457c-fn4lv 1/1 Running 0 1d 10.244.1.109 10.0.11.2
今回は、DBとSlavesのノードを停止しているのでgrafanaを開いてDBに接続をしてみたり、JMeterテストを実行してみると検知して該当podが別のノードで稼働します。
#サイドpod状態確認すると、該当podが別のノードで新規にデプロイされ稼働しています。 ※旧podのステータスは「Unknown」となる。 $ kubectl -n k8s get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE influxdb-jmeter-f899f8948-958l9 1/1 Unknown 0 48d 10.244.2.4 10.0.12.2 influxdb-jmeter-f899f8948-zxw9l 1/1 Running 0 2m 10.244.5.2 10.0.10.4 jmeter-grafana-5dc58ddb59-vj8th 1/1 Running 0 48d 10.244.1.5 10.0.11.2 jmeter-master-66cb9c8bfb-4zl6b 1/1 Running 0 48d 10.244.1.4 10.0.11.2 jmeter-slaves-6d5b7d457c-7v57d 1/1 Unknown 0 1d 10.244.2.110 10.0.12.2 jmeter-slaves-6d5b7d457c-fn4lv 1/1 Running 0 1d 10.244.1.109 10.0.11.2 jmeter-slaves-6d5b7d457c-z49x6 1/1 Running 0 2m 10.244.3.4 10.0.12.4
４．停止していたノードを「開始」し、ノードとpod状態を確認する。
#「10.0.12.2」ノードのSTATUSが「Ready」に戻っていることを確認 $ kubectl -n k8s get node NAME STATUS ROLES AGE VERSION 10.0.10.2 Ready node 49d v1.12.6 10.0.10.4 Ready node 59m v1.12.6 10.0.11.2 Ready node 49d v1.12.6 10.0.11.4 Ready node 59m v1.12.6 10.0.12.2 Ready node 49d v1.12.6 10.0.12.4 Ready node 59m v1.12.6 #podの「Unknown」が消えていることを確認 $ kubectl -n k8s get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE influxdb-jmeter-f899f8948-zxw9l 1/1 Running 0 16m 10.244.5.2 10.0.10.4 jmeter-grafana-5dc58ddb59-vj8th 1/1 Running 0 48d 10.244.1.5 10.0.11.2 jmeter-master-66cb9c8bfb-4zl6b 1/1 Running 0 48d 10.244.1.4 10.0.11.2 jmeter-slaves-6d5b7d457c-fn4lv 1/1 Running 0 1d 10.244.1.109 10.0.11.2 jmeter-slaves-6d5b7d457c-z49x6 1/1 Running 0 16m 10.244.3.4 10.0.12.4
５．次はノード停止ではなく、「削除」を選択してノードを削除してみます。
※「10.0.11.2」ノードを削除：jmeter-grafana,master,slavesの3podが稼働 
６．ノードとpodの状態を確認する。
#「10.0.11.2」ノードが消えていることを確認：ノード数が5つ $ kubectl -n k8s get node NAME STATUS ROLES AGE VERSION 10.0.10.2 Ready node 49d v1.12.6 10.0.10.4 Ready node 1h v1.12.6 10.0.11.4 Ready node 1h v1.12.6 10.0.12.2 Ready node 49d v1.12.6 10.0.12.4 Ready node 1h v1.12.6 #「10.0.11.2」で稼働していたpodが別のノードでデプロイされ「Running」となっていることを確認 $ kubectl -n k8s get pod -o wide NAME READY STATUS RESTARTS AGE IP NODE influxdb-jmeter-f899f8948-zxw9l 1/1 Running 0 30m 10.244.5.2 10.0.10.4 jmeter-grafana-5dc58ddb59-t7ccm 1/1 Running 0 48s 10.244.2.113 10.0.12.2 jmeter-master-66cb9c8bfb-6f2dn 1/1 Running 0 48s 10.244.2.114 10.0.12.2 jmeter-slaves-6d5b7d457c-s7dlv 1/1 Running 0 48s 10.244.5.3 10.0.10.4 jmeter-slaves-6d5b7d457c-z49x6 1/1 Running 0 30m 10.244.3.4 10.0.12.4
７．ノードは自動で再デプロイされ６つに戻されます。 
※コンピュートでもインスタンスが作成されていることを確認できます。 
８．ノードの状態を確認する。
#「10.0.11.5」ノードが追加された。 $ kubectl -n k8s get node NAME STATUS ROLES AGE VERSION 10.0.10.2 Ready node 49d v1.12.6 10.0.10.4 Ready node 1h v1.12.6 10.0.11.4 Ready node 1h v1.12.6 10.0.11.5 Ready node 11m v1.12.6 10.0.12.2 Ready node 49d v1.12.6 10.0.12.4 Ready node 1h v1.12.6
おしまいに
３回に渡ってOKEを紹介してきました。後発という有利を活かして、GUIでの操作が結構充実していると感じました。クラスタ構成までの敷居の低さも良いです！！
k8sのクラスター構成後はAWSだろうがどこを使っても操作は同じですので、ノード（インスタンス）性能や料金等、案件仕様等を考慮して選定すれば良いと思います。
今回のようなJMeter環境で外部環境をテストする時はOCIはアウトバウンド通信が月10GBまで無料ですので適しています!!
k8sの動作も紹介しましたので、是非これから発展させて活用してみてください。
今回はDokerイメージをPCのローカルに置いてからデプロイしてましたが、OCIにはレジストリ（OCIR）も提供してますのでこちらも活用いただけます。レジストリについてもどこかのタイミングでブログを書きたいと考えてます。