StackPointCloudがクラウドネイティブ管理プラットフォーム内のIstioとKubernetesの機能を拡張

IstioとKubernetesのクラウドネイティブ管理プラットフォームであるStackPointCloudが、企業のマイクロサービスおよびコンテナのデプロイと運用を支援するツールセットを新たに加えた。これにより、任意のクラウドプロバイダを使用したKubernetesクラスタ全体のIstioサービスを管理できるようになる。さらに同社は、KubernetesクラスタでのARM使用を支援すべく、Packet Hostと提携した。

StackPointCloudがStackPoint.ioプラットフォームに実施したおもなアップデートとして、Amazon Web Services、Google Kubernetes Engine、Microsoft Azure、Google Cloud Platform、Digital Ocean、PacketにまたがるIstioサービスメッシュのトラフィックルールをユーザがダッシュボードで監視する機能がある。StackPointCloud内でのARM Kubernetesクラスタの構築と管理も可能になった。さらにStackPointCloudは、バージョン1.10のKubernetesサポート認証も取得した。

同社CEOのMatt Baldwin氏が、今回の発表の詳細に関するInfoQのインタビューに応じてくれた。

InfoQ: 新たにKubernetes認証を取得した意味は何ですか？

Matt Baldwin: 認証がなければ、ユーザ企業は、選択したベンダがKuberneteの現行バージョンに準拠しているかどうかを判断できません。Cloud Native Computing Foundation (CNCF)が、Kubernetesの各リリースバージョンごとにプロバイダを再認証するプロセスを確立したのは、この理由からです。当社は1.8、1.9、1.10の認証を受けています。これにより、クラウドネイティブインフラストラクチャ管理プラットフォームとしてStackPointCloudを選択した企業は、上位で実行されている“バニラ”Kubernetesが変更されておらず、安定したものであるという確信を持つことができます。適合性テストをパスせず、認定されていない場合、そのベンダはメインプロジェクトからフォークした、独自のKubernetesディストリビューションを提供していることになります。この場合、一部の機能が動作しなかったり、あるいは期待と違う動作をする可能性があるため、ユーザとして理想的ではありません。信頼は認証に基づくものだと、当社は考えています。

InfoQ: 今回のStackPoint.ioのアップデートでは、引き続きオペレータと開発者の両方を重視して、プロバイダに関係なく、ひとつないし複数のKubernetesクラスタを対象としてカナリア、A/B、ブルー/グリーンといったデプロイメントを行うことが可能になっています。任意の数のKubernetesサービスを選択して、それに対するIstioトラフィックルールを設定することもできるようになりました。これらのトラフィックルールはどうやって設定するのですか？

Baldwin: StackPoint.ioのIstio Dashboardコンポーネントのバージョン１リリースでは、ユーザがルーティングルールを編集できるようになっています。現在注目しているユースケースは、おもにカナリアデプロイメント、ブルー/グリーンデプロイメント、A/Bデプロイメントです。これらはすべてウィザードで表示されています。その中でユーザは各サービスの現行バージョンを選択し、次のバージョンを選択して、最後に対象別のトラフィックの配分を設定します。50/50や、あるいは最新バージョンをテストするためにトラフィックの1パーセントのみを送信するような設定が可能です。これらはマイクロサービスを運用環境に導入する際に、一般的に使用されるユースケースです。将来的には、より複雑なルートルールのタイプも順次取り入れて、当社の製品内で管理や作成が可能なようにしていきます。ルールの適用される時間についても、即時以外のスケジュールを設定することが可能です。サービスのIstioルーティングの構成には、カスタムルールを構築するか、あるいはStackpoint.ioウィザードを使用するかを選択できます。さまざまなトラフィックルールの設定以外にも、VirtualServicesやDestinationsといったダッシュボードで、Istioサービスメッシュの他の側面を視覚的に管理することが可能です。

InfoQ: “継続的インテグレーションテストをパスする”、といったルールをスケジュール設定することも可能なのでしょうか？

Baldwin: いいえ、現在のスケジュール機能はもっと単純なものです。おもなユースケースは、例えば運用チームが、ブルー/グリーンデプロイメントを変更管理時間中に実施するようにスケジュールする、といったものです。ルールに期限を設ける機能も導入する予定です。これにより、もしカナリアデプロイメントを運用しているのであれば、それを一定期間実行するような設定が可能になります。ただし目的は、あくまでも継続的インテグレーションとデリバリの領域です — そのためのシナリオを、現在考えているところです。

InfoQ: KubernetesクラスタでARMを使用しているユーザを支援するために、PacketHostと提携しましたが、その共同ソリューションには、ARMクラスタへのノード追加と削除、ARMインスタンスの自動スケール、ARM Kubernetesクラスタのアップグレードといった、従来からStackpoint.ioで可能だった機能が含まれています。PacketHostとの今回の拡張では何が違うのでしょうか？

Baldwin: Packetはベアメタルを提供しています -ですから例えば、KubernetesをGoogleがやっているように(つまりベアメタル上で)運用したいのならば、Stackpoint経由でPacketを使用することが、システムリソースへのアクセスを単一テナント環境で手に入れる方法のひとつです。

InfoQ: “ARMインスタンス”という用語は、StackPoint.ioでは正確にはどのような意味なのですか？

Baldwin: Packetは、Intelのx86やAMD(EPYC)、Caviumの堅牢なARMv8システム{ThunderX)、そして間もなくQUalcomm(Centriq)など、さまざまなプロセッサへのアクセスを提供しています。Packetと再統合した時に当社は、Packetのx86システムのみでなく、同社のARMシステムもサポートするようにしました。これはKubernetesとクラウドネイティブとしては自然なステップで、“ワークロードをどこでもいつでも実行可能にする”という約束にも添っています。Kubernetesのコントロールプレーンとしては、当社が最初だと思っています。明確にしておきたいのですが、これは“Raspberry Pie”スタイルとは違う、低消費電力のARMです。Packetの現在の構成では、96コアと128GBのRAMが50ドル/時となっています。

InfoQ: なぜARMが重要なのでしょう？

Baldwin: ARMのようなアーキテクチャからGPUや特殊なオフロード(スマートフォンやラップトップなど)まで、基盤となる計算リソースは多様化しています。カスタムシリコンを見れば、多数のARMが見つかることは間違いありません。今後ARMとKubernetesの組み合わせは、モノのインターネット(IoT)やエッジコンピューティングといった分野で、大きな役割を果たすことになるでしょう。これまでは、このような多様なタイプの環境を立ち上げたり、管理する手段がなかったのです。Intel x86とARMインフラストラクチャのどちらも構築可能になります。