Kubernetes 1.37.2 dan Patch Serentak Tiga Cabang

Empat rilis Kubernetes keluar pada 28 Oktober 2026: v1.37.2 pukul 04:37 UTC, v1.35.10 pukul 04:37 UTC, v1.36.6 pukul 04:56 UTC, dan v1.38.0-alpha.3 pukul 09:02 UTC. Tiga rilis pertama adalah patch pemeliharaan untuk tiga cabang minor yang masih dilayani, sedangkan yang keempat adalah kandidat alpha untuk cabang berikutnya. Data ini dibaca dari feed rilis resmi repositori kubernetes/kubernetes pada 6 November 2026, dan setiap entri menautkan changelog per cabang sebagai rujukan perubahan.

TL;DR

• Empat rilis Kubernetes terbit pada 28 Oktober 2026: v1.37.2, v1.36.6, v1.35.10, dan v1.38.0-alpha.3.
• Tiga cabang minor mendapat patch pada hari yang sama, menandakan patch serentak lintas cabang.
• v1.38 baru mencapai tahap alpha.3, jadi belum layak untuk cluster produksi.
• Catatan rilisnya singkat dan menunjuk changelog per cabang, sehingga pembacaan perubahan wajib dilakukan di berkas changelog.
• Bagi operator, pekerjaan utamanya bukan memilih versi terbaru, tetapi memastikan setiap cluster berada di cabang yang masih menerima patch.

Patch serentak seperti ini punya arti khusus bagi tim yang mengelola lebih dari satu cluster. Ketika tiga cabang menerima rilis di hari yang sama, biasanya ada perbaikan yang berlaku lintas versi, misalnya penyesuaian pada komponen yang dipakai bersama atau perbaikan pada jalur build rilis. Tanpa membaca changelog masing-masing cabang, sulit memastikan apakah perbaikannya relevan untuk cluster yang berjalan di cabang paling lama.

Versi mana yang sebaiknya dipakai di cluster produksi?

Pakai cabang minor yang masih menerima patch, lalu naikkan patch terbaru di cabang itu. Pada data 28 Oktober 2026, cabang yang menerima patch adalah 1.35, 1.36, dan 1.37, sehingga cluster produksi sebaiknya berada di salah satu dari ketiganya, bukan di cabang yang sudah tidak menerima pembaruan.

Alasannya bukan soal fitur, melainkan soal jalur perbaikan. Cluster yang tertinggal satu cabang minor akan tetap berjalan, tetapi perbaikan keamanan dan kestabilan tidak lagi datang untuknya. Ketika masalah muncul, satu-satunya jalan keluar adalah naik cabang, dan itu pekerjaan yang jauh lebih besar daripada menaikkan patch di cabang yang sama.

Untuk perencanaan, halaman rilis resmi Kubernetes mencantumkan cabang yang sedang dilayani beserta jadwalnya. Membaca halaman itu lebih aman daripada mengandalkan ingatan tentang berapa cabang yang didukung, karena jumlah dan jadwalnya berubah mengikuti siklus rilis. Jadwal patch per cabang tersedia di halaman patch releases.

Kapan patch serentak seperti ini perlu diperhatikan?

Patch serentak perlu diperhatikan ketika cluster menjalankan beban kerja yang sensitif terhadap perubahan kecil, misalnya operator pihak ketiga, custom resource definition, atau konfigurasi jaringan yang bergantung pada detail perilaku komponen. Pada kondisi itu, changelog per cabang wajib dibaca sebelum upgrade dijadwalkan.

Untuk cluster yang hanya menjalankan Deployment dan Service biasa, patch pemeliharaan biasanya bisa dijadwalkan di jendela rutin. Perbedaannya terletak pada seberapa banyak komponen yang menyentuh API internal: semakin banyak operator dan webhook yang terpasang, semakin besar kemungkinan satu perubahan kecil pada perilaku komponen memicu efek berantai.

Berikut ringkasan empat rilis pada 28 Oktober 2026:

