Bermigrasi dari Cloud Run ke Google Kubernetes Engine

Cloud Run dan Kubernetes menggunakan image container standar sebagai artefak deployment, Keduanya menggunakan model API deklaratif dengan resource yang dapat ditampilkan 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 bermigrasi ke Knative untuk memindahkan workload Cloud Run ke cluster Kubernetes seperti GKE.

Panduan memulai

Panduan memulai ini adalah contoh migrasi sederhana.

Perbandingan resource sederhana

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

Namun, bagian di blue berbeda dan perlu diubah. Bagian di green harus ditambahkan.

Layanan Cloud Run	Deployment Kubernetes
apiVersion: serving.knative.dev/v1 kind: Service metadata: name: my-app namespace: 'PROJECT_NUMBER' spec: template: spec: containers: - image: gcr.io/cloudrun/hello env: - name: HELLO value: world	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

Memigrasikan layanan Cloud Run sederhana ke GKE

1. Download file YAML layanan ke direktori saat ini:

   gcloud run services describe my-app --format export > my-app.yaml
   

2. Ubah YAML agar cocok dengan deployment Kubernetes:

   • Untuk atribut "kind": ganti nilai "Service" dengan "Deployment"
   • Untuk atribut "apiVersion": ganti nilai "serving.knative.dev/v1" dengan "apps/v1"
   • Ganti metadata.namespace dengan namespace cluster GKE yang ingin di-deploy, contohnya default.
   • Tambahkan label baru pada metadata dan spec.template.metadata.
   • Tetapkan jumlah instance yang tetap ("replika") menggunakan spec.template.spec.replicas dan tetapkan pemilih label pada spec.template.spec.selector.

3. Instal dan gunakan alat command line kubectl untuk men-deploy file my-app.yaml ke cluster GKE Anda:

   kubectl apply -f ./my-app.yaml
   

4. Ekspos deployment sebagai layanan:

   kubectl expose deployment my-app --type LoadBalancer --port 80 --target-port 8080
   

Pertimbangan saat melakukan migrasi dari Cloud Run ke GKE

Cluster:

• Cloud Run adalah platform yang terkelola sepenuhnya, sedangkan GKE memerlukan lebih banyak pengelolaan platform. Jika Anda belum membuat cluster GKE, gunakan GKE Autopilot.

• Skalabilitas workload GKE dibatasi oleh ukuran cluster. Jika Anda tidak menggunakan cluster Autopilot, pertimbangkan untuk menggunakan penyediaan otomatis node dan autoscaler cluster untuk mengubah ukuran cluster Anda.

• Cloud Run memilikiredundansi zona bawaan, jadi lakukan migrasi kecluster regional dan sediakan replika yang cukup untuk memastikan layanan Anda tahan terhadap pemadaman layanan di zona region Google Cloud terpilih.

Harga

Cloud Run mengenakan biaya untuk resource yang telah digunakan, sedangkan GKE menetapkan biaya untuk resource yang disediakan.

Keamanan:

• Berbeda dengan Cloud Run, panggilan layanan GKE tidak tunduk pada izin invoker IAM.

• Karena GKE tidak menyediakan isolasi yang kuat di antara container, pertimbangkan untuk menggunakan GKE Sandbox jika Anda perlu mengeksekusi kode yang tidak dikenal atau tidak terpercaya.

Jaringan

Cloud Run memerlukan konektor Akses VPC Serverless untuk mengakses resource lain dalam VPC. Workload GKE langsung berada di VPC dan tidak memerlukan konektor.

Fitur yang tidak didukung oleh Google Kubernetes Engine

Fitur Cloud Run berikut tidak tersedia di GKE:

• Pembuatan versi konfigurasi melalui revisi
• Pemisahan traffic untuk peluncuran bertahap dan rollback revisi
• CPU hanya dialokasikan selama proses permintaan
• Peningkatan CPU
• Afinitas sesi
• Label pada workload GKE bukan merupakan label Google Cloud
• Tag pada workload

