Wawancara Backend: Bagaimana cara Anda memigrasikan Service externalIPs di Kubernetes secara aman setelah penghentian penggunaan (deprecation) di v1.36?

Pertanyaan dan cakupan

Anda mengelola kluster bare-metal Kubernetes tempat tim-tim menggunakan Service.spec.externalIPs untuk merutekan alamat publik secara langsung ke Service. Setelah melakukan upgrade ke v1.36, peringatan deprecation muncul dan peninjau keamanan khawatir bahwa seorang tenant dapat mengklaim alamat sembarang dan mencegat lalu lintas jaringan. Rancang sebuah migrasi: temukan dependensi nyata, pilih kontroler LoadBalancer atau Gateway API per titik masuk (entry point), blokir penggunaan baru, dan buktikan mekanisme rollback.

Dokumentasi Kubernetes menyatakan bahwa externalIPs tidak dialokasikan atau diperiksa kepemilikannya oleh Kubernetes. Pada v1.36, field ini didepresiasi; rilis-rilis berikutnya diperkirakan akan menonaktifkan perilaku kube-proxy dan pada akhirnya menghapusnya. Bedakan jendela kompatibilitas saat ini dari target jangka panjang; deprecation bukanlah penghapusan instan.

Konteks dan batasan

Fokuslah pada jaringan Service, RBAC, kebijakan admission, urutan migrasi, dan observabilitas. Cloud load balancer, perangkat jaringan bare-metal, dan DNS adalah dependensi platform; nyatakan kontrak, bukti kepemilikan alamat, jendela entri ganda (dual-entry window), serta fallback saat terjadi kegagalan.

Hal yang diuji oleh pewawancara

• Apakah Anda dapat membedakan field spec externalIPs pada Service dari alamat ExternalIP pada Node dan alamat LoadBalancer yang ditampilkan.
• Apakah Anda dapat menelusuri migrasi menyeluruh dari awal hingga akhir melalui audit, lalu lintas, izin, kontroler, dan DNS.
• Apakah DenyServiceExternalIPs dapat memblokir penulisan baru tanpa menghapus lalu lintas bisnis yang sudah ada.
• Apakah Anda membandingkan batas kepemilikan dan rollback dari kontroler LoadBalancer, kontroler serupa MetalLB, dan Gateway API.
• Apakah metrik dan migrasi bertahap (staged cutover) membuktikan tidak adanya traffic black hole atau pembajakan IP.

Jawaban 30 detik

“Saya akan menginventarisasi spec Service, log audit, DNS, perutean node, dan lalu lintas riil, dengan memetakan setiap externalIP ke tenant, port, dan backend. Selama migrasi, saya akan mengaktifkan DenyServiceExternalIPs untuk memblokir hanya nilai-nilai baru, sehingga objek yang ada tetap dapat dihapus. Untuk setiap titik masuk, saya akan memilih kontroler LoadBalancer yang dikontrol administrator atau Gateway API, memvalidasi health check, alamat sumber, dan connection draining melalui jalur paralel, lalu mengalihkan DNS atau upstream. Setelah lalu lintas lama mencapai nol, hapus externalIPs, pertahankan snapshot rollback, dan awasi peluncuran dengan metrik audit, 5xx, kegagalan koneksi, serta konflik alamat.”

Solusi langkah demi langkah

1. Bangun inventarisasi. Buat daftar setiap Service yang menggunakan externalIPs, alamat-alamatnya, port, namespace, pemilik, TTL DNS, protokol, EndpointSlices, external traffic policy, dan lalu lintas terkini. Pisahkan field tersebut dari entri .status.addresses pada Node yang bernama ExternalIP.

1. Modelkan risiko keamanan. Pengguna menuliskan externalIPs ke dalam spec Service sementara Kubernetes tidak mengalokasikan alamat tersebut atau menjamin keunikannya. Tenant dengan tingkat kepercayaan rendah dapat mengklaim alamat milik tenant lain dan mencegat lalu lintas. Audit operasi pembuatan, pembaruan, penghapusan, dan aturan kube-proxy, lalu korelasikan anomali berdasarkan alamat dan tenant.

