Gesaan dan konteks
Pasukan platform mesti menyuntik konteks keselamatan lalai dan label kebolehcerapan apabila Pod dicipta, tanpa mengekalkan mutating webhook luaran. Menggunakan Kubernetes MutatingAdmissionPolicy, reka bentuk polisi, binding, pengendalian konflik, audit dan pelan rollback.
Kubernetes v1.36 menandakan MutatingAdmissionPolicy sebagai stabil. Ia menggunakan CEL di dalam pelayan API untuk menerangkan pemadanan dan mutasi, serta boleh mengubah objek yang masuk dengan ApplyConfiguration atau JSONPatch. Definisi polisi dan binding adalah berasingan. Temu duga ini menguji sama ada anda boleh meletakkan mutasi deklaratif ke dalam rantaian kemasukan yang boleh diaudit dan boleh diterbalikkan dan bukannya sekadar menulis semula manifes webhook.
Perkara yang dinilai oleh penemu duga
Penemu duga mencari sempadan polisi-lawan-binding yang jelas; pilihan yang disengajakan antara ApplyConfiguration dan JSONPatch; mutasi idempoten dengan pemilikan medan yang jelas; pengendalian failurePolicy, skop, susunan, konflik, perlindungan diri, peningkatan dan rollback; serta bukti daripada peristiwa audit dan metrik.
Soalan penjelasan
Objek sasaran dan nilai lalai
Tanya sama ada hanya Pod atau juga Deployment dan Job berada dalam skop, medan mana yang merupakan nilai lalai mandatori, nilai pengguna mana yang boleh diguna pakai, dan cara akaun perkhidmatan, ruang nama (namespace) serta pemilih label mengekang perubahan.
Sempadan versi dan masa jalan (runtime)
Sahkan bahawa kluster adalah v1.36, bahawa admissionregistration.k8s.io/v1 didayakan, sama ada webhook sedia ada kekal dalam rantaian, dan sama ada polisi mesti diguna semula merentas kluster.
Risiko dan rollback
Kenal pasti medan keselamatan yang dilindungi, mod kegagalan yang boleh diterima, pengekalan audit, tetingkap perubahan, dan kesan melumpuhkan polisi pada objek sedia ada dan permintaan baharu.
Jawapan 30 saat
“Saya akan mentakrifkan pemadanan dan mutasi idempoten dalam polisi, kemudian menggunakan binding untuk menskopkan ruang nama, sumber dan parameter. ApplyConfiguration mengendalikan nilai lalai berstruktur mudah; JSONPatch dikhaskan untuk operasi tatasusunan yang tepat. Padanan yang tidak sepadan dilangkau, manakala ralat mutasi mengikut failurePolicy. Saya akan menghalang pemadanan kendiri, mengekang RBAC, dan melancarkan melalui dry run, binding yang sempit dan metrik audit. Rollback mengalih keluar binding dan memulihkan polisi berversi; ia tidak menulis semula objek sedia ada secara senyap.”
Penyelesaian langkah demi langkah
Langkah 1: Asingkan polisi dan binding
Polisi menyimpan peraturan, pemboleh ubah, syarat padanan dan ungkapan mutasi. Binding memilih sumber dan ruang nama serta boleh menyediakan parameter. Oleh itu, satu polisi boleh diguna semula dengan binding yang berbeza untuk penyewa atau persekitaran semasa pelancaran berperingkat.
Langkah 2: Pilih perwakilan mutasi
ApplyConfiguration menyatakan nilai lalai berstruktur yang hampir dengan model objek. JSONPatch mengendalikan pemasukan atau penyingkiran laluan yang tepat, tetapi indeks tatasusunan dan pelepasan JSON Pointer mestilah betul. Jangan mencampurkannya ke dalam strategi tulis ganti tersirat; setiap medan memerlukan peraturan pemilikan dan keutamaan.
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: Jadikan mutasi idempoten dan tidak merosakkan
Tulis nilai lalai hanya apabila medan tiada, dengan mengekalkan nilai pengguna yang jelas. Untuk senarai, tentukan gabungan berkunci atau penggantian keseluruhan senarai; percubaan semula, kemasukan berulang dan kemas kini tidak boleh menambah pendua. Semak sama ada menilai objek yang dimutasi boleh mencetuskan peraturan yang sama sekali lagi, mewujudkan gelung amplifikasi kendiri.
Langkah 4: Hadkan pemadanan dan lindungi polisi
Sempitkan skop dengan apiGroups, resources, operations, namespaceSelector dan objectSelector. MutatingAdmissionPolicy tidak boleh memadankan dirinya sendiri atau binding-nya, menghalang polisi daripada menukar konfigurasinya sendiri kepada keadaan yang tidak boleh dipulihkan. Gunakan senarai kebenaran yang jelas untuk medan berisiko tinggi supaya parameter CEL yang disediakan pengguna tidak dapat meluaskan kuasa menulis.
Langkah 5: Tentukan ralat dan susunan
Bezakan antara ketidakpadanan, hasil ungkapan kosong, ralat mutasi dan kegagalan sementara pelayan API. Pilih Fail atau Ignore melalui failurePolicy dan pasangkannya dengan amaran. Jangan bergantung pada susunan tersembunyi dalam kalangan pemutasi; asingkan pemilikan medan atau pusatkan keputusan apabila polisi akan menulis medan yang sama.
Langkah 6: Migrasi dan versikan webhook
Bandingkan hasil webhook lama dengan polisi baharu dalam fasa bayangan (shadow) atau audit sahaja, kemudian ikat polisi pada set ruang nama yang kecil. Rekod versi polisi, UID permintaan, ringkasan objek asal dan sebab mutasi. Alih keluar webhook secara beransur-ansur selepas konflik difahami, mengekalkan manifes berversi untuk perbandingan dan rollback.
Langkah 7: Rollback dan perhatikan
Untuk rollback kecemasan, jeda atau padamkan binding supaya permintaan baharu berhenti berubah, kemudian pulihkan versi polisi sebelumnya. Objek sedia ada tidak dimutasikan semula secara terbalik dengan mengalih keluar binding; pembersihan memerlukan pengawal atau proses kelompok yang berasingan dan diluluskan. Pantau kependaman kemasukan, kadar penolakan, bilangan mutasi, ralat ungkapan dan kadar hit mengikut ruang nama.
Model jawapan
Saya akan menganggap polisi sebagai peraturan berversi dan binding sebagai sempadan pelancaran dan kebenaran. Skopkannya kepada CREATE Pod dalam ruang nama terpilih dan gunakan nilai lalai idempoten hanya pada label dan medan keselamatan yang hilang; gunakan JSONPatch yang diuji untuk laluan tatasusunan yang tepat. Tentukan failurePolicy, senarai kebenaran medan, RBAC dan perlindungan diri sebelum pelancaran. Bandingkan hasil lama dan baharu, ikat set ruang nama yang kecil, dan kembangkan menggunakan metrik audit, kependaman dan ralat. Rollback mengalih keluar binding dan memulihkan polisi sebelumnya; objek sedia ada tidak berundur secara automatik, jadi pembersihan ialah proses diaudit yang berasingan.
Kesilapan biasa
- Kesilapan: Menggantikan keseluruhan objek. → Sebab ia gagal: Konfigurasi eksplisit pengguna dipadamkan dan konflik pemilikan muncul. → Penyelesaian: Tulis medan yang hilang sahaja dan tentukan peraturan gabungan senarai.
- Kesilapan: Menganggap pemadaman binding memulihkan objek lama. → Sebab ia gagal: Kemasukan menjejaskan permintaan; ia tidak menyediakan mutasi terbalik. → Penyelesaian: Gunakan proses pembersihan diaudit yang berasingan dan nyatakan tingkah laku objek sedia ada.
- Kesilapan: Bergantung pada susunan tetap antara polisi. → Sebab ia gagal: Perubahan susunan kemasukan boleh mengubah hasilnya. → Penyelesaian: Asingkan pemilikan medan atau pusatkan keputusan.
- Kesilapan: Menggantikan webhook pengeluaran serta-merta. → Sebab ia gagal: Perbezaan ungkapan boleh muncul pada beban puncak. → Penyelesaian: Lakukan secara shadow terlebih dahulu, lancarkan mengikut ruang nama, dan kekalkan manifes berversi.
Soalan susulan dan respons
Bagaimanakah anda memilih antara ApplyConfiguration dan JSONPatch?
Gunakan ApplyConfiguration untuk nilai lalai berstruktur dan niat yang lebih jelas. Gunakan JSONPatch untuk pemasukan, pemadaman atau laluan terlepas yang tepat. Uji pelaksanaan berulang dan konflik tatasusunan dengan mana-mana bentuk.
Patutkah failurePolicy sentiasa ditetapkan kepada Fail?
Garis dasar keselamatan dan medan pematuhan selalunya memihak kepada Fail. Label kebolehcerapan yang tidak kritikal boleh menggunakan Ignore dengan amaran dan pampasan yang jelas. Kaitkan keputusan tersebut dengan impak, matlamat ketersediaan dan bukti audit.
Bagaimanakah anda menguji bahawa polisi tidak akan merosakkan objek?
Bina matriks dengan dry run pelayan, snapshot input tetap, kemasukan berulang, label ruang nama, medan pengguna yang dipratetap, senarai kosong dan ralat ungkapan, kemudian bandingkan hasil webhook lama dan polisi baharu.
Mengapa tidak menulis pengawal (controller) sahaja?
Kemasukan menyekat atau mengubah permintaan sebelum pengekalan (persistence), yang sesuai untuk nilai lalai dan kekangan pintu masuk. Pengawal menyelaraskan secara tak segerak dan membaiki objek sedia ada. Mereka boleh saling melengkapi, tetapi pengawal tidak menggantikan polisi keselamatan pintu masuk.