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

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

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

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

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

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

料金

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

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

始める前に

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

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

GKE クラスタを設定する

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

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

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

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

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

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

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

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

    gcloud config set project PROJECT_ID

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

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

    gcloud container clusters create CLUSTER_NAME \
    --zone=ZONE \
    --num-nodes=2

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

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

    • ZONE: クラスタを作成するゾーン（us-central1-a や europe-west1-b など）。使用可能なゾーンの一覧については、リージョンとゾーンをご覧ください。

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

    gcloud container clusters get-credentials CLUSTER_NAME \
    --zone=ZONE

    このコマンドは、デフォルトで ~/.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 ではなくサービス名を使用するようにアプリのコードを更新しました。この更新により、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 を分散して、単一のノードに過負荷がかかるリスクを軽減します。この分散により、クラスタはコンピューティング リソースとメモリリソースを効率的に使用できます。

デプロイを確認する

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 を使用すると、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 for the home モジュールの 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
    --zone=ZONE

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

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

  • ZONE: クラスタが作成されたゾーン（us-central1-a など）。

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

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

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

gcloud container clusters list

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

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

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

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

シリーズの概要

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

  1. モノリスを理解する

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

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

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

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

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

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

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

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

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

次のステップ

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