Kubernetes در DomClick: چگونه با مدیریت مجموعه ای از 1000 میکروسرویس، به آرامی بخوابیم

نام من ویکتور یاگوفاروف است و پلتفرم Kubernetes را در DomClick به عنوان مدیر توسعه فنی در تیم Ops (عملیات) توسعه می دهم. می‌خواهم در مورد ساختار فرآیندهای Dev <-> Ops، ویژگی‌های عملکرد یکی از بزرگترین خوشه‌های k8s در روسیه، و همچنین رویه‌های DevOps/SRE که تیم ما اعمال می‌کند، صحبت کنم.

تیم عملیات

تیم Ops در حال حاضر 15 نفر دارد. سه نفر از آنها مسئول دفتر هستند، دو نفر در یک منطقه زمانی متفاوت کار می کنند و در دسترس هستند، از جمله در شب. بنابراین، شخصی از Ops همیشه در مانیتور است و آماده پاسخگویی به یک حادثه با هر پیچیدگی است. ما شیفت شب نداریم، که روح ما را حفظ می کند و به همه این فرصت را می دهد که به اندازه کافی بخوابند و اوقات فراغت خود را نه تنها در رایانه بگذرانند.

هرکسی شایستگی های متفاوتی دارد: شبکه، DBA، متخصصان پشته ELK، مدیران/توسعه دهندگان Kubernetes، نظارت، مجازی سازی، متخصصان سخت افزار و غیره. یک چیز همه را متحد می کند - همه می توانند تا حدودی جایگزین هر یک از ما شوند: به عنوان مثال، گره های جدید را در خوشه k8s معرفی کنید، PostgreSQL را به روز کنید، خط لوله CI/CD + Ansible بنویسید، چیزی را در Python/Bash/Go خودکار کنید، سخت افزار را به آن متصل کنید. مرکز اطلاعات. شایستگی های قوی در هیچ زمینه ای شما را از تغییر جهت فعالیت و شروع به پیشرفت در زمینه های دیگر باز نمی دارد. به عنوان مثال، من به عنوان یک متخصص PostgreSQL به یک شرکت پیوستم و اکنون حوزه اصلی مسئولیت من خوشه های Kubernetes است. در تیم از هر ارتفاعی استقبال می شود و حس اهرم بسیار توسعه یافته است.

اتفاقا ما در حال شکار هستیم. شرایط لازم برای نامزدها کاملاً استاندارد است. شخصاً برای من مهم است که یک فرد در تیم جا بیفتد، بدون درگیری باشد، اما همچنین می داند چگونه از دیدگاه خود دفاع کند، می خواهد پیشرفت کند و از انجام کاری جدید نترسد و ایده های خود را ارائه دهد. همچنین مهارت های برنامه نویسی در زبان های اسکریپت نویسی، آشنایی با اصول لینوکس و انگلیسی الزامی است. زبان انگلیسی به سادگی مورد نیاز است تا در صورت فکاپ فرد بتواند در 10 ثانیه راه حل مشکل را در گوگل جستجو کند نه در 10 دقیقه. اکنون یافتن متخصصانی با دانش عمیق لینوکس بسیار دشوار است: خنده‌دار است، اما از هر سه نامزد دو نفر نمی‌توانند به این سؤال پاسخ دهند که «میانگین بار چیست؟ از چه چیزی ساخته شده است؟» و سؤال «چگونه یک هسته خالی از برنامه C جمع آوری کنیم» چیزی از دنیای ابرمردها یا دایناسورها در نظر گرفته می شود. ما باید این را تحمل کنیم، زیرا معمولاً افراد توانایی های دیگر را بسیار توسعه داده اند، اما ما لینوکس را آموزش خواهیم داد. پاسخ به این سوال "چرا یک مهندس DevOps باید همه اینها را در دنیای مدرن ابرها بداند" باید خارج از محدوده مقاله رها شود، اما در سه کلمه: همه اینها ضروری است.

ابزارهای تیم

