Kubernetes 1.16: اہم اختراعات کا جائزہ

آج بدھ، جگہ لے جائے گا Kubernetes کی اگلی ریلیز - 1.16۔ اس روایت کے مطابق جو ہمارے بلاگ کے لیے تیار ہوئی ہے، یہ دسویں سالگرہ کا موقع ہے جب ہم نئے ورژن میں سب سے اہم تبدیلیوں کے بارے میں بات کر رہے ہیں۔

اس مواد کو تیار کرنے کے لیے استعمال ہونے والی معلومات سے لی گئی ہے۔ Kubernetes میں اضافہ ٹریکنگ ٹیبلز, چینج 1.16 اور متعلقہ مسائل، پل کی درخواستیں، اور Kubernetes Enhancement Proposals (KEP)۔ تو چلو چلتے ہیں!..

نوڈس

واقعی ایک بڑی تعداد میں قابل ذکر اختراعات (الفا ورژن کی حیثیت میں) K8s کلسٹر نوڈس (Kubelet) کے پہلو میں پیش کی گئی ہیں۔

سب سے پہلے، نام نہاد «عارضی کنٹینرز» (فوقتل کنٹینرز), pods میں ڈیبگنگ کے عمل کو آسان بنانے کے لیے ڈیزائن کیا گیا ہے۔. نیا طریقہ کار آپ کو خصوصی کنٹینرز لانچ کرنے کی اجازت دیتا ہے جو موجودہ پوڈز کے نام کی جگہ سے شروع ہوتے ہیں اور مختصر وقت کے لیے رہتے ہیں۔ ان کا مقصد کسی بھی مسائل اور ڈیبگ کو حل کرنے کے لیے دوسرے پوڈز اور کنٹینرز کے ساتھ بات چیت کرنا ہے۔ اس فیچر کے لیے ایک نئی کمانڈ نافذ کی گئی ہے۔ 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 Holdoff. پھلیوں کے لیے جن کو شروع ہونے میں کافی وقت لگتا ہے، آپ نسبتاً کم وقت کے وقفوں میں ریاست میں رائے شماری کر سکتے ہیں۔

اس کے علاوہ، RuntimeClass کے لیے ایک بہتری بیٹا اسٹیٹس میں فوری طور پر دستیاب ہے، جس میں "متضاد کلسٹرز" کے لیے تعاون شامل ہے۔ سی رن ٹائم کلاس شیڈولنگ اب ہر نوڈ کے لیے ہر RuntimeClass کے لیے سپورٹ ہونا بالکل ضروری نہیں ہے: pods کے لیے آپ کلسٹر ٹوپولوجی کے بارے میں سوچے بغیر RuntimeClass کو منتخب کر سکتے ہیں۔ اس سے پہلے، اس کو حاصل کرنے کے لیے - تاکہ پوڈز نوڈس پر ختم ہو جائیں اور ان کی ہر ضرورت کے لیے سپورٹ ہو - نوڈ سلیکٹر اور رواداری کو مناسب اصول تفویض کرنا ضروری تھا۔ میں CAP یہ استعمال کی مثالوں اور یقیناً عمل درآمد کی تفصیلات کے بارے میں بات کرتا ہے۔

Сеть

نیٹ ورکنگ کی دو اہم خصوصیات جو پہلی بار (الفا ورژن میں) کبرنیٹس 1.16 میں نمودار ہوئیں وہ ہیں:

• معاونت دوہری نیٹ ورک اسٹیک - IPv4/IPv6 - اور پوڈز، نوڈس، خدمات کی سطح پر اس کی متعلقہ "تفہیم"۔ اس میں پوڈز کے درمیان IPv4-to-IPv4 اور IPv6-to-IPv6 انٹرآپریبلٹی، پوڈز سے لے کر بیرونی خدمات تک، حوالہ جات کے نفاذ (برج CNI، PTP CNI اور میزبان-لوکل IPAM پلگ ان کے اندر)، نیز ریورس کمپیٹیبل Kubernetes کلسٹرز کے ساتھ چل رہے ہیں۔ صرف IPv4 یا IPv6۔ نفاذ کی تفصیلات درج ہیں۔ CAP.

  پوڈز کی فہرست میں دو قسموں (IPv4 اور IPv6) کے IP پتے ظاہر کرنے کی ایک مثال:

  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#

