- Kubernetes telah memimpin inovasi orkestrasi kontainer selama 10 tahun terakhir
- Berbagai keterbatasan dan kebutuhan perbaikan terlihat pada konfigurasi YAML, ketergantungan pada etcd, pengelolaan paket Helm, dan lainnya
- Adopsi HCL, penyimpanan plug-in, manajer paket baru (KubePkg), IPv6 sebagai default, dan lain-lain dibahas sebagai elemen perubahan untuk Kubernetes 2.0
- Struktur terbuka saat ini tetap penting, tetapi default dan arahan resmi memiliki dampak yang menentukan terhadap inovasi ekosistem
- Kubernetes dinilai perlu menjadi lebih cocok bagi pengguna dan organisasi yang lebih luas melalui perbaikan disruptif yang berkelanjutan
10 tahun Kubernetes: keberhasilan dan keterbatasan
Awal dan pertumbuhan
- Pada 2012–2013, rumor tentang Borg, sistem kontainer Linux internal Google, mulai menyebar di komunitas sysadmin
- Pada 2014, Kubernetes diumumkan ke publik, dan pada awalnya bahkan namanya pun sulit diucapkan
- Perusahaan besar seperti Microsoft, RedHat, IBM, dan Docker cepat bergabung, sehingga Kubernetes mulai memantapkan posisinya sebagai standar ekosistem
- Pada 2015, rilis v1.0 dan lahirnya CNCF menandai terbentuknya ekosistem terbuka secara penuh
Titik inovasi utama
Pengelolaan kontainer dalam skala besar
- Kubernetes menghadirkan skalabilitas untuk pengembangan dan deployment perangkat lunak berbasis kontainer
- Dari lingkungan pengembangan sederhana hingga deployment lingkungan seragam berskala besar di ribuan server menjadi mungkin
- Organisasi pun mendapat momentum untuk beralih dari arsitektur monolitik ke microservices yang terdistribusi
Pemeliharaan berbiaya rendah dan self-healing
- Pengelolaan server berubah drastis dari era "Simpsons" (setiap server diberi nama panggilan, dioperasikan manual) ke era "UUID" (penggantian penuh, otomatisasi, stateless)
- Konsep umur mesin dan masa dukungan OS nyaris menghilang; saat terjadi gangguan, sistem dikonfigurasi ulang secara otomatis dengan "membuat ulang node"
- Banyak keterampilan Linux kini berubah dari syarat wajib menjadi sekadar nilai tambah
Batch job dan pengelolaan Job
- Pemrosesan batch yang dulu bergantung pada "box khusus cron" kini digantikan oleh pekerjaan otomatis berbasis antrean dan mekanisme retry
- Restart otomatis saat job gagal dan penanganan yang fleksibel sangat meningkatkan efisiensi operasional dan kepuasan developer
Service discovery dan load balancing
- Alih-alih hardcoding alamat IP, Kubernetes memperkenalkan skema penamaan layanan berbasis DNS internal
- Koneksi antar-layanan disederhanakan melalui API, IP tetap, dan hostname, dan layanan eksternal pun bisa diperlakukan seperti layanan internal
Kubernetes 2.0: usulan perbaikan utama
Dari YAML ke HCL, mengganti bahasa konfigurasi
Keterbatasan YAML
- YAML memang mudah dibaca dan tampak lebih baik daripada JSON atau XML, tetapi memiliki masalah serius seperti mudah menimbulkan kesalahan, tidak mendukung tipe dengan baik, dan sulit di-debug
- Contoh: masalah Norwegia (
NO ditafsirkan sebagai false), error indentasi, kebingungan antara string dan angka, dan banyak sumber gangguan lainnya
Alternatif: adopsi HCL
- HCL(HashiCorp Configuration Language) adalah format standar Terraform yang menawarkan fitur unggul seperti strong typing, validasi, fungsi, dan percabangan kondisi
- Saat ini cukup banyak cluster Kubernetes yang sudah memanfaatkan HCL bersama Terraform
- HCL memiliki kemampuan yang lebih kuat daripada YAML, termasuk keamanan tipe, pengurangan duplikasi, konfigurasi dinamis, pemrosesan berulang, logika kondisional, dukungan komentar yang sangat baik, modularitas, dan validasi
- Masalah lisensi open source (MPL 2.0 → kompatibilitas dengan Apache 2.0) masih ada, tetapi nilainya untuk meningkatkan kualitas dinilai cukup besar
Contoh: HCL vs YAML
- Berkat keunggulan HCL dalam hal tipe, variabel, fungsi, kondisi, dan perulangan, kesalahan konfigurasi bisa dicegah lebih awal, pemeliharaan menjadi lebih baik, dan konsistensi tetap terjaga bahkan di lingkungan yang kompleks
Dukungan opsi pengganti etcd
- etcd memang kuat, tetapi pada cluster kecil atau lingkungan berspesifikasi rendah, konsumsi sumber dayanya bisa berlebihan
- Melalui dukungan resmi untuk backend plug-in seperti Kine, muncul kebutuhan untuk memperluas fleksibilitas penyimpanan default
- Contoh: k8s-dqlite: menyediakan lapisan data yang ringan dan fleksibel dengan SQLite terdistribusi + Raft
Melampaui Helm: manajer paket native
Keterbatasan Helm
- Helm adalah contoh solusi hack sementara yang kemudian menjadi standar, namun memiliki berbagai masalah seperti kompleksitas template, sulit di-debug, konflik dependensi/versi, dan kurangnya validasi
- Duplikasi chart, ketidaksesuaian versi, sulitnya instalasi lintas namespace, ketiadaan pencarian chart/metadata, ketidakpatuhan pada semantic versioning, dan pengelolaan CRD yang tidak aman menimbulkan banyak kesulitan dalam penggunaan nyata
Usulan sistem paket baru: KubePkg
- Mengelola paket, dependensi, semantic versioning, keamanan, siklus hidup, hingga metadata secara menyeluruh dalam bentuk resource Kubernetes
- Dilengkapi hook lifecycle yang canggih, strategi state serta backup/recovery, konfigurasi deklaratif, proses penandatanganan yang dapat diverifikasi, catatan audit, dan kontrol kebijakan organisasi
- Tujuannya adalah mewarisi keunggulan manajer paket Linux untuk menghadirkan keandalan dan konsistensi yang kuat bagi pengelolaan infrastruktur nyata
Persyaratan utama
- Struktur resource yang sepenuhnya native Kubernetes
- Dukungan bawaan untuk aplikasi berbasis state
- Penguatan proses penandatanganan/validasi/pemindaian keamanan
- Konfigurasi deklaratif terstruktur + validasi skema
- Kontrol penuh siklus hidup dan dukungan Upgrade/Hook yang mudah
- Resolusi dependensi/versi ala Linux
- Riwayat perubahan dan audit trail
- Kemampuan menerapkan kebijakan per organisasi
- UX pengelolaan paket Linux yang familier
Peralihan default ke IPv6
- Saat ini IPv6 dan dual-stack sudah didukung, tetapi default masih IPv4
- Ini memiliki keunggulan dalam menyelesaikan komunikasi antar-cluster, masalah NAT, dan kekurangan IP, sekaligus menghadirkan struktur jaringan yang lebih sederhana dan IPSec bawaan
- Di lingkungan yang membutuhkan banyak IP (contoh: blok /20, 40 node, 30 pod per node), batas IPv4 cepat tercapai
- Ada manfaat praktis yang jelas seperti penyederhanaan operasional di lingkungan IPv6 publik, menarik lebih banyak pengguna cloud, dan mengurangi beban pengelolaan ruang alamat privat
Kesimpulan: perlunya perubahan dan kekuatan default
- Ada pendapat bahwa karena ini platform terbuka, komunitas akan mengurusnya sendiri, tetapi default justru membentuk pola perilaku industri
- Untuk Kubernetes 2.0, kini saatnya menghadirkan keyakinan resmi, desain yang unggul, dan default yang kuat
- Sebagai standar industri dan arus utama operasional data center global, ini adalah momen penting untuk melakukan lompatan baru yang segar
- Di berbagai ranah teknologi seperti mobile dan web, perubahan berani telah berulang kali memicu inovasi seluruh ekosistem
- Kini Kubernetes juga berada pada titik untuk memikirkan tahap berikutnya melalui 2.0 yang monumental
2 komentar
Sepertinya insinyur yang bisa menyusun dan mengoperasikan vanilla k8s yang dirakit dengan menggabungkan berbagai open source akan tetap menjadi minoritas ke depannya.
Sama seperti sangat sedikit insinyur yang mampu mengoperasikan ekosistem Hadoop versi vanilla tanpa membeli cluster Hadoop yang dibundel sebagai platform Cloudera.
Komentar Hacker News
Saya rasa masalah terbesar Kubernetes adalah bahwa ini bukan sistem yang “langsung jalan begitu saja”. Hanya sedikit engineer yang benar-benar bisa mengoperasikan layanan di production tanpa hambatan, dan membangun serta memelihara cluster Kubernetes sendiri di atas VM bahkan jauh lebih sulit. Karena itu, startup serverless yang sedang naik daun muncul dari persepsi bahwa Kubernetes itu (1) memakan banyak waktu, (2) sangat rawan error, dan (3) punya peluang gagal tinggi di lingkungan production. Menurut saya, Kubernetes 2.0 harus mengarah ke platform deployment yang bisa di-self-host dengan mudah oleh siapa pun dan dipakai dengan percaya diri, sambil tetap mempertahankan core orchestrator yang kecil namun kuat. Saya sedang mengembangkan sendiri orchestrator dan platform deployment bernama Rivet, dan meski menonjolkannya sebagai platform serverless open source Rivet, saya sendiri sering memikirkan, “seperti apa Kubernetes 2.0 itu?” Semakin banyak juga kasus orang mengadopsi Rivet untuk skenario yang melampaui ekspektasi kami. Kekuatan terbesar Rivet adalah kemudahan untuk mengembangkan fitur setingkat Kubernetes controller, sehingga bisa dipakai untuk berbagai skenario seperti game server, deployment per-tenant, orkestrasi workload tingkat lanjut, multi-tenancy, billing per-tenant, hingga desain operator yang kuat.
Sudut pandang seperti ini cukup bikin saya kurang suka. Mungkin karena saya sudah agak tua dan sedikit sinis, tapi ini pola yang sering sekali terlihat. Ada teknologi X yang terlalu berat, lalu seseorang bilang, “Saya cuma ingin menjalankan ini dengan sederhana di laptop tanpa semua itu,” lalu membuat teknologi Y. Kemudian Y juga jadi populer, dan saat mulai dipakai bukan di laptop melainkan di lingkungan nyata, ia butuh skalabilitas dan akhirnya ditambahi banyak fitur sampai jadi berat. Lalu ada lagi yang bilang, “Sekarang Y juga terlalu berat,” dan mengulang hal yang sama. Ini seperti 'roda waktu', cerita yang terus berulang tanpa awal maupun akhir.
Kenyataannya, k3s (k8s ringan) memang sangat mudah dirawat. Dengan auto-update k3s dan aturan eviction yang tepat, nyaris tidak perlu disentuh, dan kalau storage seperti Ceph terasa sulit, ada alternatif “nyaris tanpa pengelolaan” seperti Lemon atau Longhorn. Ada ribuan Helm chart, jadi database yang rumit pun bisa langsung dideploy dalam 1 menit. Deployment layanan juga sangat mudah kalau hanya memakai template Helm yang umum. Helm memang tidak sempurna, tetapi kalau diatur sesuai kebutuhan, Anda tetap bisa menikmati fitur seperti pelengkapan nilai. Memang hambatan masuknya sedikit lebih tinggi daripada serverless, tetapi belajar seminggu lalu menghemat puluhan juta rupiah di production jelas sangat layak.
Masalah yang diselesaikan Kubernetes adalah, “Bagaimana saya mendeploy ini?” Saat melihat docs Rivet, yang ada hanya single container, Docker Compose, dan deployment manual (perintah Docker). Secara realistis, saya ragu apakah infrastruktur serverless pada skala nyata bisa dideploy seperti itu. Pertanyaan pertama saya adalah, “Kalau sudah sampai tahap ini, bukankah Rivet bisa dijalankan di atas Kubernetes saja (container, kube-virt, dan sebagainya)?” Saya tidak yakin Docker Compose bisa lebih kokoh atau lebih scalable daripada Kubernetes. Kalau tidak, dan yang dijual adalah layanan cloud, itu juga tidak cocok dengan konsep Kubernetes 2.0. Kalau saya yang self-host Rivet, saya mungkin akan mengubah dokumentasinya agar bisa dijalankan di Kubernetes.
Jika memakai “k8s as a service” yang meng-outsource pemeliharaan cluster ke vendor cloud, saya penasaran bagian mana yang terasa begitu rumit. Cakupan konfigurasinya memang luas, tetapi untuk konfigurasi layanan yang benar-benar akan dilepas ke production, biasanya cukup tahu sedikit setting saja. Dengan konfigurasi yang hanya sedikit lebih rumit daripada Docker Compose, aplikasi sudah bisa dideploy ke k8s. Namun untuk sebagian besar aplikasi, bahkan “sedikit lebih” itu mungkin juga tidak perlu. Sebenarnya inilah kebutuhan massal yang dulu ingin dijawab Docker Compose, dan sayang sekali ia tidak mendapat perhatian berkelanjutan.
Dalam operasi infrastruktur, menurut pengalaman saya, sesuatu yang “langsung jalan begitu saja” itu tidak akan pernah ada. Heroku pun punya masalah saat melakukan scaling. Kalau ingin platform deployment yang mudah diadopsi semua orang, akan lebih realistis memahami Kubernetes sebagai primitive dasar bagi PaaS tertentu. Rivet menarik karena unik dan menunjukkan beberapa ide dari ekosistem BEAM. Secara pribadi, saya lebih tertarik pada ketangguhan dan pendekatan local-first daripada deployment skala besar.
“Low maintenance” ya... Saya cukup sering memakai EKS (managed k8s), dan saya memang tidak perlu terlalu memikirkan kondisi cluster itu sendiri (tentu saja terpisah dari cara-cara kreatif saya sendiri untuk merusak node). Kubernetes benar-benar berpura-pura sebagai sesuatu yang “sebisa mungkin minim perawatan”, padahal pada kenyataannya ia adalah gumpalan maintenance murni. Fakta bahwa kita bisa langsung mendeploy software ke dunia hanya dengan menyerahkan yaml itu memang luar biasa. Tapi harga yang dibayar adalah maintenance yang rumit. Menyetel cluster, inisialisasi ArgoCD, mendaftarkan cluster lain dalam model hub-and-spoke, semua itu baru satu babak sirkus. Lalu masih ada pemasangan operator yang layak pakai dari tooling CNCF Landscape, serta tool pendamping lain (secara teknis bukan primer, tetapi wajib) sampai sekitar 30 buah berjalan. Menyetel values.yaml juga tidak selesai dalam satu-dua jam, dan sebagian besar waktu habis di ArgoCD dan pekerjaan template. Dari Secrets Manager -> External Secrets -> ArgoCD ApplicationSet -> values.yaml lain lagi, bahkan untuk meneruskan satu nilai boolean saja sering menghabiskan banyak waktu. Siklus update cluster/operator juga cepat, jadi masalah maintenance selalu ada terus-menerus. Saat autoscaling dengan Karpenter, penggantian node dan zero-downtime jadi pertunjukan akrobat lagi (aplikasi stateful di k8s itu keseruannya dua kali lipat). Ringkasnya: “Low maintenance” itu benar-benar ungkapan ironis.
“Low maintenance” pada akhirnya adalah konsep yang relatif terhadap alternatifnya. Dalam pengalaman saya, saat memakai k8s, beban maintenance untuk mendapatkan layanan dengan kualitas yang sama jauh lebih rendah secara keseluruhan: scaling, failover, rollback, disaster recovery, DevOps, spin-up cluster independen, dan sebagainya. Mungkin tergantung situasi, tetapi itulah pengalaman saya.
Saya sudah memakai k3s di hetzner selama 2 tahun terakhir, dan mengalami uptime 100%. Beban maintenance-nya sangat rendah sampai-sampai saya pernah kehilangan kunci SSH master node, tetapi melakukan reprovision seluruh cluster hanya memakan 90 menit termasuk memperbarui dokumentasi. Kalau benar-benar mendesak, mungkin 15 menit pun cukup. Saat ini saya menjalankan cluster k8s seharga 20 euro per bulan dengan ARM-based 3-node 1-master, sedikit storage, dan DNS otomatis terhubung dengan Cloudflare.
Tetapi yang sebenarnya Anda kelola bukan Kubernetes itu sendiri, melainkan sistem tambahan seperti sistem CI/CD, manajemen secret, dan otomasi operasional database. Di masa lalu, itu semua akan dilakukan dengan cron job, ansible, systemd, bash script, dan sejenisnya, alih-alih yaml.
Rasanya seperti Anda membangun arena sirkus itu dengan tangan sendiri. Jangan memasang terlalu banyak hal. Setiap kali Anda menambahkan sesuatu, Anda juga menambah utang teknis dan biaya maintenance, bahkan jika tool-nya gratis. Kalau autoscaling justru menambah utang/biaya maintenance lebih besar daripada penghematannya, lebih baik dimatikan saja.
Kalau kumpulan layanan serupa itu diatur dan dijalankan satu per satu secara terpisah, beban maintenance-nya akan jauh lebih besar. Tetapi Kubernetes juga cukup mudah dikelola sampai level bisa dibiarkan setelah “terbakar”, asalkan Anda tahu apa yang sedang dilakukan sehingga tidak tergoda memasang “tool yang kelihatan keren”.
K8S juga tidak memaksa yaml. Itu mungkin idiomatis, tetapi bukan keharusan.
kubectl applysejak awal juga mendukung json, dan endpoint-nya adalah json serta grpc. Konfigurasi juga bisa dihasilkan dari berbagai bahasa seperti jsonnet. Kedua, saya penasaran mengapa dependency dan dependency ordering di Helm chart dianggap masalah. Idiom utama Kubernetes ada pada loop: kalau dependensi belum ada, aplikasi seharusnya menganggapnya sebagai recoverable error dan terus mencoba ulang sampai memungkinkan. Atau crash saja, lalu ReplicaSet controller akan me-restart otomatis. Kalau chart tidak punya dependency, ya tidak ada dependency conflict. Kalau memang aplikasinya benar-benar bergantung, justru masuk akal memasukkan aplikasi/layanan dependennya langsung ke dalam Helm chart.(Mengutip komentar utama) > Tidak cukup hanya mengandalkan ReplicaSet controller untuk me-restart aplikasi saat crash. Misalnya keycloak butuh 1 menit untuk hidup, layanan yang bergantung padanya akan langsung crash tanpa keycloak, lalu retry sampai akhirnya kena throttle, sehingga meski keycloak sudah siap, tetap menunggu sia-sia 5–10 menit. Kalau hubungan dependensinya memang jelas, lebih tepat memeriksa layanan dependensi lewat init container sebelum melanjutkan ke container utama. Saya rasa akan bagus jika Kubernetes punya fitur deklarasi dependensi start yang eksplisit. Crash lalu retry beberapa kali sampai kena throttle bukanlah jawaban. Dependensi itu memang realitas yang ada.
Saya rasa kegagalan dependensi harus bisa dipulihkan. Saya pernah mengalami outage karena perilaku fail-closed akibat dependensi yang bahkan sebenarnya tidak dipakai. Dependensi antar-server hampir semuanya adalah soft dependency. Kalau dependensi downstream tidak tersedia, cukup kembalikan 500, lalu biarkan load balancer menghindari server yang unhealthy.
Orang bilang “supposed to”, tetapi itu hanya cocok untuk kasus membangun software stack in-house. Ada banyak software lama yang sudah jadi, yang awalnya hanya mendukung docker lalu belakangan dibuat bisa berjalan di kubernetes. Kalau developer membuat tool sesuai filosofinya sendiri, orang-orang tetap akan memakainya dengan cara yang mereka mau, dan hasilnya kadang jadi berantakan. Pada akhirnya, orang perlu diberi beragam fitur dan pilihan, dan pasar akan memanfaatkannya sesuai keinginan.
Mengkritik argumen ini hanya karena “bisa pakai json, bukan hanya yaml” bukanlah inti persoalannya. Itu bukan bagian yang benar-benar dipedulikan semua orang. Menurut saya itu hanya nitpicking yang tidak perlu.
Saya sangat tidak setuju dengan usulan mengganti yaml dengan HCL. HCL sulit dilihat dan dibaca oleh developer. Ada banyak keluhan soal usability seperti dukungan import atau sulitnya debugging. Saya tidak mengerti kenapa bukan bahasa definisi antarmuka seperti protobuf yang dijadikan pusat, lalu bentuknya bisa dikonversi sesuai selera pengguna.
HCL itu yang paling buruk. k8s yaml saja tidak pernah terasa kurang. Kalau konfigurasi terasa terlalu rumit, kemungkinan masalahnya lebih dekat ke desain aplikasi itu sendiri daripada config map.
Sebenarnya, entah itu HCL, JSON, atau YAML, tinggal serialisasi/deserialisasi saja di sisi klien. Jadi ini bukan isu Kubernetes itu sendiri, melainkan hanya lapisan konversi eksternal.
Definisi antarmuka Kubernetes sendiri sudah berbasis protobuf (kecuali crd).
Keluhan utama saya terhadap HCL adalah sintaks
for loop-nya. Benar-benar yang terburuk.Pernyataan seperti “HCL sulit bagi developer, linting dan debugging-nya susah” terdengar lebih seperti orang yang tidak mau belajar hal baru. Rasanya ini masalah yang muncul karena mencampur kompleksitas domain dengan proses belajar HCL.
Saya sedang mengembangkan proyek nebulous bergaya “Kubernetes 2.0” (masih tahap pre-alpha). Targetnya adalah terdistribusi secara global dan ringan, bisa dijalankan sebagai single binary di laptop sekaligus diskalakan sampai ribuan node di cloud, dengan Tailnet networking, BitTorrent storage, multi-tenancy, live migration, dan lain-lain. Sebagian besar kebutuhan ini muncul dari operasional ML (terutama kelangkaan GPU), dan mungkin akan menjadi standar dasar jika ML benar-benar menjadi hal biasa di masa depan.
Live migration terdengar menarik. Saat ini kami menjalankan strategi harga berbasis autoscaling lintas banyak cluster dan cloud, jadi live migration adalah tantangan di level yang berbeda lagi.
Ini bukan Kubernetes, melainkan sistem terpisah yang dioptimalkan khusus untuk operasional GPU.
“Distribusi global” justru mungkin adalah non-requirement. Kalau Tailnet dipakai sebagai jaringan default, itu malah fitur yang ingin segera saya hapus. Asumsi Kubernetes tentang single NIC adalah warisan sempit yang disesuaikan untuk cloud (senang melihat adanya beberapa CNI dan proyek yang lebih baru seperti Multus (lihat: blog redhat)). Saya penasaran apa perbedaan praktis desain multi-tenant ini dibanding k8s. Jika storage-nya memakai BitTorrent, dan bahkan image container publik juga dibagikan, biaya traffic egress akan sangat besar.
Kalau melihat GitHub-nya, ada
Chart.yaml, bahkan template sepertiprovider_aws.yaml, dan itu benar-benar pola kode yang saya harap tidak dilakukan.Kubernetes menurut saya memang masih sangat rumit. Hanya saja sekarang tidak terlalu terasa karena sudah populer. Di Kubernetes 2.0, saya ingin pengalaman pengguna, terutama untuk operasi yang sering dilakukan (deployment aplikasi, mengekspos layanan, mengubah service account/image, dan semacamnya) jadi jauh lebih sederhana. Tetapi sekarang tren utamanya adalah LLM, jadi pengembangan lanjutan ke arah ini tampaknya sulit.
Kubernetes punya terlalu banyak lapisan abstraksi. Pod adalah konsep inti yang keren, tetapi setelah deployment, rep set, namespace, dan lain-lain ditambahkan, saya jadi berharap ia sesederhana Docker Swarm. Terraform juga hanya satu lapisan dan terasa lebih mudah dipelajari. Saya benar-benar merasakan betapa curamnya learning curve k8s.
Ini terasa seperti isu yang menunjukkan bahwa “pembedaan tipe dalam program komputer adalah hasil persepsi manusia”. Operator/controller terlalu diabstraksikan, mirip COM/CORBA di masa lalu (baik sebagai kelebihan maupun kekurangan). Untuk implementasi sederhana, rasanya k8s-lite yang lebih terbatas justru lebih cocok. Sebaliknya, di lingkungan yang kompleks, abstraksi k8s yang ada pun sering kali tidak cukup. Saya ragu satu sistem tunggal (entah Kubernetes 2.0 atau apa pun) bisa membungkus semua masalah dunia nyata sampai masih bisa ditangani developer/desainer manusia.
Saya menginginkan sistem dengan “sane default”, yaitu keadaan dasar yang cukup memadai bahkan tanpa memilih banyak hal secara khusus (networking/storage/load balancer, dan sebagainya). Saya tidak suka yaml maupun HCL. Dibutuhkan cara konfigurasi yang lebih baik, dan masalah ini tidak akan selesai hanya dengan mengganti bahasanya. Menurut saya IPv6 wajib ada. Docker, container, dan Kubernetes seharusnya sejak awal membuat bagian internalnya IPv6-only, lalu IPv4 diperlakukan sebagai pengecualian di ingress controller.
Ada konflik mendasar antara “sane defaults” dan “mendorong konversi pelanggan ke layanan managed”. Semakin lama saya mengamati k8s, semakin kuat filosofi “batteries not included” pada storage/networking dan sejenisnya, lalu AWS/GCP menjual integrasi itu sebagai layanan mahal. Dalam praktiknya, k8s dunia nyata kadang terasa bukan open source, melainkan alat promosi untuk menjual pengisi celah cloud.
(Pengalaman pribadi) Hal yang membuat Terraform/HCL lebih baik daripada YAML adalah ia tidak bergantung pada karakter tak terlihat, sehingga lebih mudah dibaca.
Karena “sane defaults” itulah saya jauh lebih menyukai k3s.
Saya rasa ini daftar keinginan yang agak terlalu sederhana untuk sesuatu bernama rilis 2.0. Semua orang di sekitar saya sangat tidak puas dengan kompleksitas k8s di production. Inti sebenarnya adalah bagaimana mewujudkan backward compatibility sekaligus kesederhanaan pada saat yang sama. Biasanya justru backward compatibility membuat kompleksitas meledak, karena sistem baru harus menanggung fitur lama dan baru sekaligus.
Saya merasa sudah hidup di “dunia Kubernetes 2.0” dengan mengelola cluster dan aplikasi melalui Terraform.
tf apply, cluster, node, integrasi cloud (S3, dsb.), sampai layanan di dalam cluster bisa disiapkan sekaliguscloudflaredke cluster + konfigurasi tunnel API Cloudflare)Sebagai orang yang berasal dari frontend, saya merasa Kubernetes cukup intuitif. Dulu saya menerima data masukan lalu membangun UI secara reaktif, sekarang rasanya seperti menulis kode yang menyesuaikan resource dan config ke control plane.