Kubernetes 1.34 EOL 27 Oktober 2026: Urutan Upgrade Cluster

Kubernetes 1.34 berakhir masa dukungannya pada 27 Oktober 2026, tepat 14 bulan setelah rilis 27 Agustus 2025. Setelah tanggal itu, tidak ada lagi patch resmi untuk jalur 1.34; patch terakhir yang dijadwalkan adalah 1.34.13 pada 13 Oktober 2026. Cluster yang masih di 1.34 sekarang berjalan tanpa jalur perbaikan keamanan, sementara jalur yang aktif adalah 1.35, 1.36, dan 1.37.

Sampai kapan Kubernetes 1.34 masih didukung?

Sampai 27 Oktober 2026. Aturan proyek Kubernetes memberi masa dukungan sekitar 14 bulan per minor, mencakup fase penuh dan fase maintenance yang dimulai sekitar dua bulan sebelum akhir dukungan. Untuk 1.34, fase maintenance dimulai 27 Agustus 2026.

Yang penting dari kata maintenance: pada fase itu, hanya perbaikan penting yang masuk, bukan perubahan besar. Ketika fase itu selesai, jalur tersebut benar-benar ditutup, dan CVE yang ditemukan sesudahnya hanya diperbaiki di jalur yang masih hidup.

Untuk tim yang mengelola cluster produksi, angka yang paling perlu diperhatikan bukan tanggal akhir, melainkan jarak antara minor yang dipakai dan minor terbaru. Kebijakan versi Kubernetes hanya mendukung tiga minor terakhir, jadi cluster di 1.34 sekarang sudah dua minor di belakang 1.36 dan tiga minor di belakang 1.37. Jarak itu masih bisa di-upgrade satu per satu, tetapi tidak bisa dilompati sekaligus.

Versi mana yang jadi target upgrade paling masuk akal?

Target yang paling aman adalah 1.37, karena jalur itu berakhir paling lama, yaitu 28 Oktober 2027, dan merupakan jalur terbaru yang sudah menerima patch rutin. Kalau ada komponen yang belum mendukung 1.37, 1.36 adalah pilihan kedua dengan akhir dukungan 28 Juni 2027.

Minor	Tanggal rilis	Mulai maintenance	Akhir dukungan	Status per 30 Oktober 2026
1.34	27 Agustus 2025	27 Agustus 2026	27 Oktober 2026	Sudah berakhir
1.35	17 Desember 2025	28 Desember 2026	28 Februari 2027	Masih didukung, mendekati akhir
1.36	22 April 2026	28 April 2027	28 Juni 2027	Masih didukung
1.37	26 Agustus 2026	28 Agustus 2027	28 Oktober 2027	Masih didukung, terbaru

Tabel itu memperlihatkan pola yang harus diingat: tiga minor terakhir selalu berjarak sekitar empat bulan satu sama lain, dan dukungan tiap jalur sekitar 14 bulan. Artinya ada jendela sekitar enam bulan di mana dua jalur sama-sama didukung penuh, dan jendela itulah waktu paling nyaman untuk pindah.

Untuk tim yang baru akan mulai, memilih 1.37 langsung dari 1.34 tetap harus dilakukan bertahap, karena proyek Kubernetes tidak mendukung lompatan minor. Jalur yang benar adalah 1.34 ke 1.35, lalu 1.35 ke 1.36, lalu 1.36 ke 1.37, masing-masing dengan jeda verifikasi.

Bagaimana urutan upgrade komponen yang didukung?

Urutannya adalah API server lebih dulu, lalu kube-controller-manager dan kube-scheduler, lalu kubelet di setiap node, lalu kube-proxy. Urutan ini bukan preferensi gaya, melainkan konsekuensi dari aturan skew: komponen yang lebih baru tidak boleh mendahului API server.

