Kubernetesの代替品の必要性

​k8s はコンテナ オーケストレーションの分野ではよく知られるようになりました。多くの開発者にとって理想的なソリューションとなっていることは否定できません。しかし、Kubernetes は本当に完璧なのでしょうか?逆に、Kubernetes が提供する可能性に熱狂していた人が、その途中で発生する多くの問題を解決しようとしてイライラしてしまうこともあります。そのため、Kubernetes のより使いやすい代替手段を求める組織が増えています。この記事では、これらの代替手段の必要性を強調し、Kubernetes に代わる強力な候補を紹介します。

Kubernetesが解決しようとしている問題

Kubernetes は、Google の過度に複雑なコンテナ管理プラットフォームである Borg のオープンソース バージョンとして始まりましたが、その後、世界的なムーブメントに成長しました。現在、Cloud Native Computing Foundation (CNCF) によって管理され、多数の貢献者によって保守されています。

Kubernetes は、ソフトウェアの展開、コンテナ管理、インフラストラクチャのスケーリングを自動化するための事実上の標準となっています。組み込みのデフォルトのレプリケーションと自動スケーリングを使用してコンテナ化されたアプリケーションを実行し、それらの正常性、オンライン状態、迅速なスケーリングを保証します。

あらゆる Kubernetes インフラストラクチャの中心となるのはコンテナです。コンテナは、ハイパーバイザーなどの VM の不要な部分を取り除き、オペレーティング システムとアプリケーションの必要なコンポーネントのみをきちんとしたパッケージにまとめます。

代替手段を求める組織が直面する課題

1. Kubernetesはやりすぎかもしれない

ほとんどの組織は、Google や Facebook のような規模で運営されていません。私たちが話しているのは、18 のデータセンター、4,000 万平方フィート、そして 200 億ドルのことです。 McAfee は、「従業員数が 1,000 人未満の企業では、平均 22 個のカスタム アプリケーションが実行されています」と述べています。確かに、これらのアプリケーションを効果的に管理するには、依然として最新のテクノロジーと方法が必要です。しかし、Kubernetes の技術力は非常に優れているため、アプリケーション自体から注意をそらしてしまう可能性もあります。

2. Kubernetesは複雑すぎる

Kubernetes の当初の目標は「分散システムを柔軟に実行する」という非常に単純なものでしたが、この単純な目的は現状ではあまりにも混乱を招いているようです。 Google のレビューでも「Kubernetes はユーザーが正しく設定するのが難しい」と述べられており、Istio などのツールはインストールや使用が難しいです。 Kubernetes はあまりにも多くの問題を解決しようとするため、プラットフォームがさまざまな方向に引っ張られてしまいます。

3. 所有コストとメンテナンスコストが高い

Kubernetes は無料で使用できますが、非常に高価な製品です。インフラストラクチャを管理し、その上で実行されるワークロードを最適化するための隠れたコストが発生します。したがって、状態を維持するために費やす時間という点では、Kubernetes は高価です。

4. 困難で面倒な移行

Kubernetes への移行は困難で難しい作業です。これを行うには、アーキテクチャの一部またはすべてをリファクタリングする必要があります。 Kubernetes クラスターを継続的に稼働させるには、大規模なチームも必要です。適切にメンテナンスされた Kubernetes セットアップを構築できたとしても、基本的なクラスターから信頼性の高い本番環境に移行するには、まだ多くの作業が必要です。

人々は何を求めているのでしょうか?

コンテナとクラウドのオーケストレーションへの自律的なアプローチ

ソフトウェアの世界では、Kubernetes はあらゆる人にとってあらゆるものになることを目指していますが、過度に複雑になっています。 Kubernetes の魅力は薄れつつあり、人々はコンテナ オーケストレーションに対する独自のアプローチを提供する代替手段を探しています。

もっと簡単に始める方法

Kubernetes の複雑な部分に対処し、管理するために、さまざまなツールが使用されます。 Kubernetes のさまざまな領域では、それを補完するための追加のツールが必要になります。つまり、本番環境の Kubernetes クラスターでアプリケーションの実行を開始する前に、複数のミニツールの操作方法を学習する必要があります。複数のインフラストラクチャ プロバイダーにまたがって展開しようとすると、このワークロードはさらに複雑になります。多くの人は、この学習プロセスを回避し、さまざまなツールを組み合わせて開始したいと考えています。この混乱を回避するのに役立つ代替案はどれも歓迎すべき変化です。

開発者はDevOpsチームなしでも構築できる

複雑であることが知られているシステムを扱う場合、ビルド プロセスが大幅に遅くなる可能性があります。これは、これまでインフラストラクチャを扱ったことのない開発者にとって、Kubernetes 開発ワークフローに慣れることが非常に難しい場合があるためです。さらに、フレームワークに精通している開発者であっても、遭遇するさまざまなボトルネックを克服するために、Kubernetes の専門家と DevOps チームの支援が必要です。これにより、最終的には生産性が低下し、リリース サイクルが長くなります。その結果、組織は開発者の DevOps チームへの依存を排除​​する方法を模索しています。開発者に必要なときに必要なリソースにアクセスできる柔軟性と自律性を提供したいと考えています。

Kubernetes の代わりに Cycle を使用する理由は何ですか?

代替手段の必要性が完全に認識されるまで、K8s ファミリーは数年間コンテナ管理の分野を独占していました。この需要により、Kubernetes と同じことを面倒や複雑さなしで実行できる新しいソリューションが生まれました。そのようなソリューションの 1 つが、Kubernetes と競合する開発者向けの低コストのオペレーティング プラットフォームである Cycle.io です。

Cycle は、強力なコンテナ オーケストレーションと、事前構成されたサービス、自動化されたネットワーク、インフラストラクチャ管理、完全な DNS ソリューション、およびイメージ管理を組み合わせています。すべてのサーバーへのプラットフォーム更新の配信を自動化するのに役立ちます。このループを使用すると、サポートされている任意のプロバイダーから独自のインフラストラクチャを展開することもできます。そのため、いずれかのクラウド サービス プロバイダーに縛られることなく、あらゆるクラウド サービス プロバイダーにわたってインフラストラクチャ、データ、アプリケーションを所有できます。このサイクルは OCI (Open Container Initiative) に完全に準拠しており、量よりも質を優先することに重点を置いています。

結論は

Kubernetes は長年にわたり、誰もが導入を求めるホットな話題でした。だから、その人気に夢中になるのは当然です。ただし、コンテナ オーケストレーションは、ビジネスが直面する技術的な問題を解決することを目的としていることを覚えておくことが重要です。どのような問題を解決しようとしているのか、どのような問題点をターゲットにしようとしているのか、そして Kubernetes が本当に必要かどうかを把握する必要があります。これらの質問に答えた後、Kubernetes と、Cycle などのよりシンプルで効率的な他のオプションを検討し、それぞれのハードコストとソフトコストを比較検討する必要があります。この記事が、皆さんが新たな視点を得て、組織にとって正しい決定を下すためのガイドとして役立つことを願っています。