Soalan dan senario
Reka bentuk Gateway Kubernetes yang dikongsi. Pasukan platform memiliki Gateway dan infrastruktur pengimbangan beban; pasukan aplikasi memiliki nama hos, port, HTTPRoutes, dan sijil dalam ruang nama mereka. Andaikan 20 pasukan dengan 50 pendengar setiap satu, atau kira-kira 1,000 domain, manakala Gateway tunggal mempunyai had garis dasar sebanyak 64 pendengar.
Terangkan cara untuk membahagikan pendengar daripada satu Gateway gergasi kepada ListenerSets, membenarkan lampiran merentas ruang nama (cross-namespace attachment), memastikan trafik stabil semasa konflik, dan mendedahkan status supaya pasukan dapat membezakan konfigurasi Accepted, Programmed, atau Conflicted.
Perkara yang diuji oleh penemu duga
Sempadan sumber dan perwakilan
Jawapan yang kukuh memisahkan infrastruktur yang dikongsi, konfigurasi penyewa, dan lampiran laluan, kemudian menerangkan sebab pasukan aplikasi tidak sepatutnya mengedit Gateway platform secara terus.
Konflik dan lalai selamat
Nyatakan penafian lalai (default denial) ListenerSets, sumber ruang nama yang dibenarkan, keutamaan nama hos berkanun, dan sempadan rujukan sijil.
Ketekalan pengawal
Kupas pemantauan (watches), penggabungan, pengesahan, syarat status (status conditions), dan percubaan semula (retries). Objek YAML semata-mata tidak bermakna satah data (data plane) telah diprogramkan.
Skala dan migrasi
Bandingkan satu Gateway, satu Gateway bagi setiap penyewa, dan anotasi Ingress. Terangkan bila kerumitan ListenerSet berbaloi dengan kelebihan perwakilan dan kebolehoperasian.
Soalan penjelasan sebelum menjawab
- Adakah kesemua 1,000 domain berkongsi satu alamat pengimbang beban, atau adakah setiap pasukan memerlukan titik masuk yang diasingkan?
- Bolehkah pasukan aplikasi mengurus Secrets TLS mereka sendiri, atau adakah platform meluluskan sijil?
- Patutkah lampiran merentas ruang nama membenarkan semua ruang nama, pemilih label (label selector), atau hanya ruang nama yang sama?
- Adakah konfigurasi lama mesti terus berkhidmat apabila berlaku konflik, atau bolehkah konfigurasi baharu mengambil alih?
- Berapa pantas pengawal mesti mencerminkan perubahan, dan adakah replikasi merentas kluster diperlukan?
- Adakah HTTPRoute, TLSRoute, dan jenis laluan lain berkongsi sempadan kebenaran yang sama?
Kerangka jawapan 30 saat
“Saya akan membenarkan pasukan platform mencipta Gateway dan menafikan ListenerSets secara lalai, kemudian menggunakan allowedListeners untuk memilih ruang nama yang dibenarkan. Setiap pasukan aplikasi menghantar ListenerSet dan laluan dalam ruang namanya. Pengawal mengesahkan ParentRef, nama hos, port, protokol, rujukan sijil, dan AllowedRoutes, kemudian menggabungkan pendengar menggunakan Gateway induk dahulu, masa penciptaan tertua kedua, dan susunan ruang nama/nama ketiga. Konflik ditandakan sebagai Accepted=False dan Conflicted=True dan tidak boleh menggantikan pendengar aktif. Satah data hanya diprogramkan daripada agregat yang disahkan, manakala syarat status dan metrik membezakan keadaan penolakan, konflik, tidak diprogramkan, dan telah diprogramkan.”
Jawapan mendalam langkah demi langkah
Langkah 1: Anggarkan skala dan pilih sumber
Dua puluh pasukan darab 50 pendengar adalah kira-kira 1,000 titik masuk. Meletakkan kesemua 1,000 pengisytiharan dalam satu Gateway menimbulkan pertikaian penulisan objek tunggal (single-object write contention), kebenaran yang terlalu luas, dan pengiraan semula pengawal yang berulang. ListenerSets membahagikan konfigurasi milik pasukan kepada sumber bebas; Gateway mengekalkan alamat platform, kelas, dan dasar lampiran.
Langkah 2: Wujudkan jabat tangan kebenaran
allowedListeners ialah pintu keselamatan. None tidak menerima ListenerSet secara lalai; platform boleh memilih Same, label Selector, atau All. ListenerSet menggunakan parentRef untuk menamakan Gateway. Pengawal menyertakannya hanya apabila kedua-dua belah pihak membenarkan hubungan tersebut, rujukannya sah, dan pemilihan ruang nama membenarkannya.
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
name: shared-gateway
spec:
allowedListeners:
namespaces:
from: Selector
selector:
matchLabels:
gateway-access: shared
---
apiVersion: gateway.networking.k8s.io/v1
kind: ListenerSet
metadata:
name: team-a-listeners
namespace: team-a
spec:
parentRef:
name: shared-gateway
namespace: platform
listeners:
- name: app-a
hostname: app-a.example.com
protocol: HTTPS
port: 443Langkah 3: Tentukan peraturan penggabungan dan konflik
Gabungkan pendengar Gateway dengan pendengar ListenerSet yang dibenarkan, kemudian tentukan identiti daripada port, protokol, dan nama hos yang berkenaan. Selesaikan konflik secara deterministik: Gateway induk menang; kemudian ListenerSet yang lebih lama menang; baki seri menggunakan susunan ruang nama/nama. Tandakan sumber yang kalah sebagai Conflicted dan bukannya menggantikan trafik aktif secara senyap.
Langkah 4: Asingkan laluan dan sijil
ListenerSet allowedRoutes mengehadkan ruang nama yang boleh mengikat laluan. Laluan menggunakan parentRefs untuk menyasarkan bahagian ListenerSet. Dasar platform mengekang rujukan Secret TLS, memisahkan kelulusan sijil daripada kebenaran pelepasan aplikasi. Pasukan boleh mengedit ListenerSet dan Secret miliknya sendiri tetapi tidak boleh menggunakan ParentRef untuk membaca sumber penyewa lain.
Langkah 5: Pastikan pengawal menumpu
Pantau Gateway, ListenerSet, Route, label ruang nama, dan Secrets serta bina model yang diingini dikumpulkan mengikut Gateway. Nyahduplikasi dan lakukan debounce pada peristiwa, sahkan agregat, kemudian programkan pengimbang beban. Kembalikan syarat Accepted, Programmed, ResolvedRefs, dan Conflicted. Percubaan semula adalah idempoten; keadaan diingini yang terakhir kekal sehingga konfigurasi baharu berjaya diprogramkan.
Langkah 6: Bandingkan alternatif dan laluan kegagalan
Satu Gateway bagi setiap penyewa memudahkan sempadan kebenaran tetapi menggandakan alamat, pengimbang beban, dan kos sijil. Gateway tunggal dengan anotasi adalah murah tetapi kekurangan skema yang dikongsi, semantik konflik, dan kebolehoperasian merentas pelaksanaan. Apabila satah kawalan ListenerSet tidak tersedia, kekalkan syot kilat (snapshot) Programmed yang terakhir dan tolak pendengar baharu yang tidak diketahui. Jika Gateway induk hilang atau ParentRef menjadi tidak sah, tandakan anak sebagai tidak diterima dan selaraskan selepas pemulihan.
Contoh jawapan berkualiti tinggi
“Saya akan menganggap Gateway sebagai sempadan kongsi milik platform dan ListenerSets sebagai pengisytiharan milik penyewa. Platform mengkonfigurasi GatewayClass, alamat, dan allowedListeners dengan penafian sebagai lalai; hanya ruang nama yang dilabelkan dengan gateway-access=shared boleh dilampirkan. Setiap pasukan menghantar ListenerSet, HTTPRoute, dan rujukan sijil mereka sendiri.
Pada setiap peristiwa, pengawal mengesahkan ParentRef, kebenaran ruang nama, port/protokol/nama hos, AllowedRoutes, dan rujukan Secret sebelum menggabungkannya. Gateway induk menang dalam konflik, diikuti oleh masa penciptaan ListenerSet dan susunan ruang nama/nama. Pihak yang kalah menerima Accepted=False dan Conflicted=True dan tidak boleh mengambil alih trafik langsung. Hanya agregat yang disahkan akan memprogramkan pengimbang beban, dan Programmed bermaksud satah data telah menggunakannya.
Bagi 20 pasukan darab 50 pendengar, kira-kira 1,000 entri, pemisahan sumber mengelakkan pertikaian penulisan objek tunggal dan kebenaran berpusat. Semasa masa henti pengawal, satah data melayani syot kilat stabil yang terakhir dan menolak penambahan yang berkonflik. Jika penyewa memerlukan alamat yang diasingkan, sempadan pematuhan, atau domain kegagalan, saya akan menggunakan Gateway berasingan dan menerima kos infrastruktur tersebut.”
Kesilapan lazim
- Membenarkan setiap pasukan mengedit Gateway → konfigurasi saling menimpa antara satu sama lain dan kebenaran menjadi terlalu luas → platform memiliki Gateway, penyewa memiliki ListenerSets.
- Membenarkan setiap ruang nama secara lalai → mana-mana penyewa boleh meminta ingress kongsi → tetapkan kepada None secara lalai, kemudian sempitkan dengan Same atau Selector.
- Membiarkan penulisan terakhir menang → pendengar baharu boleh merampas nama hos → gunakan keutamaan berkanun dan tandakan pihak yang kalah sebagai berkonflik.
- Hanya membandingkan nama hos → protokol yang berbeza masih boleh bertembung → gunakan port, protokol, dan nama hos yang berkaitan secara bersama.
- Menghantar nama Secret terus ke satah data → keistimewaan merentas ruang nama atau kebocoran sijil → sahkan rujukan dan kebenaran terlebih dahulu.
- Memprogram semula serta-merta bagi setiap peristiwa → keadaan tidak sah sementara menyebabkan churn → lakukan debounce, gabungkan secara idempoten, beralih selepas berjaya, dan kekalkan syot kilat.
- Hanya mendedahkan Ready dalam status → penyewa tidak dapat membezakan penolakan daripada konflik atau kelambatan pengaturcaraan → gunakan syarat Accepted, Programmed, ResolvedRefs, dan Conflicted.
- Menganggap ListenerSet sebagai penskalaan tanpa had → pengawal dan pengimbang beban masih mempunyai had → bahagikan (shard) mengikut Gateway, tetapkan kuota penyewa, dan pantau penumpuan.
Soalan susulan dan jawapan
Susulan 1: Dua pasukan menghantar nama hos dan port yang sama. Siapa yang menang?
Gateway induk menang. Antara ListenerSets, masa penciptaan yang lebih lama menang; baki seri menggunakan susunan ruang nama/nama. Pihak yang kalah kekal kelihatan dengan Conflicted dan tidak boleh mengubah hasil melalui pemasaan percubaan semula.
Susulan 2: Bagaimanakah platform boleh membekukan seorang penyewa buat sementara waktu?
Keluarkan label ruang namanya atau sempitkan pemilih allowedListeners. Pengawal menandakan ListenerSet sebagai tidak diterima sambil mengekalkan syot kilat yang terakhir. Catatkan pembekuan tersebut untuk audit, dan sahkan semula semasa pemulihan dan bukannya mempercayai objek lama secara membuta tuli.
Susulan 3: ListenerSet mempunyai 64 pendengar. Bolehkah ia berkembang lagi?
Had pelaksanaan masih terpakai; kapasiti keseluruhan bukanlah tidak terhad. Bahagikan penyewa merentasi ListenerSets dan Gateways dengan kuota. Jika pengasingan alamat atau sijil lebih penting daripada perkongsian, gunakan berbilang Gateway.
Susulan 4: Bagaimanakah anda memutarkan Secret TLS tanpa gangguan perkhidmatan?
Pantau versi Secret, sahkan rantaian, nama hos, dan tarikh luputnya, serta kemas kini Programmed hanya selepas satah data mengesahkan sijil baharu. Kekalkan sijil lama untuk tempoh ihsan (grace window); sekiranya gagal, teruskan melayani versi terakhir yang diketahui baik dan cetuskan amaran.
Susulan 5: Bolehkah Route baharu menggantikan trafik langsung semasa pengawal dimulakan semula?
Tidak. Kekalkan atau bina semula keadaan yang diingini semasa satah data melayani syot kilat terakhir yang berjaya. Selepas permulaan semula, kira semula rujukan dan konflik, kemudian beralih sekali kepada versi konfigurasi yang boleh diperhatikan.
Sumber 1: Panduan pengguna Gateway API ListenerSet
Panduan ini mentakrifkan penggunaan berbilang penyewa ListenerSet yang diwakilkan, had 64 pendengar, allowedListeners, parentRef, dan keutamaan konflik. Fakta-fakta tersebut mendasari model sumber, jabat tangan kebenaran, pengendalian konflik, dan reka bentuk status.
Sumber 2: GEP-1713
GEP-1713 menerangkan pertikaian sumber, pengurusan merentas ruang nama, dan kes penggunaan domain besar, serta menyatakan peraturan penggabungan Gateway induk, masa penciptaan, dan leksikal. Anggaran kapasiti dan alternatif menggunakan kekangan tersebut.
Sumber 3: Nota keluaran Kubernetes Gateway API v1.5
Nota keluaran merekodkan peralihan ListenerSet kepada Standard dan fokusnya pada multi-tenancy, pendengar yang diwakilkan, dan lebih daripada 64 pendengar. Jawapan ini mengubah perubahan awam tersebut kepada keputusan migrasi dan tadbir urus.
Sumber 4: Panduan temu duga reka bentuk sistem awam
Panduan awam menekankan keperluan untuk menjelaskan keperluan, membincangkan skala dan kegagalan, serta menerangkan pertukaran kompromi (trade-offs). Soalan penjelasan, anggaran, susulan konflik, dan alternatif melatih isyarat temu duga yang boleh diperhatikan tersebut.