एग्रीगेशन लेयर कॉन्फ़िगर करें

एग्रीगेशन लेयर को कॉन्फ़िगर करने से कुबेरनेट्स apiserver को अतिरिक्त APIs के साथ विस्तारित किया जा सकता है, जो कोर कुबेरनेट्स APIs का हिस्सा नहीं हैं।

शुरू करने से पहले

आपको कुबरनेट्स क्लस्टर की ज़रूरत पड़ेगी और क्यूब सीटीएल कमांड लाइन साधन को समनुरूप करना होगा ताकि वो आपके क्लस्टर के साथ संवाद कर सकें। हमारी सलाह है की इस टुटोरिअल को क्लस्टर में रन करने के लिए कम से कम दो नोड का इस्तेमाल करे जो कि कंट्रोल प्लेन होस्ट के तरह ना एक्ट करे। अगर आपके पास पहले से क्लस्टर नही है, आप minikube की मदद से वह बना सकते है या आप नीचे दिए हुए इन दो कुबरनेट्स प्लेग्राउंड का इस्तेमाल कर सकते हैं:

• Katacoda
• प्ले विथ कुबेरनेट्स

संस्करण की जांच करने के लिए, लिखें kubectl version.

प्रमाणीकरण प्रवाह

कस्टम रिसोर्स डेफिनिशन (CRDs) के विपरीत, एग्रीगेशन API में मानक कुबेरनेट्स apiserver के अतिरिक्त एक अन्य सर्वर - आपका एक्सटेंशन apiserver - शामिल है। कुबेरनेट्स apiserver को आपके एक्सटेंशन apiserver के साथ संवाद करने की आवश्यकता होगी, और आपके एक्सटेंशन apiserver को कुबेरनेट्स apiserver के साथ संवाद करने की आवश्यकता होगी। इस संचार को सुरक्षित करने के लिए, कुबेरनेट्स apiserver x509 सर्टिफिकेट का उपयोग करता है ताकि यह स्वयं को एक्सटेंशन apiserver के लिए प्रमाणित कर सके।

यह खंड बताता है कि प्रमाणीकरण और प्राधिकरण प्रवाह कैसे काम करते हैं, और उन्हें कैसे कॉन्फ़िगर किया जाए।

उच्च-स्तरीय प्रवाह इस प्रकार है:

1. कुबेरनेट्स apiserver: अनुरोध करने वाले उपयोगकर्ता को प्रमाणित करें और अनुरोधित API पथ के लिए उनके अधिकारों को प्राधिकृत करें।
2. कुबेरनेट्स apiserver: अनुरोध को एक्सटेंशन apiserver पर प्रॉक्सी करें
3. एक्सटेंशन apiserver: कुबेरनेट्स apiserver से अनुरोध को प्रमाणित करें
4. एक्सटेंशन apiserver: मूल उपयोगकर्ता से अनुरोध को प्राधिकृत करें
5. एक्सटेंशन apiserver: निष्पादित करें

इस खंड का शेष भाग इन चरणों का विस्तार से वर्णन करता है।

प्रवाह को निम्नलिखित आरेख में देखा जा सकता है।

कुबेरनेट्स Apiserver प्रमाणीकरण और प्राधिकरण

एक्सटेंशन apiserver द्वारा सेवित API पथ के लिए एक अनुरोध सभी API अनुरोधों की तरह शुरू होता है: कुबेरनेट्स apiserver के साथ संचार। यह पथ पहले से ही एक्सटेंशन apiserver द्वारा कुबेरनेट्स apiserver के साथ पंजीकृत किया गया है।

उपयोगकर्ता कुबेरनेट्स apiserver के साथ संवाद करता है, पथ तक पहुंच का अनुरोध करता है। कुबेरनेट्स apiserver मानक प्रमाणीकरण और प्राधिकरण का उपयोग करता है जो कुबेरनेट्स apiserver के साथ कॉन्फ़िगर किया गया है ताकि उपयोगकर्ता को प्रमाणित किया जा सके और विशिष्ट पथ तक पहुंच को प्राधिकृत किया जा सके।

कुबेरनेट्स क्लस्टर में प्रमाणीकरण का अवलोकन के लिए, "क्लस्टर में प्रमाणीकरण" देखें। कुबेरनेट्स क्लस्टर संसाधनों तक पहुंच के प्राधिकरण का अवलोकन के लिए, "प्राधिकरण अवलोकन" देखें।

