このガイドでは、ワークロードを 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
アクセス制御:
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 ファイルにエクスポートします。
gcloud run services describe SERVICE --format export --namespace NAMESPACE --cluster CLUSTER --platform gke > FILENAME.yaml
次のように置き換えます。
SERVICE
: Knative serving サービスの名前。NAMESPACE
: サービスが実行されている Namespace。CLUSTER
: サービスが実行されているクラスタの名前。FILENAME
: 任意の一意のファイル名。
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: {} ...
- Kubernetes の Namespace を検索して、Google Cloud プロジェクトの ID に置き換える必要があります。たとえば、
--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
Cloud Run サービスへのアクセスを構成します。
デフォルトでは、Cloud Run サービスには外部からアクセスできません。サービスをインターネットに公開し、未認証のリクエストを許可するには、一般公開(未認証)アクセスを許可する必要があります。
Cloud Run サービス間など、非公開の内部専用アクセス用にこのサービスを構成するには、サービス間の認証をご覧ください。
Google Cloud コンソールのサービスページでは、表示された URL リンクをクリックして、デプロイしたサービスで一意の安定したエンドポイントを開くことができます。
サービスへのトラフィックの移行
新しくデプロイしたサービスをテストし、本番環境のトラフィックをすべて移行する準備ができたら、カスタム ドメインを構成し、登録事業者で DNS レコードを更新します。カスタム ドメインのマッピングの手順を実施します。