Migrasi dari Kubernetes ke Cloud Run

Cloud Run dan Kubernetes keduanya menggunakan image container standar sebagai artefak deployment, mereka menggunakan model API deklaratif dengan resource yang dapat direpresentasikan dalam file YAML dengan struktur standar yang sama.

Pengantar

Cloud Run Admin API v1 dirancang untuk memaksimalkan portabilitas dengan Kubernetes, misalnya, resource Cloud Run Admin API memiliki konvensi struktur dan nama atribut yang sama dengan resource Kubernetes. Lihat referensi YAML layanan Cloud Run.

Cloud Run Admin API v1 menerapkan spesifikasi Knative Serving API, tetapi Anda tidak perlu menggunakan Knative di cluster Kubernetes Anda yang sudah ada untuk memigrasikan beberapa workload Kubernetes Anda ke Cloud Run.

Resource utama Cloud Run adalah layanan. Anda dapat menganggap layanan Cloud Run sebagai abstraksi tingkat tinggi yang terlihat seperti deployment Kubernetes dengan autoscaler pod bawaan dan endpoint unik. "Pod" di Kubernetes sesuai dengan "instance" di Cloud Run. Kami merekomendasikan untuk mengubah deployment Kubernetes Anda menjadi layanan Cloud Run, satu layanan dalam satu waktu. Anda juga akan dapat menggabungkan beberapa konfigurasi Anda Horizontal Pod Autoscaler dan layanan Kubernetes ke dalam layanan Cloud Run.

Cloud Run tidak memiliki konsep namespace, sebagai gantinya project Google Cloud digunakan sebagai batas isolasi antar-resource. Saat bermigrasi ke Cloud Run dari Kubernetes, kami merekomendasikan untuk membuat satu project Google Cloud untuk setiap namespace. Di YAML dari layanan Cloud Run , nilai namespace adalah nomor project Google Cloud.

Cloud Run memiliki redundansi zona bawaan, hal ini berarti bahwa, Anda tidak perlu menyediakan replika untuk memastikan layanan Anda tahan terhadap pemadaman layanan menurut zona di region Google Cloud yang dipilih.

Panduan memulai

Panduan memulai ini adalah sebuah contoh dari contoh migrasi sederhana.

Perbandingan resource sederhana

Bandingkan deployment Kubernetes sederhana berikut yang bernama my-app dengan layanan Cloud Run yang setara. Perhatikan bagaimana file YAML hampir identik.

Bagian di blue berbeda dan perlu untuk diubah. Bagian-bagian di red harus dihapus karena Cloud Run memiliki autoscaler bawaan.

Deployment KubernetesLayanan 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

Migrasi deployment Kubernetes sederhana ke Cloud Run

  1. Download file YAML pada deployment Anda di direktori saat ini dengan:

    kubectl get deployment  my-app -o yaml > my-app.yaml
  2. Ubah YAML untuk mencocokkan dengan layanan Cloud Run. Update file my-app.yaml:

    • Untuk atribut "kind": ganti nilai "Deployment" dengan "Service"
    • Untuk atribut "apiVersion": ganti nilai "apps/v1" dengan "serving.knative.dev/v1"
    • Hapus atribut metadata.namespace atau ubah nilainya agar cocok dengan nomor project Google Cloud Anda.
    • Hapus spec.replicas dan spec.selector
  3. Deploy file my-app.yaml ke Cloud Run menggunakan perintah berikut, menggantikan REGION dengan region Google Cloud yang diinginkan, misalnya us-central1:

    gcloud run services replace my-app.yaml --region REGION

Memanggil layanan Cloud Run dilindungi oleh izin IAM. Jika Anda ingin mengekspos layanan Cloud Run yang baru secara publik ke internet dan mengizinkan pemanggilan yang tidak terautentikasi, jalankan perintah berikut:

gcloud run services add-iam-policy-binding my-app --member="allUsers" --role="roles/run.invoker" --region REGION

Fitur yang tidak didukung oleh Cloud Run

Hanya workload yang cocok untuk Cloud Run yang dapat dimigrasikan.