• اینڈ پوائنٹ کے لیے نیا API - EndpointSlice API. یہ موجودہ اینڈپوائنٹ API کی کارکردگی/اسکیل ایبلٹی مسائل کو حل کرتا ہے جو کنٹرول پلین (apiserver، etcd، endpoints-controller، kube-proxy) میں مختلف اجزاء کو متاثر کرتے ہیں۔ نئے API کو Discovery API گروپ میں شامل کیا جائے گا اور یہ ہزاروں نوڈس پر مشتمل کلسٹر میں ہر سروس پر دسیوں ہزار بیک اینڈ اینڈ پوائنٹس فراہم کر سکے گا۔ ایسا کرنے کے لیے، ہر سروس کو N آبجیکٹ سے میپ کیا جاتا ہے۔ EndpointSlice، جن میں سے ہر ایک میں ڈیفالٹ کے طور پر 100 سے زیادہ اختتامی پوائنٹس نہیں ہوتے ہیں (قدر قابل ترتیب ہے)۔ EndpointSlice API اپنی مستقبل کی ترقی کے مواقع بھی فراہم کرے گا: ہر پوڈ کے لیے متعدد IP پتوں کے لیے سپورٹ، اینڈ پوائنٹ کے لیے نئی ریاستیں (نہ صرف Ready и NotReady)، اختتامی پوائنٹس کے لیے متحرک ذیلی ترتیب۔

آخری ریلیز میں پیش کردہ ایک بیٹا ورژن تک پہنچ گیا ہے۔ فائنل کرنے والا، نام service.kubernetes.io/load-balancer-cleanup اور قسم کے ساتھ ہر سروس سے منسلک ہے۔ LoadBalancer. ایسی سروس کو حذف کرنے کے وقت، یہ وسائل کے اصل حذف ہونے سے روکتا ہے جب تک کہ تمام متعلقہ بیلنسر وسائل کی "کلین اپ" مکمل نہ ہو جائے۔

API مشینری

اصل "استحکام سنگ میل" Kubernetes API سرور کے علاقے اور اس کے ساتھ تعامل میں ہے۔ یہ بڑی حد تک بدولت ہوا۔ ان لوگوں کو مستحکم حالت میں منتقل کرنا جنہیں خصوصی تعارف کی ضرورت نہیں ہے۔ CustomResourceDefinitions (CRD)، جسے Kubernetes 1.7 کے دور دراز دنوں سے بیٹا کا درجہ حاصل ہے (اور یہ جون 2017 ہے!)۔ وہی استحکام متعلقہ خصوصیات میں آیا:

• "ذیلی وسائل" کے ساتھ /status и /scale حسب ضرورت وسائل کے لیے؛
• تبادلوں CRD کے لیے ورژن، بیرونی ویب ہک پر مبنی؛
• حال ہی میں پیش کیا (K8s 1.15 میں) پہلے سے طے شدہ اقدار (ڈیفالٹنگ) اور خودکار فیلڈ ہٹانا (کاٹنا) حسب ضرورت وسائل کے لیے؛
• موقع OpenAPI v3 اسکیما کا استعمال کرتے ہوئے OpenAPI دستاویزات کو تخلیق اور شائع کرنا جو سرور کی طرف CRD وسائل کو درست کرنے کے لیے استعمال کیا جاتا ہے۔

ایک اور طریقہ کار جو طویل عرصے سے کبرنیٹس کے منتظمین سے واقف ہے: داخلہ ویب ہک - بھی ایک طویل عرصے تک بیٹا اسٹیٹس میں رہا (K8s 1.9 کے بعد سے) اور اب اسے مستحکم قرار دیا گیا ہے۔