इस बिंदु तक सब कुछ मानक कुबेरनेट्स API अनुरोध, प्रमाणीकरण और प्राधिकरण रहा है।

अब कुबेरनेट्स apiserver एक्सटेंशन apiserver को अनुरोध भेजने के लिए तैयार है।

कुबेरनेट्स Apiserver अनुरोध को प्रॉक्सी करता है

अब कुबेरनेट्स apiserver अनुरोध को एक्सटेंशन apiserver पर भेजेगा, या प्रॉक्सी करेगा, जो अनुरोध को हैंडल करने के लिए पंजीकृत है। ऐसा करने के लिए, इसे कई चीजें जानने की आवश्यकता है:

1. कुबेरनेट्स apiserver को एक्सटेंशन apiserver के साथ कैसे प्रमाणित होना चाहिए, एक्सटेंशन apiserver को सूचित करते हुए कि अनुरोध, जो नेटवर्क पर आता है, एक वैध कुबेरनेट्स apiserver से आ रहा है?
2. कुबेरनेट्स apiserver को एक्सटेंशन apiserver को कैसे सूचित करना चाहिए उस उपयोगकर्ता नाम और समूह के बारे में जिसके लिए मूल अनुरोध प्रमाणित किया गया था?

इन दोनों के लिए प्रावधान करने के लिए, आपको कई फ्लैग का उपयोग करके कुबेरनेट्स apiserver को कॉन्फ़िगर करना होगा।

कुबेरनेट्स Apiserver क्लाइंट प्रमाणीकरण

कुबेरनेट्स apiserver TLS के माध्यम से एक्सटेंशन apiserver से कनेक्ट होता है, एक क्लाइंट सर्टिफिकेट का उपयोग करके स्वयं को प्रमाणित करता है। आपको स्टार्टअप पर प्रदान किए गए फ्लैग का उपयोग करके कुबेरनेट्स apiserver को निम्नलिखित प्रदान करना होगा:

• प्राइवेट की फ़ाइल --proxy-client-key-file के माध्यम से
• साइन किया गया क्लाइंट सर्टिफिकेट फ़ाइल --proxy-client-cert-file के माध्यम से
• क्लाइंट सर्टिफिकेट फ़ाइल को साइन करने वाले CA का सर्टिफिकेट --requestheader-client-ca-file के माध्यम से
• साइन किए गए क्लाइंट सर्टिफिकेट में वैध कॉमन नेम वैल्यू (CNs) --requestheader-allowed-names के माध्यम से

कुबेरनेट्स apiserver --proxy-client-*-file द्वारा इंगित फ़ाइलों का उपयोग करेगा एक्सटेंशन apiserver के साथ प्रमाणित होने के लिए। अनुरोध को एक अनुपालन एक्सटेंशन apiserver द्वारा वैध माना जाने के लिए, निम्नलिखित शर्तें पूरी होनी चाहिए:

1. कनेक्शन एक क्लाइंट सर्टिफिकेट का उपयोग करके किया जाना चाहिए जो उस CA द्वारा साइन किया गया हो जिसका सर्टिफिकेट --requestheader-client-ca-file में है।
2. कनेक्शन एक क्लाइंट सर्टिफिकेट का उपयोग करके किया जाना चाहिए जिसका CN उनमें से एक है जो --requestheader-allowed-names में सूचीबद्ध हैं।

इन विकल्पों के साथ शुरू किए जाने पर, कुबेरनेट्स apiserver:

1. उनका उपयोग एक्सटेंशन apiserver के साथ प्रमाणित होने के लिए करेगा।
2. kube-system नेमस्पेस में extension-apiserver-authentication नामक एक कॉन्फ़िगमैप बनाएगा, जिसमें यह CA सर्टिफिकेट और अनुमत CNs को रखेगा। इन्हें बदले में एक्सटेंशन apiserver द्वारा अनुरोधों को मान्य करने के लिए पुनर्प्राप्त किया जा सकता है।

ध्यान दें कि एक ही क्लाइंट सर्टिफिकेट का उपयोग कुबेरनेट्स apiserver द्वारा सभी एक्सटेंशन apiserver के विरुद्ध प्रमाणित होने के लिए किया जाता है। यह प्रति एक्सटेंशन apiserver एक क्लाइंट सर्टिफिकेट नहीं बनाता है, बल्कि कुबेरनेट्स apiserver के रूप में प्रमाणित होने के लिए एक ही सर्टिफिकेट का उपयोग करता है। यही एक सभी एक्सटेंशन apiserver अनुरोधों के लिए पुन: उपयोग किया जाता है।

