Petunjuk dan Cakupan
Tim platform mengoperasikan kluster Kubernetes bersama sementara tim aplikasi men-deploy layanan gRPC. Platform membutuhkan satu titik masuk, terminasi TLS, perutean berdasarkan layanan/metode/header, dan rilis canary; setiap tim aplikasi hanya boleh mengedit Route miliknya sendiri dan tidak dapat mengontrol infrastruktur atau namespace lain. Rancang sumber daya, jalur permintaan, batas otorisasi, observabilitas, dan rollback kegagalan.
Asumsikan pengontrol Gateway API telah terpasang, backend menggunakan HTTP/2 gRPC, dan klien memiliki kebijakan batas waktu (timeout) dan coba lagi (retry) yang eksplisit. Fokuslah pada batas control-plane lintas tim daripada implementasi satu vendor tertentu.
Apa yang Dinilai oleh Pewawancara
- Apakah Anda memisahkan tanggung jawab GatewayClass, Gateway, GRPCRoute, dan Service.
- Apakah Anda memahami granularitas pencocokan GRPCRoute alih-alih menghasilkan YAML Ingress generik.
- Apakah Anda menangani ReferenceGrant lintas-namespace, RBAC, default deny, dan audit.
- Apakah Anda menjelaskan bobot, streaming berdurasi panjang, dan bahaya retry.
- Apakah Anda menentukan sinyal status, gerbang rollback, dan kegagalan pengontrol/data-plane.
Pertanyaan Klarifikasi Sebelum Menjawab
- Apakah Gateway dimiliki secara terpusat oleh platform atau dimiliki oleh tim? Hal ini mengubah penautan Route dan persetujuannya.
- Apakah perutean berdasarkan layanan, metode, header, atau hostname? Prioritas pencocokan mengubah penanganan konflik.
- Apakah panggilan berupa unary atau streaming berdurasi panjang? Streaming biasanya tidak boleh di-retry atau dialihkan per permintaan.
- Apakah pemilihan canary berdasarkan persentase, penyewa (tenant), header, atau versi klien? Tentukan bobot, persistensi (stickiness), dan sinyal rollback.
- Bisakah backend Service berada di lintas-namespace atau lintas-kluster? Hal itu menambahkan pertimbangan ReferenceGrant dan pemeriksaan kesehatan (health check).
Kerangka Jawaban 30 Detik
Saya memisahkan Gateway milik platform dari GRPCRoute milik aplikasi, dengan Service sebagai batas penemuan backend. Sebuah Route mendeklarasikan kecocokan metode dan metadata gRPC; referensi lintas-namespace memerlukan otorisasi eksplisit. Pengontrol mengekspos status penerimaan dan resolusi referensi, sementara data plane merutekan berdasarkan bobot dan menghindari retry membabi buta untuk streaming. Saya memulai canary dengan satu tenant atau header eksplisit, menggunakan kesalahan metode, latensi ekor (tail latency), dan kesehatan bisnis sebagai gerbang rollback, serta kembali ke backend yang stabil saat Route atau backend tidak valid.
Pembahasan Mendalam Langkah demi Langkah
1. Tanggung jawab sumber daya dan alur data
Platform membuat GatewayClass yang memilih pengontrol, lalu listener, alamat, dan kebijakan TLS. Aplikasi membuat GRPCRoute di namespace-nya, menautkannya ke Gateway yang diizinkan dengan parentRefs, dan menargetkan Service miliknya. Pengontrol mengubah aturan yang diterima menjadi konfigurasi data-plane, mencocokkan hostname, layanan gRPC, metode, dan header sebelum memilih backendRefs.
2. Pencocokan dan penanganan konflik
Tentukan prioritas antara pencocokan persis dan fallback: pencocokan layanan/metode penuh dapat mengalahkan layanan saja, yang dapat mengalahkan fallback header. Jangan biarkan dua tim secara implisit menimpa induk dan pencocokan yang sama. Tampilkan konflik melalui kondisi seperti Accepted dan ResolvedRefs, dan pastikan CI memeriksanya. Untuk metode yang tidak dikenal, pilih UNIMPLEMENTED eksplisit atau fallback yang stabil; jangan pernah merutekan secara diam-diam ke layanan arbitrer.
3. Otorisasi multi-tenant
Aplikasi hanya dapat menulis Route dan Service miliknya. allowedRoutes membatasi namespace yang dapat ditautkan ke Gateway; referensi backend lintas-namespace memerlukan ReferenceGrant yang disetujui oleh pemilik namespace tujuan. RBAC, kebijakan admisi, dan tinjauan Git mencegah tim aplikasi mengubah TLS platform, listener, atau izin tim lain. Audit siapa yang mengubah induk, referensi backend, atau bobot.
4. Canary, streaming, dan retry
RPC Unary dapat mengirim permintaan baru ke stabil dan canary berdasarkan bobot; RPC streaming mempertahankan rutenya setelah pembentukan koneksi. Jangan mengulang panggilan non-idempoten secara otomatis, dan jangan menumpuk retry Gateway di atas batas waktu klien yang tidak jelas. Gunakan header eksplisit atau daftar tenant sebagai kunci canary sehingga satu tenant tidak berpindah secara acak selama debugging. Ubah bobot dalam commit kecil dan catat waktu aktivasi.
5. Kesehatan, status, dan rollback kegagalan
Data plane memerlukan pemeriksaan kesehatan gRPC, kumpulan koneksi (connection pools), dan batas waktu per rute yang eksplisit. Jika pengontrol tidak tersedia, tetap layani konfigurasi terakhir yang diterima tetapi tolak perubahan yang belum diverifikasi. Jika Gateway tidak diterima, referensi tidak dapat diselesaikan, atau backend tidak memiliki endpoint, ekspos status yang memblokir rilis. Rollback dapat mengatur bobot canary ke nol, memulihkan Route sebelumnya, atau beralih ke Gateway siaga (standby); buat tindakan ini idempoten.
6. Observabilitas dan batas kapasitas
Catat permintaan, kesalahan, latensi P50/P95/P99, streaming aktif, retry, dan waktu koneksi berdasarkan rute, layanan, metode, status, tenant, dan versi. Jangan memasukkan metadata mentah dengan kardinalitas tinggi ke dalam label metrik; buat sampel dan redaksikan dalam log. Uji kapasitas harus mencakup koneksi, streaming konkuren, CPU TLS, penundaan propagasi pengontrol, dan batas koneksi backend untuk lalu lintas unary maupun streaming.
Contoh Jawaban Berkualitas Tinggi
Saya memberikan kepemilikan GatewayClass, Gateway, dan listener kepada tim platform, sementara tim aplikasi hanya memiliki GRPCRoute dan Service dalam cakupan namespace. GRPCRoute mencocokkan layanan/metode dan header terkontrol; backend lintas-namespace memerlukan ReferenceGrant milik tujuan, dan allowedRoutes beserta RBAC membatasi penautan.
Untuk rilis, saya membagi bobot permintaan unary baru antara stabil dan canary. Koneksi streaming memilih rute satu kali pada saat pembentukan, jadi saya tidak mengalihkannya di tengah streaming. Saya menghindari retry otomatis untuk panggilan non-idempoten dan mengoordinasikan anggaran batas waktu serta retry antara klien dan Gateway. Pengontrol mengekspos Accepted, ResolvedRefs, dan kesehatan backend; CI memblokir referensi yang tidak valid atau konflik. Canary dimulai dengan satu tenant atau header eksplisit dan melakukan rollback jika terjadi kesalahan tingkat metode, latensi ekor, streaming aktif, atau tingkat keberhasilan bisnis, memulihkan bobot sebelumnya dengan catatan audit.
Kesalahan Umum
Memperlakukan GRPCRoute sebagai Ingress biasa
Mengabaikan semantik layanan/metode dan HTTP/2 membuat pencocokan terlalu luas. Tentukan prioritas dan perilaku metode yang tidak dikenal terlebih dahulu.
Membiarkan aplikasi mengedit Gateway
Listener dan TLS bersama menjadi dapat diubah oleh tenant. Gunakan allowedRoutes, RBAC, ReferenceGrant, dan kebijakan admisi sebagai gerbang yang terpisah.
Melakukan retry atau pengalihan streaming secara membabi buta
Hal ini dapat menduplikasi efek samping atau memutus koneksi panjang. Pisahkan kebijakan unary dan streaming berdasarkan idempotensi dan masa pakai koneksi.
Hanya memeriksa keberhasilan deployment pengontrol
Pengontrol yang sehat tidak membuktikan Route diterima atau backend dapat digunakan. Periksa Accepted, ResolvedRefs, kesehatan, dan sinyal data-plane.
Pertanyaan Lanjutan dan Tanggapan
Pertanyaan lanjutan 1: Dua Route cocok dengan metode yang sama. Apa yang terjadi?
Jangan bergantung pada urutan insidental dari suatu implementasi. Batasi kepemilikan dengan kebijakan namespace dan penautan induk, periksa konflik di CI, dan perlakukan status yang belum terselesaikan sebagai kegagalan rilis.
Pertanyaan lanjutan 2: Bagaimana cara canary menargetkan satu tenant dengan aman?
Gunakan pencocokan tenant atau header yang eksplisit alih-alih bobot acak, dan catat tingkat kesalahan versi serta tenant. Rollback terlebih dahulu menghapus kecocokan tersebut.
Pertanyaan lanjutan 3: Apakah pengontrol Gateway yang mati mengganggu lalu lintas?
Itu tergantung pada apakah data plane mempertahankan konfigurasi terakhir yang diterima. Lanjutkan melayani lalu lintas sambil membekukan perubahan, pantau usia konfigurasi, dan lakukan failover ke standby sebelum jendela keamanan kedaluwarsa.
Pertanyaan lanjutan 4: Mengapa memerlukan otorisasi untuk backendRef lintas-namespace?
Ini memungkinkan satu tim mengirim lalu lintas ke Service tim lain. ReferenceGrant milik tujuan membuat persetujuan menjadi eksplisit, sementara RBAC dan audit mencegah eskalasi hak istimewa yang tersembunyi.