Kubernetes 1.14: मुख्य आविष्कारहरूको सिंहावलोकन

यो रात हुनेछ Kubernetes को अर्को रिलीज - 1.14। हाम्रो ब्लगको लागि विकसित भएको परम्परा अनुसार, हामी यो अद्भुत खुला स्रोत उत्पादनको नयाँ संस्करणमा मुख्य परिवर्तनहरूको बारेमा कुरा गर्दैछौं।

यो सामग्री तयार गर्न प्रयोग गरिएको जानकारी बाट लिइएको हो Kubernetes संवर्द्धन ट्र्याकिङ तालिकाहरू, परिवर्तन-१.१४ र सम्बन्धित मुद्दाहरू, पुल अनुरोधहरू, Kubernetes Enhancement Proposals (KEP)।

SIG क्लस्टर-लाइफसायकलको महत्त्वपूर्ण परिचयको साथ सुरु गरौं: गतिशील फेलओभर क्लस्टरहरू Kubernetes (वा अधिक सटीक हुन, स्व-होस्ट गरिएको HA परिनियोजन) अब छ सिर्जना गर्न सकिन्छ परिचित (एकल-नोड क्लस्टरहरूको सन्दर्भमा) आदेशहरू प्रयोग गर्दै kubeadm (init и join)। संक्षेपमा, यसको लागि:

• क्लस्टरले प्रयोग गरेको प्रमाणपत्रहरू गोप्यमा हस्तान्तरण गरिन्छ;
• K8s क्लस्टर भित्र etcd क्लस्टर प्रयोग गर्ने सम्भावनाको लागि (अर्थात् पहिले अवस्थित बाह्य निर्भरताबाट छुटकारा पाउन) etcd-अपरेटर;
• गल्ती-सहिष्णु कन्फिगरेसन प्रदान गर्ने बाह्य लोड ब्यालेन्सरका लागि सिफारिस गरिएका सेटिङहरू कागजातहरू (भविष्यमा यो निर्भरता हटाउने योजना छ, तर यस चरणमा होइन)।

Kubeadm को साथ सिर्जना गरिएको Kubernetes HA क्लस्टरको वास्तुकला

कार्यान्वयनको विवरणमा फेला पार्न सकिन्छ डिजाइन प्रस्ताव। यो सुविधा साँच्चै लामो-प्रतीक्षित थियो: अल्फा संस्करण K8s 1.9 मा फिर्ता अपेक्षित थियो, तर अहिले मात्र देखा पर्‍यो।

एपीआई

टोली apply र सामान्यतया बोल्दै घोषणात्मक वस्तु व्यवस्थापन पास बाट kubectl apiserver मा। विकासकर्ता आफैंले यसो भन्दै आफ्नो निर्णय संक्षिप्त व्याख्या गर्छन् kubectl apply - Kubernetes मा कन्फिगरेसनहरूसँग काम गर्ने आधारभूत भाग, तथापि, "यो बगहरूले भरिएको छ र समाधान गर्न गाह्रो छ," र त्यसैले यो कार्यक्षमतालाई सामान्यमा ल्याउन र नियन्त्रण विमानमा स्थानान्तरण गर्न आवश्यक छ। आज अवस्थित समस्याहरूको सरल र स्पष्ट उदाहरणहरू:

कार्यान्वयनको बारेमा विवरणहरू छन् केईपी। हालको तयारी अल्फा हो (बिटामा पदोन्नति अर्को Kubernetes रिलीजको लागि योजना गरिएको छ)।

अल्फा संस्करणमा उपलब्ध गराइयो मौका OpenAPI v3 योजना को लागी प्रयोग गर्दै CustomResources को लागि OpenAPI कागजातहरू सिर्जना र प्रकाशित गर्दै (CR) मान्य गर्न प्रयोग गरियो (सर्भर-साइड) K8s प्रयोगकर्ता-परिभाषित स्रोतहरू (CustomResourceDefinition, CRD)। CRD को लागि OpenAPI प्रकाशनले ग्राहकहरूलाई अनुमति दिन्छ (जस्तै। kubectl) तपाईंको छेउमा प्रमाणीकरण गर्नुहोस् (भित्र kubectl create и kubectl apply) र योजना अनुसार कागजात जारी गर्नुहोस् (kubectl explain)। विवरण - मा केईपी.

