Kubernetes が SaaS に適しているかどうかを知る方法

[51CTO.com クイック翻訳] Kubernetes は素晴らしい技術であり、私自身も自分の SaaS 上で拡張、展開、管理を実装するプロセスから多くの恩恵を受けました。しかし客観的に言えば、一般的に以下の理由により、誰もが導入後すぐに恩恵を受けられるわけではありません。

• コンテナ技術への知識不足
• アプリケーションアーキテクチャはKubernetesのメリットを生かすのに適していない
• 作業量と時間の増加

したがって、Kubernetes に興味はあるが、必要な時間とリソースを投資する価値があるかどうかわからない場合は、この記事が参考になるはずです。

1. コンテナの使用経験はありますか?

Kubernetes が何を実現できるかを理解するには、まずコンテナが提供する利点を理解する必要があります。したがって、Kubernetes を使用する前に、次の点を事前に準備してください。

1. アプリケーションをコンテナ化する

[[221972]]

まず第一に、アプリケーションはコンテナ化されている必要があります。これは、ベース OS イメージをセットアップし、アプリケーションを 1 つのファイル (通常は Dockerfile) にパッケージ化してインストールする手順を定義したことを意味します。

上記のプロセスを実行し、アプリケーションを構成するために必要な環境変数 (アプリケーションで使用されるデータベースの URL、ユーザー名、パスワードなど) を定義することが重要です。これらにより、コンテナ イメージが Kubernetes で使用できるようになります。

また、アプリケーションに必要なさまざまなランタイム依存関係に注意し、それらのコンテナ バージョンの使用方法を理解する必要があります。

2. ストレージの仕組みを理解する

コンテナは通常、アプリケーションの実行に必要なコードのみを保持するように設計されています。コンテナの解体と起動のプロセス (複数のコンテナを扱う場合に一般的) では、コンテナのファイル システムに保存されているすべてのデータが破壊されるため、永続的なデータは別の場所に保存する必要があります。

Kubernetes について考えるときは、コンテナ ストレージがどのように動作するように設定されているか、データのバックアップ、コンテナ間でのデータの移動、コンテナ外部からのデータへのアクセスなどの問題をどのように処理するかを理解する必要があります。

Kubernetes は、自動リソースプロビジョニングなどの機能を通じてストレージ管理の実装を容易にします。この機能により、ストレージプロバイダー (AWS EBS など) は新しいボリュームを作成し、新しいコンテナの作成中に自動的にマウントすることもできます。

3. ネットワークの仕組みを理解する

ネットワークの構築方法は、Kubernetes の使用に大きな影響を与える可能性があります。初心者にとって、一部の情報を隠し、サービス間の通信を維持しながら、特定のシステムを外部のインターネット アプリケーション (データベースなど) に公開する方法を理解することは非常に重要です。経験に基づいて、負荷分散を統合する方法や、各顧客のインスタンスのホスト名を定義する方法など、より複雑な背景知識を習得する必要があります。これらすべてにより、Kubernetes の使用がはるかに簡単になります。

2. Kubernetes は現在直面している問題を解決できますか?

アプリケーションのデプロイにコンテナを使用していない場合は、Kubernetes はおそらく必要ありません。 Kubernetes が解決する問題は、一般的に、コンテナベースのアーキテクチャを試用して拡張するときに遭遇する問題だからです。

ここでは、コンテナのスケーリング問題を解決する際に Kubernetes が優れていると思われる領域をいくつか紹介します。

1. リソースを拡大する

本質的に、Kubernetes は、コンテナ ワークロードで使用できるコンピューティング リソースを提供するノードのクラスターです。このクラスター アーキテクチャにより、さまざまなリソースの拡張や削減が非常に簡単になります。クラスター内の特定のノードを追加または削除するだけで、Kubernetes はこれらのリソースを自動的に利用したり、ワークロード上の既存のリソースを再配布したりします。

この機能は、私が直面していた困難な問題を解決しました。当初はサーバーが 1 台しかなかったため、スケーリングを継続するには (面倒な手動プロセスになります)、CLI (コマンド ライン インターフェイス) でコマンドを 1 つだけ使用して、アーキテクチャを自由にスケーリングすることができました。

2. 大量の更新を実行する

Kubernetes のもう 1 つの機能は、すべてのコンテナの更新問題を解決できることです。以前は、関連する各コンテナを選択し、新しいイメージ タグを使用して再作成するためのシェル スクリプトをいくつか記述する必要がありました。全体のプロセスに 1 時間以上かかっただけでなく、更新が成功したかどうかを確認できませんでした。これで、Kubernetes を使用すると、次のような 1 つのコマンドで更新を実行できます。

 //アップデート フロントエンドのすべてのポッドを新しいイメージタグに追加 
 $ kubectl ローリングアップデートフロントエンド--image=image:v2  

Kubernetes では、さまざまなコマンドを使用して、任意の基準に基づいて Kubernetes の任意の部分 (ネットワーク、ストレージなどを含む) を更新することもできます。これは、スキーマを変更するために独自のスクリプトを作成する場合に比べて大幅に改善されています。

