純粋なアップストリームKubernetesは最高のKubernetesです

​翻訳者 |ブガッティ

校正：孫淑娟

オープンソース エコシステムは、企業のサポートが限られているニッチなプロジェクトから、ソフトウェアを開発するためのデフォルトの方法へと急速に変化しました。大規模から小規模まで、組織がオープンソース ソフトウェアを使用してイノベーションと製品開発を加速しています。

企業におけるオープンソースの現状に関する調査では、企業の 95% がオープンソースを非常に重視していることがわかりました。企業の 75% は、オープンソース ソフトウェアが IT 戦略にとって非常に重要であると主張しています。また、企業の 77% が今後 1 年間でオー​​プンソースの利用を増やす予定です。

一方、英国政府の技術職員の 71% は、5 年前よりもオープン ソース ソフトウェアの使用が増えていると回答しています。米国国防総省は、プロプライエタリソフトウェアよりもオープンソースソフトウェアを優先することを示すメモさえ発行しました。

Kubernetes が成熟するにつれて市場が統合され、多くの Kubernetes 製品がさまざまなアーキテクチャ、機能、インターフェースを提供しています。一部の製品は他の製品よりもオープン性や柔軟性が低く、さまざまな制限、依存関係、ライセンス条件が伴います。

オープンな Kubernetes 標準から逸脱すると問題が発生する可能性があります。 Cloud Computing Magazine が指摘したように、「標準化されたフォーマットがなければ、相互運用性、移植性、コンプライアンス、信頼性、セキュリティを確保することは困難です。」

1. 純粋なアップストリーム オープンソース Kubernetes とは何ですか?

Upstream Kubernetes は Kubernetes のオープンソース バージョンであり、Cloud Native Computing Foundation によってホストおよび保守されており、コードの開発、ドキュメント化、貢献を行っています。これは、コンテナをオーケストレーションするためのコアの「バニラ」Kubernetes で構成されており、アプリケーションは接続されておらず、すべてが検査、変更、再配布のために公開されています。

フリーおよびオープンソースのソフトウェア プロジェクトはすべて、コミュニティ全体に役立つテクノロジーを作成するという善意に基づいています。誰でもコードにアクセスして共同作業し、バグを迅速に修正し、パッチを追加し、パフォーマンスを最適化できます。しかし、プロジェクトが進化するにつれて、コード内で「フォーク」と呼ばれる、目標や視点の相違が生じる可能性があります。

2. Kubernetes のフォークとは何ですか?

Kubernetes のフォークは、メインのワークフローとは独立して開発されるオープンソース プロジェクトのバージョンです。フォークは、開発コミュニティの一部またはサードパーティベンダーがアップストリーム プロジェクトをコピーし、いくつかの変更を加えて完全に独立した開発ラインを開始するときに発生します。

Kubernetes をフォークする理由としては、意見の相違 (技術的または個人的な)、アップストリーム プロジェクトの開発の停滞、または異なる機能の要望などが考えられます。これはオープンソース環境でも独自の環境でも発生する可能性があります。

オープンソースの Kubernetes フォークが元のコードを改善すると、他のフォークがそれを活用してコードを独自のフォークと組み合わせ、開発者やエンドユーザーのニーズをより適切に満たすことができます。

しかし、独自の環境での Kubernetes フォークの場合、ベンダーまたはクラウド企業は独自のニーズに合わせてソース コードを変更し、ソフトウェアを再パッケージ化して、独自のディストリビューションとして顧客に提供します。 Kubernetes を本番環境で実行するために必要な追加コンポーネントを変更する可能性があります。

これにより、ソリューションの管理が複雑になり、ベンダー ロックインのリスクが生じます。

3. Kubernetesのフォークの問題

Kubernetes を大規模に導入および管理するのは困難です。多くの組織は、コンテナ プラットフォームに対するエンタープライズ サポートを得るために独自のディストリビューションを使用していますが、これにより Kubernetes の大幅な分岐バージョンが生まれました。

