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

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

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

नोडहरू

K8s क्लस्टर नोड्स (कुबेलेट) को छेउमा उल्लेखनीय आविष्कारहरूको एक साँच्चै ठूलो संख्या (अल्फा संस्करण स्थितिमा) प्रस्तुत गरिएको छ।

पहिलो, तथाकथित «क्षणिक कन्टेनरहरू» (अस्थायी कन्टेनर), पोडहरूमा डिबगिङ प्रक्रियाहरू सरल बनाउन डिजाइन गरिएको। नयाँ मेकानिजमले तपाईंलाई विशेष कन्टेनरहरू सुरू गर्न अनुमति दिन्छ जुन अवस्थित पोडहरूको नेमस्पेसमा सुरु हुन्छ र छोटो समयको लागि बाँच्दछ। तिनीहरूको उद्देश्य कुनै पनि समस्या र डिबग समाधान गर्न अन्य पोडहरू र कन्टेनरहरूसँग अन्तरक्रिया गर्नु हो। यो सुविधाको लागि नयाँ आदेश लागू गरिएको छ kubectl debug, सार मा समान kubectl exec: कन्टेनरमा प्रक्रिया चलाउनुको सट्टा (जस्तै exec) यसले पोडमा कन्टेनर सुरू गर्छ। उदाहरणका लागि, यो आदेशले नयाँ कन्टेनरलाई पोडमा जडान गर्नेछ:

kubectl debug -c debug-shell --image=debian target-pod -- bash

अल्पकालिक कन्टेनरहरू (र तिनीहरूको प्रयोगका उदाहरणहरू) बारे विवरणहरू फेला पार्न सकिन्छ अनुरूप KEP। हालको कार्यान्वयन (K8s 1.16 मा) एक अल्फा संस्करण हो, र यसको बिटा संस्करणमा स्थानान्तरणको लागि मापदण्डहरू मध्ये "[Kubernetes] को कम्तिमा 2 रिलीजहरूको लागि Ephemeral Containers API को परीक्षण गर्दैछ।"

NB: यसको सार र यसको नाममा पनि, सुविधा पहिले नै अवस्थित प्लगइनसँग मिल्दोजुल्दो छ kubectl-debugजसको बारेमा हामी पहिले नै लेखेको छ। यो आशा गरिएको छ कि अल्पकालिक कन्टेनरको आगमन संग, एक अलग बाह्य प्लगइन को विकास बन्द हुनेछ।

अर्को नवीनता - PodOverhead - प्रदान गर्न डिजाइन गरिएको पोडहरूको लागि उपरि लागत गणना गर्न संयन्त्र, जुन प्रयोग गरिएको रनटाइमको आधारमा धेरै फरक हुन सक्छ। उदाहरणका रूपमा, लेखकहरू यो KEP काटा कन्टेनरहरूमा परिणाम, जसमा अतिथि कर्नेल, काटा एजेन्ट, इनिट प्रणाली, आदि चलाउन आवश्यक छ। जब ओभरहेड यति ठूलो हुन्छ, यसलाई बेवास्ता गर्न सकिँदैन, जसको मतलब त्यहाँ थप कोटा, योजना, आदिको लागि खातामा लिने तरिका हुन आवश्यक छ। मा कार्यान्वयन गर्न PodSpec क्षेत्र थपियो Overhead *ResourceList (मा डेटासँग तुलना गर्दछ RuntimeClass, यदि एक प्रयोग गरिएको छ)।

