Google Cloud menawarkan dua platform utama untuk menjalankan aplikasi dalam container: GKE untuk menjalankan container di cluster Kubernetes, dan Cloud Run untuk menjalankan container langsung di infrastruktur Google Cloud. Namun, kapan Anda harus menggunakan salah satu dari keduanya? Dan apakah Anda dapat menggunakan keduanya? Halaman ini memberikan perbandingan antara kedua platform dan keunggulannya, serta membantu Anda mengetahui apakah strategi satu platform atau hybrid akan cocok untuk Anda.
Halaman ini dirancang untuk administrator infrastruktur dan operator aplikasi yang menjalankan berbagai kumpulan workload dalam container, dan ingin memanfaatkan kekuatan Google Kubernetes Engine (GKE) dan Cloud Run untuk men-deploy aplikasi ke Google Cloud Platform.
Sebelum membaca halaman ini, pastikan Anda memahami:
Workload stateless dan stateful
Mengapa menggunakan GKE dan Cloud Run bersama-sama?
GKE dan Cloud Run menawarkan berbagai keunggulan untuk menjalankan aplikasi dalam penampung, dan memenuhi berbagai tingkat kompleksitas beban kerja. Namun, Anda tidak perlu memilih antara kedua platform tersebut. Anda dapat secara bersamaan memanfaatkan keunggulan GKE dan Cloud Run dengan memigrasikan workload di antara kedua platform tersebut sesuai kebutuhan. Strategi campuran seperti ini dapat membantu Anda mengoptimalkan biaya, performa, dan overhead pengelolaan.
Berikut adalah beberapa manfaat penggunaan kedua runtime untuk men-deploy workload Anda:
GKE dan Cloud Run menawarkan tingkat portabilitas yang relatif tinggi:
Kedua platform menggunakan image container standar sebagai artefak deployment. Anda dapat menggunakan image yang sama untuk aplikasi di kedua platform tanpa perubahan apa pun, sehingga memungkinkan migrasi workload yang lancar antara GKE dan Cloud Run. Anda tidak perlu memperbarui penyiapan continuous integration untuk bermigrasi antara GKE dan Cloud Run selama image container disimpan di Artifact Registry.
GKE dan Cloud Run menggunakan model API deklaratif. Cloud Run Admin API v1 dirancang agar kompatibel dengan Kubernetes API. Artinya, Anda dapat menggunakan konsep Kubernetes yang sudah dikenal seperti Deployment, Layanan, dan autoscaler Pod horizontal untuk mengelola layanan Cloud Run. Kesamaan ini memudahkan penerjemahan konfigurasi antara kedua platform.
Resource direpresentasikan dalam file YAML dengan struktur deklaratif dan standar yang sama, sehingga dapat dengan mudah dimigrasikan antar-runtime. Berikut adalah contoh yang membandingkan file YAML deployment Kubernetes dan layanan Cloud Run.
GKE dan Cloud Run terintegrasi dengan lancar dengan Cloud Logging dan Cloud Monitoring, sehingga memberi Anda tampilan terpusat di konsol Google Cloud untuk mengamati metrik aplikasi, apa pun platformnya. Anda juga dapat menggunakan pemantauan tujuan tingkat layanan (SLO) di kedua platform, dan melihat tampilan terpadu SLO di dasbor Cloud Monitoring.
Anda dapat menerapkan continuous delivery ke resource GKE atau layanan Cloud Run menggunakan Cloud Deploy. Atau, jika Anda lebih suka, deploy aplikasi secara bersamaan ke GKE dan Cloud Run menggunakan deployment paralel.
Anda dapat memfasilitasi pengelolaan traffic lanjutan dengan menggunakan load balancer eksternal dan internal untuk layanan di GKE dan Cloud Run. Hal ini mencakup kemampuan untuk mengekspos endpoint eksternal sehingga Anda dapat men-deploy dan menjalankan URL yang berbeda untuk aplikasi yang sama di kedua platform. Anda juga dapat memisahkan traffic ke layanan yang sama di GKE dan Cloud Run, sehingga memungkinkan migrasi yang lancar dari satu platform ke platform lainnya.
Google Cloud menyediakan alat keamanan untuk meningkatkan postur keamanan Anda saat menggunakan kedua runtime tersebut. Pemindaian OS memungkinkan Anda memindai container untuk menemukan kerentanan sebelum men-deploy ke salah satu platform. Kebijakan Otorisasi Biner pusat dapat menerapkan integrasi dengan bidang kontrol GKE dan Cloud Run untuk mengizinkan atau memblokir deployment image berdasarkan kebijakan yang Anda tentukan. Dengan Kontrol Layanan VPC, tim keamanan dapat menentukan kontrol perimeter yang terperinci di seluruh resource GKE dan Cloud Run Anda.
Membandingkan GKE dan Cloud Run
Untuk memanfaatkan fitur terbaik GKE dan Cloud Run, serta mengetahui kapan harus memindahkan beban kerja di antara keduanya, penting untuk memahami perbedaan antara kedua layanan tersebut.
| Fitur | GKE | Cloud Run |
|---|---|---|
| Deployment dan pengelolaan | Mengelola cluster Kubernetes, termasuk konfigurasi node, jaringan, penskalaan, dan upgrade. Google Cloud mengelola infrastruktur yang mendasarinya dan menyediakan alat untuk menyederhanakan operasi cluster, tetapi Anda tetap bertanggung jawab atas aspek inti Kubernetes. |
Menjalankan container langsung di atas infrastruktur Google Cloud yang skalabel. Yang perlu Anda lakukan adalah menyediakan kode sumber atau image container, dan Cloud Run dapat mem-build container untuk Anda. Anda tidak perlu membuat cluster, atau menyediakan dan mengelola infrastruktur. |
| Kontrol dan fleksibilitas | Kontrol penuh atas cluster Kubernetes. Anda dapat membuat penyesuaian lanjutan pada konfigurasi node, kebijakan jaringan, setelan keamanan, dan add-on. |
Kontrol terbatas atas infrastruktur dasar. Anda dapat mengonfigurasi hal-hal seperti variabel lingkungan, konkurensi, dan koneksi jaringan, tetapi Anda tidak dapat menyesuaikan infrastruktur atau lingkungan yang mendasarinya. Ideal untuk kesederhanaan dan kecepatan. |
| Jenis aplikasi | Mendukung aplikasi stateless dan stateful, serta ideal untuk aplikasi kompleks dengan kebutuhan resource tertentu. | Paling cocok untuk layanan stateless, permintaan, atau berbasis peristiwa, layanan web, dan fungsi. |
| Model penetapan harga | Bayar per cluster per jam, terlepas dari mode operasi (Standar atau Autopilot), ukuran cluster, atau topologi. | Bayar per penggunaan, dibulatkan ke 100 milidetik terdekat. |
Kasus penggunaan
Anggaplah Anda adalah administrator platform dari perusahaan retail yang membangun platform e-commerce yang besar. Anda memiliki workload dalam container berikut untuk di-deploy:
Situs frontend dan aplikasi seluler: Aplikasi web stateless yang menangani penjelajahan, penelusuran, dan checkout produk.
Pengelolaan inventaris produk: Layanan stateful yang mengelola ketersediaan dan update produk.
Mesin rekomendasi: Layanan mikro kompleks yang menghasilkan rekomendasi produk yang dipersonalisasi untuk setiap pengguna.
Tugas pemrosesan batch: Mencakup tugas berkala seperti memperbarui katalog produk dan menganalisis perilaku pengguna.
Workload ini mewakili campuran layanan stateless dan stateful, sehingga Anda memutuskan untuk memanfaatkan GKE dan Cloud Run untuk performa yang optimal. Berikut adalah salah satu cara untuk menerapkan pendekatan campuran untuk workload Anda.
Setelah membaca kriteria untuk kesesuaian beban kerja Cloud Run, Anda memutuskan untuk menggunakan Cloud Run untuk situs dan aplikasi seluler, serta tugas pemrosesan batch. Men-deploy layanan ini di Cloud Run memiliki manfaat berikut:
Penskalaan otomatis saat lonjakan traffic dan tugas batch besar ditangani tanpa intervensi manual.
Efisiensi biaya dengan model bayar per penggunaan. Anda hanya membayar saat pengguna menjelajah atau check out, dan saat resource digunakan selama eksekusi tugas batch.
Deployment yang lebih cepat karena update tersedia secara instan, sehingga meningkatkan pengalaman pengguna.
Integrasi yang mudah dengan layanan Google Cloud lainnya. Misalnya, untuk pemrosesan berbasis peristiwa, Anda dapat menggunakan fungsi Cloud Run untuk memulai tugas pemrosesan batch di Cloud Run, dan mengaktifkan alur kerja yang lancar.
Pengelolaan inventaris produk adalah layanan stateful yang memerlukan kontrol terperinci dan berpotensi solusi penyimpanan kustom. Anda memutuskan untuk menggunakan GKE untuk men-deploy layanan ini karena menawarkan penyimpanan persisten dan memungkinkan Anda melampirkan volume untuk persistensi dan keandalan data produk.
Mesin rekomendasi adalah microservice kompleks yang mendapatkan manfaat dari GKE. Dengan GKE, Anda dapat mengelola dependensi yang kompleks, dan menerapkan kontrol terperinci atas alokasi dan penskalaan resource.
GKE paling cocok untuk arsitektur microservice yang kompleks, aplikasi stateful, workload yang memerlukan konfigurasi jaringan atau infrastruktur kustom, dan skenario yang memerlukan kontrol mendalam atas Kubernetes. Cloud Run paling cocok untuk aplikasi yang dipicu peristiwa. Layanan ini ideal untuk layanan web stateless, API, tugas batch, dan beban kerja lainnya yang mendapatkan manfaat dari harga bayar per penggunaan.
Contoh sebelumnya menunjukkan cara menggabungkan GKE dan Cloud Run untuk memberikan solusi yang andal dan fleksibel bagi platform e-commerce Anda. Anda mendapatkan manfaat dari kedua platform tersebut; efisiensi serverless untuk workload stateless, dan kontrol Kubernetes untuk komponen stateful dan microservice yang kompleks.
Pertimbangan
GKE dan Cloud Run saling melengkapi, yang memenuhi kebutuhan yang berbeda dalam lanskap aplikasi yang kompleks.
Berikut adalah beberapa pertimbangan saat mengadopsi pendekatan hybrid untuk men-deploy workload:
Jalankan microservice stateless di Cloud Run untuk efisiensi biaya dan skalabilitas.
Men-deploy aplikasi stateful kompleks yang memerlukan penyesuaian mendalam di GKE.
Jika menggunakan jaringan pribadi di Google Cloud, untuk mengakses resource di cluster GKE dari layanan Cloud Run, Anda dapat mengirim permintaan ke jaringan Virtual Private Cloud (VPC) menggunakan traffic keluar VPC Langsung. Untuk mengakses Layanan Kubernetes di cluster GKE, layanan Cloud Run harus terhubung ke jaringan VPC cluster, dan Layanan Kubernetes harus menggunakan Load Balancer Jaringan passthrough internal.
Untuk memigrasikan traffic antara Cloud Run dan GKE, Anda dapat mengekspos endpoint eksternal di balik Load Balancer Aplikasi eksternal Global. Saat menerapkan load balancer ini di depan layanan di kedua runtime, Anda dapat men-deploy aplikasi yang sama di Cloud Run dan GKE, sehingga Anda dapat secara bertahap mengalihkan traffic dari satu platform ke platform lainnya.
Untuk mengekspos layanan Cloud Run di Virtual Private Cloud di balik IP pribadi, gunakan load balancer internal.
Ingat, jika workload Anda sudah ada di Cloud Run, Anda selalu dapat bermigrasi ke GKE sesuai kebutuhan.
Kapan sebaiknya GKE dan Cloud Run tidak digunakan bersama-sama
Meskipun GKE dan Cloud Run menawarkan pendekatan yang menarik untuk banyak workload dalam container, ada situasi saat menggunakannya bersama-sama mungkin bukan pilihan terbaik. Berikut adalah beberapa contoh saat Anda mungkin memutuskan untuk tidak menggunakan pendekatan campuran:
Microservice yang terikat erat: Jika microservice Anda sangat bergantung satu sama lain dan memerlukan komunikasi latensi rendah yang sering, mengelolanya di seluruh platform terpisah dapat menimbulkan kompleksitas. Panggilan jaringan yang sering dilakukan antar-platform dapat menambah overhead dan potensi bottleneck, yang memengaruhi performa.
Aplikasi lama dengan dependensi kustom: Jika aplikasi Anda mengandalkan library, framework, atau konfigurasi tertentu yang tidak didukung oleh Cloud Run, penggunaannya untuk bagian aplikasi mungkin memerlukan pemfaktoran ulang atau solusi yang signifikan. Hal ini dapat menghapus manfaat serverless dan menyebabkan overhead pemeliharaan khusus platform.
Batasan anggaran dengan beban kerja yang dapat diprediksi: Jika beban kerja Anda memiliki persyaratan resource yang konsisten dan Anda memiliki anggaran yang ketat, model bayar per node GKE mungkin lebih hemat biaya daripada penagihan bayar per penggunaan Cloud Run. Jika memiliki beban kerja yang dapat diprediksi, Anda mungkin tidak sepenuhnya menggunakan manfaat penskalaan otomatis Cloud Run, sehingga biaya tetap GKE menjadi lebih menarik.
Pendekatan terbaik pada akhirnya bergantung pada kebutuhan dan prioritas spesifik Anda. Evaluasi dengan cermat persyaratan aplikasi, batasan resource, dan keahlian tim Anda sebelum memutuskan arsitektur GKE dan Cloud Run hybrid.
Langkah selanjutnya
Pelajari cara mengonversi layanan Cloud Run menjadi deployment Kubernetes di Bermigrasi dari Cloud Run ke GKE.
Kemas deployment Kubernetes Anda ke dalam penampung yang kompatibel dengan Cloud Run setelah mengikuti Bermigrasi dari Kubernetes ke Cloud Run.