課題としては次のようなものがあります。

（１）パッチ、バグ修正、アップグレード、新機能の複雑さ

新しいアップデートごとに、変更をカスタム ディストリビューションと互換性を持たせることがより困難になります。これは時間がかかり、費用のかかるプロセスです。 Kubernetes をフォークするベンダーは、アップストリームからの改善やバグ修正を取得するのに少なくとも 6 か月かかるため、クラスター API の古いバージョンを使用することが多いです。

（２）ベンダーロックイン

Kubernetes でフォークするとロックインが発生し、顧客がソリューションを簡単に置き換えたり移行したりできなくなります。これにより、パブリック、プライベート、内部サービス間でアプリケーションとデータをシームレスに移動する柔軟性が失われます。ロックインの問題により、会社が成長しても選択肢があまり残されません。ソースコードがオープンソースであっても、ベンダーは顧客が他のプラットフォームに移行できないようにする機能で Kubernetes をラップすることができます。

（３）機能性の欠如

Kubernetes のフォークバージョンでは、アプリケーションの機能が壊れる可能性があります。一部のカスタム ディストリビューションでは、完全な機能を実現するために独自の API と CLI に依存しており、ロックインにつながります。また、カスタム ディストリビューションがベンダーのカスタム Linux カーネルでのみ実行される場合、ロックインにつながります。最終的には、このフォークを維持することがより困難になり、パッチと機能の互換性に関する重要な作業を行わずに、最新のアップストリーム パッチをフォークにマージできなくなります。製品が製造中止になった場合は、運が悪いかもしれません。

（4）あまり安全ではない

Kubernetes のフォークでは安全性の低いコードが実行される場合があります。オープンソース コードに脆弱性が発見され、アップストリーム コミュニティによって修正された場合、フォークされたバージョンのコードはアップストリーム コードと同じではないため、メリットが得られない可能性があります。

（5）相互運用性の欠如

ベンダーは、カスタムディストリビューション用、または本番環境で Kubernetes を実行するために必要なサポート アプリケーションのコードなどを変更できます。 Kubernetes への変更は特定のベンダーのアプリケーション スタックや管理ツールで機能しますが、これらの独自の変更により、コンポーネントのカスタム ビルドにロックされ、他のアップストリーム オープン ソース プロジェクトとの統合ができなくなります。スタックが複数の製品で構成されている場合、相互運用性を実現するのは難しく、規模が大きくなるにつれて下流で多くの問題が発生する可能性があります。

（6）技術的負債

アップストリームから大幅に変更されたフォークをマージバックするのは困難です。これを技術的負債と呼び、共同開発のメインブランチから逸脱することで生じるソースコードを維持するためのコストを指します。フォークしたコードに変更を加えるほど、フォークをアップストリーム プロジェクトに戻すのにかかる費用と時間が増えます。

4. 純粋なアップストリームKubernetesが解決策

純粋なアップストリーム オープン ソース Kubernetes は、意思決定の中心であり、コードを貢献する場所であり、ソース コードを継続的に改善する組み込みコミュニティを備えています。

純粋なアップストリーム ソリューションにより、より大きなコミュニティとアイデアを共有し、新しい機能やリリースをアップストリームで受け入れてもらうことができます。アップストリームに依存するすべてのプロジェクトと製品は、将来のリリースを選択したり、最新の (またはすべての) アップストリーム パッチをマージしたりするときに、以前の作業から恩恵を受けます。

誰でもアップストリーム コード リポジトリから Kubernetes をコピー、インストール、配布できますが、大企業や組織では、エンタープライズ環境向けに認定され、テストされ、強化された製品が必要です。その結果、組織は、アップストリーム Kubernetes をビジネス ニーズを満たすダウンストリーム製品に変換するためにベンダーに依存することになります。

オリジナルリンク: https://www.cncf.io/blog/2023/01/30/pure-upstream-kubernetes-is-the-best-kubernetes/