संकेत और संदर्भ
एक प्लेटफ़ॉर्म टीम को Pods बनते समय बिना किसी बाहरी mutating webhook को मेंटेन किए डिफ़ॉल्ट सुरक्षा संदर्भ (security context) और ऑब्जर्वेबिलिटी लेबल इंजेक्ट करने हैं। Kubernetes MutatingAdmissionPolicy का उपयोग करके, पॉलिसी, बाइंडिंग, टकराव प्रबंधन (conflict handling), ऑडिट और रोलबैक योजना डिज़ाइन करें।
Kubernetes v1.36 MutatingAdmissionPolicy को स्थिर (stable) चिह्नित करता है। यह मिलान और म्यूटेशन का वर्णन करने के लिए API सर्वर के अंदर CEL का उपयोग करता है, और ApplyConfiguration या JSONPatch के साथ आने वाले ऑब्जेक्ट को बदल सकता है। पॉलिसी परिभाषा और बाइंडिंग अलग-अलग हैं। यह इंटरव्यू यह परीक्षण करता है कि क्या आप केवल एक वेबहुक मेनिफेस्ट को फिर से लिखने के बजाय एक ऑडिट करने योग्य, प्रतिवर्ती (reversible) एडमिशन श्रृंखला में डिक्लेरेटिव म्यूटेशन डाल सकते हैं।
इंटरव्यूअर क्या मूल्यांकन करता है
इंटरव्यूअर पॉलिसी बनाम बाइंडिंग की स्पष्ट सीमा; ApplyConfiguration और JSONPatch के बीच एक विचारशील विकल्प; स्पष्ट फ़ील्ड स्वामित्व के साथ आइडेम्पोटेंट म्यूटेशन; failurePolicy, स्कोप, ऑर्डरिंग, टकराव, आत्म-सुरक्षा (self-protection), अपग्रेड और रोलबैक का प्रबंधन; और ऑडिट इवेंट्स व मेट्रिक्स से साक्ष्य की तलाश करता है।
स्पष्टीकरण वाले प्रश्न
लक्षित ऑब्जेक्ट और डिफ़ॉल्ट
पूछें कि क्या केवल Pods या Deployments और Jobs भी स्कोप में हैं, कौन से फ़ील्ड अनिवार्य डिफ़ॉल्ट हैं, कौन से यूज़र मान मान्य हो सकते हैं, और सर्विस अकाउंट, नेमस्पेस व लेबल सिलेक्टर परिवर्तन को कैसे सीमित करते हैं।
वर्ज़न और रनटाइम सीमा
पुष्टि करें कि क्लस्टर v1.36 है, admissionregistration.k8s.io/v1 सक्षम है, क्या मौजूदा वेबहुक श्रृंखला में बने हुए हैं, और क्या पॉलिसी को कई क्लस्टरों में पुन: उपयोग किया जाना चाहिए।
जोखिम और रोलबैक
संरक्षित सुरक्षा फ़ील्ड, स्वीकार्य विफलता मोड, ऑडिट प्रतिधारण, परिवर्तन विंडो, और मौजूदा ऑब्जेक्ट्स व नए अनुरोधों पर पॉलिसी को अक्षम करने के प्रभाव की पहचान करें।
30-सेकंड का उत्तर
“मैं एक पॉलिसी में मिलान और आइडेम्पोटेंट म्यूटेशन को परिभाषित करूँगा, फिर नेमस्पेस, संसाधनों और मापदंडों को स्कोप करने के लिए बाइंडिंग का उपयोग करूँगा। ApplyConfiguration सरल संरचित डिफ़ॉल्ट को संभालता है; JSONPatch सटीक ऐरे संचालन के लिए आरक्षित है। गैर-मिलान छोड़ दिए जाते हैं, जबकि म्यूटेशन त्रुटियां failurePolicy का पालन करती हैं। मैं सेल्फ-मैचिंग को रोकूँगा, RBAC को सीमित करूँगा, और ड्राई रन, संकीर्ण बाइंडिंग्स और ऑडिट मेट्रिक्स के माध्यम से रोल आउट करूँगा। रोलबैक बाइंडिंग को हटाता है और एक वर्ज़न वाली पॉलिसी को पुनर्स्थापित करता है; यह मौजूदा ऑब्जेक्ट्स को चुपचाप फिर से नहीं लिखता है।”
चरण-दर-चरण समाधान
चरण 1: पॉलिसी और बाइंडिंग को अलग करें
पॉलिसी नियम, चर, मिलान स्थितियां और म्यूटेशन एक्सप्रेशन संग्रहीत करती है। बाइंडिंग संसाधनों और नेमस्पेस का चयन करती है और पैरामीटर प्रदान कर सकती है। इसलिए चरणबद्ध रोलआउट के दौरान किरायेदारों (tenants) या वातावरणों के लिए अलग-अलग बाइंडिंग्स के साथ एक ही पॉलिसी का पुन: उपयोग किया जा सकता है।
चरण 2: म्यूटेशन निरूपण चुनें
ApplyConfiguration ऑब्जेक्ट मॉडल के करीब संरचित डिफ़ॉल्ट व्यक्त करता है। JSONPatch सटीक पाथ इंसर्शन या हटाने को संभालता है, लेकिन ऐरे इंडेक्स और JSON Pointer एस्केपिंग सही होनी चाहिए। उन्हें एक अंतर्निहित अधिलेखन (overwrite) रणनीति में न मिलाएं; प्रत्येक फ़ील्ड को स्वामित्व और प्राथमिकता नियम की आवश्यकता होती है।
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"चरण 3: म्यूटेशन को आइडेम्पोटेंट और गैर-विनाशकारी बनाएं
डिफ़ॉल्ट केवल तभी लिखें जब फ़ील्ड अनुपस्थित हों, स्पष्ट उपयोगकर्ता मानों को संरक्षित रखें। सूचियों के लिए, कीड मर्ज या संपूर्ण-सूची प्रतिस्थापन को परिभाषित करें; पुनः प्रयास (retries), बार-बार एडमिशन और अपडेट से डुप्लिकेट नहीं जुड़ने चाहिए। जांचें कि क्या म्यूटेटेड ऑब्जेक्ट का मूल्यांकन उसी नियम को फिर से ट्रिगर कर सकता है, जिससे एक स्व-प्रवर्धक लूप बन सकता है।
चरण 4: मिलान सीमित करें और पॉलिसी को सुरक्षित रखें
apiGroups, resources, operations, namespaceSelector, और objectSelector के साथ स्कोप को संकीर्ण करें। एक MutatingAdmissionPolicy खुद से या अपनी बाइंडिंग से मेल नहीं खा सकती है, जिससे पॉलिसी अपने स्वयं के कॉन्फ़िगरेशन को एक अप्राप्य स्थिति में बदलने से बचती है। उच्च-जोखिम वाले फ़ील्ड के लिए स्पष्ट अनुमति सूचियों (allowlists) का उपयोग करें ताकि उपयोगकर्ता द्वारा प्रदान किए गए CEL पैरामीटर राइट अथॉरिटी का विस्तार न कर सकें।
चरण 5: त्रुटियों और क्रम को परिभाषित करें
गैर-मिलान, खाली एक्सप्रेशन परिणाम, म्यूटेशन त्रुटि और अस्थायी API-सर्वर विफलता के बीच अंतर करें। failurePolicy के माध्यम से Fail या Ignore चुनें और इसे अलर्ट के साथ जोड़ें। म्यूटेटर्स के बीच छिपे हुए क्रम पर भरोसा न करें; फ़ील्ड स्वामित्व को अलग करें या जब पॉलिसियां समान फ़ील्ड लिखती हैं तो निर्णय को केंद्रीकृत करें।
चरण 6: वेबहुक को माइग्रेट और वर्ज़न करें
शैडो या केवल-ऑडिट चरण में पुराने वेबहुक परिणाम की नई पॉलिसी के साथ तुलना करें, फिर पॉलिसी को एक छोटे नेमस्पेस सेट से बांधें। पॉलिसी वर्ज़न, अनुरोध UID, एक मूल-ऑब्जेक्ट सारांश और म्यूटेशन कारण रिकॉर्ड करें। टकरावों को समझने के बाद वेबहुक को धीरे-धीरे हटाएं, तुलना और रोलबैक के लिए वर्ज़न किए गए मेनिफेस्ट रखें।
चरण 7: रोल बैक करें और निरीक्षण करें
आपातकालीन रोलबैक के लिए, बाइंडिंग को रोकें या हटाएं ताकि नए अनुरोध बदलना बंद हो जाएं, फिर पिछले पॉलिसी वर्ज़न को पुनर्स्थापित करें। बाइंडिंग को हटाने से मौजूदा ऑब्जेक्ट रिवर्स-म्यूटेट नहीं होते हैं; क्लीनअप के लिए एक अलग, स्वीकृत कंट्रोलर या बैच प्रक्रिया की आवश्यकता होती है। एडमिशन लेटेंसी, अस्वीकृति दर, म्यूटेशन गणना, एक्सप्रेशन त्रुटियों और नेमस्पेस द्वारा हिट दर की निगरानी करें।
मॉडल उत्तर
मैं पॉलिसी को एक वर्ज़न वाले नियम के रूप में और बाइंडिंग को रोलआउट और अनुमति सीमा के रूप में मानूंगा। इसे चयनित नेमस्पेस में Pod CREATE तक सीमित करें और केवल गायब लेबल और सुरक्षा फ़ील्ड पर आइडेम्पोटेंट डिफ़ॉल्ट लागू करें; सटीक ऐरे पाथ के लिए परीक्षण किए गए JSONPatch का उपयोग करें। रोलआउट से पहले failurePolicy, फ़ील्ड अनुमति सूचियां, RBAC और आत्म-सुरक्षा परिभाषित करें। पुराने और नए परिणामों की तुलना करें, एक छोटे नेमस्पेस सेट को बांधें, और ऑडिट, लेटेंसी और त्रुटि मेट्रिक्स का उपयोग करके विस्तार करें। रोलबैक बाइंडिंग को हटाता है और पिछली पॉलिसी को पुनर्स्थापित करता है; मौजूदा ऑब्जेक्ट स्वचालित रूप से रोल बैक नहीं होते हैं, इसलिए क्लीनअप एक अलग ऑडिट की गई प्रक्रिया है।
सामान्य गलतियाँ
- गलती: पूरे ऑब्जेक्ट को बदलना। → यह क्यों विफल होता है: स्पष्ट उपयोगकर्ता कॉन्फ़िगरेशन मिट जाता है और स्वामित्व टकराव दिखाई देते हैं। → सुधार: केवल गायब फ़ील्ड लिखें और सूची-मर्ज नियम परिभाषित करें।
- गलती: यह मानना कि बाइंडिंग हटाने से पुराने ऑब्जेक्ट पुनर्स्थापित हो जाते हैं। → यह क्यों विफल होता है: एडमिशन अनुरोधों को प्रभावित करता है; यह रिवर्स म्यूटेशन प्रदान नहीं करता है। → सुधार: एक अलग ऑडिट की गई क्लीनअप प्रक्रिया का उपयोग करें और मौजूदा-ऑब्जेक्ट व्यवहार बताएं।
- गलती: पॉलिसियों के बीच एक निश्चित क्रम पर निर्भर रहना। → यह क्यों विफल होता है: एडमिशन ऑर्डरिंग परिवर्तन परिणाम बदल सकते हैं। → सुधार: फ़ील्ड स्वामित्व को अलग करें या निर्णय को केंद्रीकृत करें।
- गलती: प्रोडक्शन वेबहुक को तुरंत बदलना। → यह क्यों विफल होता है: पीक लोड पर एक्सप्रेशन अंतर सामने आ सकते हैं। → सुधार: पहले शैडो करें, नेमस्पेस द्वारा रोल आउट करें, और वर्ज़न किए गए मेनिफेस्ट बनाए रखें।
फ़ॉलो-अप और प्रतिक्रियाएं
आप ApplyConfiguration और JSONPatch के बीच चयन कैसे करते हैं?
संरचित डिफ़ॉल्ट और स्पष्ट इरादे के लिए ApplyConfiguration का उपयोग करें। सटीक इंसर्शन, विलोपन या एस्केप किए गए पाथ के लिए JSONPatch का उपयोग करें। किसी भी रूप के साथ दोहराव निष्पादन और ऐरे टकराव का परीक्षण करें।
क्या failurePolicy हमेशा Fail होनी चाहिए?
सुरक्षा बेसलाइन और अनुपालन फ़ील्ड अक्सर Fail का पक्ष लेते हैं। गैर-महत्वपूर्ण ऑब्जर्वेबिलिटी लेबल स्पष्ट चेतावनी और मुआवजे के साथ Ignore का उपयोग कर सकते हैं। निर्णय को प्रभाव, उपलब्धता लक्ष्यों और ऑडिट साक्ष्य से जोड़ें।
आप कैसे परीक्षण करते हैं कि कोई पॉलिसी ऑब्जेक्ट्स को दूषित नहीं करेगी?
सर्वर ड्राई रन, निश्चित इनपुट स्नैपशॉट, बार-बार एडमिशन, नेमस्पेस लेबल, पूर्व-सेट उपयोगकर्ता फ़ील्ड, खाली सूचियों और एक्सप्रेशन त्रुटियों के साथ एक मैट्रिक्स बनाएं, फिर पुराने वेबहुक और नए पॉलिसी परिणामों की तुलना करें।
इसके बजाय एक कंट्रोलर क्यों न लिखें?
एडमिशन पर्सिस्टेंस से पहले एक अनुरोध को ब्लॉक या बदलता है, जो डिफ़ॉल्ट और प्रवेश बाधाओं के लिए उपयुक्त है। कंट्रोलर एसिंक्रोनस रूप से समाधान (reconcile) करते हैं और मौजूदा ऑब्जेक्ट्स की मरम्मत करते हैं। वे एक-दूसरे के पूरक हो सकते हैं, लेकिन एक कंट्रोलर प्रवेश सुरक्षा नीति की जगह नहीं लेता है।