Bagaimana Anda akan merancang Kubernetes Topology Aware Routing lintas zona?

Pertanyaan dan konteks

Sebuah kluster Kubernetes tiga zona menjalankan layanan dengan lalu lintas lintas zona yang mahal. Tim ingin agar permintaan lebih memprioritaskan Pod di zona asal sambil tetap mempertahankan ketersediaan ketika suatu zona kekurangan kapasitas, lalu lintas timpang, atau node mengalami kegagalan. Rancang pengaktifan, distribusi endpoint, fallback, observabilitas, dan rollback.

Apa yang dievaluasi oleh pewawancara

Apakah Anda memisahkan petunjuk EndpointSlice, konsumsi kube-proxy, dan kebijakan lalu lintas Service.
Apakah Anda mengidentifikasi prasyarat seperti jumlah endpoint dan lalu lintas sumber yang seimbang alih-alih berasumsi bahwa zona yang sama selalu lebih baik.
Apakah Anda merancang fallback global, perlindungan kegagalan, dan pemantauan hot-spot.
Apakah Anda menguantifikasi biaya lintas zona, latensi, beban endpoint, dan risiko peluncuran.

Pertanyaan klarifikasi terlebih dahulu

Lalu lintas dan sasaran

Apakah lalu lintas sumber terdistribusi secara merata di seluruh zona? Apakah tujuannya adalah latensi p95 yang lebih rendah, biaya lintas zona yang lebih rendah, atau residensi data? Apakah akses lintas zona lebih disukai daripada mengembalikan kesalahan?

Endpoint dan penskalaan

Berapa banyak Pod siap (ready) yang ada di setiap zona? Bisakah penskalaan, rolling release, atau PodDisruptionBudget mengurangi jumlah endpoint aman untuk sementara? Apakah Service juga memerlukan lalu lintas lokal pada node?

Kegagalan dan observabilitas

Apakah domain kegagalannya berupa zona, node, atau jaringan? Bagaimana Anda mendeteksi zona yang kelebihan beban, petunjuk yang hilang, atau fallback kube-proxy? Bisakah fitur ini diaktifkan per Service?

Jawaban 30 detik

Pertama-tama saya akan memverifikasi bahwa lalu lintas sumber dan distribusi endpoint memenuhi prasyarat perutean, kemudian mengaktifkan preferensi zona melalui petunjuk EndpointSlice atau pengaturan traffic-distribution yang didukung oleh Service. Control plane dan kube-proxy harus melakukan fallback ke endpoint di seluruh kluster ketika kapasitas atau kondisi keamanan gagal. Pantau byte lintas zona, latensi p95, permintaan per zona, dan beban endpoint; lakukan peluncuran canary untuk perubahan tersebut dan nonaktifkan preferensi jika muncul hot spot atau kegagalan.

Solusi mendalam

1. Pisahkan control plane dan data plane

Pengontrol EndpointSlice menggunakan topologi endpoint untuk menghasilkan petunjuk (hints), dan kube-proxy atau komponen data plane node lainnya mengonsumsinya. Topology Aware Routing memprioritaskan endpoint di zona asal; fitur ini tidak menjamin perutean zona yang sama secara mutlak. Amati kalkulasi control plane, propagasi EndpointSlice, dan perilaku node secara terpisah.

2. Periksa prasyarat

Dokumentasi Kubernetes merekomendasikan setidaknya tiga endpoint per zona; dalam kluster tiga zona, ini biasanya berarti setidaknya sembilan endpoint. Dengan terlalu sedikit endpoint, pengontrol mungkin tidak mengeluarkan petunjuk sama sekali. Distribusi sumber yang terkonsentrasi di satu zona juga dapat membebani zona tersebut secara berlebih, jadi validasi asumsi ini dengan riwayat lalu lintas dan data kapasitas.

3. Pilih konfigurasi

Gunakan mode topologi atau kemampuan trafficDistribution yang didukung untuk versi Kubernetes target. Sebagai contoh:

yaml

apiVersion: v1
kind: Service
metadata:
  name: checkout
  annotations:
    service.kubernetes.io/topology-mode: "Auto"
spec:
  selector:
    app: checkout
  ports:
    - port: 443
      targetPort: 8443

Jangan mencampur anotasi topology-aware-hints versi lama, mode topologi saat ini, dan bidang khusus versi tertentu tanpa memeriksa versi API, feature gates, dan perilaku kube-proxy.

4. Rancang fallback yang aman

