kube-proxy ipvs Deprecated: Migrasi ke nftables Sebelum v1.40

Kalimat yang harus membuat operator ipvs berhenti sejenak itu pendek. Release post Kubernetes v1.37 menyebut cluster yang menjalankan kube-proxy dalam mode ipvs kini mencatat deprecation warning saat startup, lalu memberi timeline yang berakhir dengan kodenya dihapus. Hari ini belum ada yang rusak. Justru itu risikonya: migrasi menumpuk di backlog sampai upgrade versi mengubahnya jadi outage.

Saya membaca sumber primernya sampai habis: post sneak peek dan release v1.37, dokumentasi virtual IP Kubernetes, referensi konfigurasi kube-proxy, KEP-5495 (deprecation) dan KEP-3866 (backend nftables), ditambah post nftables kube-proxy tahun 2025. Setiap tanggal, flag, dan nama metrik di bawah berasal dari salah satunya. Saya tidak menjalankan benchmark, jadi tidak ada angka performa dari saya di sini, dan bagian yang tidak dijawab sumber saya tandai.

Timeline ipvs, versi demi versi

Tiga dokumen Kubernetes menyebut jadwalnya: halaman docs virtual IP, release post v1.37, dan KEP-5495. Ketiganya sepakat soal titik akhirnya. Bedanya ada di kapan warning mulai muncul, yang penting kalau Anda mencari di log lama.

Sebagian tulisan menyebut warning muncul di v1.37; KEP dan halaman docs menaruhnya di v1.35, sementara release post hanya bilang warning dicatat sekarang. Anggap v1.40 sebagai tenggat selesai, bukan titik mulai. Sampai saat itu jalan daruratnya hanyalah feature gate, dan gate yang dibuat untuk di-flip bukan tempat tinggal. Release post menulis langkah v1.40 dan v1.43 sebagai ekspektasi, jadi baca ulang halaman docs untuk minor version Anda sebelum menjadwalkan.

Kenapa ipvs kalah: maintainer dan API yang tidak cocok

Alasan langsungnya soal maintenance. KEP-5495 menyatakan sig-network kekurangan maintainer yang paham kode backend ipvs, dan selama ini mengarahkan pelapor bug ipvs untuk pindah ke backend nftables bila bisa. Backend nftables, yang diperkenalkan KEP-3866, memang dirancang sejak awal untuk menggantikan ipvs dan iptables.

Alasan desainnya lebih lama. Halaman docs menulis mode ipvs berhasil mencapai tujuannya, performa sinkronisasi rule yang lebih baik dan throughput lebih tinggi dari iptables, tetapi API IPVS di kernel ternyata tidak cocok dengan API Service Kubernetes dan backend itu tidak pernah benar-benar mengimplementasikan semua edge case fungsi Service. Release post menambahkan bahwa mode ipvs masih memakai iptables di bawahnya. Post 2025 memberi dua contoh konkret: device kube-ipvs0 harus memegang setiap alamat IP Service, dan Service yang endpoint-nya berbeda untuk client lokal dan remote sulit diekspresikan.

Fitur yang paling sering dikhawatirkan hilang adalah pilihan scheduler, dari rr dan lc sampai mh. Post 2025 berargumen fitur ini tidak berguna dalam praktik: kube-proxy berjalan independen di tiap node, dan scheduler di tiap node tidak punya cara berbagi state dengan proxy di node lain. KEP-5495 bahkan merencanakan blog post tentang mengapa scheduler IPVS sebenarnya tidak berguna di Kubernetes, yang menurutnya banyak pengguna ipvs belum sadari. Kalau alasan Anda memakai ipvs adalah least-connection, pastikan dulu fitur itu benar-benar bekerja seperti yang Anda kira.

Audit dulu: mode apa yang benar-benar jalan di tiap cluster

Sebelum merencanakan apa pun, cari tahu apa yang dijalankan tiap cluster. Perintah pertama di bawah berasal dari release post; dua lainnya dari saya, untuk distribusi yang tidak memakai layout ConfigMap ala kubeadm.

# 1. The command from the Kubernetes v1.37 release post. It assumes kube-proxy
#    reads its config from a ConfigMap in kube-system (the kubeadm layout).
kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep 'mode:'
#    An empty mode means the default, which is iptables in 1.37.

# 2. If your distribution passes flags instead of a ConfigMap, read the args.
kubectl -n kube-system get daemonset kube-proxy \
  -o jsonpath='{.spec.template.spec.containers[0].command}'
#    Look for --proxy-mode=ipvs or a --config file path.

# 3. Find ipvs-only tuning you will lose. The scheduler is the usual one.
kubectl -n kube-system get configmap kube-proxy \
  -o jsonpath='{.data.config\.conf}' | grep -A8 '^ipvs:'

