कुबेरनेट्स 1.13: प्रमुख नवाचारों का अवलोकन

इस सप्ताह की शुरुआत में , कुबेरनेट्स की अगली रिलीज़ हुई , जिसे "एंजेलिक", 1.13 डब किया गया था। यह नाम 113 नंबर के साथ जुड़ा हुआ है, जिसे "एंगेलिक" माना जाता है और, कुबेरनेट्स डेवलपर्स के अनुसार, "नई शुरुआत, परिवर्तन और नए लोगों को खोलने से पहले एक अध्याय के अंत का प्रतीक है।" हमारे ब्लॉग के लिए पहले से ही स्थापित परंपरा के अनुसार, जो हो रहा है, उसके प्रतीक के आगे के विश्लेषण में जाने के बिना, सातवीं बार हम कुबेरनेट्स के नए संस्करण में महत्वपूर्ण बदलावों के बारे में बात करेंगे, जो कि इस उत्पाद के साथ काम करने वाले देवो-एसआरई-इंजीनियरों को खुश करने के लिए डिज़ाइन किए गए हैं।

जानकारी के स्रोतों के रूप में, हमने कुबेरनेट्स एन्हांसमेंट ट्रैकिंग , चेंगेलॉग-1.13 टेबल और संबंधित मुद्दों, पुल अनुरोधों, कुबेरनेट्स एन्हांसमेंट प्रपोजल (केईपी) के डेटा पर काम किया।

कुबेदम के लिए जीए

कुबेरनेट्स 1.13 रिलीज की मुख्य घटनाओं में से एक कुबेडम कंसोल उपयोगिता के लिए एक स्थिर स्थिति (सामान्य उपलब्धता, जीए) की घोषणा थी। K8s ब्लॉग ने इसके लिए एक अलग प्रकाशन भी समर्पित किया है। जैसा कि बहुत से लोग जानते हैं, कुबेदम प्रोजेक्ट की सर्वोत्तम प्रथाओं के अनुसार कुबेरनेट समूह बनाने के लिए एक उपकरण है, साथ ही साथ उनके आगे न्यूनतम समर्थन भी है। एक विशिष्ट विशेषता यह है कि डेवलपर्स इसे कॉम्पैक्ट / स्वतंत्र और प्रदाता / अवसंरचना से मुक्त रखने का प्रयास करते हैं, न कि बुनियादी ढांचे, तीसरे पक्ष के नेटवर्क समाधान, ऐड-ऑन (निगरानी, ​​लॉगिंग, आदि) जैसे मुद्दों के समाधान सहित, क्लाउड के साथ विशिष्ट एकीकरण। प्रदाताओं।

जीए स्थिति ने निम्नलिखित क्षेत्रों में कुबेदम की परिपक्वता को चिह्नित किया:

• स्थिर कंसोल इंटरफ़ेस, जो कुबेरनेट्स अप्रचलन नीति का अनुसरण करता है: जीए रिलीज़ में प्रस्तुत कमांड और झंडे को कम से कम एक वर्ष के लिए समर्थन किया जाना चाहिए, क्योंकि वे पदावनत किए जाते हैं;
• स्थिर कार्यान्वयन "हूड के नीचे" इस तथ्य के कारण कि क्लस्टर उन तरीकों से बनाया गया है जो निकट भविष्य में नहीं बदलेंगे: नियंत्रण विमान कई स्थिर पॉड्स के रूप में शुरू होता है, बूटस्ट्रैप टोकन kubeadm join लिए उपयोग किए जाते हैं, और क्यूबनेट को कॉन्फ़िगर करने के लिए ComponentCrfig का उपयोग किया जाता है;
• एक नई एपीआई (v1beta1) के साथ कॉन्फ़िगरेशन योजना, जो घोषित रूप से लगभग सभी क्लस्टर घटकों का वर्णन करने की अनुमति देती है (कुबड्म के साथ बनाए गए क्लस्टर के लिए GitOps संभव है) - संस्करण v1 के उन्नयन को बिना या न्यूनतम बदलावों के साथ योजना बनाई गई है;
• kubeadm ( kubeadm init phase ) में तथाकथित चरण (या टूलबॉक्स इंटरफ़ेस), आपको यह चुनने की अनुमति देता है कि कौन सी आरंभीकरण प्रक्रियाएं निष्पादित की जाएंगी;
• kubeadm upgrade दल रिलीज के बीच क्लस्टर अपडेट्स की गारंटी देता है। 1.10.x, 1.11.x, 1.12.x और 1.13.x (अपडेट्स etc, API सर्वर, कंट्रोलर मैनेजर और शेड्यूलर);
• यदि आवश्यक हो तो HA-क्लस्टर तक विस्तार करने की क्षमता के साथ डिफ़ॉल्ट रूप से etcd की सुरक्षित स्थापना (यह हर जगह टीएलएस का उपयोग करता है)।

