2017年、コンテナ業界にとって忙しい年

2017 年はコンテナ エコシステムの開発にとって画期的な年でした。 AWS、Azure、Alibaba Cloudは、独自のコンテナサービスにKubernetesのサポートを相次いで追加しており、Dockerも今年10月にSwarmとKubernetesの両方をサポートすると発表しました。コンテナ オーケストレーション戦争は終わったと言う人もいます。では、なぜ Google の Kubernetes は急速に発展したのでしょうか。なぜ Docker は当初の決定を変更したのでしょうか。そして、急成長を遂げるコンテナ エコシステムにはどのような変化が起きたのでしょうか。

Kubernetes の「開かれた」道

2017 年、Kubernetes は 4 つのバージョンをリリースし、マルチユーザー、マルチロード、セキュリティ、使いやすさが向上しました。

Kubernetes 1.6 のスケーラビリティ SLO は、5,000 ノード (150,000 Pod) のクラスターをサポートし、複数の Kubernetes クラスターを組み合わせて単一の API エンドポイントを通じて使用できるほか、一連の高度なスケジューリング機能と包括的なストレージ自動化機能がリリースされています。

Kubernetes 1.7 では、ネットワーク ポリシー API が導入され、ネットワーク セキュリティが強化され、ベータ版でストレージとステートフル ワークロードの管理および API 集約レイヤーが提供されます。

Kubernetes 1.8 ではセキュリティに力を入れています。バージョン 1.6 でベータ版だったロールベースのアクセス機能が安定化しました。新しいベータ ステータスの Pod 水平自動スケーリング カスタマイズ機能が追加され、ツリー外のボリューム ドライバーを使用できるようになりました。 Kubernetes クラスターをセットアップするための kubeadm コマンドに、クラスターのアップグレードのサポートが追加されました。

Kubernetes バージョン 1.9 は、包括的な App Workload アプリケーション プログラミング インターフェイスを提供し、Windows システムのサポートを追加し、ストレージに関して Container Storage Interface 機能を追加します。

Constellation Research の主任アナリスト兼副社長である Holger Mueller 氏は、CSI の進化が現時点で Kubernetes の最も重要な新機能である可能性があると述べています。同氏は、Kubernetes が過去数年間で飛躍的に成長し、標準として非常に高い基準を設定し、急速に普及し、「2 年足らずでゼロから明確なリーダーに躍り出た」と指摘した。

Kubernetes は、Docker Inc. がこの有名なオープンソース プロジェクトを立ち上げてから 14 か月後の 2014 年 6 月にオープンソース化されました。 Kubernetes は初期の頃、Google の社内 Borg システムの影響を受けていました。 Googleは10年以上前からコンテナ化技術を活用していると主張しているが、BorgはGoogleの社内コンテナ管理システムであるという噂がある。 2015 年当時、Kubernetes は現在ほど成熟しておらず、そのリリース バージョンやその他の関連ニュースが業界で取り上げられることはほとんどありませんでした。 2015 年 7 月、Google は Linux Foundation と協力して CNCF Foundation (Cloud Native Computing Foundation) を設立し、Kubernetes をシード プロジェクトとして寄贈するという非常に賢明な決断を下しました。その後、オープンソースコミュニティにおけるKubernetesの人気は高まり続け、大手IT企業が次々とCNCF Foundationに加盟しました。それ以来、Kubernetes は止められない発展の時代に入りました。

Docker革命

Docker も 2017 年に重要な動きを見せました。まず 4 月にプロジェクトを再編成し、Moby と LinuxKit に分割し、10 月には Swarm と Kubernetes の両方のサポートを発表しました。

