Bagaimanakah anda akan mereka bentuk Kubernetes Topology Aware Routing merentasi zon?

Soalan dan konteks

Sebuah kluster Kubernetes tiga zon menjalankan perkhidmatan dengan trafik rentas zon yang mahal. Pasukan mahu permintaan mengutamakan Pod dalam zon sumber sambil kekal tersedia apabila zon kekurangan kapasiti, trafik tidak seimbang, atau nod mengalami kegagalan. Reka bentuk pengaktifan, pengedaran endpoint, fallback, kebolehlihatan (observability), dan rollback.

Perkara yang dinilai oleh penemu duga

Sama ada anda memisahkan petunjuk EndpointSlice, penggunaan kube-proxy, dan dasar trafik Service.
Sama ada anda mengenal pasti prasyarat seperti bilangan endpoint dan trafik sumber yang seimbang dan bukannya menganggap zon yang sama sentiasa lebih baik.
Sama ada anda mereka bentuk fallback global, perlindungan kegagalan, dan pemantauan titik panas.
Sama ada anda mengukur secara kuantiti kos rentas zon, kependaman, beban endpoint, dan risiko pelancaran.

Soalan penjelasan terlebih dahulu

Trafik dan matlamat

Adakah trafik sumber diagihkan secara sama rata merentasi zon? Adakah matlamatnya kependaman p95 yang lebih rendah, kos rentas zon yang lebih rendah, atau residensi data? Adakah akses rentas zon lebih diutamakan berbanding mengembalikan ralat?

Endpoint dan penskalaan

Berapakah bilangan Pod sedia (ready) yang wujud dalam setiap zon? Bolehkah penskalaan, pelepasan bergilir (rolling release), atau PodDisruptionBudget mengurangkan bilangan endpoint yang selamat buat sementara waktu? Adakah Service juga memerlukan trafik setempat nod (node-local)?

Kegagalan dan kebolehlihatan

Adakah domain kegagalan melibatkan zon, nod, atau rangkaian? Bagaimanakah anda akan mengesan zon yang terlebih beban, petunjuk yang hilang, atau fallback kube-proxy? Bolehkah ciri ini diaktifkan bagi setiap Service?

Jawapan 30 saat

Saya terlebih dahulu akan mengesahkan bahawa trafik sumber dan pengedaran endpoint memenuhi prasyarat penghalaan, kemudian mendayakan keutamaan zon melalui petunjuk EndpointSlice atau tetapan traffic-distribution yang disokong oleh Service. Satah kawalan (control plane) dan kube-proxy mesti berundur (fallback) kepada endpoint seluruh kluster apabila kapasiti atau syarat keselamatan gagal. Pantau bait rentas zon, kependaman p95, permintaan setiap zon, dan beban endpoint; lakukan pelancaran canary untuk perubahan tersebut dan nyahdayakan keutamaan jika titik panas atau kegagalan muncul.

Penyelesaian mendalam

1. Asingkan satah kawalan dan satah data

Pengawal EndpointSlice menggunakan topologi endpoint untuk menghasilkan petunjuk (hints), dan kube-proxy atau komponen satah data nod yang lain menggunakannya. Topology Aware Routing mengutamakan endpoint dalam zon sumber; ia tidak menjamin penghalaan zon yang sama secara ketat. Perhatikan pengiraan satah kawalan, penyebaran EndpointSlice, dan tingkah laku nod secara berasingan.

2. Semak prasyarat

Dokumentasi Kubernetes mengesyorkan sekurang-kurangnya tiga endpoint bagi setiap zon; dalam kluster tiga zon, ini biasanya bermaksud sekurang-kurangnya sembilan endpoint. Dengan endpoint yang terlalu sedikit, pengawal mungkin tidak mengeluarkan sebarang petunjuk. Pengagihan sumber yang tertumpu dalam satu zon juga boleh membebankan zon tersebut secara berlebihan, jadi sahkan andaian tersebut dengan sejarah trafik dan data kapasiti.

3. Pilih konfigurasi

Gunakan mod topologi atau keupayaan trafficDistribution yang disokong untuk versi Kubernetes sasaran. 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 campurkan anotasi topology-aware-hints lama, mod topologi semasa, dan medan khusus versi tanpa menyemak versi API, feature gates, dan tingkah laku kube-proxy.

4. Reka bentuk fallback yang selamat

Satah kawalan atau kube-proxy harus menggunakan endpoint seluruh kluster apabila endpoint tidak mencukupi, petunjuk tidak sah, atau peruntukan tidak selamat. Jadikan fallback boleh diperhatikan; jika tidak, trafik rentas zon mungkin disalah anggap sebagai pengoptimuman yang berjaya. Uji gangguan keseluruhan zon, kelewatan penyebaran EndpointSlice, label nod yang tidak betul, dan versi kube-proxy yang bercampur-campur.

