Saya tidak membutuhkan Kubernetes, dan kemungkinan Anda juga tidak

Mengapa meninggalkan Kubernetes dan memilih Google Cloud Run

Latar belakang adopsi Kubernetes

• Pada platform pengeditan 3D online Clara.io yang diluncurkan pada 2013, infrastruktur dioptimalkan menggunakan server bare metal, tetapi pengelolaan perangkat keras dan pemantauan membutuhkan terlalu banyak pekerjaan.
• Pada proyek Threekit.com di 2018, dipilih Kubernetes. Saat itu Azure, AWS, Docker mengadopsi Kubernetes sebagai standar dan menjadikannya arus utama.

Keterbatasan Kubernetes

1. Masalah biaya:

   • Biaya dasar untuk membangun klaster cukup besar, termasuk node manajemen dan konfigurasi klaster yang redundan.
   • Autoscaling yang lambat membuat layanan perlu diprovisikan secara berlebihan, sehingga menimbulkan biaya untuk sumber daya yang tidak terpakai.

2. Sulitnya mengelola workload:

   • Penjadwalan pekerjaan rumit, dan scheduler bawaan maupun Argo tidak efisien untuk pekerjaan dalam jumlah besar.

3. Beban kompleksitas:

   • Fitur yang sangat kaya membuat tugas sederhana pun menjadi rumit.
   • Dibutuhkan personel DevOps khusus untuk mengelola Kubernetes, yang berujung pada kenaikan biaya.

Beralih ke Google Cloud Run

Cloud Run menggantikan kompleksitas Kubernetes dengan lingkungan yang lebih sederhana dan hemat biaya.

Pengaturan baru

• Infrastruktur berbasis container Docker:
  • Mencakup layanan autoscaling dan container untuk pekerjaan yang berjalan jangka panjang.
  • Cloud Run mengotomatiskan deployment container, scaling, pengelolaan downtime, dan eksekusi pekerjaan.

Keunggulan Cloud Run

1. Efisiensi biaya:

   • Biaya dikenakan berdasarkan waktu penggunaan CPU dan memori.
   • Layanan yang idle tidak menimbulkan biaya.
   • Contoh: situs Web3D Survey dapat menangani 500.000 kunjungan per bulan dengan biaya $4/bulan.

2. Autoscaling yang cepat dan stabil:

   • Scaling terjadi dalam hitungan detik, lebih cepat daripada Kubernetes.
   • Lonjakan permintaan dapat ditangani dengan cepat.

3. Tanpa beban pengelolaan Kubernetes:

   • Cloud Run berbasis Borg milik Google, sehingga tidak perlu mengelola klaster Kubernetes.

4. Pekerjaan asinkron yang sederhana:

   • Dengan Cloud Run Tasks, retry otomatis dan eksekusi pekerjaan dalam jumlah besar menjadi mudah.

Masalah potensial Kubernetes: lock-in klaster

• Jika bergantung pada fitur-fitur Kubernetes, integrasi atau ekspansi ke sumber daya di luar klaster menjadi sulit.
• Hal ini dapat menimbulkan ketergantungan pada infrastruktur tertentu, sehingga ekspansi dan migrasi menjadi lebih rumit dan mahal.

Pertanyaan umum tentang penggunaan Cloud Run

“Apakah ketergantungan pada GCP tidak mengkhawatirkan?”

• Dengan pengaturan berbasis Docker, migrasi ke cloud lain seperti AWS dapat dilakukan dalam sekitar 1 minggu.
• Dalam praktiknya, selain faktor politik, jarang ada kasus pergantian penyedia cloud.

“Bukankah Cloud Run pada akhirnya juga Managed Kubernetes?”

• Cloud Run menggunakan antarmuka Knative, tetapi berjalan di atas Borg milik Google, bukan Kubernetes.
• Cloud Run menghilangkan kompleksitas Kubernetes dan menyediakan antarmuka yang lebih sederhana.

Kekurangan alur kerja saat ini

1. Kurang praktis dalam mengelola nama layanan:

   • Diperlukan lapisan abstraksi untuk menjaga konsistensi konfigurasi di lingkungan lokal dan server.
   • Tidak ada fitur pengelolaan nama seperti di Kubernetes.

2. Kurangnya emulasi Cloud Run Task:

   • Saat mengembangkan pekerjaan secara lokal, tidak ada lingkungan emulasi sederhana yang mencakup penangkapan dan pelacakan output log.

Kesimpulan

• Cloud Run adalah solusi yang optimal dari sisi biaya, kecepatan, skalabilitas, dan kesederhanaan
• Untuk perusahaan besar atau kebutuhan yang kompleks, Kubernetes bisa berguna, tetapi
• Untuk proyek yang mengutamakan kesederhanaan dan efisiensi, Cloud Run jauh lebih praktis
• PS: Menambahkan ekstensi tertentu ke Kubernetes mungkin bisa menyelesaikan masalah, tetapi itu hanya akan menambah kompleksitas, dan saya tidak ingin bergantung pada lingkungan Kubernetes yang melampaui kebutuhan sederhana

[blurblah]

