CodeZine(コードジン)

特集ページ一覧

OpenStack関連の技術・ビジネス・事例の最新動向

「Open Infrastructure Summit Shanghai」レポート 第3回

  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

 ここからは、Open Infrastructure Summitの中でもメインとなるOpenStackに関するセッションについて、技術・ビジネス・事例の3点に分けて紹介します。技術面では、近年注目されているKubernetesとの連携において使用されるOpenStack Zunに関するセッションについて紹介します。ビジネス面では、OpenStackの導入時にエンジニアが気になる、商用ディストリビューションに関するセッションについて紹介します。事例では、大規模ミッションクリティカルなテレコムへの導入事例と、エマージングなAPACでのパブリッククラウドサービスへの導入事例について紹介します。

目次

Virtual Kubeletを使用したKubernetesへのノードレスアプローチ

 Kubernetesが盛り上がるに連れて、OpenStackでKubernetesサービスを使用することができる便利なツールも多数登場してきています。しかし、コンテナ化されたアプリケーションを単純に使用したいだけといった場合にもKubernetesクラスタの起動と保守に非常に労力がかかってしまうのが現実でした。

 そこでOpenStackからKubernetesをより簡単に使用できるようにしようと、Zunと呼ばれるOpenStackコンポーネントの開発が続けられています。今回はZunによって実現されるOpenStackとKubernetesを組み合わせたアーキテクチャについて紹介します。

 Zunは、ユーザがノードやクラスタを作成せずにOpenStackでコンテナを実行できるようにするOpenStack Containersサービスです。また、ZunからKubernetesを操作するためにVirtual Kubeletを使用しています。Virtual Kubeletは、Kubernetes kubeletのオープンソースの実装の一つで、Azure ACI、AWS Fargate、OpenStack ZunなどのクラウドプロバイダーがKubernetesノードを使用できるようにする、つまり他のAPIと接続することを目的にしたKubeletです。

 以下では、Zunについて紹介したいと思います。

 セッションの中ではこれまでのKubernetesとOpenStackの関係として、「side by side」と「Kubernetes on OpenStack」の2種類をあげていました。「side by side」ではOpenStackとKubernetesとでリソースプールが独立して利用されており、効率的なリソース使用に課題がありました。一方で「Kubernetes on OpenStack」では、仮想化が多重になることによるオーバヘッドやネットワークの接続、クラスタの乱立による運用コスト増加といった課題がありました。

図14 Kubernetes on OpenStackのイメージ
図14 Kubernetes on OpenStackのイメージ

 そこで、リソースプールを共有化し、OpenStackのVMとKubernetesのPodとが同じレイヤで共存するアーキテクチャを提案しました。そのアーキテクチャを実現するのが、Zunプロジェクトです。KubernetesとOpenStackの組み合わせはAirshipやStarlingXといったプロジェクトでも実現されていますが、これらは「OpenStack on Kubernetes」を実現するものであり、Zunは「OpenStackとKubernetesの同レイヤでの共存」を実現しようとしている、というのが端的な違いの説明となるでしょう。

図15 VMとPodが同じリソースプールを共有している
図15 VMとPodが同じリソースプールを共有している

 ZunはVMを使用せずに、コンテナのプロビジョニングとマッピングのAPIを提供することができます。OpenStack上のコンピュートノード、NeutronのL2ネットワーク、Cinderブロックストレージを共有できます。つまりZunのコンテナまたはPodは、プライベートIPアドレス、フローティングIPアドレスを持ちます。またパブリックレジストリ(Docker hubなど)やプライベートレジストリ、Glanceに保存されたイメージを使用可能とのことです。またKeystoneのプロジェクトごとに独立させることができるとのことです。

 Zunのアーキテクチャについて説明します。コントローラノード上の「Zun API」がコンピュートを管理し、コンテナのスケジューリングを行います。コンピュートノード上の「Zun Compute」はローカルのコンテナを管理し、コンピュートノードのリソースの追跡も行いながら、直接Dockerの操作をします。

図16 Zunのアーキテクチャ
図16 Zunのアーキテクチャ

 ZunとNovaは同じリソースプロバイダに対して割り当てを要求するため、リソースの取り合いや不整合が起きないとのことです。

 ZunはContainerや、Capsuleと呼ばれるPodのようなコンテナのグループに対し、以下のような属性を持ち、操作をすることができます。

Container(一つのコンテナ)
  • プロパティ:イメージ、CPU、メモリ、ディスク、コマンド、環境、アドレス、セキュリティグループなど
  • 操作:create、update、delete、start、stop、kill、network-attach、exec、attach、log、…
Capsule(ネットワークやボリュームを共有しているコンテナのグループ)
  • プロパティ:containers、cpu、memory、…
  • 操作: create、delete、…

 今後も、仮想マシンとコンテナの両方を提供する機能は需要が見込まれそうですので、プロジェクトの定期的なアップデートを見守りたいところです。


  • ブックマーク
  • LINEで送る
  • このエントリーをはてなブックマークに追加

著者プロフィール

  • 清藤 直也(NTTデータ)(キヨフジ ナオヤ)

    NTTデータ システム技術本部。 社内のプロジェクトへ開発環境を提供する、OpenStackを用いたプライベートクラウドサービスの開発、運用に従事。現在は、社内プライベートクラウドサービスで用いられているOpenStack基盤のリソース有効活用方法について検討している。

  • 保立 純志(NTTデータ)(ホタテ ジュンシ)

    NTTデータ システム技術本部。 OpenStackコミュニティでのNFV関連機能(Tacker)の開発活動に従事する。また社内のプライベートクラウド「統合開発クラウド」へのOpenStackの導入やアップデート対応等の運用を担当している。

バックナンバー

連載:「Open Infrastructure Summit Shanghai」レポート
All contents copyright © 2005-2020 Shoeisha Co., Ltd. All rights reserved. ver.1.5