تیم Tools نقش مهمی در اتوماسیون دارد. وظیفه اصلی آنها ایجاد ابزارهای گرافیکی و CLI مناسب برای توسعه دهندگان است. به عنوان مثال، Confer توسعه داخلی ما به شما اجازه می دهد تا به معنای واقعی کلمه یک برنامه کاربردی را تنها با چند کلیک ماوس در Kubernetes منتشر کنید، منابع آن، کلیدهای صندوق و غیره را پیکربندی کنید. قبلاً Jenkins + Helm 2 وجود داشت، اما من مجبور شدم ابزار خود را برای حذف کپی پیست و ایجاد یکنواختی در چرخه عمر نرم افزار توسعه دهم.

تیم Ops خطوط لوله را برای توسعه دهندگان نمی نویسد، اما می تواند در مورد هر مشکلی در نوشته خود راهنمایی کند (بعضی از افراد هنوز Helm 3 را دارند).

DevOps

در مورد DevOps، ما آن را به این صورت می بینیم:

تیم های توسعه دهنده کد می نویسند، آن را از طریق Confer to dev -> qa/stage -> prod منتشر می کنند. مسئولیت اطمینان از کند نشدن کد و عدم وجود خطا بر عهده تیم Dev و Ops است. در روز، فرد کشیک از تیم Ops باید اول از همه به یک حادثه با برنامه خود پاسخ دهد و در عصر و شب، مدیر کشیک (Ops) در صورت اطلاع، توسعه دهنده وظیفه را از خواب بیدار کند. مطمئن باشید که مشکل در زیرساخت نیست. تمام معیارها و هشدارها در نظارت به صورت خودکار یا نیمه خودکار ظاهر می شوند.

حوزه مسئولیت Ops از لحظه ای که برنامه به مرحله تولید می رسد شروع می شود، اما مسئولیت Dev به همین جا ختم نمی شود - ما همان کار را انجام می دهیم و در یک قایق هستیم.

توسعه دهندگان در صورت نیاز به کمک برای نوشتن یک میکروسرویس مدیریتی (به عنوان مثال، Go backend + HTML5) به مدیران توصیه می کنند، و مدیران در مورد هر گونه مشکل زیرساختی یا مسائل مربوط به k8s به توسعه دهندگان توصیه می کنند.

به هر حال، ما اصلاً یکپارچه نداریم، فقط میکروسرویس ها. تعداد آنها تا کنون بین 900 تا 1000 در خوشه prod k8s در نوسان است، اگر با عدد اندازه گیری شود. اعزام ها. تعداد غلاف ها بین 1700 تا 2000 در نوسان است. در حال حاضر حدود 2000 غلاف در خوشه پرود وجود دارد.

من نمی توانم اعداد دقیقی را ارائه دهم، زیرا ما میکروسرویس های غیر ضروری را نظارت می کنیم و آنها را به صورت نیمه خودکار حذف می کنیم. K8s به ما کمک می کند تا موجودیت های غیر ضروری را پیگیری کنیم بی فایده-اپراتور، که باعث صرفه جویی زیادی در منابع و پول می شود.

مدیریت منابع

نظارت

نظارت خوب ساختار یافته و آموزنده به سنگ بنای عملکرد یک خوشه بزرگ تبدیل می شود. ما هنوز راه حلی جهانی پیدا نکرده ایم که 100٪ نیازهای نظارتی را پوشش دهد، بنابراین به طور دوره ای راه حل های سفارشی مختلفی را در این محیط ایجاد می کنیم.

