コンテナとOpenStackの活用

導入

あなたがプライベートクラウドのインフラを、ゼロからすべて構築する任務を負うことを考えてみてください。あなたは限られた予算、小さくも献身的なチーム、そして奇跡を起こすことを求められています。

数年前、アプリケーション実行環境を構築するには仮想マシンと、レガシーアプリケーションのため数台のベアメタルマシンを使ったものでした。インフラは進化し、仮想マシンは効率性と迅速性を素晴らしい水準に引き上げましたが、仮想マシン単体ではアプリケーション開発のためのアジャイルアプローチの要求に完全に見合いませんでした。仮想マシンは、引き続き多くのアプリケーション実行の基盤として提供されるでしょう。ですが、斬新なアプリケーション開発と適用のために、開発者はますますコンテナの最新動向を追いかけています。なぜなら、コンテナは迅速性と効率性の水準を向上させるからです。

DockerやKubernetes のようなコンテナ技術は、コンテナ化されたアプリケーションを構築するための先行標準になりつつあります。これらの技術は開発の迅速性を制限する複雑さから組織を開放する助けとなります。コンテナ、コンテナインフラ、そしてコンテナ展開技術は、いくつもの異なった利用例に適用可能で、大変パワフルな抽象化能力があることを、自ら証明してきました。Kubernetesのようなインフラを使うことで、アプリケーションデリバリにコンテナだけを利用するクラウドを実現できます。

しかし、最新のプライベートクラウドはコンテナだけではなく、コンテナはすべてのワークロードや利用方法に向いているわけではありません。今日、多くのプライベートクラウドインフラは、インフラ管理のためのベアメタルマシン、古いアプリケーションのための仮想マシン、そしてより新しいアプリケーションのためのコンテナを取り扱う必要があります。これら三つのアプローチに対応し、管理し、おーけストレートする能力は、運用効率化のカギとなります。

OpenStackは、プライベートクラウドを構築するための現在最高の利用可能なオプションです。ネットワーク、ストレージ、そしてコンピュートインフラをマネージする能力があり、さらに仮想マシン、ベアメタル、そしてコンテナを一つの制御プレーンからサポートします。Kubernetesは、最も人気のあるコンテナオーケストレーターであり、アプリケーションデリバリを変えてきましたが、堅牢なクラウドインフラの可用性に依存しており、OpenStackはアプリケーションをホストするため、もっとも包括的なオープンソースインフラを提供します。OpenStackのマルチテナントなクラウドインフラは、いくつかのインテグレーションポイント、デプロイメントソリューション、そして複数のクラウドをまたがり連携させる能力など、Kubernetesと相性がよいものです。

この文書では、コンテナがどのようにOpenStackと作用するか探索していきます。多様なユースケースの検証や、オープンソースプロジェクトの概要について、OpenStackに限らず、コンテナを適用しやすく、効率化しやすくするその他の技術についても紹介します。

I. OpenStackにおけるコンテナのハイレベルビュー

コンテナとOpenStackが関係する三つの主要なシナリオがあります。

最初のシナリオは、インフラコンテナと呼ばれるもので、オペレータがクラウドインフラの適用や管理、運用をしやすくするため、コンテナを利用します。このシナリオにおいてコンテナは、ベアメタルインフラ上にセットアップされ、ホスト資源への特権アクセスを許可されます。このアクセスはコンピュート、ネットワーク、ストレージといった資源に対する直接的なアドバンテージを、コンテナに許可します。これらの資源は通常、コンテナランタイムにより、ユーザから隠ぺいされるものです。コンテナは、しばしば複雑になるアプリケーションが必要とする依存関係を隔離します。一方で、インフラアプリケーションに対しては、基盤となるシステム資源の管理や操作を直接行うことを、依然として許可します。サービスのアップグレードが必要になったとき、一緒に配置されるサービスを破壊するような依存関係の変更を行うことなく、アップグレードは行われます。

最近のOpenStackのバージョンは、このインフラコンテナモデルを取り込んでいます。そして現在、オーケストレーションツールとコンテナ化されたサービスの組み合わせと共に、OpenStackの全ライフサイクルを管理する一般的な方法になっています。インフラコンテナは、コンテナオーケストレーション技術を使い様々な課題をオペレーターが解決することを実現します。とりわけOpenStackを含む既存のソフトウェアを高速に反復しアップグレードする際に発生する課題です。OpenStackをコンテナの中で実行することは、オペレーターがDay 2に発生するチャレンジを解決するのに役立ちます。これには、サービスのための新しいコンポーネントを追加したり、速やかにソフトウェアバージョンを更新したり、マシンやデータセンターをまたがって高速なローリングアップデートを行うことを含まれます。このアプローチは、OpenStackの展開や更新の問題に対し、コンテナの迅速性をもたらします。

