K8s の交換が必要です!

著者 |趙雲

現在、Kubernetes はマイクロサービスのデプロイメント問題を解決し、すでにコンテナ オーケストレーションのデファクト スタンダードとなっているため、運用保守部門とバックエンド アーキテクチャ部門の両方にとって、Kubernetes の習得は必須となっています。 Kubernetes は業界ではよく知られる名前になりました。これは間違いなく多くの開発者にとって理想的なソリューションです。

しかし、Kubernetes は本当に完璧なのでしょうか?開発者は Kubernetes が提供する可能性に熱心ですが、イライラする側面もあります。Kubernetes と並行して歩むと、途中で多くの複雑な問題が伴うことになります。そのため、より使いやすい代替手段を求める組織が増えています。

では、なぜ Kubernetes は一部の企業に嫌われ始めているのでしょうか?

Kubernetesが登場

Kubernetes はもともと、Google が同社の非常に複雑なコンテナ管理プラットフォームである Borg のオープンソース版として開発しましたが、後に世界的なムーブメントへと発展しました (中国では、「オープンソース + サブスクリプション」チームコラボレーションモデルの波も引き起こしました)。現在、Cloud Native Computing Foundation (CNCF) が所有し、大規模な貢献者コミュニティによって維持されています。

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

Kubernetes は、自動化されたソフトウェアの展開、コンテナ管理、インフラストラクチャのスケーリングの事実上の標準となっています。組み込みのデフォルトのレプリケーションと自動スケーリングを使用してコンテナ化されたアプリケーションを実行し、アプリケーションが堅牢に実行され、迅速に拡張できるようにします。

Kubernetes 放棄の謎

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

ほとんどの組織は、Google や Facebook のような規模で運営されていません。 Facebook は、総面積 4,000 万平方フィート、総費用 200 億ドルのデータセンターを 18 か所所有していると主張している。 Mcafee によれば、「従業員数が 1,000 人未満の企業では、平均してわずか 22 個のカスタム アプリケーションしか実行されていません。」ただし、これらのアプリケーションを効果的に管理するには、依然として最新のテクノロジと方法が必要です。しかし、技術的に強力すぎる Kubernetes は、これらの少数のアプリケーションには過剰であり、アプリケーション自体から注意をそらす可能性さえあります。

2. Kubernetesの設定が複雑すぎる

Kubernetes は、学習曲線が急峻で、運用が複雑であることで知られています。しかし、Kubernetes の本来の目的が「分散システムの弾力的な運用」というシンプルなものであることをご存知ないかもしれません。しかし、現状では、この単純な目的があまりにもわかりにくくなっているようです。

企業が Kubernetes を使用するために AWS や Azure などのクラウド プロバイダーを購入すると、関連する展開の複雑さは基本的にすべて自然に隠されます。しかし、Kubernetes をローカルで実行すると、etcd、負荷分散、可用性、自動スケーリング、ネットワーク、失敗したデプロイメントのロールバック、永続ストレージなどの複雑な要素を管理するために、ローカル開発者が必要になることになります。

通常はパブリック クラウドが処理する上記の複雑さを処理するサービスを構築することに加えて、オンプレミスで Kubernetes を DIY 方式で展開するには、コア コードの大幅な変更が必要になります。

Kubernetes を開発した Google でさえ、「Kubernetes は正しく構成するのが難しい」と認めざるを得ず、Istio のようなツールはセットアップして使い始めるのが難しいです。

Kubernetes はやり過ぎる傾向があります。あまりにも多くの問題を解決し、その結果、プラットフォームはさまざまな方向に引っ張られてしまいました。

3. 導入コストと保守コストが高い

Kubernetes は無料で使用できますが、実際に実装するには高価な製品です。隠れたコストは膨大で、インフラストラクチャの管理と、その上で実行されるワークロードの最適化は非常に負担が大きいです。したがって、「無料は高価」であり、Kubernetes は導入と保守に必要な時間と人的資源の点でコストがかかります。

4. 困難で面倒な移行

Kubernetes への移行は困難で要求の厳しい作業です。この点で成功するには、企業は元のアーキテクチャを部分的に、あるいは完全に再構築する必要があります。同時に、Kubernetes クラスターが確実に実行されていることを確認するには、大規模なチームが必要です。適切にメンテナンスされた Kubernetes セットアップを構築できたとしても、基本的なクラスターから信頼性の高い本番環境に移行するには、まだ多くの作業が必要です。

光輪は消え、新たな要求が生まれている

まず、コンテナとクラウド オーケストレーションには、「シンプルさを保つ」アプローチが必要です。ソフトウェアの世界のあらゆる人にとってあらゆるものになろうとする試みの中で、Kubernetes は過度に複雑になってしまいました。 Kubernetes の魅力は薄れ始めており、多くの企業がコンテナ オーケストレーションの分野で「本来の意図に忠実であり続ける」代替ソリューションを探し始めています。

