Cloud Run と Kubernetes はデプロイ アーティファクトとして標準のコンテナ イメージを使用します。どちらも宣言型 API モデルを使用し、同じ標準構造の YAML ファイルにリソースを記述します。
はじめに
Cloud Run Admin API v1 は、Kubernetes でのポータビリティを最大限に高めるように設計されています。たとえば、Cloud Run Admin API リソースは、Kubernetes リソースと同じ構造規則と属性名を共有します。Cloud Run サービスの YAML リファレンスをご覧ください。
Cloud Run Admin API v1 は Knative Serving API の仕様を実装していますが、Kubernetes ワークロードの一部を Cloud Run に移行するため、既存の Kubernetes クラスタで Knative を使用する必要はありません。
Cloud Run の主要なリソースはサービスです。Cloud Run サービスは、Pod オートスケーラーと一意のエンドポイントが組み込まれた Kubernetes Deployment のような高度な抽象化とみなすことができます。Kubernetes の Pod は、Cloud Run のインスタンスに対応します。Kubernetes Deployment は Cloud Run サービスに変換することをおすすめします（一度に 1 つのサービスに変換してください）。Kubernetes HorizontalPodAutoscaler と Kubernetes Service の一部の構成を Cloud Run サービスに統合することもできます。
Cloud Run には Namespace のコンセプトがありません。リソースを分離する境界として Google Cloud プロジェクトが使用されます。Kubernetes から Cloud Run に移行する場合は、Namespace ごとに 1 つの Google Cloud プロジェクトを作成することをおすすめします。Namespace の値は、Cloud Run サービスの YAML で Google Cloud プロジェクト番号になります。
Cloud Run にはゾーンの冗長性が組み込まれています。つまり、特定の Google Cloud リージョン内のゾーン停止に対するサービスの復元力を維持するためにレプリカをプロビジョニングする必要はありません。
クイックスタート
このクイックスタートでは、シンプルな移行例について説明します。
シンプルなリソースの比較
次のシンプルな Kubernetes Deployment（my-app）を同等の Cloud Run サービスと比べてみましょう。YAML ファイルはほとんど同じです。
blue の部分は異なるため、変更が必要です。Cloud Run にはオートスケーラーが組み込まれているため、red の部分は削除する必要があります。
| Kubernetes Deployment | Cloud Run サービス |
|---|---|
apiVersion: apps/v1 kind: Deployment metadata: name: my-app namespace: default labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world replicas: 3 selector: matchLabels: app: my-app |
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: my-app namespace: 'PROJECT_NUMBER' labels: app: my-app spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world |
シンプルな Kubernetes Deployment を Cloud Run に移行する
次のコマンドを実行して、現在のディレクトリに Deployment の YAML ファイルをダウンロードします。
kubectl get deployment my-app -o yaml > my-app.yaml
Cloud Run サービスと一致するように YAML を変更します。
my-app.yamlファイルを更新します。kind属性は、値DeploymentをServiceに置き換えます。apiVersion属性は、値apps/v1をserving.knative.dev/v1に置き換えます。metadata.namespace属性を削除するか、Google Cloud プロジェクト番号と一致するように値を変更します。spec.replicasとspec.selectorを削除します。
次のコマンドを使用して
my-app.yamlファイルを Cloud Run にデプロイします。REGION は、目的の Google Cloud リージョン（たとえばus-central1）に置き換えます。gcloud run services replace my-app.yaml --region REGION
Cloud Run サービスの呼び出しは、IAM 権限によって保護されています。新しい Cloud Run サービスをインターネットに公開して未認証の呼び出しを許可する場合は、次のコマンドを実行します。
gcloud run services add-iam-policy-binding my-app --member="allUsers" --role="roles/run.invoker" --region REGION
Cloud Run でサポートされていない機能
移行できるのは、Cloud Run に適しているワークロードのみです。
次の Kubernetes 機能は Cloud Run でサポートされていません。
replicasの固定数。回避策として、最小インスタンスと最大インスタンスと同じ数を使用。- Config Maps（回避策あり）
- カスタム HorizontalPodAutoscaler 戦略
- サービス ディスカバリ
Kubernetes Deployment から Cloud Run サービスに YAML ファイルを移行するときに、gcloud run services replace コマンドは Cloud Run でサポートされていない属性に対して明確なエラー メッセージを返します。これらの属性を削除または更新してから、成功するまでこのコマンドを繰り返します。
Cloud Run でサポートされている属性の完全なリストについては、YAML リファレンスをご覧ください。
Kubernetes リソースの移行
Kubernetes Secret を移行する
Kubernetes と同様に、Cloud Run はシークレットを環境変数またはボリュームとしてマウントできますが、シークレットは Secret Manager に保存する必要があります。
Secret Manager のシークレットと Kubernetes の Secret には重要な違いがあります。
- 名前に使用できる文字:
- Kubernetes シークレット:
[a-z0-9-.]{1,253} - Secret Manager シークレット:
[a-zA-Z0-9_-]{1,255}
- Kubernetes シークレット:
- バージョニング: Secret Manager シークレットはバージョニングされますが、Kubernetes シークレットはバージョニングされません。
- ペイロード: Secret Manager のシークレットには単一の
[]byteが含まれますが、Kubernetes Secret にはmap<string, string>が含まれます。
Secret Manager のドキュメントに従ってシークレットを作成し、Kubernetes アプリが依存しているすべての秘密鍵に新しいシークレット バージョンを追加します。
Kubernetes ConfigMap を移行する
Cloud Run には Kubernetes ConfigMap に相当するものはありませんが、ConfigMap は「暗号化されていない Secret」と考えることができるので、Secret Manager で ConfigMap をシークレットに変換できます。Kubernetes Secret を移行するの手順をご覧ください。
Kubernetes Deployment を移行する
Kubernetes Deployment は Cloud Run サービスに最も近いリソースです。Kubernetes Deployment の YAML を編集して、それを Cloud Run サービスに変換することをおすすめします。
必要な変更は次のとおりです。
namespaceは、Google Cloud プロジェクト番号に置き換えます。- ラベル（
metadata.labelsとspec.template.metadata.labels）は、有効な Google Cloud ラベルにします。 - コンテナは、サポートされている Container Registry に保存します。
- CPU とメモリの上限は、調整が必要になる場合があります。
- シークレットを参照する場合、
key属性を使用して Secret Manager のバージョンを取得します。latest属性は、シークレットの最新バージョンを参照します。 serviceAccountNameは、現在の Google Cloud プロジェクトのサービス アカウントを参照する必要があります。- ConfigMap（
configMapKeyRef）への参照は、シークレット（secretKeyRef）への参照に置き換えます。
Kubernetes Deployment が Kubernetes クラスタ内の他のリソースや VPC のリソースにアクセスしている場合は、Cloud Run サービスを適切な VPC に接続する必要があります。
Kubernetes Service を移行する
Cloud Run サービスは、containerPort を使用して、コンテナにトラフィックを転送する一意のエンドポイントを自動的に公開します。Kubernetes Deployment を Cloud Run サービスに移行した後は、この Deployment にトラフィックを転送していた Kubernetes Service を移行する必要はありません。
Kubernetes HorizontalPodAutoscaler を移行する
Cloud Run サービスには水平オートスケーラーが組み込まれています。Cloud Run は、定義された最小数と最大数の境界内で要素の組み合わせを使用し、Pod（インスタンス）を自動的にスケーリングします。
HorizontalPodAutoscaler の minReplicas 属性と maxReplicas 属性を Cloud Run サービスの autoscaling.knative.dev/minScale アノテーションと autoscaling.knative.dev/maxScale アノテーションに移行します。最小インスタンスと最大インスタンスの構成に関するドキュメントをご覧ください。
Kubernetes Job を移行する
Kubernetes Job は Cloud Run のジョブ実行に似ているため、Cloud Run ジョブに移行してジョブを実行できます。
次のサンプルは、Kubernetes Job と Cloud Run ジョブの構造上の違いを示しています。
| Kubernetes Job | Cloud Run ジョブ |
|---|---|
apiVersion: batch/v1
kind: Job
metadata:
name: my-job
spec:
template:
spec:
containers:
- image: us-docker.pkg.dev/cloudrun/container/job
|
apiVersion: run.googleapis.com/v1 kind: Job metadata: name: my-job spec: template: spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job |
移行戦略
同等のリソースを作成した後、グローバル外部アプリケーション ロードバランサの背後に外部エンドポイントを公開することで、Cloud Run と Google Kubernetes Engine（GKE）間のトラフィックを段階的に移行できます。