دو دیگر خصوصیات بیٹا تک پہنچ گئی ہیں: سرور سائڈ کا اطلاق ہوتا ہے۔ и بک مارکس دیکھیں.

اور الفا ورژن میں واحد نمایاں جدت تھی۔ ردعمل سے SelfLink - ایک خاص URI جو مخصوص آبجیکٹ کی نمائندگی کرتا ہے اور اس کا حصہ ہے۔ ObjectMeta и ListMeta (یعنی Kubernetes میں کسی بھی چیز کا حصہ)۔ وہ اسے کیوں چھوڑ رہے ہیں؟ ایک سادہ انداز میں حوصلہ افزائی آوازیں جیسا کہ اس فیلڈ کی حقیقی (زبردست) وجوہات کی عدم موجودگی اب بھی موجود ہے۔ مزید باضابطہ وجوہات کارکردگی کو بہتر بنانا (غیر ضروری فیلڈ کو ہٹا کر) اور عام-اپیسرور کے کام کو آسان بنانا ہے، جو اس طرح کے فیلڈ کو ایک خاص طریقے سے ہینڈل کرنے پر مجبور ہوتا ہے (یہ واحد فیلڈ ہے جو آبجیکٹ سے پہلے سیٹ کیا جاتا ہے۔ سلسلہ وار ہے)۔ حقیقی متروک ہونا (بیٹا کے اندر) SelfLink Kubernetes ورژن 1.20، اور فائنل - 1.21 کے ذریعے ہو گا۔

ڈیٹا اسٹوریج

اسٹوریج کے علاقے میں اہم کام، پچھلے ریلیز کی طرح، علاقے میں دیکھا جاتا ہے CSI سپورٹ. یہاں اہم تبدیلیاں یہ تھیں:

• پہلی بار (الفا ورژن میں) نمودار ہوا ونڈوز ورکر نوڈس کے لیے CSI پلگ ان سپورٹ: اسٹوریج کے ساتھ کام کرنے کا موجودہ طریقہ پاورشیل پر مبنی مائیکروسافٹ کے Kubernetes کور اور FlexVolume پلگ ان میں درختوں کے اندر پلگ ان کو بھی بدل دے گا۔

  
  ونڈوز کے لیے Kubernetes میں CSI پلگ ان کو لاگو کرنے کی اسکیم

• موقع CSI والیوم کا سائز تبدیل کرنا, K8s 1.12 میں دوبارہ متعارف کرایا گیا، بیٹا ورژن تک بڑھ گیا ہے۔
• اسی طرح کی "فروغ" (الفا سے بیٹا تک) مقامی وقتی حجم بنانے کے لیے CSI استعمال کرنے کی صلاحیت سے حاصل کی گئی تھی (CSI ان لائن والیوم سپورٹ).

Kubernetes کے پچھلے ورژن میں متعارف کرایا گیا ہے۔ حجم کلوننگ تقریب (موجودہ پیویسی کا استعمال کرتے ہوئے بطور DataSource نیا پیویسی بنانے کے لیے) کو بھی اب بیٹا اسٹیٹس مل گیا ہے۔

شیڈولر

شیڈولنگ میں دو قابل ذکر تبدیلیاں (دونوں الفا میں):