अर्को उल्लेखनीय नवीनता छ नोड टोपोलोजी प्रबन्धक (नोड टोपोलोजी प्रबन्धक), Kubernetes मा विभिन्न कम्पोनेन्टहरूका लागि हार्डवेयर स्रोतहरूको आवंटनलाई फाइन-ट्यून गर्ने दृष्टिकोणलाई एकताबद्ध गर्न डिजाइन गरिएको। यो पहल उच्च प्रदर्शन समानान्तर कम्प्युटिङ र सञ्चालनको कार्यान्वयनमा ढिलाइ कम गर्नका लागि विभिन्न आधुनिक प्रणालीहरू (दूरसंचार, मेसिन लर्निङ, वित्तीय सेवाहरू, इत्यादिको क्षेत्रबाट) को बढ्दो आवश्यकताबाट संचालित छ, जसको लागि तिनीहरू उन्नत CPU र प्रयोग गर्छन्। हार्डवेयर त्वरण क्षमताहरू। Kubernetes मा त्यस्ता अप्टिमाइजेसनहरू अहिलेसम्म भिन्न कम्पोनेन्टहरू (CPU प्रबन्धक, यन्त्र प्रबन्धक, CNI) को लागि धन्यवाद प्राप्त गरिएको छ, र अब तिनीहरूलाई एकल आन्तरिक इन्टरफेस थपिनेछ जसले दृष्टिकोणलाई एकीकृत गर्दछ र नयाँ समान - तथाकथित टोपोलोजी-को जडानलाई सरल बनाउँछ। सचेत - कुबेलेट साइडमा कम्पोनेन्टहरू। विवरण - मा अनुरूप KEP.

टोपोलोजी प्रबन्धक कम्पोनेन्ट रेखाचित्र

अर्को विशेषता - तिनीहरू चलिरहेको बेला कन्टेनरहरू जाँच गर्दै (स्टार्टअप जाँच)। तपाईलाई थाहा छ, कन्टेनरहरूको लागि जुन सुरु हुन लामो समय लाग्छ, अप-टु-डेट स्थिति प्राप्त गर्न गाह्रो छ: तिनीहरू कि त वास्तवमा काम सुरु गर्नु अघि "मारिएका" हुन्छन्, वा तिनीहरू लामो समयको लागि गतिरोधमा समाप्त हुन्छन्। नयाँ चेक (फिचर गेट मार्फत सक्षम भनिन्छ StartupProbeEnabled) रद्द गर्दछ - वा बरु, स्थगित गर्दछ - कुनै पनि अन्य जाँचको प्रभाव पोड चल्ने समाप्त नभएसम्म। यस कारणले गर्दा, सुविधालाई मूल रूपमा बोलाइएको थियो pod-Startup liveness-probe होल्डअफ। सुरु हुन लामो समय लाग्ने पोडहरूका लागि, तपाईंले अपेक्षाकृत छोटो समय अन्तरालहरूमा राज्यलाई मतदान गर्न सक्नुहुन्छ।

थप रूपमा, RuntimeClass को लागि सुधार तुरुन्तै बीटा स्थितिमा उपलब्ध छ, "विषम क्लस्टरहरू" को लागि समर्थन थप्दै। सी RuntimeClass अनुसूची अब प्रत्येक नोडको लागि प्रत्येक RuntimeClass को लागि समर्थन हुनु आवश्यक छैन: पोडहरूको लागि तपाईंले क्लस्टर टोपोलोजीको बारेमा सोच नगरी RuntimeClass चयन गर्न सक्नुहुन्छ। पहिले, यो प्राप्त गर्न - ताकि पोडहरू नोडहरूमा उनीहरूलाई चाहिने सबै कुराको समर्थनको साथ समाप्त हुन्छन् - यो नोडसेलेक्टर र सहनशीलताहरूलाई उपयुक्त नियमहरू तोक्न आवश्यक थियो। IN केईपी यसले प्रयोगका उदाहरणहरू र अवश्य पनि कार्यान्वयन विवरणहरूको बारेमा कुरा गर्छ।

सञ्जाल

Kubernetes 1.16 मा पहिलो पटक (अल्फा संस्करणमा) देखा परेका दुई महत्त्वपूर्ण नेटवर्किङ सुविधाहरू हुन्:

