KubernetesのベースにもなったGoogleのインフラストラクチャオーケストレーションツール「Borg」は、内部的にgVisorを使用している。Googleの担当者は、内部的にgVisorで実行しているのがどのアプリなのか具体的な名前は明かしていないが、「MySQL」や「WordPress」「Jenkins」など、コンテナ環境においてチームやテナント間で共有するオープンソースのアプリにgVisorは役立つと述べた。

　gVisorは、Microsoftの「Hyper-Vコンテナ」、VMwareの「vSphere Integrated Containers」、OpenStackの「Kata Containers」など他のコンテナ分離製品と原理は似ている。Googleによれば、gVisorはこうした他のアプローチより軽量であり、それはフルハイパーバイザーに依存せず、効率のよい「Linux」カーネルを使用するからだという。

　IDCのアナリスト、ゲーリー・チェン氏は「ユーザー空間で実行するカーネルなので、（他のアプローチより）非仮想化コンテナに近い」と話す。

　企業のIT部門からは、従来のVM方式からコンテナセキュリティ分離に変えたいという声が出始めている。451 Researchが2017年にコンテナ利用企業201社を対象として実施した調査によると、コンテナを早期に採用した企業の多くがセキュリティ分離のために従来のVMでコンテナを実行しているが、別の方式に変えたいという企業もあることが分かった。この調査では、コンテナをベアメタルで実行していると答えた企業はなく、回答企業の36％がVMでコンテナを実行していると答えた。一方、今後14～24カ月にVMでコンテナを実行すると答えた企業はやや少ない32％で、今後14～24カ月にベアメタル上でコンテナを実行すると答えた企業は2％だった。

　451 Researchのアナリスト、ジェイ・ライマン氏は次のように説明する。「VMでコンテナを実行する企業はスケーラビリティの壁にぶつかり、ベアメタルでコンテナを実行するときのような安定性や効率性が得られない。また、VMのライセンスの問題や、従来のVMのプロバイダーに対する内部的な抵抗もある」

　これまでは、ハイパーバイザーベースのコンテナ分離製品はコンテナ管理の中でニッチ市場だったが、GoogleがKubernetesの開発元として獲得した認知度は大きな強みになる。

　「Googleが出すコンテナ関連製品の意義は大きい。Kubernetesの存在に加え、Google自体がこの業界の先進的なコンテナ利用者だからだ」（ライマン氏）

残る課題の解決にはさらなる開発が必要

　現段階のgVisorは、軽量であることと引き換えに難点もある。標準Linuxカーネルには300種以上のシステムコールがあるが、gVisorは現在、200種にしか対応していない。gVisorで未対応のシステムコールに依存するアプリ（「Elasticsearch」「NGINX」「PostgreSQL」など）は今後の強化を待たなければならない。

　また、「Google Kubernetes Engine」（GKE）などクラウドまたはオンプレミス用コンテナオーケストレーションユーティリティーにはまだgVisorが組み込まれていない。そのため現時点では、gVisorを使うコンテナのマルチクラウド移植性には限界がある。

　ビショップ氏は次のように語った。「Dockerコンテナは外部のハイパーバイザー層を関知しないため、デプロイするアーティファクトが同じなら移植性は損なわれない。しかしハイパーバイザー層の異なる複数のクラウド間でもシームレスに移植できるかどうかは分からない。過去の例を考えると、そううまくいかないのではないだろうか」