このチュートリアルでは、Eventarc を使用して Pub/Sub メッセージ イベントを受信する限定公開の Google Kubernetes Engine(GKE)クラスタに、限定公開の HTTP エンドポイントを作成する方法について説明します。このイベントの宛先の詳細については、VPC ネットワークの内部 HTTP エンドポイントにイベントを転送するをご覧ください。
限定公開 GKE クラスタは、Virtual Private Cloud(VPC)ネイティブ クラスタの一種です。このクラスタでは、ノードには内部 IP アドレスのみが割り当てられます。つまり、デフォルトではノードと Pod はインターネットから隔離されています。コントロール プレーンへのクライアント アクセスは、禁止、制限、または無制限に設定できます。既存の非限定公開クラスタを限定公開クラスタに変換することはできません。詳細については、限定公開クラスタについてをご覧ください。
ターミナルまたは Cloud Shell で Google Cloud CLI を使用して、次のコマンドを実行できます。
プロキシ専用サブネットを作成する
この設定を禁止する組織のポリシーを作成しない限り、新しいプロジェクトは、各リージョンに 1 つのサブネットワーク(サブネット)を持つデフォルト ネットワーク(自動モードの VPC ネットワーク)が設定された状態で開始されます。各 VPC ネットワークは、サブネットと呼ばれる 1 つ以上の IP アドレス範囲で構成されています。サブネットはリージョン リソースであり、IP アドレス範囲が関連付けられています。
gcloud compute networks subnets create
コマンドを使用して、デフォルト ネットワークにプロキシ専用サブネットを作成します。gcloud compute networks subnets create proxy-only-subnet \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=us-central1 \ --network=default \ --range=10.10.10.0/24
purpose=REGIONAL_MANAGED_PROXY
と指定されたサブネットは Envoy ベースのロードバランサ用に予約され、range
は 64 個以上の IP アドレスを提供する必要があることに注意してください。プロキシ専用サブネットの範囲に一致し、TCP ポート 8080 のトラフィックを許可するファイアウォール ルールを作成します。
gcloud compute firewall-rules create allow-proxy-connection \ --allow tcp:8080 \ --source-ranges 10.10.10.0/24 \ --network=default
限定公開 GKE クラスタを作成する
gcloud container clusters create-auto
コマンドを使用して、限定公開ノードがあり、パブリック エンドポイントへのクライアント アクセス権のない Autopilot モードの限定公開 GKE クラスタを作成します。
次の例では、private-cluster
という名前の限定公開 GKE クラスタと、my-subnet
という名前のサブネットを作成します。
gcloud container clusters create-auto private-cluster \
--create-subnetwork name=my-subnet \
--enable-master-authorized-networks \
--enable-private-nodes \
--enable-private-endpoint \
--region=us-central1
次の点にご注意ください。
--enable-master-authorized-networks
を指定すると、パブリック エンドポイントへのアクセスが、承認された IP アドレス範囲に制限されます。--enable-private-nodes
は、クラスタのノードに外部 IP アドレスがないことを示します。--enable-private-endpoint
は、クラスタがコントロール プレーン API エンドポイントの内部 IP アドレスを使用して管理されていることを示します。
クラスタの作成が完了するまでに数分かかることがあります。クラスタが作成されると、クラスタのステータスが RUNNING
であることが示されます。
指定したサブネットで VM インスタンスを作成する
Compute Engine VM インスタンスは、Google のインフラストラクチャでホストされる仮想マシンです。Compute Engine インスタンス、VM インスタンス、VM という用語は同義語であり、同じ意味で使用されています。VM インスタンスには、GKE クラスタ、App Engine フレキシブル環境インスタンス、Compute Engine VM 上に構築された他の Google Cloud プロダクトが含まれます。
gcloud compute instances create
コマンドを使用して、以前に作成したサブネットに Compute Engine VM インスタンスを作成します。サービス アカウントを接続し、VM のアクセス スコープを cloud-platform
に設定します。
gcloud compute instances create my-vm \
--service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com \
--scopes=https://www.googleapis.com/auth/cloud-platform \
--zone=us-central1-a \
--subnet=my-subnet
詳しくは、VM インスタンスの作成と開始をご覧ください。
VM にイベント レシーバーをデプロイする
ビルド済みのイメージ us-docker.pkg.dev/cloudrun/container/hello
を使用して、ポート 80 でリッスンし、イベントを受信してログに記録するサービスを VM にデプロイします。
次のコマンドを実行して、VM インスタンスへの SSH 接続を確立します。
gcloud compute ssh my-vm --project=PROJECT_ID --zone=us-central1-a
SSH サーバーへの接続が確立されたら、VM インスタンスで残りのコマンドを実行します。
VM インスタンスから、
get-credentials
コマンドを使用して、作成したクラスタでkubectl
が動作するようにします。gcloud container clusters get-credentials private-cluster \ --region=us-central1 \ --internal-ip
Kubernetes コマンド
kubectl create deployment
を使用して、アプリケーションをクラスタにデプロイします。kubectl create deployment hello-app \ --image=us-docker.pkg.dev/cloudrun/container/hello
これにより、
hello-app
という名前の Deployment が作成されます。この Deployment の Pod がhello
コンテナ イメージを実行します。アプリケーションをデプロイしたら、Kubernetes Service を作成して、アプリケーションをトラフィックに公開できます。次の
kubectl expose
コマンドを実行します。kubectl expose deployment hello-app \ --type ClusterIP \ --port 80 \ --target-port 8080
出力に
service/hello-app exposed
が表示されます。次のようなメッセージは無視してかまいません。
E0418 14:15:33.970933 1129 memcache.go:287] couldn't get resource list for metrics.k8s.io/v1beta1: the server is currently unable to handle the request
Kubernetes トラフィック ルーティングを構成する
Gateway リソースは、Kubernetes のトラフィックをルーティングするデータプレーンを表します。Gateway は、派生元の GatewayClass に応じて、さまざまなロード バランシングとルーティングを表すことができます。詳細については、Gateway のデプロイをご覧ください。HTTPRoute
マニフェストをデプロイしてルートを作成し、アプリケーション バックエンドにトラフィックを送信します。
クラスタに Gateway をデプロイします。
kubectl apply -f - <<EOF kind: Gateway apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: internal-http spec: gatewayClassName: gke-l7-rilb listeners: - name: http protocol: HTTP port: 80 EOF
次の点にご注意ください。
gatewayClassName: gke-l7-rilb
には、このゲートウェイの派生元となる GatewayClass を指定します。gke-l7-rilb
は、内部アプリケーション ロードバランサに対応しています。port: 80
は、HTTP トラフィックをリッスンするためにポート 80 のみを公開することを指定します。
Gateway が正しくデプロイされたことを確認します。すべてのリソースがデプロイされるまで数分かかる場合があります。
kubectl describe gateways.gateway.networking.k8s.io internal-http
出力は次のようになります。
Name: internal-http Namespace: default ... API Version: gateway.networking.k8s.io/v1beta1 Kind: Gateway ... Spec: Gateway Class Name: gke-l7-rilb Listeners: Allowed Routes: Namespaces: From: Same Name: http Port: 80 Protocol: HTTP Status: Addresses: Type: IPAddress Value: 10.36.172.5 ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal ADD 80s sc-gateway-controller default/internal-http Normal UPDATE 20s (x3 over 80s) sc-gateway-controller default/internal-http Normal SYNC 20s sc-gateway-controller SYNC on default/internal-http was a success
HTTPRoute
マニフェストをデプロイして、HTTP トラフィックをポート 80 のhello-app
サービスに転送します。kubectl apply -f - <<EOF kind: HTTPRoute apiVersion: gateway.networking.k8s.io/v1beta1 metadata: name: hello-app-route spec: parentRefs: - kind: Gateway name: internal-http rules: - backendRefs: - name: hello-app port: 80 EOF
ネットワーク アタッチメントを作成する
ネットワーク アタッチメントは、プロデューサー VPC ネットワークが Private Service Connect インターフェースを介してコンシューマー VPC ネットワークへの接続を開始できるようにするためのリソースです。
イベントを公開するために、Eventarc はネットワーク アタッチメントを使用して、VPC ネットワークでホストされている内部 HTTP エンドポイントとの接続を確立します。
ネットワーク アタッチメントを参照する Private Service Connect インターフェースからの接続を自動的に受け入れるネットワーク アタッチメントを作成できます。HTTP 宛先サービスを含むネットワークとリージョンにネットワーク アタッチメントを作成します。
gcloud compute network-attachments create my-network-attachment \ --region=us-central1 \ --subnets=my-subnet\ --connection-preference=ACCEPT_AUTOMATIC
詳細については、ネットワーク アタッチメントについてをご覧ください。
Eventarc トリガーを作成する
新しい Pub/Sub トピックを作成し、メッセージが Pub/Sub トピックにパブリッシュされたときに、VM にデプロイされたイベント レシーバーにイベントを転送する Eventarc トリガーを作成します。
ゲートウェイのアドレスを取得します。
GATEWAY_ADDRESS=$(kubectl get gateways.gateway.networking.k8s.io internal-http -o=jsonpath="{.status.addresses[0].value}")
トリガーを作成します。
gcloud eventarc triggers create my-trigger \ --location=us-central1 \ --destination-http-endpoint-uri="http://$GATEWAY_ADDRESS:80/" \ --network-attachment="projects/PROJECT_ID/regions/us-central1/networkAttachments/my-network-attachment" \ --event-filters="type=google.cloud.pubsub.topic.v1.messagePublished" \ --service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com
PROJECT_NUMBER
は、使用する Google Cloudプロジェクト番号に置き換えます。プロジェクト番号は、 Google Cloud コンソールの [ようこそ] ページで確認できます。また、次のコマンドでも確認できます。gcloud projects describe PROJECT_ID --format='value(projectNumber)'
トリガーの構成の詳細については、VPC ネットワークの内部 HTTP エンドポイントにイベントを転送するをご覧ください。
Pub/Sub トピック イベントを生成して表示する
Pub/Sub トピックにメッセージを公開することでイベントを生成できます。
Pub/Sub トピックを検索して、環境変数として設定します。
export MY_TOPIC=$(gcloud eventarc triggers describe my-trigger \ --location=us-central1 \ --format='value(transport.pubsub.topic)')
Pub/Sub トピックにメッセージをパブリッシュしてイベントを生成します。
gcloud pubsub topics publish $MY_TOPIC --message "Hello World"
Eventarc トリガーは、限定公開 GKE クラスタの内部 HTTP エンドポイントにイベントを転送します。
アプリケーション Pod ログをチェックし、イベント配信を確認します。
POD_NAME=$(kubectl get pod --selector app=hello-app --output=name) kubectl logs $POD_NAME
イベントの本文は次のようになります。
2024/04/18 20:31:43 Hello from Cloud Run! The container started successfully and is listening for HTTP requests on $PORT {"severity":"INFO","eventType":"google.cloud.pubsub.topic.v1.messagePublished","message":"Received event of type google.cloud.pubsub.topic.v1.messagePublished. Event data: Hello World","event":{"specversion":"1.0","id":"10935738681111260","source":"//pubsub.googleapis.com/projects/my-project/topics/eventarc-us-central1-my-trigger-224","type":"google.cloud.pubsub.topic.v1.messagePublished","datacontenttype":"application/json","time":"2024-04-18T20:40:03Z","data": {"message":{"data":"SGVsbG8gV29ybGQ=","messageId":"10935738681111260","publishTime":"2024-04-18T20:40:03Z"}}}}
これで非公開 GKE クラスタの内部 HTTP エンドポイントにイベント レシーバー サービスが正常にデプロイされ、Eventarc トリガーが作成されて、Pub/Sub からイベントが生成されました。また、トリガーにより、イベントが期待どおりにターゲット エンドポイントにルーティングされたことを確認できました。