学習プログラム: モノリスを GKE アプリに変換する - アプリを GKE クラスタにデプロイする

これは、モノリシック アプリをモジュール化してコンテナ化する方法を学習する学習プログラムの最後のチュートリアルです。

この学習プログラムは、次のチュートリアルで構成されています。

  1. 概要
  2. モノリスを理解する
  3. モノリスをモジュール化する
  4. モジュラー型のアプリをコンテナ化できるように準備する
  5. モジュラー アプリをコンテナ化する
  6. アプリを GKE クラスタにデプロイする（このチュートリアル）

前のチュートリアル モジュラー アプリをコンテナ化するでは、モジュラー型の Cymbal Books アプリをデプロイ用に準備しました。アプリのモジュールをコンテナ化し、結果のコンテナをテストして、コンテナ イメージを Artifact Registry に push しました。

このチュートリアルでは、コンテナ化されたアプリを Google Kubernetes Engine クラスタにデプロイします。この手順で、Cymbal Books アプリを Kubernetes クラスタで実行される、モジュラー型のスケーラブルなシステムに変換する作業が完了します。

費用

このチュートリアルの手順に沿って操作すると、 Trusted Cloud by S3NSアカウントに料金が発生します。費用が発生するのは、GKE を有効にして Cymbal Books サンプルアプリをデプロイしたときです。これらの費用には、料金ページで説明されている GKE のクラスタごとの料金と、Compute Engine VM の実行料金が含まれます。

不要な料金が発生しないように、このチュートリアルの完了後に GKE を無効にするか、プロジェクトを削除してください。

始める前に

このチュートリアルを開始する前に、シリーズの前のチュートリアルを完了していることを確認してください。シリーズ全体の概要と特定のチュートリアルへのリンクについては、学習プログラム: モノリスを GKE アプリに変換する - 概要をご覧ください。

特に、前のチュートリアル（モジュラー アプリをコンテナ化する）の手順を完了している必要があります。

GKE クラスタを設定する

モジュラー型の Cymbal Books アプリをデプロイする前に、まず GKE クラスタを作成する必要があります。このクラスタは、アプリのコンテナが実行されるインフラストラクチャを提供します。

このチュートリアルでは、gcloud CLI を使用してクラスタを作成します。また、Trusted Cloud コンソールの使用も可能です。このコンソールには、GKE クラスタなどの Trusted Cloud by S3NSリソースの作成と管理を行うためのグラフィカル ユーザー インターフェース（GUI）が用意されています。

GKE クラスタを作成して確認する

GKE クラスタは、Kubernetes でコンテナを実行するために必要なコンピューティング リソースを提供します。gcloud CLI を使用してクラスタを作成する手順は次のとおりです。

  1. Trusted Cloud コンソールに移動します。

  2. コンソールで「Cloud Shell をアクティブにする」（Cloud Shell をアクティブにする）ボタンをクリックします。

    コンソールの下部にあるフレーム内で Cloud Shell セッションが開きます。

  3. Google Cloud CLI でデフォルト プロジェクトを設定します。

    gcloud config set project PROJECT_ID

    PROJECT_ID は、前のチュートリアルの Trusted Cloud by S3NS プロジェクトを選択または作成するセクションで作成または選択したプロジェクトのプロジェクト ID に置き換えます。プロジェクト ID は、プロジェクトを Trusted Cloud by S3NSの他のプロジェクトと区別するための一意の文字列です。プロジェクト ID を確認するには、プロジェクト セレクタに移動します。このページで、各 Trusted Cloud by S3NSプロジェクトのプロジェクト ID を確認できます。

  4. GKE クラスタを作成します。

    gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --num-nodes=2

    次のように置き換えます。

    • CLUSTER_NAME: クラスタの名前（cymbal-cluster など）。

    • CONTROL_PLANE_LOCATION: クラスタのコントロール プレーンの Compute Engine のロケーション。リージョン クラスタの場合はリージョン、ゾーンクラスタの場合はゾーン（us-central1 や europe-west1-b など）を指定します。

  5. kubectl CLI がクラスタに接続できるように、クラスタの認証情報を取得します。

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    このコマンドは、デフォルトで ~/.kube/config に保存されている Kubernetes 構成ファイルを更新します。この構成ファイルには、kubectl が GKE クラスタとやり取りするために必要な認証情報が含まれています。

  6. クラスタノードの一覧を取得して、kubectl がクラスタに接続されていることを確認します。

    kubectl get nodes

    設定が成功すると、このコマンドは GKE クラスタ内のノードの一覧を表示します。--num-nodes=2 でクラスタを作成したため、次のように 2 つのノードに関する情報が表示されます。

    NAME                                         STATUS    ROLES    AGE    VERSION
