Kubernetes エコシステムの繁栄の背後にある長所と短所

会社が Kubernetes オーケストレーションマネージャーを全面的に使用する準備ができており、デプロイメントを容易にするパッケージ管理ツールを探している場合は、Cloud Native Computing Foundation (CNCF) によってインキュベートされているオープンソースプロジェクトである Helm を選択することをお勧めします。

また、コンテナを普及させた会社の Docker Compose や、Helm を開発した同じ人々が開発した Microsoft プロジェクトである Draft、Open Service Broker API、Habitat、その他 17 種類のオープンソースパッケージマネージャーについて学ぶこともできます。 CNCFは、272の他のクラウドネイティブオープンソースプロジェクトを含むこれらすべてをLandscape[1]ウェブページにリストしています。同時に、このリストは毎週更新されます。

[[255544]]

これを選択肢の多さによる混乱と呼ぶ人もいれば、イノベーションの新たな波と呼ぶ人もいる。いずれにせよ、Kubernetes を中心に開発されたエコシステムは、その利点を実証しましたが、混乱ももたらしました。 Kubernetes を導入する準備ができている企業にとって、利用可能な多数の拡張機能とアプリケーションプログラミングインターフェイスの中から十分な情報に基づいた選択を行うことは、直面する最大の課題の 1 つになりつつあります。

「これほど多くの活動があることは驚くべきことですが、平均的な企業がこれらすべての情報を収集しようとしていることをうらやましく思いません」とIBM Cloud Platformのグローバル副社長兼CTOであるジェイソン・マギー氏は語った。マギー氏はシアトルで開催された KubeCon カンファレンスで基調講演を行った。このカンファレンスには、仮想化以来最も注目されているデータセンター関連テクノロジーについて学ぶために 8,000 人の技術愛好家が集まった。

Kubernetes は、アプリケーションの開発方法に革命をもたらすクラウドネイティブプラットフォームです。このソフトウェアは Google LLC によって作成され、4 年前にオープンソースとしてリリースされました。これは、大量のコンテナベースのソフトウェアを展開および管理するための主流のプラットフォームに急速に成長しました。コンテナベースのソフトウェアは自己完結型であり、アプリケーションが複数の環境で実行するために必要なすべてのコードと依存パッケージが含まれています。

ほぼすべてのコンピューターおよびクラウドインフラストラクチャ企業が Kubernetes をネイティブ形式で採用していることは、注目すべき偉業です。これの重要な要因は、単一のリファレンスプラットフォームによって大規模な開発者コミュニティが生まれたことです。監視、ログ記録、セキュリティ、ストレージなどの分野で Kubernetes のコア機能を拡張しています。

CNCF の Landscape は、クラウド開発者向けのアプリストアのようなものです。「強力なサードパーティエコシステムがあることが、ブルームバーグLPが開発の多くをKubernetesに移行することを選択した大きな理由の1つでした」と、金融ニュースおよび分析会社のデータ分析およびインフラストラクチャ責任者であるスティーブン・バウアー氏は述べています。「すべてのアプリケーションをKubernetesに組み込む必要はなく、コンテナネットワークインターフェース（CNI）を使用して、さまざまなプロジェクトのさまざまなコンポーネントを組み合わせて統合することができます」と、コンテナサービス用のネットワークプラグインを活用するためのKubernetesのネイティブ仕様に言及しながら同氏は述べた。

「Kubernetes エコシステムは、市場が Kubernetes の威力を認識しているため、非常に強力です」と、Kubernetes の継続的デリバリープラットフォームを販売する Codefresh のチーフエバンジェリスト、ダンガーフィールド氏は述べています。「クラウド用のユニバーサル API ですか? 素晴らしい。」

ワイルドウェスト

しかし、一部の専門家は、現在のエコシステムはワイルドウェストのようなもので、多くのプロジェクトが注目を集めようと競い合っているものの、明確な勝者はほとんどおらず、間違った選択をすると、組織は今後何年も時間のかかる移行プロセスから抜け出せない可能性があると警告しています。