पूर्व-अवस्थित लगहरू अहिले खुल्दै छन् झण्डा संग O_APPEND (तर होइन O_TRUNC) केही परिस्थितिहरूमा लगहरू हराउनबाट बच्नको लागि र रोटेशनका लागि बाह्य उपयोगिताहरूसँग लगहरू काट्ने सुविधाको लागि।

साथै Kubernetes API को सन्दर्भमा, यो नोट गर्न सकिन्छ कि मा PodSandbox и PodSandboxStatus थपियो क्षेत्र runtime_handler बारे जानकारी रेकर्ड गर्न RuntimeClass पोडमा (यसको बारेमा पाठमा थप पढ्नुहोस् Kubernetes 1.12 रिलीज, जहाँ यो कक्षा अल्फा संस्करणको रूपमा देखा पर्यो), र Admission Webhooks मा कार्यान्वयन गरियो कुन संस्करणहरू निर्धारण गर्ने क्षमता AdmissionReview तिनीहरू समर्थन गर्छन्। अन्तमा, प्रवेश वेबहुक्स नियमहरू अब छन् सीमित हुन सक्छ नेमस्पेस र क्लस्टर फ्रेमवर्कहरूद्वारा तिनीहरूको प्रयोगको सीमा।

भण्डारण

PersistentLocalVolumes, जसको रिलीज पछि बिटा स्थिति थियो K8s 1.10, .ы स्थिर (GA): यो सुविधा गेट अब असक्षम छैन र Kubernetes 1.17 मा हटाइनेछ।

अवसर भनिन्छ वातावरण चर प्रयोग गरेर डाउनवर्ड API (उदाहरणका लागि, पोड नाम) माउन्ट गरिएका डाइरेक्टरीहरूको नामका लागि subPath, विकसित भएको थियो - नयाँ क्षेत्र को रूप मा subPathExpr, जुन अब चाहिएको डाइरेक्टरी नाम निर्धारण गर्न प्रयोग गरिन्छ। सुविधा सुरुमा Kubernetes 1.11 मा देखा पर्‍यो, तर 1.14 को लागि यो अल्फा संस्करण स्थितिमा रह्यो।

अघिल्लो Kubernetes रिलीज जस्तै, धेरै महत्त्वपूर्ण परिवर्तनहरू सक्रिय रूपमा विकास भइरहेको CSI (कन्टेनर भण्डारण इन्टरफेस) को लागी पेश गरिएको छ:

CSI

उपलब्ध भयो (अल्फा संस्करणको भागको रूपमा) समर्थन CSI भोल्युमहरूको लागि रिसाइजिङ। यसलाई प्रयोग गर्नको लागि तपाईले नामको सुविधा गेट सक्षम गर्न आवश्यक छ ExpandCSIVolumes, साथै एक विशिष्ट CSI ड्राइभरमा यस अपरेशनको लागि समर्थनको उपलब्धता।

अल्फा संस्करणमा CSI को लागी अर्को सुविधा - मौका पोड स्पेसिफिकेशन भित्र CSI भोल्युमहरूमा सीधा (अर्थात PV/PVC प्रयोग नगरी) सन्दर्भ गर्नुहोस्। यो विशेष रूपमा टाढाको डेटा भण्डारणको रूपमा CSI को प्रयोगमा प्रतिबन्ध हटाउँछ, तिनीहरूका लागि संसारको ढोका खोल्दै स्थानीय क्षणिक मात्रा। प्रयोगको लागि (दस्तावेजबाट उदाहरण) सक्षम हुनुपर्छ CSIInlineVolume सुविधा गेट।

