開閉ボタン
ユーザーメニュー
ユーザーメニューコンテンツ
ログイン

  • 会員限定
  • 2020/01/29

Docker/コンテナは第二章へ Kubernetesの成熟とエコシステム発展

Dockerの登場により急速に普及をはじめたコンテナ型仮想化の技術は現在、DockerコンテナそのものからKubernetesを軸としたオーケストレーションツールへと主役が移ってきています。その様子は2017年12月に公開した記事『Dockerの歴史から紐解く、コンテナ型仮想化の「今まで」と「これから」』で紹介しました。この記事の公開から2年が経過し、現在のコンテナ型仮想化技術は、マイクロサービスやクラウドネイティブなどの文脈とともにエンタープライズな分野でも使われるメインストリームな技術へと確実に進み続けています。本記事では前記事で描いたDockerコンテナ時代の第一章に続く第二章として、コンテナ型仮想化技術のここ2年半ほどの動向をPublickeyなりにまとめてみました。

新野淳一(本記事は「Publickey」より転載)

新野淳一(本記事は「Publickey」より転載)

ITジャーナリスト/Publickeyブロガー。大学でUNIXを学び、株式会社アスキーに入社。データベースのテクニカルサポート、月刊アスキーNT編集部 副編集長などを経て1998年退社、フリーランスライターに。2000年、株式会社アットマーク・アイティ設立に参画、オンラインメディア部門の役員として2007年にIPOを実現、2008年に退社。再びフリーランスとして独立し、2009年にブログメディアPublickeyを開始。現在に至る。



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」へ
画像
Kubernetes 1.0 Launchの模様。オライリーの動画から

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

  • コンテナランタイムにおける選択肢の広がり
  • 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)となりました。

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 ServiceGitLab 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の存在を前提としたエコシステムの発展は、今後さらにペースを増して続くはずです。

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

仮想化ソフトウェア ジャンルのトピックス

仮想化ソフトウェア ジャンルのIT導入支援情報

PR

ビジネス+IT 会員登録で、会員限定コンテンツやメルマガを購読可能、スペシャルセミナーにもご招待!