2番目のシナリオは、クラウドインフラ上でコンテナ化されたアプリケーションフレームワークをホスティングする場合に関してです。これは、Docker SwarmやKubernetesといったコンテナオーケストレーションエンジン（COE）、軽量のコンテナにフォーカスしたサービス、そしてサーバレスなアプリケーションプログラミングインターフェイス（API）を含みます。OpenStackコミュニティは、ベアメタルやVMを問わず、セキュアでテナント隔離されたクラウドホストの上で、コンテナ化アプリケーションの提供が可能となるよう努力してきました。このシナリオでは、ストレージやロードバランシング、アイデンティティといったOpenstack APIの利点を、Kubernetesのようなプロジェクトにもたらすドライバによって促進されます。これらの機能によって、開発チームは新しいコンテナ化アプリケーションを書き、速やかにKubernetesクラスタをOpenStackクラウド上に展開できます。これは、彼らのアプリケーションを商用環境へデプロイする強固な自動化を伴う、開発やテストそしてコードのデバッグに必要なリソースを提供する、完全なアプリケーションライフサイクルを提供するソリューションです。

最後のシナリオは、独立したOpenStackとCOEのデプロイの間の相互作用を考えます。このホワイトペーパーでは特に、Kuberunetesクラスターのことについて記述します。OpenStackとKuberunetes双方にまたがるAPIの一致制と相互運用性は、このシナリオにおける主要な成功の源泉です。例えば、Kuberunetesに OpenStack Cinderがホストするボリュームを直接アタッチすることは可能ですし、OpenStack Keystoneを認証と認可のバックエンドとして利用することも可能です。さらに、OpenStack Neutron を OpenStack Kuryrと共に使って接続させ、ネットワークオーバーレイとして利用することも可能です。逆に言えば、Openstackクラウドにとって、Calicoのようなプロジェクト用のNeutronドライバーを使い、Kuberunetesクラスタに対して、同じネットワークオーバーレイを共有することが可能なのです。3番目のシナリオは、クラウドサービスの提供方法（KuberunetesやOpenStack）にさほど注目せず、いかに独立したサービスが相互作用するかをより注目します。

II. OpenStack コンテナのインテグレーションポイント

コンテナ上へのOpenStackインフラのデプロイ

最初にお伝えしておきたいことは、OpenStackはコンテナの普及にともない大きな変化をしてきたということです。なぜならば、コンテナはインフラストラクチャコードの管理に対し、新しいアプローチを可能にしたからです。以前の管理ストラテジーには、重い黄金のマシンイメージの作成と管理の双方が必要でしたし、もろい状態維持のためのコンフィグ管理システムが必要でした。難易度を上げていたものの正体は、サービス集合の管理です。これはどれも、リリースとリリースの間に変化する、自分自身の依存関係を必要としました。アプリケーション隔離のいくつかのやり方なしには、不可能でないにしても依存関係の解決は難しくなります。

インフラストラクチャコンテナは、OpenStackデプロイメントの新しいプロジェクトが、エレガントにこの依存関係の問題を解決するという両立を実現可能にしました。軽量、独立、自己完結、そして特徴的なこととしてステートレスであるアプリケーションを使うことで、クラウドオペレーターは複雑な制御プレーンを展開する際に、ものすごい柔軟性を得ることが出来ます。コンテナランタイムとオーケストレーションエンジンを結合されることで、インフラストラクチャコンテナは、複雑で高い可用性を持つインフラの迅速な展開、保守、そして更新を可能にします。

OpenStackクラスターの構築において、デプロイメント技術の選択にはいくつか考慮点があります。オペレーターは Linux Containers（LXC）やDockerを彼らのベースコンテナとして選択し、事前構築済みかカスタム構築されたアプリケーションコンテナを利用し、オーケストレーションのための伝統的なコンフィグ管理システムか、あるいはKuberunetesのようなよりモダンなアプローチを選択することが出来ます。表1には、既存のOpenStackデプロイメントプロジェクトと、それらの基礎的な技術を要約しています。

基礎的なデプロイメントシステムはそれぞれ、OpenStackコードの一組のコンテナを構築するため、そしてサービスをサポートするために、異なるアプローチをとっています。 OpenStack Ansible（OSA）とKollaプロジェクトは、LOCIがプロジェクトアプリケーションコンテナの構築に焦点を当てる一方、特定のオーケストレーションシステムを考慮することなく、彼ら独自のプロジェクトがホストする構築システムを持っています。ハイレベルな観点からの差分は:

1. OSAは、低レベルのLXCコンテナを利用するという点で特異なものです。そしてLXCアプリケーションコンテナの作成のため、カスタム構築システムを持っています。
2. Kolla構築システムは各サービスごとに一つDockerコンテナを生成し、OpenStack展開の初期化と管理を担うコンテナのサポートを前に進めます。Kollaコンテナは、基礎になるオペレーティングシステム、ソースやパッケージのインストール、そして更なるカスタマイズのためのテンプレートエンジンの選択を行うことで、高度に設定可能です。
3. OpenStackアプリケーションコンテナを構築する最後の選択肢は、LOCIです。LOCIはDockerコンテナを構築し、それぞれのプロジェクトに対てコンテナを一つずつ提供することもしています。LOCIは、コンパクトでセキュアなコンテナを迅速に生成することに焦点を当てています。これは、すべての共通ディストリビューションのため、デプロイメントシステムによる構築の、基礎的な利用を期待されているからです。

ベアメタルインフラストラクチャ - OpenStack とブートストラップ問題の解決

すべてのクラウドの基礎には、インフラストラクチャサービスを提供するベアメタルサーバのデータセンターが存在します。「サーバーレスコンピューティング」であってもデータセンター内のハードウェア上にあるクラウドの上で、ソフトウェアを実行しています。ハードウェアインフラストラクチャの起動法に関する問題は、致命的な問題です。OpenStackソフトウェアは、クラウド的な品質をベアメタル管理に与える方法を取り扱うため、比類なく選出されるものです。

OpenStack Ironicは、bare-metal as a serviceを提供します。スタンドアロンなサービスとして、Ironicはベアメタルノードを見つけられ、それらを管理データベース上でカタログにし、すべてのサーバライフサイクル、すなわちエンロール、プロビジョン、保守、そして廃止を含んだ管理を行います。OpenStack Novaのドライバとして使うとき、そしてOpenStackサービスの一式と紐づけられるとき、Novaはすべてのベアメタルインフラストラクチャを管理するため、パワフルでクラウド的なサービスを実現します。

このことは課題を提起します：どのようにして、一つのブートストラップOpenStackサービスは、ベアメタルインフラストラクチャを管理するのでしょうか？ひとつの典型的なソリューションは、種を設置するため、前節で記したコンテナベースのインストールツールと同じようなものを利用するというものです。この種は、しばしば「アンダークラウド」と呼ばれますが、あたかも仮想化クラウドであるかのように、ベアメタルクラスターの管理を完全に自動化するために利用できます。

これは、単にOpenStackによる仮想化をベアメタルクラウド上で実行するだけに留まらず、ベアメタル環境にKuberunetesだけのインストールを実行するのにも使えます。これにより、アイデンティティ、ストレージ、ネットワーク、そして他のOpenStackサービスを通じ利用可能なクラウドAPIのすべての利点を使うことが出来ます。

OpenStack上でのコンテナベースアプリケーションの提供

コンテナとベアメタルインフラストラクチャの、どちらのインフラストラクチャも重要です。しかし、多くの人はコンテナのことを考えたとき、アプリケーションコンテナのことを考えているようです。隔離、カプセル化、保守の容易さなどコンテナがもたらす特徴は、アプリケーションを供給するにあたり、アプリケーションコンテナを理想的なソリューションとするでしょう。しかしながら、ベアメタル、パブリッククラウド、プライベートクラウドのいずれかから、ホストサーバのプラットフォームを提供するために、コンテナは依然として必要です。

Kuberunetesはアプリケーションを提供するプラットフォームであり、永続ストレージやロードバランサー、ネットワーク、そして動的配置のコンピュートノードのような、クリティカルなインフラの提供を自動化する、クラウドAPIと共によく作用します。OpenStackは、オンプレミス型のプライベートクラウド、あるいは利用可能なパブリックもしくはマネージド型のOpenStackクラウドを通じ、クラウドインフラを提供します。

OpenStackは、Kuberunetesのための最初の上流クラウドプロバイダでした。これは、活動的な開発チームが"Kubernetes/Cloud Provider OpenStack"プラグインを保守していたことによるものです。このプラグインにより、KuberunetesはCinderブロックストレージやNeutron、Octaviaロードバランサー、そしてNovaを使ったコンピュート資源の直接的な管理といった利便性を活用することが出来ます。Kubernetes環境にドライバーをデプロイするのと同じくらいシンプルに、プロバイダーを用いることで、ドライバをロードするようフラグを設定し、ローカルユーザのクラウド認証を提供します。