Moby への名前変更は開発者の間で騒動を引き起こしたが、Rancher の Darren Stepherd 氏はツイートで次のようにまとめている。「Moby に戸惑っていますか? 簡単に言うと、Docker ユーザーにとっては何も変わりません。このようなプロジェクトは、Rancher Labs のようなシステム ビルダーを支援するために内部的な変更を加えます。」 Docker の改革後、ユーザーはニーズに応じて独自のコンテナ システムをカスタマイズできるようになりました。 Docker バイナリ ファイルは変更されていないため、ユーザーに影響はありません。

2017 年 10 月の DockerCon では、もう 1 つの大きなニュースがありました。Google との 1 年間の協力を経て、Docker は Kubernetes のサポートを発表しました。これにより、Kubernetes と Swarm を同じクラスターで実行できるようになります。カンファレンスにはKubernetesの中核著者であるティム・ホッキン氏が招待され、同氏はカンファレンスで次のように述べた。「DockerがなければKubernetesは存在しなかったと言っても過言ではありません。誰もがコンテナ技術が開発されてから4年、長い年月が経っていると考えています。しかし、実際には、今日でも分散システムを構築するのは難しく、開発者が協力して信頼性が高くスケーラブルなアプリケーションを迅速に構築するのは依然として困難です。今後もやるべきことはたくさんあります。私は、これは始まりに過ぎず、次の（両者の）協力は間違いなくより多くのものをもたらすと信じています。」 Dockerの創設者ソロモン・ハイクス氏は、「徐々に、私たちは同じグループであり、同じことに焦点を当て、同じ問題を議論し、解決することを望んでいることに気づきました。私たちは大きな家族のようで、今回はむしろ家族の再会のようなものです」と語った。

12月には、Docker Engineを分割した後にDockerから寄贈されたcontainerdがバージョン1.0として正式にリリースされ、ストレステストシステムの作成、ガベージコレクション、メモリ使用量のパディングなどのパフォーマンス改善が追加されました。これは、containerd が産業グレードのコンテナ ランタイム標準であるという 1 年前の約束を Docker が果たしたことを意味します。

CoreOS の再起動

Docker が人気のオープン ソース プロジェクトを開始した後、CoreOS は 2013 年 10 月に Container Linux をオープン ソース化しました。これは、自動化、アプリケーションの簡単な展開、セキュリティ、信頼性、およびスケーラビリティに重点を置きながら、クラスター展開のインフラストラクチャを提供するように設計された、Linux カーネルに基づく軽量オペレーティング システムです。軽量オペレーティング システムである Container Linux は、ソフトウェア コンテナー内にアプリケーションを展開するために必要な最小限の機能と、サービス検出および構成共有のための組み込みメカニズムのみを提供します。 Container Linux は、クラスター内のすべてのマシンで実行され、動的な構成レジストリを提供するデーモン etcd も提供しており、さまざまな構成データをクラスター メンバー間で簡単かつ確実に共有できます。当初、CoreOS は Docker と緊密に連携していましたが、後に Docker が「シンプルな基本ユニット」に満足していないと考え、2014 年末にオープンソースのコンテナ エンジン Rocket (略して rkt) をリリースしました。

2017 年、rkt 派の CoreOS は独自のスケジューリング ツール Fleet を放棄し、Kubernetes に重点を移しました。同社は商用KubernetesプラットフォームTectonic1.8をリリースしたばかりで、メンテナンス、自動化、パッチ適用、アップグレードなどを実行でき、ベアメタル、ローカルデータセンター、パブリッククラウドなどさまざまな環境で動作できるオープンクラウドサービスを追加しました。

アリババが独自開発したリッチコンテナ技術ポーチ

Pouch は、Alibaba が社内で開発したコンテナ技術から生まれたオープンソース インキュベーション プロジェクトです。現在、データセンターでは数十万の Pouch コンテナが稼働しており、社内のオフラインおよびオンライン ビジネスの大規模なハイブリッド展開をサポートしています。 Pouch は Alibaba T4 と Docker の統合から生まれました。 Alibaba の内部運用と保守、およびアプリケーションの観点を通じて、Alibaba 内のコンテナと物理マシンの一貫したエクスペリエンスを実現します。