5. Cegah titik panas

Keutamaan zon yang sama mengecilkan set endpoint. Jejak permintaan setiap zon, sambungan, CPU, kedalaman giliran, dan ralat. Jika satu zon menerima bahagian sumber yang tidak seimbang atau mempunyai terlalu sedikit endpoint, kurangkan keutamaan atau gunakan penghalaan global buat sementara waktu. Penskalaan dan pelepasan bergilir mesti mengekalkan endpoint sedia dan ruang simpanan PDB dalam setiap zon.

6. Nilaikan kos dan kependaman

Rekodkan bait rentas zon, p50/p95/p99 permintaan, penggunaan semula sambungan, beban endpoint, dan kadar kegagalan secara serentak. Bandingkan tetingkap trafik yang sama sebelum dan selepas pengaktifan; jika tidak, perubahan cache-hit atau percubaan semula klien boleh disalah anggap berpunca daripada penghalaan topologi. Pengurangan kos tidak boleh mengorbankan kadar ralat yang lebih buruk atau kependaman ekor (tail latency).

7. Lancarkan dan undurkan (rollback) secara beransur-ansur

Dayakan ciri pada Service yang tidak kritikal atau canary satu zon, sahkan petunjuk EndpointSlice, pilihan kube-proxy, dan peristiwa fallback, kemudian kembangkannya kepada perkhidmatan yang serupa. Rollback mengalih keluar keutamaan dan mengesahkan endpoint global; simpan versi konfigurasi, tetingkap metrik, dan bukti latih tubi kegagalan.

Contoh jawapan yang mantap

Saya menganggap keutamaan topologi sebagai pengoptimuman prestasi yang boleh diundur (reversible). Pertama, sahkan bilangan endpoint dan pengagihan sumber, kemudian biarkan pengawal EndpointSlice mencipta petunjuk untuk satah data nod. Endpoint yang tidak mencukupi, ketidakseimbangan zon, atau komponen yang tidak serasi akan mencetuskan fallback global. Pantau bait rentas zon, beban setiap zon, kependaman, ralat, dan kiraan fallback; lakukan pelancaran canary sebelum pengembangan. Mana-mana zon yang terlebih beban atau gagal boleh memulihkan ketersediaan dengan menyahdayakan keutamaan.

Kesilapan lazim

Menganggap petunjuk menjamin penghalaan zon yang sama secara ketat.
Mengabaikan bilangan endpoint dan prasyarat sumber yang seimbang.
Memerhatikan kos rentas zon sambil terlepas pandang lebihan beban endpoint dan tail latency.
Menganggap anotasi lama, medan versi, dan feature gates sebagai satu API universal.
Tiada fallback global atau latih tubi kegagalan apabila petunjuk hilang.
Membiarkan pelancaran atau pengecilan skala menurunkan zon di bawah margin selamat endpoint sedia.

Soalan susulan dan jawapan

Mengapakah perlu fallback apabila endpoint berkurangan?

Keutamaan topologi mengecilkan set calon; endpoint yang terlalu sedikit meningkatkan risiko beban lampau dan kegagalan. Endpoint global mengekalkan ketersediaan terlebih dahulu.

Adakah tiga endpoint merupakan peraturan tegar?

Ia adalah cadangan kebolehgunaan dalam dokumentasi Kubernetes untuk menambah baik peruntukan zon, bukan jaminan mutlak untuk setiap beban kerja. Sahkannya berdasarkan matlamat trafik, kapasiti, dan kegagalan anda.

Bagaimana jika semua permintaan berasal dari satu zon sahaja?

Keutamaan zon yang sama boleh menumpukan beban di situ. Kurangkan keutamaan, tambah endpoint dalam zon tersebut, atau kembali kepada fallback global, kemudian sahkan dengan metrik beban dan kependaman.

Bagaimanakah anda membuktikan bahawa kube-proxy telah menggunakan petunjuk tersebut?

Periksa petunjuk EndpointSlice, versi komponen nod, dan pengagihan permintaan sebenar. Gunakan bait rentas zon dan kadar hit endpoint setiap zon untuk bukti hujung-ke-hujung dan bukannya hanya menyemak objek satah kawalan.

Adakah rollback memerlukan pembinaan semula Service?

Biasanya cuma alih keluar atau laraskan keutamaan topologi dan sahkan bahawa EndpointSlice serta tingkah laku satah data nod kembali kepada pemilihan global. Kekalkan latih tubi rollback dan bukti metrik.