Aturan skew yang resmi menyebut empat batas. Instance API server dalam satu cluster HA harus berada dalam satu minor satu sama lain. kubelet tidak boleh lebih baru dari API server dan boleh tertinggal sampai tiga minor. kontroler dan scheduler boleh tertinggal paling banyak satu minor dari API server. kubectl boleh berbeda satu minor ke atas atau ke bawah.

Batas-batas itu menjelaskan kenapa urutan tidak boleh dibalik, dan kenapa satu node yang di-upgrade terlalu cepat bisa membuat masalah yang sulit direproduksi. Kalau kubelet di-upgrade lebih dulu ke versi yang lebih baru dari API server, node tersebut secara teknis di luar dukungan, dan masalah yang muncul sesudahnya tidak bisa diklaim sebagai bug.

Kapan patch rutin Kubernetes keluar?

Setiap bulan, pada tanggal yang dijadwalkan proyek rilis. Jadwal yang tercatat setelah Oktober 2026 adalah 10 November 2026, 15 Desember 2026, dan 12 Januari 2027, dengan batas cherry-pick sekitar empat hari sebelum tanggal rilis.

Untuk cluster yang masih hidup di jalur 1.35, perhatikan bahwa jalur itu masuk fase maintenance pada 28 Desember 2026 dan berakhir 28 Februari 2027. Artinya dua patch setelah Desember tidak akan lagi membawa perbaikan untuk jalur tersebut, sehingga jadwal upgrade sebaiknya diletakkan sebelum akhir tahun.

Kebiasaan yang membantu: catat tanggal patch berikutnya, tanggal akhir dukungan, dan minor yang dipakai sekarang di tempat yang sama dengan catatan operasional cluster, supaya ketiganya bisa dibandingkan dalam satu pandangan. Tanpa catatan itu, satu-satunya pengingat biasanya adalah peringatan deprecation dari API server, dan itu datang terlalu dekat dengan tenggat.

Bagaimana langkah kerja upgrade dari 1.34 ke jalur berikutnya?

Lakukan satu minor per jendela maintenance, dengan verifikasi di antara langkah. Melompati satu minor tidak didukung, jadi rangkaian 1.34 ke 1.35 ke 1.36 harus dijalankan sebagai tiga pekerjaan terpisah, bukan satu.

1. Catat versi semua komponen: kubectl version, lalu versi kubelet di tiap node dari kubectl get nodes -o wide.
2. Periksa API yang sudah deprecated dengan melihat metrik apiserver_requested_deprecated_apis pada endpoint metrik API server. API yang masih dipanggil workloads lama akan hilang di minor berikutnya.
3. Periksa apakah ada workload yang bergantung pada fitur alpha atau beta. Fitur beta biasanya berubah perilaku antar-minor, jadi ini sumber kejutan paling sering.
4. Ambil backup objek penting, termasuk etcd, sebelum menyentuh control plane.
5. Upgrade control plane satu node pada satu waktu, mulai dari node tempat API server aktif. Tunggu sampai semua instance API server melaporkan versi baru sebelum melanjutkan.
6. Upgrade kubelet dan kube-proxy per node dengan drain lebih dulu, lalu uncordon setelah node kembali Ready.
7. Ulangi untuk minor berikutnya hanya setelah semua node melaporkan versi yang sama dan workload berjalan normal.

Dokumentasi kubeadm menempatkan langkah control plane dan langkah node sebagai dua fase terpisah, dan itu penting untuk cluster kecil yang hanya punya satu control plane. Pada cluster seperti itu, fase control plane berarti API server berhenti sebentar, jadi jendela maintenance harus benar-benar diumumkan.

Untuk node, drain adalah bagian yang sering menimbulkan gangguan tak terduga. Pod tanpa pengatur replika akan hilang saat drain, dan pod dengan emptyDir kehilangan isi direktorinya. Kedua hal itu perlu diputuskan sebelum eksekusi, bukan ditemukan saat drain setengah jalan.

Bagaimana membuktikan cluster sehat setelah upgrade?

