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 機能はサポートされていません。

移行に関する考慮事項

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

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 にデプロイする必要があります。

  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:defaultnamespace: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
    

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

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

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

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

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

    Cloud Run に移動します

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

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