• समर्थन दोहोरो नेटवर्क स्ट्याक - IPv4/IPv6 - र पोडहरू, नोडहरू, सेवाहरूको स्तरमा यसको सम्बन्धित "बुझाइ"। यसमा IPv4-to-IPv4 र IPv6-to-IPv6 पोडहरू बीचको अन्तरसञ्चालन, पोडहरू देखि बाह्य सेवाहरू, सन्दर्भ कार्यान्वयनहरू (ब्रिज CNI, PTP CNI र होस्ट-स्थानीय IPAM प्लगइनहरू भित्र), साथै कुबर्नेट्स क्लस्टरहरू चलिरहेको रिभर्स कम्प्याटिबल समावेश गर्दछ। IPv4 वा IPv6 मात्र। कार्यान्वयन विवरणहरू छन् केईपी.

  पोडहरूको सूचीमा दुई प्रकारका IP ठेगानाहरू (IPv4 र IPv6) प्रदर्शन गर्ने एउटा उदाहरण:

  kube-master# kubectl get pods -o wide
  NAME               READY     STATUS    RESTARTS   AGE       IP                          NODE
  nginx-controller   1/1       Running   0          20m       fd00:db8:1::2,192.168.1.3   kube-minion-1
  kube-master#

• Endpoint को लागि नयाँ API - EndpointSlice API। यसले कन्ट्रोल-प्लेन (apisserver, etcd, endpoints-controller, kube-proxy) मा विभिन्न कम्पोनेन्टहरूलाई असर गर्ने अवस्थित Endpoint API को प्रदर्शन/स्केलेबिलिटी समस्याहरू समाधान गर्छ। नयाँ API डिस्कवरी एपीआई समूहमा थपिनेछ र हजारौं नोडहरू समावेश भएको क्लस्टरमा प्रत्येक सेवामा दशौं हजार ब्याकइन्ड एन्डपोइन्टहरू सेवा गर्न सक्षम हुनेछ। यो गर्नका लागि, प्रत्येक सेवा N वस्तुहरूमा म्याप गरिएको छ EndpointSlice, जसको प्रत्येकमा पूर्वनिर्धारित रूपमा 100 भन्दा बढी अन्त्य बिन्दुहरू छैनन् (मान कन्फिगर योग्य छ)। EndpointSlice API ले यसको भविष्यको विकासको लागि अवसरहरू पनि प्रदान गर्नेछ: प्रत्येक पोडको लागि बहु ​​आईपी ठेगानाहरूको लागि समर्थन, अन्तिम बिन्दुहरूको लागि नयाँ राज्यहरू (मात्र होइन Ready и NotReady), अन्तिम बिन्दुहरूको लागि गतिशील सबसेटिङ।

पछिल्लो विमोचनमा प्रस्तुत गरिएको बीटा संस्करणमा पुगेको छ फाइनलाइजर, नाम दिइएको service.kubernetes.io/load-balancer-cleanup र प्रकार संग प्रत्येक सेवा संलग्न LoadBalancer। यस्तो सेवा मेटाउने समयमा, यसले सबै सान्दर्भिक ब्यालेन्सर स्रोतहरूको "सफाई" पूरा नभएसम्म स्रोतको वास्तविक मेटाउन रोक्छ।

एपीआई मेसिनरी

वास्तविक "स्थिरीकरण माइलस्टोन" Kubernetes API सर्भरको क्षेत्रमा छ र यसको साथ अन्तरक्रिया। यो धेरै हदसम्म धन्यवाद भयो स्थिर स्थितिमा स्थानान्तरण गर्दै जसलाई विशेष परिचय आवश्यक छैन CustomResourceDefinitions (CRD), जसमा Kubernetes 1.7 (र यो जुन 2017 हो!) को टाढाका दिनहरू देखि बिटा स्थिति भएको छ। समान स्थिरता सम्बन्धित सुविधाहरूमा आयो:

• "उप-स्रोतहरू" संग /status и /scale CustomResources को लागि;
• रूपान्तरण बाह्य वेबहुकमा आधारित CRD को लागि संस्करणहरू;
• भर्खरै प्रस्तुत (K8s 1.15 मा) पूर्वनिर्धारित मानहरू (डिफल्ट) र स्वचालित क्षेत्र हटाउने (छाँट्ने) CustomResources को लागि;
• मौका सर्भर साइडमा CRD स्रोतहरू मान्य गर्न प्रयोग गरिने OpenAPI कागजातहरू सिर्जना गर्न र प्रकाशित गर्न OpenAPI v3 स्कीमा प्रयोग गर्दै।

अर्को संयन्त्र जुन लामो समयदेखि Kubernetes प्रशासकहरूलाई परिचित भएको छ: प्रवेश वेबहुक - पनि लामो समय (K8s 1.9 देखि) को लागि बीटा स्थितिमा रह्यो र अब स्थिर घोषित गरिएको छ।

