Kubernetes がアプリケーションに適しているかどうかを判断する 5 つの方法

多くの場合、アプリケーションの最新化への道筋は次のようになります。まず、アプリケーションをマイクロサービスにリファクタリングします。次に、各サービスをコンテナ化します。最後に、Kubernetes にデプロイします。 Kubernetes は、コンテナ化されたアプリケーションを実行するための事実上の標準プラットフォームとなったオープンソースのオーケストレーション エンジンです。

問題は、すべての近代化がこの道をたどるわけではないということです。多くの場合、Kubernetes は最新のソフトウェア デプロイメントの一部ではありません。

Kubernetes は優れたテクノロジーですが、すべてのアプリケーション展開に最適なソリューションとは程遠いものです。アプリケーションがコンテナを使用してマイクロサービスとして実行される場合でも、Kubernetes は必ずしもこれらのアプリケーションをデプロイするための最良の方法とは限りません。コンテナを実行するために使用できる、よりシンプルなソリューション (Amazon ECS や Lambda など) も他にもあります。また、アプリケーションがマイクロサービスのセットでない場合は、Kubernetes は明らかにこれらのアプリケーションを実行するのに適した方法ではありません。

では、Kubernetes では実際にどのような種類のアプリケーションを実行できるのでしょうか?アプリケーションの機能要件またはアーキテクチャ特性のうち、K8s (Kubernetes フォロワーがこのプラットフォームを呼ぶときの名前) に特に適しているもの、または逆に、代替ホスティング ソリューションに適しているものはどれですか。

この記事では、Kubernetes を使用してアプリケーションをデプロイする前に準備しておくべき 5 つの重要な要素を紹介し、これらの質問に答えます。また、Kubernetes ワークロードの「アンチパターン」、つまり特定のワークロードを K8s で実行するかどうかを選択する際にチームがよく犯す間違いについても見ていきます。

アプリケーションが Kubernetes に適しているかどうかを判断するにはどうすればよいですか?

アプリケーションが Kubernetes でのデプロイメントに適しているかどうかを評価するときは、Kubernetes が次の各特性にどの程度適合しているかを考慮してください。

1. アプリケーションは、小さく、クリーンで、スタンドアロンのスケーラブルなサービスとして実行されます

アプリケーションが小さく簡潔なサービスのセットとして実行される場合、Kubernetes に適しています。主な理由は、Kubernetes が各サービスを個別に動的にスケーリングできるため、アプリケーションが利用可能なホスティング リソースを最も効率的に使用できることです。

対照的に、「モノリス」として実行されるアプリケーション（つまり、アプリケーション全体が単一のサービスとして実行されるアプリケーション）は、Kubernetes のメリットを享受できません。 K8s 上でモノリシック アプリケーションを実行することを選択すると、より単純なデプロイメント モデル (別の仮想マシン上でアプリケーションを実行するなど) を選択する場合よりも複雑になり、モノリシック アプリケーションはきめ細かく制御したり動的にスケーリングしたりできないため、多くのメリットが得られません。

2. アプリケーションはハードウェアに依存しない

K8s を使用してサーバーのクラスターをセットアップし、これらのクラスター全体にアプリケーションをデプロイできるため、特定のハードウェア構成を必要としないアプリケーションは Kubernetes 上で適切に実行されます。 Kubernetes は、クラスター内の各アプリケーションを配置する場所を決定し、必要に応じてアプリケーションにリソースを割り当てます。あるいは、Kubernetes がデプロイメント時に各アプリケーションに割り当てるリソースの最小量を定義することもできます (通常は定義する必要があります)。

一方、アプリケーションで厳密な CPU またはメモリの割り当てが必要な場合 (または GPU などの特殊なハードウェア デバイスにアクセスする必要がある場合) は、通常、K8s クラスターではなく VM にアプリケーションを直接デプロイする方が合理的です。

3. アプリケーションは多数のアプリケーションの1つであり、これらのアプリケーションは共有インフラストラクチャ上で共存できます。

Kubernetes では、名前空間と呼ばれる機能を使用してワークロードを相互にセグメント化できます。名前空間は基本的に、単一のサーバー クラスター内で定義できる仮想境界です。ただし、Kubernetes では、各アプリケーションを専用の仮想マシンまたは物理サーバー上で実行することで得られる「ハード」なアプリケーション分離は提供されません。