यह भी ध्यान दिया जा सकता है कि कुबेदम अब डोकर 18.09.0 और इसके नए संस्करणों को सही ढंग से पहचानता है। अंत में, डेवलपर्स kubeadm उपयोगकर्ताओं को एक छोटा सा ऑनलाइन सर्वेक्षण लेने के लिए कहते हैं जिसमें वे परियोजना के उपयोग और विकास पर अपनी इच्छा व्यक्त कर सकते हैं।

डिफ़ॉल्ट रूप से CoreDNS

कोरडीएनएस, जिसे कुबेरनेट्स 1.11 रिलीज़ में स्थिर दर्जा प्राप्त हुआ, और भी आगे बढ़ गया और K8s (अब तक उपयोग किए गए क्यूब-डीएनएस के बजाय) में डिफ़ॉल्ट डीएनएस सर्वर बन गया । यह योजना बनाई गई थी कि यह 1.12 के रूप में जल्दी होगा, लेकिन डेवलपर्स को स्केलेबिलिटी और मेमोरी खपत में अतिरिक्त अनुकूलन की आवश्यकता का सामना करना पड़ा था, जो केवल वर्तमान रिलीज़ द्वारा पूरा किया गया था।



क्यूब-डीएनएस के लिए समर्थन "कम से कम एक अगली रिलीज के लिए" जारी रहेगा, लेकिन डेवलपर्स अब अप-टू-डेट समाधान के लिए पलायन शुरू करने की आवश्यकता के बारे में बात कर रहे हैं।

Kubernetes 1.13 में CoreDNS विषय से संबंधित परिवर्तनों में से, NodeLocal DNS कैश प्लगइन को DNS प्रदर्शन को बेहतर बनाने के लिए भी नोट किया जा सकता है । DNS कैश के लिए क्लस्टर नोड्स पर एक एजेंट चलाकर सुधार प्राप्त किया जाता है, जिसे सीधे इस नोड के पॉड्स द्वारा एक्सेस किया जाएगा। डिफ़ॉल्ट रूप से, फ़ंक्शन अक्षम है, और इसे सक्रिय करने के लिए, आपको KUBE_ENABLE_NODELOCAL_DNS=true सेट करना होगा।

भंडारण की सुविधा

कुबेरनेट्स की हालिया रिलीज़ में बहुत अधिक ध्यान कंटेनर स्टोरेज इंटरफेस (CSI) के साथ काम करने के लिए दिया गया है, जो कि K8s 1.9 में CSI के अल्फा संस्करण के साथ शुरू हुआ, 1.10 पर बीटा संस्करण के साथ जारी रहा ... हालांकि, हम पहले से ही इसके बारे में एक से अधिक बार देख चुके हैं । K8s 1.13 में एक महत्वपूर्ण नया मील का पत्थर पहुंच गया है: CSI समर्थन को स्थिर (GA) घोषित किया गया है ।


(" कंटेनर भंडारण इंटरफ़ेस को समझना " लेख से आरेख)

इसके साथ ही, CSI विनिर्देशन v1.0.0 के लिए समर्थन दिखाई दिया और मानक (0.3 और पुराने) के पुराने संस्करणों के लिए समर्थन को हटा दिया गया। इसका मतलब यह है कि पुराने CSI ड्राइवरों को Kubernetes 1.15 और पुराने में काम करने के लिए CSI 1.0 (और नए क्यूबलेट प्लगइन पंजीकरण निर्देशिका में जाने) की आवश्यकता होगी। वैसे, खुद ड्राइवरों से, एडब्ल्यूएस ईबीएस वॉल्यूम (इलास्टिक ब्लॉक स्टोर) के जीवन चक्र के प्रबंधन के लिए सीएसआई इंटरफेस के अल्फा संस्करण की उपस्थिति को ध्यान देने योग्य है।

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

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