Memigrasikan resource Cloud Run

Bagian berikut menjelaskan migrasi resource yang digunakan pada Cloud Run, seperti layanan, tugas, dan secret Cloud Run.

Memigrasikan layanan Cloud Run

Anda dapat memigrasikan layanan Cloud Run ke resource berikut di GKE:

1. Deployment Kubernetes untuk membuat instance (disebut "pod" di Kubernetes).
2. Layanan Kubernetes untuk mengekspos deployment di endpoint tertentu.
3. Horizontal Pod Autoscaler Kubernetes: untuk menskalakan deployment secara otomatis.

Atribut deployment Kubernetes adalah superset dari atribut layanan Cloud Run. Seperti yang ditunjukkan dalam quickstart, setelah mengubah atribut apiVersion dan kind menjadi apps/v1 dan Deployment, Anda juga perlu mengubah hal berikut:

• Ganti namespace dengan namespace cluster GKE yang akan di-deploy, contohnya default.
• serviceAccountName harus merujuk ke akun layanan Kubernetes, yang secara opsional bisa bertindak sebagai akun layanan IAM dengan Workload Identity.
• Tambahkan LABEL pada metadata.labels dan spec.template.metadata.labels yang akan digunakan untuk memilih deployment dan pod. Contoh: app: NAME
• Di bagian spec.template:
  • Tambahkan atribut replicas untuk menentukan jumlah "instance".
  • Tambahkan atribut selector.matchLabels yang dipilih di label LABEL.
• Jika layanan Cloud Run Anda memasang secret, lihat Memigrasikan secret.
• Jika layanan Cloud Run yang dimigrasikan mengakses resource di Virtual Private Cloud, Anda tidak perlu menggunakan konektor Akses VPC Serverless.

Setelah membuat deployment Kubernetes, buat layanan Kubernetes untuk mengeksposnya:

apiVersion: v1
kind: Service
metadata:
  name: NAME
spec:
  selector:
    LABEL
  ports:
    - protocol: TCP
      port: 80
      targetPort: PORT

Replace:

• NAME: dengan nama layanan Anda.
• LABEL: dengan label yang ditentukan dalam deployment Anda. Contohnya app: NAME
• PORT: dengan containerPort container yang menerima permintaan di layanan Cloud Run, yang nilai defaultnya adalah 8080.

Kemudian, Anda dapat membuat Horizontal Pod Autoscaler Kubernetes secara opsional untuk menskalakan jumlah pod secara otomatis. Ikuti dokumentasi Penskalaan Otomatis Pod Horizontal Kubernetes untuk membuat HorizontalPodAutoscaler. Gunakan nilai instance minimum (autoscaling.knative.dev/minScale) dan instance maksimum (autoscaling.knative.dev/maxScale) dari Cloud Run Anda sebagai nilai untuk atribut minReplicas dan maxReplicas HorizontalPodAutoscaler.

Memigrasikan tugas Cloud Run

Anda dapat melakukan migrasi tugas Cloud Run ke tugas Kubernetes di GKE.

Berbeda dengan tugas Cloud Run, tugas Kubernetes dijalankan saat dibuat. Jika ingin menjalankan tugas lagi, Anda perlu membuat tugas baru.

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

Tugas Cloud Run	Tugas Kubernetes
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	apiVersion: batch/v1 kind: Job metadata: name: my-job spec: template: spec: containers: - image: us-docker.pkg.dev/cloudrun/container/job

Memigrasikan secret

Anda dapat menyimpan secret yang ada di Secret Manager atau memigrasikannya ke secret Kubernetes.

Jika memilih untuk menyimpan secret di Secret Manager, Anda perlu memperbarui cara penggunaannya di GKE

Jika Anda memilih untuk bermigrasi dari Secret Manager ke secret Kubernetes, pertimbangkan perbedaan antara secret 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: Secret dari Secret Manager berisi satu []byte, sedangkan secret Kubernetes berisi map<string, string>.

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).