1. Blokir penggunaan baru terlebih dahulu. Aktifkan DenyServiceExternalIPs. Fitur ini menolak Service baru yang menggunakan field tersebut dan nilai baru yang ditambahkan ke Service yang sudah ada, sementara penghapusan nilai yang ada tetap dimungkinkan. Uji dalam mode audit atau kluster berisiko rendah sebelum diberlakukan; migrasikan objek yang ada secara terpisah.

1. Pilih penggantinya. Di lingkungan cloud, utamakan type: LoadBalancer yang dikontrol administrator. Pada bare-metal, gunakan kontroler dengan pool alamat dan pemeriksaan konflik. Jika pemisahan peran atau perutean bersama menjadi hal penting, gunakan Gateway API: platform memiliki Gateway dan aplikasi mengelola objek HTTPRoute yang dibatasi.

kind: Gateway
apiVersion: gateway.networking.k8s.io/v1
spec:
  gatewayClassName: platform-public
  addresses:
  - type: IPAddress
    value: 192.0.2.4

Ini hanya mengilustrasikan pengalamatan yang dimiliki administrator. Verifikasi GatewayClass, kapabilitas kontroler, sertifikat, dan pool IP untuk deployment sebelum menerapkannya.

1. Jalankan validasi paralel. Tempatkan titik masuk baru di balik hostname terpisah atau DNS dengan TTL rendah, lalu bandingkan keberhasilan koneksi, TLS, alamat sumber, koneksi berdurasi panjang, health check, dan konvergensi EndpointSlice. Jika menggunakan kembali sebuah IP, catat kepemilikannya di kontroler baru sebelum mengalihkan upstream sehingga dua implementasi tidak pernah mengumumkannya secara bersamaan.

1. Drain dan hapus. Pastikan tidak ada koneksi baru pada titik masuk lama dan tunggu hingga masa pakai koneksi maksimum tercapai. Hapus externalIPs sambil tetap mempertahankan bukti audit dan snapshot rollback. Urutan langkah harus mempertahankan setidaknya satu jalur yang dapat diverifikasi di antara DNS, load balancer, Service, dan backend.

1. Rencanakan versi dan rollback. v1.36 memunculkan peringatan deprecation; linimasa yang dipublikasikan memperkirakan perilaku kube-proxy akan dinonaktifkan paling cepat pada v1.40 dan penghapusan penuh paling cepat pada v1.43. Rollback hanya memulihkan titik masuk lama yang kepemilikannya telah divalidasi; ini tidak pernah membuka kembali penulisan sembarang oleh tenant. Jika penggantinya gagal, kembalikan konfigurasi DNS atau kontroler untuk sementara waktu sambil terus memblokir risiko baru.

Jawaban model

Saya akan memperlakukan setiap externalIP sebagai aset migrasi, bukan sebagai field yang diganti secara membabi buta. Inventarisasi API, audit, DNS, aturan node, dan log lalu lintas menentukan alamat, tenant, port, masa pakai koneksi, dan kepemilikan. Field ini adalah spec Service yang dapat ditulis oleh pengguna dan Kubernetes tidak mengalokasikan atau memeriksa konfliknya, yang menciptakan risiko intersepsi kelas CVE-2020-8554.

Selama migrasi, saya akan mengaktifkan DenyServiceExternalIPs untuk menolak penambahan sekaligus mempertahankan kemampuan penghapusan nilai yang ada. Penggantinya bergantung pada titik masuk: LoadBalancer cloud, kontroler bare-metal dengan pool alamat administrator, atau Gateway API dengan Gateway milik platform dan rute terbatas milik aplikasi. Hostname paralel atau cutover dengan TTL rendah membandingkan perilaku koneksi, TLS, alamat sumber, dan health check sebelum menguras (drain) koneksi lama dan menghapus field tersebut.

Rencana ini mencatat peringatan pada v1.36, perkiraan paling cepat perubahan perilaku kube-proxy pada v1.40, dan perkiraan paling cepat penghapusan penuh pada v1.43. Rollback hanya memulihkan titik masuk milik administrator yang telah divalidasi. Saya akan melacak konflik alamat, 5xx, kegagalan koneksi, latensi propagasi DNS, dan Service yang tersisa.

Kesalahan umum