Tag	Waktu rilis (UTC)	Jenis	Rujukan perubahan
v1.38.0-alpha.3	2026-10-28 09:02	alpha	CHANGELOG-1.38
v1.37.2	2026-10-28 04:37	patch	CHANGELOG-1.37
v1.36.6	2026-10-28 04:56	patch	CHANGELOG-1.36
v1.35.10	2026-10-28 04:37	patch	CHANGELOG-1.35

Isi catatan rilis pada feed GitHub sengaja dibuat singkat. Untuk v1.37.2, isinya hanya mengarahkan pembaca ke milis pengumuman dan ke changelog cabang 1.37. Artinya, siapa pun yang ingin tahu perubahan apa yang masuk harus membuka changelog tersebut, karena halaman rilis tidak memuat ringkasan perubahan.

Kebiasaan ini penting dipahami agar tidak terjadi kesalahan penilaian. Rilis yang catatannya pendek bukan berarti perubahannya kecil. Catatan pendek hanya berarti ringkasannya ada di tempat lain, dan pada proyek sebesar Kubernetes, changelog per cabang itulah sumber yang bisa dipertanggungjawabkan.

Ada cara membaca changelog yang lebih efisien daripada membacanya dari atas. Mulai dari bagian yang menandai perubahan perilaku, lalu turun ke perbaikan bug, dan berhenti di sana jika cluster hanya memakai komponen bawaan. Bagian yang menyangkut perubahan API dan penghapusan fitur biasanya paling relevan bagi tim yang memasang operator atau controller sendiri, karena di situlah pekerjaan penyesuaian biasanya muncul.

Urutan waktu rilis juga memberi petunjuk. Pada 28 Oktober 2026, patch untuk 1.35 dan 1.37 tercatat pada menit yang sama, sementara 1.36 menyusul sekitar sembilan belas menit kemudian, dan alpha 1.38 keluar sekitar empat setengah jam setelahnya. Pola ini menunjukkan bahwa ketiga patch dibangun dari basis yang sama lalu diuji per cabang, dan alpha mengikuti jalur terpisah. Bagi operator, artinya tidak ada alasan menganggap satu cabang lebih mendesak hanya karena dirilis beberapa menit lebih awal.

Yang justru layak diperhatikan adalah selisih antara patch dan alpha. Empat setengah jam bukan waktu yang cukup untuk pengujian menyeluruh, jadi keluarnya alpha pada hari yang sama bukan tanda bahwa cabang baru sudah stabil. Ia hanya tanda bahwa pipeline rilis berjalan sesuai jadwal.

Untuk cluster yang dijalankan dengan alat pengelolaan terpusat, patch seperti ini biasanya muncul sebagai pembaruan minor pada saluran pemeliharaan. Membaca catatan alat tersebut tidak cukup, karena ringkasannya sering hanya menyebut nomor versi tanpa isi changelog. Kebiasaan yang lebih aman adalah membuka changelog cabang yang bersangkutan, terutama jika patch menyentuh komponen yang dipakai langsung oleh beban kerja.

Bagaimana menyiapkan upgrade patch tanpa downtime?

Siapkan upgrade patch dengan menaikkan satu node control plane lebih dulu, memastikan komponen tetap sehat, baru menggulir node pekerja satu per satu sambil memantau beban kerja yang dipindahkan. Untuk patch di cabang yang sama, perubahan API biasanya tidak ada, sehingga risiko utamanya ada pada ketersediaan selama proses pengguliran.

Urutan kerja yang bisa dipakai:

1. Catat versi setiap komponen dan node sebelum menyentuh apa pun, karena campuran versi dalam satu cluster adalah sumber kebingungan yang paling umum.
2. Baca changelog cabang yang dipakai, lalu tandai perubahan yang menyentuh komponen yang benar-benar berjalan.
3. Cadangkan objek konfigurasi penting dan pastikan prosedur pemulihan sudah pernah diuji, bukan hanya tertulis.
4. Naikkan control plane satu node per satu node, dan tahan langkah berikutnya sampai tiap node kembali sehat.
5. Gulir node pekerja dengan jeda yang cukup agar beban kerja sempat dipindahkan dan dijadwalkan ulang.
6. Verifikasi bahwa semua node melaporkan versi yang sama dan tidak ada pod yang tertahan pada status yang tidak selesai.

