عارضي ڪنٽينرز بابت تفصيل (۽ انهن جي استعمال جا مثال) ۾ ڳولهي سگهجن ٿا لاڳاپيل KEP. موجوده عمل (K8s 1.16 ۾) هڪ الفا ورزن آهي، ۽ بيٽا ورزن ۾ ان جي منتقلي لاءِ معيار جي وچ ۾ آهي “[Kubernetes] جي گهٽ ۾ گهٽ 2 رليزز لاءِ Ephemeral Containers API کي جانچڻ.”
NB: ان جي ذات ۽ ان جي نالي ۾، خصوصيت اڳ ۾ ئي موجود پلگ ان وانگر آهي kubectl-debugجنهن بابت اسان اڳ ۾ ئي لکيو آهي. اهو توقع آهي ته عارضي ڪنٽينرز جي آمد سان، هڪ الڳ خارجي پلگ ان جي ترقي بند ٿي ويندي.
هڪ ٻي جدت - PodOverhead - مهيا ڪرڻ لاء ٺهيل پوڊ لاءِ اوور هيڊ خرچن جي حساب لاءِ ميڪانيزم، جيڪو استعمال ٿيل رن ٽائم جي لحاظ کان تمام گھڻو مختلف ٿي سگھي ٿو. مثال طور، ليکڪ هن KEP نتيجي ۾ ڪاتا ڪنٽينرز، جن کي گيسٽ ڪنٽينل، ڪاٽا ايجنٽ، انٽ سسٽم وغيره هلائڻ جي ضرورت آهي. جڏهن اوور هيڊ تمام وڏو ٿي وڃي ٿو، ان کي نظر انداز نٿو ڪري سگهجي، جنهن جو مطلب آهي ته ان کي وڌيڪ ڪوٽا، منصوبابندي، وغيره لاء اڪائونٽ ۾ وٺڻ جو هڪ طريقو هجڻ گهرجي. ان کي لاڳو ڪرڻ لاء PodSpec فيلڊ شامل ڪيو ويو Overhead *ResourceList (ان ۾ ڊيٽا سان گڏ RuntimeClass، جيڪڏهن هڪ استعمال ڪيو وڃي).
هڪ ٻيو قابل ذڪر جدت آهي نوڊ ٽوپولوجي مينيجر(نوڊ ٽوپولوجي مئنيجر)، ڪبرنيٽس ۾ مختلف حصن لاءِ هارڊويئر وسيلن جي مختص کي ٺيڪ ڪرڻ جي طريقي کي متحد ڪرڻ لاءِ ٺهيل آهي. هي قدم مختلف جديد سسٽم (ٽيليڪميونيڪيشن، مشين لرننگ، مالي خدمتون وغيره جي شعبي کان) جي وڌندڙ ضرورتن جي ڪري آهي اعليٰ ڪارڪردگي متوازي ڪمپيوٽنگ ۽ عملن جي عمل ۾ دير کي گهٽائڻ لاءِ، جنهن لاءِ اهي جديد سي پي يو استعمال ڪن ٿا ۽ هارڊويئر تيز ڪرڻ جي صلاحيت. Kubernetes ۾ اهڙيون اصلاحون هن وقت تائين حاصل ڪيون ويون آهن مختلف حصن (سي پي يو مئنيجر، ڊيوائس مئنيجر، سي اين آئي) جي مهرباني، ۽ هاڻي انهن کي هڪ واحد اندروني انٽرفيس شامل ڪيو ويندو جيڪو طريقي کي متحد ڪري ٿو ۽ نئين هڪجهڙائي جي ڪنيڪشن کي آسان بڻائي ٿو - نام نهاد ٽوپولوجي-. آگاهي - اجزاء Kubelet پاسي تي. تفصيل - ۾ لاڳاپيل KEP.
ٽوپولوجي مئنيجر جزو ڊراگرام
ايندڙ خصوصيت - ڪنٽينرز جي جانچ ڪندي جڏهن اهي هلائي رهيا آهن (شروعاتي جاچ). جيئن توهان ڄاڻو ٿا، ڪنٽينرز لاءِ جيڪي لانچ ٿيڻ ۾ گهڻو وقت وٺن ٿا، ان لاءِ تازه ترين اسٽيٽس حاصل ڪرڻ مشڪل آهي: اهي يا ته ”ماري“ ويندا آهن ان کان اڳ جو اهي اصل ۾ ڪم ڪرڻ شروع ڪن، يا اهي ڊگهي عرصي تائين بند ٿي وڃن. نئون چيڪ (فعال جي دروازي ذريعي سڏيو ويندو آهي StartupProbeEnabled) منسوخ ڪري ٿو - يا بلڪه، ملتوي ڪري ٿو - ڪنهن ٻئي چيڪن جو اثر ان وقت تائين جيستائين پوڊ کي ختم نه ڪيو وڃي. انهي سبب لاء، خاصيت کي اصل ۾ سڏيو ويندو هو pod-Startup liveness-probe holdoff. پوڊز لاءِ جيڪي شروع ٿيڻ ۾ ڊگهو وقت وٺن ٿا، توهان نسبتا مختصر وقت جي وقفن ۾ رياست کي پول ڪري سگهو ٿا.
اضافي طور تي، RuntimeClass لاءِ هڪ سڌارو فوري طور تي بيٽا اسٽيٽس ۾ موجود آهي، ”متضاد ڪلستر“ لاءِ سپورٽ شامل ڪندي. سي رن ٽائم ڪلاس شيڊيولنگ ھاڻي اھو ضروري نه آھي ته ھر نوڊ لاءِ ھر RuntimeClass لاءِ سپورٽ ھجي: پوڊز لاءِ توھان منتخب ڪري سگھو ٿا RuntimeClass بغير سوچڻ جي. اڳي، هن کي حاصل ڪرڻ لاءِ - ته جيئن پوڊس ختم ٿين نوڊس تي هر شي جي مدد سان انهن جي ضرورت لاءِ - اهو ضروري هو ته مناسب ضابطن کي مقرر ڪيو وڃي NodeSelector ۽ رواداري. IN ڪيپ اهو استعمال جي مثالن بابت ڳالهائيندو آهي ۽، يقينا، عمل درآمد جي تفصيل.
حمايت ٻٽي نيٽ ورڪ اسٽيڪ - IPv4/IPv6 - ۽ ان سان لاڳاپيل "سمجھ" پوڊس، نوڊس، خدمتن جي سطح تي. ان ۾ شامل آهي IPv4-to-IPv4 ۽ IPv6-to-IPv6 پوڊز جي وچ ۾ مداخلت، پوڊ کان ٻاهرين خدمتن تائين، حوالن تي عمل درآمد (برج CNI، PTP CNI ۽ Host-Local 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#
آخري نقطي لاءِ نئون API - EndpointSlice API. اهو حل ڪري ٿو موجوده Endpoint 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 سرور جي علائقي ۾ آهي ۽ ان سان رابطو. اهو ٿي چڪو آهي وڏي پئماني تي شڪر انهن کي مستحڪم حيثيت ڏانهن منتقل ڪرڻ جن کي خاص تعارف جي ضرورت ناهي CustomResource Definitions (CRD)، جن کي ڪبرنيٽس 1.7 جي ڏورانهن ڏينهن کان بيٽا جي حيثيت حاصل آهي (۽ هي جون 2017 آهي!). ساڳئي استحڪام سان لاڳاپيل خاصيتون آيو:
"ذيلي ذريعا" سان گڏ /status и /scale ڪسٽم وسيلن لاء؛
پهريون ڀيرو (الفا ورزن ۾) ظاهر ٿيوونڊوز ورڪر نوڊس لاءِ CSI پلگ ان سپورٽ: اسٽوريج سان ڪم ڪرڻ جو موجوده طريقو به ان-ٽري پلگ ان کي تبديل ڪندو Kubernetes core ۾ ۽ FlexVolume پلگ ان Microsoft کان Powershell جي بنياد تي؛
ونڊوز لاءِ Kubernetes ۾ CSI پلگ ان لاڳو ڪرڻ جي اسڪيم
موقعو CSI حجم کي تبديل ڪرڻ, K8s 1.12 ۾ واپس متعارف ڪرايو ويو، بيٽا ورزن تائين وڌي ويو آهي؛
ساڳي ئي ”ترقي“ (الفا کان بيٽا تائين) حاصل ڪئي وئي سي ايس آءِ استعمال ڪرڻ جي صلاحيت سان مقامي عارضي حجم ٺاهڻ لاءِ (CSI ان لائن حجم سپورٽ).
Kubernetes جي پوئين ورزن ۾ متعارف ڪرايو ويو حجم ڪلوننگ فنڪشن (موجوده پي وي سي استعمال ڪندي جيئن DataSource نئين پي وي سي ٺاهڻ لاءِ) پڻ هاڻي بيٽا اسٽيٽس حاصل ڪري چڪو آهي.
شيڊيولر
شيڊول ۾ ٻه قابل ذڪر تبديليون (ٻئي الفا ۾):
EvenPodsSpreading - موقعو لوڊ جي ”منصفانه ورڇ“ لاءِ منطقي ايپليڪيشن يونٽن جي بدران پوڊ استعمال ڪريو (جهڙوڪ تعیناتي ۽ ريپليڪا سيٽ) ۽ هن تقسيم کي ترتيب ڏيڻ (هڪ سخت ضرورت جي طور تي يا نرم حالت جي طور تي، يعني ترجيح). خصوصيت کي وڌايو ويندو موجوده تقسيم جي صلاحيتن جي منصوبابندي ڪيل پوڊ، في الحال محدود اختيارن طرفان PodAffinity и PodAntiAffinity، منتظمين کي هن معاملي ۾ بهتر ڪنٽرول ڏئي ٿو، جنهن جو مطلب آهي بهتر اعلي دستيابي ۽ بهتر وسيلن جو استعمال. تفصيل - ۾ ڪيپ.
استعمال ڪريو BestFit پاليسي в RequestedToCapacityRatio Priority Function پوڊ پلاننگ دوران، جيڪو اجازت ڏيندو استعمال ڪريو پيڪنگنگ ("ڪنٽينرز ۾ پيڪنگ") ٻنهي بنيادي وسيلن لاءِ (پروسيسر، ميموري) ۽ وڌايل (جهڙوڪ GPU). وڌيڪ تفصيل لاءِ، ڏسو ڪيپ.
شيڊولنگ پوڊس: استعمال ڪرڻ کان اڳ بهترين فٽ پاليسي (سڌي طرح ڊفالٽ شيڊولر ذريعي) ۽ ان جي استعمال سان (اسڪيولر توسیع ڪندڙ ذريعي)
ان کان سواء، جي نمائندگي ڪئي وئي آهي مکيه Kubernetes ڊولپمينٽ ٽري (وڻ کان ٻاهر) کان ٻاهر توهان جي پنهنجي شيڊولر پلگ ان ٺاهڻ جي صلاحيت.
ٻيون تبديليون
پڻ ڪبرنيٽس 1.16 رليز ۾ توهان نوٽ ڪري سگهو ٿا لاء شروعات آڻڻ دستياب ميٽرڪ مڪمل ترتيب ۾، يا وڌيڪ واضح طور تي، مطابق سرڪاري ضابطا K8s اوزارن ڏانهن. اهي گهڻو ڪري لاڳاپيل تي ڀروسو ڪندا آهن Prometheus دستاويز. تضادات مختلف سببن جي ڪري پيدا ٿيا (مثال طور، موجوده هدايتن جي ظاهر ٿيڻ کان اڳ ڪجهه ميٽرڪس ٺاهيا ويا هئا)، ۽ ڊولپر فيصلو ڪيو ته اهو وقت آهي هر شيء کي هڪ معيار تي آڻڻ جو، "باقي Prometheus ecosystem جي مطابق." هن شروعات جو موجوده عمل الفا اسٽيٽس ۾ آهي، جنهن کي ڪبرنيٽس جي ايندڙ ورزن ۾ بيٽا (1.17) ۽ مستحڪم (1.18) ۾ ترقي ڪئي ويندي.
ريشيل ٿيلAPI جوابن ۾ ڊيٽا کمپريشن ميڪانيزم. اڳي، هڪ HTTP فلٽر انهن مقصدن لاءِ استعمال ڪيو ويو، جنهن ڪيتريون ئي پابنديون لاڳو ڪيون جيڪي ان کي ڊفالٽ طور فعال ٿيڻ کان روڪيو. "شفاف درخواست ڪمپريشن" هاڻي ڪم ڪري ٿو: ڪلائنٽ موڪلڻ Accept-Encoding: gzip هيڊر ۾، انهن کي هڪ GZIP-compressed جواب ملي ٿو جيڪڏهن ان جي سائيز 128 KB کان وڌيڪ آهي. وڃو ڪلائنٽ پاڻمرادو ڪمپريشن جي حمايت ڪن ٿا (گهربل هيڊر موڪلڻ)، تنهن ڪري اهي فوري طور تي ٽرئفڪ ۾ گهٽتائي محسوس ڪندا. (ٻين ٻولين لاءِ ٿوري تبديلي جي ضرورت ٿي سگھي ٿي.)
ممڪن ٿيوخارجي ميٽرڪس جي بنياد تي HPA کان / صفر پوڊ تائين اسڪيلنگ. جيڪڏھن توھان ماپ ڪريو ٿا شيون / خارجي ميٽرڪس جي بنياد تي، پوءِ جڏھن ڪم لوڊ بيڪار ھجي ته توھان وسيلن کي بچائڻ لاءِ پاڻمرادو 0 نقلن تائين ماپ ڪري سگھو ٿا. هي خصوصيت خاص طور تي انهن ڪيسن لاءِ ڪارائتو هجڻ گهرجي جتي مزدور GPU وسيلن جي درخواست ڪن ٿا، ۽ بيڪار ڪارڪنن جي مختلف قسمن جو تعداد موجود GPUs جي تعداد کان وڌيڪ آهي.
نئون گراهڪ - k8s.io/client-go/metadata.Client - شين تائين "عام" رسائي لاءِ. اهو ٺهيل آهي آساني سان ميٽاداٽا ٻيهر حاصل ڪرڻ لاءِ (يعني سبسيڪشن metadata) ڪلسٽر وسيلن مان ۽ انهن سان گڏ ڪچرو گڏ ڪرڻ ۽ ڪوٽا آپريشن انجام ڏيو.
kubeadm افاديت ڏانهن شامل ڪيو ويو تجرباتي (الفا ورزن) آپريشن دوران ڪسٽمائيز پيچ لاڳو ڪرڻ جي صلاحيت init, join и upgrade. وڌيڪ سکو ته پرچم ڪيئن استعمال ڪجي --experimental-kustomize۾ ڏسو ڪيپ.
apiserver لاءِ نئون آخري نقطو - readyz, - توهان کي ان جي تياري بابت معلومات برآمد ڪرڻ جي اجازت ڏئي ٿي. API سرور پڻ ھاڻي ھڪڙو جھنڊو آھي --maximum-startup-sequence-duration، توهان کي ان جي بحالي کي منظم ڪرڻ جي اجازت ڏئي ٿي.
ٻه Azure لاء خاصيتون مستحڪم قرار ڏنو: حمايت دستيابي جا علائقا (دستياب زون) ۽ ڪراس ريسورس گروپ (آر جي). ان کان سواء، Azure شامل ڪيو آهي:
وضاحت ڏيڻservice.beta.kubernetes.io/azure-pip-name لوڊ بيلنس جي عوامي IP جي وضاحت ڪرڻ لاء؛
موقعو سيٽنگون LoadBalancerName и LoadBalancerResourceGroup.
AWS هاڻي آهي حمايت ونڊوز تي EBS لاءِ ۽ بهتر ڪيل EC2 API ڪالون DescribeInstances.
Kubeadm هاڻي آزاد آهي لڏپلاڻ ڪري ٿو CoreDNS ترتيب جڏهن CoreDNS ورزن کي اپڊيٽ ڪيو وڃي.
بائنري وغيره لاڳاپيل Docker تصوير ۾ ٺهيل world-executable، جيڪو توهان کي اجازت ڏئي ٿو هن تصوير کي بغير روٽ حقن جي ضرورت کان سواء. پڻ، etcd لڏپلاڻ واري تصوير روڪيو etcd2 ورزن سپورٽ.
В ڪلستر آٽو اسڪيلر 1.16.0 بنيادي تصوير جي طور تي distroless استعمال ڪرڻ، بهتر ڪارڪردگي، نوان بادل فراهم ڪندڙ شامل ڪيا ويا (DigitalOcean، Magnum، Packet).
استعمال ٿيل / منحصر سافٽ ويئر ۾ تازه ڪاريون: Go 1.12.9، etcd 3.3.15، CoreDNS 1.6.2.