Memang tidak ada silver bullet. Yang penting adalah menggunakannya dengan baik sesuai situasi, haha.
Kalau Kubernetes diadopsi tanpa kritik hanya karena sedang tren, itu bisa membuat segalanya jadi lebih sulit. Meski begitu, saya tetap menganggapnya alat yang cukup bagus untuk lingkungan dengan skala yang agak besar.
Bahkan kalau sudah diadopsi, kalau cuma sampai tahap adopsi lalu selesai, kemungkinan besar tidak akan bisa dimanfaatkan dengan baik.
Dan seperti alat apa pun, itu tidak akan bisa memenuhi 100% kebutuhan developer atau pengguna, jadi menurut saya otomatisasi pada tingkat yang tepat tetaplah hal yang wajib.

[bungker]

Kubernetes itu setelah selesai dibangun tinggal menikmati hasil saja ... sob

[riki3]

Kubernetes adalah mata pencaharian saya, dan dulu ada masa ketika saya yakin inilah jawaban yang benar.
Namun seiring waktu, saya mendapati diri sendiri mengalami banyak masalah dan membuang-buang waktu.

Saya merekomendasikan k8s kepada orang lain, tetapi sepertinya saya tidak akan menggunakannya untuk layanan saya sendiri. Bukan cuma k8s, saya bahkan sudah lelah dengan container secara umum.

[joon14]

Kalau sedang menggunakan AWS, apakah bisa dianggap mirip dengan ECS?

[tujuc]

Ya, kurang lebih begitu. :)

[eclipsense]

Yang salah itu tidak bisa memakai Kubernetes; jadi agak kurang tepat kalau dibilang Kubernetes itu kurang bagus.

[tujuc]

Saya juga punya pemikiran yang mirip dengan penulis.
Skala perusahaan kami juga belum sampai tahap membutuhkan kube.

Saya sempat berpikir semua developer akan bisa mengelola semuanya dengan menggunakan Kube.
Tapi ternyata lebih baik memberi panduan agar mereka bisa membangun infrastruktur dan menyelesaikan masalah setidaknya pada tingkat yang memadai dibanding rata-rata developer di perusahaan...

[doolayer]

???: Saya tidak memerlukan AI, dan Anda mungkin juga tidak memerlukannya.

[ilbanin00]

Produk apa pun pasti punya bagian-bagian yang merupakan trade-off.

[bbulbum]

Karena saya memakai layanan managed, saya sendiri tidak terlalu merasa kesulitan dalam pengelolaannya,,
Alat apa pun akan berguna jika digunakan secukupnya, tetapi saya merasa Kubernetes secara khusus sering dikritik terutama karena "memungkinkan konfigurasi yang kompleks".

[tujuc]

Karena ini adalah teknologi yang bisa membuat hampir semua hal sesuai keinginan saya... :) Mungkin karena sering digunakan dengan cara yang rumit, hahaha...

[GN⁺]

Pendapat Hacker News

• Mengungkapkan keluhan terhadap "teknologi cloud", dan menyebutkan bahwa saat menggunakan Kubernetes, banyak waktu habis untuk mengubah file YAML dan menyelesaikan error. Ia berpendapat ingin menghindari integrasi cloud dan menyiapkan server sendiri

• Kubernetes menimbulkan biaya infrastruktur yang besar selain waktu untuk DevOps dan administrasi. Disarankan bahwa menggunakan Kubernetes terkelola dari penyedia cloud lebih efisien

• Kubernetes bukan alat orkestrasi kontainer, melainkan alat untuk membangun klaster komputer, dan jika tidak membutuhkan klaster, maka tidak perlu menggunakan Kubernetes

• Investasi berlebihan pada DevOps mulai berkurang, dan dibagikan sudut pandang yang kritis terhadap Kubernetes. Ditekankan bahwa untuk startup kecil, satu server saja bisa cukup

• Hal-hal yang perlu diperhatikan saat menggunakan Cloud Run mencakup batas koneksi TCP, pemilihan lingkungan eksekusi, dan pengaturan autoscaling

• Cloud Run cocok untuk startup kecil, tetapi ditunjukkan bahwa ia kekurangan kontrol firewall yang merupakan elemen dasar arsitektur keamanan. Dijelaskan bahwa pada akhirnya VPC akan dibutuhkan

• Dinyatakan bahwa perbandingan antara Google Cloud Run dan Kubernetes tidak adil, lalu dijelaskan kelebihan dan kekurangan masing-masing. Ditekankan bahwa Kubernetes cocok untuk pekerjaan yang kompleks

• Dijelaskan bahwa Kubernetes memiliki kurva belajar yang curam, tetapi merupakan alat yang kuat jika digunakan dengan tepat

• Tidak setuju dengan kritik terhadap Kubernetes, dan menekankan bahwa saat men-deploy aplikasi yang kompleks, Kubernetes API mungkin diperlukan

• Dijelaskan bahwa kompleksitas Kubernetes terutama muncul dari pekerjaan administrasi sistem, sementara Kubernetes sendiri stabil

• Ditunjukkan bahwa IaC dan CM seharusnya mengurangi konfigurasi dan memudahkan pengelolaan, tetapi pada praktiknya justru membutuhkan lebih banyak usaha. Dalam banyak kasus Kubernetes tidak diperlukan, dan administrator sistem yang baik lebih penting