ビルド、テスト、デプロイの自動化、Dockerイメージの管理など。PublickeyGoogle、Kubernetes発表その同じ6月10日、GoogleはKubernetesをオープンソースとして公開することを発表します。PlatformVMware、マイクロソフトが相次いでDockerと協業発表8月にはVMwareがDockerとの協業を発表。ServerでDocker採用と発表。同じ頃、DockerはdotCloudのビジネスをcontrolCloudに売却し、Dockerビジネスに専念することを表明。Swarmを発表します。V3でそれまでのアーキテクチャを捨てて、DockerとKubernetesをコアとすると発表。Kubernetesへの傾倒を明確にします。Project」)の発足を発表。それまでDockerやCoreOSなどそれぞれのベンダが独自に実装していたコンテナが、一気に標準化へ舵を切ります。Project」発足。Foundation」を設立。開発主体がこの団体へ移動します。Kubernetesが1.0に到達。Containers」を発表します。Mac/Windows」が登場。Swarmを内蔵することを発表。このあたりから、SwarmとKubernetesを軸としたコンテナオーケストレーションツールの主導権争いが表面化してきます。Engineにオーケストレーション機能を内蔵。外部ツール不要でクラスタ運用を実現。Kubernetesが独自コンテナランタイム開発を表明Kubernetes側は当然のことながら、こうしたDockerの動きを歓迎しませんでした。10月には、Kubernetesの開発陣が独自のコンテナランタイム「cri-o」を開発中であることを表明します。Kubernetes、独自のコンテナランタイム「cri-o」開発中。PublickeyDockerからcontainerdが分離これをDocker側が警戒したのかどうかは不明ですが、12月にはDockerエンジンのコアランタイムを「containerd」として分離、独立したオープンソースプロジェクトとなります。11月には日本人としては初めてのDockerメンテナとして、NTTの須田氏が就任しました。2017年、Kubernetesが事実上の標準にそして今年、コンテナオーケストレーションツールをめぐる状況は大きく動きました。Kubernetes優勢の状況へ2月、CoreOSはKubernetesがコンテナオーケストレーションツールのデファクトになったとし、自社で開発していたオーケストレーションツール「fleet」の開発終了を発表します。Publickeyこの頃から、Kubernetesがコンテナオーケストレーションツールとして頭一つ抜け出した状況が見え始めます。1.6は、etcd3とgRPCを採用したことで大幅に性能向上。名前空間の分離や物理ノードの考慮などの機能向上も果たしました。Projectを発表します。Projectはさまざまなコンテナ関連のソフトウェアをコンポーネント化することで、目的ごとに特化したコンテナシステムを作ることができるフレームワークです。Project」を発表。すべてをコンテナで組み立てる世界を目指す。Publickey6月にはオラクルもKubernetesへの注力を発表。1.0」として発表されます。Foundationへの加盟を発表。状況はKubernetesへ一気に傾き始めました。2017で、DockerはついにKubernetesの統合とサポートを発表しました。コンテナオーケストレーションの事実上の標準がKubernetesになったと言えます。[速報]DockerがKubernetesとの統合およびサポートを発表。Service」(AKS)を発表。Engine」(略称GKEはそのまま)にサービス名を変更。EKS)を発表しました。1.0」リリースKubernetesが独自に開発を進めていたコンテナランタイムのcri-oも1.0に到達。Interface)となりました。Publickeyこれによってコンテナランタイムとコンテナイメージの標準は「OCI」、コンテナランタイムとKubernetesとの間のAPIは「CRI」として標準化されたことになります。コンテナランタイムの多様化こうして2017年末のコンテナの主な状況をまとめると、コンテナランタイムが標準化され、コンテナオーケストレーションツールの事実上の標準の座にKubernetesがつき、主要クラウドベンダはKubernetesのマネージドサービスを開始した、ということになるでしょう。この状況から今後なにが起きるのかを少し考えてみます。ひとつは標準に沿ったうえでのコンテナランタイムの多様化ではないでしょうか。実際にKubernetesは独自のコンテナランタイムであるcri-oをリリースしています。Containers」の開発をスタートさせました。コンテナがアプリケーションの基盤としてさまざまな用途で使われるようになるとすれば、その用途に合った特徴を備えたさまざまなコンテナランタイム実装が登場することは自然なことなのかもしれません。いえ、現在のところコンテナ実装はcontainerdが事実上の標準となっています。そのcontainerdは今月、バージョン1.0に到達したばかりです。いましばらくこうした状況が続くとみられます。Cloudなどの主要なクラウドによるマネージドなKubernetesのサービスがはじまったことも注目に値します。Foundationはなかなかやり方が上手で、「Kubernetes適合認証プログラム」を開始し、独自のKubernetes実装などによるAPIの齟齬などが広まらないように手を打っています。するとすぐに思いつくのが、複数の異なるクラウドをKubernetesのレイヤで抽象化する、というアイデアでしょう。これまでクラウド間で仮想マシンを柔軟に移動させることは可能ではありましたが面倒であり、動的に行えるような柔軟性もありませんでした。どのクラウドも同じコンテナオーケストレーションツールのKubernetesと標準仕様のコンテナが使われているのであれば、これをKubernetesのレイヤで束ねてコンテナをクラウド間で柔軟に移動する、ということが可能になります。Datacenterで(Kubernetesとは異なる実装で)こうしたことを実現しようとしていました。今年、Kubernetesとの統合を発表した同社としては、あらためてKubernetesを用いた実装で実現しようとしてくると思われますし、おそらく他のベンダやオープンソースなどでも同様のソフトウェアが登場してくるのではないでしょうか。これが機能するようになれば、ユーザーはKubernetesのオーケストレーション機能を用いてワークロードの種類や価格に合わせてクラウドを自由に使い分ける、といったことがやりやすくなります。一方で、クラウドベンダにとって自社のクラウドがKubernetesで抽象化されてしまうのは、独自性や付加価値を失うことにつながってしまいます。そこでクラウドベンダとしては、コンテナをベースにアプリケーションの開発、テスト、デプロイ、本番運用までの一連のライフサイクル全体でユーザーに使いやすくなるようなツールやサービスを構築することで、できるだけ競合他社のクラウドへワークロードが逃げないような施策を打つことでしょう。Fargate」を発表したのは、さすがによく考えられた戦略に沿ってサービスができているように見えます。ハイブリッドクラウドもKubernetesになるか?ではオンプレミスでのKubernetesの展開はどうでしょうか?もしもオンプレミスでもKubernetesがある程度使われるようになるとすれば、前述のパブリッククラウド同士の連携と同様に、Kubernetesのレイヤでハイブリッドクラウドを構築するための基盤として展開されるものになると考えられます。オンプレミスでのKubernetesの展開は未知数です。Service」(PKS)を今年の8月に発表していますので、動向を注目したいと思います。マイクロソフトはWindows上でのKubernetesについて目立った動きを見せていません。ServerでDocker対応を発表したように、おそらく何らかの発表を来年にはしてくるのではないでしょうか。2018年はコンテナによるソリューションのフェーズへKubernetesにはまだ、仮想ネットワークの構築やコンテナに適したストレージをどうするか、といった課題も残っています。来年にはこうした課題に対するソリューションも安定したものになってくると思われます。いえ、2017年末でコンテナとコンテナオーケストレーションの基盤技術をめぐる競争はおおむね終結したように見えます。2018年はその基盤を用いてどんな価値のあるソリューションを構築するか、そういう新たなフェーズへと入っていくのではないでしょうか。Functionsが13%。Niino(jniino)IT系の雑誌編集者、オンラインメディア発行人を経て独立。2009年にPublickeyを開始しました。2.7サポートを発表Google、Lookerの買収完了を発表。Enterprise、BtoBスタートアップ向け支援プログラムで無料提供と発表。Networksの買収を正式発表。Terminal」機能確定版リリース。コマンドラインからIssueやプルリクなど実行可能に。usPublickeyについて/運営者についてお問い合わせ広告についてプライバシーポリシ。