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 Kubernetes | Layanan 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
Download file YAML pada deployment Anda di direktori saat ini dengan:
kubectl get deployment my-app -o yaml > my-app.yaml
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
danspec.selector
- Untuk atribut "
Deploy file
my-app.yaml
ke Cloud Run menggunakan perintah berikut, menggantikan REGION dengan region Google Cloud yang diinginkan, misalnyaus-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}
- Secret Kubernetes:
- Pembuatan versi: Secret dari Secret Manager diberi versi, sedangkan secret Kubernetes tidak.
- Payload: Rahasia dari Secret Manager berisi satu
[]byte
, sedangkan secret Kubernetes berisimap<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
danspec.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 Kubernetes | Tugas 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).