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の設定を見てみます。

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.8/html/machine_management/configuring-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という定義が必要なので下記を参考に考えます。

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.8/html/machine_management/configuring-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用のサンプルがあるようです。

https://access.redhat.com/documentation/ja-jp/openshift_container_platform/4.8/html/machine_management/creating-machineset-azure

マニフェストファイルでARMテンプレートやTerraformでやっていることが実現できそうに見えました。
Terraformを運用環境にapplyするのは結構勇気の要る作業なので、マニフェストファイルを適用したら自動的に環境が調整される世界は心理的にも工数的にも良さそうだなと思います。

まとめ

実際にスケールするところまでは見れていないですが、OpenShiftのクラスターコンソールを楽しみつつクラスタのオートスケールについてどのような設定ができるか確認できました。
ごちゃごちゃと書いてしまいましたが、まとめると下記のポイントになってくるかと思います。

インフラ定義がマニフェストファイルで完結する（っぽい）ので、TerraformやARMテンプレートのような仕組みを使わずにOpenShiftとyamlファイルさえあれば柔軟なインフラを構築できそう
マニフェストファイルで詳細なカスタマイズもできるし、クラスターコンソールから簡易的なマニフェストファイルを生成することもできる
AKSとは違い、クラスタのスケールダウンを詳細に定義できるので、アプリの特性に合わせたスケールダウン動作を実装できる
アベイラビリティゾーン（やリージョン）の単位でオートスケール設定を組めるので、データセンターの障害に対して強い構成が組みやすい