まず、Pouch は豊富なコンテナ技術です。内部アプリケーションのエクスペリエンスは仮想マシンのエクスペリエンスに似ています。 init プロセスがあり、さまざまなシステム サービスが充実しています。 2 番目に、カーネルの強化と軽量仮想マシンのサポートにより、Pouch は豊富なセキュリティ分離の保証と分離ディメンションを提供します。特に超大規模なシナリオにおける画像配信では、P2P を通じてネットワーク負荷を軽減できます。カーネルの互換性という点では、企業の現状にさらに合致しています。ほとんどのエンタープライズ IT システムのカーネルはゆっくりとアップグレードされ、バージョンも低いことを考慮すると、既存の基盤インフラストラクチャとの互換性が最大限に高まります。

さらに、Pouch は別のオープンソース プロジェクト ファイル配布システムである Dragonfly と一緒に使用できます。

メソスは依然として存続している

Docker の Kubernetes サポート イニシアチブより 1 か月前に、Mesos も今年 9 月に Kubernetes のサポートを発表し、プラットフォーム ユーザーが複数の運用レベルの Kubernetes クラスターをインストール、拡張、アップグレードできるようにしました。 Mesosphere の CTO である Tobi Knaup 氏は、この動きは顧客にオーケストレーション システムの選択肢を増やすことが目的であると述べました。 「当社の顧客は運用チームであり、時には何万人もの開発者をサポートする必要があり、多様なソフトウェアを必要としており、選択肢が 1 つに限定されるべきではありません。選択肢は非常に重要です。」

Mesos の Marathon は、Swarm や Kubernetes よりも前の最初の Docker コンテナ オーケストレーション システムであることを知っておく必要があります。コンテナ開発の初期の頃は、コンテナ オーケストレーションの問題を解決するために多くの人が Mesos を選択しました。 Apache Mesos の商用バージョンは DCOS です。同社は第4回目の資金調達で1億1,200万ドルを調達しており、HPE、マイクロソフトなどから強力な支援を受けている。 Mesosphere は、DCOS の目標が世界中で 2,000 社の顧客を獲得することであることを公言しています。現在、Mesosphere は良い結果を残しており、米国のトップ 10 金融サービス企業のうち 5 社、北米のトップ 10 銀行のうち 5 社、世界のトップ 10 通信事業者のうち 5 社、最大手のコネクテッド カー メーカーのうち 6 社が Mesos を選択しています。 Autodesk、Yelp、Dangdang、Douban などの IT 企業もその忠実なユーザーです。

2017 年の KubeCon 基調講演で、ケルシー・ハイタワー氏は、運用担当者全員が満足するために 1 つの共有クラスターだけに依存することは想定すべきではなく、Google の Borg システムはそのように設計されていないと述べました。 Mesosphere のプロダクト マーケティング マネージャーである Chris Gaun 氏は、次のようにコメントしています。「Kubernetes は孤立したものではありません。少なくとも、CI/CD ソリューションと組み合わせる必要があります。その上で、機械学習フレームワークに基づく最新かつ効率的なデータ サービスとソリューションを装備できれば、ユーザーの満足度は高まります。」

牧場主の大きな変化

Rancher Labs は、オペレーティング システム レベルの仮想化ツールの作成に取り組んでおり、その中で最も有名なのは Linux コンテナーです。 Rancher Labs は 2014 年に設立されました。Rancher 独自の Docker コンテナ管理プラットフォームである Cattle と、軽量のオープンソース コンテナ Linux オペレーティング システムである RancherOS という 2 つの製品があります。

