Apa yang Diajarkan Wawancara Kerja tentang Kubernetes

• Kubernetes diadopsi bahkan di perusahaan kecil bukan karena skalabilitas teknis, melainkan sebagai standar untuk menyelesaikan penyeragaman cara deployment dan persoalan operasional organisasi
• Dalam proses mencari kerja belakangan ini, semua perusahaan yang diajak bicara menggunakan Kubernetes, berbeda dengan 5 tahun lalu ketika VM·serverless·K8s masih hidup berdampingan
• Alasan utama yang disebut para CTO adalah bahwa setiap layanan bisa di-deploy dengan cara yang sama, pengetahuan operasional bisa ditinggalkan di YAML dan chart Helm, serta riwayat perubahan dapat dilacak lewat GitOps
• Perusahaan kecil menanggung kompleksitas Kubernetes bukan karena fitur lanjutan seperti HPA, Pod Disruption Budget, atau node affinity, tetapi karena keuntungan organisasional
• Untuk perusahaan tahap awal, lebih baik memulai tanpa Kubernetes agar bisa fokus pada produk, dan kebutuhan adopsinya membesar ketika CTO tidak lagi menangani engineering sendirian

---

Perubahan yang Terlihat dalam Pencarian Kerja Belakangan Ini

• Dari membaca lowongan, mengikuti wawancara, dan berbicara dengan sekitar dua belas tim engineering dalam proses mencari kerja belakangan ini, hasilnya adalah semua perusahaan yang diajak bicara menggunakan Kubernetes
• Saat mencari kerja 5 tahun lalu, ada kelompok yang jarang memakai Kubernetes, kelompok yang memakai systemd di atas VM/VPS/EC2, dan kelompok serverless seperti Lambda dan Cloud Run yang sama-sama ada
• Tempat kerja saat ini memang punya masalah berskala Big Tech sehingga Kubernetes jelas cocok, tetapi tetap mengejutkan bahwa startup beranggotakan 10 orang dengan hanya dua layanan juga memakai Kubernetes
• Perusahaan-perusahaan yang diajak bicara tidak menjalankan microservices atau lingkungan yang mendekati skala tinggi, dan mereka tidak terlalu tertarik pada sisi teknis Kubernetes

Alasan Adopsi Kubernetes dan Kriteria Penilaiannya

• Mengapa memakai Kubernetes

  • Alasan pertama adalah uniformity; jika semua layanan di-deploy dengan cara yang sama, tidak akan ada situasi di mana hanya satu layanan tertentu terikat pada skrip bash lama di bare VM atau Docker Compose
  • Alasan kedua adalah pengetahuan yang bisa dibagikan dan direkrut; karena Kubernetes dipakai seperti bahasa bersama, hanya dengan melihat chart Helm dan konfigurasi Kube, arsitektur dapat dipahami dengan cepat
  • Jika pengetahuan tersimpan di YAML, bukan di kepala seseorang, maka setelah orang itu pergi, penerusnya tidak perlu menghabiskan berminggu-minggu hanya untuk memahami cara menjalankannya
  • SRE on-call di perusahaan saat ini pun dapat memelihara layanan yang belum pernah dilihat sebelumnya karena pola Kubernetes serupa di tiap tim
  • Keuntungan ini hanya berlaku jika konfigurasinya tidak terlalu nyeleneh
  • Alasan ketiga adalah kemampuan pelacakan; alih-alih menjalankan kubectl apply -f langsung ke cluster, chart Helm diunggah ke git lalu perubahan melewati persetujuan MR dan deployment melalui FluxCD atau ArgoCD sehingga riwayat perubahan tersimpan
  • Alur seperti ini membantu kepatuhan hampir tanpa biaya tambahan karena GitOps dan Kubernetes memang saling cocok secara alami
  • Perusahaan saat ini lolos sertifikasi ISO dengan baik melalui cara ini