「現在Kubernetesを導入している企業は、オープンソースプロジェクトの進化という地雷原を進んでいます」と、SiliconANGLEの姉妹市場調査会社Wikibonのシニアアナリスト、ジェームズ・コビエルス氏は語る。「一般的に、幅広い実稼働レベルのエンタープライズユースケースに対応できる、成熟したベンダーに依存しないスタックにはまだ到達していません。」

エコシステムが急速に成長した理由の 1 つは、Kubernetes の所有権が Google からコミュニティに移行したことです。 Google は、プロジェクトを管理しようとすると競合他社の貢献が妨げられ、プラットフォームの成長が妨げられることを経験から学んでいた。彼らは、他のオープンソースプロジェクトに大混乱をもたらしたような分裂を避けたいと考えています。一例を挙げると、IaaS (Infrastructure as a Service) プラットフォームである OpenStack は、メンバー間の内紛や多数の派生バージョンが原因で、約束を果たせなかったと言われています。

「より広い世界で勝つためには、手放すことを学ばなければならず、私たちが残したギャップは他の人がそれを利用できるようになることを信じる必要がある」と、Googleのシニアソフトウェアエンジニアであり、Kubernetesの主任開発者の一人であるティム・ホッキン氏は語った。「表面的な作業には限度があり、エコシステムは繁栄しなければなりません。」

「Google が Kubernetes を単純にオープンソース化していたら、今日のような影響力はなかっただろう」と、ガートナーのリサーチディレクター、グレッグジークフリード氏は語る。

Linuxへの道を見つける

こうして CNCF が誕生しました。 2014年、GoogleがKubernetesをオープンソース化する準備をしていたとき、同社はすでにMesosと呼ばれる競合プロジェクトを育成していたApache Foundationを迂回し、代わりにLinux Foundationと提携してクラウドネイティブソフトウェアの新しい統治機関としてCNCFを設立することを選択しました。 Linux Foundation の単一の Linux カーネルをサポートしてきた実績は、Google が Kubernetes を前進させる上で期待しているモデルです。

オープンソースの管理団体は、特に関連製品やサービスを販売する貢献者との間で利益相反が発生することが多いため、長い間苦戦してきました。「イノベーションと安定性の間には微妙な境界線がある」とフォレスター・リサーチの副社長兼上級アナリスト、デイブ・バルトレッティ氏は言う。「これらの企業は収益を上げなければなりませんが、収益を上げるためには安定していなければなりません。」

Kubernetes 開発者は、コアを安定させ、エコシステムにおけるイノベーションを促進したいと考えています。 CNCF の使命は、業界全体の競合企業を単一の Kubernetes コードベースにまとめることです。 Linux プレイブックを活用し、Kubernetes ディストリビューション間の継続性を監査するための Kubernetes 認定適合プログラムを開発しました。

現在までに90のパッケージとホストされたKubernetesディストリビューション[2]が認定されており、「フォーク」と呼ばれる差異がないことが保証されています。 CNCF では、メンバーが作成したパッチを参照用にコミュニティに送信することも義務付けており、これにより不注意によるフォークのリスクが軽減されます。

それ以来、CNCF は独自の方法を切り開き、オープンソースプロジェクトのエコシステムを受け入れ、育成してきました。オープンソース財団の責任の 1 つは、コンテストで優勝者を選び、プロジェクト管理、サポート、ドキュメントのプロモーション、その他のリソースなどのサービスの提供を特定のプロジェクトに割り当てることで、優勝者のプロジェクトが成功できるように支援することです。これらのプロジェクトは「インキュベーション」と呼ばれ、成熟すると「卒業」します。

CNCF の創設者たちは、Apache のポリシーは制限が厳しすぎ、開発者中心すぎると考えています。彼らはより包括的なアプローチを望んでいました。「Apacheプロジェクトのポリシーとプロセスをすべて捨てて、最初からやり直したいと考えていた」とCNCFの創設者の1人で、現在は企業のクラウド移行支援に注力するGet Cloud NativeのCEOを務めるパトリック・オライリー氏は語る。