त्यहाँ CSI सँग सम्बन्धित Kubernetes को "आन्तरिक" मा पनि प्रगति भएको छ, जुन अन्त प्रयोगकर्ताहरू (प्रणाली प्रशासकहरू) लाई त्यति देखिँदैन ... हाल, विकासकर्ताहरू प्रत्येक भण्डारण प्लगइनको दुई संस्करणहरूलाई समर्थन गर्न बाध्य छन्: एक - "मा पुरानो बाटो", K8s कोडबेस भित्र (in-tree), र दोस्रो - नयाँ CSI को भागको रूपमा (यसको बारेमा थप पढ्नुहोस्, उदाहरणका लागि, मा यहाँ)। यसले बुझ्न सकिने असुविधाहरू निम्त्याउँछ जुन CSI आफैं स्थिर हुँदा सम्बोधन गर्न आवश्यक छ। कारणले गर्दा आन्तरिक (इन-ट्री) प्लगइनहरूको API लाई बहिष्कार गर्न सम्भव छैन सान्दर्भिक Kubernetes नीति.

यो सबै अल्फा संस्करण पुग्यो तथ्यलाई नेतृत्व माइग्रेसन प्रक्रिया आन्तरिक प्लगइन कोड, CSI प्लगइनहरूमा इन-ट्रीको रूपमा लागू गरिएको छ, जसको लागि विकासकर्ताहरूको चिन्तालाई तिनीहरूको प्लगइनहरूको एउटा संस्करणलाई समर्थन गर्न कम हुनेछ, र पुराना APIहरूसँग अनुकूलता रहनेछ र तिनीहरूलाई सामान्य परिदृश्यमा अप्रचलित घोषित गर्न सकिन्छ। Kubernetes (1.15) को अर्को विमोचन सम्ममा सबै क्लाउड प्रदायक प्लगइनहरू माइग्रेट हुनेछन्, कार्यान्वयनले बिटा स्थिति प्राप्त गर्नेछ र K8s स्थापनाहरूमा पूर्वनिर्धारित रूपमा सक्रिय हुनेछ। विवरणहरूको लागि, हेर्नुहोस् डिजाइन प्रस्ताव। यो बसाइसराइको परिणाम पनि हो अस्वीकार विशिष्ट क्लाउड प्रदायकहरू (AWS, Azure, GCE, Cinder) द्वारा परिभाषित भोल्युम सीमाहरूबाट।

थप रूपमा, CSI (CSIBlockVolume) हस्तान्तरण बिटा संस्करणमा।

नोड्स/कुबेलेट

अल्फा संस्करण प्रस्तुत गरियो नयाँ अन्त्य बिन्दु Kubelet मा, को लागी डिजाइन गरिएको प्रमुख स्रोतहरूमा मेट्रिक्स फिर्ता गर्नुहोस्। सामान्यतया, यदि पहिले कुबेलेटले cAdvisor बाट कन्टेनर प्रयोगमा तथ्याङ्कहरू प्राप्त गर्यो भने, अब यो डेटा CRI (कन्टेनर रनटाइम इन्टरफेस) मार्फत कन्टेनर रनटाइम वातावरणबाट आउँछ, तर डकरको पुरानो संस्करणहरूसँग काम गर्ने अनुकूलता पनि सुरक्षित गरिएको छ। पहिले, कुबेलेटमा सङ्कलन गरिएका तथ्याङ्कहरू REST API मार्फत पठाइएका थिए, तर अब एउटा अन्तिम बिन्दुमा अवस्थित छ। /metrics/resource/v1alpha1। विकासकर्ताहरूको दीर्घकालीन रणनीति छ Kubelet द्वारा प्रदान गरिएको मेट्रिक्स को सेट को न्यूनतम गर्न को लागी छ। वैसे, यी मेट्रिक्स आफैं अहिले फोन गर्छन् "कोर मेट्रिक्स" होइन, तर "स्रोत मेट्रिक्स", र "प्रथम-कक्षा स्रोतहरू, जस्तै cpu, र मेमोरी" को रूपमा वर्णन गरिन्छ।

