Knative serving サービスの Cloud Run への移行

このガイドでは、ワークロードを Cloud Run に移行します。通常、ワークロードを移行するには、Kubernetes ベースの機能を移植してから、既存の各サービスを Cloud Run に再デプロイする必要があります。

Cloud Run への移行の主なメリット

• Knative Serving API 仕様を実装し、コンテナ契約を遵守するフルマネージドのサーバーレス プロダクト。

• Cloud Run の v1 Admin API は、Knative serving でのポータビリティを最大限に高めるように設計されています。

• ユーザー エクスペリエンスは Cloud Run と Knative serving で似ています。

  • gcloud run コマンド グループは、両方のプロダクトで使用されます。
  • ユーザー インターフェースのレイアウトと動作は、Google Cloud コンソールと同様です。

始める前に

Cloud Run では、次の Google Kubernetes Engine 機能はサポートされていません。

• クラスタと Pod の機能（Startup、Liveness と Readiness のプローブ、サービス ディスカバリなど）。
• 構成:
  • ConfigMaps - Secret Manager を使用して ConfigMap を Secret に変換できます。
  • NVIDIA GPU

• アクセス制御:

  • GKE 固有の IAM ロール
  • Workload Identity
  • クラスタ マルチテナンシー

  Cloud Run の IAM を使用すると、リソースへアクセスも同じ方法で制御できます。サービス ID の使用も検討してください。

移行に関する考慮事項

依存関係と要件をすべて移行できるようにするには、プロダクト間の以下の違いを理解する必要があります。

Secret

Cloud Run では、Secret を環境変数またはボリュームとしてマウントできますが、機密情報を含む Secret は Secret Manager に保存する必要があります。

Secret Manager のシークレットと Kubernetes の Secret の重要な違い:

機能	Secret Manager シークレット	Kubernetes Secret
名前に使用できる文字:	[a-zA-Z0-9_-]{1,255}	[a-z0-9-.]{1,253}
バージョニング	Secret はバージョニングされます	サポートなし
Secret ペイロード	単一 []byte	マップ: <string, string>

Secret Manager を使用して、Knative serving サービスの秘密鍵にバージョニングされた Secret を作成する方法を確認してください。

ネットワーキング

既存のネットワーク構成を Cloud Run に移行する際は、次の情報を参考にしてください。

サービス エンドポイント

Knative serving サービスの Kubernetes エンドポイントは Cloud Run ではサポートされていません。Cloud Run の一意のエンドポイントの詳細については、こちらをご覧ください。

ドメイン マッピング

Cloud Run の DomainMapping API は Knative serving と互換性があります。ただし、Cloud Run では、使用可能な Cloud Run のロケーションのサブセットでドメイン マッピングが提供されます。カスタム ドメインには、グローバル HTTP(S) ロードバランサを使用することをおすすめします。

VPC 接続

Cloud Run サービスは VPC の外部に存在します。VPC 内のリソースと通信するには、サーバーレス VPC アクセス コネクタを使用する必要があります。

上り（内向き）制御

Knative serving サービスがプライベート内部ネットワーク用に構成され、内部ロードバランサ（ILB）を使用している場合、Cloud Run サービスを Ingress = Internal に構成できます。サービスを internal に構成すると、VPC 内または他の Cloud Run サービスへのアクセスが制限されます。サービス間通信の詳細を確認してください。

サービスの移行

サービスを移行するには、Knative serving サービスをエクスポートし、エクスポートされた YAML ファイルを編集して、再構成したサービスを Cloud Run にデプロイする必要があります。

注: 最初に Knative serving 用に作成した元の YAML 構成ファイルを取得して使用する場合は、エクスポートと変更の手順をスキップできます。元の YAML 構成ファイルを使用すると、簡単に Cloud Run に直接デプロイし、サービスを作成できます。

1. 次のコマンドを実行して、Knative serving サービスをローカルの YAML ファイルにエクスポートします。

   gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yaml
   

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

   • SERVICE: Knative serving サービスの名前。
   • NAMESPACE: サービスが実行されている Namespace。
   • CLUSTER: サービスが実行されているクラスタの名前。
   • FILENAME: 任意の一意のファイル名。

2. Cloud Run 用にエクスポートされた FILENAME.yaml ファイルを変更します。

   • Kubernetes の Namespace を検索して、Google Cloud プロジェクトの ID に置き換える必要があります。たとえば、namespace:default は namespace:my-unique-id に置き換えます。
   • サポートされていない機能の構成をすべて更新する必要があります。

   • 次のすべての属性とその値を削除する必要があります。

     • metadata.annotations.kubectl.kubernetes.io/last-applied-configuration
     • metadata.managedFields
     • spec.template.spec.containers.readinessProbes
     • spec.template.spec.enableServiceLinks

     たとえば、spec: > template: > spec: > containers: の属性から次の構成を削除する必要があります。

     ...
      readinessProbe:
        successThreshold: 1
        tcpSocket: {}
     ...
     

3. --platform managed フラグを使用して、変更した .yaml ファイルを Cloud Run にデプロイします。デプロイの詳細については、こちらをご覧ください。

   Cloud Run には同じ Google Cloud プロジェクトを使用できます。

   gcloud run services replace FILENAME.yaml --platform managed --region REGION
   

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

   • FILENAME: 作成したエクスポート構成ファイルの名前。
   • REGION: サポートされている Cloud Run のロケーション。例: us-central1

4. Cloud Run サービスへのアクセスを構成します。

   • デフォルトでは、Cloud Run サービスには外部からアクセスできません。サービスをインターネットに公開し、未認証のリクエストを許可するには、一般公開（未認証）アクセスを許可する必要があります。

   • Cloud Run サービス間など、非公開の内部専用アクセス用にこのサービスを構成するには、サービス間の認証をご覧ください。

5. Google Cloud コンソールのサービスページでは、表示された URL リンクをクリックして、デプロイしたサービスで一意の安定したエンドポイントを開くことができます。

   Cloud Run に移動します。

サービスへのトラフィックの移行

新しくデプロイしたサービスをテストし、本番環境のトラフィックをすべて移行する準備ができたら、カスタム ドメインを構成し、登録事業者で DNS レコードを更新します。カスタム ドメインのマッピングの手順を実施します。