Petunjuk dan konteks
Sebuah kluster Kubernetes HA sedang melakukan rolling upgrade pada control plane-nya dari v1.35 ke v1.36. Selama periode tersebut, instans kube-apiserver yang berbeda mungkin mengenali versi sumber daya yang berbeda, sehingga klien yang diarahkan ke server lama dapat menerima 404 yang keliru untuk sumber daya yang sebenarnya ada di peer yang lebih baru. Rancang dan jelaskan bagaimana Mixed Version Proxy harus merutekan permintaan, membatasi trust, menyediakan observabilitas, dan mendukung rollback. Bedakan perilaku Beta Kubernetes v1.36 dari version-skew policy standar.
Hal yang dievaluasi oleh pewawancara
- Memisahkan version skew, cache penemuan (discovery cache), dan visibilitas API ke dalam domain kegagalan (failure domain) yang berbeda.
- Mengetahui bahwa proxy merutekan permintaan sumber daya; proxy tidak menggantikan konversi API atau migrasi penyimpanan.
- Menjelaskan penemuan peer (peer discovery), penerusan (forwarding), propagasi identitas, dan pencegahan loop.
- Mencakup keamanan upgrade, kemampuan audit (auditability), batas waktu (timeout), percobaan ulang (retry), dan rollback.
Pertanyaan klarifikasi yang perlu diajukan
- Apakah ini penggantian bergulir (rolling replacement) di dalam satu kluster atau migrasi lintas kluster? Asumsikan satu kluster dengan beberapa server API peer.
- Apakah klien hanya menggunakan sumber daya bawaan Kubernetes, atau juga aggregated API server dan CRD? Konfirmasikan cakupan proxy untuk versi sumber daya yang tidak dikenal.
- Apakah load balancer bersama, mTLS, audit terpusat, dan metrik sudah tersedia? Hal-hal ini menentukan propagasi identitas dan diagnosis.
- Berapa batasan (budget) untuk latensi tambahan, ketidaktersediaan, dan waktu rollback?
Kerangka jawaban 30 detik
Mulailah dengan kegagalannya: selama rolling upgrade, server API lama dapat salah mengira versi sumber daya baru sebagai sumber daya yang hilang. Kemudian jelaskan jalurnya: server API entri melakukan discovery dan keputusan lokal; ketika versinya tidak dikenal secara lokal, server tersebut meneruskannya ke peer yang kompatibel, lalu mengembalikan respons peer, status, dan identitas audit ke pemanggil. Tutup dengan batasannya: ikuti version-skew policy, larang loop proxy, batasi identitas proxy, kembalikan kegagalan penerusan yang eksplisit, hindari retry yang menyembunyikan kerusakan control plane, dan lakukan rollback melalui metrik serta feature switch bertahap.
Pembahasan mendalam langkah demi langkah
1. Mengklasifikasikan permintaan dan memutuskan apakah akan meneruskan
Server API mem-parsing grup, versi, sumber daya, dan kata kerja (verb). Jika sumber daya terdaftar secara lokal, prosesnya mengikuti autentikasi, otorisasi, admisi, dan penyimpanan lokal. Jika versi yang diminta tidak dikenal dalam discovery lokal, server memeriksa peer mana yang mengiklankan versi sumber daya tersebut. Server hanya meneruskan setelah peer secara eksplisit mengonfirmasi dukungan; jika tidak, server mengembalikan error yang dapat dibedakan. Proxy tidak boleh menebak versi atau mengubah setiap 404 bisnis biasa menjadi pemicu penerusan.
2. Menemukan peer, mempertahankan identitas, dan menghentikan loop
Peer harus berasal dari daftar keanggotaan control plane yang terkontrol atau mekanisme discovery internal yang tepercaya. Koneksi menggunakan identitas layanan control plane yang ada dan saluran terenkripsi. Permintaan yang diteruskan membawa identitas pengguna asli, grup, header otorisasi, dan konteks audit, sementara proxy tetap menegakkan batas otorisasinya sendiri. Tambahkan penanda hop (hop marker) atau metadata internal yang setara; server yang melihat penanda tersebut tidak boleh meneruskannya lagi, sehingga mencegah loop A-ke-B-ke-A.
3. Menangani konsistensi dan kegagalan
Operasi baca dapat mengamati cache discovery yang berbeda secara singkat di seluruh server API, sehingga klien harus mengandalkan versi sumber daya server dan resourceVersion. Penerusan hanya terjadi jika target dapat dijangkau dan kompatibel versinya; batas waktu habis, penolakan, atau respons ketidakcocokan versi akan langsung gagal (fail fast) disertai alasan yang tercatat. Jangan terapkan retry tanpa batas pada operasi tulis, yang dapat menduplikasi efek samping. Jika retry diperlukan, gunakan kunci idempotensi atau kebijakan retry klien yang eksplisit.
4. Melakukan peluncuran, mengamati, dan melakukan rollback
Upgrade satu server API di luar jam sibuk, lalu pantau rasio hit proxy, latensi penerusan, error versi tidak dikenal, respons 5xx, kelengkapan audit, dan konvergensi discovery sebelum memperluas batch. Mixed Version Proxy berstatus Beta dan diaktifkan secara default di v1.36, tetapi hal itu tidak menghilangkan kebutuhan untuk memvalidasi matriks version skew distribusi. Jika sinyal memburuk, hentikan penggantian, pertahankan lalu lintas pada peer yang diketahui kompatibel, dan jika didukung, nonaktifkan feature gate dan lakukan rollback control plane. Pertahankan rantai penerusan dan identitas asli dalam catatan audit.
Contoh jawaban model
Saya akan memperlakukan Mixed Version Proxy sebagai lapisan kompatibilitas control plane sementara, bukan sebagai API gateway baru. Server entri mengautentikasi, mengotorisasi, dan mengklasifikasikan permintaan. Sumber daya yang diketahuinya secara lokal mengikuti jalur lokal; versi sumber daya yang tidak dikenal secara lokal hanya diteruskan jika peer secara eksplisit mengiklankannya. Koneksi menggunakan identitas control plane yang ada, membawa konteks pengguna asli dan audit, serta menambahkan penanda hop tunggal untuk mencegah loop. Status peer dan semantik respons tetap dipertahankan. Waktu habis akan fail fast, dan operasi tulis tidak menerima retry otomatis tanpa batas.
Saya akan memvalidasi jalur tersebut dengan upgrade bertahap: mencatat hit lokal, hit proxy, versi target, latensi, kelas error, dan ID korelasi audit. Jeda batch ketika rasio hit atau 5xx melebihi ambang batas. Status Beta-by-default di v1.36 bukanlah pengganti untuk memeriksa kebijakan skew distribusi atau cakupan aggregated API dan CRD. Rollback berarti menghentikan penggantian, memulihkan rangkaian anggota control plane, menonaktifkan feature gate jika didukung, dan memeriksa cache discovery sehingga klien tidak terus menggunakan kapabilitas yang sudah usang.
Kesalahan umum
- Menjelaskan proxy sebagai pengonversi versi API sembarangan, alih-alih sebagai rute untuk versi sumber daya yang tidak dikenal.
- Hanya mengatakan "teruskan ke node yang lebih baru" tanpa peer discovery, propagasi identitas, atau perlindungan loop.
- Meneruskan setiap error 404, mengubah sumber daya yang benar-benar tidak ada menjadi lalu lintas control plane.
- Melakukan retry operasi tulis tanpa syarat dan menciptakan efek samping duplikat.
- Hanya memantau latensi rata-rata sambil mengabaikan konvergensi discovery, integritas audit, atau batasan skew.
Pertanyaan lanjutan dan respons
Pertanyaan lanjutan 1: Bisakah aggregated API server atau CRD di-proxy secara otomatis?
Konfirmasikan apakah sumber daya tersebut berada dalam cakupan Mixed Version Proxy yang diimplementasikan. Aggregated API server memiliki batas discovery, autentikasi, dan ketersediaan yang independen; dukungan untuk sumber daya bawaan tidak serta-merta berarti mendukungnya. Berikan matriks kapabilitas dan jalur fail-fast yang eksplisit untuk sumber daya yang tidak didukung.
Pertanyaan lanjutan 2: Bagaimana cara mencegah penerusan memperparah pemadaman (outage) control plane?
Gunakan penanda hop tunggal, tenggat waktu (deadlines), batas konkurensi, dan circuit breaker. Jangan mencoba ulang tanpa batas di sisi sumber. Buat peringatan untuk rasio hit proxy, error target, dan kedalaman antrean, serta biarkan pengontrol upgrade menjeda batch ketika sinyal-sinyal tersebut melampaui ambang batas.
Pertanyaan lanjutan 3: Bagaimana jika cache discovery klien sudah usang (stale)?
Klien tetap mengikuti aturan discovery dan version skew Kubernetes. Penerusan di sisi server dapat mengurangi false 404 selama rolling upgrade; ini tidak dapat secara permanen menyimpan cache sumber daya baru untuk klien atau menggantikan migrasi versi API. Minta klien melakukan discovery ulang dan menggunakan versi API eksplisit jika diperlukan.