Pertanyaan dan skenario
Rancang Kubernetes Gateway bersama. Tim platform memiliki Gateway dan infrastruktur load balancing; tim aplikasi memiliki hostname, port, HTTPRoute, dan sertifikat di namespace mereka. Asumsikan ada 20 tim dengan masing-masing 50 listener, atau sekitar 1.000 domain, sementara satu Gateway memiliki batas dasar 64 listener.
Jelaskan cara memecah listener dari satu Gateway raksasa menjadi ListenerSets, mengotorisasi lampiran lintas-namespace (cross-namespace attachment), menjaga kestabilan lalu lintas selama terjadi konflik, dan menampilkan status sehingga tim dapat membedakan konfigurasi Accepted, Programmed, atau Conflicted.
Hal yang diuji oleh pewawancara
Batasan sumber daya dan delegasi
Jawaban yang kuat memisahkan infrastruktur bersama, konfigurasi tenant, dan lampiran route, lalu menjelaskan mengapa tim aplikasi tidak boleh mengedit Gateway platform secara langsung.
Konflik dan pengaturan default yang aman
Sebutkan penolakan default (default denial) untuk ListenerSets, sumber namespace yang diizinkan, prioritas hostname yang deterministik, dan batasan referensi sertifikat.
Konsistensi controller
Cakup watches, penggabungan (merging), validasi, kondisi status, dan percobaan ulang (retries). Objek YAML saja tidak berarti data plane telah terprogram.
Skala dan migrasi
Bandingkan satu Gateway, satu Gateway per tenant, dan anotasi Ingress. Jelaskan kapan kompleksitas ListenerSet sepadan dengan keuntungan delegasi dan interoperabilitas.
Pertanyaan klarifikasi sebelum menjawab
- Apakah seluruh 1.000 domain berbagi satu alamat load balancer, atau apakah setiap tim memerlukan titik masuk yang terisolasi?
- Bolehkah tim aplikasi mengelola TLS Secret mereka sendiri, atau apakah platform yang menyetujui sertifikat?
- Apakah lampiran lintas-namespace harus mengizinkan semua namespace, selector label, atau hanya namespace yang sama?
- Haruskah konfigurasi lama tetap melayani lalu lintas saat terjadi konflik, atau bolehkah konfigurasi baru mengambil alih?
- Seberapa cepat controller harus merefleksikan perubahan, dan apakah replikasi lintas-klaster diperlukan?
- Apakah HTTPRoute, TLSRoute, dan jenis route lainnya berbagi batasan otorisasi yang sama?
Kerangka jawaban 30 detik
"Saya akan membiarkan tim platform membuat Gateway dan menolak ListenerSets secara default, kemudian menggunakan allowedListeners untuk memilih namespace yang diizinkan. Setiap tim aplikasi mengirimkan ListenerSet dan route di namespace masing-masing. Controller memvalidasi ParentRef, hostname, port, protokol, referensi sertifikat, dan AllowedRoutes, lalu menggabungkan listener dengan memprioritaskan parent Gateway terlebih dahulu, waktu pembuatan tertua kedua, dan urutan namespace/nama ketiga. Konflik akan ditandai Accepted=False dan Conflicted=True serta tidak dapat menggantikan listener yang aktif. Data plane hanya diprogram dari agregat yang telah divalidasi, sementara kondisi status dan metrik membedakan status penolakan, konflik, unprogrammed, dan programmed."
Jawaban mendalam langkah demi langkah
Langkah 1: Estimasi skala dan pilih sumber daya
Dua puluh tim dikali 50 listener menghasilkan sekitar 1.000 titik masuk. Menaruh semua 1.000 deklarasi dalam satu Gateway menciptakan perebutan penulisan satu objek (write contention), izin yang terlalu luas, dan komputasi ulang controller yang berulang. ListenerSets memecah konfigurasi milik tim menjadi sumber daya independen; Gateway tetap memegang alamat platform, class, dan kebijakan lampiran.
Langkah 2: Membangun handshake otorisasi
allowedListeners adalah gerbang keamanan. None tidak menerima ListenerSet apa pun secara default; platform dapat memilih Same, label Selector, atau All. ListenerSet menggunakan parentRef untuk menyebutkan Gateway. Controller menyertakannya hanya ketika kedua belah pihak mengotorisasi hubungan tersebut, referensinya valid, dan pemilihan namespace mengizinkannya.
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: Menentukan aturan penggabungan dan konflik
Gabungkan listener Gateway dengan listener ListenerSet yang telah diotorisasi, lalu tentukan identitas dari port, protokol, dan hostname yang berlaku. Selesaikan konflik secara deterministik: parent Gateway menang; kemudian ListenerSet yang lebih lama menang; sisa seri menggunakan urutan namespace/nama. Tandai sumber daya yang kalah sebagai Conflicted alih-alih menggantikan lalu lintas aktif secara diam-diam.
Langkah 4: Mengisolasi route dan sertifikat
allowedRoutes pada ListenerSet membatasi namespace mana yang boleh mengikat route. Suatu route menggunakan parentRefs untuk menargetkan bagian ListenerSet. Kebijakan platform membatasi referensi TLS Secret, memisahkan persetujuan sertifikat dari izin rilis aplikasi. Suatu tim dapat mengedit ListenerSet dan Secret mereka sendiri tetapi tidak dapat menggunakan ParentRef untuk membaca sumber daya tenant lain.
Langkah 5: Membuat controller konvergen
Amati (watch) Gateway, ListenerSet, Route, label namespace, dan Secret, lalu bangun model target yang dikelompokkan berdasarkan Gateway. Lakukan deduplikasi dan debounce pada event, validasi agregat, lalu program load balancer. Kembalikan kondisi Accepted, Programmed, ResolvedRefs, dan Conflicted. Percobaan ulang bersifat idempoten; status target terakhir tetap bertahan hingga konfigurasi baru berhasil diprogram.
Langkah 6: Membandingkan alternatif dan jalur kegagalan
Satu Gateway per tenant menyederhanakan batasan izin tetapi melipatgandakan alamat, load balancer, dan biaya sertifikat. Satu Gateway tunggal dengan anotasi berbiaya murah tetapi tidak memiliki skema bersama, semantik konflik, dan interoperabilitas lintas-implementasi. Ketika control plane ListenerSet tidak tersedia, pertahankan snapshot Programmed terakhir dan tolak listener baru yang tidak dikenal. Jika parent Gateway hilang atau ParentRef menjadi tidak valid, tandai dependensi turunan sebagai unaccepted dan rekonsiliasi setelah pemulihan.
Contoh jawaban berkualitas tinggi
"Saya akan memperlakukan Gateway sebagai batasan bersama milik platform dan ListenerSets sebagai deklarasi milik tenant. Platform mengonfigurasi GatewayClass, alamat, dan allowedListeners dengan penolakan sebagai default; hanya namespace yang diberi label gateway-access=shared yang boleh melampirkan konfigurasi. Setiap tim mengirimkan ListenerSet, HTTPRoute, dan referensi sertifikat mereka sendiri.
Pada setiap event, controller memvalidasi ParentRef, otorisasi namespace, port/protokol/hostname, AllowedRoutes, dan referensi Secret sebelum melakukan penggabungan. Parent Gateway menang saat terjadi konflik, diikuti oleh waktu pembuatan ListenerSet dan urutan namespace/nama. Pihak yang kalah menerima Accepted=False dan Conflicted=True serta tidak dapat mengambil alih lalu lintas aktif. Hanya agregat yang tervalidasi yang memprogram load balancer, dan Programmed berarti data plane telah menerapkannya.
Untuk 20 tim dikali 50 listener, sekitar 1.000 entri, pemecahan sumber daya menghindari perebutan penulisan satu objek dan izin yang tersentralisasi. Selama downtime controller, data plane melayani snapshot stabil terakhir dan menolak penambahan yang berkonflik. Jika sebuah tenant membutuhkan alamat terisolasi, batasan kepatuhan, atau failure domain, saya akan menggunakan Gateway terpisah dan menerima konsekuensi biaya infrastruktur."
Kesalahan umum
- Membiarkan setiap tim mengedit Gateway → konfigurasi saling menimpa dan izin menjadi terlalu luas → platform memiliki Gateway, tenant memiliki ListenerSets.
- Mengizinkan setiap namespace secara default → tenant mana pun dapat meminta ingress bersama → gunakan default None, lalu persempit dengan Same atau Selector.
- Membiarkan penulisan terakhir yang menang (last write wins) → listener baru dapat membajak hostname → gunakan prioritas deterministik dan tandai yang kalah sebagai conflicted.
- Hanya membandingkan hostname → protokol yang berbeda masih bisa bertabrakan → gunakan port, protokol, dan hostname yang berlaku secara bersamaan.
- Meneruskan nama Secret langsung ke data plane → eskalasi hak akses lintas-namespace atau kebocoran sertifikat → validasi referensi dan otorisasi terlebih dahulu.
- Memprogram ulang secara langsung untuk setiap event → status tidak valid sementara menyebabkan churn → lakukan debounce, gabungkan secara idempoten, beralih setelah berhasil, dan pertahankan snapshot.
- Hanya mengekspos Ready pada status → tenant tidak dapat membedakan penolakan dari konflik atau jeda pemrograman → gunakan kondisi Accepted, Programmed, ResolvedRefs, dan Conflicted.
- Menganggap ListenerSet sebagai penskalaan tanpa batas → controller dan load balancer tetap memiliki batasan → lakukan sharding berdasarkan Gateway, tetapkan kuota tenant, dan pantau konvergensi.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Dua tim mengirimkan hostname dan port yang sama. Siapa yang menang?
Parent Gateway menang. Di antara ListenerSets, waktu pembuatan yang lebih lama menang; jika masih seri, gunakan urutan namespace/nama. Pihak yang kalah tetap terlihat dengan status Conflicted dan tidak dapat mengubah hasil melalui waktu percobaan ulang.
Pertanyaan lanjutan 2: Bagaimana platform dapat membekukan satu tenant untuk sementara?
Hapus label namespace-nya atau persempit selector allowedListeners. Controller menandai ListenerSet sebagai unaccepted sambil mempertahankan snapshot terakhir. Catat pembekuan tersebut untuk audit, dan lakukan validasi ulang saat pemulihan alih-alih mempercayai objek lama begitu saja.
Pertanyaan lanjutan 3: Sebuah ListenerSet memiliki 64 listener. Bisakah bertambah lebih banyak?
Batas implementasi tetap berlaku; kapasitas total tidak tak terbatas. Bagi tenant ke beberapa ListenerSets dan Gateway dengan kuota. Jika isolasi alamat atau sertifikat lebih penting daripada berbagi pakai, gunakan beberapa Gateway.
Pertanyaan lanjutan 4: Bagaimana cara merotasi TLS Secret tanpa downtime?
Pantau versi Secret, validasi chain, hostname, dan masa berlakunya, serta perbarui Programmed hanya setelah data plane mengonfirmasi sertifikat baru. Pertahankan sertifikat lama selama masa tenggang (grace window); jika gagal, lanjutkan melayani versi terakhir yang diketahui baik dan kirimkan peringatan.
Pertanyaan lanjutan 5: Bisakah Route baru menggantikan lalu lintas aktif saat controller sedang restart?
Tidak. Pertahankan atau bangun kembali status target sementara data plane melayani snapshot sukses terakhir. Setelah restart, hitung ulang referensi dan konflik, lalu beralih sekali ke versi konfigurasi yang dapat diamati.
Sumber 1: Panduan pengguna Gateway API ListenerSet
Panduan ini mendefinisikan penggunaan multi-tenant terdelegasi dari ListenerSet, batas 64 listener, allowedListeners, parentRef, dan prioritas konflik. Fakta-fakta tersebut mendasari model sumber daya, handshake otorisasi, penanganan konflik, dan desain status.
Sumber 2: GEP-1713
GEP-1713 menjelaskan perebutan sumber daya, pengelolaan lintas-namespace, dan kasus penggunaan domain besar, serta menetapkan aturan penggabungan berdasarkan parent Gateway, waktu pembuatan, dan leksikal. Estimasi kapasitas dan alternatif menggunakan batasan-batasan tersebut.
Sumber 3: Catatan rilis Kubernetes Gateway API v1.5
Catatan rilis mencatat perpindahan ListenerSet ke Standard dan fokusnya pada multi-tenancy, listener yang didelegasikan, serta dukungan untuk lebih dari 64 listener. Jawaban ini mengubah perubahan publik tersebut menjadi keputusan migrasi dan tata kelola.
Sumber 4: Panduan wawancara system-design publik
Panduan publik menekankan pada klarifikasi kebutuhan, pembahasan skala dan kegagalan, serta penjelasan untung-rugi (trade-offs). Klarifikasi, estimasi, pertanyaan lanjutan terkait konflik, dan alternatif melatih sinyal-sinyal wawancara yang dapat diamati tersebut.