Kubernetes 1.9 में ब्लॉक रॉ डिवाइस (नेटवर्क नहीं) का उपयोग करने के लिए पेश किए गए अवसर को लगातार वॉल्यूम को बीटा में अनुवाद किया गया है और अब यह डिफ़ॉल्ट रूप से सक्षम है।

हम इस तथ्य के साथ भंडारण के विषय को समाप्त करते हैं कि GCERegionalPersistentDisk के लिए समर्थन स्थिर घोषित किया गया है।

क्लस्टर नोड्स

तृतीय-पक्ष डिवाइस निगरानी प्लगइन्स के लिए समर्थन का अल्फा संस्करण पेश किया गया है । इस पहल के पीछे विचार यह है कि डिवाइस-विशिष्ट ज्ञान को क्यूबलेट से पेड़ से बाहर लाया जाए। क्लस्टर व्यवस्थापक कंटेनर स्तर पर डिवाइस प्लगइन्स द्वारा रिपोर्ट किए गए मैट्रिक्स प्राप्त करेंगे, और निर्माता कुबेरनेट्स कोर में बदलाव किए बिना इन मैट्रिक्स को बनाने में सक्षम होंगे। कार्यान्वयन का विवरण प्रस्ताव में पाया जा सकता है, जिसे क्यूबलेट मेटाडेटा एपीआई कहा जाता है ।

स्थिर घोषित किया गया , क्यूबलेट प्लगिन वॉचर (जिसे कुब्लेट डिवाइस प्लगिन पंजीकरण के रूप में भी जाना जाता है) नोड-स्तर प्लग-इन (डिवाइस प्लग-इन, सीएसआई और सीएनआई) को क्यूबलेट के साथ अपने बारे में संवाद करने की अनुमति देता है।