Secara khusus, fitur Kubernetes berikut tidak didukung oleh Cloud Run:

  • Jumlah replicas tetap (solusinya adalah menggunakan jumlah instance minimum dan maksimum yang sama
  • Config Maps (solusi tersedia)
  • Strategi horizontal Pod autoscaler kustom
  • Service Discovery

Saat memigrasikan file YAML dari deployment Kubernetes ke layanan Cloud Run, perintah gcloud run services replace akan menampilkan pesan error yang jelas untuk atribut apa pun yang tidak didukung oleh Cloud Run. Hapus atau perbarui atribut tersebut, lalu ulangi perintah hingga berhasil.

Anda dapat merujuk pada Referensi YAML untuk melihat daftar lengkap atribut yang didukung oleh Cloud Run.

Migrasikan resource Kubernetes

Migrasikan secret Kubernetes

Seperti Kubernetes, Cloud Run mendukung pemasangan secret sebagai variabel atau volume lingkungan, tetapi rahasia harus disimpan di Secret Manager.

Ada beberapa perbedaan penting antara rahasia Secret Manager dan secret Kubernetes:

  • Karakter yang diizinkan dalam nama:
    • Secret Kubernetes: [a-z0-9-.]{1,253}
    • Secret pada Secret Manager: [a-zA-Z0-9_-]{1,255}
  • Pembuatan versi: Secret dari Secret Manager diberi versi, sedangkan secret Kubernetes tidak.
  • Payload: Rahasia dari Secret Manager berisi satu []byte, sedangkan secret Kubernetes berisi map<string, string>.

Ikuti dokumentasi Secret Manager untuk membuat rahasia dan menambahkan versi rahasia baru untuk setiap kunci rahasia yang diandalkan aplikasi Kubernetes Anda.

Migrasikan ConfigMaps Kubernetes

Cloud Run tidak memiliki fitur yang setara dengan Kubernetes ConfigMaps, tetapi karena ConfigMaps dapat dilihat sebagai Rahasia yang tidak dienkripsi, sebagai gantinya Anda dapat mengubah ConfigMaps Anda menjadi rahasia di Secret Manager. Lihat petunjuknya di bagian Migrasikan secret Kubernetes.

Migrasikan deployment Kubernetes

Deployment Kubernetes adalah resource yang memetakan yang terdekat dengan layanan Cloud Run. Kami merekomendasikan untuk memulai dari YAML pada deployment Kubernetes Anda lalu edit untuk mengubahnya menjadi layanan Cloud Run.

Perubahan utama yang diperlukan adalah:

  • namespace harus diganti dengan nomor project Google Cloud.
  • Label (metadata.labels dan spec.template.metadata.labels) harus berupa label Google Cloud yang valid.
  • Container harus disimpan dalam container registry yang didukung.
  • Batas CPU dan memori mungkin perlu untuk disesuaikan.
  • Saat mereferensikan rahasia, atribut "key" digunakan untuk mengambil versi di Secret Manager, dengan "latest" yang mereferensikan versi terbaru dari rahasia tersebut.
  • serviceAccountName harus merujuk ke Akun Layanan dalam project Google Cloud saat ini
  • Referensi ke ConfigMaps (configMapKeyRef) harus diganti dengan referensi ke secret (secretKeyRef)

Jika deployment Kubernetes Anda mengakses resource lainnya di cluster Kubernetes atau resource Anda pada VPC, Anda harus menghubungkan layanan Cloud Run ke VPC yang sesuai

Migrasikan Layanan Kubernetes

Layanan Cloud Run secara otomatis mengekspos endpoint unik yang merutekan traffic ke container dengan containerPort. Setelah Anda memigrasikan deployment Kubernetes ke layanan Cloud Run, Anda tidak perlu memigrasikan layanan Kubernetes yang merutekan traffic ke deployment ini.

Migrasikan HorizontalPodAutoscaler Kubernetes

Layanan Cloud Run memiliki autoscaler horizontal bawaan: Cloud Run secara otomatis menskalakan pod (disebut "instances") menggunakan kombinasi faktor dalam batas-batas jumlah instance minimum dan maksimum yang ditentukan.

Migrasikan atribut minReplicas dan maxReplicas dari HorizontalPodAutoscaler ke anotasi autoscaling.knative.dev/minScale dan autoscaling.knative.dev/maxScale dari layanan Cloud Run. Lihat dokumentasi tentang cara mengonfigurasi instance minimum dan instance maksimum.

Migrasikan Tugas Kubernetes

Karena tugas Kubernetes serupa dengan eksekusi tugas Cloud Run. Anda dapat bermigrasi ke tugas Cloud Run dan untuk menjalankan tugas.

Contoh berikut menunjukkan perbedaan struktural antara tugas Kubernetes dan tugas Cloud Run:

Tugas KubernetesTugas 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

Strategi migrasi

Setelah Anda membuat resource yang setara, dengan mengekspos endpoint eksternal pada Load Balancer Aplikasi eksternal global, Anda dapat memigrasikan traffic secara bertahap antara Cloud Run dan Google Kubernetes Engine (GKE).