SIOS Tech. Lab | エンジニアのタメになるOSS・クラウド・認証の技術トピックス 
目次
はじめに
「RKSを知る！」の連載第3回目の記事としまして、RKS(Ridge Kubernetes Service)について、解説していきたいと思います。
第2回目の記事にてクラスタの作成方法を紹介しましたが、今回はRKSそのものの概要や料金形態について触れていきたいと思います。
本連載についてはリンクページを用意していますため、概要や連載記事は下記URLからご確認ください。
RKSを知る！ 概要＆連載リンク集
RKSとは？
RKS(Ridge Kubernetes Service)とは、第1回目の記事にて紹介した通り、Ridgeが提供しているマネージドKubernetesサービスです。
特徴としてはRAEにより、WorkerNode数やリリース対象国、HA構成にするかどうかなどを設定することで、自動的にKubernetesクラスタを生成することができる点にあります。
Ridgeが提携しているデータセンターでしたらどこでも構成することが可能であり、例えばアメリカのダラスに１クラスタ作成し、インドのムンバイに２クラスタ作成するなど、地理的に離れていてもコンソールひとつで生成管理が可能になります。
しかしながら、クラスタ内のNodeを分割して別のデータセンターに置くことは出来ず、必ずクラスタ内のリソースはデータセンターと紐づく必要があります。
コンソール上の見え方としてはリージョンなどを移動する必要はなく、一元的に複数のクラスタをコンソールから管理することが可能です。
他のクラウドベンダのようにリージョンを切り替えるたび、確認できるリソースが異なるといった管理面での混乱は少ないので、管理はしやすいと思います。
RKSのネットワーク
RKSにて生成されたKubernetesクラスタのネットワークはプライベートネットワークであり、MasterNodeもWorkerNodeも実際にサーバにアクセスすることは出来ず、SSHでのアクセスも不可となっています。
外部への通信は全てRidgeCloudにて管理されており、必要なアクセス経路は全てRidgeより提供されることになります。
Node自体のアクセスは出来ないのですが、kubectlでのアクセスに必要なクレデンシャル情報を、クラスタ構築後に各ユーザーへアクセス許可を発行することで取得することが出来ます。
RKSにて構築したクラスタの操作はkubectlのみサポートしているため、kubectlのクラスタ切替方法を周知している必要があります。
RKSのKubernetesクラスタへのアクセスは後日、別記事にて紹介したいと思います。
RKSでのロードバランサー
kubermetesのServiceTypeにLoadBalancerというタイプが存在します。
このタイプは各クラウドベンダのロードバランサーサービスを利用し、クラスタと外部ネットワークの疎通を行うserviceリソースを構築するものになります。
たびたび説明している通り、RKSは提携先のデータセンターのリソースによりクラウドサービスを提供していますが、他のクラウドベンダと同じくServiceTypeをLoadBalancerに設定することで、RKS独自のロードバランサーをserviceとして構築することが出来ます。
ロードバランサーの構築もRAEによってサポートしており、ユーザはkubernetesリソースをクラスタにアプライすることで簡単に実現することが出来ます。
RKSによりロードバランサーを作成した際にコンソールからロードバランサー情報を確認できるのですが、そちらはまた別記事にて紹介したいと思います。
RKSのストレージ
RKSで利用できるストレージはクラスタ構築時に指定したストレージ容量分、RAEにて自動的に生成されます。
生成されたストレージ容量範囲でPersistentVolumeを構築することで、RKS上のKubernetesクラスタのデータ永続化やPod間データ連携が可能になります。
なお、一度構築したNodeの容量は変更できないため、データ容量を追加・削減したいとした場合、新規でNodeを作成し、既存Nodeを削除する必要があります。
このNodeの追加削除に関してもdrain等のKubernetesの管理面の知識が必要になるため、ある程度Kubernetesの情報に精通している必要があるように感じました。
PersistentVolumeも作成後、コンソールから情報を確認できるのですが、こちらも別記事にて紹介したいと思います。
RKSのMasterNode
RKSが生成するMasterNodeは他のマネージドKubernetesサービスと同じく、ユーザがアクセスしコマンド操作を行うことは出来ません。
MasterNodeはKubernetesクラスタの根幹設定が行われているため、セキュリティ的な観点に寄り、意図的にアクセス制限が行われています。
また、MasterNodeの性能はユーザ側で指定することは出来ないようで、RAEにより１台辺りCPUコア数2~4、メモリ4GBの範囲内で生成されます。
RKSのWorkerNode
RKSにより生成されるWorkerNodeはクラスタ構成時に設定した内容に従い、RAEによって自動的に生成されます。
他のマネージドKubernetesサービスと同じくクラスタ構成後もWorkerNodeの追加は可能であり、ユーザの設定によりWorkerNodeの構成数を変更させることが出来ます。
しかしながら、構築したWorkerNodeの容量を変更することは出来ないため、リソースの追加・削除を行うには新規でNodeを追加し、既存Nodeを削除するなどの対応が必要になります。
WorkerNodeの性能はデータセンターごとにより設定範囲は異なるため、リリースする国を選定した際に設計時の想定性能が構成可能か確認する必要があります。
RKSの料金形態
RKSの料金形態は他のクラウドベンダと同じく、使用したリソース分に課金される従量課金制を採用しています。
課金料金は利用するデータセンター毎に異なるため、同じリソース料を使用したとしても料金が異なる場合があります。
料金情報はRidge公式HP上では確認できず、RidgeCloudConsole上のみから確認できるため、無料トライアルアカウントを申請しRidgeCloudConsoleを確認するか、Ridgeの担当者に問い合わせする必要があります。
RKSの料金例
データセンター毎の料金情報をまとめ、今回の投稿で紹介しようと考えたのですが、第1回目の投稿で紹介した通り、Ridgeが提携している国が20を超えており、内容が1投稿に収まらないくらい膨大になってしまいますため、今回は少数例のみ取り上げて紹介したいと思います。
今回は料金の記載方法が異なるロケーションを抜粋し、2021年4月現在もっとも日本に近い台北ロケーションの料金情報とアメリカ-ダラスの料金情報を紹介したいと思います。
なお、表記されている料金は1Nodeに掛かる料金であるため、複数Nodeでクラスタを構築した場合、その分課金されることになります。
台北ロケーション
台北ロケーションのリソースは他のロケーションに比べ、自由に構成することが可能です。
料金も使用する最小リソースを基準に料金情報が記載されており、使用するユーザがどれくらいの容量を使用するか想定し、料金を計算する必要があります。
アメリカ-ダラスロケーション
ダラスロケーションのリソースはAWSのインスタンスのように、ある一定の容量を決め打ちで用意されており、想定容量に近いリソースタイプを選択し使用することになります。
料金もリソースタイプごとに異なりますが、決め打ちの料金であるため、計算はある程度しやすいとも言えます。
あとがき
今回は連載第3回目としまして、RKSの各種情報や料金形態の例などを紹介しました！
RKSを調査しながら、クラスタを国を跨いで分割管理したり、海外でサービスを展開する際にレイテンシーを軽減するために近隣国にクラスタを構築するなど、海外展開を考えた場合、他のクラウドベンダよりも実現しやすいと感じました。
実際の操作方法などは後日別記事にて紹介したいと思いますため、次回もお楽しみにしてください！
ここまでお読みいただき、ありがとうございました！
Be the first to comment