財団は、プロジェクトがインキュベーションプロジェクトになるためのハードルを下げ、ほとんどの意思決定権をプロジェクト所有者に委任します。「CNCF は、普段は話さないような人でも発言する機会を与えてくれる」とオライリー氏は語った。「これが最善の方法だと言っているわけではないが、現時点ではこれが最善の方法だ」

現在、CNCF の技術監視委員会が、どの新しいプロジェクトを育成するかを決定する唯一の機関です。これは、サプライヤーやその他のビジネス関係者を含む理事会とは別の組織です。財団はまた、業界からの圧力を最小限に抑えるために、各プロジェクトに中立的なガバナンスプロセスを設けることを要求しています。

「Apacheのコミュニティプロセスは少々扱いにくく、急速な進化や多様な視点を考慮に入れていない」とガートナーのジークフリード氏は語った。「CNCF は、管理されたコミュニティプロセスを育成し、奨励します。」

実際、CNCF は、将来オープンソースプロジェクトをどのように扱うべきかのモデルになると考える人もいます。「本質的には、これはマイクロサービスという新しい世界に合わせてアプリケーション開発プラットフォームを再構築するものです」とWikibonのKobielus氏は語った。「これはコンピュータの歴史上前例のない野心的な計画だ。」

しかし、ルールが少ないと不確実性が増すという欠点があります。イノベーションと安定性のバランスをとる上で、CNCF のアプローチが他のアプローチよりも必ずしも優れているかどうかはまだわかりません。これまでのところ、Kubernetes 以外に卒業したプロジェクトは 2 つだけです。1 つは、ネットワークサービスを簡素化するプロキシサーバーである Envoy です。もう 1 つは、監視プラットフォームである Prometheus です。

したがって、まだ初期段階にあり、プロジェクトが成熟するには何年もかかるでしょう。現在、「Kubernetes エコシステムは、多くのベンダーがディストリビューションやマネージドクラウドバージョンをめぐって競争する混沌とした分野になっている」と Kobielus 氏は言う。「そして、Googleが開発したKubernetesを中心としたオープンソースプロジェクトの数が増えたことで、混乱はさらに深刻化しました。」

無秩序から秩序へ

さまざまな選択肢が出現した背景には、いくつかの意図的な要因があります。 Google が Kubernetes をコミュニティにリリースする目的の 1 つは、コアコードベースを削減しながら、時間の経過とともに拡張機能にさらに多くの機能を移行することです。 Kubernetes自体は「リリース当時とはまったく異なる」とホッキング氏は語った。「コアからさらに多くの機能を排除したいと考えています。」

CNCFの最高技術責任者であるクリス・アニシュチック氏は、同財団はその原則を守るために懸命に取り組んでいると述べた。「Kubernetesは、コアから機能を取り出し、可能な限り拡張性を高めることに重点を置いてきました」と彼は今週のインタビューで語った。

しかし、Kubernetes を採用したい組織にとっては、選択肢の多さが問題を引き起こす可能性があります。これは「法的なコンプライアンス要件や社内基準に従う必要がある」大企業にとって特に心配なことだと、ポリシー主導のクラウドセキュリティおよびコンプライアンス企業であるDivvyCloudのCEO、ブライアン・ジョンソン氏は述べた。「エコシステム内のほとんどのプロジェクトには、この点に関して明確な技術的管理やベストプラクティスがありません。」

成功するプロジェクトを選ぶことで、組織はコミュニティの研究開発能力をより有効に活用できるようになります。プロジェクトの成功は、次のイノベーションにつながるからです。「オープンソースの世界では、すべてのエネルギーを吸収しようとする動きがある」とIBMのマギー氏は語った。「あなたはそれを使って作業したいと思うでしょう。」

いくつかのインキュベーションプロジェクトが卒業し、他のプロジェクトが廃止されるにつれて、Kubernetes エコシステムはもはや「独自のものを構築するためのツールの集まり」ではなくなるだろうと Siegfried 氏は述べた。「完全な統合となるだろう。」