मूल अनुरोध उपयोगकर्ता नाम और समूह

जब कुबेरनेट्स apiserver अनुरोध को एक्सटेंशन apiserver पर प्रॉक्सी करता है, यह एक्सटेंशन apiserver को उस उपयोगकर्ता नाम और समूह के बारे में सूचित करता है जिसके साथ मूल अनुरोध सफलतापूर्वक प्रमाणित हुआ था। यह इन्हें अपने प्रॉक्सी किए गए अनुरोध के http हेडर में प्रदान करता है। आपको कुबेरनेट्स apiserver को उपयोग किए जाने वाले हेडर के नामों के बारे में बताना होगा।

• उपयोगकर्ता नाम को स्टोर करने के लिए हेडर --requestheader-username-headers के माध्यम से
• समूह को स्टोर करने के लिए हेडर --requestheader-group-headers के माध्यम से
• सभी अतिरिक्त हेडर में जोड़े जाने वाले प्रीफ़िक्स --requestheader-extra-headers-prefix के माध्यम से

ये हेडर नाम भी extension-apiserver-authentication कॉन्फ़िगमैप में रखे जाते हैं, ताकि एक्सटेंशन apiserver द्वारा उन्हें पुनर्प्राप्त और उपयोग किया जा सके।

एक्सटेंशन Apiserver अनुरोध को प्रमाणित करता है

कुबेरनेट्स apiserver से प्रॉक्सी किए गए अनुरोध को प्राप्त करने पर, एक्सटेंशन apiserver को यह सत्यापित करना होगा कि अनुरोध वास्तव में एक वैध प्रमाणीकरण प्रॉक्सी से आया है, जिस भूमिका को कुबेरनेट्स apiserver पूरा कर रहा है। एक्सटेंशन apiserver इसे निम्नानुसार सत्यापित करता है:

1. ऊपर वर्णित अनुसार kube-system में कॉन्फ़िगमैप से निम्नलिखित पुनर्प्राप्त करें:
   • क्लाइंट CA सर्टिफिकेट
   • अनुमत नामों (CNs) की सूची
   • उपयोगकर्ता नाम, समूह और अतिरिक्त जानकारी के लिए हेडर नाम
2. जांचें कि TLS कनेक्शन क्लाइंट सर्टिफिकेट का उपयोग करके प्रमाणित किया गया था जो:
   • उस CA द्वारा साइन किया गया था जिसका सर्टिफिकेट पुनर्प्राप्त CA सर्टिफिकेट से मेल खाता है।
   • अनुमत CNs की सूची में CN है, जब तक कि सूची खाली न हो, उस स्थिति में सभी CNs स्वीकार्य हैं।
   • उपयुक्त हेडर से उपयोगकर्ता नाम और समूह निकालें

यदि उपरोक्त पास हो जाता है, तो अनुरोध एक वैध प्रॉक्सी किए गए अनुरोध है जो एक वैध प्रमाणीकरण प्रॉक्सी से आता है, इस मामले में कुबेरनेट्स apiserver।

ध्यान दें कि उपरोक्त प्रदान करना एक्सटेंशन apiserver कार्यान्वयन की जिम्मेदारी है। कई इसे डिफ़ॉल्ट रूप से करते हैं, k8s.io/apiserver/ पैकेज का लाभ उठाते हुए। अन्य कमांड-लाइन विकल्पों का उपयोग करके इसे ओवरराइड करने के विकल्प प्रदान कर सकते हैं।

कॉन्फ़िगमैप पुनर्प्राप्त करने की अनुमति के लिए, एक्सटेंशन apiserver को उपयुक्त भूमिका की आवश्यकता होती है। kube-system नेमस्पेस में extension-apiserver-authentication-reader नामक एक डिफ़ॉल्ट भूमिका है जिसे असाइन किया जा सकता है।

एक्सटेंशन Apiserver अनुरोध को प्राधिकृत करता है