दुई अन्य सुविधाहरू बिटामा पुगेका छन्: सर्भर-साइड लागू и बुकमार्कहरू हेर्नुहोस्.

र अल्फा संस्करण मा मात्र महत्वपूर्ण नवीनता थियो अस्वीकार देखि SelfLink - एक विशेष URI निर्दिष्ट वस्तु को प्रतिनिधित्व र को भाग हुनु ObjectMeta и ListMeta (अर्थात Kubernetes मा कुनै पनि वस्तु को भाग)। किन छोड्दैछन् ? सरल तरिकामा प्रेरणा आवाज यस क्षेत्रको लागि वास्तविक (अत्यधिक) कारणहरूको अनुपस्थिति अझै अवस्थित छ। अधिक औपचारिक कारणहरू प्रदर्शन अनुकूलन गर्न (अनावश्यक क्षेत्र हटाएर) र जेनेरिक-एपिसर्भरको कामलाई सरल बनाउनका लागि हो, जुन यस्तो क्षेत्रलाई विशेष तरिकामा ह्यान्डल गर्न बाध्य पारिएको छ (यो मात्र क्षेत्र हो जुन वस्तुको ठीक अगाडि सेट गरिएको छ। क्रमबद्ध छ)। साँचो अप्रचलितता (बीटा भित्र) SelfLink Kubernetes संस्करण 1.20, र अन्तिम - 1.21 द्वारा हुनेछ।

डाटा भण्डारण

भण्डारण क्षेत्रमा मुख्य काम, अघिल्लो विज्ञप्ति जस्तै, क्षेत्रमा अवलोकन गरिएको छ CSI समर्थन। यहाँ मुख्य परिवर्तनहरू थिए:

• पहिलो पटक (अल्फा संस्करणमा) देखा पर्‍यो Windows कार्यकर्ता नोडहरूको लागि CSI प्लगइन समर्थन: भण्डारणको साथ काम गर्ने हालको तरिकाले कुबर्नेट्स कोरमा इन-ट्री प्लगइनहरू र माइक्रोसफ्टबाट Powershell मा आधारित FlexVolume प्लगइनहरू पनि प्रतिस्थापन गर्नेछ;

  
  Windows को लागि Kubernetes मा CSI प्लगइनहरू लागू गर्ने योजना

• मौका CSI भोल्युमहरू रिसाइज गर्दै, K8s 1.12 मा फिर्ता पेश गरिएको, बिटा संस्करणमा बढेको छ;
• एक समान "प्रमोशन" (अल्फा देखि बीटा सम्म) स्थानीय अल्पकालिक भोल्युमहरू सिर्जना गर्न CSI प्रयोग गर्ने क्षमता द्वारा प्राप्त गरिएको थियो (CSI इनलाइन भोल्युम समर्थन).

Kubernetes को अघिल्लो संस्करण मा प्रस्तुत भोल्युम क्लोनिङ प्रकार्य (विद्यमान PVC को रूपमा प्रयोग गर्दै DataSource नयाँ PVC सिर्जना गर्न) ले अब बिटा स्थिति प्राप्त गरेको छ।

अनुसूचीकर्ता

तालिकामा दुई उल्लेखनीय परिवर्तनहरू (दुबै अल्फामा):

