AKS(Azure Kubernetes Services)は簡単な設定を入れるだけでクラスタのオートスケールが可能で便利ですが、あまり詳細なコントロールができない認識です。
OpenShift だとマニフェストファイルでオートスケールを調整できるように見えるので、ちょっと調べてみました。
OpenShift 環境の構築トライ
実物を知らずして進めるのも良くないと思い、構築の方もトライしました。
色々試したポイントとして、OpenShift の 4 系は VM サイズが最低でも D8s_v3、最低 4 台立つようなので、サブスクリプションのクォータの調整をしてから対応を進めましょう。オートスケールを踏まえると、「Standard DSv3 ファミリ vCPUs」を 48 以上くらいにしておきたいです。「リージョンの vCPU の合計」の方もご確認を。
サブスクリプションの準備が整ったら下記 URL の記事に従い、OpenShift 環境を構築します。
https://docs.microsoft.com/ja-jp/azure/openshift/tutorial-create-cluster
手順内で（省略可能）となっている部分については今回は省略してみました。
クラスターが作成されるまでに通常約 35 分かかります。とのことです。気長に待ちましょう。
下記を見るとクラスタへの接続方法が確認できます。
https://docs.microsoft.com/ja-jp/azure/openshift/tutorial-connect-cluster#connect-to-the-cluster
いろいろなビューがあって便利そうなので、こちらの画面も見つつ、ドキュメントを追ってみることにします。
ClusterAutoscaler の設定確認
下記を参考に、ClusterAutoscaler の設定を見てみます。
コマンドで設定する手順になっていますが、クラスターコンソールの「管理」→「クラスター設定」から、「Cluster Autoscaler」のところで設定することもできそうです。
GPU ノードはお財布が辛いので、例えばこれくらいですかね？
apiVersion: "autoscaling.openshift.io/v1"
kind: "ClusterAutoscaler"
metadata:
name: "default"
spec:
podPriorityThreshold: -10
resourceLimits:
maxNodesTotal: 24
cores:
min: 8
max: 128
memory:
min: 4
max: 256
scaleDown:
enabled: true
delayAfterAdd: 10m
delayAfterDelete: 5m
delayAfterFailure: 30s
unneededTime: 60s
resourceLimits で記載している値は AKS でも設定できなく無いかなと思うのですが、scaleDown の定義は気になりますね。
例えばノードをバンバンスケールダウンしたかったら delayAfterDelete の時間を短くすれば良さそうです。
enabled の設定があるので、スケールダウンしないという選択も可能に見えます。
この設定は次の MachineAutoscaler の設定をしないと動かないとのこと。
MachineAutoscaler の設定確認
ClusterAutoscaler だけではスケーリングしないようで、MachineAutoscaler という定義が必要なので下記を参考に考えます。
ほぼコピペですがこんな感じでどうでしょうか？
apiVersion: "autoscaling.openshift.io/v1beta1"
kind: "MachineAutoscaler"
metadata:
name: "worker-japan-east-1a"
namespace: "openshift-machine-api"
spec:
minReplicas: 1
maxReplicas: 4
scaleTargetRef:
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
name: worker-japan-east-1a
name の値が気になるところ・・・MachineSet という概念があるそうです。
OpenShift のクラスターコンソールを眺めていたら、「コンピュート」→「マシンセット」で出てきました。
初期構築で出来るみたいですね。
「コンピュート」→「マシン」のビューを見るとアベイラビリティゾーンが分かれているので、単リージョンでも安全に運用できそうな構成であることが分かりました。
MachineSet の名前は「matsuedatest-hclr8-worker-japaneast1」のような名前だったので、アベイラビリティゾーン 1 を使用する MachineSet へのオートスケール設定をする場合は、こんな定義になるでしょうか。
apiVersion: "autoscaling.openshift.io/v1beta1"
kind: "MachineAutoscaler"
metadata:
name: "matsuedatest-hclr8-worker-japaneast1"
namespace: "openshift-machine-api"
spec:
minReplicas: 1
maxReplicas: 4
scaleTargetRef:
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
name: matsuedatest-hclr8-worker-japaneast1
お、良く見るとクラスターコンソールの 「コンピュート」→「マシンセット」 から Machine Autoscaler が設定できるようです。レプリカの最小数と最大数を入れて保存したら、こんな yaml が生成されました。上記で外してなかった感じがしますね！
apiVersion: autoscaling.openshift.io/v1beta1
kind: MachineAutoscaler
metadata:
creationTimestamp: 'XXXX-XX-XXTXX:XX:XXZ'
finalizers:
- machinetarget.autoscaling.openshift.io
generation: 1
managedFields:(略)
name: matsuedatest-hclr8-worker-japaneast1
namespace: openshift-machine-api
resourceVersion: 'XXXX'
uid: XXXX
spec:
maxReplicas: 4
minReplicas: 1
scaleTargetRef:
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
name: matsuedatest-hclr8-worker-japaneast1
status:
lastTargetRef:
apiVersion: machine.openshift.io/v1beta1
kind: MachineSet
name: matsuedatest-hclr8-worker-japaneast1
MachineSet について追加で調べたこと
クラウドごとに、例えば Azure の場合は Azure 用のサンプルがあるようです。
マニフェストファイルで ARM テンプレートや Terraform でやっていることが実現できそうに見えました。
Terraform を運用環境に apply するのは結構勇気の要る作業なので、マニフェストファイルを適用したら自動的に環境が調整される世界は心理的にも工数的にも良さそうだなと思います。
まとめ
実際にスケールするところまでは見れていないですが、OpenShift のクラスターコンソールを楽しみつつクラスタのオートスケールについてどのような設定ができるか確認できました。
ごちゃごちゃと書いてしまいましたが、まとめると下記のポイントになってくるかと思います。
- インフラ定義がマニフェストファイルで完結する（っぽい）ので、Terraform や ARM テンプレートのような仕組みを使わずに OpenShift と yaml ファイルさえあれば柔軟なインフラを構築できそう
- マニフェストファイルで詳細なカスタマイズもできるし、クラスターコンソールから簡易的なマニフェストファイルを生成することもできる
- AKS とは違い、クラスタのスケールダウンを詳細に定義できるので、アプリの特性に合わせたスケールダウン動作を実装できる
- アベイラビリティゾーン（やリージョン）の単位でオートスケール設定を組めるので、データセンターの障害に対して強い構成が組みやすい