एक्सटेंशन apiserver अब यह सत्यापित कर सकता है कि हेडर से पुनर्प्राप्त उपयोगकर्ता/समूह दिए गए अनुरोध को निष्पादित करने के लिए प्राधिकृत हैं। यह कुबेरनेट्स apiserver को एक मानक SubjectAccessReview अनुरोध भेजकर ऐसा करता है।

एक्सटेंशन apiserver के लिए स्वयं कुबेरनेट्स apiserver को SubjectAccessReview अनुरोध जमा करने के लिए प्राधिकृत होने के लिए, इसे सही अनुमतियों की आवश्यकता होती है। कुबेरनेट्स में system:auth-delegator नामक एक डिफ़ॉल्ट ClusterRole शामिल है जिसमें उपयुक्त अनुमतियां हैं। इसे एक्सटेंशन apiserver के सर्विस अकाउंट को प्रदान किया जा सकता है।

एक्सटेंशन Apiserver निष्पादित करता है

यदि SubjectAccessReview पास हो जाता है, तो एक्सटेंशन apiserver अनुरोध को निष्पादित करता है।

कुबेरनेट्स Apiserver फ्लैग सक्षम करें

निम्नलिखित kube-apiserver फ्लैग के माध्यम से एग्रीगेशन लेयर को सक्षम करें। आपके प्रोवाइडर द्वारा इन्हें पहले से ही संभाला जा चुका हो सकता है।

--requestheader-client-ca-file=<एग्रीगेटर CA सर्ट का पथ>
--requestheader-allowed-names=front-proxy-client
--requestheader-extra-headers-prefix=X-Remote-Extra-
--requestheader-group-headers=X-Remote-Group
--requestheader-username-headers=X-Remote-User
--proxy-client-cert-file=<एग्रीगेटर प्रॉक्सी सर्ट का पथ>
--proxy-client-key-file=<एग्रीगेटर प्रॉक्सी कुंजी का पथ>

CA पुनर्प्रयोग और विरोध

कुबेरनेट्स apiserver के दो क्लाइंट CA विकल्प हैं:

• --client-ca-file
• --requestheader-client-ca-file

इनमें से प्रत्येक स्वतंत्र रूप से कार्य करता है और एक दूसरे के साथ विरोध कर सकता है, यदि सही ढंग से उपयोग नहीं किया जाए।

• --client-ca-file: जब कुबेरनेट्स apiserver पर एक अनुरोध आता है, यदि यह विकल्प सक्षम है, तो कुबेरनेट्स apiserver अनुरोध के सर्टिफिकेट की जांच करता है। यदि यह --client-ca-file द्वारा संदर्भित फ़ाइल में CA सर्टिफिकेट में से एक द्वारा साइन किया गया है, तो अनुरोध को वैध माना जाता है, और उपयोगकर्ता कॉमन नेम CN= का मान है, जबकि समूह संगठन O= है। TLS प्रमाणीकरण पर दस्तावेज़ीकरण देखें।
• --requestheader-client-ca-file: जब कुबेरनेट्स apiserver पर एक अनुरोध आता है, यदि यह विकल्प सक्षम है, तो कुबेरनेट्स apiserver अनुरोध के सर्टिफिकेट की जांच करता है। यदि यह --requestheader-client-ca-file द्वारा संदर्भित फ़ाइल में CA सर्टिफिकेट में से एक द्वारा साइन किया गया है, तो अनुरोध को संभावित रूप से वैध माना जाता है। फिर कुबेरनेट्स apiserver जांचता है कि क्या कॉमन नेम CN= --requestheader-allowed-names द्वारा प्रदान की गई सूची में से एक है। यदि नाम अनुमत है, तो अनुरोध स्वीकृत हो जाता है; यदि नहीं, तो अनुरोध अस्वीकृत हो जाता है।

यदि दोनों --client-ca-file और --requestheader-client-ca-file प्रदान किए जाते हैं, तो अनुरोध पहले --requestheader-client-ca-file CA की जांच करता है और फिर --client-ca-file की। सामान्यतः, इन विकल्पों में से प्रत्येक के लिए अलग-अलग CA का उपयोग किया जाता है, या तो रूट CA या इंटरमीडिएट CA; नियमित क्लाइंट अनुरोध --client-ca-file से मेल खाते हैं, जबकि एग्रीगेशन अनुरोध --requestheader-client-ca-file से मेल खाते हैं। हालांकि, यदि दोनों समान CA का उपयोग करते हैं, तो सामान्य रूप से --client-ca-file के माध्यम से पास होने वाले क्लाइंट अनुरोध विफल हो जाएंगे, क्योंकि CA --requestheader-client-ca-file में CA से मेल खाएगा, लेकिन कॉमन नेम CN= --requestheader-allowed-names में स्वीकार्य कॉमन नामों में से एक से मेल नहीं खाएगा। इससे आपके kubelets और अन्य कंट्रोल प्लेन घटकों के साथ-साथ अंतिम उपयोगकर्ताओं को कुबेरनेट्स apiserver के साथ प्रमाणित होने में असमर्थ हो सकता है।