अल्फा स्थिति में एक नई सुविधा NodeLease है । यदि पहले नोड के "दिल की धड़कन" को NodeStatus द्वारा निर्धारित किया गया था, तो एक नई सुविधा के साथ, प्रत्येक नोड में एक Lease ऑब्जेक्ट जुड़ा होता है ( kube-node-lease नेमस्पेस में), जो समय-समय पर नोड द्वारा अपडेट किया जाता है। "पल्स" अब दोनों मापदंडों द्वारा निर्धारित किया गया है: पुराना नोडस्टैटस, जो केवल परिवर्तन के मामले में या एक निश्चित समय समाप्त होने तक मास्टर को सूचित किया जाता है (डिफ़ॉल्ट रूप से यह प्रति मिनट एक बार होता है), और एक नया ऑब्जेक्ट (इसे अक्सर अपडेट किया जाता है)। चूंकि यह ऑब्जेक्ट बहुत छोटा है, इसलिए यह स्केलेबिलिटी और प्रदर्शन में बहुत सुधार करेगा। लेखक 2000 से अधिक नोड्स के आकार के साथ क्लस्टर का परीक्षण करने के बाद एक नया "पल्स" बनाने के बारे में सेट करते हैं, जो कि उनके काम के दौरान कॉर्ड-लिमिट के खिलाफ आराम कर सकते हैं, अधिक जानकारी के लिए केईपी-0009 देखें।

 type Lease struct { metav1.TypeMeta `json:",inline"` // Standard object's metadata. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#metadata // +optional ObjectMeta metav1.ObjectMeta `json:"metadata,omitempty"` // Specification of the Lease. // More info: https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status // +optional Spec LeaseSpec `json:"spec,omitempty"` } type LeaseSpec struct { HolderIdentity string `json:"holderIdentity"` LeaseDurationSeconds int32 `json:"leaseDurationSeconds"` AcquireTime metav1.MicroTime `json:"acquireTime"` RenewTime metav1.MicroTime `json:"renewTime"` LeaseTransitions int32 `json:"leaseTransitions"` } 

(नोड के "पल्स" का प्रतिनिधित्व करने के लिए नई वस्तु का कॉम्पैक्ट विनिर्देश - Lease - LeaderElectionRecord समान है)

सुरक्षा

डायनेमिक ऑडिट कंट्रोल का अल्फा संस्करण डायनामिक एडमिशन कंट्रोल के विचारों का अनुसरण करता है और उन्नत ऑडिट क्षमताओं का एक गतिशील कॉन्फ़िगरेशन प्रदान करता है - इसके लिए आप अब एक वेबहूक को पंजीकृत कर सकते हैं जो घटनाओं की एक धारा प्राप्त करेगा। इस सुविधा की आवश्यकता को इस तथ्य से समझाया गया है कि कुबेरनेट्स ऑडिटिंग बहुत शक्तिशाली सुविधाएँ प्रदान करता है, लेकिन उन्हें कॉन्फ़िगर करना मुश्किल है, और प्रत्येक कॉन्फ़िगरेशन परिवर्तन के लिए अभी भी एक एसेज़र की आवश्यकता होती है।

डेटा इनक्रिप्शन ( एन डी प्रलेखन देखें) को प्रायोगिक स्थिति से बीटा में स्थानांतरित कर दिया गया है ।

 kind: EncryptionConfiguration apiVersion: apiserver.config.k8s.io/v1 resources: - resources: - secrets providers: - identity: {} - aesgcm: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - aescbc: keys: - name: key1 secret: c2VjcmV0IGlzIHNlY3VyZQ== - name: key2 secret: dGhpcyBpcyBwYXNzd29yZA== - secretbox: keys: - name: key1 secret: YWJjZGVmZ2hpamtsbW5vcHFyc3R1dnd4eXoxMjM0NTY= 

(एन्क्रिप्टेड डेटा के साथ एक उदाहरण विन्यास प्रलेखन से लिया गया है ।)

इस श्रेणी में कम महत्वपूर्ण नवाचारों में:

• अब ऑडिट लॉग में प्राप्त नहीं किए जा सकने वाले अनुरोधों को अस्वीकार करने के लिए एपिस्वर को कॉन्फ़िगर किया जा सकता है ।
• PodSecurityPolicy ऑब्जेक्ट्स PodSecurityPolicy fsGroup और supplementalGroups विकल्पों के लिए MayRunAs नियम के समर्थन के साथ जोड़ा PodSecurityPolicy था , जो डिफ़ॉल्ट GID को मजबूर किए बिना फली / कंटेनरों के लिए अनुमत समूह पहचानकर्ताओं (GID) की सीमा को परिभाषित करने की अनुमति देता है। इसके अलावा, PodSecurityPolicy साथ, रनअर्सग्रुप रणनीति अब RunAsGroup के विनिर्देश में संभव है, अर्थात। आप कंटेनरों के लिए मुख्य GID को नियंत्रित कर सकते हैं।
• क्यूब-शेड्यूलर के लिए, हमने पिछले असुरक्षित पोर्ट (10251) को नए सुरक्षित पोर्ट (10259) से बदल दिया और इसे डिफ़ॉल्ट रूप से चालू कर दिया। यदि कोई अतिरिक्त झंडे निर्दिष्ट नहीं हैं, तो लोड होने पर, स्मृति में इसके लिए स्व-हस्ताक्षरित प्रमाण पत्र बनाए जाते हैं।

CLI

kubectl diff , जो स्थानीय कॉन्फ़िगरेशन और वर्किंग ऑब्जेक्ट के वर्तमान विवरण के बीच अंतर दिखाती है (कॉन्फ़िगरेशन के साथ निर्देशिकाओं के लिए कार्य और पुनरावर्ती रूप से), बीटा स्थिति प्राप्त की है।

वास्तव में, " kubectl apply " में बदलाव करें, जो कि kubectl apply साथ किए जाएंगे, और एक और नई सुविधा का उपयोग किया जाता है - APIServer DryRun । इसका सार - निष्क्रिय शुरुआत - नाम से स्पष्ट होना चाहिए, और एक अधिक विस्तृत विवरण कुबेरनेट्स प्रलेखन में उपलब्ध है। वैसे, रिलीज़ 1.13 में ड्राईरुन फ़ंक्शन को बीटा संस्करण में "अपग्रेड" भी किया गया था और डिफ़ॉल्ट रूप से चालू किया गया था।

और कुबेरनेट्स के कंसोल वर्ल्ड में बीटा की एक और प्रगति ने नए प्लगइन तंत्र को प्रभावित किया है । रास्ते के साथ, उन्होंने प्लगइन्स ( kubectl plugin list ) के आउटपुट के क्रम को सही किया , वहां से अतिरिक्त छंटाई को हटा दिया।

इसके अलावा, उपयोग किए गए kubectl describe node -भंडारण संसाधनों के आउटपुट को kubectl describe node में जोड़ा गया था, और अनुमानित प्रकार के वॉल्यूम को kubectl describe pod जोड़ा गया था।

अन्य परिवर्तन

टेंट बेस्ड एविक्शन शेड्यूलर फ़ंक्शन को बीटा स्थिति में बदल दिया गया है और विकास में एक लंबी खामोशी के बाद डिफ़ॉल्ट रूप से सक्षम है। इसका उद्देश्य स्वचालित रूप से कुछ शर्तों की घटना पर नोड्स (NodeController या kubelet के माध्यम से) को जोड़ने के लिए है, जैसे कि, उदाहरण के लिए, node.kubernetes.io/not-ready / node.kubernetes.io/not-ready , जो Ready=False में NodeCondition मान से मेल खाती है।

क्लस्टर के संचालन के लिए महत्वपूर्ण पॉड्स का एक एनोटेशन - critical-pod - को हटा दिया जाता है। इसके बजाय, प्राथमिकताओं का उपयोग करने का प्रस्ताव है (कुबेरनेट्स 1.11 के साथ बीटा में) ।

AWS के लिए, पहली बार (अल्फा संस्करणों के भाग के रूप में), निम्नलिखित उपलब्ध हुआ:

• AWS ALB (एप्लीकेशन लोड बैलेंसर) के लिए कुबेरनेट्स इनग्रेडेशन संसाधनों के साथ एकीकरण - aws-alb- ingress- नियंत्रक (प्रोजेक्ट मूल रूप से Ticketmaster और CoreOS द्वारा बनाया गया था जो पहले AWS क्लाउड पर माइग्रेट करता था);
• AWS का बाहरी CCM (क्लाउड नियंत्रक प्रबंधक) - क्लाउड-प्रदाता-aws , जो क्लाउड-विशिष्ट प्रदाता (AWS) कार्यक्षमता के साथ नियंत्रकों को लॉन्च करने के लिए जिम्मेदार है।

SIG Azure ने Azure Disk (Ultra SSD, Standard SSD और Premium Azure Files) के लिए अतिरिक्त समर्थन लागू किया और बीटा के लिए क्रॉस रिसोर्स ग्रुप नोड्स को बढ़ावा दिया। इसके अलावा, विंडोज के लिए सीएनआई प्लगइन्स में अब डीएनएस को एक कंटेनर में कॉन्फ़िगर करने की क्षमता है।

अनुकूलता

• Thedd संस्करण 3.2.24 है (कुबेरनेट्स 1.12 के बाद से नहीं बदला है)।
• डॉकर के सत्यापित संस्करण - 1.11.1, 1.12.1, 1.13.1, 17.03, 17.06, 17.09, 18.06 (भी नहीं बदले हैं)।
• गो संस्करण - 1.11.2, न्यूनतम समर्थित के साथ मेल खाता है।
• CNI संस्करण 0.6.0 है।
• CSI संस्करण 1.0.0 है।
• CoreDNS संस्करण 1.2.6 है।

पुनश्च

हमारे ब्लॉग में भी पढ़ें:

• "हम कंटेनर भंडारण इंटरफ़ेस (कुबेरनेट्स में और न केवल) को समझते हैं ";
• " कुबेरनेट्स 1.12: मुख्य नवाचारों का अवलोकन ";
• " कुबेरनेट्स 1.11: कुंजी नवाचारों का अवलोकन ";
• " कुबेरनेट्स 1.10: प्रमुख नवाचारों का अवलोकन ";
• कुबेरनेट्स 1.9: कुंजी नवाचारों का अवलोकन ।