Docker 1.0の到達とKubernetesの登場

　まずはDockerとKubernetesの登場とその後の主要なできごとを、2017年の終わりまで簡単に振り返りましょう。

　2013年3月26日に当時のdotCloud社（現Docker社）が、Dockerをオープンソースとしてはじめて公開します。

　そして2014年6月9日（米国時間）にはDocker 1.0が登場。

［速報］コンテナ型仮想化のDocker 1.0がリリース。Dockerはコンテナエンジンからプラットフォームになると宣言 － Publickey
　奇しくもその翌日、2014年6月10日にGoogleがKubernetesをオープンソースとして公開します。

　公開から約1年後の2015年7月にはKubernetesがバージョン1.0に到達。と同時にベンダから独立した組織である「Cloud Native Computing Foundation」が設立され、Kubernetesの開発主体がGoogleから移管されました。

Kubernetesが1.0に到達。今後は開発の主体を新団体「Cloud Native Computing Foundation」へ

　2016年10月、Kubernetesの開発チームは独自のコンテナランタイム「cri-o」を開発中であることを表明。コンテナランタイムにDocker以外の選択肢があることの具体性が高まります。
　Kubernetes、独自のコンテナランタイム「cri-o」開発中。コンテナランタイムのインターフェイスを標準化し、Dockerだけでなくどんなコンテナランタイムでも対応可能に
　2017年3月に登場したKubernetes 1.6は、etcd3とgRPCを採用したことで大幅に性能向上。さらに名前空間の分離や物理ノードの考慮などの機能向上も果たしました。

　2017年7月にはOpen Container Initiativeによるコンテナランタイムとコンテナイメージの標準化作業が「OCI 1.0」完了。

Open Container Initiativeによるコンテナランタイムとコンテナイメージの最初の標準化作業が完了、「OCI v1.0」発表
　そして、2017年10月に開催されたDockerCon Europe 2017で、Dockerが製品にKubernetesを統合することを発表。コンテナオーケストレーションの事実上の標準がKubernetesに決定した瞬間です。

［速報］DockerがKubernetesとの統合およびサポートを発表。DockerCon EU 2017

　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つに大別できます。


　本記事では、第二章における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）となりました。

Kubernetes、Dockerに依存しないKubernetes用の軽量コンテナランタイム「cri-o」正式版1.0リリース

　そしてDockerから分離し独立したプロジェクトになっていたコンテナランタイムのcontainerdは、この数か月後にバージョン1.0に到達。

事実上の標準コンテナランタイム「containerd」がバージョン1.0に到達
　事実上の標準コンテナランタイムであるcontainerdが独立、成熟する一方、OCIやCRIに対応した新たなコンテナランタイムもさまざまなベンダから登場し始めます。

　前述のように2017年10月にはKubernetesの開発チームから独自のコンテナランタイム「cri-o」が登場しましたが、その3カ月前の2017年7月にはオラクルが、Rust言語で実装したより高速に起動するコンテナランタイムの「Railcar」をオープンソースで公開しています。

Rust言語による新しいDockerコンテナランタイム実装「Railcar」、オラクルがオープンソースで公開。なぜRustでコンテナランタイムを実装したのか？
　2017年12月にはOpenStack Foundationが仮想マシンをベースとしたよりセキュアなコンテナであるKata Containersの開発を発表。

コンテナの軽量さと仮想マシンの堅牢さを兼ね備えた新しいコンテナ実装「Kata Containers」、OpenStack Foundationが発表
　翌年、2018年5月7日にはGoogleがコンテナのセキュリティを大幅に高めたgVisorを発表。大きな話題となりました。

コンテナの軽量さと、より安全な分離を実現する「gVisor」、Googleがオープンソースで公開

　5月15日にはgVisorがAppEngineに採用されたことも発表し、本番環境で実用になることが示されました。

App Engineが軽量コンテナのgVisorを実行環境として採用、スタンダード環境でNode.jsをサポート開始
　そのすぐ後の5月24日、Kata Containersもバージョン1.0に到達します。