• Zabbix. نظارت خوب قدیمی، که در درجه اول برای ردیابی وضعیت کلی زیرساخت در نظر گرفته شده است. زمانی که یک گره از نظر پردازش، حافظه، دیسک، شبکه و غیره از بین می رود، به ما می گوید. هیچ چیز ماوراء الطبیعه نیست، اما ما یک DaemonSet مجزا از عوامل داریم که با کمک آن، به عنوان مثال، وضعیت DNS را در خوشه نظارت می کنیم: ما به دنبال غلاف های احمقانه coredns می گردیم، در دسترس بودن میزبان های خارجی را بررسی می کنیم. به نظر می رسد که چرا با این کار زحمت بکشید، اما با حجم زیاد ترافیک، این جزء یک نقطه شکست جدی است. من قبلا شرح داده شده، چگونه با عملکرد DNS در یک خوشه مبارزه کردم.
• اپراتور پرومتئوس. مجموعه ای از صادرکنندگان مختلف یک نمای کلی از تمام اجزای خوشه ارائه می دهد. در مرحله بعد، همه اینها را روی داشبوردهای بزرگ در Grafana تجسم می کنیم و از alertmanager برای هشدارها استفاده می کنیم.

ابزار مفید دیگری برای ما بود ورود به فهرست. ما آن را بعد از چندین بار نوشتیم که با موقعیتی مواجه شدیم که در آن یک تیم با مسیرهای ورودی تیم دیگر همپوشانی داشت که منجر به 50 برابر خطا شد. اکنون قبل از استقرار در تولید، توسعه‌دهندگان بررسی می‌کنند که هیچ‌کس تحت تأثیر قرار نگیرد و برای تیم من این ابزار خوبی برای تشخیص اولیه مشکلات Ingresses است. خنده دار است که در ابتدا برای ادمین ها نوشته شده بود و نسبتاً "دست و پا چلفتی" به نظر می رسید، اما پس از اینکه تیم های توسعه دهنده عاشق این ابزار شدند، این ابزار بسیار تغییر کرد و به نظر نمی رسید که "یک مدیر یک چهره وب برای ادمین ها ساخته است." ” به زودی ما این ابزار را رها خواهیم کرد و چنین شرایطی حتی قبل از راه اندازی خط لوله تایید می شود.

منابع تیم در مکعب

قبل از اینکه به مثال ها بپردازیم، ارزش دارد توضیح دهیم که چگونه منابع را برای آنها تخصیص می دهیم میکروسرویس ها.

برای درک اینکه کدام تیم ها و در چه مقادیری از آنها استفاده می کنند منابع (پردازنده، حافظه، SSD محلی)، ما هر دستور را به خود اختصاص می دهیم فضای نام در "مکعب" و با توجه به نیازهای تیم ها، حداکثر قابلیت های آن را از نظر پردازنده، حافظه و دیسک محدود کنید. بر این اساس، یک فرمان، به طور کلی، کل خوشه را برای استقرار مسدود نمی کند و هزاران هسته و ترابایت حافظه را تخصیص می دهد. دسترسی به فضای نام از طریق AD اعطا می شود (ما از RBAC استفاده می کنیم). فضاهای نام و محدودیت های آنها از طریق یک درخواست کشش به مخزن GIT اضافه می شوند و سپس همه چیز به طور خودکار از طریق خط لوله Ansible منتشر می شود.

مثالی از تخصیص منابع به یک تیم:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

درخواست ها و محدودیت ها

مکعبی" درخواست تعداد منابع رزرو شده تضمین شده برای غلاف (یک یا چند کانتینر داکر) در یک خوشه. حد یک حداکثر غیر تضمینی است. اغلب می‌توانید روی نمودارها ببینید که چگونه برخی از تیم‌ها برای همه برنامه‌هایش درخواست‌های زیادی برای خود تنظیم کرده‌اند و نمی‌توانند برنامه را در «مکعب» مستقر کنند، زیرا همه درخواست‌ها در فضای نام آن‌ها قبلاً «خرج شده‌اند».

راه صحیح برون رفت از این وضعیت، نگاه به مصرف واقعی منابع و مقایسه آن با مقدار درخواستی (Request) است.

در اسکرین شات های بالا می بینید که CPU های درخواستی با تعداد واقعی رشته ها مطابقت دارند و Limits می تواند از تعداد واقعی رشته های CPU بیشتر شود =)