• Kesimpulan yang didapat

  • Pilihan para CTO bukanlah pilihan bodoh, melainkan cara untuk menyelesaikan masalah nyata
  • Kubernetes terlihat seperti solusi teknis untuk masalah teknis, tetapi banyak CTO ternyata lebih tertarik pada manfaat nonteknis daripada yang diperkirakan
  • Masalah teknis perusahaan kecil tidak selalu sampai memerlukan Kubernetes, dan kemungkinan besar manifest mereka tidak memiliki topologySpreadConstraints, HPA, Pod Disruption Budget, atau aturan node affinity
  • Mereka mempertahankan jumlah node yang kurang lebih sama seperti saat memakai VM, sambil menerima biaya operasional perangkat lunak yang kompleks demi keuntungan organisasional

• Mengapa peralihan ini terjadi belakangan

  • Lima tahun lalu, VM dengan systemd, serverless, dan Kubernetes sama-sama masih menjadi pilihan, tetapi sekarang dalam lowongan kerja kombinasi VM dan systemd hampir menghilang, serverless tetap menjadi ceruk, dan Kubernetes yang menang
  • Alasan waktu peralihannya tidak sepenuhnya pasti
  • Kemungkinan alasannya adalah managed Kubernetes seperti EKS, GKE, dan AKS sudah matang, dan jumlah orang yang mempelajari Kubernetes sudah cukup banyak sehingga merekrut untuk cara lain justru menjadi lebih sulit
  • Helm membuat opsi untuk langsung memakai chart buatan orang lain menjadi pilihan yang realistis

• Kapan akan memakai Kubernetes

  • Patokan pribadi adalah saat CTO tidak lagi menjadi satu-satunya engineer
  • Ketika engineer kedua bergabung, deployment harus bisa dilakukan oleh orang yang tidak menyiapkan server secara langsung, dan dibutuhkan kontrol akses yang semestinya alih-alih memberi kunci SSH untuk semuanya
  • Pada akhirnya seseorang akan meninggalkan perusahaan, dan pengetahuan operasional yang dimiliki orang itu juga bisa ikut hilang
  • Mulai dari titik ini, pengetahuan harus tersimpan di dalam sistem, bukan pada orang
  • Sebelum tahap itu, debugging cluster memang sulit dan energi yang seharusnya dipakai untuk produk bisa habis ke infrastruktur
  • Tepat sebelum panggilan dengan pelanggan besar, menghadapi pod yang masuk CrashLoopBackOff dan menghabiskan dua jam mencari penyebabnya bisa jadi lebih buruk daripada penanganan darurat yang cepat dan mudah dipahami seperti memperbaikinya buru-buru dengan git pull di VPS

[GN⁺]

Pendapat Lobste.rs

• Di Eropa, alasannya cukup jelas. Para CTO percaya bahwa kalau dijalankan di atas K8s, penyedia managed K8s bisa diganti dalam hitungan beberapa minggu
  Bukan berarti itu benar, tapi memang begitulah keyakinan mereka. Mereka juga menganggap environment PR jadi lebih mudah
  Namun inti utamanya adalah pergantian penyedia. Mereka memperkirakan dalam beberapa tahun ke depan akan ada larangan memakai penyedia yang terhubung dengan AS, terutama untuk GDPR, sistem keuangan, dan semacamnya. Jadi mereka bersiap menghadapi risiko itu

