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

テクノロジー

はじめに

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

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

RKSを知る! 概要&連載リンク集

AKSの拡張性

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

Azure Kubernetes Service (AKS) クラスターのベースライン アーキテクチャ - Azure Architecture Center
Azure Kubernetes Service (AKS) クラスターをデプロイするベースライン インフラストラクチャのリファレンス アーキテクチャ。

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

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

Azure Kubernetes Service (AKS) でのクラスター オートスケーラーの使用 - Azure Kubernetes Service
Azure Kubernetes Service (AKS) クラスターでのアプリケーションの需要を満たすように、クラスター オートスケーラーを使用してクラスターを自動的にスケーリングする方法について説明します。

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

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

Azure portal または PowerShell を使用して仮想マシンのサイズを変更する - Azure Virtual Machines
Azure 仮想マシンに使用する 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はスタートアップサービスのため、拡張性についても今後のアップデートが期待されます。

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