Kubernetes から Cloud Run に移行する

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 サービス

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 Secret: [a-z0-9-.]{1,253}
- Secret Manager シークレット: [a-zA-Z0-9_-]{1,255}
バージョニング: Secret Manager のシークレットはバージョニングされますが、Kubernetes Secret はバージョニングされません。
ペイロード: 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

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）間のトラフィックを段階的に移行できます。