• Terlepas dari ukuran perusahaan, ini terlihat seperti bukti bahwa industri teknologi benar-benar kehilangan arah. Stack makin seragam dan kompleks, tetapi akibatnya justru makin sulit menemukan produk dan layanan yang bisa dipakai tanpa harus menggertakkan gigi

  • Layer tingkat rendah terlalu penuh bug dan terlalu rumit, sehingga untuk bisa bertahan, pada akhirnya orang terpaksa membuat sesuatu seperti Kubernetes. Kalau ingin mencegah stack terus meninggi, layer bawahnya harus dibuat lebih baik
    Kita butuh fondasi sistem operasi yang jauh lebih baik. Misalnya, container itu awalnya merupakan campuran berbagai fitur isolasi kernel tanpa desain yang konsisten, sehingga penuh celah
    Sekarang isolasi container memang sudah jauh lebih baik, tetapi itu hasil tambal-sulam ala whack-a-mole, bukan sesuatu yang sejak awal dirancang dengan keamanan dan kewarasan. Sampai kernel membereskan utang teknis raksasanya, atau ada yang membuat kernel yang layak untuk dipindahkan orang, kita akan terus menumpuk sesuatu di atasnya

• Alat deployment yang cukup kompleks pada akhirnya akan memuat setengah implementasi Kubernetes yang dibuat sebagai solusi sementara, didefinisikan secara tidak resmi, penuh bug, dan lambat

  • Istilah “setengah” itu tepat. Hanya saja setengah yang dimaksud kebetulan adalah setengah yang memang dibutuhkan
    Saya bisa panjang lebar menjelaskan bagaimana perusahaan SaaS e-commerce bernilai miliaran dolar ditata pada 2009, atau bagaimana backend online game multiplayer AAA berskala sangat besar dijalankan, dan keduanya jelas lebih mirip Kubernetes daripada deployment di satu mesin
    Tetapi mereka lebih cepat, dan punya opini yang kuat sesuai kebutuhan organisasi secara tepat, bukan dengan cara yang bentrok dengan kebutuhan produk
    Bagian “penuh bug” dari Kubernetes sering kali bukan berasal dari sistem intinya, melainkan dari banyaknya layer antarmuka yang kita tumpuk di atasnya agar berperilaku seperti yang kita mau
  • Ini berlaku untuk Erlang, bukan Kubernetes. Untuk Kubernetes sama sekali tidak masuk akal

• Masalahnya adalah kebanyakan organisasi mengadopsi K8s secara setengah-setengah, bahkan membentuk tim DevOps untuk mengelolanya, tetapi pada akhirnya tetap melempar semua pekerjaan penulisan, deployment, debugging, dan operasi terkait K8s ke software engineer
  Tim DevOps yang baik seharusnya memberikan pengalaman seperti Heroku secara internal. Orang cukup mendefinisikan resource yang dibutuhkan dan merge ke main, lalu deployment terjadi; bukan malah tersesat di dashboard GitOps/DevOps yang buruk sambil mencari tahu apa yang salah
  Heroku adalah puncak pengalaman pengembang, dan menurut saya setelah K8s kita kehilangan itu

  • Selain fakta bahwa kita bisa melihat Pod berjalan di node, saya tidak tahu apa perbedaan besar dalam pengalaman memakai Heroku dan Kubernetes
    Memang Heroku memberi pengalaman yang lebih terintegrasi, seperti koneksi database atau deployment lewat git push, tetapi membuat lapisan luar kustom di atas Kubernetes bukan ide bagus. Pada akhirnya semua parameter tetap diteruskan apa adanya

• Di industri ini, adopsi teknologi selalu berjalan dengan prinsip “rekrut seperti pakaian jadi, pecat bila tak dibutuhkan”. Ini hanya contoh terbarunya

• Kalimat “pengetahuan harus dimiliki sistem, bukan orang” merangkum dengan sangat baik sesuatu yang selama ini saya pikirkan samar-samar
  Formalisasi seperti ini hanya mungkin ketika variabilitas proses menurun. Orang melakukannya sendiri, mendokumentasikan prosesnya, membuat skrip, lalu mengotomatisasikannya
  Dalam workflow umum dari alat atau ekosistem populer, sebagian besar tahap ini hampir bisa didapat gratis

