در پایان سال گذشته، پخش زنده دیگری از جامعه PostgreSQL روسیه انجام شد ، که طی آن یکی از بنیانگذاران آن نیکولای ساموخوالوف با مدیر فنی Flant دیمیتری استولیاروف در مورد این DBMS در زمینه Kubernetes صحبت کرد.
ما در حال انتشار متن بخش اصلی این بحث هستیم و در ویدیوی کامل ارسال شده:
پایگاه های داده و Kubernetes
NS: امروز در مورد VACUUM و CHECKPOINT صحبت نمی کنیم. ما می خواهیم در مورد Kubernetes صحبت کنیم. میدونم سالها تجربه داری من ویدیوهای شما را تماشا کردم و حتی برخی از آنها را دوباره تماشا کردم... بیایید مستقیماً به سر اصل مطلب برویم: اصلاً چرا Postgres یا MySQL در K8s؟
DS: پاسخ قطعی برای این سوال وجود ندارد و نمی تواند باشد. اما در کل این سادگی و راحتی است... پتانسیل. همه خواهان خدمات مدیریت شده هستند.
NS: چگونه ، فقط در خانه؟
DS: بله: مانند RDS، فقط در هر کجا.
NS: "هرجا" نکته خوبی است. در شرکت های بزرگ همه چیز در مکان های مختلف قرار دارد. پس چرا اگر یک شرکت بزرگ است، راه حل آماده را انتخاب نکنید؟ به عنوان مثال، Nutanix پیشرفت های خاص خود را دارد، سایر شرکت ها (VMware...) همان "RDS، فقط در خانه" را دارند.
DS: اما ما در مورد یک پیاده سازی جداگانه صحبت می کنیم که فقط تحت شرایط خاصی کار می کند. و اگر در مورد Kubernetes صحبت می کنیم، پس زیرساخت های بسیار متنوعی وجود دارد (که می تواند در K8s باشد). اساساً این یک استاندارد برای APIهای ابری است ...
NS: این نیز رایگان است!
DS: خیلی مهم نیست. آزاد بودن برای بخش نه چندان بزرگی از بازار مهم است. چیز دیگری مهم است... احتمالاً گزارش را به خاطر دارید.»
NS: آره.
DS: متوجه شدم که بسیار مبهم دریافت شده است. برخی از مردم فکر می کردند که من می گویم: "بچه ها، بیایید همه پایگاه های داده را به Kubernetes وارد کنیم!"، در حالی که برخی دیگر تصمیم گرفتند که همه اینها دوچرخه های وحشتناکی هستند. اما من می خواستم چیزی کاملاً متفاوت بگویم: «ببینید چه اتفاقی می افتد، چه مشکلاتی وجود دارد و چگونه می توان آنها را حل کرد. آیا اکنون باید از پایگاه داده های Kubernetes استفاده کنیم؟ تولید؟ خوب، فقط اگر دوست دارید ... انجام کارهای خاصی را انجام دهید. اما برای یک توسعه دهنده، می توانم بگویم که آن را توصیه می کنم. برای یک توسعه دهنده، پویایی ایجاد/حذف محیط ها بسیار مهم است.
NS: منظور شما از dev، همه محیط هایی است که prod نیستند؟ مرحله‌بندی، کیفیت…
DS: اگر در مورد استندهای پرف صحبت می کنیم، احتمالاً نه، زیرا الزامات وجود دارد. اگر ما در مورد موارد خاصی صحبت می کنیم که یک پایگاه داده بسیار بزرگ برای مرحله بندی نیاز است، احتمالاً نه ... اگر این یک محیط ثابت و طولانی مدت است، پس وجود پایگاه داده در K8s چه فایده ای دارد؟
NS: هیچ یک. اما در کجا محیط های ایستا را می بینیم؟ یک محیط ثابت فردا منسوخ خواهد شد.
DS: مرحله بندی می تواند ثابت باشد. مشتری داریم...
NS: بله من هم دارم. اگر یک پایگاه داده 10 ترابایتی و 200 گیگابایت مرحله بندی داشته باشید، مشکل بزرگی است...
DS: یه کیس خیلی باحال دارم! در مرحله بندی یک پایگاه داده محصول وجود دارد که تغییرات در آن ایجاد می شود. و یک دکمه وجود دارد: "تولید به تولید". این تغییرات - دلتاها - اضافه می شوند (به نظر می رسد آنها به سادگی از طریق API هماهنگ شده اند) در تولید. این یک گزینه بسیار عجیب و غریب است.
NS: من استارت‌آپ‌هایی را در Valley دیده‌ام که در RDS یا حتی در Heroku نشسته‌اند - اینها داستان‌های 2-3 سال پیش هستند - و آنها Dump را در لپ‌تاپ خود دانلود می‌کنند. چون دیتابیس هنوز فقط 80 گیگ هست و روی لپ تاپ هم جا هست. سپس دیسک های اضافی را برای همه می خرند تا آنها 3 پایگاه داده برای انجام پیشرفت های مختلف داشته باشند. این نیز چگونه اتفاق می افتد. من همچنین دیدم که آنها از کپی کردن محصول در صحنه سازی نمی ترسند - این بسیار به شرکت بستگی دارد. اما من هم دیدم که خیلی می ترسند و اغلب وقت و دست کافی ندارند. اما قبل از اینکه به این موضوع بپردازیم، می خواهم در مورد Kubernetes بشنوم. آیا من به درستی فهمیدم که هنوز کسی در حال تولید نیست؟
DS: ما پایگاه های اطلاعاتی کوچکی در تولید داریم. ما در مورد حجم های ده ها گیگابایتی و سرویس های غیر بحرانی صحبت می کنیم که برای ساختن کپی برای آنها تنبل بودیم (و چنین نیازی وجود ندارد). و به شرطی که ذخیره سازی معمولی تحت Kubernetes وجود داشته باشد. این پایگاه داده در یک ماشین مجازی کار می کرد - به صورت مشروط در VMware، در بالای سیستم ذخیره سازی. ما آن را در آن قرار دادیم و اکنون می توانیم آن را از ماشینی به ماشین دیگر منتقل کنیم.
NS: پایگاه های داده با این حجم تا 100 گیگابایت را می توان در عرض چند دقیقه روی دیسک های خوب و شبکه خوب پخش کرد، درست است؟ سرعت 1 گیگابایت در ثانیه دیگر عجیب نیست.
DS: بله، برای عملیات خطی این مشکلی ندارد.
NS: باشه، فقط باید به پرود فکر کنیم. و اگر Kubernetes را برای محیط های غیر تولیدی در نظر می گیریم، چه باید بکنیم؟ من آن را در Zalando می بینم ، در کرانچی ، گزینه های دیگری نیز وجود دارد. و وجود دارد - این دوست خوب ما آلوارو از اسپانیا است: کاری که آنها انجام می دهند اساساً فقط نیست و کل توزیع ()، که علاوه بر خود Postgres، آنها تصمیم گرفتند یک نسخه پشتیبان، یعنی پروکسی Envoy نیز در آن قرار دهند.
DS: فرستاده برای چی؟ به طور خاص ترافیک Postgres را متعادل می کنید؟
NS: آره. یعنی آنها آن را به این صورت می‌بینند: اگر شما یک توزیع و هسته لینوکس بگیرید، پس از آن PostgreSQL معمولی هسته است، و آنها می‌خواهند توزیعی بسازند که سازگار با فضای ابری باشد و روی Kubernetes اجرا شود. کامپوننت ها (پشتیبان گیری و ...) را کنار هم می گذارند و اشکال زدایی می کنند تا به خوبی کار کنند.
DS: خیلی باحاله! اساسا این نرم افزار برای ایجاد Postgres مدیریت شده خود است.
NS: توزیع های لینوکس مشکلات ابدی دارند: نحوه ساخت درایورها به گونه ای که همه سخت افزارها پشتیبانی شوند. و آنها این ایده را دارند که در Kubernetes کار خواهند کرد. من می دانم که در اپراتور Zalando اخیراً شاهد اتصال به AWS بودیم و این دیگر خیلی خوب نیست. نباید ارتباطی با زیرساخت خاصی وجود داشته باشد - پس چه فایده ای دارد؟
DS: من دقیقا نمی دانم Zalando در چه وضعیتی قرار گرفت، اما در Kubernetes فضای ذخیره سازی به گونه ای ساخته شده است که گرفتن نسخه پشتیبان از دیسک با استفاده از روش عمومی غیرممکن است. اخیراً در استاندارد - در آخرین نسخه — ما عکس های فوری را ممکن کردیم، اما کجا اجرا می شود؟ انصافاً همه چیز هنوز خیلی خام است... ما داریم CSI را بالای AWS، GCE، Azure، vSphere امتحان می کنیم، اما به محض اینکه شروع به استفاده از آن کردید، می بینید که هنوز آماده نیست.
NS: به همین دلیل است که گاهی اوقات باید به زیرساخت ها تکیه کنیم. من فکر می کنم این هنوز یک مرحله اولیه است - دردهای در حال رشد. سوال: چه توصیه ای به تازه کارانی دارید که می خواهند PgSQL را در K8s امتحان کنند؟ چه اپراتوری شاید؟
DS: مشکل اینجاست که Postgres برای ما 3 درصد است. ما همچنین یک لیست بسیار بزرگ از نرم افزارهای مختلف در Kubernetes داریم، من حتی همه چیز را لیست نمی کنم. به عنوان مثال، Elasticsearch. اپراتورهای زیادی وجود دارد: برخی به طور فعال در حال توسعه هستند، برخی دیگر نیستند. ما برای خودمان الزاماتی را در مورد آنچه که یک اپراتور باید داشته باشد، ترسیم کرده ایم تا بتوانیم آن را جدی بگیریم. در اپراتور مخصوص Kubernetes - نه در "اپراتور برای انجام کاری در شرایط آمازون"... در واقع، ما به طور گسترده (= تقریباً همه مشتریان) از یک اپراتور استفاده می کنیم - (به زودی مقاله ای در مورد او منتشر خواهیم کرد).
NS: و برای MySQL هم نیست؟ من می دانم که Percona... از آنجایی که آنها اکنون روی MySQL، MongoDB و Postgres کار می کنند، باید نوعی راه حل جهانی ایجاد کنند: برای همه پایگاه های داده، برای همه ارائه دهندگان ابر.
DS: ما وقت نداشتیم که اپراتورهای MySQL را بررسی کنیم. این تمرکز اصلی ما در حال حاضر نیست. MySQL به طور مستقل به خوبی کار می کند. چرا از یک اپراتور استفاده کنید اگر فقط می توانید یک پایگاه داده را راه اندازی کنید ... می توانید یک کانتینر Docker را با Postrges راه اندازی کنید یا می توانید آن را به روشی ساده راه اندازی کنید.
NS: در این مورد هم سوالی بود. اصلا اپراتور نداره؟
DS: بله، 100٪ از ما PostgreSQL را بدون اپراتور اجرا می کنیم. تا اینجای کار. ما به طور فعال از اپراتور برای Prometheus و Redis استفاده می کنیم. ما برنامه هایی برای پیدا کردن یک اپراتور برای Elasticsearch داریم - این اپراتور است که بیشتر "در آتش" است، زیرا می خواهیم در 100٪ موارد آن را در Kubernetes نصب کنیم. همانطور که می خواهیم اطمینان حاصل کنیم که MongoDB نیز همیشه در Kubernetes نصب است. در اینجا آرزوهای خاصی ظاهر می شود - این احساس وجود دارد که در این موارد می توان کاری انجام داد. و ما حتی به Postgres نگاه نکردیم. البته، ما می دانیم که گزینه های مختلفی وجود دارد، اما در واقع ما یک مستقل داریم.
DB برای آزمایش در Kubernetes
NS: بریم سراغ مبحث تست زدن. نحوه اعمال تغییرات در پایگاه داده - از دیدگاه DevOps. میکروسرویس‌ها، پایگاه‌های اطلاعاتی زیادی وجود دارد، چیزی در جایی در حال تغییر است. چگونه از CI/CD عادی اطمینان حاصل کنیم تا همه چیز از دیدگاه DBMS مرتب باشد. رویکرد شما چیست؟
DS: نمی توان یک پاسخ داشت. چندین گزینه وجود دارد. اولی اندازه پایه ای است که می خواهیم پهن کنیم. شما خودتان اشاره کردید که شرکت‌ها نگرش‌های متفاوتی نسبت به داشتن نسخه‌ای از پایگاه داده prod در dev و stage دارند.
NS: و تحت شرایط GDPR، فکر می کنم آنها بیشتر و بیشتر مراقب هستند... می توانم بگویم که در اروپا قبلاً شروع به اعمال جریمه کرده اند.
DS: اما اغلب می‌توانید نرم‌افزاری بنویسید که زباله‌ای را از تولید گرفته و آن را مبهم کند. داده‌های Prod به‌دست می‌آیند (عکس فوری، تخلیه، کپی باینری...)، اما ناشناس هستند. در عوض، می‌توان اسکریپت‌های تولیدی وجود داشته باشد: اینها می‌توانند فیکسچر یا فقط یک اسکریپت باشند که یک پایگاه داده بزرگ تولید می‌کند. مشکل این است: چقدر طول می کشد تا یک تصویر پایه ایجاد شود؟ و مدت زمان استقرار آن در محیط مورد نظر چقدر است؟
ما به یک طرح رسیدیم: اگر مشتری یک مجموعه داده ثابت (نسخه حداقل پایگاه داده) داشته باشد، به طور پیش فرض از آنها استفاده می کنیم. اگر در مورد محیط های بررسی صحبت می کنیم، زمانی که یک شعبه ایجاد کردیم، نمونه ای از برنامه را مستقر کردیم - یک پایگاه داده کوچک را در آنجا راه اندازی کردیم. اما خوب معلوم شد ، زمانی که یک بار در روز (شب) یک Dump از تولید می گیریم و یک کانتینر Docker با PostgreSQL و MySQL با این داده های بارگذاری شده بر اساس آن می سازیم. اگر لازم است پایگاه داده را 50 بار از این تصویر گسترش دهید، این کار کاملاً ساده و سریع انجام می شود.
NS: با کپی ساده؟
DS: داده ها مستقیماً در تصویر داکر ذخیره می شوند. آن ها ما یک تصویر آماده داریم، البته 100 گیگابایت. به لطف لایه‌های موجود در Docker، ما می‌توانیم به سرعت این تصویر را هر چند بار که نیاز داریم مستقر کنیم. روش احمقانه است، اما خوب کار می کند.
NS: بعد وقتی تست میکنی درست داخل داکر عوض میشه درسته؟ کپی روی نوشتن در داکر - آن را دور بیندازید و دوباره بروید، همه چیز خوب است. کلاس! و آیا در حال حاضر به طور کامل از آن استفاده می کنید؟
DS: خیلی وقته
NS: ما کارهای بسیار مشابهی انجام می دهیم. فقط ما از Docker's copy-on-write استفاده نمی کنیم، بلکه از یک نسخه دیگر استفاده می کنیم.
DS: عمومی نیست. و داکر در همه جا کار می کند.
NS: در تئوری، بله. اما ما ماژول هایی هم در آنجا داریم، شما می توانید ماژول های مختلف بسازید و با فایل سیستم های مختلف کار کنید. چه لحظه ای اینجاست از سمت Postgres، ما به همه اینها متفاوت نگاه می کنیم. حالا من از سمت داکر نگاه کردم و دیدم همه چیز برای شما کار می کند. اما اگر پایگاه داده بزرگ باشد، مثلاً 1 ترابایت، پس همه اینها زمان زیادی می برد: عملیات در شب، و پر کردن همه چیز در داکر... و اگر 5 ترابایت در داکر پر شود... یا همه چیز خوب است؟
DS: تفاوت چیست: اینها حباب هستند، فقط بیت و بایت.
NS: تفاوت این است: آیا این کار را از طریق dump و restore انجام می دهید؟
DS: اصلا لازم نیست. روش های تولید این تصویر می تواند متفاوت باشد.
NS: برای برخی از مشتریان، ما آن را به گونه‌ای ساخته‌ایم که به‌جای تولید منظم تصویر پایه، دائماً آن را به‌روز نگه می‌داریم. این در اصل یک کپی است، اما داده ها را نه مستقیماً از استاد، بلکه از طریق یک آرشیو دریافت می کند. یک بایگانی باینری که در آن WAL ها هر روز دانلود می شوند، جایی که پشتیبان گیری می شود... این WAL ها سپس با کمی تاخیر (به معنای واقعی کلمه 1-2 ثانیه) به تصویر پایه می رسند. ما به هر شکلی از آن کلون می کنیم - اکنون به طور پیش فرض ZFS را داریم.
DS: اما با ZFS شما به یک گره محدود می شوید.
NS: آره. اما ZFS جادویی هم دارد : با آن می توانید یک عکس فوری ارسال کنید و حتی (من واقعاً این را هنوز تست نکرده ام، اما...) می توانید یک دلتا بین دو ارسال کنید. PGDATA. در واقع، ما ابزار دیگری داریم که واقعاً برای چنین وظایفی در نظر نگرفته‌ایم. PostgreSQL دارد ، که مانند یک rsync «هوشمند» عمل می کند و از بسیاری از مواردی که مجبور به تماشای آن نیستید صرفنظر می کند، زیرا هیچ چیز در آنجا تغییر نکرده است. ما می توانیم یک هماهنگی سریع بین دو سرور انجام دهیم و به همان روش به عقب برگردیم.
بنابراین، از این سمت، بیشتر DBA، ما در حال تلاش برای ایجاد ابزاری هستیم که به ما امکان می دهد همان کاری را که شما گفتید انجام دهیم: ما یک پایگاه داده داریم، اما می خواهیم چیزی را 50 بار، تقریباً همزمان، آزمایش کنیم.
DS: 50 بار یعنی باید 50 نمونه Spot سفارش دهید.
NS: نه، ما همه کارها را روی یک دستگاه انجام می دهیم.
DS: اما اگر این پایگاه داده مثلاً ترابایتی باشد چگونه 50 برابر گسترش خواهید داد. به احتمال زیاد او به 256 گیگابایت رم مشروط نیاز دارد؟
NS: بله، گاهی اوقات شما به حافظه زیادی نیاز دارید - این طبیعی است. اما این نمونه ای از زندگی است. دستگاه تولیدی دارای 96 هسته و 600 گیگابایت است. در همان زمان، 32 هسته (حتی گاهی اوقات 16 هسته) و 100-120 گیگابایت حافظه برای پایگاه داده استفاده می شود.
DS: و 50 نسخه در آن جا می شود؟
NS: بنابراین فقط یک کپی وجود دارد، سپس کپی روی نوشتن (ZFS) کار می کند... جزئیات بیشتری را به شما خواهم گفت.
به عنوان مثال، ما یک پایگاه داده 10 ترابایتی داریم. یک دیسک برای آن درست کردند، ZFS هم اندازه آن را 30-40 درصد فشرده کرد. از آنجایی که ما تست بارگذاری را انجام نمی دهیم، زمان پاسخ دقیق برای ما مهم نیست: بگذارید تا 2 برابر کندتر باشد - اشکالی ندارد.
ما این فرصت را به برنامه نویسان، QA، DBA و غیره می دهیم. آزمایش را در 1-2 رشته انجام دهید. به عنوان مثال، آنها ممکن است نوعی مهاجرت را اجرا کنند. این به 10 هسته در یک زمان نیاز ندارد - به 1 باطن Postgres، 1 هسته نیاز دارد. مهاجرت آغاز خواهد شد - شاید همچنان شروع می شود، سپس از هسته دوم استفاده می شود. ما 16-32 هسته اختصاص داده ایم، بنابراین 10 نفر می توانند همزمان کار کنند، مشکلی نیست.
زیرا از نظر فیزیکی PGDATA به همین ترتیب، معلوم می شود که ما در واقع پستگرس را فریب می دهیم. ترفند این است: به عنوان مثال، 10 Postgre به طور همزمان راه اندازی می شود. معمولا مشکل چیست؟ قرار دادند ، فرض کنید 25٪. بر این اساس، این 200 گیگابایت است. شما نمی توانید بیش از سه مورد از این موارد را راه اندازی کنید، زیرا حافظه تمام می شود.
اما در برخی موارد متوجه شدیم که این کار ضروری نیست: shared_buffers را روی 2 گیگابایت تنظیم کردیم. PostgreSQL دارد ، و در واقع این تنها چیزی است که تأثیر می گذارد . ما آن را روی 0,5 ترابایت تنظیم کردیم. و حتی مهم نیست که آنها در واقع وجود ندارند: او طوری برنامه ریزی می کند که گویی وجود دارند.
بر این اساس، هنگامی که نوعی مهاجرت را آزمایش می کنیم، می توانیم تمام برنامه ها را جمع آوری کنیم - خواهیم دید که چگونه در تولید اتفاق می افتد. ثانیه های آنجا متفاوت خواهند بود (آهسته تر)، اما داده هایی که ما در واقع می خوانیم، و خود طرح ها (چه JOIN وجود دارد و غیره) دقیقاً مانند زمان تولید است. و شما می توانید بسیاری از این گونه بررسی ها را به صورت موازی روی یک دستگاه اجرا کنید.
DS: فکر نمی کنید اینجا چند مشکل وجود دارد؟ اولین راه حلی است که فقط روی PostgreSQL کار می کند. این رویکرد بسیار خصوصی است، عمومی نیست. دوم این است که Kubernetes (و همه چیزهایی که فناوری‌های ابری در حال حاضر به سمت آن می‌روند) شامل گره‌های زیادی است و این گره‌ها زودگذر هستند. و در مورد شما یک گره حالت دار و پایدار است. این چیزها باعث تعارض من می شود.
NS: اول، من موافقم، این یک داستان کاملاً Postgres است. من فکر می کنم اگر ما نوعی IO مستقیم و یک مخزن بافر برای تقریباً تمام حافظه داشته باشیم، این رویکرد کار نخواهد کرد - برنامه ها متفاوت خواهند بود. اما در حال حاضر ما فقط با Postgres کار می کنیم و به دیگران فکر نمی کنیم.
درباره Kubernetes شما خودتان همه جا به ما می گویید که ما یک پایگاه داده پایدار داریم. اگر نمونه با شکست مواجه شد، نکته اصلی ذخیره دیسک است. در اینجا ما همچنین کل پلتفرم را در Kubernetes داریم، و کامپوننت با Postgres جداست (اگرچه یک روز آنجا خواهد بود). بنابراین، همه چیز به این صورت است: نمونه سقوط کرد، اما ما PV آن را ذخیره کردیم و به سادگی آن را به نمونه (جدید) دیگری متصل کردیم، گویی هیچ اتفاقی نیفتاده است.
DS: از دیدگاه من، ما در Kubernetes pods ایجاد می کنیم. K8s - الاستیک: گره ها در صورت نیاز سفارش داده می شوند. وظیفه این است که به سادگی یک pod ایجاد کنید و بگویید که به X مقدار منابع نیاز دارد و سپس K8s خودش آن را کشف خواهد کرد. اما پشتیبانی ذخیره سازی در Kubernetes هنوز ناپایدار است: به (این نسخه منتشر شد از هفته پیش) این ویژگی ها فقط بتا می شوند.
شش ماه تا یک سال می گذرد - کم و بیش پایدار می شود یا حداقل به این صورت اعلام می شود. سپس امکان اسنپ شات و تغییر اندازه مشکل شما را به طور کامل حل می کند. چون شما پایه دارید. بله، ممکن است خیلی سریع نباشد، اما سرعت به چیزی بستگی دارد که "زیر هود" وجود دارد، زیرا برخی از پیاده سازی ها می توانند در سطح زیرسیستم دیسک کپی و کپی بر روی نوشتن شوند.
NS: همچنین لازم است همه موتورها (آمازون، گوگل...) شروع به پشتیبانی از این نسخه کنند - این نیز مدتی طول می کشد.
DS: ما هنوز از آنها استفاده نمی کنیم. ما از خودمان استفاده می کنیم.
توسعه محلی برای Kubernetes
NS: آیا با چنین آرزویی مواجه شده اید که باید همه غلاف ها را روی یک دستگاه نصب کنید و آزمایش کوچکی انجام دهید. برای به دست آوردن سریع اثبات مفهوم، ببینید که برنامه در Kubernetes اجرا می شود، بدون اینکه تعداد زیادی ماشین برای آن اختصاص دهید. Minikube وجود دارد، درست است؟
DS: به نظر من این مورد - مستقر در یک گره - منحصراً در مورد توسعه محلی است. یا برخی مظاهر چنین الگویی. بخور ، وجود دارد , . ما به سمت استفاده از Kubernetes IN Docker حرکت می کنیم. حالا برای آزمایش با آن شروع به کار کردیم.
NS: قبلاً فکر می کردم که این تلاشی برای قرار دادن همه پادها در یک تصویر Docker است. اما معلوم شد که این در مورد چیزی کاملا متفاوت است. به هر حال، ظروف جداگانه، غلاف های جداگانه وجود دارد - فقط در Docker.
DS: آره. و یک تقلید نسبتاً خنده دار ساخته شده است ، اما معنی این است ... ما یک ابزار برای استقرار داریم - . ما می خواهیم آن را به حالت شرطی تبدیل کنیم werf up: "Kubernetes محلی را برای من بیاور." و سپس شرطی را در آنجا اجرا کنید werf follow. سپس توسعه‌دهنده می‌تواند IDE را ویرایش کند و فرآیندی در سیستم راه‌اندازی می‌شود که تغییرات را می‌بیند و تصاویر را بازسازی می‌کند و آنها را مجدداً در K8s محلی مستقر می‌کند. اینگونه است که می خواهیم برای حل مشکل توسعه محلی تلاش کنیم.
عکس های فوری و شبیه سازی پایگاه داده در واقعیت K8s
NS: اگر به کپی روی نوشتن برگردیم. متوجه شدم که ابرها نیز عکس های فوری دارند. آنها متفاوت کار می کنند. به عنوان مثال، در GCP: شما یک نمونه چند ترابایتی در ساحل شرقی ایالات متحده دارید. شما به صورت دوره ای عکس های فوری می گیرید. شما یک کپی از دیسک در ساحل غربی را از یک عکس فوری بر می دارید - در عرض چند دقیقه همه چیز آماده است، خیلی سریع کار می کند، فقط حافظه پنهان باید در حافظه پر شود. اما این کلون‌ها (عکس‌های فوری) برای «تامین» یک جلد جدید هستند. هنگامی که شما نیاز به ایجاد نمونه های زیادی دارید، این کار جالب است.
اما برای آزمایش، به نظرم می رسد که عکس های فوری، که شما در مورد آنها در Docker صحبت می کنید یا من در مورد آن در ZFS، btrfs و حتی LVM صحبت می کنم ... - آنها به شما اجازه می دهند که داده های واقعاً جدیدی را روی یک ماشین ایجاد نکنید. در فضای ابری، شما همچنان هر بار هزینه آنها را پرداخت می کنید و نه ثانیه ها، بلکه چند دقیقه صبر می کنید (و در مورد ، احتمالاً یک ساعت).
در عوض، می توانید این داده ها را در یک یا دو ثانیه به دست آورید، آزمایش را اجرا کرده و دور بیندازید. این عکس های فوری مشکلات مختلفی را حل می کند. در مورد اول - برای افزایش مقیاس و دریافت کپی های جدید، و در مورد دوم - برای آزمایش.
DS: موافق نیستم انجام درست شبیه سازی حجم، وظیفه ابر است. من به اجرای آنها نگاه نکرده ام، اما می دانم که چگونه این کار را روی سخت افزار انجام می دهیم. ما Ceph داریم، هر حجم فیزیکی را اجازه می دهد () گفتن کلون کردن و یک جلد دوم با همان ویژگی ها را در ده ها میلی ثانیه دریافت کنید، آمی و غیره شما باید درک کنید که یک کپی روی نوشتن مشکل در داخل وجود دارد. چرا ابر نباید همین کار را بکند؟ من مطمئن هستم که آنها سعی می کنند این کار را انجام دهند.
NS: اما باز هم چند ثانیه، ده‌ها ثانیه طول می‌کشد تا یک نمونه را مطرح کنند، داکر را به آنجا بیاورند و غیره.
DS: چرا لازم است یک نمونه کامل مطرح شود؟ ما یک نمونه با 32 هسته داریم، 16 ... و می تواند در آن جا شود - به عنوان مثال، چهار. هنگامی که پنجمین مورد را سفارش می دهیم، نمونه قبلاً مطرح می شود و سپس حذف می شود.
NS: بله، جالب است، داستان Kubernetes متفاوت است. پایگاه داده ما در K8 نیست و یک نمونه داریم. اما شبیه سازی یک پایگاه داده چند ترابایتی بیش از دو ثانیه طول نمی کشد.
DS: این عالی است. اما نکته اولیه من این است که این یک راه حل عمومی نیست. بله، جالب است، اما فقط برای Postgres و فقط در یک گره مناسب است.
NS: نه تنها برای Postgres مناسب است: این طرح ها، همانطور که توضیح دادم، فقط در آن کار می کنند. اما اگر در مورد برنامه‌ها به خود زحمت نمی‌دهیم و فقط به تمام داده‌ها برای آزمایش عملکردی نیاز داریم، این برای هر DBMS مناسب است.
DS: سالها پیش ما کاری مشابه را روی عکس‌های فوری LVM انجام دادیم. این یک کلاسیک است. این رویکرد بسیار فعال مورد استفاده قرار گرفت. گره های حالت دار فقط یک درد هستند. چون نباید آنها را رها کنید، باید همیشه آنها را به خاطر بسپارید...
NS: آیا امکان هیبریدی را در اینجا می بینید؟ فرض کنید stateful نوعی غلاف است، برای چندین نفر (بسیاری از آزمایش‌کنندگان) کار می‌کند. ما یک جلد داریم، اما به لطف سیستم فایل، کلون ها محلی هستند. اگر غلاف بیفتد، اما دیسک باقی بماند، غلاف بالا می‌آید، اطلاعات مربوط به همه کلون‌ها را می‌شمرد، دوباره همه چیز را برمی‌دارد و می‌گوید: «اینها کلون‌های شما روی این پورت‌ها اجرا می‌شوند، به کار با آنها ادامه دهید».
DS: از نظر فنی این بدان معنی است که در Kubernetes یک پاد است که در آن تعداد زیادی Postgres را اجرا می کنیم.
NS: آره. او یک محدودیت دارد: فرض کنید بیش از 10 نفر همزمان با او کار نمی کنند. اگر به 20 مورد نیاز دارید، ما یک پاد دوم را راه اندازی خواهیم کرد. ما آن را به طور کامل شبیه سازی می کنیم، با دریافت دومین جلد کامل، همان 10 کلون "نازک" را خواهد داشت. آیا این فرصت را نمی بینید؟
DS: ما باید مسائل امنیتی را در اینجا اضافه کنیم. این نوع سازماندهی به این معنی است که این پاد دارای امتیازات (قابلیت) بالایی است، زیرا می تواند عملیات غیر استاندارد را روی سیستم فایل انجام دهد ... اما تکرار می کنم: معتقدم در میان مدت آنها ذخیره سازی را در Kubernetes و در ابرها کل داستان را با حجم درست می کنند - همه چیز "فقط کار خواهد کرد". تغییر اندازه، شبیه سازی وجود خواهد داشت... یک حجم وجود دارد - می گوییم: "یکی جدید بر اساس آن ایجاد کنید" و بعد از یک ثانیه و نیم آنچه را که نیاز داریم به دست می آوریم.
NS: من برای چند ترابایت به یک و نیم ثانیه اعتقاد ندارم. در Ceph شما خودتان این کار را انجام می دهید، اما در مورد ابرها صحبت می کنید. به فضای ابری بروید، یک کلون از یک حجم EBS چند ترابایتی روی EC2 بسازید و ببینید کارایی آن چگونه خواهد بود. چند ثانیه طول نمیکشه من خیلی علاقه دارم که کی به این سطح برسند. میفهمم چی میگی ولی التماس می کنم فرق کنم.
DS: باشه ولی گفتم میان مدت نه کوتاه مدت. برای چندین سال.
درباره اپراتور PostgreSQL از Zalando
در میانه این جلسه، Alexey Klyukin، توسعه دهنده سابق Zalando نیز به آن ملحق شد و در مورد تاریخچه اپراتور PostgreSQL صحبت کرد:
خیلی خوب است که به طور کلی به این موضوع پرداخته می شود: هم Postgres و هم Kubernetes. زمانی که ما در سال 2017 این کار را در Zalando شروع کردیم، موضوعی بود که همه می خواستند انجام دهند، اما هیچ کس آن را انجام نداد. همه قبلا Kubernetes داشتند، اما وقتی از آنها پرسیدند که با پایگاه‌های داده چه کار کنند، حتی مردم هم دوست دارند ، که K8s را موعظه می کرد، چیزی شبیه به این گفت:
به سرویس های مدیریت شده بروید و از آنها استفاده کنید، پایگاه داده را در Kubernetes اجرا نکنید. در غیر این صورت، K8s شما تصمیم می گیرد، برای مثال، ارتقاء دهد، تمام گره ها را خاموش کند، و داده های شما به دور، بسیار دور پرواز خواهد کرد.
تصمیم گرفتیم اپراتوری بسازیم که برخلاف این توصیه، پایگاه داده Postgres را در Kubernetes راه اندازی کند. و ما دلیل خوبی داشتیم - . این یک failover خودکار برای PostgreSQL است که به درستی انجام شده است. استفاده از etcd، کنسول یا ZooKeeper به عنوان ذخیره‌سازی اطلاعات در مورد خوشه. چنین مخزنی که به هر کسی که بپرسد، مثلاً رهبر فعلی چیست، همان اطلاعات را می دهد - علیرغم اینکه همه چیز را توزیع کرده ایم - تا مغز شکافی وجود نداشته باشد. به علاوه ما داشتیم برای او.
به طور کلی، نیاز شرکت به خطای خودکار پس از مهاجرت از یک مرکز داده سخت افزاری داخلی به ابر ظاهر شد. ابر مبتنی بر راه حل اختصاصی PaaS (پلتفرم به عنوان سرویس) بود. این منبع باز است، اما برای راه‌اندازی آن کار زیادی لازم بود. نامیده شد .
در ابتدا کوبرنتیس وجود نداشت. به طور دقیق تر، زمانی که راه حل خودمان به کار گرفته شد، K8 از قبل وجود داشت، اما آنقدر خام بود که برای تولید مناسب نبود. به نظر من سال 2015 یا 2016 بود. تا سال 2017، Kubernetes کم و بیش بالغ شده بود - نیاز به مهاجرت به آنجا وجود داشت.
و ما قبلا یک کانتینر داکر داشتیم. یک PaaS وجود داشت که از Docker استفاده می کرد. چرا K8s را امتحان نمی کنید؟ چرا اپراتور خود را نمی نویسید؟ مورات کابیلف، که از آویتو به ما آمد، این را به عنوان یک پروژه به ابتکار خود - "بازی کردن" - شروع کرد و پروژه "بلند شد".
اما به طور کلی می خواستم در مورد AWS صحبت کنم. چرا کد مربوط به AWS تاریخی وجود داشت...
وقتی چیزی را در Kubernetes اجرا می کنید، باید بدانید که K8s چنین کاری در حال پیشرفت است. به طور مداوم در حال توسعه، بهبود و حتی از زمان به زمان شکسته شدن است. شما باید تمام تغییرات در Kubernetes را زیر نظر داشته باشید، باید آماده باشید که اگر اتفاقی افتاد در آن غوطه ور شوید و نحوه عملکرد آن را با جزئیات یاد بگیرید - شاید بیشتر از آنچه می خواهید. این، در اصل، برای هر پلتفرمی که پایگاه داده خود را بر روی آن اجرا می کنید، صدق می کند...
بنابراین، وقتی بیانیه را انجام دادیم، Postgres را روی یک حجم خارجی (EBS در این مورد، از آنجایی که ما روی AWS کار می‌کردیم) داشتیم. پایگاه داده بزرگ شد، در برخی موارد لازم بود اندازه آن تغییر کند: به عنوان مثال، اندازه اولیه EBS 100 ترابایت بود، پایگاه داده به آن بزرگ شد، اکنون می خواهیم EBS 200 ترابایت بسازیم. چگونه؟ فرض کنید می‌توانید یک Dump/Restore را در یک نمونه جدید انجام دهید، اما این کار زمان زیادی می‌برد و مستلزم خرابی است.
بنابراین، من یک تغییر اندازه می خواستم که پارتیشن EBS را بزرگ کند و سپس به سیستم فایل بگوید از فضای جدید استفاده کند. و ما این کار را انجام دادیم، اما در آن زمان Kubernetes هیچ API برای عملیات تغییر اندازه نداشت. از آنجایی که ما روی AWS کار می کردیم، برای API آن کد نوشتیم.
هیچ کس شما را از انجام همین کار برای پلتفرم های دیگر باز نمی دارد. در بیانیه هیچ اشاره ای وجود ندارد که آن را فقط می توان بر روی AWS اجرا کرد و در سایر موارد کار نخواهد کرد. به طور کلی، این یک پروژه منبع باز است: اگر کسی بخواهد ظهور استفاده از API جدید را سرعت بخشد، خوش آمدید. بخور , pull requests - تیم Zalando سعی می کند خیلی سریع به آنها پاسخ دهد و اپراتور را ارتقا دهد. تا جایی که من می دانم پروژه است در Google Summer of Code و برخی ابتکارات مشابه دیگر. زالاندو بسیار فعال روی آن کار می کند.
جایزه PS!
اگر به موضوع PostgreSQL و Kubernetes علاقه مند هستید، لطفاً توجه داشته باشید که سه شنبه بعدی Postgres هفته گذشته برگزار شد، جایی که من با نیکولای صحبت کردم. الکساندر کوکوشکین از زالاندو. ویدیو از آن موجود است .
PPS
در وبلاگ ما نیز بخوانید:
- «"؛
- «"؛
- «"؛
- «'.
منبع: www.habr.com