Kubernetes 1.14: مکيه جدت جو جائزو

هن رات وٺندو Kubernetes جي ايندڙ رليز - 1.14. روايت جي مطابق جيڪا اسان جي بلاگ لاءِ ترقي ڪئي آهي، اسان هن شاندار اوپن سورس پراڊڪٽ جي نئين ورزن ۾ اهم تبديلين بابت ڳالهائي رهيا آهيون.

هن مواد کي تيار ڪرڻ لاء استعمال ڪيل معلومات مان ورتو ويو آهي Kubernetes واڌارو ٽريڪنگ ٽيبل, تبديلي-1.14 ۽ لاڳاپيل مسئلا، پل درخواستون، ڪبرنيٽس اينهانسمينٽ پروپوزل (KEP).

اچو ته هڪ اهم تعارف سان شروع ڪريون SIG ڪلستر-لائف سائيڪل کان: متحرڪ ناڪامي ڪلستر ڪبرنيٽس (يا وڌيڪ صحيح هجڻ لاءِ، خود ميزباني ڪيل HA ڊيپلائيمينٽ) هاڻي آهي ٺاهي سگهجي ٿو استعمال ڪندي واقف (سنگل نوڊ ڪلستر جي حوالي سان) حڪم kubeadm (init и join). مختصر ۾، هن لاء:

• ڪلستر پاران استعمال ٿيل سرٽيفڪيٽ رازن ڏانهن منتقل ڪيا ويا آهن؛
• K8s ڪلستر جي اندر etcd ڪلستر استعمال ڪرڻ جي امڪان لاءِ (يعني اڳئين موجود خارجي انحصار کان نجات حاصل ڪرڻ) etcd-آپريٽر;
• خارجي لوڊ بيلنس لاءِ تجويز ڪيل سيٽنگن کي دستاويز ڪري ٿو جيڪا غلطي برداشت ڪرڻ واري ترتيب فراهم ڪري ٿي (مستقبل ۾ هن انحصار کي ختم ڪرڻ جي منصوبابندي ڪئي وئي آهي، پر هن اسٽيج تي نه).

Kubernetes HA ڪلستر جو آرڪيٽيڪچر kubeadm سان ٺهيل آهي

ان تي عملدرآمد جا تفصيل هن ۾ ملي سگهن ٿا ڊيزائن جي تجويز. اها خاصيت واقعي ڊگهي انتظار ۾ هئي: الفا ورزن واپس K8s 1.9 ۾ توقع ڪئي وئي، پر صرف هاڻي ظاهر ٿيو.

API

ٽيم apply ۽ عام طور تي ڳالهائڻ بياناتي اعتراض جو انتظام گذري ويو کان kubectl apiserver ۾. ڊولپرز پاڻ مختصر طور تي پنهنجي فيصلي جي وضاحت ڪندي چيو kubectl apply - Kubernetes ۾ ترتيبن سان ڪم ڪرڻ جو هڪ بنيادي حصو، جڏهن ته، "اها خرابين سان ڀريل آهي ۽ درست ڪرڻ ڏکيو آهي،" ۽ تنهن ڪري هن ڪارڪردگي کي معمول تي آڻڻ ۽ ڪنٽرول جهاز ڏانهن منتقل ڪرڻ جي ضرورت آهي. مسئلن جا سادي ۽ واضح مثال جيڪي اڄ موجود آهن:

ان تي عملدرآمد بابت تفصيل ڏنل آهن ڪيپ. موجوده تياري الفا آهي (بيٽا ڏانهن واڌاري ايندڙ ڪبرنيٽس رليز لاءِ منصوبابندي ڪئي وئي آهي).

الفا ورزن ۾ دستياب آهي موقعو استعمال ڪندي OpenAPI v3 اسڪيم لاءِ OpenAPI دستاويز ٺاهڻ ۽ شايع ڪرڻ CustomResources لاءِ (CR) تصديق ڪرڻ لاءِ استعمال ڪيو ويو (سرور-سائيڊ) K8s صارف جي بيان ڪيل وسيلن (CustomResourceDefinition، CRD). CRD لاءِ OpenAPI شايع ڪرڻ گراهڪن کي اجازت ڏئي ٿو (مثال طور kubectl) توهان جي پاسي تي تصديق ڪريو (اندر kubectl create и kubectl apply) ۽ اسڪيم مطابق دستاويز جاري ڪريو (kubectl explain). تفصيل - ۾ ڪيپ.

