Komuniti Kubernetes sedang sibuk membincangkan bagaimana rupa versi hipotetikal 2.0, dengan pembangun dan jurutera berkongsi kekecewaan dan senarai hajat mereka untuk platform orkestrasi kontena yang popular ini. Walaupun artikel asal yang mencadangkan perubahan menerima reaksi bercampur-campur kerana penyampaiannya yang tidak jelas, respons komuniti telah mencetuskan perbincangan bermakna tentang batasan semasa Kubernetes dan hala tuju masa depannya.
Peperangan Bahasa Konfigurasi: YAML vs HCL vs Segala-galanya
Salah satu perdebatan paling hangat berpusat pada penggantian YAML dengan HashiCorp Configuration Language ( HCL ). Sesetengah pembangun berasa teruja dengan kemungkinan ini, terutamanya mereka yang sudah menggunakan Terraform yang menghargai keselamatan jenis dan struktur HCL . Walau bagaimanapun, komuniti terbahagi dua dalam isu ini. Ramai pembangun mendapati HCL mengelirukan dan sukar dibaca, dengan kebimbangan tentang ralat nyahpepijat dan sokongan import. Cadangan alternatif termasuk menggunakan Protocol Buffers atau bahasa definisi antara muka lain yang membolehkan pengguna menentukan konfigurasi dalam bahasa pengaturcaraan pilihan mereka.
Perbincangan ini mendedahkan kekecewaan yang lebih luas dengan pengurusan konfigurasi dalam Kubernetes . Ramai pengguna sudah mengatasi batasan YAML dengan menggunakan alat seperti Terraform untuk menguruskan keseluruhan infrastruktur Kubernetes mereka, menganggap YAML sebagai perwakilan perantaraan dan bukannya sesuatu yang mereka tulis secara langsung.
Ciri-ciri Kubernetes 2.0 yang Dicadangkan daripada Perbincangan Komuniti:
- Menggantikan YAML dengan HCL ( HashiCorp Configuration Language ) untuk konfigurasi
- Melaksanakan API berasaskan gRPC / Protocol Buffer untuk sokongan berbilang bahasa yang lebih baik
- Menggantikan etcd dengan PostgreSQL atau backend storan boleh-pasang yang lain
- Menambah sokongan IPv6 asli di seluruh platform
- Memasukkan "lalai yang munasabah" untuk rangkaian, storan, dan pengimbangan beban
- Menambah baik pengurusan pakej untuk menggantikan sistem templat Go milik Helm
- Menambah sokongan WebAssembly ( WASM ) untuk beban kerja
- Melaksanakan sokongan ruang nama pengguna (userns) yang lebih baik secara lalai
Storan dan Kesederhanaan: Titik Kesakitan yang Berterusan
Tema berulang dalam perbincangan komuniti ialah kerumitan Kubernetes , terutamanya sekitar storan dan rangkaian. Ramai jurutera melaporkan bahawa walaupun Kubernetes berfungsi dengan baik untuk aplikasi tanpa keadaan, menguruskan storan berterusan kekal bermasalah. Komuniti mencadangkan bahawa Kubernetes 2.0 sepatutnya merangkumi lalai yang waras untuk pengimbang beban, rangkaian, dan storan, dan bukannya memaksa pengguna untuk menyusun penyelesaian daripada pelbagai pembekal.
Sekarang ini menjalankan K8S pada apa-apa selain daripada pembekal awan dan mainan adalah bencana yang menunggu untuk berlaku melainkan anda seorang jurutera infrastruktur yang sangat berpengalaman.
Isu kerumitan ini melangkaui storan. Beberapa ahli komuniti berhujah bahawa Kubernetes telah menjadi terlalu kaya dengan ciri, cuba menyokong kehendak dan keinginan semua orang dalam platform teras, yang membawa kepada kerumitan yang tidak perlu bagi kebanyakan pengguna.
Masalah Komuniti dengan Kubernetes Semasa:
- Pengurusan Storan: Storan berterusan kekal kompleks dan bermasalah, terutamanya untuk penggunaan dalam premis
- Kerumitan Konfigurasi: Templat YAML dengan Helm sukar untuk dinyahpepijat dan diselenggara
- Persediaan Rangkaian: Reka bentuk rangkaian yang berfokuskan IPv4 tidak memanfaatkan kelebihan IPv6
- Pengurusan Pakej: Templat Go dalam Helm mewujudkan senario ralat yang mengelirukan
- Keluk Pembelajaran: Memerlukan pasukan kejuruteraan khusus (dianggarkan 3+ jurutera pada kos $1 juta USD setiap tahun) untuk penggunaan pengeluaran
- Terikat dengan Vendor Awan: Pendekatan "bateri tidak disertakan" mendorong pengguna ke arah perkhidmatan penyedia awan yang mahal
Penambahbaikan Infrastruktur Teknikal
Komuniti telah mengenal pasti beberapa penambahbaikan teknikal untuk potensi Kubernetes 2.0. Ini termasuk menggantikan etcd dengan PostgreSQL atau backend storan boleh pasang yang lain, melaksanakan API berasaskan gRPC untuk sokongan berbilang bahasa yang lebih baik, dan menambah sokongan IPv6 yang betul dari awal. Ramai pengguna juga mahukan sistem pengurusan pakej yang lebih baik untuk menggantikan Helm , yang dikritik secara meluas kerana sistem templat Go dan kesukaran nyahpepijatnya.
Menariknya, sesetengah ahli komuniti mencadangkan bahawa penyelesaiannya tidak semestinya penulisan semula yang lengkap, tetapi alat dan abstraksi yang lebih baik yang dibina di atas asas Kubernetes yang sedia ada.
 |
|---|
| Tangkapan skrin dari Artifact Hub ini menggambarkan sumber berkaitan pengurusan pakej, menonjolkan keperluan untuk perkakas yang lebih baik dalam perbincangan Kubernetes 20 |
Cabaran Keserasian Ke Belakang
Mungkin pandangan yang paling menyedarkan daripada perbincangan komuniti ialah cabaran keserasian ke belakang. Seperti yang dinyatakan oleh seorang jurutera, mencipta versi 2.0 dengan keserasian ke belakang yang mencukupi untuk penggunaan berperingkat sambil menjadikan sistem lebih mudah adalah amat sukar. Keserasian ke belakang biasanya meningkatkan kerumitan kerana sistem baharu mesti mengendalikan kedua-dua pendekatan lama dan baharu.
Ini telah menyebabkan sesetengah ahli komuniti berhujah bahawa apa yang benar-benar diperlukan oleh Kubernetes bukanlah perubahan revolusioner, tetapi rekod jejak kestabilan dan kesederhanaan selama sedekad. Tumpuan sepatutnya pada mengurangkan kemungkinan pengguna mencipta konfigurasi yang kompleks dan sukar diselenggara dan bukannya menambah ciri baharu.
Konsensus komuniti nampaknya ialah walaupun Kubernetes mempunyai ruang untuk penambahbaikan, sebarang perubahan besar mesti mengimbangi inovasi dengan teliti dengan keperluan praktikal pengguna sedia ada yang telah membina infrastruktur mereka di sekitar sistem semasa.