एक धेरै चाखलाग्दो nuance: प्रोमेथियस ढाँचा प्रयोग गर्ने विभिन्न मामलाहरु संग तुलना मा gRPC अन्त बिन्दु को स्पष्ट प्रदर्शन लाभ को बावजूद। (तलको एउटा बेन्चमार्कको नतिजा हेर्नुहोस्), समुदायमा यस निगरानी प्रणालीको स्पष्ट नेतृत्वको कारण लेखकहरूले प्रोमेथियसको पाठ ढाँचालाई प्राथमिकता दिए।

"gRPC प्रमुख अनुगमन पाइपलाइनहरूसँग उपयुक्त छैन। Endpoint Metrics Server मा मेट्रिक्स डेलिभर गर्न वा यससँग प्रत्यक्ष रूपमा एकीकृत हुने कम्पोनेन्टहरू निगरानी गर्नका लागि मात्र उपयोगी हुनेछ। मेट्रिक्स सर्भरमा क्यासिङ प्रयोग गर्दा प्रोमेथियस पाठ ढाँचा प्रदर्शन पर्याप्त राम्रो समुदायमा प्रोमिथियसलाई व्यापक रूपमा ग्रहण गरिएकोले हामीलाई gRPC भन्दा प्रोमिथियसलाई प्राथमिकता दिनको लागि। एकपटक OpenMetrics ढाँचा थप स्थिर भएपछि, हामी प्रोटो-आधारित ढाँचाको साथ gRPC कार्यसम्पादनमा पुग्न सक्षम हुनेछौं।"

मेट्रिक्सका लागि नयाँ Kubelet अन्त्य बिन्दुमा gRPC र Prometheus ढाँचाहरू प्रयोग गर्ने तुलनात्मक प्रदर्शन परीक्षणहरू मध्ये एक। थप ग्राफ र अन्य विवरणहरू फेला पार्न सकिन्छ केईपी.

अन्य परिवर्तनहरू बीच:

• Kubelet अब (एक पटक) रोक्न खोज्दै अपरेसनहरू पुन: सुरु र मेटाउनु अघि अज्ञात अवस्थामा कन्टेनरहरू।
• प्रयोग गर्दै PodPresets अब init कन्टेनरमा थपियो नियमित कन्टेनरको लागि समान जानकारी।
• कुबेलेट प्रयोग गर्न थाले usageNanoCores CRI तथ्याङ्क प्रदायकबाट, र Windows मा नोडहरू र कन्टेनरहरूको लागि थपियो नेटवर्क तथ्याङ्क।
• अपरेटिङ सिस्टम र आर्किटेक्चर जानकारी अब लेबलहरूमा रेकर्ड गरिएको छ kubernetes.io/os и kubernetes.io/arch नोड वस्तुहरू (बिटाबाट GA मा स्थानान्तरण गरिएको)।
• पोडमा कन्टेनरहरूको लागि विशेष प्रणाली प्रयोगकर्ता समूह निर्दिष्ट गर्ने क्षमता (RunAsGroup, मा देखा पर्‍यो K8s 1.11) उन्नत बिटा अघि (पूर्वनिर्धारित रूपमा सक्षम)।
• du र cAdvisor मा प्रयोग गरिएको फेला पार्नुहोस्, प्रतिस्थापित गो कार्यान्वयनमा।

CLI

cli-runtime र kubectl मा थपे -के साथ एकीकरणको लागि झण्डा अनुकूलन गर्नुहोस् (वैसे, यसको विकास अब छुट्टै भण्डारमा गरिन्छ), अर्थात्। विशेष अनुकूलन डाइरेक्टरीहरूबाट थप YAML फाइलहरू प्रशोधन गर्न (तिनीहरू प्रयोग गर्ने विवरणहरूको लागि, हेर्नुहोस् केईपी):

सरल फाइल प्रयोगको उदाहरण अनुकूलन (kustomize को एक अधिक जटिल आवेदन भित्र सम्भव छ ओभरले)