Control plane atau kube-proxy harus menggunakan endpoint di seluruh kluster ketika endpoint tidak mencukupi, petunjuk tidak valid, atau alokasi tidak aman. Buat fallback dapat diobservasi; jika tidak, lalu lintas lintas zona dapat disalahartikan sebagai pengoptimalan yang berhasil. Uji pemadaman seluruh zona, propagasi EndpointSlice yang tertunda, label node yang salah, dan versi kube-proxy yang beragam.

5. Cegah hot spot

Preferensi zona yang sama mempersempit himpunan endpoint. Lacak permintaan per zona, koneksi, CPU, kedalaman antrean, dan kesalahan. Jika satu zona menerima porsi sumber yang tidak proporsional atau memiliki terlalu sedikit endpoint, kurangi preferensi atau gunakan perutean global untuk sementara. Penskalaan dan rolling release harus mempertahankan endpoint siap dan ruang cadangan PDB di setiap zona.

6. Evaluasi biaya dan latensi

Catat byte lintas zona, p50/p95/p99 permintaan, penggunaan ulang koneksi, beban endpoint, dan tingkat kegagalan secara bersamaan. Bandingkan jendela lalu lintas yang sama sebelum dan sesudah pengaktifan; perubahan cache-hit atau percobaan ulang klien dapat disalahartikan sebagai akibat dari perutean topologi. Pengurangan biaya tidak boleh mengorbankan tingkat kesalahan yang lebih buruk atau tail latency.

7. Luncurkan dan lakukan rollback secara bertahap

Aktifkan fitur pada Service non-kritis atau canary satu zona, verifikasi petunjuk EndpointSlice, pilihan kube-proxy, dan peristiwa fallback, lalu perluas ke layanan serupa. Rollback menghapus preferensi dan memverifikasi endpoint global; simpan versi konfigurasi, jendela metrik, dan bukti simulasi kegagalan.

Contoh jawaban yang kuat

Saya memperlakukan preferensi topologi sebagai pengoptimalan performa yang dapat dibatalkan (reversible). Pertama, validasi jumlah endpoint dan distribusi sumber, lalu biarkan pengontrol EndpointSlice membuat petunjuk untuk data plane node. Endpoint yang tidak memadai, ketidakseimbangan zona, atau komponen yang tidak kompatibel akan memicu fallback global. Pantau byte lintas zona, beban per zona, latensi, kesalahan, dan jumlah fallback; lakukan canary sebelum perluasan. Setiap zona yang kelebihan beban atau gagal dapat memulihkan ketersediaan dengan menonaktifkan preferensi.

Kesalahan umum

Mengasumsikan petunjuk menjamin perutean zona yang sama secara mutlak.
Mengabaikan jumlah endpoint dan prasyarat sumber yang seimbang.
Memantau biaya lintas zona sambil mengabaikan kelebihan beban endpoint dan tail latency.
Memperlakukan anotasi lama, bidang versi, dan feature gates sebagai satu API universal.
Tidak memiliki fallback global atau simulasi kegagalan saat petunjuk menghilang.
Membiarkan peluncuran atau scale-down menurunkan zona di bawah margin aman endpoint siap.

Pertanyaan lanjutan dan jawaban

Mengapa melakukan fallback saat endpoint langka?

Preferensi topologi mempersempit himpunan kandidat; terlalu sedikit endpoint meningkatkan risiko kelebihan beban dan kegagalan. Endpoint global mempertahankan ketersediaan terlebih dahulu.

Apakah tiga endpoint merupakan aturan mutlak?

Ini adalah rekomendasi penerapan dalam dokumentasi Kubernetes untuk meningkatkan alokasi zona, bukan jaminan mutlak untuk setiap beban kerja. Validasi terhadap sasaran lalu lintas, kapasitas, dan kegagalan Anda.

Bagaimana jika semua permintaan berasal dari satu zona?

Preferensi zona yang sama dapat memusatkan beban di sana. Kurangi preferensi, tambahkan endpoint di zona tersebut, atau lakukan fallback secara global, lalu konfirmasikan dengan metrik beban dan latensi.

Bagaimana Anda membuktikan bahwa kube-proxy menggunakan petunjuk tersebut?

Periksa petunjuk EndpointSlice, versi komponen node, dan distribusi permintaan aktual. Gunakan byte lintas zona dan hit rate endpoint per zona untuk bukti menyeluruh (end-to-end) daripada hanya memeriksa objek control plane.

Apakah rollback memerlukan pembuatan ulang Service?

Biasanya cukup hapus atau sesuaikan preferensi topologi dan verifikasi bahwa EndpointSlice serta perilaku data plane node kembali ke pemilihan global. Simpan latihan simulasi rollback dan bukti metrik.