つまり、サーバー クラスターを共有できるワークロードが多数あり、それぞれが独自の仮想環境を実行している場合は Kubernetes が最適ですが、ワークロード間の堅牢な分離が必要な場合は K8s はあまり適していません。また、ワークロードの数が少ない場合もあまり意味がありません。その場合、Kubernetes のセットアップと管理の難しさが、Kubernetes がもたらす価値を上回ります。

4. アプリケーションは複数のサービスを実行します。一部は内部サービス、一部は外部サービスです。

通常、最新のアプリケーションでは、一部のマイクロサービスのみが外部である必要があり、つまり、それらのマイクロサービスはアプリケーションの外部 (ただし、会社のネットワーク内) のリソースに接続できますが、その他のサービス (アプリケーションのフロントエンドとバックエンド データベース間でデータを内部的に移動するサービスなど) は、アプリケーションまたはこれらのアプリケーションをホストするサーバー クラスターに接続する必要はありません。

Kubernetes は、このようなタイプのアプリケーションに最適なソリューションです。Kubernetes を使用すると、どのサービスを企業ネットワークに公開し、どのサービスを社内専用にするかを細かく定義できるためです。また、企業ネットワークの IP アドレスを節約できることも非常に重要です。これは、通常、エンタープライズ環境では IP アドレスの供給が限られているため重要です。

5. アプリケーションにカスタムDNS設定が必要

Kubernetes を使用すると、管理者はネットワーク名の解決方法を細かく制御できるため、IP アドレスをホスト名またはサービス名にマッピングするために (汎用 DNS サーバーを使用するのではなく) カスタム ドメイン名設定を必要とするアプリケーションに役立ちます。

ほとんどの従来のアプリケーションでは、特別な DNS 設定は必要ありません。ただし、DNS 構成が手動で設定されているエンタープライズ環境や、特別な DNS 設定を必要とする内部サービスが多数あるアプリケーションでは、Kubernetes は他の種類のホスティング環境では利用できないレベルの DNS 制御と柔軟性を提供するため、Kubernetes は非常に便利です。

Kubernetes を決して使用してはいけない場合

Kubernetes を使用するかどうかの決定プロセスについてもう少し詳しく説明するために、K8s ルートを選択しない場合の例を見てみましょう。

モノリシック アプリケーションがある場合は、それを Docker コンテナーに配置することにします。 Kubernetes は技術的にはコンテナ化されたモノリスを実行できますが、そのようなアプリケーションを Kubernetes にデプロイすることを選択すると、多くの課題に直面し、ほとんどメリットが得られません。

Kubernetes はアプリケーションのさまざまな部分を個別にスケーリングできないため、アプリケーションはホスト リソースを効率的に使用できません。アプリケーション全体は、水平方向または垂直方向にのみ拡張できます。

コンテナ化されたモノリスは、配信段階 (開発、テスト、本番など) ごとに異なる構成が必要になる場合もあります。つまり、構成エラーによる障害の可能性の低減など、一貫した構成という点でコンテナの利点を享受できなくなります。

最悪なのは、セキュリティ構成データ (アクセス資格情報など) をモノリシック コンテナ イメージにコピーする必要が生じ、機密情報が悪意のある人物の手に渡るリスクが増すことです。

要するに、モノリシック アプリケーションを Kubernetes 上のコンテナーとして実行することを技術的に妨げるものは何もありませんが、そうすることは決して良い考えではありません。これは Kubernetes 上でアプリケーションを実行する 1 つの方法ですが、客観的に見て悪い方法です。

最後に、私は Kubernetes に反対しているわけではないことを強調したいと思います。 Kubernetes には、特に共有クラスター上で適切に動作し、特別なネットワーク構成を必要とする個別のマイクロサービスとして実行されるアプリケーションにとって、多くの利点があります。

しかし、他のアプリケーションの場合、Kubernetes よりもセットアップと管理が簡単で、パフォーマンス、スケーラビリティ、コスト削減も向上する代替のデプロイメント ソリューションが存在する可能性があります。誰もがやっているからという理由だけで Kubernetes の流行に飛びつく前に、一歩下がって、最も人気のあるものではなく、特定のアプリケーションに最適なデプロイメント戦略について考えることが重要です。