Kubernetes 1.38 Beta: Siklus Rilis dan Patch 1.37.2, 1.36.6

Kubernetes v1.38.0-beta.0 terbit 6 November 2026 pukul 04.34 UTC, sembilan hari setelah v1.38.0-alpha.3 pada 28 Oktober 2026. Pada tanggal yang sama dengan alpha tersebut, dua cabang lama juga menerima patch: v1.37.2 pukul 04.37 UTC dan v1.36.6 pukul 04.56 UTC. Semua versi dan waktu di artikel ini dibaca dari halaman rilis resmi kubernetes/kubernetes pada 7 November 2026.

TL;DR

• v1.38.0-beta.0 terbit 6 November 2026, sembilan hari setelah v1.38.0-alpha.3 pada 28 Oktober 2026.
• Pada 28 Oktober 2026, tiga rilis keluar di hari yang sama: v1.38.0-alpha.3, v1.37.2, dan v1.36.6.
• v1.37.2 dan v1.36.6 terbit hanya berselisih 19 menit, menandakan patch disiapkan bersamaan.
• Beta berarti fitur sudah dikunci. Yang berubah setelah tahap ini adalah perbaikan bug, bukan penambahan fitur.
• Klaster produksi sebaiknya tetap di cabang stabil yang masih menerima patch, bukan mengikuti beta.

Bagi tim platform, kalender rilis Kubernetes lebih penting daripada daftar fitur. Keputusan upgrade, jadwal uji, dan perencanaan jendela pemeliharaan semuanya bergantung pada cabang mana yang sedang di tahap apa. Artikel ini menyusun urutan rilis dari data resmi, lalu menerjemahkannya jadi keputusan praktis tanpa mengarang tanggal yang belum diumumkan.

Rilis apa saja yang keluar pada akhir Oktober sampai awal November 2026?

Ada tiga rilis pada 28 Oktober 2026 dan satu rilis pada 6 November 2026. Yang pertama di hari itu adalah v1.37.2 pukul 04.37 UTC, disusul v1.36.6 pukul 04.56 UTC, lalu v1.38.0-alpha.3 pukul 09.02 UTC. Rilis berikutnya adalah v1.38.0-beta.0 pada 6 November 2026 pukul 04.34 UTC.

Rilis	Tanggal (UTC)	Kanal	Isi
v1.37.2	28 Oktober 2026, 04.37	Patch cabang 1.37	Perbaikan bug untuk cabang stabil
v1.36.6	28 Oktober 2026, 04.56	Patch cabang 1.36	Perbaikan bug untuk cabang stabil sebelumnya
v1.38.0-alpha.3	28 Oktober 2026, 09.02	Alpha cabang 1.38	Tahap awal siklus, fitur masih bisa berubah
v1.38.0-beta.0	6 November 2026, 04.34	Beta cabang 1.38	Fitur dikunci, fokus perbaikan bug

Pola yang terlihat: patch untuk cabang lama dan alpha untuk cabang baru bisa keluar di hari yang sama. Ini bukan kebetulan, melainkan konsekuensi dari siklus rilis yang berjalan bersamaan. Tim yang memantau satu cabang saja bisa melewatkan fakta bahwa cabang lain sedang bergerak, dan itu memengaruhi perencanaan upgrade.

Apa arti beta bagi pengguna klaster produksi?

Beta berarti fitur untuk cabang tersebut sudah dikunci, sehingga penambahan fitur baru tidak lagi diterima dan perubahan yang masuk hanya berupa perbaikan bug. Bagi pengguna produksi, artinya tidak ada yang perlu dilakukan: klaster sebaiknya tetap di cabang stabil yang masih menerima patch, yaitu jalur v1.37.2 atau v1.36.6 pada data di atas.

Tahap beta berguna untuk tim yang ingin menguji lebih awal, misalnya penyedia layanan yang perlu memastikan operator atau kontroler buatan sendiri tetap kompatibel. Pengujian di beta memberi waktu lebih panjang dibanding menunggu rilis stabil, tetapi menuntut kesediaan menerima perubahan perilaku antar beta dan rc.

Yang perlu dihindari adalah membaca beta sebagai "sudah hampir selesai, jadi aman". Kode di tahap beta masih menerima perbaikan yang bisa mengubah perilaku, dan belum melewati seluruh pengujian yang dilalui rilis stabil. Klaster produksi yang menjalankan beta berarti menanggung risiko regresi tanpa jaminan dukungan.