3. 自己修復機能

自己修復機能はここで最後に言及する必要があるものですが、Kubernetes の最も重要な機能でもあります。 Kubernetes は、ノードが応答しない、コンテナがヘルスチェックに失敗するなどのアーキテクチャの問題を検出すると、規定の手順に従って、操作を再開できるまで対応する部分を再作成します。

これはとても便利です。何らかの理由でクラスターの一部がオフラインになった場合は、対応するワークロードを再分配する必要があり、Kubernetes でサーバー全体を再構築して問題を解決することもできます。

3. アプリケーション アーキテクチャを変更する必要はありますか?

[[221973]]
場合によっては、アプリケーションに Kubernetes を導入することは、四角い釘を丸い穴に打ち込むようなものです。

私のアプリケーションはもともと、複数のコンテナをデプロイしてマルチインスタンス プラットフォームを作成するために構築されていたため、Kubernetes に移行したときに多くの変更は加えませんでした。

以下では、自分のワークロードを Kubernetes に移行する際に学んだことの一部を紹介します。

1. アプリケーションの起動時間は重要

新しいデプロイメントを作成する場合、エンドユーザーが使用できるようになるまで、アプリケーションが起動するまで待つ必要があります。これにより、エンドユーザーがボタンを押した瞬間にデプロイメント プロセスで新しいインスタンスが作成される場合、またはすべての顧客インスタンスの更新を実行する場合に問題が発生し、一部のポッドを再生成する必要が生じます。

したがって、Kubernetes に移行する場合は、エンドユーザーが製品を使用する際にエクスペリエンスが低下しないように、コード ベースにいくつかの変更を加えて起動プロセスを効率化する必要がある場合があります。

2. マルチテナントアーキテクチャの調整が難しい

マルチテナント アーキテクチャとは、パーティション化されたテナント環境内のすべてのエンド ユーザーを管理するアプリケーションのインスタンスが 1 つあり、通常はすべてのユーザーと 1 つのデータベースを共有することを意味します。

アプリケーションがクラスター化された方法 (複数のサーバーを 1 つのインスタンスに結合する方法) で構築されていない場合は、Kubernetes を使用しないでください。

Kubernetes を使用する際に通常使用されるアーキテクチャには 2 種類あります。

• マルチインスタンスアーキテクチャ、つまり各ユーザーにアプリケーションのインスタンスが割り当てられる
• 使用リソースをスケールアップおよびスケールダウンするクラスタリング機能を備えたマルチテナントアーキテクチャ

個人的には、実装が簡単なため、クラスター化されたマルチテナント アーキテクチャよりもマルチインスタンス アーキテクチャを好みます。さらに、マルチテナンシーをマルチインスタンス アーキテクチャに移行するのにかかる労力は、マルチインスタンス アーキテクチャにさまざまなクラスター機能を追加する場合よりもはるかに少なくなります。

3. ステートレスアプリケーションへの移行は大規模なプロジェクトです

Kubernetes の重要な機能は、デプロイメント内のポッドの数をスケールアップおよびスケールダウンできることです。ただし、アプリケーションがクラスター化もステートレスもされていない場合は、追加のポッドが適切に構成されず、デプロイメント プロセス中に使用されない可能性があるため、この機能は無駄になります。

ほとんどの場合、Kubernetes でステートレス プロセスを使用するのは、アプリケーションが構成を処理する方法を書き直す必要があるため、労力に見合いません。

アプリケーションをステートレス モードまたはクラスター モードに変換するのに時間をかけたくない場合でも問題ありません。Kubernetes には、ステートフル デプロイメント モードへの切り替えを支援する他の多くの方法が用意されています。もちろん、これらの方法にも独自の問題がありますが、この記事では詳しくは説明しません。

4. Kubernetes を導入すべきでしょうか?

Kubernetes への移行を検討する際には、それが本当に現在のシステムに適しているかどうかを検討する必要があります。ほとんどの初期段階のスタートアップにとって、Kubernetes は必要ないかもしれません。また、成熟した企業の中には、すでに他のテクノロジーに多額の投資を行っているところもあり、移行は現実的ではない場合もあります。

ここで、Kubernetes への移行に最も適しているのは、既存の最小限の実行中のクラウド インフラストラクチャからより安定した状態に移行し、コンテナーを使用して実稼働ワークロードを「強化」したいと考えているスタートアップ企業であると考えます。これは実際に私が経験したプロセスです。とはいえ、不十分なリソース管理とサーバーの過負荷による定期的な停止から Kubernetes の使用と移行までの全プロセスを個人的に経験しました。今日、私はインフラについてもう心配していません。

元のタイトル: Kubernetes が SaaS に適しているかどうかを知る方法、著者: Ben Sears

[51CTOによる翻訳。パートナーサイトに転載する場合は、元の翻訳者と出典を51CTO.comとして明記してください。