Google Kubernetes Engine からの Google Cloud Platform サービスの使用

このドキュメントでは、Google Kubernetes Engine(GKE)から Google Cloud Platform(GCP)サービスを使用する方法について説明します。GKE で実行されるアプリケーションから Cloud Storage や Cloud SQL などの GCP サービスを使用する場合は、使用するサービスの環境を構成する必要があります。このドキュメントでは、一般的なアーキテクチャ パターンとその関連タスクについて説明し、構成例について説明するドキュメントへのリンクを提供します。

目標

  • GCP サービスを使用するためのサービス アカウントと秘密鍵を構成します。
  • Cloud SQL データベースを使用するように Cloud SQL Proxy Docker イメージを構成します。
  • Compute Engine の VM 上で動作するカスタム サービスを使用するように、内部負荷分散を構成します。
  • 固定 IP アドレスを必要とする外部サービスを使用するように、NAT ゲートウェイを構成します。
  • Stackdriver Logging を使用してアプリケーション ログを記録します。

一般的なタスクについて

次の図は、GKE から他のサービスを使用する場合の一般的なアーキテクチャ パターンを示しています。

GKE から GCP サービスを使用するための一般的なアーキテクチャ パターンの図

これらのアーキテクチャを構成するタスクは次のとおりです。

  • Cloud API を通じて Cloud Storage などの GCP サービスを使用するには、サービス アカウントに適切な役割を割り当て、Kubernetes の secret オブジェクトを使用して関連付けられる秘密鍵をアプリに指定します。
  • Cloud SQL を使用するには、サービス アカウントに適切な役割を割り当て、サイドカー ポッドパターンを使用して Cloud SQL Proxy をポッドに追加します。
  • Compute Engine VM 上で実行されるカスタム サービスをスケーラブルな方法で使用するには、内部負荷分散を構成します。
  • 固定 IP アドレスを必要とする外部サービスを使用するには、NAT ゲートウェイを構成します。
  • Logging でアプリケーション ログを記録するには、アプリから標準出力(stdout)と標準エラー(stderr)にログメッセージが書き込まれるようにします。

後続のセクションには、構成手順へのリンクがあります。

Cloud API を通じた GCP サービスの使用

サービス アカウントと秘密鍵を使用すると、Cloud API を通じて GCP サービスを使用できます。Kubernetes には、次の図に示すように、認証情報をクラスター内に格納してアプリケーション ポッドに追加する secret リソースタイプがあります。

複数のポッドがアクセスする Kubernetes "secret" オブジェクトの秘密鍵を示す図

GKE で実行されるアプリケーションから Cloud Pub/Sub を使用する方法を示す例については、サービス アカウントを使用した Cloud Platform への認証をご覧ください。Cloud Storage、BigQuery、Cloud Datastore、Cloud Spanner などの他の GCP サービスについても同じ手順を適用できます。ただし、サービス アカウントとサービスに適切な役割を選択する必要があります。また、各サービスに固有の手順の実行が必要な場合もあります。

このアプローチに対する例外は Cloud SQL です。Cloud SQL がデータベースに安全にアクセスするには Cloud SQL Proxy クライアントが必要なため、このサービスには別のアプローチが必要です。これについては次のセクションで説明します。

Cloud SQL Proxy を利用する Cloud SQL の使用

GKE で実行されるアプリケーションから Cloud SQL インスタンスにアクセスするには、Cloud SQL Proxy Docker イメージを使用します。このイメージを使用するアプリケーション ポッドに追加して、同じポッド内で Cloud SQL Proxy クライアントをアプリケーションが使用できるようにします。Cloud SQL Proxy クライアントは、次の図に示すように、アプリケーションと Cloud SQL インスタンス間でデータを安全に転送します。

コンテナ内でアプリケーションが Cloud SQL Proxy と通信し、次に Cloud SQL Proxy が安全な接続を使用して Cloud SQL と通信する例を示す図

Cloud SQL Proxy イメージをアプリケーション ポッドに追加する方法については、Cloud SQL: GKE からの接続をご覧ください。

内部負荷分散を介した外部サービスの使用

GKE で実行されるアプリケーションから外部サービスにアクセスするには、内部または外部のネームサービスを使用して、アプリケーションがサービス エンドポイントを検出できるようにします。ネームサービスを構成する 3 つの方法の説明については、クラスタ内から外部サービスへの接続をご覧ください。

外部サービスが Compute Engine インスタンスで実行されている場合は、内部負荷分散を使用した外部サービスの冗長化やスケーラビリティが必要な場合があります。次の図はこの方法を示しています。

コンテナ内アプリケーションが Cloud Load Balancing と通信し、Cloud Load Balancing が、各種サービスを実行する Compute Engine の複数のインスタンスと通信する例を示す図

Compute Engine インスタンスを実行するバックエンド サービスで内部負荷分散を設定する方法については、内部負荷分散の設定をご覧ください。

NAT ゲートウェイを介した外部サービスの使用

アプリケーション ポッドをホストする VM ノードは、GKE で実行されるアプリケーションから下りパケットを送信します。VM ノードには下りパケットのソース IP アドレスとして使用されるエフェメラル IP アドレスがあります。このため、アプリケーションからのソース IP アドレスは、パケットを送信する VM ノードごとに変化する場合があります。その結果、パケットが同じアプリケーションから送信されていても、外部サービスでは複数の異なるソース IP アドレスからパケットを受信します。通常の状況では、これは特に問題とはなりません。しかし、一部の外部サービスは単一ソースからのパケットのみを受け入れるように構成されているため、固定 IP アドレスからパケットを送信することが必要になる場合もあります。

このシナリオでは、NAT ゲートウェイとして機能する Compute Engine インスタンスを使用できます。NAT ゲートウェイにカスタム ルーティング ルールを作成することにより、次の図に示すように、固定 IP アドレスを使用して外部サービスにパケットを送信できます。

カスタム ルーティングを使用して外部サービスの手前にある NAT ゲートウェイと通信する GKE を示す図

詳細については、GKE での NAT ゲートウェイの使用、および高可用性かつ高帯域幅の NAT ゲートウェイの構築をご覧ください。これらの記事では、NAT ゲートウェイ インスタンスのデプロイとカスタム ルーティング ルールの作成方法を説明しています。

VM ノードにプライベート IP アドレスしかないプライベート クラスタを使用する場合にも、同じアーキテクチャを適用できます。その場合、NAT ゲートウェイはプライベート サブネットからパケットを受信し、単一のパブリック IP アドレスを使用してそれらのパケットを外部サービスに転送します。

Stackdriver Logging へのアプリケーション ログの送信

Stackdriver Logging はデフォルトで有効化されており、GKE でコンテナログとシステムログを自動的に収集して処理し、専用の永続データストアに保存できます。GKE は、次の図に示すように、ポッド内の stdout および stderr からログを読み取るロギング エージェントを各ノードにデプロイします。

コンテンツがロギング エージェント、ひいては Logging に書き込まれる "stdout" および "stderr" への書き込みを行う複数のアプリケーション ポッドを示す図

したがって、アプリケーションで stdoutstderr にログメッセージが書き込まれるようにする必要があります。GKE で実行されるアプリケーションからのログの収集、クエリ、および分析に Logging を使用する方法については、GKE - ロギングをご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...