第二に、より簡単に始める方法が必要でした。 Kubernetes のさまざまな部分には、それを補完するための追加のツールが必要ですが、Kubernetes の複雑さの処理と管理に役立つさまざまなツールがすでに存在しています。つまり、開発者は、本番環境の Kubernetes クラスターでアプリケーションの実行を開始する前に、複数のミニツールの操作方法を学習する必要があります。

複数のインフラストラクチャ プロバイダーに展開しようとすると、このワークロードはさらに複雑になります。多くの人は、この学習プロセスから解放され、新しいツールを組み合わせて使用​​したいと考えています。この混乱を回避するのに役立つ代替案はどれも歓迎すべき変化です。

さらに、開発者は DevOps チームなしで構築できます。複雑であることが知られているシステムの場合、ビルド プロセスが大幅に遅くなる可能性があります。これは、これまでインフラストラクチャを扱ったことのない開発者にとって、Kubernetes 開発ワークフローに慣れることが困難な場合があるためです。

さらに、フレームワークに精通している開発者であっても、遭遇するさまざまなボトルネックを克服するために、Kubernetes の専門家と DevOps チームの支援が必要です。これにより、最終的には生産性が低下し、リリース サイクルが長くなります。

その結果、組織は開発者の DevOps チームへの依存を排除​​する方法を模索しています。開発者に必要なときに必要なリソースにアクセスできる柔軟性と自律性を提供したいと考えています。

Kubernetes の代替

Kubernetes は長年にわたりコンテナ管理の分野を支配してきました。代替手段の必要性が完全に認識されたことで、Kubernetes と同じことをより少ない手間と複雑さで実行できると約束する新しいソリューションが登場しました。

現在のコンテナ オーケストレーションの分野を見ると、これらのニーズを満たし、Kubernetes に取って代わる可能性のあるのは誰でしょうか?

多くの人がCycle.ioに注目しています。 Cycle は開発者向けに構築されたメンテナンスの少ないプラットフォームであり、Kubernetes の競合製品です。開発者が Cycle に期待している理由はいくつかあります。Cycle は、強力なコンテナ オーケストレーションと、事前構成されたサービス、自動化されたネットワーク、インフラストラクチャ管理、完全な DNS ソリューション、イメージ最適化などの機能を深く統合しています。 Cycle は、すべてのサーバーにプラットフォームの更新を自動的に提供するのに役立ち、企業はサポートされている任意のプロバイダーからローカル インフラストラクチャを展開できます。このように、クラウド サービス プロバイダー全体のインフラストラクチャ、データ、アプリケーションは、いずれか 1 つのプロバイダーに縛られることはありません。さらに、Cycle は OCI に完全に準拠しており、その理念は「量より質」に重点を置いています。

もちろん、コンテナ オーケストレーションの分野には代替オプションとして優れたツールが数多くありますが、ここでは詳しく挙げていません。

最後に

Kubernetes は今日非常に人気があり、多くの素晴らしい機能を備え、多くの支持者を抱えています。 Kubernetes を採用した多くのチームも非常に満足しています。ただし、これらのチームのインスタンスのほとんどは、Google や Amazon などの強力なクラウド ベンダーによって管理されています。これは、企業の実際のビジネス開発に隠れた危険をもたらします。1 つは、企業がこれらの機能を本当に必要とするかどうかの考慮を無視していること、もう 1 つは、企業と開発者が作業をサポートするためにこれらの「代理で管理される」抽象化だけに頼ることができないことです。最下層で何が起こっているかを理解することによってのみ、真の制御を実現できます。

他の人が使っているからといって、Kubernetes を使用しないでください。実際のビジネス ニーズを慎重に評価します。解決しようとしている問題、対処しようとしている問題点、Kubernetes が本当に必要かどうかを把握する必要があります。これらの質問に答えた後、Kubernetes を Cycle などの他のよりシンプルで効率的なオプションと並べて検討し、それぞれのハードコストとソフトコストを比較検討する必要があります。

たとえば、大規模なインフラストラクチャに一連の同種のサービスを展開する予定の場合は、Kubernetes が最適な選択肢となる可能性があります。追加の複雑さと運用コストに注意してください。これらのコストの一部は、Kubernetes クラウド サービス環境を使用することで回避できます。保守と拡張が容易な信頼性の高いオーケストレーション サービスだけを探しているのであれば、これはやりすぎです。

結局のところ、あらゆるテクノロジーは、企業が直面する問題の解決に役立ちます。本当にKubernetesが必要ですか?

参考リンク:

https://dzone.com/articles/the-need-for-a-kubernetes-alternative

https://www.theregister.com/2021/02/25/google_kubernetes_autopilot/

https://dzone.com/articles/image-optimization-common-missing-and-solutions

https://zhuanlan.zhihu.com/p/346301133