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 Console と同様です。

準備

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

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

• アクセス制御:

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

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

移行に関する考慮事項

プロダクト全体で次の違いを確認し、理解して、すべての依存関係と要件を移植できるようにする必要があります。

Secret

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

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

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

Secret Manager を使用して、Knative serving サービスの秘密鍵にバージョニングされたシークレットを作成する方法を学習します。

ネットワーキング

次の情報を使用して、既存のネットワーク構成を 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 は、サービスが実行されている名前空間に置き換えます。
   • CLUSTER は、サービスが実行されているクラスタの名前に置き換えます。
   • FILENAME は、任意の一意のファイル名で置き換えます。

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

   • Kubernetes の名前空間を検索して、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 レコードを更新できます。カスタム ドメインを構成するの手順を実行してください。