Bagaimanakah anda akan mereka bentuk TLSRoute dan mTLS bahagian hadapan dengan Kubernetes Gateway API?

1. Senario, matlamat, dan bukan-matlamat

Pasukan infrastruktur mengendalikan Gateway yang dikongsi manakala pasukan aplikasi menggunakan perkhidmatan dalam namespace mereka sendiri. Perkhidmatan pembayaran memerlukan Gateway untuk tidak sekali-kali melihat teks biasa (plaintext), perkhidmatan pengurusan dalaman memerlukan pengesahan sijil klien di bahagian pinggir (edge), dan juruaudit memerlukan perubahan laluan serta kegagalan jabat tangan (handshake) direkodkan. Pasukan sepatutnya menerbitkan laluan secara bebas manakala kebenaran sijil, backend, dan listener kekal dikekang.

Nyatakan bukan-matlamat terlebih dahulu: sumber Gateway API menyatakan niat (intent). Pelaksanaan konkrit TLS, tingkah laku pengimbangan beban, dan penyimpanan sijil kekal sebagai sifat pengawal GatewayClass. Oleh itu, reka bentuk memerlukan matriks keupayaan pengawal dan pemeriksaan keserasian; tingkah laku daripada satu pelaksanaan tidak boleh dianggap sebagai jaminan API.

2. Menghuraikan keupayaan Gateway API 1.5

Gateway API 1.5 memindahkan TLSRoute, pengesahan sijil klien bahagian hadapan, dan keupayaan TLS backend yang berkaitan ke arah sokongan stabil, serta menaikkan taraf ReferenceGrant kepada v1. TLSRoute memadankan nama hos daripada SNI jabat tangan TLS dan memajukan sambungan ke backend; listener boleh menggunakan Passthrough atau Terminate.

Dalam Passthrough, Gateway memproksi bait yang disulitkan dan backend memiliki sijil serta jabat tangan. Dalam Terminate, TLS tamat di Gateway dan TCP yang dinyahsulit dihantar ke backend. Pemilikan kunci, keterlihatan data, dan titik pelaksanaan dasar adalah berbeza, jadi prestasi sahaja tidak boleh menentukan pilihan antara keduanya.

3. Mereka bentuk sumber dan pemilikan

Pasukan platform mencipta Gateway dan listener; pasukan aplikasi mencipta objek TLSRoute yang terikat kepada listener yang dinamakan. Gunakan parentRefs.sectionName untuk mengikat laluan kepada listener yang eksplisit dan bukannya membenarkan satu laluan menuntut keseluruhan Gateway. Nama hos, port, protokol, dan rujukan sijil adalah input dasar untuk semakan.

Pasangan sumber ini menyatakan niat passthrough:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: shared-edge
  namespace: infra
spec:
  gatewayClassName: example-gateway-class
  listeners:
  - name: tls-passthrough
    protocol: TLS
    port: 8443
    tls:
      mode: Passthrough
---
apiVersion: gateway.networking.k8s.io/v1
kind: TLSRoute
metadata:
  name: payments
  namespace: payments
spec:
  parentRefs:
  - name: shared-edge
    namespace: infra
    sectionName: tls-passthrough
  hostnames: ["pay.example.com"]
  rules:
  - backendRefs:
    - name: payments
      port: 8443

Rujukan rentas-namespace mesti melepasi mekanisme pembenaran pengawal dan dibenarkan secara eksplisit oleh ReferenceGrant atau dasar yang setara. Jangan bergantung pada keterlihatan lalai.

4. Memilih antara Passthrough dan Terminate

Passthrough bermakna Gateway tidak memegang sebarang kunci peribadi dan tidak melihat protokol aplikasi. Ia sesuai untuk penyulitan hujung-ke-hujung yang ketat, TLS bersama secara terus ke backend, atau keperluan TCP yang disulitkan. Pertukarannya ialah Gateway tidak boleh menghalakan berdasarkan kandungan HTTP, menggunakan had lapisan aplikasi yang seragam, atau mengesahkan sijil klien di pinggir; backend menanggung kerja jabat tangan dan giliran sijil.

Terminate memusatkan pengurusan sijil dan membolehkan pengesahan sijil klien di pinggir, penghalaan yang konsisten, dan kebolehcerapan yang konsisten. Pertukarannya ialah keterlihatan teks biasa di Gateway. Jika lompatan ke backend mesti kekal disulitkan, konfigurasikan juga backend TLS; pendedahan kunci peribadi dan domain kegagalan pengawal juga bertambah.

