Perintah dan konteks
Tim platform harus menginjeksi konteks keamanan default dan label observabilitas saat Pod dibuat, tanpa perlu mengelola mutating webhook eksternal. Dengan menggunakan Kubernetes MutatingAdmissionPolicy, rancang kebijakan, binding, penanganan konflik, audit, dan rencana rollback.
Kubernetes v1.36 menandai MutatingAdmissionPolicy berstatus stabil. Fitur ini menggunakan CEL di dalam API server untuk mendeskripsikan pencocokan dan mutasi, serta dapat mengubah objek yang masuk dengan ApplyConfiguration atau JSONPatch. Definisi kebijakan dan binding dibuat terpisah. Wawancara ini menguji apakah Anda dapat menerapkan mutasi deklaratif ke dalam rantai admisi yang dapat diaudit dan dibalikkan (reversible), bukan sekadar menulis ulang manifes webhook.
Apa yang dinilai oleh pewawancara
Pewawancara mencari batasan yang jelas antara kebijakan versus binding; pilihan yang disengaja antara ApplyConfiguration dan JSONPatch; mutasi idempoten dengan kepemilikan field yang eksplisit; penanganan failurePolicy, cakupan, pengurutan, konflik, perlindungan diri (self-protection), pemutakhiran, dan rollback; serta bukti dari log peristiwa audit dan metrik.
Pertanyaan klarifikasi
Objek target dan nilai default
Tanyakan apakah cakupannya hanya Pod atau juga mencakup Deployment dan Job, field mana yang wajib memiliki nilai default, nilai pengguna mana yang boleh menang, dan bagaimana service account, namespace, serta label selector membatasi perubahan tersebut.
Batasan versi dan runtime
Konfirmasikan bahwa kluster menggunakan versi v1.36, bahwa admissionregistration.k8s.io/v1 telah diaktifkan, apakah webhook yang ada tetap berada di dalam rantai admisi, dan apakah kebijakan tersebut harus dapat digunakan kembali di seluruh kluster.
Risiko dan rollback
Identifikasi field keamanan yang dilindungi, mode kegagalan yang dapat diterima, retensi audit, jendela waktu perubahan (change window), dan dampak penonaktifan kebijakan terhadap objek yang ada serta permintaan baru.
Jawaban 30 detik
“Saya akan mendefinisikan pencocokan dan mutasi idempoten dalam sebuah kebijakan, kemudian menggunakan binding untuk membatasi cakupan namespace, sumber daya, dan parameter. ApplyConfiguration menangani nilai default terstruktur sederhana; JSONPatch dicadangkan untuk operasi array yang presisi. Kasus yang tidak cocok akan dilewati, sementara kesalahan mutasi mengikuti failurePolicy. Saya akan mencegah pencocokan diri sendiri (self-matching), membatasi RBAC, dan melakukan peluncuran melalui dry run, binding yang sempit, serta metrik audit. Rollback dilakukan dengan menghapus binding dan memulihkan kebijakan yang memiliki versi; ini tidak akan menulis ulang objek yang ada secara diam-diam.”
Solusi langkah demi langkah
Langkah 1: Pisahkan kebijakan dan binding
Kebijakan menyimpan aturan, variabel, kondisi pencocokan, dan ekspresi mutasi. Binding memilih sumber daya dan namespace serta dapat menyediakan parameter. Oleh karena itu, satu kebijakan dapat digunakan kembali dengan binding yang berbeda untuk penyewa (tenant) atau lingkungan yang berbeda selama peluncuran bertahap.
Langkah 2: Pilih representasi mutasi
ApplyConfiguration mengekspresikan nilai default terstruktur yang mendekati model objek. JSONPatch menangani penyisipan atau penghapusan jalur yang tepat, tetapi indeks array dan JSON Pointer escaping harus benar. Jangan mencampurkannya ke dalam strategi penimpaan (overwrite) implisit; setiap field membutuhkan aturan kepemilikan dan prioritas.
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicy
metadata:
name: pod-default-observability
spec:
matchConstraints:
resourceRules:
- apiGroups: [""]
apiVersions: ["v1"]
operations: ["CREATE"]
resources: ["pods"]
mutations:
- applyConfiguration:
expression: >-
Object{metadata: Object{labels: {"observability.example.com/enabled": "true"}}}
---
apiVersion: admissionregistration.k8s.io/v1
kind: MutatingAdmissionPolicyBinding
metadata:
name: pod-default-observability-binding
spec:
policyName: pod-default-observability
matchResources:
namespaceSelector:
matchLabels:
platform.example.com/enabled: "true"Langkah 3: Buat mutasi bersifat idempoten dan tidak merusak
Tulis nilai default hanya jika field tidak ada, dengan tetap mempertahankan nilai eksplisit yang diberikan pengguna. Untuk daftar (list), tentukan penggabungan berbasis kunci (keyed merge) atau penggantian seluruh daftar; percobaan ulang (retry), admisi berulang, dan pembaruan tidak boleh menambahkan duplikat. Periksa apakah evaluasi objek yang telah dimutasi dapat memicu aturan yang sama lagi, yang dapat menciptakan loop amplifikasi diri.
Langkah 4: Batasi pencocokan dan lindungi kebijakan
Persempit cakupan dengan apiGroups, resources, operations, namespaceSelector, dan objectSelector. MutatingAdmissionPolicy tidak boleh mencocokkan dirinya sendiri atau binding-nya, untuk mencegah kebijakan mengubah konfigurasinya sendiri ke status yang tidak dapat dipulihkan. Gunakan allowlist eksplisit untuk field berisiko tinggi agar parameter CEL yang disediakan pengguna tidak dapat memperluas otoritas penulisan.
Langkah 5: Definisikan penanganan kesalahan dan urutan
Bedakan antara ketidakcocokan, hasil ekspresi kosong, kesalahan mutasi, dan kegagalan sementara pada API server. Pilih Fail atau Ignore melalui failurePolicy dan pasangkan dengan peringatan (alerts). Jangan bergantung pada urutan tersembunyi di antara mutator; pisahkan kepemilikan field atau buat keputusan terpusat ketika beberapa kebijakan akan menulis ke field yang sama.
Langkah 6: Migrasikan dan versi webhook
Bandingkan hasil webhook lama dengan kebijakan baru dalam fase bayangan (shadow) atau khusus audit, kemudian kaitkan kebijakan ke sekumpulan namespace kecil. Catat versi kebijakan, UID permintaan, ringkasan objek asli, dan alasan mutasi. Hapus webhook secara bertahap setelah potensi konflik dipahami, dengan tetap menyimpan manifes berversi untuk perbandingan dan rollback.
Langkah 7: Lakukan rollback dan observasi
Untuk rollback darurat, jeda atau hapus binding sehingga permintaan baru berhenti diubah, lalu pulihkan versi kebijakan sebelumnya. Objek yang ada tidak akan mengalami mutasi balik hanya dengan menghapus binding; pembersihan memerlukan pengontrol atau proses batch terpisah yang telah disetujui. Pantau latensi admisi, tingkat penolakan, jumlah mutasi, kesalahan ekspresi, dan hit rate berdasarkan namespace.
Jawaban model
Saya akan memperlakukan kebijakan sebagai aturan yang memiliki versi dan binding sebagai batas peluncuran serta izin. Batasi cakupannya pada CREATE Pod di namespace tertentu dan terapkan nilai default idempoten hanya pada label dan field keamanan yang hilang; gunakan JSONPatch yang telah teruji untuk jalur array yang presisi. Tentukan failurePolicy, allowlist field, RBAC, dan perlindungan diri sebelum peluncuran. Bandingkan hasil lama dan baru, tautkan ke sekumpulan namespace kecil, dan perluas menggunakan metrik audit, latensi, serta kesalahan. Rollback dilakukan dengan menghapus binding dan memulihkan kebijakan sebelumnya; objek yang ada tidak otomatis kembali ke kondisi semula, sehingga pembersihan merupakan proses terpisah yang diaudit.
Kesalahan umum
- Kesalahan: Mengganti seluruh objek. → Mengapa gagal: Konfigurasi eksplisit pengguna terhapus dan konflik kepemilikan muncul. → Perbaikan: Tulis hanya field yang hilang dan tentukan aturan penggabungan daftar.
- Kesalahan: Menganggap penghapusan binding akan memulihkan objek lama. → Mengapa gagal: Admisi memengaruhi permintaan; admisi tidak menyediakan pembalikan mutasi (reverse mutation). → Perbaikan: Gunakan proses pembersihan terpisah yang diaudit dan nyatakan perilaku objek yang ada.
- Kesalahan: Bergantung pada urutan tetap di antara kebijakan. → Mengapa gagal: Perubahan urutan admisi dapat mengubah hasil. → Perbaikan: Pisahkan kepemilikan field atau sentralisasi keputusan.
- Kesalahan: Langsung mengganti webhook produksi. → Mengapa gagal: Perbedaan ekspresi dapat muncul saat beban puncak. → Perbaikan: Lakukan mode shadow terlebih dahulu, luncurkan per namespace, dan pertahankan manifes berversi.
Pertanyaan lanjutan dan tanggapan
Bagaimana Anda memilih antara ApplyConfiguration dan JSONPatch?
Gunakan ApplyConfiguration untuk nilai default terstruktur dan maksud yang lebih jelas. Gunakan JSONPatch untuk penyisipan, penghapusan, atau jalur dengan karakter escape yang presisi. Uji eksekusi berulang dan konflik array pada kedua bentuk tersebut.
Haruskah failurePolicy selalu bernilai Fail?
Dasar keamanan dan field kepatuhan sering kali lebih memilih Fail. Label observabilitas yang tidak kritis dapat menggunakan Ignore dengan peringatan eksplisit dan kompensasi. Hubungkan keputusan tersebut dengan dampak, target ketersediaan, dan bukti audit.
Bagaimana Anda menguji bahwa suatu kebijakan tidak akan merusak objek?
Bangun matriks dengan dry run server, snapshot input tetap, admisi berulang, label namespace, field pengguna yang telah ditetapkan sebelumnya, daftar kosong, dan kesalahan ekspresi, lalu bandingkan hasil webhook lama dan kebijakan baru.
Mengapa tidak menulis controller saja?
Admisi memblokir atau mengubah permintaan sebelum persistensi data, yang sangat cocok untuk nilai default dan batasan masuk. Controller melakukan rekonsiliasi secara asinkron dan memperbaiki objek yang ada. Keduanya dapat saling melengkapi, tetapi controller tidak dapat menggantikan kebijakan keamanan pintu masuk.