Kubernetes エコシステムでは統合が進行中であるという証拠があります。 Sourced Technologies SLは今週、GitHubリポジトリの分析に基づき、「コアKubernetesプロジェクトへのコミット率が鈍化しているようだ」と述べた。

「統合の第1ラウンドが起こっているのを見てきました」とIBMのマギー氏は言う。「しかし、私たちはまだ、各部分をどう統合するかというエコシステム構築の段階にあります。」

こうしたサイクルを経験するのは新しいことではありません。業界が Linux を選択する前には、20 を超えるバージョンの Unix がありました。 Hadoop ビッグデータエコシステムも、ソフトウェアベンダーやクラウドコンピューティング企業が介入して導入と統合のプロセスを簡素化するまでは、初期の頃は非常に複雑でした。「最も可能性の高い結果は、主流のKubernetesフレームワークが5～10個存在し、それを早期に採用した企業がテストして検証することだ」とジョンソン氏は述べた。

Kubernetes の導入スピードが、その成熟プロセスを大幅に加速させました。「銀行の参入を認めれば、人々はもう大きな変化を望まなくなる」とオライリー氏は語った。

IT の選択

では、この時期に IT マネージャーはどのように意思決定を行うべきでしょうか?ほとんどの企業にとって、それは問題ではないとフォレスター社のバルトレッティ氏は言う。

「企業はまず、自分たちがプラットフォーム構築者なのか、プラットフォーム運営者なのか、それともプラットフォーム消費者なのかを理解しなければならない」と彼は語った。「この選択によって、リソースの割り当て方法が決まります。」

Bartoletti 氏は、プラットフォームビルダーを、Kubernetes プラットフォーム上でアプリケーションを作成することに主に依存するビジネスを展開する企業と定義しています。彼らにとって、エコシステムに関して正しい選択をすることは非常に重要です。プラットフォームの運営者は独自の Kubernetes インスタンスをホストすることを好み、プラットフォームを戦略的なものとは考えていません。プラットフォームの消費者は、機能するプラットフォームだけを望んでおり、それがどこから来たのかは特に気にしません。

「旅行予約システムを構築する場合、差別化できるプラットフォームを選択することが重要です」とバルトレッティ氏は語った。「しかし、平均的な企業がすべてのコミュニティに参加する必要はないでしょう。」

プラットフォーム運営者は、IBM、Red Hat、Pivotal Software など、エコシステムで活躍する商用 Kubernetes ベンダーと提携することで、行き詰まりを回避できます。「Pivotal が素晴らしいサービスを提供しているのであれば、変更する理由はありません」と彼は言う。「なぜなら、Pivotal の仕事は、そのサービスが確実に機能することだからです。」

プラットフォームの消費者にとっては、完全に制御可能なサービスを提供し、顧客の現在のステータスを維持する責任を負うことができる主流のパブリッククラウドプロバイダーを選択するのが最適です。

専門家は、現在のエコシステムは素晴らしいが、プラットフォームの消費者は傍観者でいるだけではいけないと考えている。オープンソースプロジェクトの利点の 1 つは、標準ツールセットに基づいており、環境の変化に適応できることです。たとえば、Docker Inc. は当初、Kubernetes ではなく独自の Swarm オーケストレーションツールを選択しましたが、後に Kubernetes との統合が妨げられることはなく、Swarm は引き続き選択肢として残っています。

責任あるオープンソースベンダーは厳格な決定を下しません。「[Amazon Web Services] が将来的に Lambda から別のサーバーレスプラットフォームに移行する可能性はありますが、Lambda を使用したことを後悔する人はいるでしょうか?」バルトレッティ氏は語った。「私の顧客は誰も後悔していません。」

この事実を考慮すると、IT マネージャーは自分の決定についてあまり心配する必要はありません。オープンソースの世界では、間違った選択でも満足のいく結果が得られる可能性があるからです。