Kapan sebaiknya klaster upgrade ke cabang minor baru?

Setelah rilis stabil keluar dan setelah operator serta beban kerja yang dipakai tim dinyatakan kompatibel. Rilis stabil untuk cabang 1.38 belum ada pada 7 November 2026, jadi keputusan upgrade belum relevan sekarang. Yang relevan sekarang adalah menyiapkan uji kompatibilitas selama tahap beta berjalan.

Urutan yang masuk akal: petakan komponen yang bergantung pada API Kubernetes, lalu periksa catatan perubahan cabang 1.38 untuk API yang dihapus atau diubah. Setelah itu, jalankan klaster uji dengan versi beta untuk menemukan komponen yang gagal lebih awal, bukan setelah rilis stabil keluar.

Untuk patch dalam cabang yang sama, urutannya lebih sederhana: baca catatan rilis, terapkan di klaster uji, lalu produksi. Patch dalam satu cabang biasanya tidak membawa perubahan API, sehingga risiko utamanya ada pada perilaku runtime dan bukan pada kompatibilitas manifes.

Bagaimana membaca catatan perubahan Kubernetes dengan benar?

Baca berkas changelog per cabang, bukan ringkasan pengumuman. Setiap cabang punya berkas changelog sendiri di repositori, dan berkas itulah yang memuat daftar perubahan beserta nomor pull request. Pengumuman rilis hanya menautkan ke berkas tersebut tanpa menyalin isinya.

Untuk cabang 1.38, berkas yang dipakai adalah CHANGELOG-1.38.md di repositori Kubernetes. Isinya bertambah seiring siklus berjalan, jadi membaca berkas yang sama di dua waktu berbeda akan memberi hasil berbeda. Itu normal, dan justru alasan berkas itu lebih berguna daripada ringkasan yang ditulis sekali.

Kebiasaan yang membantu: catat nomor pull request yang menyentuh komponen yang dipakai tim, lalu pantau pull request itu, bukan seluruh changelog. Pada cabang yang menerima ratusan perubahan per siklus, memantau sepuluh pull request yang relevan jauh lebih terkendali daripada membaca semuanya.

Rujukan resminya ada di changelog cabang 1.38, sementara daftar cabang yang masih didukung dan jadwal rilisnya ada di halaman rilis Kubernetes. Untuk patch per cabang, halaman patch releases mencantumkan riwayat versi per cabang.

Bagaimana menyiapkan uji kompatibilitas selama tahap beta?

Siapkan klaster uji terpisah dengan versi beta, lalu jalankan beban kerja yang benar-benar dipakai di produksi. Menguji dengan manifes contoh tidak memberi informasi yang berguna, karena yang biasanya rusak adalah konfigurasi khusus: anotasi internal, kebijakan admission, dan operator pihak ketiga.

Urutan yang masuk akal dimulai dari inventaris komponen. Catat setiap operator, kontroler, dan alat CLI yang berkomunikasi dengan API server, beserta versi masing-masing. Dari daftar itu, tandai komponen yang sudah menyatakan dukungan untuk cabang 1.38, dan tandai juga yang belum menyebut apa pun. Kelompok kedua adalah sumber kejutan utama.

1. Buat klaster uji dengan v1.38.0-beta.0, terpisah dari klaster produksi dan tanpa akses ke data produksi.
2. Pasang komponen dari inventaris satu per satu, catat versi yang gagal start atau gagal mendaftar.
3. Jalankan beban kerja utama dan bandingkan perilakunya dengan hasil di klaster produksi.
4. Periksa log API server untuk peringatan tentang API yang sudah usang, karena peringatan itu muncul sebelum penghapusan.
5. Catat setiap kegagalan beserta nomor pull request terkait, supaya bisa dilacak saat rc keluar.

Langkah keempat sering menghasilkan temuan paling berharga. Peringatan penggunaan API yang usang tidak menggagalkan apa pun hari ini, tetapi menunjukkan bagian mana dari manifes yang perlu diubah sebelum cabang berikutnya menghapus API tersebut. Menunggu sampai penghapusan benar-benar terjadi berarti memperbaiki manifes di tengah jendela pemeliharaan yang sempit.