• EvenPodsSpreading - अवसर लोडको "उचित वितरण" को लागि तार्किक अनुप्रयोग एकाइहरूको सट्टा पोडहरू प्रयोग गर्नुहोस् (जस्तै डिप्लोइमेन्ट र रेप्लिकासेट) र यो वितरण समायोजन (कडा आवश्यकता वा नरम अवस्थाको रूपमा, अर्थात् प्राथमिकता)। सुविधाले योजनाबद्ध पोडहरूको अवस्थित वितरण क्षमताहरू विस्तार गर्नेछ, हाल विकल्पहरूद्वारा सीमित छ PodAffinity и PodAntiAffinity, यस मामिलामा प्रशासकहरूलाई राम्रो नियन्त्रण दिँदै, जसको अर्थ राम्रो उच्च उपलब्धता र अनुकूलित स्रोत खपत। विवरण - मा केईपी.
• प्रयोग गर्नुहोस् बेस्टफिट नीति в RequestedToCapacityRatio प्राथमिकता प्रकार्य पोड योजना को समयमा, जसले अनुमति दिनेछ प्रयोग गर्नुहोस् बिन प्याकिङ ("कन्टेनरहरूमा प्याकिङ") दुवै आधारभूत स्रोतहरू (प्रोसेसर, मेमोरी) र विस्तारितहरू (जस्तै GPU) को लागि। थप विवरणहरूको लागि, हेर्नुहोस् केईपी.

  
  शेड्युलिंग पोडहरू: उत्तम फिट नीति प्रयोग गर्नु अघि (डिफल्ट शेड्यूलर मार्फत) र यसको प्रयोगको साथ (शेड्युलर विस्तारक मार्फत)

यसबाहेक, प्रस्तुत मुख्य Kubernetes विकास रूख (रुख बाहिर) बाहिर आफ्नो आफ्नै अनुसूचक प्लगइनहरू सिर्जना गर्ने क्षमता।

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

Kubernetes 1.16 रिलीज मा पनि यो नोट गर्न सकिन्छ लागि पहल ल्याउने उपलब्ध मेट्रिक्स पूर्ण क्रममा, वा अधिक स्पष्ट रूपमा, अनुसार आधिकारिक नियमहरू K8s इन्स्ट्रुमेन्टेसनमा। तिनीहरू धेरै हदसम्म सम्बन्धितमा भर पर्छन् प्रोमेथियस दस्तावेज। विभिन्न कारणहरूका लागि विसंगतिहरू देखा पर्‍यो (उदाहरणका लागि, केही मेट्रिकहरू हालको निर्देशनहरू देखा पर्नु अघि मात्र सिर्जना गरिएको थियो), र विकासकर्ताहरूले निर्णय गरे कि यो सबै कुरालाई एक मानकमा ल्याउने समय हो, "बाँकी प्रोमेथियस इकोसिस्टमको अनुरूप।" यस पहलको हालको कार्यान्वयन अल्फा स्थितिमा छ, जसलाई क्रमशः कुबर्नेट्सको पछिल्ला संस्करणहरूमा बिटा (१.१७) र स्थिर (१.१८) मा प्रवर्द्धन गरिनेछ।

साथै, निम्न परिवर्तनहरू नोट गर्न सकिन्छ:

