Temu duga backend: Bagaimanakah anda akan memindahkan Kubernetes Service externalIPs secara selamat selepas usang (deprecation) dalam v1.36?

Soalan dan skop

Anda menguruskan kluster Kubernetes bare-metal di mana pasukan menggunakan Service.spec.externalIPs untuk menghalakan alamat awam secara terus ke Service. Selepas menaik taraf ke v1.36, amaran pengusangan (deprecation warnings) muncul dan penyemak keselamatan bimbang bahawa penyewa (tenant) boleh menuntut alamat sewenang-wenangnya dan memintas trafik. Reka bentuk satu migrasi: kenal pasti kebergantungan sebenar, pilih pengawal LoadBalancer atau Gateway API bagi setiap titik masuk, sekat penggunaan baharu, dan buktikan keupayaan pengunduran (rollback).

Dokumentasi Kubernetes menyatakan bahawa externalIPs tidak diperuntukkan atau disahkan pemilikan oleh Kubernetes. Dalam v1.36, medan ini telah diusangkan; keluaran seterusnya dijangka akan menyahdayakan kelakuan kube-proxy dan akhirnya membuangnya terus. Bezakan tetingkap keserasian semasa daripada sasaran jangka panjang; pengusangan bukanlah pemadaman serta-merta.

Konteks dan sempadan

Fokus pada perangkaian Service, RBAC, dasar kemasukan (admission policy), susunan migrasi, dan kebolehcerapan (observability). Pengimbang beban awan (cloud load balancers), peranti rangkaian bare-metal, dan DNS adalah kebergantungan platform; nyatakan kontrak, bukti pemilikan alamat, tetingkap dwi-titik masuk (dual-entry window), dan pelan sandaran kegagalan (failure fallback) bagi komponen tersebut.

Perkara yang diuji oleh penemu duga

• Sama ada anda membezakan medan spesifikasi Service externalIPs daripada alamat Node ExternalIP dan alamat LoadBalancer yang dipaparkan.
• Sama ada anda boleh menjejaki migrasi hujung-ke-hujung melalui audit, trafik, kebenaran, pengawal (controllers), dan DNS.
• Sama ada DenyServiceExternalIPs boleh menyekat penulisan baharu tanpa memadamkan trafik perniagaan sedia ada.
• Sama ada anda membandingkan sempadan pemilikan dan pengunduran bagi pengawal LoadBalancer, pengawal seumpama MetalLB, dan Gateway API.
• Sama ada metrik dan peralihan berperingkat (staged cutover) membuktikan tiada lohong hitam trafik (traffic black hole) atau rampasan IP (IP hijack).

Jawapan 30 saat

“Saya akan menginventorikan spesifikasi Service, log audit, DNS, penghalaan nod, dan trafik sebenar, dengan memetakan setiap externalIP kepada penyewa, port, dan backend. Semasa migrasi, saya akan mendayakan DenyServiceExternalIPs untuk menyekat nilai baharu sahaja, sambil membiarkan objek sedia ada boleh dibuang. Bagi setiap titik masuk, saya akan memilih pengawal LoadBalancer kawalan pentadbir atau Gateway API, mengesahkan pemeriksaan kesihatan (health checks), alamat sumber, dan penyaliran sambungan (connection draining) melalui laluan selari, kemudian menukar DNS atau huluan (upstream). Selepas trafik lama mencapai sifar, buang externalIPs, simpan syot kilat (snapshot) pengunduran, dan kawal pelancaran dengan metrik audit, 5xx, kegagalan sambungan, dan konflik alamat.”

Penyelesaian langkah demi langkah

1. Bina inventori. Senaraikan setiap Service yang menggunakan externalIPs, alamat, port, ruang nama (namespace), pemilik, TTL DNS, protokol, EndpointSlices, dasar trafik luaran (external traffic policy), dan trafik terkini. Asingkan medan ini daripada entri Node .status.addresses yang dinamakan ExternalIP.

1. Modelkan risiko keselamatan. Pengguna menulis externalIPs ke dalam spesifikasi Service manakala Kubernetes tidak memperuntukkan alamat tersebut atau menjamin keunikannya. Penyewa dengan tahap kepercayaan rendah (low-trust tenant) boleh menuntut alamat penyewa lain dan memintas trafik. Audit operasi cipta, kemas kini, padam, dan peraturan kube-proxy, sambil menghubungkaitkan anomali mengikut alamat dan penyewa.