Untuk tim kecil, pengujian penuh di setiap tahap beta mungkin berlebihan. Alternatif yang lebih murah adalah menguji satu klaster non-produksi yang menyerupai produksi, lalu fokus pada komponen yang paling sering berubah. Yang penting bukan cakupan pengujiannya, tetapi apakah hasilnya dicatat dan dibaca sebelum rilis stabil keluar.

Ada satu jebakan yang perlu dihindari saat menguji beta: memakai klaster uji yang sudah lama tidak dipakai. Klaster seperti itu sering menyimpan konfigurasi yang tidak lagi mencerminkan produksi, sehingga hasil pengujiannya terlihat bersih tanpa alasan yang jelas. Sebelum dipakai, klaster uji sebaiknya dibangun ulang dari manifes yang sama dengan produksi, dengan nama dan kredensial yang berbeda.

Apa yang perlu dicatat saat mengikuti siklus rilis?

Catat empat hal per rilis: nomor versi, tanggal dan waktu rilis dalam UTC, cabangnya, dan status tahapnya. Empat medan itu cukup untuk menjawab pertanyaan yang paling sering muncul, misalnya "apakah patch ini masuk ke cabang yang kita pakai" atau "berapa lama lagi sampai rilis stabil".

Waktu rilis sebaiknya disimpan dalam UTC, bukan waktu lokal. Pada data 28 Oktober 2026, tiga rilis keluar dalam rentang kurang dari lima jam, dan menyimpannya dalam zona waktu berbeda-beda membuat urutannya sulit dibaca. Zona waktu tunggal menghilangkan satu sumber kebingungan yang tidak perlu.

Medan status tahap juga penting karena menentukan tindakan. Alpha berarti fitur masih bisa berubah, beta berarti fitur dikunci, dan rilis stabil berarti siap dipakai. Tanpa status itu, sebuah nomor versi hanya angka, dan angka tidak memberi tahu apakah aman dipasang di klaster yang melayani pengguna.

Kebiasaan terakhir yang layak dipertahankan: simpan tautan ke changelog cabang yang sedang dipakai, bukan hanya nomor versinya. Changelog itu bertambah sepanjang siklus, dan tautan yang tersimpan membuat pemeriksaan berikutnya lebih cepat daripada mencari ulang setiap kali ada pertanyaan.

Satu catatan penutup soal patch keamanan. Patch untuk cabang lama dan rilis beta untuk cabang baru sering keluar di minggu yang sama, seperti terlihat pada 28 Oktober 2026. Kondisi itu mudah disalahbaca sebagai tanda bahwa cabang lama sudah tidak penting, padahal justru sebaliknya: patch itulah yang menjaga klaster yang belum siap upgrade tetap aman. Memantau keduanya sekaligus, dengan catatan terpisah untuk masing-masing, jauh lebih aman daripada hanya mengikuti cabang terbaru.

FAQ

Apakah v1.38.0-beta.0 bisa dipakai di produksi?

Tidak disarankan. Beta belum melewati seluruh pengujian rilis stabil dan masih menerima perubahan perilaku. Gunakan untuk klaster uji yang memang bertujuan menemukan regresi lebih awal, bukan untuk klaster yang melayani pengguna.

Berapa lama jarak antara alpha dan beta di cabang 1.38?

Sembilan hari. v1.38.0-alpha.3 terbit 28 Oktober 2026 pukul 09.02 UTC, dan v1.38.0-beta.0 terbit 6 November 2026 pukul 04.34 UTC. Jarak sependek itu menunjukkan siklus berjalan cepat setelah fitur dikunci.

Mengapa dua patch keluar di hari yang sama?

Karena patch untuk cabang berbeda disiapkan dari basis perbaikan yang sama, lalu dirilis berurutan. Pada 28 Oktober 2026, v1.37.2 dan v1.36.6 terbit berselisih 19 menit, pola yang sama seperti patch serentak di proyek lain.

Apakah patch cabang lama masih penting kalau sudah ada cabang baru?

Penting. Klaster yang masih di cabang 1.36 atau 1.37 tetap butuh patch keamanan dan perbaikan bug. Cabang baru tidak menggantikan patch untuk cabang yang masih dipakai, karena tidak semua tim bisa upgrade segera.

Rekomendasi Tools & Layanan

Mau langsung nyobain AI yang dibahas di artikel ini tanpa setup ribet? AI token plan Alibaba Cloud ngasih akses ke Qwen, DeepSeek, dan model lain lewat satu API, dan platform Qwen buat build agent sendiri. Free tier-nya cukup buat eksperimen pertama.