KuberunetesやほかのアプリケーションフレームワークをOpenStack上にインストールするソリューションはいくつかあります。コンテナフレームワークを実現するもっとも簡単な方法の一つは、Magnumを使うことです。これは、Kuberunetesを含む、いくつかのアプリケーションプラットフォームの選択肢を背景にした、完全なマネージドクラスタをデプロイするシンプルなAPIを提供します。これはOpenStack APIと、クラウドプロバイダプラグインを利用するKuberunetes展開の例です。例えば、200以上の独立、または連携したCERNのOpenStackオンサイトクラウドや、パートナークラウド上にもあるKuberunetes環境において使用中です。もしあなたがお好みのOpenStackクラウドでMagnum APIを利用可能でなければ、あなたは他のKuberunetesインストールツールを利用することが出来ます。それは、 kubeadm、Kubernetes Anywhere、Cross-Cloud、またはKubesprayといったツールを、あなたのKuberunetesクラスタをOpenStack上にインストールしたり管理するため使うことが出来ます。これらはそれぞれ標準Kuberunetesを使うため、ストレージやロードバランスの利便性を得るためクラウドプロバイダインターフェイスを有効にするのも簡単です。

Zunは、もう一つのOpenStackプロジェクトであり、サーバやクラスタの管理をすることなく、個々のコンテナを管理する軽量コンテナサービスAPIを提供します。OpenStackにホストされたKuberunetesクラスタは、弾力的です。なぜなら、Nova APIを直接通じてクラウドリソースをクラスタに追加、あるいは削除することにより動的に大きさを変えるからです。その他にも、KuberunetesはOpenStack Zunに対しコンテナバックエンドとして使われ、Podインフラストラクチャの管理をZunで行います。軽量でマルチテナントなコンテナサービスAPIを、直接サーバを作る必要なくコンテナを稼働するために提供します。NeutronとCinderの直接インテグレーションは、ネットワーキングとボリュームを個々のコンテナのために提供するため使われます。

最後に、QinlingプロジェクトはLambda、Azure Functions、Google Cloud Functionsと似たようなサーバレス機能をサポートする、プラットフォームの実現に焦点を当てた「Function as a Service」を提供します。これはコンテナの管理をさらに抽象化し、イベント駆動、オンデマンドにスケールするサーバレスコンピュートの体験と共に、ユーザの開発を加速します。Qinlingは、KuberunetesやDocker Swarmといった、異なるコンテナオーケストレーションのためのバックエンド、多様な人気のあるファンクションパッケージ、ローカルストレージやOpenStack Swiftのようなストレージバックエンドをサポートします。

Kata Containers - 仮想化を通じたセキュアなアプリケーション

Kata コンテナは新しいオープンソースプロジェクトであり、この新規実装は、コンテナエコシステムの中でシームレスに統合された軽量仮想マシンの新しい実装です。Kata コンテナは、コンテナのように軽量で速く、コンテナ管理層と共に統合されます。この中には、DockerやKubernetes (k8s) といった、よく利用されるオーケストレーションツールがあります。さらに、VMのセキュリティ優位性もまた提供されます。Kataコンテナは、Open Container Initiative (OCI)標準に従っています。この標準は、OpenStackファウンデーションがアクティブに活動しているものです。Kataコンテナは, OpenStackファウンデーションにホストされてますが、OpenStackプロジェクトから分離されたプロジェクトとして、自治の仕組みと自身のコミュニティを持ちます。

業界のコンテナへの以降は、信頼されたワークロードと信頼されないワークロードが混在するマルチテナント環境の中で、ユーザのワークロードを確保するという独自のチャレンジが存在します。Kata Containersは、ハードウェアを背景にした隔離を、各コンテナやポッド内のコンテナの集合のための境界として利用します。このアプローチは、伝統的なコンテナアーキテクチャにおける、共有カーネルに関するセキュリティの関心に焦点を当てたものです。

Kata Containersは、長時間実行されるWebサーバーアプリケーションだけでなく、継続的インテグレーション／継続的デリバリーなどイベントベースとオンデマンドのデプロイメントに最適です。 また、従来の仮想化された環境のコンテナへの移行も簡単に行えます。従来のゲストカーネルやデバイスパススルー機能をサポートしています。 Kata Containersは、セキュリティ、スケーラビリティ、リソース使用率の向上を実現すると同時に、全体的に単純化されたスタックにつながります。