仮想マシンをベースにしたセキュアなコンテナ実装「Kata Containers」がバージョン1.0に到達。OpenStack Foundationが開発
　さらに半年後の2018年11月27日、AWSがFirecrackerを公開。仮想マシンと同等のセキュリティと150ミリ秒以下の高速起動を実現すると紹介され、AWS Lambdaに使われていることも明らかにされました。

［速報］AWS、独自のセキュアなコンテナ実行用マイクロVM「Firecracker」、オープンソースで公開。AWS re:Invent 2018

　Kata Containersが仮想マシンを軽量化するというアプローチの一方、gVisorはコンテナをよりセキュアに実装するアプローチなど、Publickeyでは紹介できていないコンテナランタイムも含めてさまざまな特徴を持つコンテナの選択肢が広がっています。

Kubernetesとエコシステムの成熟

　Kubernetes本体の成熟とエコシステムの発展も、この時期に見られた動きでした。

　2017年12月に登場したKubernetes 1.9では、Windows Serverがついにサポートされ、それまで本体に含まれていたストレージインターフェイスがプラグインとして切り出される準備が始まりました。

Kubernetes 1.9リリース。主要なAPIが正式版に、Windows Serverサポート、コンテナストレージインターフェイスも
　2018年3月には、Kubernetes本体がインキュベーション段階から卒業。

Kubernetesは十分成熟したソフトウェアに到達したとし、CNCFのインキュベーション段階からの卒業を発表
　これを待っていたかのように、2018年5月にはGoogle Kubernetes Engineが正式版に。6月にはAmazon EKS（Amazon Elastic Container Service for Kubernetes）が正式版となりました。

　2018年12月には前述したKubernetesのストレージインターフェイスが正式版に。

Kubernetes 1.13リリース。Container Storage Interface仕様が正式版に、CoreDNSがデフォルトのDNSサーバへ
　2018年12月に開催された「KubeCon + CloudNativeCon North America 2018」のキーノートでは、「Kubernetesは以前より成熟し、より良いものになったことで、とてもとても退屈なものとなりました」と説明され、Kubernetes本体の成熟さが示された一方で、プラグインAPIなどによる拡張性を重視していく姿勢が表明されました。

Kubernetesはオープンな標準と拡張性にフォーカスしている。KubeCon + CloudNativeCon North America 2018

　もちろん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が基盤として欠かせないものになっていく方向性が示唆されました。

Cloud Foundry Foundationが「Eirini」プロジェクト発表。Diegoの代わりにKubernetesをオーケストレーションで利用可能に
　2019年3月にRed Hatが開始した「OperatorHub.io」は、Kubernetesの機能を拡張してアプリケーションの運用管理を支援する「Operator」と呼ばれるソフトウェアのマーケットプレイスです。

Kubernetesアプリケーションの運用ツールポータル「OperatorHub.io」、Red Hatが開始。AWS、Google Cloud、Azureらが協力

　これによってKubernetes上でさまざまなソフトウェアの利用が促進されることでしょう。

　仮想化ハイパーバイザによるサーバ仮想化が普及したときに登場したソリューションの1つが、仮想化ハイパーバイザとサーバを統合したコンバージドインフラストラクチャ／ハイパーコンバージドインフラストラクチャでした。

　コンテナ型仮想化の普及により、それと同じことが起きています。米Diamantiは、DockerとKubernetesに最適化した統合サーバを販売しており、2019年11月には日本でも本格展開が発表されています。

DockerコンテナとKubernetesの実行に最適化したコンバージドインフラ「Diamanti」が日本で本格展開へ
　仮想化の普及と進化はソフトウェアのレイヤだけでなく、プロセッサやネットワーク、ストレージなども含めたシステムとしての最適化とともに行われてきました。

　コンテナ型仮想化とオーケストレーションのソフトウェアレイヤにおける標準化がほぼ落ち着いてきたと見える現在、これに最適化されたシステムが今後さらに登場し、進化、普及していくことになるのでしょう。

　このようにDockerに代表されるコンテナ型仮想化とそのオーケストレーションを実現するKubernetesの存在を前提としたエコシステムの発展は、今後さらにペースを増して続くはずです。

【次ページ】 分散アプリケーション開発環境も整備へ