زما نوم ویکتور یاګوفروف دی، او زه په DomClick کې د کوبرنیټس پلیټ فارم ته د Ops (عملیات) ټیم کې د تخنیکي پراختیا مدیر په توګه وده ورکوم. زه غواړم زموږ د Dev <-> Ops پروسو جوړښت په اړه وغږیږم، په روسیه کې د یو ترټولو لوی k8s کلسترونو فعالیت کولو ځانګړتیاوې، او همدارنګه د DevOps/SRE کړنې چې زموږ ټیم پلي کوي.
د عملیاتو ټیم
د Ops ټیم اوس مهال 15 کسان لري. له دوی څخه درې یې د دفتر مسؤل دي، دوه په مختلف وخت زون کې کار کوي او د شپې په شمول شتون لري. پدې توګه ، د Ops څخه یو څوک تل په نظارت کې وي او د هرې پیچلتیا پیښې ته ځواب ویلو ته چمتو وي. موږ د شپې بدلونونه نلرو، کوم چې زموږ روحیه ساتي او هرچا ته دا فرصت ورکوي چې کافي خوب وکړي او نه یوازې په کمپیوټر کې د تفریح وخت تیر کړي.
هرڅوک مختلف وړتیاوې لري: شبکه کونکي، DBAs، د ELK سټیک متخصصین، د کوبرنیټس مدیران / پراختیا کونکي، څارنه، مجازی کول، د هارډویر متخصصین، او نور. یو شی هرڅوک متحد کوي - هرڅوک کولی شي یو څه زموږ څخه هر یو ځای په ځای کړي: د بیلګې په توګه، د k8s کلستر کې نوي نوډونه معرفي کړئ، PostgreSQL تازه کړئ، د CI/CD + ځواب وړ پایپ لاین ولیکئ، په Python/Bash/Go کې یو څه اتومات کړئ، هارډویر سره وصل کړئ. د معلوماتو مرکز. په هره برخه کې قوي وړتیا ستاسو د فعالیت سمت بدلولو او په نورو برخو کې د پرمختګ پیل کولو مخه نه نیسي. د مثال په توګه، زه د PostgreSQL متخصص په توګه یو شرکت سره یوځای شوم، او اوس زما د مسؤلیت اصلي ساحه د Kubernetes کلسترونه دي. په ټیم کې، هر ډول لوړوالی ښه راغلاست دی او د ګټې اخیستنې احساس خورا پرمختللی دی.
په لاره کې، موږ ښکار کوو. د کاندیدانو اړتیاوې خورا معیاري دي. زما لپاره په شخصي توګه، دا مهمه ده چې یو شخص په ټیم کې ځای ونیسي، غیر منازعې وي، مګر په دې هم پوهیږي چې څنګه د خپل نظر دفاع وکړي، وده کول غواړي او د نوي کولو څخه ویره نلري، خپل نظرونه وړاندې کوي. همچنان ، د سکریپټینګ ژبو کې د برنامې مهارتونه ، د لینکس او انګلیسي اساساتو پوهه اړینه ده. انګلیسي ساده ته اړتیا لري ترڅو یو څوک د فاکیپ په صورت کې ګوګل کولی شي په 10 ثانیو کې د ستونزې حل حل کړي ، نه په 10 دقیقو کې. اوس د لینوکس ژوره پوهه لرونکي متخصصین موندل خورا ګران دي: دا مسخره ده ، مګر له دریو څخه دوه نوماندان نشي کولی دې پوښتنې ته ځواب ووایی "د بار اوسط څه شی دی؟ دا د څه شی څخه جوړ شوی دی؟"، او پوښتنه "څنګه د C پروګرام څخه د کور ډمپ راټولول" د سپرمین نړۍ یا ډیناسورونو څخه یو څه ګڼل کیږي. موږ باید د دې سره مخ شو، ځکه چې معمولا خلکو نور وړتیاوې لوړې کړي، مګر موږ به لینکس ته درس ورکړو. د دې پوښتنې ځواب "ولې د ډیو اوپس انجینر اړتیا لري چې دا ټول د بادل په عصري نړۍ کې پوه شي" باید د مقالې له ساحې بهر پریښودل شي ، مګر په دریو ټکو کې: دا ټول اړین دي.
د ټیم وسایل
د وسیلو ټیم په اتوماتیک کې مهم رول لوبوي. د دوی اصلي دنده د پراختیا کونکو لپاره مناسب ګرافیکي او CLI وسیلې رامینځته کول دي. د مثال په توګه، زموږ د داخلي پراختیا کنفرانس تاسو ته اجازه درکوي په لفظي توګه د یو څو موږک کلیکونو سره Kubernetes ته یو غوښتنلیک وړاندې کړئ، د هغې سرچینې تنظیم کړئ، د والټ څخه کیلي، او نور. مخکې، جینکنز + هیلم 2 شتون درلود، مګر ما باید د کاپي پیسټ له منځه وړلو او د سافټویر ژوند دورې ته یووالي راوستلو لپاره خپل وسیله رامینځته کړه.
د Ops ټیم د پراختیا کونکو لپاره پایپ لاین نه لیکي، مګر کولی شي د دوی په لیکلو کې د هرې مسلې په اړه مشوره ورکړي (ځینې خلک لاهم هیلم 3 لري).
DevOps
د DevOps لپاره، موږ دا د دې په څیر ګورو:
دیو ټیمونه کوډ لیکي، دا د dev -> qa/stage -> prod ته د Confer له لارې راوباسي. د دې ډاډ ترلاسه کولو مسؤلیت چې کوډ ورو نه کیږي او غلطۍ پکې نه وي د دیو او اوپس ټیمونو سره دی. د ورځې په جریان کې ، د عملیاتي ټیم څخه وظیفه شخص باید لومړی د خپل غوښتنلیک سره یوې پیښې ته ځواب ووایی ، او په ماښام او شپه کې ، د دندې مدیر (Ops) باید پرمخ وړونکی له دندې څخه راویښ کړي که چیرې هغه پوهیږي. ډاډ ترلاسه کړئ چې ستونزه په زیربنا کې نه ده. په نظارت کې ټول میټریکونه او خبرتیاوې په اوتومات ډول یا نیمه اتوماتیک ښکاري.
د Ops د مسؤلیت ساحه له هغه شیبې څخه پیل کیږي چې غوښتنلیک تولید ته لیږدول کیږي ، مګر د دیو مسؤلیت دلته پای ته نه رسیږي - موږ ورته کار کوو او په ورته کښتۍ کې یو.
پرمخ وړونکي مدیرانو ته مشوره ورکوي که دوی د اډمین مایکرو سرویس لیکلو کې مرستې ته اړتیا ولري (د مثال په توګه ، Go backend + HTML5) ، او مدیران پراختیا کونکو ته د زیربنایی مسلو یا k8s پورې اړوند مسلو په اړه مشوره ورکوي.
په لاره کې، موږ په ټوله کې یو واحد نلرو، یوازې مایکرو خدمتونه. د دوی شمیر تر دې دمه د prod k900s کلستر کې د 1000 او 8 ترمنځ بدلون راځي، که د شمیر په واسطه اندازه شي ځای پرځای کول. د پوډونو شمیر د 1700 او 2000 ترمنځ بدلون موندلی. اوس مهال د پروډ کلستر کې شاوخوا 2000 پوډونه شتون لري.
زه نشم کولی دقیق شمیر ورکړم، ځکه چې موږ غیر ضروري مایکرو خدماتو څارنه کوو او په نیمه اتوماتیک ډول یې پرې کوو. K8s موږ سره مرسته کوي چې د غیر ضروري ادارو تعقیب وساتو ، کوم چې ډیری سرچینې او پیسې خوندي کوي.
د سرچینو مدیریت
څارنه
ښه جوړ شوی او معلوماتي څارنه د لوی کلستر د عملیاتو بنسټ جوړوي. موږ تر اوسه یو نړیوال حل نه دی موندلی چې د څارنې ټولې اړتیاوې 100٪ پوښي، نو موږ په دوره توګه پدې چاپیریال کې مختلف دودیز حلونه رامینځته کوو.
- زبیبکس. ښه زوړ څارنه، چې موخه یې د زیربنا عمومي حالت تعقیب کول دي. دا موږ ته وایی کله چې نوډ د پروسس کولو ، حافظې ، ډیسکونو ، شبکې او داسې نورو شرایطو کې مړ شي. هیڅ فوق العاده ندي ، مګر موږ د اجنټانو جلا ډیمون سیټ هم لرو ، د دې په مرسته ، د مثال په توګه ، موږ په کلستر کې د DNS حالت څارو: موږ د احمق کورډنس پوډونه ګورو ، موږ د بهرني کوربه شتون چیک کوو. داسې ښکاري چې ولې د دې سره ځوریږي، مګر د ټرافیک لوی مقدار سره دا برخه د ناکامۍ یو جدي ټکی دی. زه لا دمخه ، څنګه ما په کلستر کې د DNS فعالیت سره مبارزه وکړه.
- د پرومیتیوس آپریټر. د مختلفو صادرونکو سیټ د کلستر د ټولو برخو لوی عمومي کتنه وړاندې کوي. بیا ، موږ دا ټول په ګرافانا کې په لوی ډشبورډونو کې لیدو ، او د خبرتیاو لپاره د خبرتیا مدیر وکاروو.
زموږ لپاره بله ګټوره وسیله وه . موږ دا څو ځله وروسته له هغه لیکلي چې موږ د داسې وضعیت سره مخ شو چې یو ټیم د بل ټیم انګریس لارې له مینځه وړي، د 50x غلطیو په پایله کې. اوس تولید ته د ګمارلو دمخه ، پراختیا کونکي ګوري چې هیڅوک به اغیزمن نشي ، او زما د ټیم لپاره دا د انګریز سره د ستونزو لومړني تشخیص لپاره ښه وسیله ده. دا مسخره ده چې په لومړي سر کې دا د مدیرانو لپاره لیکل شوی و او دا خورا "ناقص" ښکاري، مګر وروسته له دې چې د ډیو ټیمونه د وسیلې سره مینه کې شول، دا خورا بدل شو او داسې نه ښکاري چې "یو مدیر د مدیرانو لپاره ویب پاڼه جوړه کړې. » ډیر ژر به موږ دا وسیله پریږدو او دا ډول شرایط به حتی د پایپ لاین له غځیدو دمخه تایید شي.
په کیوب کې د ټیم سرچینې
مخکې لدې چې موږ مثالونو ته ورسیږو ، دا د توضیح کولو ارزښت لري چې موږ څنګه سرچینې تخصیص کوو کوچني خدمتونه.
د دې لپاره چې پوه شي چې کوم ټیمونه او په کوم مقدار کې دوی کاروي سرچینې (پروسیسر، حافظه، محلي SSD)، موږ هره کمانډ خپل ځان ته اختصاص کوو نومځای په "کیوب" کې او د پروسیسر، حافظې او ډیسک په شرایطو کې د هغې اعظمي وړتیاوې محدود کړئ، مخکې یې د ټیمونو اړتیاوو په اړه بحث وکړ. په دې اساس، یوه کمانډ، په عموم کې، به د ګمارنې لپاره ټول کلستر بند نه کړي، د زرګونو کورونو او ټیرابایټ حافظې تخصیص کړي. نوم ځای ته لاسرسی د AD له لارې ورکول کیږي (موږ RBAC کاروو). د نوم ځایونه او د دوی محدودیتونه د GIT ذخیره ته د پلټ غوښتنې له لارې اضافه شوي ، او بیا هرڅه په اوتومات ډول د ځواب وړ پایپ لاین له لارې بهر کیږي.
ټیم ته د سرچینو تخصیص یوه بیلګه:
namespaces:
chat-team:
pods: 23
limits:
cpu: 11
memory: 20Gi
requests:
cpu: 11
memory: 20Gi
غوښتنې او حدود
کیوب شوی" غوښتنه د تضمین شویو زیرمو شمیر دی پوډ (یو یا ډیر ډاکر کانټینرونه) په کلستر کې. حد یو غیر تضمین شوی حد دی. تاسو ډیری وختونه په ګرافونو کې لیدلی شئ چې څنګه یو ټیم د خپلو ټولو غوښتنلیکونو لپاره ډیری غوښتنې تنظیم کړي او نشي کولی غوښتنلیک "کیوب" ته ځای په ځای کړي ، ځکه چې د دوی د نوم ځای لاندې ټولې غوښتنې دمخه " مصرف شوي" دي.
له دې حالت څخه د وتلو سمه لاره دا ده چې د سرچینو حقیقي مصرف وګورئ او د غوښتل شوي مقدار (غوښتنې) سره پرتله کړئ.
په پورته سکرین شاټونو کې تاسو لیدلی شئ چې "غوښتل شوي" CPUs د تارونو ریښتیني شمیر سره سمون لري ، او محدودیتونه کولی شي د CPU تارونو ریښتیني شمیر څخه ډیر شي =)
اوس راځئ چې یو څه نوم ځای په تفصیل سره وګورو (ما د نوم ځای کیوب سیسټم غوره کړی - پخپله د "کیوب" اجزاو لپاره د سیسټم نوم ځای) او غوښتل شوي ته د واقعی کارول شوي پروسیسر وخت او حافظې تناسب وګورئ:
دا څرګنده ده چې ډیر حافظه او CPU د سیسټم خدماتو لپاره ساتل کیږي په پرتله چې واقعیا کارول کیږي. د کیوب سیسټم په قضیه کې ، دا توجیه کیږي: داسې پیښ شوي چې د نګینکس انګریس کنټرولر یا نوډلوکلډنز په خپل سر کې CPU ته زیان رسوي او ډیر RAM یې مصرف کړی ، نو دلته دا ډول زیرمه توجیه کیږي. برسېره پردې، موږ نشو کولی د تیرو 3 ساعتونو لپاره په چارټونو تکیه وکړو: دا د پام وړ ده چې د لوی وخت په اوږدو کې تاریخي میترونه وګورئ.
د "سپارښتنو" سیسټم رامینځته شوی. د مثال په توګه، دلته تاسو لیدلی شئ چې کومې سرچینې به د "حدود" (پورته اجازه لرونکی بار) لوړولو څخه غوره وي ترڅو "تروتلینګ" واقع نشي: هغه شیبه کله چې سرچینې دمخه په ټاکل شوي وخت کې CPU یا حافظه مصرف کړې وي او تر هغه وخته پورې انتظار کوي چې دا "غیر منجمد" شي:
او دلته هغه پوزې دي چې باید د دوی اشتها کمه کړي:
په throttling + د سرچینو نظارت ، تاسو کولی شئ له یو څخه ډیر مقالې ولیکئ ، نو په نظرونو کې پوښتنې وکړئ. په څو ټکو کې، زه کولی شم ووایم چې د دې ډول میټریکونو اتومات کول خورا ستونزمن دي او ډیر وخت ته اړتیا لري او د "کړکۍ" افعال او "CTE" Prometheus / VictoriaMetrics سره د عمل توازن ته اړتیا لري (دا شرایط په نرخونو کې دي، ځکه چې نږدې شتون لري. په PromQL کې د دې په څیر هیڅ شی نشته، او تاسو باید ډارونکي پوښتنې د متن په څو سکرینونو ویشئ او اصلاح یې کړئ).
د پایلې په توګه ، پراختیا کونکي په کیوب کې د دوی نوم ځایونو نظارت کولو لپاره وسیلې لري ، او دوی کولی شي د ځان لپاره غوره کړي چیرې او په کوم وخت کې کوم غوښتنلیکونه خپلې سرچینې "کټ" ولري او کوم سرورونه ټوله شپه ټوله CPU ورکول کیدی شي.
میتودولوژي
په شرکت کې لکه څنګه چې اوس دی فیشني، موږ د DevOps- او SRE- تمرین کوونکی کله چې یو شرکت 1000 مایکرو خدمتونه ولري، شاوخوا 350 پراختیا کونکي او د ټول زیربنا لپاره 15 مدیران، تاسو باید "فیشنیبل" اوسئ: د دې ټولو "باسورډونو" تر شا د هرڅه او هرڅوک اتومات کولو ته بیړنۍ اړتیا شتون لري، او مدیران باید خنډ نه وي. په پروسو کې.
د Ops په توګه، موږ د خدماتو غبرګون نرخونو او غلطیو پورې اړوند پراختیا کونکو لپاره مختلف میټریکونه او ډشبورډونه چمتو کوو.
موږ میتودونه کاروو لکه: , и د دوی سره یوځای کولو سره. موږ هڅه کوو د ډشبورډونو شمیر کم کړو ترڅو په یو نظر کې دا روښانه شي چې کوم خدمت اوس مهال خرابیږي (د مثال په توګه ، په ثانیه کې د ځواب کوډونه ، د ځواب وخت 99 فیصده) او داسې نور. هرڅومره ژر چې ځینې نوي میټریکونه د عمومي ډشبورډ لپاره اړین شي ، موږ سمدلاسه یې رسم او اضافه کوو.
ما د یوې میاشتې لپاره ګراف نه دی رسم کړی. دا شاید یو ښه نښه وي: دا پدې مانا ده چې ډیری "غوښتنې" لا دمخه احساس شوي. دا پیښ شوي چې د اونۍ په جریان کې به زه لږترلږه په ورځ کې یو ځل یو څه نوي ګراف رسم کړم.
پایله شوې پایله ارزښتناکه ده ځکه چې اوس پراختیا کونکي په ندرت سره د پوښتنو سره مدیرانو ته ځي "چیرې یو ډول میټریک وګوري."
تطبیق د خدمت میش یوازې د کونج په شاوخوا کې دی او باید د هرچا لپاره ژوند خورا اسانه کړي ، د وسیلو همکاران لا دمخه د "صحي شخص اسټیو" خلاصولو پلي کولو ته نږدې دي: د هرې HTTP (s) غوښتنې ژوند دوره به په نظارت کې څرګند شي ، او دا به تل ممکنه وي چې پوه شي چې "په کوم پړاو کې هرڅه مات شوي" د بین خدمت (او نه یوازې) متقابل عمل په جریان کې. د DomClick مرکز څخه خبرونو کې ګډون وکړئ. =)
د Kubernetes زیربنا ملاتړ
په تاریخي توګه، موږ پیچلي نسخه کاروو Kubespray - د کوبرنیټس د ځای په ځای کولو، پراخولو او تازه کولو کې د ځواب وړ رول. په ځینو وختونو کې، د غیر kubeadm تاسیساتو لپاره مالتړ د اصلي څانګې څخه قطع شوی و، او kubeadm ته د بدلولو پروسه وړاندیز شوې نه وه. د پایلې په توګه، د ساوت برج شرکت خپل فورک جوړ کړ (د کوبیډم ملاتړ او د جدي ستونزو لپاره ګړندي حل سره).
د ټولو k8s کلسترونو تازه کولو پروسه داسې ښکاري:
- واخله Kubespray د ساوت برج څخه، زموږ د تار، مرجیم سره وګورئ.
- موږ د دې لپاره تازه معلومات خپروو فشار- "کیوب".
- موږ په یو وخت کې یو نوډ تازه کوو (په ځواب کې دا "سریال: 1" دی) Dev- "کیوب".
- موږ تازه کوو Prod د شنبې په ماښام په یو وخت کې یو نوډ.
په راتلونکي کې د هغې د ځای په ځای کولو پلانونه شتون لري Kubespray د یو څه چټکتیا لپاره او لاړ شئ kubeadm.
په مجموع کې موږ درې "کیوب" لرو: فشار، دیو او پروډ. موږ پلان لرو چې یو بل پیل کړو (ګرم سټنډرډ) پروډ- "کیوب" په دوهم ډیټا مرکز کې. فشار и Dev په "مجازی ماشینونو" کې ژوند وکړئ (د فشار لپاره oVirt او د دیو لپاره VMWare کلاوډ). Prod- "کیوب" په "ناره فلز" کې ژوند کوي: دا د 32 CPU تارونو سره ورته نوډونه دي، 64-128 GB حافظه او 300 GB SSD RAID 10 - په ټولیز ډول 50 شتون لري. درې "پتلي" نوډونه "ماسټرانو" ته وقف شوي دي Prod- "کیوبا": 16 GB حافظه، 12 CPU تارونه.
د خرڅلاو لپاره، موږ غوره کوو چې د "نور فلز" وکاروو او د غیر ضروري پرتونو څخه مخنیوی وکړو OpenStack: موږ "شوري ګاونډیان" او CPU ته اړتیا نلرو وخت غلا کول. او د ادارې پیچلتیا په کور کې د OpenStack په قضیه کې نږدې دوه چنده کیږي.
د CI/CD "کیوبیک" او نورو زیربناوو برخو لپاره موږ یو جلا GIT سرور کاروو، Helm 3 (دا د هیلم 2 څخه یو ډیر دردناک لیږد و، مګر موږ د اختیارونو څخه ډیر خوښ یو. اټوم)، جینکنز، ځواب ورکوونکی او ډاکر. موږ د فیچر څانګو سره مینه لرو او له یو ذخیره څخه مختلف چاپیریال ته ځای په ځای کول.
پایلې
دا په عمومي شرایطو کې هغه څه دي چې د DevOps پروسه د عملیاتي انجینر له لید څخه په DomClick کې ښکاري. مقاله زما د تمې په پرتله لږ تخنیکي وه: له همدې امله ، په هابري کې د ډوم کلیک خبرونه تعقیب کړئ: د کوبرنیټس او نور ډیر څه په اړه به ډیر "سخت" مقالې وي.
سرچینه: www.habr.com