Dua hasil bacaan perlu hati-hati. Field mode yang kosong bukan ipvs: docs menyebut mode yang tidak diset memakai default yang direkomendasikan, yaitu iptables di v1.37, dan versi mendatang akan mengubah default ke nftables. Docs menyarankan mode diset eksplisit di setiap cluster supaya upgrade tidak menukar backend diam-diam. Lalu di managed Kubernetes, penyedia biasanya memegang setting ini; saya tidak meneliti satu pun penyedia, jadi cek dokumentasinya sebelum mengira Anda bisa mengubahnya.

ipvs lawan nftables, pada hal-hal yang menentukan migrasi

Halaman docs menyebut mode nftables pada dasarnya pengganti mode iptables dan ipvs, dan merekomendasikannya sebagai pengganti ipvs. Tabel ini menyandingkan kedua backend pada perbedaan yang mengubah apa yang Anda operasikan.

Baris performa perlu dibaca hati-hati. Post 2025 menampilkan grafik yang tidak saya salin, dan tak satu pun sumber memberi angka yang bisa saya kutip, jadi klaim yang bisa dipertanggungjawabkan adalah tidak ada regresi, bukan lebih cepat. Ukur di cluster Anda sendiri. Docs menambah satu fakta untuk fleet lama: kalau node terlalu tua untuk mode nftables, pertimbangkan mode iptables daripada ipvs, karena performa iptables sudah jauh membaik sejak ipvs diperkenalkan.

Preflight: kernel, binary nft di host, dan komponen tetangga

Tiga hal bisa menggagalkan cutover sebelum dimulai: kernel, binary nft di host, dan software lain yang menyentuh netfilter. Jalankan pengecekan di bawah pada setiap node pool, bukan hanya satu node wakil.

# Run on every node pool before you touch kube-proxy.

# Kernel: nftables mode needs 5.13 or later.
uname -r

# Host nft binary: the 2025 kube-proxy post says not to run nftables mode on
# nodes whose host filesystem has an nft older than 1.0.0, because early
# versions of the tool can interfere with other nftables users on the machine.
# No nft installed is fine; an old one is the problem.
nft --version

# Whole fleet at a glance (kubectl reports the kernel per node).
kubectl get nodes -o custom-columns='NODE:.metadata.name,KERNEL:.status.nodeInfo.kernelVersion'

# Who else writes netfilter rules? A CNI or NetworkPolicy engine that edits
# kube-proxy's iptables chains directly is the case to read the docs for.
kubectl -n kube-system get pods -o wide | grep -i -E 'calico|cilium|flannel|weave|antrea'

Kernel tidak sepelik kelihatannya. KEP-5495 menyebut semua kernel yang terlalu tua untuk mode nftables sudah keluar dari LTS pada akhir 2026, tetapi tetap mencantumkan kernel lama sebagai kekurangan utama seluruh rencana. Soal komponen tetangga, post 2025 menyebut kebanyakan komponen jaringan tidak peduli selama tidak mencoba berinteraksi atau menimpa rule iptables kube-proxy, tetapi tool monitoring yang belum diperbarui bisa melaporkan data lebih sedikit di mode nftables. Baca dokumentasi CNI dan NetworkPolicy Anda untuk pernyataan eksplisit.

Cutover: satu edit config dan satu restart

Editnya kecil. Post 2025 menyebut cluster yang ada dikonversi dengan memperbarui konfigurasi kube-proxy dan me-restart pod kube-proxy, tanpa reboot node, karena kube-proxy menghapus rule iptables atau ipvs yang ada saat start di mode nftables.

# kube-proxy config.conf after the change. Field names are from the
# KubeProxyConfiguration v1alpha1 reference.
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration

# Always set the mode explicitly. The docs warn that the default will change
# from iptables to nftables in a future release, and that you should pin it
# so an upgrade cannot change your proxy backend under you.
mode: nftables

# nftables mode defaults to "primary" (the node's primary IPs). iptables and
# ipvs defaulted to "all". Leave it as primary only if nothing relies on a
# NodePort answering on every local address.
nodePortAddresses:
  - primary

# ipvs: block deleted on purpose. A leftover scheduler setting does nothing
# useful here, and the KEP suggests keeping the old ipvs flags as warned
# no-ops so a forgotten one does not hide.

# Apply and roll. No node reboot is needed: per the 2025 post, kube-proxy
# deletes the old iptables or ipvs rules when it starts in nftables mode.
kubectl -n kube-system edit configmap kube-proxy
kubectl -n kube-system rollout restart daemonset kube-proxy
kubectl -n kube-system rollout status daemonset kube-proxy

# On a node: the proxy now owns an nftables table named kube-proxy, and a
# single verdict map dispatches Service traffic.
nft list table ip kube-proxy | head -40

# Rollback is the same edit in reverse: set mode back and restart. Reverting
# makes kube-proxy delete its nftables rules, per the same post.

Risikonya bukan di editnya, melainkan di tempat Anda menerapkannya. Me-restart DaemonSet me-restart proxy di setiap node sekaligus, jadi lakukan di cluster staging dulu dan biarkan soak sebelum production. Memecah satu node pool dengan DaemonSet kedua mungkin saja bisa; saya belum mengujinya dan docs tidak menjelaskannya, jadi tidak saya tampilkan. Rollback adalah edit yang sama dibalik, alasan nyata untuk menyimpan config lama di version control.

