Kubernetes を使うべきではない理由

Kubernetes はあなたのスタックに適していますか?

多くのチームが Kubernetes の使用を開始することに興奮しています。 Kubernetes 自体が提供する弾力性、回復力、移植性、信頼性、その他の利点に関心を持つ人もいます。中には、プラットフォームを利用してテクノロジーについてもっと学ぶ機会だけを求めているテクノロジー愛好家もいます。開発者の中には、それを使用した経験を積み、履歴書にもう一つの非常に望ましいスキルを追加したいと考える人もいます。一般的に、今日の開発者のほとんどは、ある時点で Kubernetes を利用したいと考えています。

それはとても良いアイデアかもしれないが、そうではない。

Kubernetesは分散アーキテクチャの問題を解決することを目指している

公式ドキュメント Web サイトの定義によると:

これは分散システム専用に設計されたものではなく、コンテナ化されたアプリケーション用に作られました。それでも、マイクロサービス ソリューションなどの分散システムの管理と拡張を容易にする多くのリソースが提供されます。オーケストレーション システムとしても考えられます。

自動化とオーケストレーションは異なる概念ですが、関連しています。自動化により、IT システムと人間のやり取りを削減または置き換え、代わりにソフトウェアを使用してタスクを実行し、コスト、複雑さ、およびエラーを削減することで、ビジネスの効率化に役立ちます。

通常、自動化とは単一のタスクを自動化することを指します。これは、複数の異なるシステムにまたがる多くのステップを含むプロセスまたはワークフローを自動化する方法であるビジネス プロセスとは異なります。プロセスに自動化を組み込み始めると、プロセスを自動的に実行するように調整できます。

—オーケストレーションとは何ですか? RedHat公式サイト

言い換えれば、Kubernetes を使用すると、適切なオーケストレーション システムがなければ維持するのが難しい複雑なソリューションの管理が容易になります。 DevOps エンジニアリング プラクティスを自分で実装することはできますが、数十から数百のサービスに拡張したい場合は拡張できません。

Kubernetesは複雑

その機能を活用するには、開発者と IT オペレーターは、コンテナ、ネットワーク、セキュリティ、移植性、回復力、および Kubernetes 自体に関する知識を持っている必要があります。ワークロードを適切に活用するには、各コンポーネントがどのように機能するかを理解する必要があります。クラスターを管理するには、従来の仮想化環境とは大きく異なる、クラスターのアーキテクチャ、ストレージ、API、管理システムを理解する必要があります。このソリューションを拡張するには、Helm や Istio などのサービスをデプロイ、監視、追跡するためのツールを統合する方法を学習する必要があります。そこには多くの新しい概念が追加されているので、チームはこの課題に備える必要があります。

Kubernetesは小規模なソリューションには高価

理由を理解するために、Kubernetes の重要な概念の 1 つである「回復力」について詳しく説明しましょう。これを活用するには、アプリケーションの実行に必要な最小数を超える追加のノードが必要です。ノードに障害が発生した場合、要求されたポッドは利用可能なノードに再配置されます。実稼働ワークロードの場合、回復力のために少なくとも 3 つのノードが推奨されます。

1 つのアプリケーションのみをホストする場合、それだけの価値がないことは想像に難くありません。ただし、10 個以上のクラスターがある場合でも、クラスターのコストが維持する価値があるかどうかを検討する必要があります。

環境を維持するためのコストには運用サポートも含まれます。プラットフォームが複雑になるほど、より多くの専門家が関与する必要があります。これは、サポートを提供するためにサードパーティの専門会社を雇うこと、または Openshift のようなサポート サービスを含むソリューションを雇うことを意味する場合があります。

Kubernetesを選択するタイミング

使用するアーキテクチャ、アプリケーションの数とアプリケーション間の依存関係のレベル、チームの運用能力に応じて、利用可能なすべてのテクノロジーの中で Kubernetes が適切な選択肢であるかどうかを検討できます。

Web Apps for Containers を使用すると、完全に本番環境に対応した環境が得られます。標準プラン、SSL 機能、アプリケーション インサイトを使用すると、何もすることなく、安全でスケーラブルな監視環境を実現できます。

分離されたアプリケーションのみ、または接続されたアプリケーションの数が少ない場合、同じ仮想ネットワークで実行されている Azure Web アプリとコンテナー インスタンスの組み合わせで十分な場合があります。

一方、コンテナ化されたアプリケーションの数が増えている場合は、それらを Kubernetes でホストすると興味深い場合があります。 Web アプリケーション、API、定期的なジョブなど、複数の種類のアプリケーションを 1 つの集中環境でホストできるようになります。チームは、複数のクラウドネイティブ ソリューションではなく、Kubernetes に集中できるようになります。

マイクロサービスのような分散シナリオを扱う場合は、ぜひ試してみてください。分散アーキテクチャは複雑であり、Kubernetes はそれを簡単にすることを目的としています。 Kubernetes 以外に、分散アプリケーション向けに完全かつスケーラブルなプラットフォームは考えられません。

結論は

互いに分離されているか、相互に依存していない少数のコンテナー化されたアプリケーションを扱う場合は、コンテナー用の Azure Web Apps や Azure Container Instances などの他のホスト オプション、またはそれらの組み合わせの方がシンプルで、コストも安くなる場合があります。

チームが Kubernetes に慣れていて、コンテナー化されたアプリケーションの数が増えている場合は、Azure Kubernetes Service などの単一の Kubernetes プラットフォームでそれらを集中的にホストする価値があるかもしれません。

Kubernetes は、パフォーマンスを向上させ、分散システムに必要な操作の量を削減するように設計されたプラットフォームです。基本的に、これにより、マイクロサービスなどの複雑なシナリオの操作が簡素化されます。

多くのアプリケーションを扱っていない場合、分散アーキテクチャを使用していない場合、またはスタッフに専門家がいない場合は、Kubernetes が提供する機能を活用することはできません。Kubernetes はそのようなユーザー向けに構築されていないからです。結果的に、ソリューションに予期せぬ不要な複雑さが追加されることになります。