gke-nov18-default-pool-6a8f9caf-bryg   Ready     <none>   30s    v1.30.8-gke.1128000
gke-nov18-default-pool-6a8f9caf-ut0i   Ready     <none>   30s    v1.30.8-gke.1128000

    この例では、両方のノードが Ready 状態です。この状態は、GKE クラスタがコンテナ化されたワークロードをホストする準備ができていることを意味します。

アプリをデプロイする

GKE クラスタを作成したので、Cymbal Books アプリをデプロイできます。アプリをクラスタにデプロイするには、Kubernetes マニフェストをクラスタに適用します。

Kubernetes マニフェストを適用する

Cloud Shell で次のコマンドを実行して、アプリを GKE クラスタにデプロイします。

  1. コンテナ化されたアプリケーションのルート ディレクトリに移動します。

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/

  2. Kubernetes マニフェストを適用します。

    kubectl apply -f kubernetes_manifest.yaml

上記のコマンドは、kubernetes-manifest.yaml ファイルで指定されたリソースを作成するように Kubernetes に指示します。これらのリソースには、Service、Deployment、Pod などがあります。

Service は、コンテナ化用にモジュラー アプリを準備するチュートリアルのモジュラー コードを変更するセクションで初めて登場しました。このチュートリアルでは、localhost ではなく Service 名を使用するようにアプリのコードを更新しました。この更新により、Kubernetes はモジュール間でリクエストをルーティングできるようになり、モジュールがクラスタ内で相互に通信できるようになります。マニフェストを適用すると、Kubernetes によってクラスタ内にサービスが作成されます。

Deployment は、クラスタ内のノードに分散された Pod の複数のレプリカを実行できる Kubernetes API オブジェクトです。次のセクションでは、Pod について説明します。

Kubernetes Pod とは

前のチュートリアルでは、Cymbal Books アプリの各モジュールのコンテナ イメージを作成しました。たとえば、home_app モジュールと book_details_app モジュールに基づいてコンテナ イメージを作成しました。

kubectl apply コマンドを使用して Kubernetes マニフェストをデプロイすると、Kubernetes は Artifact Registry からクラスタにコンテナ イメージを pull します。クラスタでは、コンテナ イメージがコンテナになり、コンテナは Pod 内で実行されます。

Pod は、コンテナが実行される分離された環境であり、次のタスクを実行します。

  • CPU とメモリを割り当てる: Pod は、コンテナの動作に必要なリソースを提供します。
  • ネットワーキングを提供する: 各 Pod に独自の IP アドレスがあります。これにより、Pod が他の Pod と通信できるようになります。

Pod はノード（クラスタのコンピューティング能力を提供するマシン）で実行されます。Kubernetes は Pod をノードに自動的に割り当て、クラスタのノード全体に Pod を分散し、単一ノードが過負荷状態になるリスクを軽減します。この分散により、クラスタはコンピューティング リソースとメモリリソースを効率的に使用できます。

Deployment を確認する

kubectl apply コマンドで Kubernetes マニフェストを適用したら、アプリがクラスタに正常にデプロイされたことを確認します。Deployment を確認するには、Pod と Service が正しく実行されていることを確認します。

Pod を確認する

クラスタ内の Pod を表示するには、次のコマンドを実行します。

kubectl get pods

このコマンドは、Pod とその現在のステータスを一覧表示します。STATUS 列で、すべての Pod が「Running」とマークされていることを確認します。これは、Pod が正常に実行され、リクエストを処理する準備ができていることを示します。想定される出力は次のようになります。

NAME                             READY   STATUS    RESTARTS   AGE
home-app-67d59c6b6d-abcde        1/1     Running   0          30s
book-details-app-6d8bcbc58f-xyz  1/1     Running   0          30s
book-reviews-app-75db4c4d7f-def  1/1     Running   0          30s
images-app-7f8c75c79c-ghi        1/1     Running   0          30s

Pod のステータスは、作成中およびコンテナの起動中は「Pending」と表示されます。Pod が Pending の状態のままになっている時間が長い場合、その Pod が正常な Running 状態になるために十分なリソースがクラスタにない可能性があります。Pod のステータスが CrashLoopBackOff の場合、コンテナに問題がある可能性があります。トラブルシューティングの手順については、このチュートリアルの後半で説明します。

Service を確認する

Service を使用すると、Pod 間の通信が可能になり、外部クライアント（ユーザー、自動スクリプト、モニタリング ツールなど）がアプリにアクセスできるようになります。クラスタ内の Service を表示するには、次のコマンドを実行します。

kubectl get services

このコマンドの出力は次のようになります。

