前回までのあらすじ
最近様々な業界で、コンテナ上のワークロードが増えてきたように感じています。弊社のFinOpsソリューション：Spotには、Oceanというコンテナワークロードのコスト最適化サービスがあります。GKEとの連携は可能ではあるものの、日本語書かれた親切なガイドみかけないため、やり方をご紹介します。
前回の記事では、GKEクラスタ内にOceanを利用するためのOcean Controllerを設置し、Spot OceanのSaaSプレーンとの連携まで完了しました。しかし最後に、ルートボリュームがpd-ssd, pd-standard, nullのどれかではないといけないとエラーが出てしまいました。
さあ、burikiはこの記事内で見事GKEクラスタとSpot Oceanを連携させることが出来るのか?!
GKEクラスタの再作成(三度目の正直)
以下の構成でクラスタ(cluster-1)を作成します。
・Zonal location: asia-east1-a
・Number of nodes: 3
・Machine type: e2-small(2 CPU, 2GB memory)
・Boot disk type: Standard persistend disk(前回はデフォルトのBalancedで作ってしまった)
Spotコンソールにてクラスタの登録作業
前回の記事の手順に従って再びクラスタの登録を行います。
Step 1
Ocean用のトークンの発行
Step 2
Google Cloud PlatformのCloud Shellで以下を実行
# ControllerInit.shファイルを作成
$ touch ControllerInit.sh
#ファイルの作成を確認
$ ls
ControllerInit.sh
#Spotコンソールで表示されたスクリプトをコピペ
$ vi ControllerInit.sh
#コンテナのエンドポイント情報などをkubectlのconfigに出力
$ gcloud container clusters get-credentials cluster-1 --zone asia-east1-a
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.
#kubectl configに情報が空っぽでないことを確認
$ kubectl config view
#クラスタに対して、自分に管理者権限を付与
$ kubectl create clusterrolebinding cluster-1 --clusterrole=cluster-admin --user=<ENTER_USER_ID>
clusterrolebinding.rbac.authorization.k8s.io/cluster-1 created
#Ocean Controllerをインストール
$ ./ControllerInit.sh
2023-01-23T06:00:11.554Z downloading
2023-01-23T06:00:12.392Z rendering
2023-01-23T06:00:12.422Z applying
secret/spotinst-kubernetes-cluster-controller created
configmap/spotinst-kubernetes-cluster-controller-config created
serviceaccount/spotinst-kubernetes-cluster-controller created
clusterrole.rbac.authorization.k8s.io/spotinst-kubernetes-cluster-controller created
clusterrolebinding.rbac.authorization.k8s.io/spotinst-kubernetes-cluster-controller created
deployment.apps/spotinst-kubernetes-cluster-controller created
Step 3
[Test Connectivity]ボタンで、Spot側からGoogle Cloud PlatformにデプロイしたOcean Controllerを検出する。
結果は、、、
ヨシ！
仮想マシンのリストを見ると、Ocean Controllerインスタンスも一番下にデプロイできています。
数日後、、、
コスト最適化が出来ているか確認するため、連携が完了してから数日間放置してみました。結果はこんな感じです。
| カラム | 数値 | 意味 |
|---|---|---|
| Ocean Nodes / Registered Nodes | 1/4 | Oceanで管理しているノードの数 |
| Hours | 80.24 | Oceanで管理している稼働時間 |
| Total Saved | $3.49 | 削減額 |
| Potential Costs | $4.25 | Oceanを使わなかった場合の利用料 |
| Actual Costs | $0.76 | 実際の利用料 |
| Savings | 82.16% | 実際の利用料÷Oceanを使わなかった場合の利用料、削減率 |
約4日間ほど稼働させて、本来なら$4.25の利用料が、Oceanによる削減効果で$0.76まで削減することが出来ました。割合で考えると、驚異の80％越えの削減率となりました。
まとめ
というわけで、無事OceanとGKEクラスタの連携、利用料最適化に成功しました。数日で削減効果も数字として表れてくれたので、読者の皆様にも効果を確認していただけたと思います。ただ一点、通常の運用だとOceanは60~70%の削減効果が見込まれます。ここまで削減効果が高かったのは、特にワークロードも動かしていない、安定した状態での運用なので、変動もなく削減効果がほぼ最大だったのではないかと考えています。Node Activityを見てみると、Preemptibleインスタンスを使っていると確認できます。もっと変動が起こり、Spotインスタンスを使用するようになれば、さらなる利用料の最適化が望めるかもしれません。
おまけ
私の様なGoogle Cloud初心者には「Preemptibleってなに？」と思った方もいるんじゃないかなと思います。そんな方のためにザックリPreemptiveについて補足します。
一般的にスポットインスタンスというと、そのクラウドベンダー内で使用されていないコンピューティングキャパシティを格安で使えるものを指します。ただあくまでも余っているものを使うだけなので、クラウド内のリソース需要に応じて回収されてしまいます。ですので、回収されるたびにスポットインスタンス上で動いているアプリケーションには中断が生じてしまい、動かせるアプリケーションの種類が限られてきます。しかしSpot by NetAppが次のスポットインスタンスの購入・マイグレーションを自動でやってくれるので、中断を気にせずスポットインスタンスを使って様々なアプリケーションを動かせるというわけです。話を戻しますが、Google Cloud Platoformにはこのスポットインスタンス相当のものが2種類あります。
・Spot VM
・Preemptible VM
どちらも60%~91%という割引率は変わりませんが、Preemptible VMの方は、実行開始後24時間しか実行できません。Spot VMにはこういった制限はありません。そしてまとめのスクショを見ていただけると分かるように、Spot OceanはSpot VMとPreemptible VMの両方に対応しています(Spot Oceanの基盤になっているSpot Elastigroupというスポットインスタンスを使用したサービスも両方対応しています)。