Gesaan dan Skop
Pasukan platform mengendalikan kluster Kubernetes kongsi manakala pasukan aplikasi menggunakan perkhidmatan gRPC. Platform ini memerlukan satu titik masuk, penamatan TLS, penghalaan mengikut perkhidmatan/kaedah/pengepala dan pelepasan canary; setiap pasukan aplikasi hanya boleh mengedit Route miliknya sendiri dan tidak boleh mengawal infrastruktur atau namespace lain. Reka bentuk sumber, laluan permintaan, sempadan kebenaran, kebolehlihatan (observability) dan pengunduran kegagalan.
Andaikan pengawal Gateway API telah dipasang, backend menyokong HTTP/2 gRPC, dan klien mempunyai dasar had masa tamat (timeout) serta percubaan semula (retry) yang jelas. Fokus pada sempadan satah kawalan (control-plane) rentas pasukan dan bukannya pelaksanaan satu vendor tertentu.
Perkara yang Dinilai oleh Penemu Duga
- Sama ada anda mengasingkan tanggungjawab GatewayClass, Gateway, GRPCRoute dan Service.
- Sama ada anda memahami kekhususan pemadanan GRPCRoute dan bukannya menghasilkan YAML Ingress generik.
- Sama ada anda mengendalikan ReferenceGrant rentas namespace, RBAC, penafian lalai (default deny) dan audit.
- Sama ada anda menerangkan pemberat, penstriman jangka panjang dan bahaya percubaan semula.
- Sama ada anda mentakrifkan isyarat status, pintu kawalan pengunduran dan kegagalan pengawal/satah data.
Soalan Penjelasan Sebelum Menjawab
- Adakah Gateway dimiliki secara berpusat oleh platform atau dimiliki oleh pasukan? Ini mengubah cara Route dilampirkan dan diluluskan.
- Adakah penghalaan mengikut perkhidmatan, kaedah, pengepala atau nama hos? Keutamaan pemadanan mengubah pengendalian konflik.
- Adakah panggilan jenis unary atau penstriman jangka panjang? Penstriman biasanya tidak sepatutnya dicuba semula atau dipotong setiap permintaan.
- Adakah pemilihan canary mengikut peratusan, penyewa (tenant), pengepala atau versi klien? Tentukan pemberat, kelekatan (stickiness) dan isyarat pengunduran.
- Bolehkah backend Service berada merentasi namespace atau kluster? Ini menambah pertimbangan ReferenceGrant dan pemeriksaan kesihatan.
Rangka Kerja Jawapan 30 Saat
Saya mengasingkan Gateway milik platform daripada GRPCRoute milik aplikasi, dengan Service sebagai sempadan penemuan backend. Sesuatu Route mengisytiharkan pemadanan kaedah dan metadata gRPC; rujukan rentas namespace memerlukan kebenaran yang jelas. Pengawal mendedahkan status penerimaan dan penyelesaian rujukan, manakala satah data menghala mengikut pemberat dan mengelakkan percubaan semula secara membabi buta untuk penstriman. Saya memulakan canary dengan satu penyewa atau pengepala yang jelas, menggunakan ralat kaedah, kependaman ekor (tail latency) dan kesihatan perniagaan sebagai pintu kawalan pengunduran, serta kembali kepada backend yang stabil apabila Route atau backend tidak sah.
Huraian Terperinci Langkah demi Langkah
1. Tanggungjawab sumber dan aliran data
Platform mencipta GatewayClass yang memilih pengawal, kemudian pendengar (listeners), alamat dan dasar TLS. Aplikasi mencipta GRPCRoute dalam namespace miliknya, melampirkannya pada Gateway yang dibenarkan dengan parentRefs, dan menyasarkan Service miliknya. Pengawal mengubah peraturan yang diterima kepada konfigurasi satah data, memadankan nama hos, perkhidmatan gRPC, kaedah dan pengepala sebelum memilih backendRefs.
2. Pemadanan dan pengendalian konflik
Tentukan keutamaan antara padanan tepat dan sandaran (fallback): padanan perkhidmatan/kaedah penuh boleh mengatasi perkhidmatan sahaja, yang boleh mengatasi sandaran pengepala. Jangan benarkan dua pasukan menimpa induk dan pemadanan yang sama secara tersirat. Paparkan konflik melalui syarat seperti Accepted dan ResolvedRefs, dan pastikan CI menyemaknya. Bagi kaedah yang tidak diketahui, pilih UNIMPLEMENTED yang jelas atau sandaran yang stabil; jangan sesekali menghala secara senyap ke perkhidmatan sebarangan.
3. Kebenaran berbilang penyewa
Aplikasi hanya boleh menulis Route dan Service miliknya. allowedRoutes mengehadkan namespace yang boleh dilampirkan pada Gateway; rujukan backend rentas namespace memerlukan ReferenceGrant yang diluluskan oleh pemilik namespace destinasi. RBAC, dasar kemasukan dan semakan Git menghalang pasukan aplikasi daripada mengubah TLS platform, pendengar atau pemberian pasukan lain. Audit individu yang menukar induk, rujukan backend atau pemberat.
4. Canary, penstriman dan percubaan semula
RPC Unary boleh menghantar permintaan baharu kepada stabil dan canary mengikut pemberat; RPC penstriman mengekalkan laluannya selepas sambungan diwujudkan. Jangan cuba semula panggilan bukan idempoten secara automatik, dan jangan tindih percubaan semula Gateway pada had masa klien yang tidak jelas. Gunakan pengepala yang jelas atau senarai penyewa sebagai kunci canary supaya seorang penyewa tidak beralih secara rawak semasa penyahpepijatan. Tukar pemberat dalam komit kecil dan rekod masa pengaktifan.
5. Kesihatan, status dan pengunduran kegagalan
Satah data memerlukan pemeriksaan kesihatan gRPC, kolam sambungan dan had masa tamat per-laluan yang jelas. Jika pengawal tidak tersedia, teruskan menyajikan konfigurasi terakhir yang diterima tetapi tolak perubahan yang belum disahkan. Jika Gateway tidak diterima, rujukan tidak dapat diselesaikan atau backend tiada titik akhir (endpoints), dedahkan status yang menyekat pelepasan. Pengunduran boleh menetapkan pemberat canary kepada sifar, memulihkan Route sebelumnya atau beralih kepada Gateway tunggu sedia (standby); jadikan proses ini idempoten.
6. Kebolehlihatan dan sempadan kapasiti
Rekod permintaan, ralat, kependaman P50/P95/P99, penstriman aktif, percubaan semula dan masa sambungan mengikut laluan, perkhidmatan, kaedah, status, penyewa dan versi. Jangan letakkan metadata mentah berkardinaliti tinggi ke dalam label metrik; buat sampel dan padamkannya dalam log. Ujian kapasiti mesti merangkumi sambungan, penstriman serentak, CPU TLS, kelewatan penyebaran pengawal dan had sambungan backend untuk kedua-dua trafik unary dan penstriman.
Contoh Jawapan Berkualiti Tinggi
Saya memberikan pemilikan GatewayClass, Gateway dan pendengar kepada pasukan platform, manakala pasukan aplikasi hanya memiliki GRPCRoute dan Service berskop namespace. GRPCRoute memadankan perkhidmatan/kaedah dan pengepala yang dikawal; backend rentas namespace memerlukan ReferenceGrant milik destinasi, manakala allowedRoutes berserta RBAC mengehadkan pelampiran.
Untuk pelepasan, saya membahagikan pemberat permintaan unary baharu antara stabil dan canary. Sambungan penstriman memilih sekali sahaja semasa penetapan sambungan, jadi saya tidak memotongnya di pertengahan strim. Saya mengelakkan percubaan semula automatik untuk panggilan bukan idempoten dan menyelaraskan belanjawan had masa tamat serta percubaan semula antara klien dan Gateway. Pengawal mendedahkan Accepted, ResolvedRefs dan kesihatan backend; CI menyekat rujukan tidak sah atau konflik. Canary bermula dengan satu penyewa atau pengepala yang jelas dan berundur apabila berlaku ralat peringkat kaedah, kependaman ekor, strim aktif atau kadar kejayaan perniagaan, lalu memulihkan pemberat sebelumnya dengan rekod audit.
Kesilapan Biasa
Menganggap GRPCRoute sebagai Ingress biasa
Mengabaikan semantik perkhidmatan/kaedah dan HTTP/2 menjadikan padanan terlalu luas. Tentukan keutamaan dan tingkah laku kaedah yang tidak diketahui terlebih dahulu.
Membenarkan aplikasi mengedit Gateway
Pendengar dan TLS kongsi menjadi boleh diubah oleh penyewa. Gunakan allowedRoutes, RBAC, ReferenceGrant dan dasar kemasukan sebagai pintu kawalan yang berasingan.
Mencuba semula atau memotong penstriman secara membabi buta
Ini boleh menduplikasi kesan sampingan atau memotong sambungan yang panjang. Asingkan dasar unary dan penstriman mengikut keidempotenan dan jangka hayat sambungan.
Hanya menyemak kejayaan penggunaan (deployment) pengawal
Pengawal yang sihat tidak membuktikan Route diterima atau backend boleh digunakan. Semak Accepted, ResolvedRefs, kesihatan dan isyarat satah data.
Soalan Susulan dan Maklum Balas
Soalan susulan 1: Dua Route sepadan dengan kaedah yang sama. Apakah yang berlaku?
Jangan bergantung pada susunan sampingan sesuatu pelaksanaan. Hadkan pemilikan dengan dasar namespace dan pelampiran induk, semak konflik dalam CI dan anggap status yang tidak diselesaikan sebagai kegagalan pelepasan.
Soalan susulan 2: Bagaimanakah canary boleh menyasarkan satu penyewa dengan selamat?
Gunakan padanan penyewa atau pengepala yang jelas dan bukannya pemberat rawak, serta rekod kadar ralat versi dan penyewa. Pengunduran terlebih dahulu membuang padanan tersebut.
Soalan susulan 3: Adakah pengawal Gateway yang terhenti mengganggu trafik?
Ia bergantung pada sama ada satah data mengekalkan konfigurasi terakhir yang diterima. Teruskan menyajikannya sambil membekukan perubahan, pantau usia konfigurasi dan lakukan alih keluar kecemasan (failover) ke sistem tunggu sedia sebelum tempoh keselamatan tamat.
Soalan susulan 4: Mengapa memerlukan kebenaran untuk backendRef rentas namespace?
Ia membolehkan satu pasukan menghantar trafik ke Service pasukan lain. ReferenceGrant milik destinasi menjadikan persetujuan jelas, manakala RBAC dan audit menghalang peningkatan keistimewaan (privilege escalation) yang tersembunyi.