Dockerコンテナ時代の第二章～Kubernetesの成熟とエコシステム発展の時代
Dockerの登場により急速に普及をはじめたコンテナ型仮想化の技術は現在、DockerコンテナそのものからKubernetesを軸としたオーケストレーションツールへと主役が移ってきています。
その様子は2017年12月に公開した記事「Dockerコンテナ時代の第一章の終わり、そして第二章の展望など」で紹介しました。
この記事の公開から2年が経過し、現在のコンテナ型仮想化技術は、マイクロサービスやクラウドネイティブなどの文脈とともにエンタープライズな分野でも使われるメインストリームな技術へと確実に進み続けています。
本記事では前記事で描いたDockerコンテナ時代の第一章に続く第二章として、コンテナ型仮想化技術のここ2年半ほどの動向をPublickeyなりにまとめてみました。
Docker 1.0の到達とKubernetesの登場
まずはDockerとKubernetesの登場とその後の主要なできごとを、2017年の終わりまで簡単に振り返りましょう。
2013年3月26日に当時のdotCloud社（現Docker社）が、Dockerをオープンソースとしてはじめて公開します。
そして2014年6月9日（米国時間）にはDocker 1.0が登場。
奇しくもその翌日、2014年6月10日にGoogleがKubernetesをオープンソースとして公開します。
公開から約1年後の2015年7月にはKubernetesがバージョン1.0に到達。と同時にベンダから独立した組織である「Cloud Native Computing Foundation」が設立され、Kubernetesの開発主体がGoogleから移管されました。
Kubernetes 1.0 Launchの模様。オライリーの動画から2016年10月、Kubernetesの開発チームは独自のコンテナランタイム「cri-o」を開発中であることを表明。コンテナランタイムにDocker以外の選択肢があることの具体性が高まります。
2017年3月に登場したKubernetes 1.6は、etcd3とgRPCを採用したことで大幅に性能向上。さらに名前空間の分離や物理ノードの考慮などの機能向上も果たしました。
2017年7月にはOpen Container Initiativeによるコンテナランタイムとコンテナイメージの標準化作業が「OCI 1.0」完了。
そして、2017年10月に開催されたDockerCon Europe 2017で、Dockerが製品にKubernetesを統合することを発表。コンテナオーケストレーションの事実上の標準がKubernetesに決定した瞬間です。
10月にはMicrosoft AzureがKubernetesのマネージドサービス「Azure Container Service」（AKS）を発表。Google Cloudはこれまで提供してきたKubernetesベースのGoogle Container Engineを「Google Kubernetes Engine」（略称GKEはそのまま）にサービス名を変更。そして11月にはAWSも「Amazon Elastic Container Service for Kubernetes」（Amazon EKS）を発表しました。
このようにして2017年の終わりには、コンテナランタイムにはDocker以外にも選択肢があること、コンテナオーケストレーションはKubernetesが事実上の業界標準となったことが、誰の目にも明らかになりました。
そして前回の記事では、ここまでをDockerコンテナ時代の第一章として紹介しました。
第二章における3つのトレンド
2017年後半から現在までをDockerコンテナ時代の第二章と位置付けるとするならば、コンテナ型仮想化を基盤としたさまざまな技術が同時に発展しはじめた時代といえます。
それらをPubilckeyなりに整理すると、次の3つに大別できます。
- コンテナランタイムにおける選択肢の広がり
- Kubernetes自身とエコシステムの成熟
- Kubernetesによるマルチクラウドへの期待
本記事では、第二章における3つのトレンドとしてそれぞれを紹介していきましょう。
コンテナランタイムにおける選択肢の広がり
コンテナランタイムとコンテナイメージの標準が「OCI」として、コンテナランタイムとKubernetesとの間のAPIが「CRI」として標準化されたことは、さまざまなコンテナランタイム登場の下地となりました。
2017年7月、Open Container Initiativeによるコンテナランタイムとコンテナイメージの標準化作業が完了し、「OCI 1.0」として発表されます。
3カ月後の2017年10月、Kubernetesが独自に開発を進めていたコンテナランタイムのcri-oも1.0に到達。コンテナランタイムとKubernetesのあいだのAPIも「CRI」（Kubernetes Container Runtime Interface）となりました。
そしてDockerから分離し独立したプロジェクトになっていたコンテナランタイムのcontainerdは、この数か月後にバージョン1.0に到達。
事実上の標準コンテナランタイムであるcontainerdが独立、成熟する一方、OCIやCRIに対応した新たなコンテナランタイムもさまざまなベンダから登場し始めます。
前述のように2017年10月にはKubernetesの開発チームから独自のコンテナランタイム「cri-o」が登場しましたが、その3カ月前の2017年7月にはオラクルが、Rust言語で実装したより高速に起動するコンテナランタイムの「Railcar」をオープンソースで公開しています。
2017年12月にはOpenStack Foundationが仮想マシンをベースとしたよりセキュアなコンテナであるKata Containersの開発を発表。
翌年、2018年5月7日にはGoogleがコンテナのセキュリティを大幅に高めたgVisorを発表。大きな話題となりました。
5月15日にはgVisorがAppEngineに採用されたことも発表し、本番環境で実用になることが示されました。
そのすぐ後の5月24日、Kata Containersもバージョン1.0に到達します。
さらに半年後の2018年11月27日、AWSがFirecrackerを公開。仮想マシンと同等のセキュリティと150ミリ秒以下の高速起動を実現すると紹介され、AWS Lambdaに使われていることも明らかにされました。
Kata Containersが仮想マシンを軽量化するというアプローチの一方、gVisorはコンテナをよりセキュアに実装するアプローチなど、Publickeyでは紹介できていないコンテナランタイムも含めてさまざまな特徴を持つコンテナの選択肢が広がっています。
Kubernetesとエコシステムの成熟
Kubernetes本体の成熟とエコシステムの発展も、この時期に見られた動きでした。
2017年12月に登場したKubernetes 1.9では、Windows Serverがついにサポートされ、それまで本体に含まれていたストレージインターフェイスがプラグインとして切り出される準備が始まりました。
2018年3月には、Kubernetes本体がインキュベーション段階から卒業。
これを待っていたかのように、2018年5月にはGoogle Kubernetes Engineが正式版に。6月にはAmazon EKS（Amazon Elastic Container Service for Kubernetes）が正式版となりました。
2018年12月には前述したKubernetesのストレージインターフェイスが正式版に。
2018年12月に開催された「KubeCon + CloudNativeCon North America 2018」のキーノートでは、「Kubernetesは以前より成熟し、より良いものになったことで、とてもとても退屈なものとなりました」と説明され、Kubernetes本体の成熟さが示された一方で、プラグインAPIなどによる拡張性を重視していく姿勢が表明されました。
もちろんKubernetesはまだまだ発展途上のソフトウェアであり、いまでも6カ月ごとのバージョンアップが行われています。しかしソフトウェアの品質としては本番利用に耐えるほどのものになったというのが、成熟したと表現される理由でしょう。
このようにKubernetes本体の成熟さが示された一方で、Kubernetesをとりまくエコシステムの発展も目立ってきました。
2018年7月には、Kuberntesを基盤にサーバレスコンピューティングを実現するためのソフトウェア「Knative」をGoogleがオープンソースとして公開。
Knativeは、コンテナをサーバレス環境で実行可能にするGoogleの新サービス「Serverless containers」の基盤になっているほか、Pivotal Function ServiceやGitLab ServerlessなどGoogle以外のサーバレスコンピューティング環境の基盤としても採用され始めており、Kubernetesを基盤としたサーバレスコンピューティング環境のカギを握るソフトウェアとみられています。
2018年10月には、独自のコンテナオーケストレーション機能「Diego」を実装していたPaaS型クラウド基盤ソフトのCloudFoundryが、Diegoの代わりにKubernetesを利用可能にする「Eirini」プロジェクトを発表。
PaaSにおいてもKubernetesが基盤として欠かせないものになっていく方向性が示唆されました。
2019年3月にRed Hatが開始した「OperatorHub.io」は、Kubernetesの機能を拡張してアプリケーションの運用管理を支援する「Operator」と呼ばれるソフトウェアのマーケットプレイスです。
これによってKubernetes上でさまざまなソフトウェアの利用が促進されることでしょう。
仮想化ハイパーバイザによるサーバ仮想化が普及したときに登場したソリューションの1つが、仮想化ハイパーバイザとサーバを統合したコンバージドインフラストラクチャ／ハイパーコンバージドインフラストラクチャでした。
コンテナ型仮想化の普及により、それと同じことが起きています。米Diamantiは、DockerとKubernetesに最適化した統合サーバを販売しており、2019年11月には日本でも本格展開が発表されています。
仮想化の普及と進化はソフトウェアのレイヤだけでなく、プロセッサやネットワーク、ストレージなども含めたシステムとしての最適化とともに行われてきました。
コンテナ型仮想化とオーケストレーションのソフトウェアレイヤにおける標準化がほぼ落ち着いてきたと見える現在、これに最適化されたシステムが今後さらに登場し、進化、普及していくことになるのでしょう。
このようにDockerに代表されるコンテナ型仮想化とそのオーケストレーションを実現するKubernetesの存在を前提としたエコシステムの発展は、今後さらにペースを増して続くはずです。
分散アプリケーション開発環境も整備へ
Kubernetesが事実上の標準となったことは、分散アプリケーションのためのインフラ環境の安定も意味します。
これにより、今後ニーズが高まるであろう分散アプリケーションの開発環境においても動きがありました。
2017年5月。分散環境におけるサービス間の通信やセキュリティ、運用管理などを容易にする「サービスメッシュ」を提供するためのフレームワーク「Istio」がオープンソースで公開されました。
2018年6月にはIstioは1.0に到達します。
Istioはいまのところサービスメッシュを提供するフレームワークでもっとも知名度の高いものですが、2019年5月には、アプリケーションからサービスメッシュを呼び出すAPIなどを標準化しようとする動きがありました。
現在もサービスメッシュにはIstio以外の選択肢がいくつも存在していますが、標準化されたAPIの普及によってより多くの選択肢が登場してくるかもしれません。
Kubernetesによるマルチクラウドへの期待
2018年8月に「Cloud Service Platform」という名称で発表され、2019年4月に「Anthos」と改名されたGoogleの新サービスは、Kubernetesによるインフラの抽象化をハイブリッドクラウドやマルチクラウドの実現に使うというアプローチで登場しました。
Anthosは、Google Cloud上ではGoogle Kubernetes Engine（GKE）を基盤として稼働し、オンプレミスではVMware環境上に構成されたGKE on Prem上で稼働。さらにAWSなどほかのクラウドでも実行可能だと紹介されまています。
Anthosに対応したアプリケーションであれば、オンプレミス、Google Cloud、それ以外のクラウドのどこでも実行可能となります。
Googleのハイブリッドクラウド／マルチクラウド戦略の要となるのが、Kubernetesを核とするこのAnthosなのです。
Heptio、Pivotalと相次いでKubernetesに強い企業を買収することでKubernetesへの注力を示してきたVMwareも、2019年8月に発表したTanzuによってKubernetesを中心としたマルチクラウド、ハイブリッドクラウドの実現を目論んでいます。
VMwareは仮想化ハイパーバイザであるvSphereをオンプレミスやさまざまなクラウドで稼働させることで、VMware環境で統一したマルチクラウド／ハイブリッドクラウドの実現を戦略の柱としてきました。
この方向性は現在も変わらないものの、それに加えてあらゆるデータセンター、クラウド、エッジでKubernetesを稼働させ、統一したアプリケーションの実行環境、運用環境をKubernetesのレイヤで実現しようとしているのがTanzuの目指すところです。
Red Hatを買収したIBMも、ハイブリッドクラウド戦略においてはKubernetesを基盤としたOpenShiftを重要なソフトウェアとして位置づけています。オンプレミスではOpenShiftを、IBM CloudではOpenShift on IBM Cloudを展開し、共通したソフトウェア基盤を提供するのです。
Kubernetesはコンピューティングの主要な3要素であるコンピュート、ネットワーク、ストレージのいずれも抽象化し、下位レイヤを隠蔽することが可能です（一方で、可用性のために離れたコンテナへ分散させるといった、下位レイヤを意識させることも可能です）。
複数のクラウドを用いるハイブリッドクラウド環境やマルチクラウド環境が当たり前になっていくと予想される中で、このKubernetesによるインフラ抽象化を用いたマルチクラウド／ハイブリッドクラウドのソリューションは今後もさまざまなベンダから提供されるでしょう。
Docker社はデベロッパー向けビジネスへ方向転換
コンテナ型仮想化のブームの火付け役となったDocker社にもこの2年のあいだに大きな変化がありました。
2018年4月、Docker社の創業者としてCEOを務め、その後CTOの肩書きへ移ったSolomon Hykes氏が退職します。
同社はDockerの成功によって第二のVMwareを目指してエンタープライズ市場での飛躍を模索していました。その会社の方向性と合わなかったのでしょう。
DockerCon 2016の基調講演に登場したSolomon Hykes氏しかし同社のエンタープライズ市場における飛躍はかなわず、2019年11月にはエンタープライズ向けに展開していたDocker Enterprise製品群をMirantis社へ売却。今後はデベロッパー向けのツールとビジネスにフォーカスすることを明らかにしました。
同社はコンテナランタイムにおいてはDockerという強力な製品とブランドを持っていました。しかしKubernetesを基盤としたエンタープライズ向けのソリューションでは、同社がKubernetes対抗のオーケストレーションツールであるSwarmを推していたことなどがあだとなり、残念ながら市場での強さを発揮することができなかったのだと思われます。
Kubernetesを基盤としたソリューションはさらに広がる
Dockerコンテナ時代の第二章では、事実上の標準となったKubernetesを基盤としたさまざまなソリューションやエコシステムの発展が目に見えるようになってきた時代だといえるでしょう。
これはまだ始まったばかりであり、今後さらに多数の製品やサービスがこの市場に登場することは間違いありません。
特にサーバレスコンピューティングやマルチクラウドの分野で、Kubernetesを基盤としたさらに完成度の高いソリューションがどのように登場してくるのか、非常に楽しみなところです。
Linuxディストリビューションやクラウドサービスなどを振り返れば分かるとおり、注目分野の黎明期には多くのベンダが参入し、多数の製品やソリューションが登場します。Kubernetesを基盤としたソリューションの市場では、いままさにそれが起きているといえます。
一方で時間の経過と共に、そうしたソリューションの多くが市場から脱落していき、生き残った数社によって市場のマジョリティが構成されてきたことも目にしてきました。クラウド市場における上位ベンダによる寡占化の進行は、そうした例の1つでしょう。
Dockerコンテナ時代における第三章、第四章では、そうした発展と収束にいたる風景が見られることになるのではないでしょうか。
また数年後に、Publickeyの記事でそうした動きを紹介したいと思います。
関連記事
あわせて読みたい
ハードディスクが物理破壊できないクラウド／「Amazon CodeGuru」は自動コードレビュー／「CSS Writing Modes 3」W3Cの勧告に、ほか。2019年12月の人気記事
≪前の記事
この1年、Publickeyのどの記事がたくさん読まれたのか？ 2019年総合ランキング発表
<!- script for simple analytics events -->