OpenStackとコンテナの技術動向

　今回のサミットには、運用者の視点でOpenStackを含めたコンテナセキュリティ、クラウド基盤の運用性とコンテナ、VMとコンテナのハイブリッド環境を中心に参加してきました。その中で気になったトピックを挙げて行きたいと思います。

コンテナセキュリティ

Kata Containers Cakes

　今回のサミットで、Zuul（の独立）と並んで目玉の一つとなったのは、Kata Containersの正式リリースです。先日のOpenStack ops meetup TokyoやKubeCon EU 2018でも紹介されていましたが、今回晴れてバージョン1.0としてお披露目されました。

Kata Container concept diagram（出典: Katacontainers The speed of containers、the security of VMs^※1 P.12、P.13）

※1: https://katacontainers.io/docs/Kata-Containers-On-boarding-Deck-for-Website01022018.pdf

　Kata Containersは超軽量の（と謳っている）仮想マシンを挟むことで、悪意や脆弱性のあるコンテナからホストへの侵入を防ぐ方式を採っており、セキュリティの大幅な強化に繋がります。

　VMの起動時間の課題に対しては、VM起動の横でコンテナイメージのインポートやストレージのマウントを並列化することで高速化しているそうですが、テクニカルな概要はワークショップで説明に使われていた資料^※1を読むのがよいでしょう。

　ちなみに、Kataというネーミングは、ギリシャ語で「信託」を意味するそうです。

　コンテナランタイムのセキュリティについては、現状これというデファクトスタンダードはありませんが、以下のようにKata Containers以外にも複数の方式が提案されています。

Micro VM （Kata Containers）

• 極小のVM上にコンテナを起動して動作させる
• セキュリティ隔離は強固だが、オーバーヘッドが懸念される
• OpenStack Foundation傘下のため各プロジェクトとの親和性が期待できる

Rootless^※2 （containerd/runc）

※2: https://www.slideshare.net/AkihiroSuda/rootless

• containerd/runcの非root権限による動作
• 複数の方式が提案されているが、ユーザ権限で動作させることで、ホストやランタイムの脆弱性等へのリスク対策になる
• 方式によるが、実行速度面の期待ができそう
• NTT研究所の須田氏により、性能測定結果^※3が投稿されている

※3: https://github.com/rootless-containers/runrootless/issues/14#issuecomment-393048682

Sandbox （gVisor^※4: containerd/runsc）

※4: https://github.com/google/gvisor

• KubeCon 2018 EUで突然のお披露目
• KVM方式とptrace方式（システムコール制御）があるため、上記2方式とそれぞれ重なる所はあるが、ptrace方式はシステムコールのエミュレート（置換）をgVisorが行なっている
• Google謹製のためKubernetes（以下K8s）との親和性が高くなる方向に開発されると想定される

その他のセキュリティに関する講演

　コンテナセキュリティを基礎から詳しく述べている講演としては「Intro to Container Security」^※5がお勧めです。

※5: https://www.openstack.org/summit/vancouver-2018/summit-schedule/events/21021/intro-to-container-security

クラウド基盤の運用性とコンテナ

　基盤の管理という視点で今回OpenStack Summitでお披露目となった新プロジェクトで、おもしろいなと感じたのはAirship / Kubicornです。

Airship

　Airshipは、AT&TやSK Telecom主導により開発が進められている、クラウド基盤を統合的に管理するツール群の総称です。

　クラウド基盤の構成管理に関する類似プロジェクトとしては、OpenStack Helmがあげられますが、Airship（とその中心サブプロジェクトのArmada）はそもそもOpenStack Helmから始動したプロジェクトでもあります。

　Airshipは、宣言的記述によるコンテナ管理で、OpenStack基盤のデプロイだけでなく、ライフサイクル全体のワークフローを纏めて管理する目的で作られています。本質的には、OpenStackに特化したものではなく、様々なプロジェクトに適用可能です。

Software Layers of the AT&T Network Cloud Reference Design（出典: Airship | A New Open Infrastructure Project for OpenStack Figure1 - Software Layers of the AT&T Network Cloud Reference Design^※6）