1. Sekat penggunaan baharu terlebih dahulu. Dayakan DenyServiceExternalIPs. Ia menolak Service baharu yang menggunakan medan tersebut dan nilai baharu yang ditambah pada Service sedia ada, manakala pembuangan nilai sedia ada kekal dibenarkan. Uji dalam mod audit atau kluster berisiko rendah sebelum penguatkuasaan; pindahkan objek sedia ada secara berasingan.

1. Pilih pengganti. Dalam persekitaran awan, utamakan type: LoadBalancer kawalan pentadbir. Pada bare-metal, gunakan pengawal dengan kolam alamat (address pool) dan pemeriksaan konflik. Apabila pemisahan peranan atau penghalaan berkongsi adalah penting, gunakan Gateway API: platform memiliki Gateway dan aplikasi menguruskan objek HTTPRoute yang dihadkan.

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

Ini menggambarkan pengalamatan milik pentadbir sahaja. Sahkan GatewayClass, keupayaan pengawal, sijil, dan kolam IP untuk penggunaan sebelum melaksanakannya.

1. Jalankan pengesahan selari. Letakkan titik masuk baharu di belakang nama hos berasingan atau DNS TTL rendah dan bandingkan kejayaan sambungan, TLS, alamat sumber, sambungan jangka panjang, pemeriksaan kesihatan, dan penumpuan EndpointSlice. Jika menggunakan semula IP, rekod pemilikan dalam pengawal baharu sebelum menukar huluan supaya dua pelaksanaan tidak mengumumkannya secara serentak.

1. Salirkan dan buang. Pastikan tiada sambungan baharu pada titik masuk lama dan tunggu sehingga jangka hayat sambungan maksimum tamat. Buang externalIPs sambil mengekalkan bukti audit dan syot kilat pengunduran. Susunan ini mesti mengekalkan sekurang-kurangnya satu laluan yang boleh disahkan antara DNS, pengimbang beban, Service, dan backend.

1. Rancang versi dan pengunduran. v1.36 mengeluarkan amaran pengusangan; garis masa yang diterbitkan menjangkakan kelakuan kube-proxy dinyahdayakan paling awal dalam v1.40 dan pembuangan penuh paling awal dalam v1.43. Pengunduran hanya memulihkan titik masuk lama yang telah disahkan pemilikannya; ia tidak sekali-kali membuka semula penulisan penyewa sewenang-wenangnya. Jika penggantian gagal, kembalikan konfigurasi DNS atau pengawal buat sementara waktu sambil terus menyekat risiko baharu.

Jawapan model

Saya akan menganggap setiap externalIP sebagai aset migrasi, bukan sekadar medan untuk diganti secara membuta tuli. Inventori API, audit, DNS, peraturan nod, dan log trafik menetapkan alamat, penyewa, port, jangka hayat sambungan, dan pemilikan. Medan ini adalah spesifikasi Service yang boleh ditulis oleh pengguna dan Kubernetes tidak memperuntukkan atau menyemak konfliknya, yang mewujudkan risiko pemintasan kelas CVE-2020-8554.

Semasa migrasi, saya akan mendayakan DenyServiceExternalIPs untuk menolak penambahan sambil mengekalkan pembuangan nilai sedia ada. Penggantian bergantung pada titik masuk: LoadBalancer awan, pengawal bare-metal dengan kolam alamat pentadbir, atau Gateway API dengan Gateway milik platform dan laluan dihadkan milik aplikasi. Nama hos selari atau peralihan TTL rendah membandingkan kelakuan sambungan, TLS, alamat sumber, dan pemeriksaan kesihatan sebelum menyalirkan sambungan lama dan membuang medan tersebut.

Pelan ini merekodkan amaran v1.36, perubahan kelakuan kube-proxy terawal yang dijangka pada v1.40, dan pembuangan penuh terawal pada v1.43. Pengunduran hanya memulihkan titik masuk milik pentadbir yang telah disahkan. Saya akan menjejaki konflik alamat, 5xx, kegagalan sambungan, kelewatan penyebaran DNS, dan baki Service yang tinggal.

Kesilapan lazim