यसको अतिरिक्त:

• थपियो नयाँ टोली kubectl create cronjob, जसको नाम आफै बोल्छ।
• В kubectl logs अब तपाईं सक्नुहुन्छ मिलाउनु झण्डाहरू -f (--follow स्ट्रिमिङ लगहरूका लागि) र -l (--selector लेबल क्वेरीको लागि)।
• kubectl सिकायो वाइल्ड कार्ड द्वारा चयन गरिएका फाइलहरू प्रतिलिपि गर्नुहोस्।
• टोलीलाई kubectl wait थपे झण्डा --all निर्दिष्ट स्रोत प्रकारको नाम स्थानमा सबै स्रोतहरू चयन गर्न।

अन्य

निम्न क्षमताहरूले स्थिर (GA) स्थिति प्राप्त गरेका छन्:

• ReadinessGate, पोडको तत्परतालाई ध्यानमा राखी थप सर्तहरू परिभाषित गर्न पोड स्पेसिफिकेशनमा प्रयोग गरिन्छ;
• ठूला पृष्ठहरूको लागि समर्थन (फिचर गेट भनिन्छ HugePages);
• CustomPodDNS;
• PriorityClass API पोड प्राथमिकता र पूर्वाग्रह.

Kubernetes 1.14 मा प्रस्तुत गरिएका अन्य परिवर्तनहरू:

• पूर्वनिर्धारित RBAC नीतिले अब API पहुँच अनुमति दिँदैन discovery и access-review प्रमाणीकरण बिना प्रयोगकर्ताहरू (अप्रमाणित).
• आधिकारिक CoreDNS समर्थन सुनिश्चित गरियो लिनक्स मात्र, त्यसैले क्लस्टरमा यसलाई (CoreDNS) डिप्लोय गर्न kubeadm प्रयोग गर्दा, नोडहरू लिनक्समा मात्र चल्नु पर्छ (नोडसेलेक्टरहरू यस सीमाको लागि प्रयोग गरिन्छ)।
• पूर्वनिर्धारित CoreDNS कन्फिगरेसन अहिले छ उपयोगहरु अगाडि प्लगइन प्रोक्सीको सट्टा। साथै, CoreDNS मा थपियो ReadinessProbe, जसले उपयुक्त (सेवाको लागि तयार छैन) पोडहरूमा लोड सन्तुलन रोक्छ।
• kubeadm मा, चरणहरूमा init वा upload-certs, सम्भव भयो नयाँ नियन्त्रण-प्लेनलाई kubeadm-certs गोप्यमा जडान गर्न आवश्यक प्रमाणपत्रहरू लोड गर्नुहोस् (झण्डा प्रयोग गर्नुहोस् --experimental-upload-certs).
• विन्डोज स्थापनाहरूको लागि अल्फा संस्करण देखा पर्‍यो समर्थन gMSA (समूह व्यवस्थित सेवा खाता) - सक्रिय निर्देशिकामा विशेष खाताहरू जुन कन्टेनरहरूद्वारा पनि प्रयोग गर्न सकिन्छ।
• G.C.E को लागि सक्रिय etcd र kube-apiserver बीच mTLS एन्क्रिप्शन।
• प्रयोग गरिएको/आश्रित सफ्टवेयरमा अद्यावधिकहरू: Go 1.12.1, CSI 1.1, CoreDNS 1.3.1, kubeadm मा Docker 18.09 समर्थन, र न्यूनतम समर्थित Docker API संस्करण अब 1.26 छ।

PS

हाम्रो ब्लगमा पनि पढ्नुहोस्:

• «Kubernetes 1.13: मुख्य आविष्कारहरूको सिंहावलोकन»;
• «Kubernetes 1.12: मुख्य आविष्कारहरूको सिंहावलोकन»;
• «Kubernetes 1.11: मुख्य आविष्कारहरूको सिंहावलोकन»;
• «Kubernetes 1.10: मुख्य आविष्कारहरूको सिंहावलोकन"।

स्रोत: www.habr.com