從 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 第 1 版實作了 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 部分不同，需要變更。 red 中的部分應刪除，因為 Cloud Run 內建自動調度器。

Kubernetes DeploymentCloud 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

  1. 使用下列指令，在目前目錄中下載部署作業的 YAML 檔案：

    kubectl get deployment  my-app -o yaml > my-app.yaml

  2. 修改 YAML，使其符合 Cloud Run 服務。更新 my-app.yaml 檔案：

    • 針對「kind」屬性：將值「Deployment」替換為「Service」
    • 針對「apiVersion」屬性：將值「apps/v1」替換為「serving.knative.dev/v1」
    • 刪除 metadata.namespace 屬性，或變更其值，確保與 Google Cloud 專案編號一致。
    • 刪除 spec.replicas 和 spec.selector

  3. 使用下列指令將 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 Manager 中。

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

  • 名稱可用的字元：
  • 版本控管：Secret Manager 中的密鑰會進行版本控管，但 Kubernetes 密鑰不會。
  • 酬載：Secret Manager 中的密鑰包含單一 []byte，而 Kubernetes 密鑰則包含 map<string, string>。

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

遷移 Kubernetes ConfigMap

Cloud Run 沒有 Kubernetes ConfigMaps 的對等項目，但由於 ConfigMaps 可視為未加密的 Secret，因此您可以改為在 Secret Manager 中將 ConfigMaps 轉換為 Secret。請參閱「遷移 Kubernetes Secret」一節的操作說明。

遷移 Kubernetes Deployment

Kubernetes 部署是與 Cloud Run 服務最接近的對應資源。建議您從 Kubernetes 部署的 YAML 開始，並加以編輯，將其轉換為 Cloud Run 服務。

主要必要變更如下：

  • 請將 namespace 替換為 Google Cloud 專案編號。
  • 標籤 (metadata.labels 和 spec.template.metadata.labels) 必須是有效 Google Cloud 標籤。
  • 容器必須儲存在支援的容器登錄檔中。
  • 可能需要調整 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 工作

因為 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

遷移策略

建立對應資源後，您就能透過全球外部應用程式負載平衡器公開外部端點，逐步在 Cloud Run 和 Google Kubernetes Engine (GKE) 之間遷移流量。