※6: http://about.att.com/content/dam/inside_connections_blogdocs/Whitepaper%20-%20Airship%20a%20New%20Open%20Infrastructure%20Project%20for%20OpenStack%20v1.0.pdf

　図中緑色は外部のオープンソースプロジェクトであり、図中青色がAirshipのサブプロジェクト群です。一見して分かるように、大別するとK8s、OpenStack、Airshipという3つのエコシステムの組み合わせであることが分かります。

　なお、入門用にAirship in a bottle^※7が用意されています。

※7: https://github.com/openstack/airship-in-a-bottle

Kubicorn

　Kubicorn^※8は、Kris Nova氏によるK8sマルチクラスタ管理のソフトウェアです。

※8: https://github.com/kubicorn/kubicorn

　類似プロジェクトとしてはOpenStack Magnumがありますが、Kubicornは基盤をOpenStackに限定しておらず、マルチプラットフォーム対応です。開発者は開発の経緯として、TerraformやKopsの経験を経て、（Kopsの）コードの大きさに疲れ気味になり独自に開発を始めた、と述べています。内部的にKubeadm（公式クラスタ管理ツール）やCluster API（Kubernetesクラスタ自体の作成や削除を制御するもの）を利用しており、シンプルな構造になっています。

　K8sマルチクラスタの是非については、ユーザ企業各社がシングルクラスタマルチテナント化に舵を切っている傾向がある一方で、諸般の事情から複数クラスタの運用を選択している企業もあります。マルチクラスタを運用する場合であっても、ユーザ企業としてKaaS（Kubernetes as a Service）サービスを利用して終わらせていることも多く、自身で敢えて複数管理するというユースケースに合致するユーザは絞られそうです。

VMとコンテナのハイブリッド環境

　VMとコンテナの管理統合/接続については、様々な方式が講演されていました。

Istio / CalicoでVMとコンテナを接続する

　「Bringing Istio to Openstack^※9」セッションや「Kubernetes and Openstack unified networking using Calico」ワークショップでは、OpenStack上のVMをIstioでK8s上のコンテナと接続したり、CalicoでOpenStackとK8sを接続する構成が説明されていました。前者の例ではサービスメッシュにVMを所属させるためにK8sのSecretを渡す、あるいはKubernetes上のサービスにVMがアクセスするためにDNS Relay等を利用するなど、構成要件がなかなか大変そうに見受けられました。

※9: https://www.openstack.org/videos/vancouver-2018/bringing-istio-to-openstack

K8sから透過的にOpenStack上のVMを利用する

　「Friendly coexistence of Virtual Machines and Containers on Kubernetes using KubeVirt^※10」セッションではKubevirtを用いてK8sからOpenStack上のVM（上のコンテナ）を管理する方法が、「Build Your Serverless Container Cloud with OpenStack and Kubernetes^※11」セッションではKubevirtとZunを用いてServerless環境を構築する方法が説明されていました。

※10: https://www.openstack.org/videos/vancouver-2018/friendly-coexistence-of-virtual-machines-and-containers-on-kubernetes-using-kubevirt

※11: https://www.openstack.org/videos/vancouver-2018/build-your-serverless-container-cloud-with-openstack-and-kubernetes

　OpenStackの周辺エコシステムと絡めると、「誰がどれをどう利用する」「何をどこにどう載せる」というクラウド基盤の混載や連携が複雑化、乱立する状況となっていて、リファレンスモデルを整理する必要がありそうです。

まとめると

　OpenStackそのものは過渡期を過ぎて成熟期に入り、新規性よりも運用性へのフォーカスが見て取れます。その中で、コンテナ技術との統合については試行錯誤が繰り広げられている状況であると感じました。この状況は、K8sやランタイムのエコシステムの状況も鑑みる^※12に、今後1〜2年程度は続くのではないかと見ています。

※12: つい先日も、K8sをYAMLで管理できるソリューションがGoogleから提案されており、当面ツール/フレームワークの取捨選択と栄枯盛衰は混乱が続きそうです（https://kubernetes.io/blog/2018/05/29/introducing-kustomize-template-free-configuration-customization-for-kubernetes/）