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」では、仮想化が多重になることによるオーバヘッドやネットワークの接続、クラスタの乱立による運用コスト増加といった課題がありました。
そこで、リソースプールを共有化し、OpenStackのVMとKubernetesのPodとが同じレイヤで共存するアーキテクチャを提案しました。そのアーキテクチャを実現するのが、Zunプロジェクトです。KubernetesとOpenStackの組み合わせはAirshipやStarlingXといったプロジェクトでも実現されていますが、これらは「OpenStack on Kubernetes」を実現するものであり、Zunは「OpenStackとKubernetesの同レイヤでの共存」を実現しようとしている、というのが端的な違いの説明となるでしょう。
ZunはVMを使用せずに、コンテナのプロビジョニングとマッピングのAPIを提供することができます。OpenStack上のコンピュートノード、NeutronのL2ネットワーク、Cinderブロックストレージを共有できます。つまりZunのコンテナまたはPodは、プライベートIPアドレス、フローティングIPアドレスを持ちます。またパブリックレジストリ（Docker hubなど）やプライベートレジストリ、Glanceに保存されたイメージを使用可能とのことです。またKeystoneのプロジェクトごとに独立させることができるとのことです。
Zunのアーキテクチャについて説明します。コントローラノード上の「Zun API」がコンピュートを管理し、コンテナのスケジューリングを行います。コンピュートノード上の「Zun Compute」はローカルのコンテナを管理し、コンピュートノードのリソースの追跡も行いながら、直接Dockerの操作をします。
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、…
今後も、仮想マシンとコンテナの両方を提供する機能は需要が見込まれそうですので、プロジェクトの定期的なアップデートを見守りたいところです。
