Google 會運用 AI 技術將內容翻譯成你偏好的語言，但可能會出錯。

從 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 叢集中的 Knative，即可將部分 Kubernetes 工作負載遷移至 Cloud Run。

Cloud Run 的主要資源是「服務」。您可以將 Cloud Run 服務視為高階抽象概念，類似於 Kubernetes 部署，內建 Pod 自動調度資源工具和專屬端點。Kubernetes 中的「Pod」對應 Cloud Run 中的「執行個體」。建議您將 Kubernetes 部署項目轉換為 Cloud Run 服務，一次轉換一項服務。您也可以將 Kubernetes 水平自動調度 Pod 資源和 Kubernetes 服務的部分設定，合併至 Cloud Run 服務。

Cloud Run 沒有命名空間的概念，而是使用Google Cloud 專案做為資源之間的隔離邊界。從 Kubernetes 遷移至 Cloud Run 時，建議您為每個命名空間建立一個Google Cloud 專案。在 Cloud Run 服務的 YAML 中，命名空間值為 Google Cloud 專案編號。

Cloud Run 內建可用區備援機制，因此您不必佈建副本，就能確保服務在所選 Google Cloud 區域發生可用區中斷時，仍能正常運作。

快速入門導覽課程

本快速入門導覽課程是簡單的遷移範例。

簡單比較資源

請比較下列名為 my-app 的簡易 Kubernetes 部署作業與對等的 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 部署作業遷移至 Cloud Run

使用下列指令，在目前目錄中下載部署作業的 YAML 檔案：
```
kubectl get deployment  my-app -o yaml > my-app.yaml
```
修改 YAML，使其與 Cloud Run 服務相符。更新 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 區域，例如 europe-west1：
```
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 的工作負載才能遷移。

請特別注意，Cloud Run 不支援下列 Kubernetes 功能：

replicas 的固定數量 (解決方法是使用相同的下限和上限執行個體數量)
ConfigMap (有解決方法)
自訂水平 Pod 自動配置器策略
服務探索
本機磁碟 (暫時和永久)

將 YAML 檔案從 Kubernetes 部署作業遷移至 Cloud Run 服務時，如果 Cloud Run 不支援任何屬性，gcloud run services replace 指令會傳回明確的錯誤訊息。請刪除或更新這些屬性，然後重複執行指令，直到成功為止。

如需 Cloud Run 支援的完整屬性清單，請參閱 YAML 參考資料。

遷移 Kubernetes 資源

遷移 Kubernetes Secret

與 Kubernetes 相同，Cloud Run 支援將 Secret 掛接為環境變數或磁碟區，但 Secret 應儲存在 Secret Manager 中。

Secret Manager 密鑰和 Kubernetes 密鑰之間有幾項重要差異：

名稱中可使用的字元：
- Kubernetes 密鑰：[a-z0-9-.]{1,253}
- Secret Manager 密鑰：[a-zA-Z0-9_-]{1,255}
版本管理：Secret Manager 的 Secret 有版本管理功能，Kubernetes Secret 則沒有。
酬載：Secret Manager 的 Secret 包含單一 []byte，而 Kubernetes Secret 則包含 map<string, string>。

請按照 Secret Manager 說明文件建立密鑰，並為 Kubernetes 應用程式依賴的每個密鑰金鑰新增密鑰版本。

遷移 Kubernetes ConfigMap

Cloud Run 沒有與 Kubernetes ConfigMaps 相當的功能，但由於 ConfigMap 可視為未加密的 Secret，因此您可以改為將 ConfigMap 轉換為 Secret Manager 中的 Secret。請參閱「遷移 Kubernetes Secret」一節的操作說明。

遷移 Kubernetes Deployment

由 Service 公開的 Kubernetes Deployment 是最接近 Cloud Run 服務的資源。建議您從 Kubernetes 部署作業的 YAML 著手，並編輯該 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) 應替換為 Secret 的參照 (secretKeyRef)

如果 Kubernetes 部署項目會存取 Kubernetes 叢集中的其他資源，或虛擬私有雲上的資源，您必須將 Cloud Run 服務連結至適當的虛擬私有雲

遷移 Kubernetes 服務

Cloud Run 服務會自動公開不重複的端點，並使用 containerPort 將流量轉送至容器。將 Kubernetes 部署作業遷移至 Cloud Run 服務後，您就不需要遷移將流量轉送至這項部署作業的 Kubernetes 服務。

遷移 Kubernetes HorizontalPodAutoscaler

Cloud Run 服務內建水平自動調度資源功能：Cloud Run 會根據多項因素，在定義的執行個體數量上下限範圍內，自動調度 Pod (稱為「執行個體」) 資源。

將 HorizontalPodAutoscaler 的 minReplicas 和 maxReplicas 屬性，遷移至 Cloud Run 服務的 autoscaling.knative.dev/minScale 和 autoscaling.knative.dev/maxScale 註解。請參閱說明文件，瞭解如何設定執行個體數量下限和執行個體數量上限。

遷移沒有服務的 Kubernetes Deployment

如果 Kubernetes 部署作業會執行背景或排定的工作，且未透過服務公開，則可遷移至 Cloud Run worker 集區。

下列範例說明 Kubernetes 部署作業和 Cloud Run worker 集區之間的結構差異：

Kubernetes Deployment	Cloud Run worker 集區
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:	apiVersion: run.googleapis.com/v1 kind: WorkerPool metadata: name: my-app annotations: run.googleapis.com/manualInstanceCount: '1' spec: template: metadata: labels: app: my-app spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world

Kubernetes Deployment

Cloud Run worker 集區

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:

apiVersion: run.googleapis.com/v1
kind: WorkerPool
metadata:
  name: my-app
  annotations:
    run.googleapis.com/manualInstanceCount: '1'
spec:
template:
    metadata:
      labels:
      app: my-app
    spec:
      containers:
      - image: gcr.io/cloudrun/hello
        env:
        - name: HELLO
          value: world

遷移 Kubernetes 工作

因為 Kubernetes 工作與 Cloud Run 工作執行作業類似。您可以遷移至 Cloud Run 工作並執行工作。

下列範例顯示 Kubernetes 工作和 Cloud Run 工作之間的結構差異：

Kubernetes 工作	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 工作

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) 之間遷移流量。

從 Kubernetes 遷移至 Cloud Run 透過集合功能整理內容 你可以依據偏好儲存及分類內容。

簡介