Reka bentuk berkualiti temu duga adalah berlapis: tetapkan sambungan pembayaran yang sangat sensitif kepada passthrough secara lalai, manakala tamatkan perkhidmatan pengurusan yang memerlukan identiti dan dasar berpusat, kemudian lindungi lompatan kedua dengan backend TLS.

5. mTLS Bahagian Hadapan dan sauh kepercayaan (trust anchors)

mTLS Bahagian Hadapan mengesahkan sambungan klien-ke-Gateway. Gateway memeriksa sijil klien terhadap berkas CA yang dikonfigurasikan; mod ketat (strict mode) hanya menerima klien yang disahkan. Sandaran yang tidak selamat mungkin membenarkan sijil yang hilang atau tidak sah sampai ke backend, jadi ia mestilah pengecualian eksplisit yang digabungkan dengan dasar rangkaian dan amaran audit.

Kumpulkan sauh kepercayaan mengikut penyewa atau persekitaran. Edarkan berkas CA melalui rujukan Secret atau ConfigMap yang terkawal. Pasukan aplikasi tidak sepatutnya menerima rujukan kunci peribadi platform. Semasa giliran (rotation), terbitkan CA baharu, perhatikan tetingkap dwi-kepercayaan, batalkan CA lama, dan rekod masa serta skop pengaktifan.

6. Pembenaran berbilang penyewa dan konflik

Listener pada Gateway yang dikongsi ialah sempadan platform. Aplikasi sepatutnya hanya meminta nama hos dan backend yang diluluskan. Pengawal harus menolak nama hos yang bertindih, parentRefs yang tidak dibenarkan, backend rentas-namespace, dan port atau protokol di luar dasar, serta mendedahkan sebabnya dalam status sumber.

Sahkan ReferenceGrant, rujukan Secret, dan keupayaan GatewayClass semasa kemasukan (admission). Semak perubahan dasar dalam Git; pada masa larian, pengawal harus menghasilkan konfigurasi hanya daripada sumber yang diluluskan. Jika berlaku konflik laluan, kekalkan konfigurasi baik terakhir yang diketahui dan laporkan Accepted=False daripada membiarkan tingkah laku pemenang-tulis-terakhir (last-writer-wins) menulis ganti penyewa lain secara senyap.

7. Kegagalan, peningkatan taraf, dan kebolehcerapan

Sebelum pelaksanaan, sahkan bahawa pengawal menyokong versi TLSRoute yang stabil, mod TLS yang dipilih, pengesahan klien, dan backend TLS. Peningkatan taraf Gateway API mungkin memerlukan penghijrahan sumber eksperimen ke v1 yang stabil; menggantikan URL YAML sahaja adalah tidak mencukupi.

Perhatikan padanan SNI, conditions listener dan laluan, tamat tempoh sijil, sebab kegagalan sijil klien, ralat sambungan backend, kependaman penyebaran konfigurasi, serta metrik jabat tangan dan trafik bagi setiap penyewa. Pastikan berkas kepercayaan, keadaan laluan, dan pemeriksaan kesihatan backend kekal konsisten semasa failover. Jika Gateway tidak tersedia, tentukan sandaran DNS atau pengimbang beban yang eksplisit daripada memintasnya dengan trafik teks biasa.

8. Rubrik dan soalan susulan

Mesti dijelaskan

• Bezakan penghalaan SNI TLSRoute daripada sempadan kunci dan teks biasa bagi Passthrough dan Terminate.
• Reka bentuk kepercayaan CA, giliran, dasar kegagalan, dan pembenaran rentas-namespace untuk mTLS bahagian hadapan.
• Terangkan perbezaan keupayaan pengawal, conditions sumber, penghijrahan peningkatan taraf, dan kebolehcerapan daripada hanya menampal YAML.

Soalan susulan

• Jika dua namespace menuntut SNI yang sama, bagaimanakah anda menghalang tulis ganti senyap (silent overwrite)?
• Selepas Gateway menamatkan TLS, bagaimanakah anda menjamin bahawa lompatan kedua kekal mematuhi penyulitan standard?
• Semasa giliran CA klien, bagaimanakah anda menyokong dwi-sijil sambil mengehadkan jangka hayat maksimum sijil lama?

Panduan pemarkahan

Jawapan yang cemerlang menghubungkan pemilikan sumber, sempadan penyulitan, pembenaran, dan bukti masa larian: tentukan siapa yang memegang setiap kunci, tolak konflik dengan status conditions, dan buktikan dasar dengan metrik jabat tangan, sijil, dan backend.