Bukti paling langsung adalah semua node melaporkan versi yang diharapkan dan semua workload inti berjalan. Pemeriksaan itu perlu ditambah dua hal: tidak ada pod yang berputar ulang terus-menerus, dan tidak ada lonjakan event error setelah waktu upgrade.

Perintah yang dipakai berurutan: kubectl get nodes untuk memastikan versi dan status Ready, kubectl get pods -A untuk melihat pod yang tidak berjalan, lalu kubectl get events -A --sort-by=.lastTimestamp untuk melihat kejadian terakhir. Tiga perintah itu cukup untuk menangkap mayoritas masalah pasca-upgrade tanpa alat tambahan.

Setelah itu, uji jalur yang bergantung pada jaringan internal, karena perubahan pada kube-proxy dan aturan service biasanya baru terasa saat trafik nyata masuk. Uji juga satu deployment baru, bukan hanya yang sudah ada, untuk memastikan jalur pembuatan objek masih bekerja.

Simpan hasil pemeriksaan itu sebagai catatan. Ketika masalah muncul beberapa hari kemudian, catatan versi dan waktu upgrade adalah pembeda antara regresi upgrade dan masalah baru yang kebetulan muncul bersamaan.

Satu pemeriksaan tambahan yang layak masuk daftar: pastikan komponen tambahan di luar inti, seperti pengendali ingress, penyedia penyimpanan, dan agen monitoring, juga mendukung minor tujuan. Komponen-komponen ini biasanya punya siklus rilis sendiri, dan dukungannya terhadap minor Kubernetes tertentu bisa tertinggal satu sampai dua rilis. Menemukan itu sebelum upgrade jauh lebih murah daripada menemukannya saat ingress berhenti melayani trafik.

Untuk cluster yang dikelola lewat penyedia layanan, urutan dan jadwal upgrade mengikuti kebijakan penyedia, bukan jadwal proyek Kubernetes. Yang tetap bisa dikendalikan adalah kesiapan workload: API yang deprecated, fitur beta yang dipakai, dan pengujian setelah upgrade.

Apa yang terjadi kalau cluster dibiarkan di versi yang sudah berakhir?

Cluster tetap berjalan, tetapi tidak lagi menerima perbaikan keamanan, dan semua dukungan komunitas untuk jalur itu berhenti. Kerentanan yang ditemukan setelah tanggal akhir dukungan hanya diperbaiki di jalur aktif, sehingga celah yang sudah diketahui publik akan tetap terbuka.

Selain itu, jarak versi menutup pilihan. Setelah tertinggal lebih dari tiga minor, upgrade satu per satu menjadi pekerjaan berantai yang panjang, dan setiap langkah membawa risikonya sendiri. Semakin lama ditunda, semakin besar kemungkinan upgrade harus dilakukan di bawah tekanan insiden, bukan dalam jendela yang tenang.

FAQ

Apakah Kubernetes 1.34 masih bisa dipakai setelah 27 Oktober 2026?

Secara teknis bisa, karena cluster tidak berhenti sendiri. Yang berhenti adalah aliran patch, sehingga tidak ada perbaikan keamanan resmi untuk jalur 1.34 setelah tanggal tersebut.

Bisakah langsung lompat dari 1.34 ke 1.37?

Tidak didukung. Upgrade harus satu minor per langkah: 1.34 ke 1.35, lalu 1.35 ke 1.36, lalu 1.36 ke 1.37, masing-masing dengan verifikasi sebelum lanjut.

Berapa jauh kubelet boleh tertinggal dari API server?

Paling banyak tiga versi minor, dan kubelet tidak boleh lebih baru dari API server. Untuk API server di 1.37, kubelet yang didukung adalah 1.37, 1.36, 1.35, dan 1.34.

Di mana jadwal patch dan akhir dukungan resmi bisa dicek?

Di halaman patch releases dan version skew policy pada situs resmi Kubernetes, plus panduan langkah kubeadm di dokumentasi upgrade kubeadm.