ڪيترن ئي ماڻهن کي يقين آهي ته اهو ڪافي آهي ايپليڪيشن کي ڪبرنيٽس ڏانهن منتقل ڪرڻ (يا ته هيلم استعمال ڪندي يا دستي طور تي) ۽ اهي خوش ٿيندا. پر اهو ايترو سادو ناهي.
ٽيم DevOps انجنيئر جولين گنڊي پاران هڪ مضمون ترجمو ڪيو. هو شيئر ڪري ٿو ته هن جي ڪمپني کي لڏپلاڻ جي عمل دوران ڪهڙا نقصان ٿيا ته جيئن توهان ساڳئي ريڪ تي قدم نه رکو.
قدم هڪ: سيٽنگ اپ پوڊ درخواستون ۽ حدون
اچو ته هڪ صاف ماحول قائم ڪندي شروع ڪريون جنهن ۾ اسان جا پوڊ هلندا. ڪبرنيٽس پوڊ کي شيڊول ڪرڻ ۽ ناڪامي جي حالتن کي سنڀالڻ جو وڏو ڪم ڪري ٿو. پر اهو ظاهر ٿيو ته شيڊيولر ڪڏهن ڪڏهن پوڊ نٿو رکي سگهي جيڪڏهن اهو اندازو لڳائڻ مشڪل آهي ته ان کي ڪاميابيءَ سان ڪم ڪرڻ لاءِ ڪيترا وسيلا گهربل آهن. هي اهو آهي جتي وسيلن ۽ حدن لاء درخواستون اچن ٿيون. درخواستن ۽ حدن کي ترتيب ڏيڻ لاء بهترين طريقي جي باري ۾ تمام گهڻو بحث آهي. ڪڏهن ڪڏهن اهو محسوس ٿئي ٿو ته اهو سائنس کان وڌيڪ فن آهي. هتي اسان جو طريقو آهي.
پوڊ درخواستون - هي بنيادي قيمت آهي جيڪو شيڊولر طرفان استعمال ڪيو ويو آهي پوڊ کي بهتر طور تي رکڻ لاءِ.
کان : فلٽرنگ قدم نوڊس جي سيٽ کي طئي ڪري ٿو جتي پوڊ شيڊول ڪري سگهجي ٿو. مثال طور، PodFitsResources فلٽر چيڪ ڪري ٿو ته ڇا هڪ نوڊ وٽ ڪافي وسيلا آهن پوڊ جي مخصوص وسيلن جي درخواستن کي پورو ڪرڻ لاءِ.
اسان ايپليڪيشن جي درخواستن کي استعمال ڪندا آهيون ته جيئن اهي اندازو لڳائي سگهجن ته ڪيترا وسيلا آهن حقيقت ۾ اپليڪيشن ان کي صحيح ڪم ڪرڻ جي ضرورت آهي. هن طريقي سان شيڊولر نوڊس کي حقيقي طور تي رکي سگهي ٿو. اسان شروعاتي طور تي مارجن سان درخواستون مقرر ڪرڻ چاھيون ھيون ته يقيني بڻائڻ لاءِ ته ھر پوڊ وٽ ڪافي تعداد ۾ وسيلا آھن، پر اسان ڏٺو ته شيڊيولنگ جا وقت خاصا وڌي ويا ۽ ڪجھ پوڊ مڪمل طور تي شيڊول نه ٿيا، ڄڻ انھن لاءِ وسيلن جي ڪا به درخواست نه ملي ھئي.
انهي صورت ۾، شيڊولر اڪثر ڪري پوڊ کي ٻاهر ڪڍندو هو ۽ انهن کي ٻيهر شيڊول ڪرڻ جي قابل نه هوندو آهي ڇاڪاڻ ته ڪنٽرول جهاز کي خبر ناهي ته ايپليڪيشن کي ڪيترا وسيلن جي ضرورت هوندي، شيڊولنگ الگورتھم جو هڪ اهم حصو.
پوڊ جي حد - هي پوڊ لاء هڪ واضح حد آهي. اهو وسيلن جي وڌ ۾ وڌ مقدار جي نمائندگي ڪري ٿو جيڪو ڪلستر ڪنٽينر کي مختص ڪندو.
ٻيهر، کان : جيڪڏهن هڪ ڪنٽينر ۾ 4 GiB ميموري جي حد مقرر ڪئي وئي آهي، ته ڪوبيليٽ (۽ ڪنٽينر جو رن ٽائم) ان کي لاڳو ڪندو. رن ٽائيم ڪنٽينر کي مخصوص وسيلن جي حد کان وڌيڪ استعمال ڪرڻ جي اجازت نٿو ڏئي. مثال طور، جڏهن هڪ ڪنٽينر ۾ هڪ عمل ميموري جي اجازت ڏنل مقدار کان وڌيڪ استعمال ڪرڻ جي ڪوشش ڪري ٿو، سسٽم ڪنييل پروسيس کي "آئوٽ آف ميموري" (OOM) غلطي سان ختم ڪري ٿو.
هڪ ڪنٽينر هميشه وسيلن جي درخواست ۾ بيان ڪيل کان وڌيڪ وسيلا استعمال ڪري سگهي ٿو، پر ڪڏهن به حد ۾ بيان ڪيل کان وڌيڪ استعمال نٿو ڪري سگهي. اهو قدر صحيح طور تي مقرر ڪرڻ ڏکيو آهي، پر اهو تمام ضروري آهي.
مثالي طور تي، اسان چاهيون ٿا ته هڪ پوڊ جي وسيلن جي گهرج کي تبديل ڪرڻ جي عمل جي زندگي جي چڪر تي بغير سسٽم ۾ ٻين عملن سان مداخلت ڪرڻ جي - اهو مقصد آهي حد مقرر ڪرڻ جو.
بدقسمتي سان، مان خاص هدايتون نه ٿو ڏئي سگهان ته ڪهڙا قدر مقرر ڪيا وڃن، پر اسان پاڻ هيٺ ڏنل قاعدن تي عمل ڪندا آهيون:
- لوڊ ٽيسٽنگ ٽول استعمال ڪندي، اسان ٽريفڪ جي بيس لائين ليول کي نقل ڪريون ٿا ۽ پوڊ وسيلن جي استعمال جي نگراني ڪريون ٿا (ميموري ۽ پروسيسر).
- اسان پوڊ جي درخواستن کي بي ترتيبي طور تي گھٽ قيمت تي مقرر ڪيو (تقريبن 5 ڀيرا درخواستن جي قيمت جي وسيلن جي حد سان) ۽ مشاهدو ڪيو. جڏهن درخواستون تمام گهٽ هونديون آهن، اهو عمل شروع نٿو ڪري سگهي، اڪثر ڪري پراسرار Go رن ٽائيم غلطيون پيدا ڪري ٿي.
نوٽ ڪريو ته اعلي وسيلن جي حدون شيڊولنگ کي وڌيڪ ڏکيو بڻائي ٿو ڇو ته پوڊ کي ڪافي وسيلن سان گڏ ٽارگيٽ نوڊ جي ضرورت آهي.
هڪ اهڙي صورتحال جو تصور ڪريو جتي توهان وٽ هڪ ٿلهي وزن وارو ويب سرور آهي تمام گهڻي وسيلن جي حد سان، چئو 4 GB ياداشت. اهو عمل امڪاني طور تي افقي طور تي ماپ ڪرڻو پوندو، ۽ هر نئين ماڊل کي گهٽ ۾ گهٽ 4 GB موجود ميموري سان نوڊ تي شيڊول ڪرڻو پوندو. جيڪڏهن ڪو به اهڙو نوڊ موجود نه آهي، ته ڪلستر کي ان پوڊ کي پروسيس ڪرڻ لاءِ هڪ نئون نوڊ متعارف ڪرائڻ گهرجي، جنهن ۾ ڪجهه وقت لڳي سگهي ٿو. اهو ضروري آهي ته وسيلن جي درخواستن ۽ حدن جي وچ ۾ فرق کي گهٽ ۾ گهٽ رکڻ لاء تيز ۽ هموار اسڪيلنگ کي يقيني بڻائڻ لاء.
قدم ٻه: ترتيب ڏيڻ Liveness ۽ تيارگي جا امتحان
هي هڪ ٻيو ذيلي موضوع آهي جيڪو اڪثر ڪبرنيٽس ڪميونٽي ۾ بحث ڪيو ويندو آهي. اهو ضروري آهي ته زندگي ۽ تياري جي ٽيسٽن جي سٺي سمجھ هجي جيئن اهي سافٽ ويئر لاءِ هڪ ميکانيزم مهيا ڪن ٿا ته جيئن آسانيءَ سان هلن ۽ وقت کي گھٽ ڪري. بهرحال، اهي توهان جي ايپليڪيشن کي هڪ سنگين ڪارڪردگي هٽائي سگهن ٿا جيڪڏهن صحيح ترتيب نه ڏني وئي آهي. هيٺ ڏنل هڪ خلاصو آهي ته ٻنهي نمونن وانگر آهن.
حياتي ڏيڻ ڏيکاري ٿو ته ڇا ڪنٽينر هلي رهيو آهي. جيڪڏهن اهو ناڪام ٿئي ٿو، ڪوبلٽ ڪنٽينر کي ماريندو آهي ۽ ان لاءِ ٻيهر شروع ڪرڻ واري پاليسي فعال ڪئي وئي آهي. جيڪڏهن ڪنٽينر هڪ Liveness تحقيق سان ليس نه آهي، ته پوء ڊفالٽ رياست ڪامياب ٿي ويندي - هي اهو آهي جيڪو ان ۾ چوي ٿو .
حياتياتي جاچ سستا هجڻ گهرجي، مطلب ته انهن کي تمام گهڻا وسيلا استعمال نه ڪرڻ گهرجن، ڇاڪاڻ ته اهي اڪثر هلن ٿا ۽ ڪبرنيٽس کي اطلاع ڏيڻ جي ضرورت آهي ته ايپليڪيشن هلي رهي آهي.
جيڪڏهن توهان هر سيڪنڊ کي هلائڻ جو اختيار مقرر ڪيو، اهو شامل ڪندو 1 درخواست في سيڪنڊ، تنهنڪري هوشيار رهو ته اضافي وسيلن جي ضرورت پوندي هن ٽرئفڪ کي سنڀالڻ لاءِ.
اسان جي ڪمپني ۾، Liveness ٽيسٽون هڪ ايپليڪيشن جي بنيادي حصن جي جانچ ڪن ٿيون، جيتوڻيڪ ڊيٽا (مثال طور، ريموٽ ڊيٽابيس يا ڪيش مان) مڪمل طور تي رسائي لائق نه آهي.
اسان ايپس کي "صحت" جي آخري پوائنٽ سان ترتيب ڏنو آهي جيڪو صرف 200 جو جوابي ڪوڊ ڏئي ٿو. اهو هڪ اشارو آهي ته اهو عمل هلي رهيو آهي ۽ درخواستن تي عمل ڪرڻ جي قابل آهي (پر اڃا تائين ٽرئفڪ نه آهي).
ڪوشش ڪر تيارگي ظاهر ڪري ٿو ته ڇا ڪنٽينر درخواستن جي خدمت ڪرڻ لاءِ تيار آهي. جيڪڏهن تياري جي جاچ ناڪام ٿئي ٿي، آخر پوائنٽ ڪنٽرولر پوڊ جي IP پتي کي هٽائي ٿو پوڊ سان لاڳاپيل سڀني خدمتن جي آخري پوائنٽن مان. اهو پڻ چيو ويو آهي Kubernetes دستاويزن ۾.
تياري جاچ وڌيڪ وسيلا استعمال ڪري ٿي ڇاڪاڻ ته انهن کي لازمي طور تي پس منظر ڏانهن موڪليو وڃي ٿو انهي طريقي سان جيڪو ظاهر ڪري ٿو ته درخواست درخواستن کي قبول ڪرڻ لاءِ تيار آهي.
ڪميونٽي ۾ تمام گهڻو بحث مباحثو آهي ته ڇا ڊيٽابيس تائين سڌو رسائي حاصل ڪجي. مٿي ڏنل (چڪون اڪثر ڪيون وينديون آهن، پر ترتيب ڏئي سگھجن ٿيون)، اسان فيصلو ڪيو ته ڪجهه ايپليڪيشنن لاءِ، ٽريفڪ جي خدمت ڪرڻ جي تياري صرف ان جي تصديق ڪرڻ کان پوءِ شمار ڪئي ويندي آهي ته رڪارڊ ڊيٽابيس مان واپس ڪيا ويا آهن. سٺي نموني تيار ڪيل آزمائشي دستيابي جي اعلي سطح کي يقيني بڻائي ۽ مقرري دوران ختم ٿيڻ جو وقت ختم ڪيو.
جيڪڏهن توهان فيصلو ڪيو ته ڊيٽابيس کان پڇا ڳاڇا ڪرڻ لاءِ توهان جي درخواست جي تيارگي کي جانچڻ لاءِ، پڪ ڪريو ته اهو ممڪن آهي جيترو سستو آهي. اچو ته هي درخواست وٺون:
SELECT small_item FROM table LIMIT 1هتي هڪ مثال آهي ته اسان ڪبرنيٽس ۾ انهن ٻن قدرن کي ڪيئن ترتيب ڏيون ٿا:
livenessProbe:
httpGet:
path: /api/liveness
port: http
readinessProbe:
httpGet:
path: /api/readiness
port: http periodSeconds: 2
توھان ڪجھ اضافي ترتيبن جا اختيار شامل ڪري سگھو ٿا:
initialDelaySeconds- ڪنٽينر جي لانچ ۽ نموني جي شروعات جي وچ ۾ ڪيترا سيڪنڊ گذري ويندا.periodSeconds- نموني جي وچ ۾ انتظار جو وقفو.timeoutSeconds- سيڪنڊن جو تعداد جنهن کان پوءِ يونٽ کي هنگامي سمجهيو ويندو آهي. باقاعده وقت ختم ٿيڻ.failureThreshold- ٻيهر شروع ڪرڻ واري سگنل کان اڳ ٽيسٽ ناڪامين جو تعداد پوڊ ڏانهن موڪليو ويو آهي.successThreshold- پوڊ تيار حالت ۾ وڃڻ کان اڳ ڪامياب جاچ جو تعداد (ناڪام ٿيڻ کان پوءِ، جڏهن پوڊ شروع ٿئي ٿو يا بحال ٿئي ٿو).
قدم ٽي: پوڊ لاءِ ڊفالٽ نيٽ ورڪ پاليسيون ترتيب ڏيڻ
ڪبرنيٽس وٽ ”فليٽ“ نيٽ ورڪ ٽوپوگرافي آهي؛ ڊفالٽ طور، سڀ پوڊ سڌو سنئون هڪ ٻئي سان رابطو ڪن ٿا. ڪجهه حالتن ۾ اهو گهربل نه آهي.
هڪ امڪاني سيڪيورٽي مسئلو اهو آهي ته هڪ حملو ڪندڙ نيٽ ورڪ تي سڀني پوڊس ڏانهن ٽرئفڪ موڪلڻ لاء هڪ واحد خطرناڪ ايپليڪيشن استعمال ڪري سگهي ٿو. جيئن سيڪيورٽي جي ڪيترن ئي علائقن سان، گهٽ ۾ گهٽ استحقاق جو اصول هتي لاڳو ٿئي ٿو. مثالي طور، نيٽ ورڪ پاليسين کي واضح طور تي بيان ڪرڻ گهرجي ته پوڊ جي وچ ۾ ڪنيڪشن جي اجازت آهي ۽ ڪهڙي نه آهن.
مثال طور، هيٺ ڏنل هڪ سادي پاليسي آهي جيڪا هڪ مخصوص نالي جي جڳهه لاءِ ايندڙ ايندڙ ٽرئفڪ کي رد ڪري ٿي:
---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: default-deny-ingress
spec:
podSelector: {}
policyTypes:
- Ingress
ھن ٺاھ جوڙ جو تصور:
(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
وڌيڪ تفصيل .
مرحلا چار: ٿلهو ۽ شروعاتي ڪنٽينرز استعمال ڪندي حسب ضرورت رويي
اسان جي مکيه مقصدن مان هڪ هو ڊولپرز لاءِ بغير وقت جي ڪبرنيٽس کي ڊيپلائيمينٽ مهيا ڪرڻ. اهو ڏکيو آهي ڇاڪاڻ ته اتي ڪيترائي اختيار آهن ايپليڪيشنن کي بند ڪرڻ ۽ انهن جي استعمال ڪيل وسيلن کي آزاد ڪرڻ لاءِ.
سان خاص مشڪلاتون پيدا ٿيون . اسان محسوس ڪيو ته جڏهن اهي پوڊ ترتيب سان ترتيب ڏني وئي، فعال ڪنيڪشن ڪامياب مڪمل ٿيڻ کان اڳ ختم ٿي ويا.
آن لائين وسيع تحقيق کان پوء، اهو ظاهر ٿئي ٿو ته ڪبرنيٽس پوڊ کي ختم ڪرڻ کان پهريان پاڻ کي ختم ڪرڻ لاء نينگڪس ڪنيڪشن جو انتظار نٿو ڪري. پري-اسٽاپ ٿلهو استعمال ڪندي، اسان هيٺ ڏنل ڪارڪردگي تي عمل ڪيو ۽ مڪمل طور تي ختم ٿيڻ کان نجات حاصل ڪئي:
lifecycle:
preStop:
exec:
command: ["/usr/local/bin/nginx-killer.sh"]
پر nginx-killer.sh:
#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
echo "Waiting while shutting down nginx..."
sleep 10
done
ٻيو انتهائي مفيد نمونو آهي init ڪنٽينرز جو استعمال مخصوص ايپليڪيشنن جي شروعات کي سنڀالڻ لاءِ. اهو خاص طور تي ڪارائتو آهي جيڪڏهن توهان وٽ وسيلن جي گنجائش وارو ڊيٽابيس لڏپلاڻ وارو عمل آهي جنهن کي هلائڻ جي ضرورت آهي ايپليڪيشن شروع ٿيڻ کان اڳ. توھان پڻ وضاحت ڪري سگھوٿا ھڪڙي اعلي وسيلن جي حد ھن عمل لاءِ بغير ڪنھن حد مقرر ڪرڻ جي مکيه ايپليڪيشن لاءِ.
هڪ ٻيو عام اسڪيم آهي رازن تائين رسائي حاصل ڪرڻ هڪ init ڪنٽينر جيڪو اهي سندون مهيا ڪري ٿو مکيه ماڊل کي، جيڪو رازن تائين غير مجاز رسائي کي روڪي ٿو پاڻ کي مکيه ايپليڪيشن ماڊل مان.
هميشه وانگر، دستاويز مان اقتباس: Init ڪنٽينر محفوظ طور تي ڪسٽم ڪوڊ يا يوٽيلٽيز کي هلائيندا آهن جيڪي ٻي صورت ۾ ايپليڪيشن ڪنٽينر جي تصوير جي سيڪيورٽي کي گهٽائي ڇڏيندا. غير ضروري اوزارن کي الڳ رکڻ سان، توهان ايپليڪيشن ڪنٽينر جي تصوير جي حملي واري سطح کي محدود ڪريو ٿا.
قدم پنج: ڪنييل کي ترتيب ڏيڻ
آخرڪار، اچو ته هڪ وڌيڪ جديد ٽيڪنالاجي بابت ڳالهايون.
Kubernetes هڪ انتهائي لچڪدار پليٽ فارم آهي جيڪو توهان کي ڪم لوڊ هلائڻ جي اجازت ڏئي ٿو جيئن توهان مناسب ڏسندا آهيو. اسان وٽ ڪيتريون ئي اعليٰ ڪارڪردگي واريون ايپليڪيشنون آهن جيڪي انتهائي وسيلا آهن. وسيع لوڊ ٽيسٽ ڪرڻ کان پوءِ، اسان دريافت ڪيو ته هڪ ايپليڪيشن متوقع ٽرئفڪ لوڊ کي سنڀالڻ ۾ جدوجهد ڪري رهي هئي جڏهن Kubernetes جي ڊفالٽ سيٽنگون اثر ۾ هيون.
بهرحال، ڪبرنيٽس توهان کي اجازت ڏئي ٿو ته هڪ امتيازي ڪنٽينر کي هلائڻ لاءِ جيڪو صرف هڪ مخصوص پوڊ لاءِ ڪنيل پيٽرولر تبديل ڪري ٿو. ھتي اھو آھي جيڪو اسان وڌ ۾ وڌ کليل ڪنيڪشن کي تبديل ڪرڻ لاءِ استعمال ڪيو:
initContainers:
- name: sysctl
image: alpine:3.10
securityContext:
privileged: true
command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]
هي هڪ وڌيڪ ترقي يافته ٽيڪنڪ آهي جنهن جي اڪثر ضرورت نه آهي. پر جيڪڏهن توهان جي ايپليڪيشن ڳري لوڊ کي منهن ڏيڻ ۾ جدوجهد ڪري رهي آهي، توهان ڪوشش ڪري سگهو ٿا انهن مان ڪجهه سيٽنگن کي ٽائيڪ ڪرڻ جي. هن عمل تي وڌيڪ تفصيل ۽ مختلف قدرن کي ترتيب ڏيڻ - هميشه وانگر .
نتيجو
جڏهن ته ڪبرنيٽس شايد دٻي مان هڪ تيار ٿيل حل وانگر نظر اچن ٿا، اتي ڪجھ اهم قدم آهن جيڪي توهان کي کڻڻ جي ضرورت آهي توهان جي ايپليڪيشنن کي آسانيء سان هلائڻ لاء.
توهان جي Kubernetes جي لڏپلاڻ دوران، "لوڊ ٽيسٽنگ چڪر" جي پيروي ڪرڻ ضروري آهي: ايپليڪيشن لانچ ڪريو، ان کي لوڊ ڪريو، ان کي جانچيو، ميٽرڪس ۽ اسڪيلنگ رويي جو مشاهدو ڪريو، ان ڊيٽا جي بنياد تي ترتيب ترتيب ڏيو، پوءِ چڪر کي ٻيهر ورجايو.
توهان جي متوقع ٽرئفڪ جي باري ۾ حقيقت پسند ٿيو ۽ ان کان اڳتي وڌڻ جي ڪوشش ڪريو ته ڏسو ته ڪهڙا حصا پهرين ڀڃندا آهن. هن بار بار واري طريقي سان، صرف چند فهرست ڏنل سفارشون ڪاميابي حاصل ڪرڻ لاء ڪافي هوندا. يا شايد ان کي وڌيڪ گہرے حسب ضرورت جي ضرورت هجي.
هميشه پاڻ کان اهي سوال پڇو:
- ايپليڪيشنون ڪيترا وسيلا استعمال ڪن ٿيون ۽ اهو حجم ڪيئن بدلجي ويندو؟
- حقيقي اسڪيلنگ گهرجون ڇا آهن؟ ايپ اوسط تي ڪيتري ٽرئفڪ کي سنڀاليندي؟ چوٽي ٽرئفڪ بابت ڇا؟
- ڪيتري وقت خدمت کي افقي طور تي ماپڻ جي ضرورت پوندي؟ ٽريفڪ حاصل ڪرڻ لاءِ نوان پوڊ آن لائن آڻڻ جي ڪهڙي ضرورت آهي؟
- ڪئين صحيح طريقي سان پوڊس کي بند ڪيو وڃي؟ ڇا اهو سڀ ڪجهه ضروري آهي؟ ڇا اهو ممڪن آهي ته بغير وقت جي مقرري حاصل ڪرڻ؟
- توهان حفاظتي خطرن کي ڪيئن گھٽائي سگهو ٿا ۽ ڪنهن به سمجھوتي ٿيل پوڊ کان نقصان کي محدود ڪري سگهو ٿا؟ ڇا ڪنهن به خدمتن کي اجازت يا رسائي آهي جنهن جي انهن کي ضرورت ناهي؟
Kubernetes هڪ ناقابل اعتماد پليٽ فارم مهيا ڪري ٿو جيڪو توهان کي هڪ ڪلستر ۾ هزارين خدمتن کي ترتيب ڏيڻ لاء بهترين طريقا استعمال ڪرڻ جي اجازت ڏئي ٿو. بهرحال، هر ايپليڪيشن مختلف آهي. ڪڏهن ڪڏهن عمل درآمد ٿورو وڌيڪ ڪم جي ضرورت آهي.
خوشقسمتيء سان، Kubernetes سڀني ٽيڪنيڪل مقصدن حاصل ڪرڻ لاء ضروري تشڪيل مهيا ڪري ٿي. وسيلن جي درخواستن ۽ حدن جي ميلاپ کي استعمال ڪندي، جاندار ۽ تياري جي جاچ، شروعاتي ڪنٽينرز، نيٽ ورڪ پاليسين، ۽ ڪسٽم ڪرنل ٽيوننگ، توهان اعلي ڪارڪردگي حاصل ڪري سگهو ٿا غلطي رواداري ۽ تيز رفتار اسڪيبلٽي سان.
ٻيو ڇا پڙهو:
- .
- .
- .
جو ذريعو: www.habr.com