• विन्डोज समर्थन विकास с उपस्थिति यो OS (अल्फा संस्करण) को लागि Kubeadm उपयोगिताहरू, अवसर RunAsUserName विन्डोज कन्टेनरहरूको लागि (अल्फा संस्करण), सुधार समूह व्यवस्थित सेवा खाता (gMSA) बिटा संस्करण सम्म समर्थन, समर्थन vSphere भोल्युमहरूको लागि माउन्ट/संलग्न गर्नुहोस्।
• रिसाइकल API प्रतिक्रियाहरूमा डाटा सङ्कुचन तंत्र। पहिले, यी उद्देश्यहरूका लागि HTTP फिल्टर प्रयोग गरिएको थियो, जसले यसलाई पूर्वनिर्धारित रूपमा सक्षम हुनबाट रोक्न धेरै प्रतिबन्धहरू लगाएको थियो। "पारदर्शी अनुरोध सङ्कुचन" अब काम गर्दछ: ग्राहकहरू पठाउँदै Accept-Encoding: gzip हेडरमा, तिनीहरूले GZIP-संकुचित प्रतिक्रिया प्राप्त गर्छन् यदि यसको आकार 128 KB नाघेको छ। गो क्लाइन्टहरूले स्वचालित रूपमा कम्प्रेसन समर्थन गर्दछ (आवश्यक हेडर पठाउँदै), त्यसैले उनीहरूले तुरुन्तै ट्राफिकमा कमी देख्नेछन्। (अन्य भाषाहरूको लागि थोरै परिमार्जन आवश्यक हुन सक्छ।)
• सम्भव भयो बाह्य मेट्रिक्समा आधारित HPA बाट/शून्य पोडहरूमा स्केल गर्दै। यदि तपाइँ वस्तुहरू/बाह्य मेट्रिक्समा आधारित मापन गर्नुहुन्छ भने, जब कार्यभारहरू निष्क्रिय हुन्छन्, तपाइँ स्रोतहरू बचत गर्न स्वचालित रूपमा 0 प्रतिकृतिहरूमा मापन गर्न सक्नुहुन्छ। यो सुविधा विशेष गरी कामदारहरूले GPU स्रोतहरू अनुरोध गर्ने मामिलाहरूका लागि उपयोगी हुनुपर्दछ, र विभिन्न प्रकारका निष्क्रिय कामदारहरूको संख्या उपलब्ध GPU हरूको संख्या भन्दा बढी छ।
• नयाँ ग्राहक - k8s.io/client-go/metadata.Client - वस्तुहरूमा "सामान्यीकृत" पहुँचको लागि। यो सजिलै मेटाडेटा पुन: प्राप्त गर्न डिजाइन गरिएको हो (अर्थात् उपखण्ड metadata) क्लस्टर स्रोतहरूबाट र तिनीहरूसँग फोहोर सङ्कलन र कोटा सञ्चालनहरू प्रदर्शन गर्नुहोस्।
• Kubernetes निर्माण गर्नुहोस् अब तपाईं सक्नुहुन्छ बिना लिगेसी ("बिल्ट-इन" इन-ट्री) क्लाउड प्रदायकहरू (अल्फा संस्करण)।
• kubeadm उपयोगितामा थपे प्रयोगात्मक (अल्फा संस्करण) सञ्चालनको समयमा अनुकूलन प्याचहरू लागू गर्ने क्षमता init, join и upgrade। झण्डा कसरी प्रयोग गर्ने बारे थप जान्नुहोस् --experimental-kustomize, मा हेर्नुहोस् केईपी.
• Apiserver को लागि नयाँ अन्त बिन्दु - readyz, - तपाईंलाई यसको तयारी बारे जानकारी निर्यात गर्न अनुमति दिन्छ। API सर्भरमा पनि झण्डा छ --maximum-startup-sequence-duration, तपाईंलाई यसको पुन: सुरुहरू विनियमित गर्न अनुमति दिँदै।
• दुई Azure को लागि सुविधाहरू स्थिर घोषित: समर्थन उपलब्धता क्षेत्रहरू (उपलब्धता क्षेत्रहरू) र क्रस संसाधन समूह (आरजी)। थप रूपमा, Azure थपिएको छ:
  • प्रमाणीकरण समर्थन AAD र ADFS;
  • एनोटेसन service.beta.kubernetes.io/azure-pip-name लोड ब्यालेन्सरको सार्वजनिक आईपी निर्दिष्ट गर्न;
  • मौका सेटिङ्हरू LoadBalancerName и LoadBalancerResourceGroup.
• AWS अहिले छ समर्थन विन्डोजमा EBS को लागि र अनुकूलित EC2 API कलहरू DescribeInstances.
• कुबेडम अब स्वतन्त्र छ माइग्रेट गर्छ CoreDNS संस्करण अपग्रेड गर्दा CoreDNS कन्फिगरेसन।
• बाइनरीहरू आदि सम्बन्धित डकर छविमा बनेको विश्व-कार्यान्वयनयोग्य, जसले तपाईंलाई रूट अधिकारहरूको आवश्यकता बिना यो छवि चलाउन अनुमति दिन्छ। साथै, आदि माइग्रेसन छवि रोकियो etcd2 संस्करण समर्थन।
• В क्लस्टर अटोस्केलर १.१६.० आधार छविको रूपमा डिस्ट्रोलेस प्रयोग गर्न स्विच गरियो, सुधारिएको प्रदर्शन, नयाँ क्लाउड प्रदायकहरू थपियो (डिजिटल ओशन, म्याग्नम, प्याकेट)।
• प्रयोग गरिएको/निर्भर सफ्टवेयरमा अद्यावधिकहरू: Go 1.12.9, etcd 3.3.15, CoreDNS 1.6.2।

PS

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

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

स्रोत: www.habr.com