حالا بیایید به برخی از فضای نام با جزئیات نگاه کنیم (من فضای نام kube-system را انتخاب کردم - فضای نام سیستم برای اجزای خود "مکعب") و نسبت زمان و حافظه واقعی پردازنده استفاده شده را به زمان درخواستی مشاهده کنیم:

بدیهی است که حافظه و CPU بسیار بیشتری نسبت به استفاده واقعی برای سرویس های سیستم رزرو شده است. در مورد سیستم kube، این قابل توجیه است: این اتفاق افتاد که کنترل کننده ورودی nginx یا nodelocaldn در اوج خود به CPU برخورد کردند و مقدار زیادی RAM مصرف کردند، بنابراین در اینجا چنین ذخیره ای توجیه می شود. علاوه بر این، نمی‌توانیم برای 3 ساعت گذشته به نمودارها اعتماد کنیم: دیدن معیارهای تاریخی در یک دوره زمانی طولانی مطلوب است.

سیستمی از "توصیه ها" ایجاد شد. برای مثال، در اینجا می‌توانید ببینید که کدام منابع بهتر است «محدودیت‌ها» (نوار مجاز بالا) را افزایش دهند تا «گسیختگی» رخ ندهد: لحظه‌ای که یک منبع قبلاً CPU یا حافظه را در برش زمان اختصاص داده شده صرف کرده است و منتظر است تا "نجماد" شود:

و در اینجا غلاف هایی هستند که باید اشتهای آنها را مهار کنند:

بر گاز دادن + نظارت بر منابع، می توانید بیش از یک مقاله بنویسید، بنابراین سوالات خود را در نظرات بپرسید. در چند کلمه، می توانم بگویم که کار خودکارسازی چنین معیارهایی بسیار دشوار است و به زمان زیادی نیاز دارد و با توابع "پنجره" و "CTE" Prometheus / VictoriaMetrics نیاز به زمان زیادی دارد (این اصطلاحات در نقل قول هستند، زیرا تقریباً وجود دارد هیچ چیز شبیه این در PromQL نیست، و شما باید پرس و جوهای ترسناک را به چندین صفحه متن تقسیم کنید و آنها را بهینه کنید).

در نتیجه، توسعه‌دهندگان ابزارهایی برای نظارت بر فضاهای نام خود در Cube دارند، و می‌توانند خودشان انتخاب کنند که کجا و در چه زمانی می‌توانند منابع خود را در کدام برنامه‌ها «قطع» کنند، و به کدام سرورها می‌توان کل CPU را در تمام طول شب در اختیار داشت.

روش شناسی ها

در شرکت همانطور که اکنون است مد روز، ما به DevOps- و پایبند هستیم SRE-متخصص وقتی یک شرکت دارای 1000 میکروسرویس، حدود 350 توسعه‌دهنده و 15 ادمین برای کل زیرساخت است، شما باید «مد روز» باشید: پشت همه این «کلمات» نیاز مبرمی به خودکار کردن همه چیز و همه وجود دارد، و مدیران نباید گلوگاه باشند. در فرآیندها

به عنوان Ops، ما معیارها و داشبوردهای مختلفی را برای توسعه دهندگان مرتبط با نرخ پاسخگویی سرویس و خطاها ارائه می دهیم.

ما از متدولوژی هایی مانند: RED, استفاده از и سیگنال های طلاییبا ترکیب آنها با یکدیگر ما سعی می کنیم تعداد داشبوردها را به حداقل برسانیم تا در یک نگاه مشخص شود که کدام سرویس در حال حاضر ضعیف است (مثلاً کدهای پاسخ در هر ثانیه، زمان پاسخگویی به صدک 99) و غیره. به محض اینکه برخی معیارهای جدید برای داشبوردهای عمومی ضروری شد، بلافاصله آنها را ترسیم و اضافه می کنیم.

من یک ماه است که نمودار نکشیده ام. این احتمالاً نشانه خوبی است: به این معنی است که بیشتر "خواست ها" قبلاً تحقق یافته اند. این اتفاق افتاد که در طول هفته حداقل یک بار در روز چند نمودار جدید ترسیم می کردم.