• Saya tidak banyak mengerjakan DevOps, dan saat ini sistem saya berjalan baik hanya dengan systemd dan container podman yang sesekali dipakai. Saya bekerja di bidang IoT/AgTech
  Tulisan ini punya nuansa “klaim” yang sering saya dengar dari eksekutif non-teknis. Kira-kira seperti, “Mereka juga pakai LoRa, kan? Berarti beres? Besok bisa rilis, kan?”
  Ada keyakinan bahwa ketidakseragaman adalah satu-satunya hambatan menuju sukses. Jika dua sistem memakai Fiber, Modbus, atau “punya API”, maka keduanya dianggap bisa langsung dihubungkan untuk menghasilkan pengalaman keren di mana “1 + 1 lebih besar dari jumlahnya”
  Tetapi hanya karena dua software sepakat pada standar interoperabilitas tingkat rendah, itu tidak berarti pekerjaan nyata untuk menentukan bagaimana data yang mudah di-parse itu harus ditafsirkan dan dipakai secara berguna otomatis hilang
  Hanya karena dua orang bisa berbicara dalam bahasa yang sama, bukan berarti tidak ada lagi pekerjaan yang harus dilakukan. Memakai bahasa bersama juga tidak menghapus keputusan-keputusan yang dibuat sebagian tim saat menggunakan alat itu berdasarkan kondisi yang mereka ketahui waktu itu
  Pada masa awal, Fortran adalah bahasa bersama di dunia sains/teknik, tetapi itu tetap tidak mencegah orang benar-benar bingung dengan pekerjaan rekan mereka atau harus menulis ulang semuanya
  Saya tidak keberatan dengan nilai K8s atau fakta bahwa sekarang ia menjadi “standar”. Namun saya sulit setuju dengan klaim bahwa itu membuat jenis masalah pemrograman tertentu menghilang. Hukum kekekalan kejelekan masih tetap berlaku

• Kubernetes adalah platform deployment yang cukup baik

• Bentuk distribusinya juga jadi alasan lain. Saya mengerjakan node Canton, dan perangkat lunak Canton upstream beserta aplikasi terkait disediakan sebagai chart Helm
  Terlepas dari apakah Kubernetes cocok untuk pekerjaan kami, dan menurut saya tidak, perangkat lunaknya memang didistribusikan dan didukung seperti itu. Kalau keluar dari jalur itu, pekerjaannya justru jadi lebih banyak daripada sekadar menangani Kubernetes

• Apa cuma saya yang merasa tulisan ini terdengar sangat seperti ditulis AI?
  Meski begitu, saya setuju dengan maksudnya. Saya sedang memindahkan setup homelab/self-hosting dari kondisi berisi konfigurasi systemd kustom, perintah shell yang sudah tidak saya ingat, dan “sial, prosedur konfigurasi itu saya tulis di file Markdown yang mana ya?”, dan rasanya benar-benar menyegarkan
  Saya memang belum memakai sistem continuous deployment yang sesungguhnya, tetapi rasanya menyenangkan mengetahui bahwa dengan satu skrip shell apply kecil dan sekumpulan file YAML, saya mungkin bisa memulihkan 90% keadaan bahkan setelah bencana
  systemd itu sederhana secara konsep, tetapi reproducibility-nya rumit; Kubernetes kebalikannya. Biaya konseptualnya lebih tinggi, tetapi reproducibility dan pemahaman yang mengikutinya jauh lebih kuat. Setidaknya untuk saat ini saya melihatnya begitu
  Saya masih berada di tahap tengah belajar Kubernetes, tetapi belakangan ini cukup senang memakainya

  • Sepuluh tahun lalu saya mungkin setuju, tetapi sekarang systemd juga terasa seperti “monster lain” karena beragam opsi namespace dan integrasi pengguna dinamis
    Integrasi vertikal dengan definisi kelas satu seperti ini terasa seperti arah yang salah
  • Apakah ini ditulis AI atau bukan sebenarnya tidak terlalu penting. Yang penting adalah apakah tulisannya bagus atau jelek