Langkah pertama sering dilewati, padahal murah. Cluster yang memiliki campuran versi antar node bisa lolos dari pemeriksaan permukaan karena tetap melayani trafik, tetapi masalah baru muncul ketika satu fitur membutuhkan konsistensi versi di seluruh node. Mencatat versi awal membuat selisih itu terlihat sejak awal.

Untuk lingkungan dengan banyak cluster, urutan pengguliran yang lazim dipakai adalah dari cluster non-produksi, lalu cluster produksi dengan trafik terkecil, baru sisanya. Cara ini memberi kesempatan untuk menemukan masalah pada beban yang paling ringan, dan biaya kegagalannya jauh lebih kecil dibanding menemukannya di cluster utama.

Apa arti alpha.3 untuk perencanaan jangka panjang?

alpha.3 berarti cabang 1.38 sudah masuk tahap pengujian awal dengan tiga iterasi alpha, tetapi belum mencapai beta maupun rilis final. Untuk perencanaan, artinya fitur pada cabang 1.38 belum bisa dianggap tersedia, dan tim sebaiknya tidak membangun ketergantungan pada perilakunya.

Tahap alpha berguna untuk dua hal: menguji kompatibilitas operator sebelum versi final keluar, dan mendeteksi perubahan yang akan memaksa penyesuaian konfigurasi. Keduanya pekerjaan yang lebih murah dilakukan di cluster pengujian daripada setelah versi final terpasang di produksi.

Pada praktiknya, tim yang memelihara operator atau controller sendiri biasanya mulai menguji di tahap alpha, karena perubahan pada API dapat memaksa penyesuaian kode. Tim yang hanya memakai komponen bawaan bisa menunggu sampai tahap beta atau rilis final, karena perubahan yang tersisa umumnya tidak menyentuh kontrak yang mereka pakai.

Selain itu, tahap alpha memberi kesempatan memeriksa kompatibilitas alat pendukung. Alat seperti pengelola manifes, pengecek kebijakan, dan pengumpul metrik sering tertinggal beberapa minggu dari rilis Kubernetes, dan menguji lebih awal membuat selisih itu terlihat sebelum versi final dipakai di produksi. Temuan pada tahap itu jauh lebih murah ditangani daripada temuan yang muncul saat pengguliran cluster utama.

Yang perlu dihindari adalah menganggap nomor alpha sebagai versi yang lebih baru sehingga layak dipasang di produksi. Urutan versi tidak sama dengan urutan kematangan. Cabang 1.37 yang baru menerima patch kedua justru lebih matang dibanding cabang 1.38 yang baru mencapai alpha ketiga, meskipun angka minornya lebih kecil.

FAQ

Apakah v1.38.0-alpha.3 boleh dipakai di cluster produksi?

Tidak. Status alpha menandakan tahap pengujian awal, dan perilakunya masih dapat berubah sebelum rilis final. Untuk produksi, gunakan patch terbaru dari cabang yang masih dilayani, yaitu cabang yang menerima pembaruan pada siklus pemeliharaan terakhir.

Kenapa catatan rilis Kubernetes sangat singkat?

Karena ringkasan perubahan dipelihara di changelog per cabang, bukan di halaman rilis. Catatan rilis resmi hanya mengarahkan pembaca ke milis pengumuman dan ke berkas changelog cabang terkait, sehingga pembacaan detail wajib dilakukan di berkas itu.

Berapa cabang minor yang menerima patch pada 28 Oktober 2026?

Ada tiga cabang yang menerima patch pada hari itu: 1.35, 1.36, dan 1.37. Selain itu, cabang 1.38 menerima rilis alpha.3. Jumlah cabang yang dilayani dapat berubah mengikuti siklus rilis, jadi acuannya adalah halaman rilis resmi.

Apakah upgrade patch selalu tanpa downtime?

Tidak selalu, tetapi downtime dapat dihindari jika control plane dinaikkan satu node per satu node dan node pekerja digulir dengan jeda. Beban kerja yang tidak dikonfigurasi untuk toleran terhadap penggantian node tetap berisiko mengalami gangguan singkat.