• Kesalahan: Menganggap deprecation sebagai penghapusan instan → Penyebab kegagalan: jendela kompatibilitas salah dipahami dan menyebabkan downtime yang tidak direncanakan → Solusi: rencanakan peringatan, penonaktifan perilaku, dan penghapusan sebagai milestone yang terpisah.
• Kesalahan: Mengganti externalIPs secara langsung dengan loadBalancerIP → Penyebab kegagalan: pool alamat dan pemeriksaan konflik mungkin masih dapat dilewati → Solusi: biarkan kontroler yang dikendalikan administrator mengalokasikan dan memublikasikan status.
• Kesalahan: Menghapus setiap field lama saat penegakan admission dimulai → Penyebab kegagalan: tidak ada bukti lalu lintas atau connection draining → Solusi: blokir penambahan, lakukan uji canary pada pengganti, drain, lalu hapus berdasarkan aset.
• Kesalahan: Hanya memeriksa Service, bukan DNS, aturan node, dan lalu lintas → Penyebab kegagalan: titik masuk tersembunyi atau black hole tetap ada → Solusi: pertahankan inventarisasi migrasi menyeluruh dan jendela observasi.
• Kesalahan: Membiarkan tenant memiliki alamat Gateway → Penyebab kegagalan: pengganti menciptakan kembali kelemahan izin yang sama → Solusi: Gateway dimiliki platform dan rute aplikasi dibatasi.

Pertanyaan lanjutan dan jawaban

Apakah DenyServiceExternalIPs memengaruhi Service yang sudah ada?

Fitur ini menolak Service baru yang menggunakan field tersebut dan nilai baru yang ditambahkan ke Service yang sudah ada; menghapus nilai yang ada tetap dimungkinkan. Verifikasi perilaku ini pada versi target dan amati event penolakan. Ini adalah pengaman (guard), bukan alat migrasi otomatis.

Mengapa tidak mengisi IP LoadBalancer secara manual pada bare-metal?

Penetapan manual tetap tidak memiliki pool alamat, deteksi konflik, status kesehatan, dan audit. Kontroler dengan pool milik administrator menjadikan alokasi, pelepasan, dan keunikan sebagai tanggung jawab platform; alamat statis tetap memerlukan persetujuan eksplisit.

Bagaimana Gateway API dapat mempertahankan self-service untuk aplikasi?

Platform membuat Gateway dan GatewayClass serta membatasi alamat, listener, dan referensi lintas-namespace. Tim aplikasi mengirimkan HTTPRoute yang tunduk pada kebijakan referensi, objek kebijakan, dan kontrol audit.

Bagaimana Anda menangani koneksi berdurasi panjang dan WebSocket?

Ukur masa pakai koneksi sebelum mengalihkan DNS atau titik masuk. Hentikan koneksi baru pada jalur lama tetapi izinkan koneksi yang ada untuk mengering (drain), dengan menggunakan perilaku retry dual-entry jika sesuai. Pisahkan kegagalan koneksi baru dari penutupan alami dalam metrik.

Kapan switch rollback dapat dihapus?

Setelah lalu lintas lama bernilai nol, setiap Service telah menghapus field tersebut, pemeriksaan konflik alamat lolos, jendela TTL DNS berakhir, dan jalur baru memenuhi SLO observasinya. Kemudian hapus snapshot sambil mempertahankan bukti audit; tanggal kalender tidak dapat menggantikan bukti nyata.

Referensi

• Deprecasi Service ExternalIPs Kubernetes v1.36 (Blog Kubernetes)
• Dokumentasi Service (Dokumentasi Kubernetes)
• Dokumentasi Admission Control (Dokumentasi Kubernetes)
• Dokumentasi Gateway API (Dokumentasi Kubernetes)

Checklist wawancara

Pisahkan semantik field dari risiko keamanan, lalu sebutkan urutannya: inventarisasi, blokir penambahan, titik masuk pengganti, validasi paralel, drain, penghapusan, dan rollback.

Poin penting dalam satu kalimat

Migrasi ExternalIPs menggantikan titik masuk yang dapat ditulis pengguna dengan jalur alokasi alamat yang dapat diverifikasi, diaudit, dan dimiliki oleh administrator.

Terus berlatih

Jika sebuah kluster menggunakan Gateway API, MetalLB, dan cloud LoadBalancer secara bersamaan, rancang satu katalog titik masuk, model kepemilikan alamat, dan protokol rollback lintas-lingkungan.