NAME               TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)        AGE
home-app-service   LoadBalancer   10.12.3.4       35.185.1.2        80:30837/TCP   30s
details-service    ClusterIP      10.12.3.5       <none>            80/TCP         30s
reviews-service    ClusterIP      10.12.3.6       <none>            80/TCP         30s
images-service     LoadBalancer   10.12.3.7       34.125.6.3        80:32014/TCP   30s

出力で確認すべきキーフィールドは次のとおりです。

  • TYPE: このフィールドは、Service の公開方法を示します。LoadBalancer タイプの Service は、アプリへの外部アクセスを提供します。
  • EXTERNAL-IP: LoadBalancer タイプの Service の場合、EXTERNAL-IP フィールドには、アプリにアクセスするためにユーザーがウェブブラウザに入力したパブリック IP アドレスが表示されます。ClusterIP タイプの Service の場合、ClusterIP Service はクラスタ内でのみアクセスできるため、このフィールドは空になります。

Deployment をテストする

Cymbal Books アプリを GKE クラスタにデプロイしたら、アプリにアクセスできることと、コンテナが相互に通信できることを確認します。

アプリにアクセスする

次の手順で、アプリにアクセスできることを確認します。

  1. home-app-service の外部 IP アドレスを取得します。

    kubectl get services

    出力で **EXTERNAL-IP** 列を探し、home-app-service に関連付けられている IP アドレスをメモします。

  2. ウェブブラウザを開いて、次の URL を入力します。

    http://EXTERNAL-IP

    EXTERNAL-IP は、前の手順でコピーした IP アドレスに置き換えます。

  3. Cymbal Books アプリのホームページが正しく読み込まれることを確認します。

サービス間の通信を確認する

Cymbal Books アプリのコンテナは、情報を交換するためにサービスに依存しています。次の手順で、コンテナが効果的に通信できることを確認します。

  1. 前述のように、home-app-service の外部 IP アドレスを取得します。

  2. アプリのインターフェースを使用して、コンテナ間のインタラクションをテストします。そのため、アプリのインターフェースで利用可能なすべてのリンクをクリックして、次の機能が動作することを確認します。

    • 書籍の表紙画像を確認する: ホームページと書籍の詳細ページの両方で書籍の表紙画像が正しく読み込まれることを確認します。その場合、home_app コンテナと book_details_app コンテナは images_app コンテナと正常に通信しています。
    • 書籍の詳細を表示する: ホームページから書籍の詳細ページに移動します。書籍の詳細が表示された場合は、home_app コンテナが book_details_app と正しく通信しています。
    • 書籍のレビューを表示する: 書籍のレビューのリンクをクリックして、home_app コンテナが book_reviews_app コンテナと通信できることを確認します。

アプリが GKE クラスタで実行されるようになりました。

これで完了です。ここでは、モノリシック アプリを、ライブ GKE クラスタで実行されるモジュラー化およびコンテナ化されたシステムに変換する方法を説明しました。この過程で、密結合されたコードを独立したモジュールに分割する方法、コンテナ イメージをビルドしてリポジトリに push する方法、Kubernetes マニフェストを定義する方法、レジストリから GKE にアプリをデプロイする方法を学びました。これは大きな成果であり、チームがクラウド向けにアプリケーションをモダナイズするために実際に行う操作を反映しています。

トラブルシューティング

アプリが応答しない場合や、コンテナが通信できない場合は、次のトラブルシューティング手順で一般的な問題を診断し、解決します。

Pod のステータスを確認する

まず、クラスタ内のすべての Pod を一覧表示して、それらが想定どおりに実行されているかどうかを確認します。

kubectl get pods

出力を確認して、各 Pod が Running 状態であることを確認します。実行されていない Pod がある場合は、その名前をメモして、さらに詳しく調べます。

Pod ログを検査する

Pod がリクエストを正しく処理していない場合は、ログを調べてエラー メッセージがないか確認します。

kubectl logs POD_NAME

POD_NAME は、検査する Pod の名前に置き換えます。 このコマンドは、起動時の問題やランタイム エラーの特定に役立ちます。

詳細情報を確認するために Pod の説明を取得する

Pod が 5 分以上 Running 以外の状態（Pending、ContainerCreating、CrashLoopBackOff など）のままになっている場合は、次のコマンドを使用して、Pod のステータスとイベントに関する詳細情報を確認できます。

kubectl describe pod POD_NAME

POD_NAME は、詳細情報を取得する Pod の名前に置き換えます。

出力の Events セクションは、リソース制約またはイメージの pull に関する問題が原因で Pod が正しく起動していないことを示している可能性があります。

Service 構成を確認する

