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
Download file YAML layanan ke direktori saat ini:
gcloud run services describe my-app --format export > my-app.yaml
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, contohnyadefault
. - Tambahkan label baru pada
metadata
danspec.template.metadata
. - Tetapkan jumlah instance yang tetap ("replika")
menggunakan
spec.template.spec.replicas
dan tetapkan pemilih label padaspec.template.spec.selector
.
- Untuk atribut "
Instal dan gunakan alat command line
kubectl
untuk men-deploy filemy-app.yaml
ke cluster GKE Anda:kubectl apply -f ./my-app.yaml
Ekspos deployment sebagai layanan:
kubectl expose deployment my-app --type LoadBalancer --port 80 --target-port 8080
Pertimbangan saat bermigrasi 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:
- Deployment Kubernetes untuk membuat instance (disebut "pod" di Kubernetes).
- Layanan Kubernetes untuk mengekspos deployment di endpoint tertentu.
- Horizontal Pod Autoscaler Kubernetes: untuk menskalakan deployment secara otomatis.
Atribut deployment Kubernetes adalah superset dari
atribut layanan Cloud Run.
Seperti yang ditunjukkan dalam panduan memulai, 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, contohnyadefault
. serviceAccountName
harus merujuk ke akun layanan Kubernetes, yang secara opsional dapat bertindak sebagai akun layanan IAM dengan Workload Identity Federation untuk GKE.- Tambahkan LABEL pada
metadata.labels
danspec.template.metadata.labels
yang akan digunakan untuk memilih deployment dan pod. Contoh:app: NAME
- Pada
spec.template
:- Tambahkan atribut
replicas
untuk menentukan jumlah "instance". - Tambahkan atribut
selector.matchLabels
yang dipilih di label LABEL.
- Tambahkan atribut
- 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 adalah8080
.
Kemudian, Anda dapat membuat Horizontal Pod Autoscaler Kubernetes secara opsional untuk menskalakan jumlah pod secara otomatis.
Ikuti dokumentasi Horizontal Pod Autoscaling 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 memigrasikan 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}
- Secret Kubernetes:
- Pembuatan versi: Secret dari Secret Manager diberi versi, sedangkan secret Kubernetes tidak.
- Payload: Secret dari Secret Manager berisi satu
[]byte
, sedangkan secret Kubernetes berisimap<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).