इस कारण से, --client-ca-file विकल्प - कंट्रोल प्लेन घटकों और अंतिम उपयोगकर्ताओं को प्राधिकृत करने के लिए - और --requestheader-client-ca-file विकल्प - एग्रीगेशन apiserver अनुरोधों को प्राधिकृत करने के लिए - के लिए अलग-अलग CA सर्ट का उपयोग करें।

यदि आप API सर्वर चलाने वाले होस्ट पर kube-proxy नहीं चला रहे हैं, तो आपको यह सुनिश्चित करना होगा कि सिस्टम निम्नलिखित kube-apiserver फ्लैग के साथ सक्षम है:

--enable-aggregator-routing=true

APIService ऑब्जेक्ट्स पंजीकृत करें

आप गतिशील रूप से कॉन्फ़िगर कर सकते हैं कि कौन से क्लाइंट अनुरोध एक्सटेंशन apiserver पर प्रॉक्सी किए जाएं। निम्नलिखित एक उदाहरण पंजीकरण है:

apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  name: <पंजीकरण ऑब्जेक्ट का नाम>
spec:
  group: <यह एक्सटेंशन apiserver जिस API समूह को होस्ट करता है>
  version: <यह एक्सटेंशन apiserver जिस API संस्करण को होस्ट करता है>
  groupPriorityMinimum: <इस समूह के लिए इस APIService की प्राथमिकता, API दस्तावेज़ीकरण देखें>
  versionPriority: <एक समूह के भीतर इस संस्करण की क्रमबद्धता को प्राथमिकता देता है, API दस्तावेज़ीकरण देखें>
  service:
    namespace: <एक्सटेंशन apiserver सेवा का नेमस्पेस>
    name: <एक्सटेंशन apiserver सेवा का नाम>
  caBundle: <pem एनकोडेड ca cert जो सर्वर सर्ट को साइन करता है जिसका उपयोग वेबहुक द्वारा किया जाता है>

एक APIService ऑब्जेक्ट का नाम एक वैध पथ सेगमेंट नाम होना चाहिए।

एक्सटेंशन apiserver से संपर्क करना

एक बार कुबेरनेट्स apiserver ने निर्धारित कर लिया कि अनुरोध एक्सटेंशन apiserver को भेजा जाना चाहिए, इसे यह जानने की आवश्यकता है कि इससे कैसे संपर्क किया जाए।

service स्टैंज़ा एक्सटेंशन apiserver की सेवा का संदर्भ है। सेवा नेमस्पेस और नाम आवश्यक हैं। पोर्ट वैकल्पिक है और डिफ़ॉल्ट रूप से 443 है।

यहां एक एक्सटेंशन apiserver का उदाहरण है जो पोर्ट "1234" पर कॉल करने के लिए कॉन्फ़िगर किया गया है, और ServerName my-service-name.my-service-namespace.svc के विरुद्ध TLS कनेक्शन को सत्यापित करने के लिए कस्टम CA बंडल का उपयोग करता है।

apiVersion: apiregistration.k8s.io/v1
kind: APIService
...
spec:
  ...
  service:
    namespace: my-service-namespace
    name: my-service-name
    port: 1234
  caBundle: "Ci0tLS0tQk...<base64-encoded PEM bundle>...tLS0K"
...

आगे क्या है

• एग्रीगेशन लेयर के साथ काम करने के लिए एक एक्सटेंशन api-server सेट करें।
• एक उच्च स्तरीय अवलोकन के लिए, एग्रीगेशन लेयर के साथ कुबेरनेट्स API का विस्तार देखें।
• जानें कि कैसे कस्टम रिसोर्स डेफिनिशन का उपयोग करके कुबेरनेट्स API का विस्तार करें।