اڳ ۾ موجود لاگ هاڻي کليل آهن پرچم سان O_APPEND (پر نه O_TRUNC) ڪجهه حالتن ۾ لاگز جي نقصان کان بچڻ لاءِ ۽ گھمڻ لاءِ ٻاهرين يوٽيلٽيز سان لاگز کي ٽوڙڻ جي سهولت لاءِ.

پڻ Kubernetes API جي حوالي سان، اهو نوٽ ڪري سگهجي ٿو ته ان ۾ PodSandbox и PodSandboxStatus شامل ڪيو ويو ميدان runtime_handler جي باري ۾ معلومات رڪارڊ ڪرڻ لاء RuntimeClass پوڊ ۾ (ان بابت وڌيڪ پڙهو متن ۾ ڪبرنيٽس 1.12 رليز، جتي هي ڪلاس هڪ الفا ورزن جي طور تي ظاهر ٿيو) ۽ داخلا ويب هوڪس ۾ لاڳو ڪيو ويو ڪهڙو نسخو طئي ڪرڻ جي صلاحيت AdmissionReview اهي حمايت ڪن ٿا. آخرڪار، داخلا ويب هوڪس ضابطا هاڻي آهن محدود ٿي سگهي ٿو نالو اسپيس ۽ ڪلستر فريم ورڪ پاران انهن جي استعمال جي حد.

ذخيرو

PersistentLocalVolumes، جنهن کي ڇڏڻ کان وٺي بيٽا جي حيثيت هئي K8s 1.10, اعلان ڪيو مستحڪم (GA): هي خصوصيت دروازو هاڻي غير فعال نه آهي ۽ Kubernetes 1.17 ۾ هٽايو ويندو.

موقعو ماحولياتي متغير استعمال ڪندي سڏيو ويندو آهي هيٺيون API (مثال طور، پوڊ جو نالو) ڊائريڪٽرن جي نالن لاءِ جيئن لڳل subPath، ترقي ڪئي وئي - هڪ نئين ميدان جي صورت ۾ subPathExpr، جيڪو هاڻي مطلوب ڊاريڪٽري جو نالو طئي ڪرڻ لاءِ استعمال ڪيو ويندو آهي. خصوصيت شروعات ۾ ڪبرنيٽس 1.11 ۾ ظاهر ٿي، پر 1.14 لاءِ اها الفا ورزن جي حيثيت ۾ رهي.

جيئن ته پوئين ڪبرنيٽس رليز سان، ڪيتريون ئي اهم تبديليون متعارف ڪرايون ويون آهن فعال طور تي ترقي ڪندڙ CSI (ڪنٽينر اسٽوريج انٽرفيس):

سي آء

دستياب ٿيو (الفا ورزن جي حصي جي طور تي) حمايت CSI حجمن لاءِ ماپڻ. ان کي استعمال ڪرڻ لاءِ توھان کي فعال ڪرڻ جي ضرورت پوندي خصوصيت گيٽ سڏيو ExpandCSIVolumes, گڏو گڏ هڪ مخصوص CSI ڊرائيور ۾ هن آپريشن لاء حمايت جي موجودگي.

الفا ورزن ۾ CSI لاءِ ٻي خصوصيت - موقعو سڌو حوالو ڏيو (يعني PV/PVC استعمال ڪرڻ کان سواءِ) پوڊ جي وضاحتن ۾ CSI حجمن ڏانهن. هي خاص طور تي ريموٽ ڊيٽا اسٽوريج جي طور تي CSI جي استعمال تي پابندي کي هٽائي ٿوانهن لاءِ دنيا جا دروازا کولڻ مقامي عارضي حجم. استعمال لاءِ (دستاويز مان مثال) چالو ڪيو وڃي CSIInlineVolume خصوصيت جو دروازو.