Yang rusak: empat perbedaan bernama dan satu tanpa saklar

Ini berasal dari bagian docs tentang migrasi dari mode iptables ke nftables, dicocokkan dengan referensi konfigurasi. Mode ipvs punya default semua alamat untuk NodePort seperti mode iptables, jadi perbedaan pertama berlaku juga untuk Anda.

• Alamat NodePort menyempit. Default nftables adalah primary, jadi NodePort hanya menjawab di alamat IPv4 dan/atau IPv6 utama node. Probe atau script yang memakai alamat sekunder jadi sunyi. Set nodePortAddresses secara eksplisit; docs memberi contoh 0.0.0.0/0 untuk semua IPv4 lokal.
• NodePort di localhost butuh opt-in. Awalnya ini tidak jalan di mode nftables. v1.37 menambahkan userspace proxy opt-in, alpha dan di balik feature gate KubeProxyNFTablesLocalhostNodePorts, diaktifkan dengan mencantumkan localhost di nodePortAddresses. Referensi konfigurasi menyebut di mode nftables ini hanya melayani TCP. Contoh di release post adalah container registry lokal yang diakses lewat localhost dengan NodePort.
• Firewall host jadi urusan Anda. Mode iptables menambah rule yang menerima traffic NodePort masuk kalau-kalau firewall memblokirnya. Mode nftables tidak melakukan apa-apa di situ, jadi firewall lokal harus mengizinkan seluruh rentang NodePort sendiri.
• Workaround conntrack hilang. Kernel sebelum 6.1 punya bug yang bisa menutup koneksi TCP berumur panjang ke IP Service dengan error Connection reset by peer. Mode iptables memasang workaround yang belakangan menimbulkan masalah lain; mode nftables tidak memasang apa pun secara default. Kalau counter-nya bergerak, jalankan kube-proxy dengan conntrack-tcp-be-liberal.

# Ask kube-proxy whether anything depends on the behaviours nftables mode
# changes. The docs name these two counters in the iptables-to-nftables
# section. Non-zero means yes. I could not confirm that ipvs mode exports them,
# so an empty result on an ipvs node proves nothing.
curl -s 127.0.0.1:10249/metrics | grep -E \
  'iptables_localhost_nodeports_accepted_packets_total|iptables_ct_state_invalid_dropped_packets_total'

# Wrong: assume a localhost NodePort keeps working because "it is just a mode".
# Right: only if you opt in (alpha in 1.37, TCP only, loopback listed explicitly).
#   featureGates:
#     KubeProxyNFTablesLocalhostNodePorts: true
#   nodePortAddresses: ["primary", "localhost"]

# Old-kernel workaround for dropped long-lived TCP connections ("Connection
# reset by peer", kernels before 6.1). Only if the conntrack counter above moved:
#   kube-proxy --conntrack-tcp-be-liberal

Perbedaan kelima tidak punya saklar: mode nftables memilih backend secara acak. Siapa pun yang memakai sh atau mh untuk stickiness harus memindahkan kebutuhan itu ke tempat lain sebelum cutover. Sumber tidak menyebut pengganti satu-lawan-satu dan saya tidak akan mengarangnya.

Yang dilakukan hari Senin

Enam langkah, berurutan. Tiga pertama tidak berbiaya dan menghilangkan kejutan walau Anda tidak migrasi kuartal ini.

1. Jalankan perintah audit di setiap cluster dan catat mode serta minor version kube-proxy di satu tempat.
2. Pin mode secara eksplisit di setiap config kube-proxy, termasuk cluster iptables, karena docs menyebut default akan berubah ke nftables di rilis mendatang.
3. Daftar kernel dan versi nft host di setiap node, dan tandai pool di bawah kernel 5.13 atau dengan nft lebih tua dari 1.0.0.
4. Di staging, pindah ke mode nftables dan uji setiap NodePort di semua alamat yang benar-benar Anda pakai, NodePort localhost bila ada, dan rule firewall host.
5. Untuk pool yang tidak bisa menjalankan mode nftables, rencanakan mode iptables daripada bertahan di ipvs, seperti saran docs.
6. Jadwalkan production sebelum upgrade ke v1.40. Setelah gate itu di-flip, cluster yang masih mode ipvs tanpa override akan membuat kube-proxy keluar dengan error.

Post ini mencerminkan dokumen seperti yang saya baca pada 17 Oktober 2026. Nomor versi setelah v1.37 adalah rencana, jadi cek halaman virtual IP untuk rilis Anda sebelum bertindak berdasarkan tanggal.

Aturan yang dibawa pulang: mode kube-proxy yang deprecated adalah migrasi dengan tenggat dalam hitungan minor release, dan pekerjaannya sebagian besar bukan baris config melainkan empat perilaku di sekitarnya. Pin mode, cek kernel, ubah satu cluster, dan biarkan tes NodePort serta firewall memberi tahu apa yang selama ini Anda andalkan.