かつて、Cattle は Rancher の組み込みオーケストレーション システムであり、Swarm、Mesos、Kubernetes オーケストレーション システムもサポートしていました。しかし今年、CoreOS と同様に、Racher はコンテナ管理プラットフォームのバージョン 2.0 をリリースし、Kubernetes をオールインすることを発表しました。バージョン 2.0 は Kubernetes をベースに設計された UI を備え、CLI、AP、Docker Compose をサポートし、自社製またはサードパーティのクラウド ベンダーのクラスターをインポートして構成することもできます。

Liang Sheng 氏はメディアのインタビューで次のように語っています。「Kubernetes クラスターを導入している顧客は多くいますが、Google のような理想的な統一アーキテクチャは備えていません。さまざまなチーム、プロジェクト、アプリケーションを区別するためにアクセスを制御するツールが必要です。さまざまな種類のインフラストラクチャを処理するには、集中コンソールが必要です。Kubernetes は、この点ではまだ不十分です。Kubernetes は独自の監視構成とネットワーク ドライバーを提供するため、汎用的なソリューションが必要です。」

IaaSベンダーもKubernetesをサポート

Google は社内では Borg システムを使用していますが、パブリック クラウド コンテナ サービスではコンパイル システムとして Kubernetes を使用しています。 Kuberentes の加熱曲線との興味深い一致は、ガートナーの IaaS ベンダーのマジック クアドラントで、2011 年に設立された Google Cloud が 2014 年に IBM や他のベンダー数社とともにビジョナリー クアドラントでわずかに優位に立っていたものの、2016 年には Google Cloud が単独でビジョナリー クアドラントを占め、2017 年には Google Cloud がビジョナリー クアドラントで一定の優位性を維持したことです。

今年、Azure は 2 月に Kubernetes の公式サポートを発表し、IBM は 3 月に、Oracle は 9 月に、Alibaba Cloud は 11 月に、AWS は 12 月にサポートを発表しました。実際、上記のメーカーはすでに Docker のパートナーであり、Docker Enterprise Edition (Docker EE) のサポートなど、関連するエンタープライズ レベルの製品サービスを提供しています。一般的なマイクロサービスとアプリケーション移行シナリオに加えて、AWS、Azure、Alibaba Cloud のコンテナー サービスでは機械学習シナリオもサポートされています。 Google、IBM、Oracle が AI プラットフォーム サービスを直接提供しています。一方、パブリッククラウド上のAWS、Azure、Alibaba Cloud、Google Cloudなどのベンダーが提供するコンテナサービスはほぼ無料（Google）で、ユーザーが消費したリソースに対してのみ課金されます。コンテナ オーケストレーション管理の市場価値については、次の段落で説明します。

Kubernetes と Docker は味方でしょうか、それとも敵でしょうか?コンテナエコシステム開発の観点から見ると、これは誤った提案かもしれない。

評価額10億ドルのスタートアップ企業であるDockerは、事実上の標準とほぼみなされるコンテナランタイムを提供しています。一方、Google の Kubernetes はオーケストレーション エンジン戦争に勝利したようです。オーケストレーション システム層は市場に大きな利益をもたらすと一般的に考えられているため、Kubernetes は Docker に直接的な脅威を与えると言われています。 Cloud Technology Partnership のチーフアーキテクトであり Forbes のオブザーバーでもある Mike Kavis 氏の見解では、実際の市場価値があるのは PaaS/CaaS プラットフォーム全体であり、オーケストレーション システムは 1 つのレイヤーにすぎません。 Docker と同等に言及されるべきなのは VMWare や CloudFoundry などであり、Docker の収益モデルはそれに対応するサポート サービスであるはずです。

昨年のケルシー・ハイタワーとソロモン・ハイクスのツイッターでの論争を覚えている人は多いと思います。建設的な批判は、Docker が自社の製品計画をある程度再検討するのに役立つはずです。現在、Kubernetes は Docker を実現する手段となっています。元Googleで働いていた、現在のDockerチーフエバンジェリストであるパトリック・シャネゾン氏はインタビューで、Kubernetesのセキュリティパフォーマンスは以前はまだ改善する必要があったが、現在は状況は改善していると語った。

