Sahabatku tersayang, kamu telah membangun Kubernetes

• Surat untuk seorang teman

  • Menjelaskan bahwa meskipun berusaha menghindari Kubernetes, pada akhirnya tetap membangun sistem yang serupa.
  • Sang teman memilih "teknologi yang membosankan" dan menginginkan eksekusi container yang sederhana, tetapi pada akhirnya mengalami masalah akibat skrip dan konfigurasi yang rumit.
  • Bahkan setelah beralih ke Docker Compose, tidak semua masalah dapat diselesaikan, dan disadari bahwa tetap dibutuhkan solusi terpisah untuk deployment, rolling update, rollback, dan scaling.

• Perluasan server dan kompleksitas jaringan

  • Muncul kebutuhan untuk berkembang ke server kedua.
  • Mencoba service discovery dengan menggunakan overlay network seperti Tailscale.
  • Berupaya menyelesaikan kompleksitas jaringan, tetapi pada akhirnya justru menghadapi lebih banyak masalah.

• Pemeliharaan dan otomatisasi

  • Muncul pertanyaan: jika orang yang membuat skrip itu sedang cuti atau keluar dari perusahaan, siapa yang akan mengelola konfigurasi rumit dan perubahan pengaturan yang tidak terdokumentasi?
  • Untuk mengatasi masalah pemeliharaan skrip kustom, VM dibuat immutable dan dapat dikelola versinya dengan menggunakan Ansible.
  • Mereka berpikir bahwa karena tidak menggunakan Kubernetes, sistem itu akan lebih mudah dipelihara.

• Pemunculan container dan masalah keamanan

  • Muncul kebutuhan untuk secara terprogram membuat container lain.
  • Me-mount Docker socket ke web app berisiko dari sisi keamanan, sehingga ditulis layanan terpisah untuk mengatasinya.
    • Masalah tersebut diselesaikan dengan menulis layanan terpisah yang hanya mengekspos bagian aman dari Docker API.

• Kesimpulan

  • Pada akhirnya mereka menyadari bahwa yang dibangun adalah sistem yang mirip dengan Kubernetes.
    • Sebuah sistem kompleks pun selesai dibangun, lengkap dengan format konfigurasi standar, metode deployment, overlay network, service discovery, node immutable, dan API server

• PS

  • Ini bukan berarti menolak kemungkinan adanya solusi yang lebih baik untuk menggantikan Kubernetes.
  • Hanya saja, sebelum menyimpulkan bahwa Kubernetes itu rumit, disarankan untuk benar-benar memahami masalah yang sedang coba diselesaikannya.

[savvykang]

Saya agak tidak paham dengan cerita tentang memperkenalkan Kubernetes untuk menyelesaikan serah terima deployment.

[kandk]

Pemeliharaan dan otomatisasi dapat dilakukan dengan mudah pada level kode.
Infra as code juga dimungkinkan.

[savvykang]

Di lingkungan layanan k8s terkelola seperti EKS, memang ada load balancer dan bisa terintegrasi dengan Route 53, tetapi pada k8s yang di-host sendiri ternyata tidak ada implementasi load balancer dan integrasi DNS juga terbatas. Di perusahaan yang memang punya tim pengelola k8s tersendiri, mungkin saja kelebihan yang Anda sebutkan itu memang berlaku.

Sekilas terdengar seperti solusi yang bagus, tetapi saat benar-benar dipakai, ternyata tidak bekerja di semua situasi.

[kandk]

Mudah digunakan bahkan tanpa tim pengelola k8s. Jika memakai EKS, itu sudah cukup.

[savvykang]

Bukankah ini sama saja dengan klaim bahwa serah terima kerja selesai hanya dengan memberikan source code? Menurut saya, manual kerja dan riwayat pelaksanaan pekerjaan tetap diperlukan.

[kbumsik]

Infrastructure as Code memang pada dasarnya ada agar cukup dengan memberikan source code saja semuanya selesai.
Tentu saja, seperti halnya kode apa pun, dokumentasi dasar tetap harus tersedia.

[kandk]

Kalau source code-nya ditulis dengan rapi dan dokumentasinya bagus, itu memungkinkan.
Kalau ada manual kerja dan riwayat pelaksanaan pekerjaan secara terpisah tentu akan membantu, tetapi rasanya itu cerita yang berbeda dari tulisan ini.

[GN⁺]

Komentar Hacker News

• Ada pengalaman di beberapa perusahaan yang berhasil melakukan deployment menggunakan skrip shell

  • Dengan 2 layanan PHP, menangani lebih dari 1 miliar request per hari, dan deployment dilakukan tanpa downtime dengan mengirim file ke server lalu menjalankan migrasi
  • Di industri yang tidak membutuhkan skala web seperti akun pensiun, deployment dilakukan lewat perintah Docker di Jenkins
  • Lingkungan pengujian bisa disiapkan sesuai kebutuhan dalam hitungan menit
  • Perusahaan saat ini mencoba mengadopsi Kubernetes, tetapi kesulitan karena kompleksitasnya

• Kubernetes membutuhkan dua atau tiga staf khusus hanya untuk mengelola file YAML

  • Jika memilih penyedia cloud, bagian yang rumit bisa ditangani, tetapi ada biaya tambahan
  • File YAML adalah file konfigurasi yang seharusnya dihasilkan oleh alat, bukan ditulis manusia
  • Kebanyakan situs web dan layanan tidak membutuhkan Kubernetes

• Gagasan bahwa hal yang sederhana itu rapuh adalah keliru

  • Jauh lebih sulit memahami dan men-debug kompleksitas YAML dan Kubernetes
  • Salah satu alternatif Kubernetes adalah skrip shell

• Ada juga kasus ketika Kubernetes memang tidak diperlukan

  • Dengan instance EC2 dan skrip shell sederhana, bisa menangani lebih dari 100.000 pengguna serentak
  • Jika tidak ada masalah, tidak perlu mengubahnya hanya demi perubahan

• Dengan skrip shell, aturan iptables dan pengeditan sysctl bisa dikelola dengan mudah

  • Dengan menggunakan antrean pekerjaan, tugas bisa didorong alih-alih membuat container secara terprogram

• Mengkritik Kubernetes dianggap tidak profesional

  • Jika bukan aplikasi berskala besar seperti Google atau Netflix, lebih baik menulis skrip yang sederhana

• Anggapan bahwa semua keterbatasan sistem buatan sendiri adalah biaya, dan bahwa semua fleksibilitas solusi umum adalah keuntungan, adalah keliru

  • Ingin mengikuti pola yang serupa di codebase dan ingin layanan di-deploy dengan cara yang sama

• Masalah Kubernetes adalah begitu banyak library open source membuat sistem sulit dipahami dan memicu bug

• Orang yang sudah melewati kurva belajar Kubernetes mengatakan bahwa kompleksitasnya tidak separah itu

  • Kelas untuk mengajarkan Kubernetes kepada developer memakan waktu sekitar 30 menit dan membuat mereka bisa menulis chart Helm