特に、外部 IP アドレスでホーム モジュールを公開する Service など、Service が正しく設定されていることを確認します。次のコマンドを使用して、Service を一覧表示します。

kubectl get services

ホーム モジュールの Service で、EXTERNAL-IP アドレスが Pending としてリストされている場合は、次のコマンドを実行します。

kubectl describe service SERVICE_NAME

SERVICE_NAME は、ホーム モジュールの Service の名前に置き換えます。

このコマンドは、Service 構成の詳細を提供し、外部 IP アドレスの割り当ての遅延などの構成上の問題を特定する際に役立ちます。

クラスタ イベントを確認する

クラスタ イベントを調べると、問題がクラスタの複数のコンポーネントに影響しているかどうかを判断できます。

kubectl get events

このコマンドを使用すると、より広範なリソースまたはネットワークの問題がデプロイに影響しているかどうかを判断できます。

リソースのクリーンアップ

GKE クラスタの実行には費用が発生します。このチュートリアルを完了したら、追加料金が発生しないようにリソースをクリーンアップします。クラスタと、必要に応じてプロジェクト全体を削除する手順は次のとおりです。

GKE クラスタを削除する

GKE クラスタを削除するには、次のコマンドを使用します。

gcloud container clusters delete CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION

次のように置き換えます。

  • CLUSTER_NAME: 作成したクラスタの名前（cymbal-cluster など）。

  • CONTROL_PLANE_LOCATION: クラスタのコントロール プレーンの Compute Engine のロケーション。リージョン クラスタの場合はリージョン、ゾーンクラスタの場合はゾーンを指定します。

メッセージが表示されたら、削除を確定します。

クラスタが削除されたことを確認する

クラスタが削除されたことを確認するには、次のコマンドを実行します。

gcloud container clusters list

クラスタは出力に表示されなくなります。その場合は、しばらく待ってからもう一度お試しください。

（省略可） Trusted Cloud by S3NS プロジェクトを削除する

このチュートリアル専用の Trusted Cloud by S3NS プロジェクトを作成し、不要になった場合は、 Trusted Cloud by S3NS プロジェクト全体を削除できます。プロジェクトを削除すると、すべてのリソースが削除され、プロジェクトの課金が停止します。

  1. Trusted Cloud コンソールで、[リソースの管理] ページを開きます。
  2. 削除するプロジェクトを選択します。
  3. [プロジェクトを削除] をクリックし、プロンプトに従って確定します。

シリーズの概要

これで完了です。この学習プログラムを修了すると、モノリシック アプリを Kubernetes クラスタで実行されるモジュラー化およびコンテナ化されたアプリに変換する基本的な方法を習得できます。プロセスの概要は次のとおりです。

  1. モノリスを理解する

    • Cymbal Books モノリシック アプリの構造を確認しました。
    • モノリスを実行してエンドポイントをテストするために、ローカル Python 環境を設定しました。
    • モジュール化の準備として、アプリのコードベースを理解しました。

  2. モノリスをモジュール化する

    • モノリシック コードを個別のモジュールに分割する方法を学びました。各モジュールは、書籍の詳細やレビューの表示など、個別の機能を処理します。
    • これらのモジュールが、異なるポートで実行される独立した Flask アプリとして実装されていることを確認しました。
    • モジュール化されたアプリをテストしました。

  3. モジュラー コードをコンテナ化できるように準備する

    • localhost の代わりに Service 名を使用するために、home.py の URL を更新する必要があることを学習しました。
    • Kubernetes マニフェストにより、すでに相互に通信しているアプリのモジュールが Kubernetes クラスタのコンテキスト内で相互に検出できるように Service を定義する方法を学習しました。

  4. モジュラー アプリをコンテナ化する

    • Trusted Cloud by S3NS プロジェクトを設定し、GitHub から Cloud Shell にアプリのクローンを作成しました。
    • Docker を使用して各モジュールのコンテナ イメージをビルドし、コンテナをローカルでテストしました。
    • コンテナ イメージを Artifact Registry に push して、クラスタへのデプロイ用にアプリを準備しました。
    • Artifact Registry のコンテナ イメージ パスを参照するように Kubernetes マニフェストを更新しました。

  5. アプリを GKE クラスタにデプロイする（現在ご覧になっているチュートリアル）。

    • GKE クラスタを作成しました。
    • Artifact Registry から GKE クラスタにコンテナ イメージをデプロイしました。
    • アプリの最終バージョンをテストしました。このバージョンはスケーラブルで、Kubernetes 環境で実行できます。

次のステップ

クラスタの作成方法に関する実践的なトレーニングについては、学習プログラム: スケーラブルなアプリケーションをご覧ください。