Julia Evans 氏はツイートに Kubernetes コンポーネントの図を投稿しました。

開発者にとって、複数のオーケストレーション システムが相互にサポートし合うことは、双方にとってメリットのある状況です。オープンソースの世界には多くのヒーローが存在し、ダイナミクスとトレンドが次々と生まれています。かつて公然と「口論」していたKubernetesとDockerでさえ、過去の恨みを脇に置いた。なぜ他人は過去にこだわり続けるのでしょうか?

Google や Docker などのコンテナ プレーヤーは、成熟したコンテナ テクノロジをどのように活用して企業にサービスを提供するかに関心を持っています。 Tim Hockin 氏は、「今日でも分散システムを構築するのは依然として困難であり、開発者が協力して信頼性が高くスケーラブルなアプリケーションを迅速に構築するのは依然として困難です」と述べています。

結論

コンテナ テクノロジーの価値は、オープン コミュニティとオープン エコシステムにあります。今年のコンテナ業界のメインテーマは何かと問われれば、それはおそらく標準化でしょう。 Kubernetes の成功は、オープン コミュニティ ポリシーとオープン コンテナ オーケストレーション標準の実装にあります。そして、Docker はついに 12 月にコンテナ ランタイム標準 containerd 1.0 を提出しました。

標準化とは、人々がこの問題に関して合意に達し、これに基づいてイノベーションを支援する意思があることを意味します。もう議論する必要はなく、車輪の再発明をする必要もありません。業界全体としては経験を積み、より迅速かつ効率的に新分野へ進出することができ、安定した成長期を迎えることができます。

マーケットシェアとマインドシェアは異なる概念です。オープンソースコミュニティで高い評価を得ているKubernetesは、Mind Shareでも完全勝利を収めたと言えるでしょう。ますます多くの開発者の心をつかんでいます。 「戦わずして勝つ」という戦略により、Kubernetes の市場は自然と活性化し、ほぼすべての大手クラウドベンダーが Kubernetes オーケストレーション サービスを提供することを決定しました。

開発者のプロジェクトが商業的に成功したいのであれば、まずオープンソース コミュニティで認知されなければなりません。オープンソース コミュニティでは、最も誠実で「厳しい」アドバイスを得ることができます。コードを見せてください。ここ以上に技術力を信頼できる場所は他にありません。 GitHub はかつてメディアのインタビューで次のように述べました。「オープンソース コミュニティは独自の社会構造を発展させており、この社会構造は常に進化しています。プロセス全体を通じてそれに参加しなければ、遅かれ早かれ歴史の流れに見捨てられることになります。」残念ながら、今日では、この傾向に逆らう IT メーカーは存在しないでしょう。

12 月初旬に終了したばかりの KubeCon では、多くの基調講演者が「退屈」という言葉を繰り返し使用し、Kubernetes を成功させるにはプロジェクトを再び退屈にする必要があると述べました。不満を言う人の中には、インターネット分散システムの構築について多少の知識がないと、Kubernetes を理解して使用するのは難しいプロジェクトだと言う人もいます。それは複雑なシステムです。 Kubernetes はもっと「退屈」にならないのでしょうか? 「Kubernetes を必要な場所に作成し、その周りにエコシステムを育てることが、まさに当初からの目標です。コア部分は退屈なままでなければなりません」と、Kubernetes の伝道師であるケルシー・ハイタワー氏は語った。同時に、Red Hat の Clayton Coleman 氏も、アプリケーションの開発は楽しいが、アプリケーションの実行は退屈だと述べています。

噂話や会話の話題が少ないときは、人々は仕事に集中できる時間です。業界では、コンテナ技術をどのように活用してアプリケーション層に革新をもたらし、より多くの価値を生み出すかが問題となっています。将来がどうなるか、待って見てみましょう。