CSI سان لاڳاپيل Kubernetes جي "اندروني" ۾ پڻ ترقي ڪئي وئي آهي، جيڪي آخري صارفين (سسٽم ايڊمنسٽريٽر) کي ڏسڻ ۾ نه اينديون آهن ... في الحال، ڊولپرز هر اسٽوريج پلگ ان جي ٻن نسخن کي سپورٽ ڪرڻ تي مجبور آهن: هڪ - "ان ۾. پراڻي طريقي سان، K8s ڪوڊ بيس جي اندر (ان-ٽري)، ۽ ٻيو - نئين CSI جي حصي طور (ان بابت وڌيڪ پڙهو، مثال طور، ۾ هتي). اهو سمجھڻ واري تڪليف جو سبب بڻائيندو آهي جنهن کي خطاب ڪرڻ جي ضرورت آهي جيئن CSI پاڻ کي مستحڪم ڪري ٿو. اهو ممڪن ناهي ته صرف اندروني (ان-ٽري) پلگ ان جي API کي ختم ڪرڻ جي ڪري لاڳاپيل Kubernetes پاليسي.

هي سڀ حقيقت اها آهي ته الفا ورزن تائين پهچي ويو لڏپلاڻ وارو عمل اندروني پلگ ان ڪوڊسي ايس آئي پلگ ان ۾ ان-ٽري طور لاڳو ڪيو ويو آهي، جنهن جي ڪري ڊولپرز جون پريشانيون انهن جي پلگ ان جي هڪ ورزن کي سپورٽ ڪرڻ لاءِ گهٽجي وينديون، ۽ پراڻن APIs سان مطابقت برقرار رهندي ۽ انهن کي عام حالتن ۾ غيرمعمولي قرار ڏئي سگهجي ٿو. اميد آهي ته ڪبرنيٽس (1.15) جي ايندڙ رليز تائين سڀ ڪلائوڊ فراهم ڪندڙ پلگ ان لڏپلاڻ ڪئي ويندي، عمل درآمد بيٽا اسٽيٽس حاصل ڪندو ۽ ڊفالٽ طور K8s تنصيبات ۾ چالو ڪيو ويندو. تفصيل لاءِ، ڏسو ڊيزائن جي تجويز. هن لڏپلاڻ جو نتيجو پڻ نڪتو ناڪام مخصوص ڪلائوڊ فراهم ڪندڙن (AWS، Azure، GCE، Cinder) پاران بيان ڪيل حجم جي حدن مان.

اضافي طور تي، سي ايس آئي سان بلاڪ ڊوائيسز لاء سپورٽ (CSIBlockVolume) منتقل ٿيل بيٽا ورزن ڏانهن.

نوڊس / ڪبيليٽ

الفا نسخو پيش ڪيو نئون نقطو Kubelet ۾، لاء ٺهيل مکيه وسيلن تي ميٽرڪ واپسي. عام طور تي ڳالهائڻ، جيڪڏهن اڳ ۾ ڪوبلٽ حاصل ڪيل انگ اکر ڪنٽينر جي استعمال تي cAdvisor کان، هاڻي هي ڊيٽا ڪنٽينر رن ٽائم ماحول مان CRI (ڪنٽينر رن ٽائم انٽرفيس) ذريعي اچي ٿو، پر ڊڪر جي پراڻن ورزن سان ڪم ڪرڻ لاءِ مطابقت پڻ محفوظ آهي. اڳي، ڪبيليٽ ۾ گڏ ڪيل انگ اکر REST API ذريعي موڪليا ويا، پر هاڻي هڪ آخري پوائنٽ تي واقع آهي /metrics/resource/v1alpha1. ڊولپرز جي ڊگهي-مدت حڪمت عملي تي مشتمل آهي Kubelet پاران مهيا ڪيل ميٽرڪس جي سيٽ کي گھٽائڻ لاء. رستي جي ذريعي، اهي ميٽرڪ پاڻ کي هاڻي اهي سڏين ٿا نه "بنيادي ميٽرڪس"، پر "وسيلا ميٽرڪ"، ۽ بيان ڪيا ويا آهن "پهريون درجي جا وسيلا، جهڙوڪ سي پي يو، ۽ ياداشت".

