RKSを知る！ 連載第22回目 :マネージドKubernetesサービス比較調査 –拡張性編

はじめに

「RKSを知る！」の連載第22回目の記事としまして、マネージドKubernetesの拡張性の比較として、RKSと各クラウドベンダ(AKS,EKS)と比較し、各クラウドベンダごとの拡張性の比較を行っていきたいと思います！

本連載についてはリンクページを用意していますため、概要や連載記事は下記URLからご確認ください。

RKSを知る！ 概要＆連載リンク集

AKSの拡張性

AKSの拡張性は自動スケーリングまたは手動スケーリングという 2 つの方法があります。

https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/containers/aks/secure-baseline-aks#node-and-pod-scalabilit

手動スケーリングはAzure Cloud Shellで専用コマンドを実行、またはGUIでのAKSサービス画面から従来のKuberntesのスケーリングに近い動作でスケーリングを実施します。

自動スケーリングはクラスター オートスケーラーの有効化を実施することにより、ノード数の範囲を指定して、自動的にスケーリングを実施するよう設定を行います。

https://docs.microsoft.com/ja-jp/azure/aks/cluster-autoscaler

また、AKSで稼働しているWorkerNodeのサイズはGUIおよびコマンド操作から変更可能となります。

※変更手順については以下の公式ドキュメントから確認することができます。

https://docs.microsoft.com/ja-jp/azure/virtual-machines/windows/resize-vm

EKSの拡張性

EKSのNodeのスケールイン、スケールアウトはAWSマネジメントコンソール、ないしaws cliによる手動スケーリングとClusterAutoScalerにて自動スケーリングをサポートしています。

Nodeの自動スケーリングはClusterAutoScalerにより実施可能であり、デフォルトではクラスタを構成しているWorkerNodeの全体CPU、ないしメモリ使用量が50%を超過した場合、スケールアウト、クラスタ全体のCPU、ないしメモリ使用量が10%未満となった場合、スケールインを自動的に実施します。

EKSのNodeの性能(インスタンスタイプ)はクラスタ構築時に作成したノードグループに紐づいているため、クラスタ構築後にインスタンスタイプのみを変更することは出来ません。

EKSのネットワーク帯域については、元々EC2のインスタンスタイプによって帯域が決定されている関係があるため、インスタンスタイプの変更で自動的に拡張されます。

RKSの拡張性

Riddge Cloudは基本的にGUIでの手動スケーリングが対応可能となっています。(Nodeの増減が可能)

また、クラスターのノード構成はクラスター構築時にカスタマイズできますが、ノード追加時には選択できない仕様となっております。

自動スケーリングについてはRidge Cloud側での自動適用となっているため、利用者側でのスケーリングレベルの制御ができない状況となっています。

代わりに、Ridge Cloud側でNodeに障害が発生した場合は自動的にスケーリングする仕様になっているため、利用者側で拡張性の設計を行う必要がない状況となります。

まとめ

今回はRKSと各クラウドベンダごとのマネージドKuberntesにおける拡張性を調査しました。

AKS、EKSともにノードの拡張は手動、および自動でカスタマイズすることができますが、RKSでは基本的に手動でのノード増減のみとなっているため、比較すると、拡張性は各クラウドベンダが一歩先を進んでいる印象となりました。

RKSはスタートアップサービスのため、拡張性についても今後のアップデートが期待されます。

ここまでお読みいただきありがとうございました！

About サイオステクノロジーの中の人です 88 Articles

サイオステクノロジーで働く中の人です。

Twitter YouTube