--- title: "Kubernetes 1.34 Sudah EOL, Saatnya Upgrade Cluster" description: "Kubernetes 1.34 berhenti mendapat patch sejak 27 Oktober 2026. Ini jadwal EKS, AKS, GKE, pilihan versi tujuan, dan langkah upgrade yang aman." url: "https://nivelva.com/insight/kubernetes-1-34-eol-upgrade" category: "Server \u0026 Infrastruktur" tags: ["kubernetes","kubernetes 1.34","upgrade cluster","kubeadm","eol"] author: "Lucas Tan" published: "2026-11-12T16:27:00+07:00" updated: "2026-11-12T16:27:00+07:00" language: "id" publisher: "Nivelva (https://nivelva.com)" --- # Kubernetes 1.34 Sudah EOL, Saatnya Upgrade Cluster > **Jawaban singkat:** Kubernetes 1.34 mencapai end of life pada 27 Oktober 2026, jadi tidak ada lagi patch keamanan dari proyek Kubernetes. Cluster yang dikelola sendiri sebaiknya naik ke 1.35, lalu 1.36 atau 1.37, satu minor per langkah, setelah API usang dicek dan etcd dibackup. Masih menjalankan cluster Kubernetes 1.34? Versi itu resmi mencapai end of life (EOL) pada 27 Oktober 2026. Sejak tanggal itu proyek Kubernetes tidak lagi merilis patch untuk 1.34, termasuk perbaikan keamanan. Cluster tidak langsung mati, semua pod tetap berjalan. Masalahnya ada di celah yang ditemukan setelah tanggal itu: tidak akan ada perbaikannya di jalur 1.34. Kalau cluster kamu dikelola sendiri (kubeadm, K3s, atau sejenisnya), sekarang waktunya merencanakan upgrade. ## Apa arti EOL untuk Kubernetes 1.34? Proyek Kubernetes merawat tiga versi minor terbaru, dan tiap versi mendapat sekitar satu tahun patch. Menurut halaman rilis resmi, 1.34 masuk mode pemeliharaan pada 27 Agustus 2026. Sejak saat itu hanya perbaikan keamanan kritis yang diterima. Patch terakhir yang tercantum adalah 1.34.12, rilis 15 September 2026. Per 12 November 2026, versi yang masih dirawat adalah 1.35, 1.36, dan 1.37. Kalau istilah seperti pod, node, dan control plane masih terasa asing, baca dulu [istilah dasar Kubernetes](https://nivelva.com/insight/istilah-dasar-kubernetes-pod-deployment-service) supaya langkah di bawah lebih mudah diikuti. ## Bagaimana dengan EKS, AKS, dan GKE? Layanan Kubernetes terkelola punya jadwal sendiri yang biasanya lebih panjang dari jadwal proyek. Angka di bawah diambil dari dokumentasi masing-masing penyedia per 12 November 2026. | Penyedia | Akhir dukungan standar 1.34 | Catatan | |:--|:--|:--| | Kubernetes (upstream) | 27 Oktober 2026 | Patch terakhir 1.34.12 | | Amazon EKS | 2 Desember 2026 | Setelah itu masuk extended support berbayar sampai 2 Desember 2027 | | Azure AKS | November 2026 | Paket LTS AKS tercantum sampai November 2027 | | Google GKE | 25 Januari 2027 | Google menyebut tanggal ini perkiraan dan bisa berubah | Jadi pengguna layanan terkelola punya sedikit waktu lebih. Tetap saja, extended support di EKS dikenai biaya tambahan per jam cluster, dan penyedia bisa meng-upgrade control plane secara otomatis bila dukungan benar-benar habis. ## Upgrade ke versi berapa? Pilihan realistisnya 1.36 atau 1.37. Menurut halaman rilis Kubernetes, 1.36 dirawat sampai 28 Juni 2027, dan 1.37 sampai 28 Oktober 2027. Kubernetes 1.37 dengan nama "Garhwal" rilis 26 Agustus 2026. Beberapa perubahan yang perlu kamu tahu dari pengumuman resminya: - **KYAML stabil.** Format YAML yang lebih ketat, bisa dipakai lewat `kubectl get -o kyaml`. Manifest YAML lama tetap berlaku. - **Metrics API (`metrics.k8s.io`) stabil di `v1`.** API ini dipakai `kubectl top` dan HPA. Versi `v1beta1` masih bisa dipakai selama masa transisi. - **Pod certificates dan ClusterTrustBundles stabil.** Workload bisa menerima sertifikat X.509 lewat projected volume. - **HPA scale to zero masuk beta dan aktif bawaan.** Hanya berlaku untuk metrik object dan external, dengan `spec.minReplicas: 0`. - **cgroup v1 mulai ditinggalkan.** Kubelet di 1.37 gagal start di node cgroup v1 kecuali `failCgroupV1: false` diset sementara. - **Mode `ipvs` di kube-proxy dan `kube-dns` usang.** Rencananya `ipvs` dimatikan bawaan di 1.40. Satu hal penting: kamu tidak bisa lompat langsung dari 1.34 ke 1.37. Upgrade control plane harus satu minor per langkah, yaitu 1.34 ke 1.35, lalu ke 1.36, lalu ke 1.37. ## Bagaimana langkah upgrade cluster kubeadm? Langkah ini mengikuti dokumentasi resmi kubeadm untuk node Debian atau Ubuntu dengan repositori `pkgs.k8s.io`. Ulangi seluruh rangkaian untuk setiap minor. Contoh di bawah untuk naik ke 1.35. Ganti `1.35.x` dengan patch terbaru yang tercantum di halaman rilis. ### 1. Backup etcd dan cek API usang Simpan snapshot etcd sebelum menyentuh apa pun, misalnya dengan `etcdctl snapshot save`. Lalu cek apakah masih ada klien yang memanggil API usang: ```bash kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis ``` Kalau ada hasil, perbarui manifest, chart Helm, atau operator yang memakai API tersebut. Baca juga catatan rilis tiap versi bagian "Deprecations and removals". ### 2. Ganti repositori paket ke minor baru Repositori `pkgs.k8s.io` dipisah per minor. Ubah `v1.34` menjadi `v1.35` di file `/etc/apt/sources.list.d/kubernetes.list`, lalu jalankan `sudo apt-get update`. Langkah ini sering terlewat, sehingga paket versi baru tidak ditemukan. ### 3. Upgrade kubeadm dan control plane pertama ```bash sudo apt-mark unhold kubeadm sudo apt-get install -y kubeadm='1.35.x-*' sudo apt-mark hold kubeadm sudo kubeadm upgrade plan sudo kubeadm upgrade apply v1.35.x ``` Di control plane lain, cukup jalankan `sudo kubeadm upgrade node` setelah kubeadm diperbarui. ### 4. Upgrade kubelet di tiap node, satu per satu ```bash kubectl drain --ignore-daemonsets sudo apt-mark unhold kubelet kubectl sudo apt-get install -y kubelet='1.35.x-*' kubectl='1.35.x-*' sudo apt-mark hold kubelet kubectl sudo systemctl daemon-reload && sudo systemctl restart kubelet kubectl uncordon ``` Untuk worker node, jalankan `sudo kubeadm upgrade node` sebelum memperbarui kubelet. Jalankan perintah `kubectl` dari mesin yang punya akses admin ke cluster. ### 5. Verifikasi sebelum lanjut ke minor berikutnya Cek `kubectl get nodes` sampai semua node Ready di versi baru, lalu pastikan aplikasi, ingress, dan HPA bekerja normal. Baru setelah itu ulangi langkah 1 sampai 5 untuk 1.36. ## Bagaimana dengan K3s dan cluster kecil? K3s mengikuti nomor versi Kubernetes upstream, jadi K3s 1.34 juga sudah tidak mendapat patch dari jalur upstream. Prinsipnya sama: naik satu minor per langkah, server dulu baru agent. Panduan memasang dan menata cluster ringan ada di artikel [membuat cluster Kubernetes dengan K3s](https://nivelva.com/insight/cluster-kubernetes-k3s). Sambil upgrade, cek juga komponen pihak ketiga. Banyak cluster kecil masih memakai Ingress NGINX yang proyeknya sudah pensiun. Pilihan penggantinya dibahas di [alternatif Ingress NGINX](https://nivelva.com/insight/ingress-nginx-pensiun-alternatif). > **Uji dulu di staging:** > > Jangan upgrade cluster produksi tanpa uji coba. Buat salinan cluster di lingkungan staging, jalankan rangkaian upgrade lengkap, lalu catat apa saja yang rusak. Pastikan juga versi Helm chart, CNI, dan CSI driver yang kamu pakai mendukung versi tujuan. ## Pertanyaan yang sering muncul ## Pertanyaan yang sering diajukan ### Apakah cluster Kubernetes 1.34 berhenti bekerja setelah EOL? Tidak. Cluster tetap berjalan seperti biasa. Bedanya, tidak ada lagi patch keamanan atau perbaikan bug dari proyek Kubernetes untuk 1.34, jadi celah baru tidak akan ditambal. ### Bisakah langsung upgrade dari 1.34 ke 1.37? Tidak untuk control plane. Kubernetes hanya mendukung upgrade satu versi minor per langkah, jadi jalurnya 1.34 ke 1.35, ke 1.36, lalu ke 1.37. ### Berapa lama proses upgrade satu minor? Tergantung jumlah node dan beban aplikasi. Yang paling lama biasanya drain node dan verifikasi aplikasi, bukan perintah kubeadm-nya. Sisihkan jendela pemeliharaan dan lakukan di luar jam sibuk. ### Saya pakai EKS, apakah harus buru-buru? Per 12 November 2026, dukungan standar 1.34 di EKS berakhir 2 Desember 2026. Setelah itu cluster masuk extended support yang berbayar, jadi lebih hemat bila upgrade sebelum tanggal itu. ### Apa yang paling sering bikin upgrade gagal? API usang yang masih dipakai manifest atau chart lama, repositori paket yang lupa diganti ke minor baru, dan add-on seperti CNI atau ingress controller yang belum mendukung versi tujuan. ## Checklist singkat - Catat versi cluster sekarang dengan `kubectl version` dan `kubectl get nodes`. - Backup etcd dan simpan di luar cluster. - Cek API usang dan perbarui manifest atau chart. - Ganti repositori paket ke minor berikutnya. - Upgrade control plane, lalu node satu per satu. - Verifikasi aplikasi, lalu ulangi untuk minor berikutnya sampai 1.36 atau 1.37. ## Sumber - - - - - - - --- Diterbitkan oleh Nivelva Insight (https://nivelva.com/insight/). Artikel ini: https://nivelva.com/insight/kubernetes-1-34-eol-upgrade Kontak Nivelva: WhatsApp https://wa.me/6285111245007, email hello@nivelva.com