• EvenPodsSpreading --.موقع بوجھ کی "منصفانہ تقسیم" کے لیے منطقی ایپلیکیشن یونٹس کے بجائے پوڈز کا استعمال کریں۔ (جیسے تعیناتی اور ریپلیکا سیٹ) اور اس تقسیم کو ایڈجسٹ کرنا (ایک سخت ضرورت کے طور پر یا نرم حالت کے طور پر، یعنی ترجیح)۔ یہ خصوصیت منصوبہ بند پوڈز کی موجودہ تقسیم کی صلاحیتوں کو وسعت دے گی، جو فی الحال اختیارات کے لحاظ سے محدود ہے۔ PodAffinity и PodAntiAffinity، منتظمین کو اس معاملے میں بہتر کنٹرول دینا، جس کا مطلب ہے بہتر اعلیٰ دستیابی اور وسائل کا بہتر استعمال۔ تفصیلات - میں CAP.
• استعمال کریں بیسٹ فٹ پالیسی в RequestedToCapacityRatio ترجیحی فنکشن پوڈ کی منصوبہ بندی کے دوران، جو اجازت دے گا استعمال کریں بن پیکنگ ("کنٹینرز میں پیکنگ") دونوں بنیادی وسائل (پروسیسر، میموری) اور توسیع شدہ (جیسے GPU) کے لیے۔ مزید تفصیلات کے لیے دیکھیں CAP.

  
  شیڈولنگ پوڈ: بہترین فٹ پالیسی استعمال کرنے سے پہلے (براہ راست ڈیفالٹ شیڈیولر کے ذریعے) اور اس کے استعمال کے ساتھ (شیڈیولر ایکسٹینڈر کے ذریعے)

اس کے علاوہ، کی طرف سے نمائندگی مین Kubernetes ڈویلپمنٹ ٹری (درخت سے باہر) کے باہر اپنے شیڈیولر پلگ ان بنانے کی صلاحیت۔

دیگر تبدیلیاں۔

Kubernetes 1.16 ریلیز میں بھی اسے نوٹ کیا جا سکتا ہے۔ کے لئے پہل لانا مکمل ترتیب میں دستیاب میٹرکس، یا زیادہ واضح طور پر، کے مطابق سرکاری ضابطے K8s کے آلے تک۔ وہ زیادہ تر اسی پر انحصار کرتے ہیں۔ پرومیتھیس دستاویزات. مختلف وجوہات کی بنا پر تضادات پیدا ہوئے (مثال کے طور پر، موجودہ ہدایات کے ظاہر ہونے سے پہلے ہی کچھ میٹرکس بنائے گئے تھے)، اور ڈویلپرز نے فیصلہ کیا کہ اب وقت آگیا ہے کہ ہر چیز کو ایک ہی معیار پر لایا جائے، "باقی Prometheus ماحولیاتی نظام کے مطابق"۔ اس اقدام کا موجودہ نفاذ الفا کی حیثیت میں ہے، جسے Kubernetes کے بعد کے ورژنز میں بیٹا (1.17) اور مستحکم (1.18) میں بتدریج فروغ دیا جائے گا۔

اس کے علاوہ، مندرجہ ذیل تبدیلیوں کو نوٹ کیا جا سکتا ہے:

• ونڈوز سپورٹ ڈویلپمنٹ с ظہور اس OS (الفا ورژن) کے لیے Kubeadm افادیت، موقع RunAsUserName ونڈوز کنٹینرز کے لیے (الفا ورژن) بہتری گروپ مینیجڈ سروس اکاؤنٹ (gMSA) بیٹا ورژن تک سپورٹ کرتا ہے، حمایت vSphere والیوم کے لیے ماؤنٹ/اٹیچ کریں۔
• ری سائیکل API ردعمل میں ڈیٹا کمپریشن میکانزم. پہلے، ان مقاصد کے لیے ایک HTTP فلٹر استعمال کیا جاتا تھا، جس نے متعدد پابندیاں عائد کیں جو اسے بطور ڈیفالٹ فعال ہونے سے روکتی تھیں۔ "شفاف درخواست کمپریشن" اب کام کرتا ہے: کلائنٹ بھیج رہے ہیں۔ Accept-Encoding: gzip ہیڈر میں، اگر اس کا سائز 128 KB سے زیادہ ہو تو انہیں GZIP-کمپریسڈ جواب ملتا ہے۔ گو کلائنٹس خود بخود کمپریشن کو سپورٹ کرتے ہیں (مطلوبہ ہیڈر بھیجنا)، اس لیے وہ فوری طور پر ٹریفک میں کمی محسوس کریں گے۔ (دوسری زبانوں کے لیے معمولی ترمیم کی ضرورت ہو سکتی ہے۔)
• ممکن ہو گیا۔ بیرونی میٹرکس کی بنیاد پر HPA کو/صفر پوڈ تک پیمانہ کرنا. اگر آپ آبجیکٹ/بیرونی میٹرکس کی بنیاد پر اسکیل کرتے ہیں، تو جب کام کا بوجھ بیکار ہوتا ہے تو آپ وسائل کو بچانے کے لیے خود بخود 0 replicas پر اسکیل کرسکتے ہیں۔ یہ خصوصیت خاص طور پر ان معاملات کے لیے مفید ہونی چاہیے جہاں کارکن GPU وسائل کی درخواست کرتے ہیں، اور مختلف قسم کے بیکار کارکنوں کی تعداد دستیاب GPUs کی تعداد سے زیادہ ہے۔
• نیا کلائنٹ - k8s.io/client-go/metadata.Client - اشیاء تک "عام" رسائی کے لیے۔ اسے آسانی سے میٹا ڈیٹا کو بازیافت کرنے کے لیے ڈیزائن کیا گیا ہے (یعنی ذیلی سیکشن metadata) کلسٹر وسائل سے اور ان کے ساتھ کوڑا اٹھانے اور کوٹہ کے کام انجام دیں۔
• Kubernetes بنائیں اب آپ کر سکتے ہیں بغیر میراث کے ("بلٹ ان" ان ٹری) کلاؤڈ فراہم کنندگان (الفا ورژن)۔
• kubeadm یوٹیلیٹی کو شامل کیا تجرباتی (الفا ورژن) آپریشن کے دوران اپنی مرضی کے مطابق پیچ لگانے کی صلاحیت init, join и upgrade. جھنڈا استعمال کرنے کے طریقے کے بارے میں مزید جانیں۔ --experimental-kustomizeمیں دیکھیں CAP.
• apiserver کے لئے نیا اختتامی نقطہ - readyz, - آپ کو اس کی تیاری کے بارے میں معلومات برآمد کرنے کی اجازت دیتا ہے۔ API سرور کے پاس بھی اب ایک جھنڈا ہے۔ --maximum-startup-sequence-duration، آپ کو اس کے دوبارہ شروع ہونے کو منظم کرنے کی اجازت دیتا ہے۔
• دو Azure کی خصوصیات مستحکم قرار دیا گیا: حمایت دستیابی زونز (دستیابی زونز) اور کراس ریسورس گروپ (آر جی)۔ اس کے علاوہ، Azure نے مزید کہا:
  • تصدیق کی حمایت AAD اور ADFS؛
  • تشریح service.beta.kubernetes.io/azure-pip-name لوڈ بیلنسر کے عوامی IP کی وضاحت کرنے کے لیے؛
  • موقع настройки LoadBalancerName и LoadBalancerResourceGroup.
• AWS اب ہے کی حمایت ونڈوز پر EBS کے لیے اور مرضی کے مطابق EC2 API کالز DescribeInstances.
• Kubeadm اب خود مختار ہے۔ ہجرت کرتا ہے CoreDNS ورژن کو اپ گریڈ کرتے وقت CoreDNS کنفیگریشن۔
• بائنریز وغیرہ متعلقہ ڈوکر امیج میں کیا ہے world-executable، جو آپ کو روٹ رائٹس کی ضرورت کے بغیر اس تصویر کو چلانے کی اجازت دیتا ہے۔ نیز، وغیرہ کی منتقلی کی تصویر روک دیا etcd2 ورژن کی حمایت.
• В کلسٹر آٹو اسکیلر 1.16.0 ڈسٹرولیس کو بیس امیج کے طور پر استعمال کرنے پر سوئچ کیا، کارکردگی میں بہتری آئی، نئے کلاؤڈ فراہم کنندگان (DigitalOcean، Magnum، Packet) شامل کیے گئے۔
• استعمال شدہ/ منحصر سافٹ ویئر میں اپ ڈیٹس: 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