هڪ تمام دلچسپ nuance: GRPC جي آخري پوائنٽ جي واضح ڪارڪردگي جي فائدن جي باوجود Prometheus فارميٽ استعمال ڪرڻ جي مختلف ڪيسن جي مقابلي ۾ (هيٺ ڏنل معيارن مان هڪ جو نتيجو ڏسو)، ليکڪن ڪميونٽي ۾ هن نگراني نظام جي واضح قيادت جي ڪري پروميٿيس جي ٽيڪسٽ فارميٽ کي ترجيح ڏني.

"gRPC وڏي مانيٽرنگ پائپ لائنز سان مطابقت نه رکي ٿي. Endpoint صرف ڪارائتو ٿيندو ميٽرڪس کي ميٽرڪس سرور تائين پهچائڻ يا اجزاء جي نگراني ڪرڻ لاءِ جيڪي سڌو سنئون ان سان ضم ٿين ٿا. Prometheus ٽيڪسٽ فارميٽ ڪارڪردگي جڏهن ميٽرڪس سرور ۾ ڪيشنگ استعمال ڪندي ايترو سٺو اسان لاءِ GRPC تي پروميٿيس کي ترجيح ڏيون ٿا ڇو ته ڪميونٽي ۾ پروميٿيس کي وڏي پيماني تي اپنائڻ. هڪ دفعو OpenMetrics فارميٽ وڌيڪ مستحڪم ٿي ويندو، اسان هڪ پروٽو-بنياد فارميٽ سان gRPC ڪارڪردگي سان رجوع ڪرڻ جي قابل ٿي وينداسين.

GRPC ۽ Prometheus فارميٽ استعمال ڪرڻ جي تقابلي ڪارڪردگي ٽيسٽ مان ھڪڙو نئون Kubelet Endpoint ۾ ميٽرڪس لاءِ. وڌيڪ گراف ۽ ٻيا تفصيل ملي سگھن ٿا ڪيپ.

ٻين تبديلين جي وچ ۾:

• Kubelet هاڻي (هڪ ڀيري) روڪڻ جي ڪوشش ڪنٽينر اڻڄاتل حالت ۾ شروع ڪرڻ کان اڳ ۽ آپريشن کي ختم ڪريو.
• استعمال ڪندي PodPresets هاڻي init ڪنٽينر ڏانهن شامل ڪيو ويو آهي ساڳئي معلومات هڪ باقاعده ڪنٽينر لاء.
• ڪبيليٽ استعمال ڪرڻ شروع ڪيو usageNanoCores CRI شماريات فراهم ڪندڙ کان، ۽ ونڊوز تي نوڊس ۽ ڪنٽينرز لاءِ شامل ڪيو ويو نيٽ ورڪ جا انگ اکر.
• آپريٽنگ سسٽم ۽ فن تعمير جي معلومات هاڻي ليبل ۾ رڪارڊ ٿيل آهي kubernetes.io/os и kubernetes.io/arch نوڊ شيون (بيٽا کان GA تائين منتقل ٿيل).
• پوڊ ۾ ڪنٽينرز لاءِ مخصوص سسٽم يوزر گروپ جي وضاحت ڪرڻ جي صلاحيت (RunAsGroup، ۾ ظاهر ٿيو K8s 1.11) ترقي يافته بيٽا کان اڳ (ڊفالٽ طور تي فعال).
• du ۽ ڳولهيو استعمال ڪيو caAdvisor ۾، تبديل ٿيل Go تي عملدرآمد تي.

CLI

cli-runtime ۽ kubectl ۾ شامل ڪيو ويو -k پرچم سان انضمام لاء ترتيب ڏيڻ (رستي جو، ان جي ترقي هاڻي هڪ الڳ مخزن ۾ ڪيو ويندو آهي)، يعني. خاص ڪسٽمائيزيشن ڊائريڪٽرن مان اضافي YAML فائلن کي پروسيس ڪرڻ لاءِ (انهن کي استعمال ڪرڻ بابت تفصيل لاءِ، ڏسو ڪيپ):