نتیجه به دست آمده ارزشمند است زیرا اکنون توسعه‌دهندگان به ندرت به سراغ مدیران می‌روند و سؤال می‌کنند «کجا باید به نوعی معیار نگاه کرد».

پیاده سازی مش سرویس نزدیک است و باید زندگی را برای همه آسان‌تر کند، همکاران Tools در حال حاضر به اجرای خلاصه "Istio یک فرد سالم" نزدیک شده‌اند: چرخه زندگی هر درخواست HTTP در نظارت قابل مشاهده است. درک "در چه مرحله ای همه چیز خراب شد" در طول تعامل بین خدماتی (و نه تنها) همیشه امکان پذیر است. در اخبار مرکز DomClick مشترک شوید. =)

پشتیبانی زیرساخت Kubernetes

از لحاظ تاریخی، ما از نسخه پچ شده استفاده می کنیم کوبسپری - نقش قابل قبول برای استقرار، گسترش و به روز رسانی Kubernetes. در برخی مواقع، پشتیبانی از تاسیسات غیر kubeadm از شاخه اصلی قطع شد و روند تغییر به kubeadm پیشنهاد نشد. در نتیجه، شرکت Southbridge فورک خود را (با پشتیبانی از kubeadm و راه حل سریع برای مشکلات بحرانی) ساخت.

روند به روز رسانی همه کلاسترهای k8s به شکل زیر است:

• بگیر کوبسپری از Southbridge، با موضوع ما، مرجیم بررسی کنید.
• ما در حال عرضه به‌روزرسانی هستیم فشار- "مکعب".
• ما به روز رسانی را یک نود در یک زمان منتشر می کنیم (در Ansible این "سریال: 1" است) در برنامه نویس- "مکعب".
• در حال بروز رسانی بر انگیختن در عصر شنبه یک گره در یک زمان.

برنامه هایی برای جایگزینی آن در آینده وجود دارد کوبسپری برای چیزی سریعتر و رفتن به kubeadm.

در مجموع ما سه "مکعب" داریم: استرس، توسعه و تولید. ما در حال برنامه ریزی برای راه اندازی یکی دیگر هستیم (آماده به کار داغ) Prod-“Cube” در مرکز داده دوم. فشار и برنامه نویس در "ماشین های مجازی" زندگی کنید (oVirt برای استرس و VMWare cloud برای Dev). بر انگیختن- "Cube" روی "فلز لخت" زندگی می کند: اینها گره های یکسان با 32 رشته پردازنده، 64-128 گیگابایت حافظه و 300 گیگابایت SSD RAID 10 هستند - در مجموع 50 مورد از آنها وجود دارد. سه گره "نازک" به "استادها" اختصاص داده شده است. بر انگیختن- "کوبا": 16 گیگابایت حافظه، 12 رشته پردازنده.

برای فروش، ما ترجیح می دهیم از "فلز لخت" استفاده کنیم و از لایه های غیر ضروری مانند اجتناب کنیم OpenStack: ما به "همسایگان پر سر و صدا" و CPU نیاز نداریم دزدیدن زمان. و پیچیدگی مدیریت در مورد OpenStack داخلی تقریباً دو برابر می شود.

برای CI/CD "Cubic" و سایر اجزای زیرساخت ما از یک سرور GIT جداگانه، Helm 3 استفاده می کنیم (این انتقال نسبتا دردناکی از Helm 2 بود، اما ما از گزینه ها بسیار راضی هستیم اتمیجنکینز، آنزیل و داکر. ما عاشق شاخه های ویژگی و استقرار در محیط های مختلف از یک مخزن هستیم.

نتیجه

به طور کلی، فرآیند DevOps در DomClick از دیدگاه یک مهندس عملیات شبیه به این است. این مقاله کمتر از آنچه انتظار داشتم فنی بود: بنابراین، اخبار DomClick را در Habré دنبال کنید: مقالات "سخت‌کور" بیشتری در مورد Kubernetes و موارد دیگر وجود خواهد داشت.

منبع: www.habr.com