Pertanyaan dan konteks
Sebuah controller hanya membutuhkan nama objek, label, namespace, dan resourceVersion, namun membaca field spec dan status Pod yang berukuran besar. Gunakan negosiasi metadata-only Kubernetes untuk permintaan list, kemudian jelaskan aggregated API yang tidak didukung, respons 406, dan watch berikutnya.
Apa yang sedang diuji oleh pewawancara
- Apakah Anda menyusun parameter
Acceptdengan benar dan membedakan representasi single-object dari list. - Apakah Anda memahami respons parsial sebagai sebuah representasi, bukan sekadar patch pemfilteran field arbitrer.
- Apakah Anda merancang penanganan 406, version-skew, dan fallback objek penuh tanpa membuat startup gagal atau melakukan retry tanpa henti.
- Apakah
resourceVersionlist/watch dan konsistensi cache tetap terjaga dengan benar.
Pertanyaan klarifikasi untuk diajukan terlebih dahulu
Batasan sumber daya dan server
Apakah targetnya berupa in-tree API, CRD, atau aggregated API? Apakah setiap apiserver dan proxy mendukung respons metadata-only?
Pola penggunaan
Apakah klien hanya membangun indeks keberadaan dan label, atau nantinya akan membutuhkan spec? Haruskah klien memulai watch segera setelah list?
Kebijakan kegagalan
Bolehkah klien membaca objek penuh ketika respons parsial tidak tersedia, atau harus gagal secara eksplisit untuk melindungi anggaran bandwidth dan memori?
Kerangka jawaban 30 detik
Saya akan memprioritaskan application/json;as=PartialObjectMetadataList;g=meta.k8s.io;v=v1 untuk list dan hanya menerima metadata ditambah resourceVersion list. Saya akan menambahkan application/json berkualitas lebih rendah sebagai fallback, lalu memeriksa kind respons untuk mengetahui apa yang sebenarnya dikembalikan. Tanpa fallback, perlakukan 406 sebagai kapabilitas yang tidak didukung alih-alih badai retry. Mulai watch dari versi resource yang dikembalikan dan catat representasinya di dalam cache.
Langkah jawaban mendalam
1. Membedakan representasi
Gunakan as=PartialObjectMetadata untuk satu objek dan as=PartialObjectMetadataList untuk sebuah koleksi. Respons akan menghilangkan spec serta status dan mempertahankan metadata; hal ini menurunkan biaya serialisasi, jaringan, dan decode tetapi tidak dapat melayani pemanggil yang membutuhkan field bisnis.
2. Menyusun permintaan fallback
GET /api/v1/pods
Accept: application/json;as=PartialObjectMetadataList;g=meta.k8s.io;v=v1, application/json;q=0.9Jika representasi yang diinginkan tidak tersedia, server dapat memilih JSON normal. Klien harus memeriksa kind, apiVersion, dan Content-Type; HTTP 200 saja tidak membuktikan bahwa objek parsial telah dikembalikan.
3. Menangani mode strict dan 406
Ketika permintaan hanya mengiklankan representasi parsial yang tidak didukung oleh API target, Kubernetes mengembalikan 406. Catat itu sebagai hasil kapabilitas dan beralihlah ke objek penuh, lewati resource, atau munculkan error konfigurasi sesuai kebijakan. Jangan mencoba ulang header Accept yang sama tanpa batas atau mengklasifikasikan 406 sebagai kegagalan jaringan sementara.
4. Menangani aggregated API dan CRD
API bawaan umumnya mendukung respons metadata-only, tetapi API di balik agregasi mungkin tidak. CRD dan implementasi pihak ketiga juga bisa hanya mengekspos objek penuh. Lakukan probe kapabilitas berdasarkan resource dan server, cache hasilnya dengan masa kedaluwarsa, dan jangan pernah menggeneralisasi keberhasilan satu resource ke setiap resource.
5. Mempertahankan konsistensi list/watch
resourceVersion list tetap menjadi titik awal untuk watch. Simpan token tersebut, tangani kedaluwarsa, diskoneksi, dan relist, serta ingat bahwa metadata-only mengubah representasi alih-alih semantik resource-version. Fallback objek penuh harus menggunakan versi yang sama untuk mengisi cache, menghindari data usang yang bercampur.
6. Merancang perilaku cache dan upgrade
Entri cache harus mencatat representasi dan ketersediaan field. Jalur yang membutuhkan spec tidak boleh berasumsi bahwa field tersebut ada di entri metadata-only; lakukan GET penuh yang terkontrol berdasarkan nama. Lakukan probe ulang kapabilitas Accept setelah meng-upgrade server atau proxy agar jalur objek penuh yang tidak diperlukan tidak bertahan selamanya.
7. Mengukur biaya dan keamanan
Bandingkan byte permintaan, CPU decode, puncak heap, latensi list, tingkat koneksi ulang watch, dan rasio GET penuh. Label, anotasi, dan owner reference masih dapat memuat data sensitif; otorisasi tidak hilang hanya karena yang dikembalikan hanyalah metadata. Hindari mencatat setiap anotasi ke dalam log dan metrik.
Contoh jawaban berkualitas tinggi
Saya akan memprioritaskan PartialObjectMetadataList dan menyertakan JSON normal berkualitas lebih rendah sebagai fallback. Klien memvalidasi kind yang dikembalikan dan melakukan satu kali pengalihan kapabilitas pada respons 406. Klien memulai watch dari resourceVersion list dan mencatat ketersediaan field di dalam cache. Aggregated API, CRD, dan jalur yang membutuhkan spec mendapatkan probe dan pembacaan terpisah, sementara metrik byte, CPU, memori, dan koneksi ulang membuktikan manfaatnya.
Kesalahan umum
- Menggunakan parameter
PartialObjectMetadatasingle-object untuk list. - Memperlakukan metadata-only sebagai pemfilteran field sisi server yang arbitrer dan mengabaikan kind respons.
- Memperlakukan 406 sebagai 5xx yang dapat di-retry ketika tidak ada fallback yang ditawarkan.
- Mengasumsikan kapabilitas in-tree berlaku untuk aggregated API atau setiap CRD.
- Menghilangkan
resourceVersionlist dan memulai ulang watch dari titik yang salah. - Mengukur ukuran respons tanpa memperhitungkan CPU decode, puncak heap, atau biaya koneksi ulang.
Pertanyaan lanjutan dan jawaban
Mengapa menggunakan PartialObjectMetadataList untuk list?
Permintaan koleksi mengembalikan representasi list, dan PartialObjectMetadataList secara eksplisit menyatakan bahwa setiap item hanya berisi metadata. Bentuk single-object ditujukan untuk satu GET; klien tidak boleh mencampurnya dan menebak-nebak.
Bagaimana jika server tidak mendukung respons parsial?
Dengan JSON normal sebagai fallback berkualitas lebih rendah, periksa kind respons dan gunakan objek penuh. Dalam mode strict, catat 406 sebagai kapabilitas yang tidak tersedia dan lewati atau gagalkan sesuai kebijakan resource. Jangan lakukan retry tanpa henti.
Apakah metadata-only mengubah resourceVersion?
Tidak. Ini mengubah representasi, bukan semantik resource-version. Versi list tetap menjadi jangkar bagi watch dan konsistensi cache.
Apakah semua CRD mendukung permintaan ini?
Jangan berasumsi demikian. Aggregated API dan CRD mungkin tidak mengimplementasikan representasi parsial; lakukan probe dan cache kapabilitas per resource.
Kapan Anda harus membaca objek secara penuh?
Ketika sebuah keputusan membutuhkan spec, status, atau field bisnis lainnya. Gunakan metadata untuk membangun indeks, lalu picu GET penuh yang terkontrol berdasarkan nama atau event.