نوټ. ژباړه: دا مواد د تعلیمي پروژې څخه دي د یوې مشهورې پوښتنې ځواب دی کله چې د Kubernetes پر بنسټ زیربنا ډیزاین کول. موږ امید لرو چې د هر اختیار د ګټو او زیانونو په کافي اندازه توضیحات به تاسو سره ستاسو د پروژې لپاره غوره انتخاب کولو کې مرسته وکړي.
د تمديد؛ DR: د کاري بارونو ورته سیټ په څو لوی کلسترونو کې پرمخ وړل کیدی شي (هر کلستر به د کار بارونو لوی شمیر ولري) یا په ډیری کوچنیو (په هر کلستر کې د لږ شمیر بارونو سره).
لاندې یو جدول دی چې د هرې تګلارې ګټې او زیانونه ارزوي:
کله چې د کوبرنیټس د چلولو غوښتنلیکونو لپاره د پلیټ فارم په توګه کاروئ، ډیری اساسي پوښتنې اکثرا د کلسترونو د تنظیم کولو پیچلتیاو په اړه راپورته کیږي:
- څو کلسترونه باید وکاروم؟
- زه باید دوی څومره لوی کړم؟
- په هر کلستر کې باید څه شی شامل وي؟
په دې مقاله کې، زه به هڅه وکړم چې د هرې تګلارې ګټې او زیانونه تحلیل کولو سره دې ټولو پوښتنو ته ځواب ووایم.
د یوې پوښتنې بیان
د سافټویر جوړونکي په توګه، تاسو احتمال لرئ په ورته وخت کې ډیری غوښتنلیکونه جوړ او چل کړئ.
برسېره پردې، د دې غوښتنلیکونو ډیری مثالونه احتمال لري چې په مختلفو چاپیریالونو کې وګرځي - د بیلګې په توګه، دا ممکن وي dev, ازموینه и پروډ.
پایله د غوښتنلیکونو او چاپیریالونو بشپړ میټریکس دی:
غوښتنلیکونه او چاپیریال
پورته مثال د 3 غوښتنلیکونو او 3 چاپیریالونو استازیتوب کوي، په پایله کې ټول 9 ممکنه اختیارونه.
د غوښتنلیک هره بیلګه د ځان ځای پرځای کولو واحد دی چې د نورو څخه په خپلواکه توګه کار کیدی شي.
هغه یاداښت کړه د غوښتنلیک بیلګه کیدای شي ډیری څخه جوړ وي برخېلکه فرنټ اینڈ، بیک اینډ، ډیټابیس، او داسې نور. د مایکرو خدماتو غوښتنلیک په قضیه کې، مثال به ټول مایکرو خدمتونه شامل وي.
د پایلې په توګه، د Kubernetes کاروونکي ډیری پوښتنې لري:
- ایا ټول غوښتنلیکونه باید په یوه کلستر کې ځای په ځای شي؟
- ایا دا د هرې غوښتنلیک مثال لپاره د جلا کلستر درلودل ارزښت لري؟
- یا شاید د پورته تګلارو ترکیب باید وکارول شي؟
دا ټول اختیارونه خورا د اعتبار وړ دي، ځکه چې Kubernetes یو انعطاف وړ سیسټم دی چې د کارونکي وړتیاوې نه محدودوي.
دلته ځینې ممکنه لارې دي:
- یو لوی عام کلستر؛
- ډیری کوچني خورا ځانګړي کلسترونه؛
- په هر غوښتنلیک کې یو کلستر؛
- په هر چاپیریال کې یو کلستر.
لکه څنګه چې لاندې ښودل شوي، لومړۍ دوه طریقې د اختیارونو د اندازې په مقابل کې دي:
له څو لویو کلسترونو (کیڼ اړخ) څخه ډیری کوچني (ښي) ته
په عموم کې، یو کلستر د بل په پرتله "لوی" ګڼل کیږي که چیرې دا د نوډونو او پوډونو لوی مقدار ولري. د مثال په توګه، د 10 نوډونو او 100 پوډونو سره کلستر د 1 نوډ او 10 پوډونو سره د کلستر څخه لوی دی.
ښه، راځئ چې پیل وکړو!
1. یو لوی عام کلستر
لومړی اختیار دا دی چې ټول کاري بارونه په یوه کلستر کې ځای په ځای کړئ:
یو لوی کلستر
د دې طریقې دننه، کلستر د نړیوال په توګه کارول کیږي زیربنا پلیټ فارم - تاسو په ساده ډول هر هغه څه ځای په ځای کړئ چې تاسو ورته اړتیا لرئ په موجوده کوبرنیټس کلستر کې.
Kubernetes د کلستر برخې ته اجازه ورکوي چې په منطقي توګه له یو بل څخه جلا شي، نو د هر غوښتنلیک مثال کولی شي خپل نوم ځای ولري.
راځئ چې د دې طریقې ګټې او زیانونه وګورو.
+ د سرچینو مؤثره کارول
د یو واحد کلستر سره، تاسو یوازې د ټولو سرچینو یوه کاپي ته اړتیا لرئ چې د Kubernetes کلستر چلولو او اداره کولو لپاره اړین دي.
د مثال په توګه، دا د ماسټر نوډونو لپاره ریښتیا ده. په عموم ډول، هر Kubernetes کلستر 3 ماسټر نوډونه لري، نو د یو واحد کلستر لپاره به د دوی شمیره همداسې پاتې وي (د پرتله کولو لپاره، 10 کلسترونه به 30 ماسټر نوډونو ته اړتیا ولري).
پورتني لنډیز په نورو خدماتو باندې هم پلي کیږي چې په ټول کلستر کې فعالیت کوي ، لکه د بار توازن کونکي ، د ننوتلو کنټرولرونه ، تصدیق کول ، د ننوتلو او څارنې سیسټمونه.
په یوه کلستر کې، دا ټول خدمتونه په یوځل کې د ټولو کاري بارونو لپاره کارول کیدی شي (د دوی کاپي جوړولو ته اړتیا نشته، لکه څنګه چې د ډیری کلسترونو قضیه ده).
+ ارزانه
د پورته پایلو په پایله کې، لږ کلسترونه معمولا ارزانه دي ځکه چې د سر لګښتونه شتون نلري.
دا په ځانګړې توګه د ماسټر نوډونو لپاره ریښتیا ده، کوم چې کولی شي د پام وړ پیسې مصرف کړي پرته له دې چې دوی څنګه کوربه شوي وي (په ودانۍ یا بادل کې).
ځینې منظم شوي Kubernetes خدمتونه، لکه او یا ، د کنټرول پرت وړیا چمتو کړئ. په دې حالت کې، د لګښت مسله کمه ده.
داسې اداره شوي خدمتونه هم شتون لري چې د هر Kubernetes کلستر د عملیاتو لپاره یو ثابت فیس اخلي (د مثال په توګه، ).
+ موثره اداره
د یو کلستر اداره کول د څو اداره کولو په پرتله اسانه دي.
اداره کېدای شي لاندې دندې ولري:
- د Kubernetes نسخه تازه کول؛
- د CI/CD پایپ لاین جوړول؛
- د CNI پلگ ان نصب کول؛
- د کارونکي تصدیق سیسټم تنظیم کول؛
- د لاسرسي کنټرولر نصب کول؛
او ډیری نور…
د یو کلستر په حالت کې، تاسو باید دا ټول یوازې یو ځل ترسره کړئ.
د ډیری کلسترونو لپاره، عملیات باید څو ځله تکرار شي، کوم چې احتمال به د پروسې او وسیلو ځینې اتوماتیک ته اړتیا ولري ترڅو په پروسه کې ثبات او ثبات یقیني کړي.
او اوس د تاوان په اړه یو څو خبرې.
- د ناکامۍ یو ټکی
د انکار په صورت کې یوازینی یو کلستر به سمدلاسه کار ودروي ټول کاري بارونه!
ډیری لارې شتون لري چې شیان غلط کیدی شي:
- د Kubernetes تازه کول د غیر متوقع اړخیزو اغیزو لامل کیږي؛
- د کلستر پراخه برخه (د مثال په توګه، د CNI پلگ ان) د توقع سره سم کار نه کوي؛
- د کلستر برخو څخه یو په سمه توګه نه دی ترتیب شوی؛
- په زیربناوو کې ناکامي.
یوه ورته پیښه کولی شي په ګډ کلستر کې کوربه شوي ټولو کاري بارونو ته جدي زیان ورسوي.
- هیڅ سخت موصلیت نشته
په ګډ کلستر کې چلول پدې معنی دي چې غوښتنلیکونه په کلستر نوډونو کې هارډویر، د شبکې وړتیاوې، او عملیاتي سیسټم شریکوي.
په یو معنی ، دوه کانټینرونه چې دوه مختلف غوښتنلیکونه په ورته نوډ کې روان دي د دوه پروسې په څیر دي چې په ورته ماشین کې د ورته OS کارنل چلوي.
د لینکس کانټینرونه یو څه انزوا چمتو کوي ، مګر دا نږدې دومره قوي ندي لکه څنګه چې د مجازی ماشینونو لخوا چمتو شوي. په اصل کې، په کانټینر کې یوه پروسه ورته پروسه ده چې د کوربه عملیاتي سیسټم پرمخ ځي.
دا یو امنیتي مسله کیدی شي: دا ترتیب په تیوریکي توګه غیر اړونده غوښتنلیکونو ته اجازه ورکوي چې له یو بل سره اړیکه ونیسي (یا په قصدي یا تصادفي توګه).
برسیره پردې، د Kubernetes په کلستر کې ټول کاري بار ځینې کلستر پراخه خدمات شریکوي لکه - دا غوښتنلیکونو ته اجازه ورکوي چې په کلستر کې د نورو غوښتنلیکونو خدمات ومومي.
ټول پورتني ټکي ممکن د غوښتنلیک امنیت اړتیاو پورې اړوند مختلف معنی ولري.
Kubernetes د امنیتي مسلو د مخنیوي لپاره مختلف وسایل چمتو کوي لکه и . په هرصورت، د دوی په سمه توګه تنظیم کول ځینې تجربې ته اړتیا لري؛ سربیره پردې، دوی نشي کولی په بشپړ ډول ټول امنیتي سوراخونه وتړي.
دا مهمه ده چې تل په یاد ولرئ چې Kubernetes په اصل کې د دې لپاره ډیزاین شوی و شریکوللپاره نه انزوا او خوندیتوب.
- د سخت څو کرایه کولو نشتوالی
د Kubernetes په کلستر کې د ګډو سرچینو کثرت ته په پام سره، ډیری لارې شتون لري چې مختلف غوښتنلیکونه کولی شي د یو بل په ګوتو کې ګام پورته کړي.
د مثال په توګه، یو غوښتنلیک ممکن شریکې سرچینې انحصار کړي (لکه CPU یا حافظه) او نور غوښتنلیکونه رد کړي چې ورته ورته نوډ لاسرسي کې روان وي.
Kubernetes د دې چلند کنټرول لپاره مختلف میکانیزمونه وړاندې کوي، لکه (مقاله هم وګورئ""- نږدې ژباړه.), и . په هرصورت، لکه څنګه چې د امنیت په حالت کې، د دوی ترتیب خورا غیر معمولی دی او دوی نشي کولی په بشپړ ډول د ټولو غیر متوقع اړخیزو اغیزو مخه ونیسي.
- د کاروونکو لوی شمیر
د یو واحد کلستر په حالت کې، تاسو باید ډیری خلکو ته لاسرسی خلاص کړئ. او هرڅومره چې د دوی شمیر ډیر وي ، هغومره لوړ خطر چې دوی به یو څه "مات کړي".
په کلستر کې تاسو کولی شئ کنټرول کړئ چې څوک کولی شي څه وکړي (مقاله وګورئ""- نږدې ژباړه.). په هرصورت، دا به کاروونکو ته د دوی د مسؤلیت ساحې په حدودو کې د یو څه "ماتولو" مخه ونه نیسي.
- کلسترونه په نامعلوم وخت کې وده نشي کولی
هغه کلستر چې د ټولو کاري بارونو لپاره کارول کیږي احتمال به خورا لوی وي (د نوډونو او پوډونو شمیر له مخې).
مګر دلته بله ستونزه رامینځته کیږي: په کبرنیټس کې کلسترونه په غیر مستقیم ډول وده نشي کولی.
د کلستر اندازې په اړه نظریاتي حد شتون لري. په Kubernetes کې دا تقریبا دی .
په هرصورت، په ریښتینې ژوند کې، ستونزې خورا دمخه پیل کیدی شي - د بیلګې په توګه، یوازې سره .
حقیقت دا دی چې لوی کلسترونه د Kubernetes کنټرول پرت کې لوړ بار ځای په ځای کوي. په بل عبارت، د کلستر ساتل او په اغیزمنه توګه چلول د احتیاط سره سمون ته اړتیا لري.
دا مسله په اصلي بلاګ کې په یوه اړونده مقاله کې سپړل شوې چې نومیږي "".
مګر راځئ چې مخالف چلند ته پام وکړو: ډیری کوچني کلسترونه.
2. ډیری کوچني، ځانګړي کلسترونه
د دې طریقې سره، تاسو د هر عنصر لپاره جلا کلستر کاروئ چې تاسو یې ځای په ځای کوئ:
ډیری کوچني کلسترونه
د دې مقالې د موخو لپاره، لاندې د لګولو وړ عنصر د غوښتنلیک مثال ته اشاره کوي - د بیلګې په توګه، د جلا غوښتنلیک یوه dev نسخه.
دا تګلاره Kubernetes د تخصص په توګه کاروي منډې وخت د انفرادي غوښتنلیک مثالونو لپاره.
راځئ چې د دې طریقې ګټې او زیانونه وګورو.
+ محدود "د چاودنې وړانګې"
کله چې یو کلستر ناکام شي، منفي پایلې یوازې د هغو کاري بارونو پورې محدودې دي چې په دې کلستر کې ځای پرځای شوي. نور ټول د کار بارونه ناڅاپه پاتې دي.
+ موصلیت
په انفرادي کلسترونو کې کوربه شوي کاري بار سرچینې نه شریکوي لکه پروسیسر، حافظه، عملیاتي سیسټم، شبکه، یا نور خدمتونه.
پایله د غیر اړونده غوښتنلیکونو ترمینځ سخت انزوا ده ، کوم چې د دوی امنیت لپاره ګټور کیدی شي.
+ د کاروونکو لږ شمیر
د دې په پام کې نیولو سره چې هر کلستر یوازې د کار بارونو محدود سیټ لري، د کاروونکو شمیر چې ورته لاسرسی لري کم شوی.
هرڅومره چې لږ خلک کلستر ته لاس رسی ولري، د خطر کم دی چې یو څه به "مات شي".
راځئ چې زیانونه وګورو.
– د منابعو بې کفایته استعمال
لکه څنګه چې مخکې یادونه وشوه، هر Kubernetes کلستر د مدیریت سرچینو ځانګړي سیټ ته اړتیا لري: ماسټر نوډونه، د کنټرول پرت برخې، نظارت او د ننوتلو حلونه.
د ډیری کوچنیو کلسترونو په صورت کې، د سرچینو لویه برخه باید مدیریت ته ځانګړې شي.
- ګرانه
د منابعو بې کفایته کارول په اتوماتيک ډول لوړ لګښتونه اړوي.
د مثال په توګه، د ورته کمپیوټري ځواک سره د دریو پرځای د 30 ماسټر نوډونو ساتل به لازمي لګښتونه اغیزمن کړي.
- په اداره کې ستونزې
د ډیری Kubernetes کلسترونو اداره کول یوازې د یو اداره کولو په پرتله خورا ستونزمن دي.
د مثال په توګه، تاسو باید د هر کلستر لپاره تصدیق او تایید تنظیم کړئ. د Kubernetes نسخه به هم څو ځله تازه شي.
تاسو به احتمالا د دې ټولو دندو د لا اغیزمن کولو لپاره اتومات کارولو ته اړتیا ولرئ.
اوس راځئ چې لږ سخت سناریو وګورو.
3. په هر غوښتنلیک کې یو کلستر
پدې طریقه کې، تاسو د یو ځانګړي غوښتنلیک ټولو مثالونو لپاره جلا کلستر جوړ کړئ:
د هر غوښتنلیک کلستر
دا لاره د اصولو د عمومي کولو په توګه ګڼل کیدی شي "په هر ټیم کې جلا کلستر، ځکه چې معمولا د انجینرانو ټیم یو یا څو غوښتنلیکونه رامینځته کوي.
راځئ چې د دې طریقې ګټې او زیانونه وګورو.
+ کلستر په غوښتنلیک کې تنظیم کیدی شي
که یو غوښتنلیک ځانګړي اړتیاوې ولري، دوی په کلستر کې پلي کیدی شي پرته له دې چې نورو کلسترونو اغیزه وکړي.
پدې اړتیاو کې ممکن د GPU کارمندان ، د CNI ځینې ځانګړي پلگ انونه ، د خدماتو میش ، یا ځینې نور خدمتونه شامل وي.
هر کلستر کولی شي د هغه غوښتنلیک سره سمون ولري چې په دې کې روان دي نو دا یوازې هغه څه لري چې ورته اړتیا وي.
- په یوه کلستر کې مختلف چاپیریال
د دې تګلارې نیمګړتیا دا ده چې د مختلف چاپیریال څخه د غوښتنلیک مثالونه په ورته کلستر کې یوځای شتون لري.
د مثال په توګه، د غوښتنلیک پروډ نسخه په ورته کلستر کې د dev نسخه په څیر پرمخ ځي. دا پدې معنی هم ده چې پراختیا کونکي په ورته کلستر کې کار کوي په کوم کې چې د غوښتنلیک تولید نسخه چلیږي.
که ، په dev نسخه کې د پراختیا کونکو کړنو یا خرابیو له امله ، په کلستر کې ناکامي رامینځته کیږي ، نو د پروډ نسخه په احتمالي توګه هم زیانمن کیدی شي - د دې چلند لوی نیمګړتیا.
او په نهایت کې ، زموږ په لیست کې وروستۍ سناریو.
4. په هر چاپیریال کې یو کلستر
پدې سناریو کې د هر چاپیریال لپاره د جلا کلستر تخصیص شامل دی:
په هر چاپیریال کې یو کلستر
د مثال په توګه، تاسو ممکن کلسترونه ولرئ dev, ازموینه и پروډ، په کوم کې چې تاسو به د ځانګړي چاپیریال لپاره وقف شوي غوښتنلیک ټولې بیلګې پرمخ وړئ.
دلته د دې طریقې ګټې او زیانونه دي.
+ د تولید چاپیریال جلا کول
د دې طریقې دننه، ټول چاپیریال له یو بل څخه جلا کیږي. په هرصورت، په عمل کې دا په ځانګړي ډول د تولید چاپیریال کې مهم دی.
د غوښتنلیک تولید نسخې اوس د هغه څه څخه خپلواک دي چې په نورو کلسترونو او چاپیریالونو کې پیښیږي.
پدې توګه ، که چیرې ناڅاپه ستونزه په dev کلستر کې رامینځته شي ، نو د غوښتنلیکونو پروډ نسخې به کار ته دوام ورکړي لکه څنګه چې هیڅ پیښ شوي ندي.
+ کلستر چاپیریال ته تنظیم کیدی شي
هر کلستر د خپل چاپیریال سره سمون کیدی شي. د مثال په توګه، تاسو کولی شئ:
- په dev کلستر کې د پراختیا او ډیبګ کولو لپاره وسیلې نصب کړئ؛
- په کلستر کې د ازموینې چوکاټونه او اوزار نصب کړئ ازموینه;
- په کلستر کې ډیر پیاوړي هارډویر او شبکې چینلونه وکاروئ پروډ.
دا تاسو ته اجازه درکوي چې د غوښتنلیک پراختیا او عملیات دواړه موثریت زیات کړي.
+ د تولید کلستر ته د لاسرسي محدودیت
د پروډ کلستر سره مستقیم کار کولو اړتیا په ندرت سره راپورته کیږي ، نو تاسو کولی شئ د پام وړ د خلکو حلقه محدود کړئ څوک چې دې ته لاسرسی لري.
تاسو کولی شئ نور هم لاړ شئ او په بشپړ ډول دې کلستر ته د خلکو لاسرسی رد کړئ، او د اتوماتیک CI/CD وسیلې په کارولو سره ټولې ګمارنې ترسره کړئ. دا ډول چلند به د انساني غلطیو خطر په دقیق ډول کم کړي چیرې چې دا خورا اړونده وي.
او اوس د تاوان په اړه یو څو خبرې.
- د غوښتنلیکونو تر مینځ هیڅ انزوا نشته
د کړنلارې اصلي زیان د غوښتنلیکونو تر مینځ د هارډویر او سرچینو انزوا نشتوالی دی.
غیر اړونده غوښتنلیکونه د کلستر سرچینې شریکوي: د سیسټم کور، پروسیسر، حافظه، او ځینې نور خدمتونه.
لکه څنګه چې یادونه وشوه، دا ممکن خطرناک وي.
- د غوښتنلیک انحصاراتو ځایی کولو کې پاتې راتلل
که یو غوښتنلیک ځانګړي اړتیاوې ولري، نو دوی باید په ټولو کلسترونو کې مطمین وي.
د مثال په توګه، که یو غوښتنلیک GPU ته اړتیا ولري، نو هر کلستر باید لږترلږه یو کارګر د GPU سره ولري (حتی که دا یوازې د هغه غوښتنلیک لخوا کارول کیږي).
د پایلې په توګه، موږ د لوړ لګښتونو او د سرچینو غیر موثر کارونې خطر سره مخ یو.
پایلې
که تاسو د غوښتنلیکونو ځانګړی سیټ لرئ، دوی کولی شي په ډیری لوی کلسترونو یا ډیری کوچنیو کې ځای پرځای شي.
مقاله د مختلفو طریقو د ګټو او زیانونو په اړه بحث کوي، د یو نړیوال کلستر څخه تر څو کوچنیو او خورا متخصصینو پورې:
- یو لوی عمومي کلستر؛
- ډیری کوچني خورا ځانګړي کلسترونه؛
- په هر غوښتنلیک کې یو کلستر؛
- په هر چاپیریال کې یو کلستر.
نو تاسو باید کومه لاره غوره کړئ؟
د تل په څیر، ځواب د کارونې قضیې پورې اړه لري: تاسو اړتیا لرئ چې د مختلفو طریقو ګټې او زیانونه وزن کړئ او ترټولو غوره انتخاب غوره کړئ.
په هرصورت، انتخاب پورته مثالونو پورې محدود ندی - تاسو کولی شئ د دوی هر ډول ترکیب وکاروئ!
د مثال په توګه، تاسو کولی شئ د هر ټیم لپاره یو څو کلسترونه تنظیم کړئ: یو پرمختیایي کلستر (په کوم کې به چاپیریال وي dev и ازموینه) او کلستر لپاره تولید (چیرې چې د تولید چاپیریال به موقعیت ولري).
پدې مقاله کې د معلوماتو پراساس ، تاسو کولی شئ د یوې ځانګړې سناریو لپاره د هغې مطابق ګټې او زیانونه غوره کړئ. غوره چانس!
PS
زموږ په بلاګ کې هم ولولئ:
- «»
- «»
- «»
- «".
سرچینه: www.habr.com