سادي فائل جي استعمال جو مثال حسب ضرورت (ڪسٽمائيز جي هڪ وڌيڪ پيچيده ايپليڪيشن اندر ممڪن آهي پورو ٿي چڪو آهي)

ان کان سواء

• شامل ڪيو ويو نئين ٽيم kubectl create cronjob، جنهن جو نالو پاڻ لاءِ ڳالهائي ٿو.
• В kubectl logs هاڻي توهان ڪري سگهو ٿا گڏ ڪرڻ جھنڊو -f (--follow اسٽريمنگ لاگز لاءِ) ۽ -l (--selector ليبل جي سوال لاءِ).
• ڪيوبڪبل سيکاريو وائلڊ ڪارڊ ذريعي چونڊيل فائلن کي نقل ڪريو.
• ٽيم ڏانهن kubectl wait شامل ڪيو ويو جھنڊو --all مخصوص وسيلن جي قسم جي نالي جي جڳهه ۾ سڀني وسيلن کي چونڊڻ لاء.

ٻيا

هيٺيون صلاحيتون حاصل ڪيون ويون آهن مستحڪم (GA) حيثيت:

• ReadinessGate, پوڊ جي تياري ۾ حساب ۾ رکيل اضافي شرطن جي وضاحت ڪرڻ لاءِ پوڊ جي وضاحت ۾ استعمال ڪيو ويو؛
• وڏن صفحن لاءِ سپورٽ (فيچر گيٽ سڏجي ٿو HugePages);
• CustomPodDNS;
• PriorityClass API پوڊ جي ترجيح ۽ ترجيح.

Kubernetes 1.14 ۾ متعارف ٿيل ٻيون تبديليون:

• ڊفالٽ RBAC پاليسي هاڻي API جي رسائي جي اجازت نٿي ڏئي discovery и access-review صارفين جي تصديق کان سواء (غير تصديق ٿيل).
• سرڪاري CoreDNS سپورٽ يقيني بڻايو صرف لينڪس، تنهن ڪري جڏهن kubeadm استعمال ڪندي ان کي ترتيب ڏيڻ لاء (CoreDNS) ڪلستر ۾، نوڊس صرف لينڪس تي هلڻ گهرجن (نوڊ سليڪٽر هن حد تائين استعمال ڪيا ويا آهن).
• ڊفالٽ CoreDNS ترتيب هاڻي آهي استعمال ڪري ٿو اڳتي پلگ ان پراکسي جي بدران. پڻ، CoreDNS ۾ شامل ڪيو ويو ReadinessProbe، جيڪو مناسب (خدمت لاءِ تيار ناهي) پوڊس تي لوڊ توازن کي روڪي ٿو.
• ڪعبي ۾، مرحلن تي init يا upload-certs, ممڪن ٿيو نئين ڪنٽرول جهاز کي kubeadm-certs راز سان ڳنڍڻ لاءِ گهربل سرٽيفڪيٽ لوڊ ڪريو (پرچم استعمال ڪريو --experimental-upload-certs).
• ونڊوز تنصيب لاءِ الفا ورزن ظاهر ٿيو آهي حمايت gMSA (گروپ مئنيجڊ سروس کاتو) - خاص اڪائونٽس فعال ڊاريڪٽري ۾ جيڪي ڪنٽينرز پاران پڻ استعمال ڪري سگھجن ٿا.
• G.C.E لاءِ چالو mTLS encryption etcd ۽ kube-apiserver جي وچ ۾.
• استعمال ٿيل / منحصر سافٽ ويئر ۾ تازه ڪاريون: Go 1.12.1، CSI 1.1، CoreDNS 1.3.1، Docker 18.09 سپورٽ kubeadm ۾، ۽ گھٽ ۾ گھٽ سپورٽ Docker API ورزن ھاڻي 1.26 آھي.

پي ايس

اسان جي بلاگ تي پڻ پڙهو:

• «Kubernetes 1.13: مکيه جدت جو جائزو"؛
• «Kubernetes 1.12: مکيه جدت جو جائزو"؛
• «Kubernetes 1.11: مکيه جدت جو جائزو"؛
• «Kubernetes 1.10: مکيه جدت جو جائزو».

جو ذريعو: www.habr.com