• Kesilapan: Menganggap pengusangan sebagai pemadaman serta-merta → Sebab ia gagal: tetingkap keserasian disalah tafsir dan menyebabkan masa henti yang tidak dirancang → Penyelesaian: rancang amaran, penyahdayaan kelakuan, dan pembuangan sebagai pencapaian berasingan.
• Kesilapan: Menggantikan externalIPs secara terus dengan loadBalancerIP → Sebab ia gagal: kolam alamat dan pemeriksaan konflik masih boleh dipintas → Penyelesaian: biarkan pengawal kawalan pentadbir memperuntukkan dan menerbitkan status.
• Kesilapan: Memadam setiap medan lama apabila penguatkuasaan kemasukan bermula → Sebab ia gagal: tiada bukti trafik atau penyaliran sambungan → Penyelesaian: sekat penambahan, uji rintis (canary) pengganti, salirkan, kemudian buang mengikut aset.
• Kesilapan: Hanya menyemak Service, bukan DNS, peraturan nod, dan trafik → Sebab ia gagal: titik masuk tersembunyi atau lohong hitam kekal wujud → Penyelesaian: kekalkan inventori migrasi hujung-ke-hujung dan tetingkap pemerhatian.
• Kesilapan: Membiarkan penyewa memiliki alamat Gateway → Sebab ia gagal: penggantian ini mewujudkan semula kelemahan kebenaran yang sama → Penyelesaian: gunakan Gateway milik platform dan laluan aplikasi yang dihadkan.

Soalan susulan dan jawapan

Adakah DenyServiceExternalIPs menjejaskan Service sedia ada?

Ia menolak Service baharu yang menggunakan medan tersebut dan nilai baharu yang ditambah pada Service sedia ada; membuang nilai sedia ada kekal dibenarkan. Sahkan kelakuan ini dalam versi sasaran dan perhatikan peristiwa penolakan. Ia adalah pengawal keselamatan, bukan alat migrasi automatik.

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

Penetapan manual masih kekurangan kolam alamat, pengesanan konflik, status kesihatan, dan audit. Pengawal dengan kolam milik pentadbir menjadikan peruntukan, pelepasan, dan keunikan sebagai tanggungjawab platform; alamat tetap masih memerlukan kelulusan eksplisit.

Bagaimanakah Gateway API boleh mengekalkan layan diri (self-service) aplikasi?

Platform mencipta Gateway dan GatewayClass serta mengehadkan alamat, pendengar (listeners), dan rujukan silang ruang nama (cross-namespace references). Pasukan aplikasi menyerahkan HTTPRoutes tertakluk kepada dasar rujukan, objek dasar, dan kawalan audit.

Bagaimanakah anda mengendalikan sambungan jangka panjang dan WebSockets?

Ukur jangka hayat sambungan sebelum menukar DNS atau titik masuk. Hentikan sambungan baharu pada laluan lama tetapi benarkan sambungan sedia ada disalirkan keluar, dengan menggunakan kelakuan percubaan semula dwi-titik masuk di mana sesuai. Asingkan kegagalan sambungan baharu daripada penutupan biasa dalam metrik.

Bilakah suis pengunduran boleh dibuang?

Selepas trafik lama menjadi sifar, setiap Service telah membuang medan tersebut, semakan konflik alamat lulus, tetingkap TTL DNS berakhir, dan laluan baharu memenuhi SLO pemerhatiannya. Kemudian buang syot kilat sambil mengekalkan bukti audit; tarikh kalendar tidak boleh menggantikan bukti sebenar.

Rujukan

• Pengusangan Service ExternalIPs Kubernetes v1.36 (Blog Kubernetes)
• Dokumentasi Service (Dokumentasi Kubernetes)
• Dokumentasi Kawalan Kemasukan / Admission Control (Dokumentasi Kubernetes)
• Dokumentasi Gateway API (Dokumentasi Kubernetes)

Senarai semak temu duga

Asingkan semantik medan daripada risiko keselamatan, kemudian berikan susunan: inventori, sekat penambahan, titik masuk pengganti, pengesahan selari, penyaliran, pembuangan, dan pengunduran.

Pengajaran utama dalam satu ayat

Migrasi ExternalIPs menggantikan titik masuk yang boleh ditulis oleh pengguna dengan laluan peruntukan alamat milik pentadbir yang boleh diaudit dan boleh disahkan.

Terus berlatih

Jika sesebuah kluster menggunakan Gateway API, MetalLB, dan LoadBalancer awan secara bersama, reka satu katalog titik masuk, model pemilikan alamat, dan protokol pengunduran rentas persekitaran.