OpenStackとKubernetesの並列したインテグレーション

オープンソースプラットフォームを選ぶ主要な利益の一つは、これらのプラットフォームの標準デプロイメントにまたがる、インターフェイスの安定性にあります。OpenStackファウンデーションとCloud Native Computing Foundation (CNCF) の双方は、OpenStackクラウドとKuberunetesクラスタの間に相互運用性標準を維持しています。これには、ライブラリやアプリケーション、そしてドライバがすべてのプラットフォームをまたがり、どこにデプロイされたかに関わらずに動作することを保証します。これにより、並列したインテグレーションの機会を作り、OpenStackとKuberunetesの双方にお互いに提供されるリソースのアドバンテージをもたらします。

KuberunetesコミュニティのOpenStack Special Interest Group （SIG-OpenStack）は、クラウドプロバイダOpenStackプラグインを保守しています。さらにOpenStack上にKuberunetesを稼働させるクラウドプロバイダインターフェイスの追加により、Kuberunetesが個々のOpenStackサービスのアドバンテージを利用するいくつかのドライバを保守します。このドライバには以下のものが含まれます。

• 二つのスタンドアロンなCinderドライバ。フレックスボリュームドライバは、ドライバに接続するために実行ベースのモデルを使います。そしてコンテナストレージインターフェイス（CSI）ドライバは、コンテナオーケストレーションシステムのために標準インターフェイスを使い、任意のストレージシステムをコンテナワークロード向けに提供します。70以上のストレージドライバのサポートにより、これらのドライバは、単一のCinder APIを通じて、バトルテストを経たプロプライエタリとオープンソースストレージの資産に接することが出来ます。
• Keystoneに向けのWebhookベースの認可と認証インターフェイス。各モード、認可と認証、はそれぞれと独立して構成することが出来ます。作業は進行中ですが、このインターフェイスは、OpenStack Keystoneを使いKuberunetes RBACを支援する、緩やかなマルチテナンシをサポートします。

OpenStackとKuberunetesの双方は極めて動的なネットワークモデルをサポートします。これは様々なドライバに支援されたものです。これらの標準的なネットワークインターフェイスにより、スタンドアロンのOpenStackとKuberunetesクラスタを強固なネットワークのインテグレーションと共に構築することが容易になります。OpenStackの中では、Kuryrプロジェクトが共通ネットワークインターフェイス（CNI）を生成し、NeutronとDocker、Kuberunetesを接続します。一方で、Calicoのような外部のプロジェクトは、標準的なNeutron APIを通じ人気のあるKuberunetesネットワークオーバーレイへの直接的なアクセスを提供します。

IV. まとめ

過去数年間、コンテナ化は開発者と組織の双方に重要なツールとなってきています。OpenStackは、モジュラー設計と拡大するコミュニティを活用し、コンテナ技術をいくつものレイヤで統合してきました。これはコンテナとOpenStackを商用環境に持ち込もうとするいくつもの組織と、コンテナに新しい機能をもたらそうとするプロジェクトの数、双方に見ることが出来ます。OpenStack FoundationはOpenStack内で新技術を統合し、活用できるようにするために努力しており、コンテナは、その約束の重要な例です。

より学習するために、 Containers Landing Page を訪れましょう。ここには、ドキュメントのコピーと共に、OpenStackとコンテナの統合にフォーカスした多くの映像へのリンクがあります。Kubernetes SIG-OpenStackはSlackチャンネル、メーリングリストがあり、もしあなたがKubernetesとOpenStackを統合するコミュニティと直接関わるならば、週次ミーティングもあります。

VI. 執筆者

OpenStack Kubernetes SIG コミュニティーのメンバー

• Jaesuk Ahn, SK Telecom
• Christian Berendt, Betacloud Solutions GmbH
• Anne Bertucio, OpenStack Foundation
• Pete Birley, AT&T
• Chris Hoge, OpenStack Foundation
• Lingxian Kong, Catalyst Cloud
• Hongbin Lu, Huawei
• Daniel Mellado, Red Hat, Inc.
• Allison Price, OpenStack Foundation
• David Rabel, B1 Systems GmbH
• Sangho Shin, SK Telecom
• Davanum Srinivas, Huawei
• Luis Tomás, Red Hat, Inc.
• Sam Yaple, Verizon Digital Media Services
• Mikhail Fedosin, Red Hat, Inc.
• Flavio Percoco, Red Hat, Inc.

エディター

• Brian E Whitaker, Zettabyte Content LLC