Kubernetesの登場後、コンテナ型仮想化はどう発展した？　技術トレンドの変遷を振り返る（1/5 ページ）

公開 2020年01月07日 07時05分

[ITmedia]

印刷する Googleで優先するソースとして追加

この記事は新野淳一氏のブログ「Publickey」に掲載された「Dockerコンテナ時代の第二章～Kubernetesの成熟とエコシステム発展の時代」（2020年1月6日掲載）を、ITmedia NEWS編集部で一部編集し、転載したものです。

　Dockerの登場により急速に普及をはじめたコンテナ型仮想化の技術は現在、DockerコンテナそのものからKubernetesを軸としたオーケストレーションツールへと主役が移ってきています。

　この記事の公開から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コンテナ時代の第一章として紹介しました。