Komunitas Kubernetes sedang ramai dengan diskusi tentang bagaimana seharusnya versi 2.0 hipotetis terlihat, dengan para developer dan engineer berbagi frustrasi dan daftar keinginan mereka untuk platform orkestrasi kontainer yang populer ini. Meskipun artikel asli yang mengusulkan perubahan mendapat reaksi beragam karena presentasinya yang kurang jelas, respons komunitas telah memicu percakapan bermakna tentang keterbatasan Kubernetes saat ini dan arah masa depannya.
Perang Bahasa Konfigurasi: YAML vs HCL vs Semua yang Lain
Salah satu perdebatan terpanas berpusat pada penggantian YAML dengan HashiCorp Configuration Language ( HCL ). Beberapa developer antusias dengan kemungkinan ini, terutama mereka yang sudah menggunakan Terraform dan menghargai keamanan tipe dan struktur HCL . Namun, komunitas sangat terbagi dalam masalah ini. Banyak developer merasa HCL membingungkan dan sulit dibaca, dengan kekhawatiran tentang debugging error dan dukungan import. Saran alternatif termasuk menggunakan Protocol Buffers atau bahasa definisi interface lain yang memungkinkan pengguna menentukan konfigurasi dalam bahasa pemrograman pilihan mereka.
Diskusi ini mengungkap frustrasi yang lebih luas dengan manajemen konfigurasi di Kubernetes . Banyak pengguna sudah bekerja mengatasi keterbatasan YAML dengan menggunakan tools seperti Terraform untuk mengelola seluruh infrastruktur Kubernetes mereka, memperlakukan YAML sebagai representasi perantara daripada sesuatu yang mereka tulis secara langsung.
Fitur Kubernetes 2.0 yang Diusulkan dari Diskusi Komunitas:
- Mengganti YAML dengan HCL ( HashiCorp Configuration Language ) untuk konfigurasi
- Mengimplementasikan API berbasis gRPC / Protocol Buffer untuk dukungan multi-bahasa yang lebih baik
- Mengganti etcd dengan PostgreSQL atau backend penyimpanan pluggable lainnya
- Menambahkan dukungan IPv6 native di seluruh platform
- Menyertakan "default yang masuk akal" untuk networking, storage, dan load balancing
- Meningkatkan manajemen paket untuk menggantikan sistem templating Go milik Helm
- Menambahkan dukungan WebAssembly ( WASM ) untuk workload
- Mengimplementasikan dukungan user namespace (userns) yang lebih baik secara default
Storage dan Kesederhanaan: Titik Sakit yang Persisten
Tema berulang dalam diskusi komunitas adalah kompleksitas Kubernetes , terutama seputar storage dan networking. Banyak engineer melaporkan bahwa meskipun Kubernetes bekerja dengan baik untuk aplikasi stateless, mengelola persistent storage tetap bermasalah. Komunitas menyarankan bahwa Kubernetes 2.0 harus menyertakan default yang masuk akal untuk load balancer, networking, dan storage, daripada memaksa pengguna untuk menyatukan solusi dari berbagai provider.
Saat ini menjalankan K8S di platform selain cloud provider dan mainan adalah bencana yang menunggu terjadi kecuali Anda benar-benar engineer infrastruktur yang berpengalaman.
Masalah kompleksitas ini meluas melampaui storage. Beberapa anggota komunitas berargumen bahwa Kubernetes telah menjadi terlalu kaya fitur, mencoba mendukung keinginan dan hasrat semua orang dalam platform inti, yang menyebabkan kompleksitas yang tidak perlu bagi sebagian besar pengguna.
Keluhan Komunitas terhadap Kubernetes Saat Ini:
- Manajemen Penyimpanan: Penyimpanan persisten tetap kompleks dan bermasalah, terutama untuk deployment on-premises
- Kompleksitas Konfigurasi: Templating YAML dengan Helm sulit untuk di-debug dan dipelihara
- Pengaturan Jaringan: Desain jaringan yang berfokus pada IPv4 tidak memanfaatkan keunggulan IPv6
- Manajemen Paket: Template Go milik Helm menciptakan skenario error yang membingungkan
- Kurva Pembelajaran: Membutuhkan tim engineering khusus (diperkirakan 3+ engineer dengan biaya $1M USD per tahun) untuk deployment produksi
- Ketergantungan pada Cloud Vendor: Pendekatan "batteries not included" mendorong pengguna ke layanan cloud provider yang mahal
Peningkatan Infrastruktur Teknis
Komunitas telah mengidentifikasi beberapa peningkatan teknis untuk Kubernetes 2.0 potensial. Ini termasuk mengganti etcd dengan PostgreSQL atau backend storage pluggable lainnya, mengimplementasikan API berbasis gRPC untuk dukungan multi-bahasa yang lebih baik, dan menambahkan dukungan IPv6 yang tepat dari awal. Banyak pengguna juga menginginkan sistem manajemen paket yang lebih baik untuk menggantikan Helm , yang dikritik secara luas karena sistem templating Go dan kesulitan debugging-nya.
Menariknya, beberapa anggota komunitas menyarankan bahwa solusinya tidak harus berupa penulisan ulang lengkap, tetapi lebih pada tooling dan abstraksi yang lebih baik yang dibangun di atas fondasi Kubernetes yang ada.
 |
|---|
| Screenshot dari Artifact Hub ini mengilustrasikan sumber daya terkait manajemen paket, menyoroti kebutuhan akan tooling yang lebih baik dalam diskusi Kubernetes 20 |
Tantangan Kompatibilitas Mundur
Mungkin wawasan paling mengkhawatirkan dari diskusi komunitas adalah tantangan kompatibilitas mundur. Seperti yang dicatat oleh seorang engineer, membuat versi 2.0 dengan kompatibilitas mundur yang cukup untuk adopsi bertahap sambil membuat sistem lebih sederhana sangatlah sulit. Kompatibilitas mundur biasanya meningkatkan kompleksitas karena sistem baru harus menangani pendekatan lama dan baru.
Ini telah membuat beberapa anggota komunitas berargumen bahwa yang benar-benar dibutuhkan Kubernetes bukanlah perubahan revolusioner, tetapi rekam jejak stabilitas dan kesederhanaan selama satu dekade. Fokusnya harus pada mengurangi kemungkinan pengguna membuat konfigurasi yang kompleks dan sulit dipelihara daripada menambahkan fitur baru.
Konsensus komunitas tampaknya adalah bahwa meskipun Kubernetes memiliki ruang untuk perbaikan, setiap perubahan besar harus dengan hati-hati menyeimbangkan inovasi dengan kebutuhan praktis pengguna yang ada yang telah membangun infrastruktur mereka di sekitar sistem saat ini.
Referensi: What Would A Kubernetes 2.0 Look Like