اپراتور در Kubernetes برای مدیریت خوشه های پایگاه داده. ولادیسلاو کلیمنکو (Altinity، 2019)

این گزارش به مسائل عملی توسعه یک اپراتور در Kubernetes، طراحی معماری و اصول اولیه عملیاتی آن اختصاص دارد.

در بخش اول گزارش به موارد زیر می پردازیم:

• اپراتور در Kubernetes چیست و چرا مورد نیاز است.
• چگونه اپراتور دقیقاً مدیریت سیستم های پیچیده را ساده می کند.
• آنچه اپراتور می تواند و نمی تواند انجام دهد.

بعد، اجازه دهید به بحث در مورد ساختار داخلی اپراتور بپردازیم. بیایید گام به گام معماری و عملکرد اپراتور را بررسی کنیم. بیایید با جزئیات به آن نگاه کنیم:

• تعامل بین اپراتور و Kubernetes.
• اپراتور چه عملکردهایی را بر عهده می گیرد و چه وظایفی را به Kubernetes محول می کند.

بیایید به مدیریت خرده ها و کپی های پایگاه داده در Kubernetes نگاه کنیم.
در مرحله بعد، در مورد مسائل مربوط به ذخیره سازی اطلاعات بحث خواهیم کرد:

• نحوه کار با Persistent Storage از دیدگاه اپراتور.
• مشکلات استفاده از Local Storage

در قسمت پایانی گزارش به نمونه های کاربردی کاربرد می پردازیم clickhouse-operator با Amazon یا Google Cloud Service. این گزارش بر اساس نمونه ای از توسعه و تجربه عملیاتی یک اپراتور برای ClickHouse است.

ویدئو:

نام من ولادیسلاو کلیمنکو است. امروز می خواستم در مورد تجربه خود در توسعه و راه اندازی یک اپراتور صحبت کنم و این یک اپراتور تخصصی برای مدیریت کلاسترهای پایگاه داده است. مثلا ClickHouse-operator برای مدیریت خوشه ClickHouse.

چرا ما این فرصت را داریم که در مورد اپراتور و ClickHouse صحبت کنیم؟

• ما از ClickHouse پشتیبانی و توسعه می دهیم.
• در حال حاضر، ما سعی می کنیم به آرامی سهم خود را در توسعه ClickHouse داشته باشیم. و ما از نظر حجم تغییرات انجام شده در ClickHouse بعد از Yandex دوم هستیم.
• ما در حال تلاش برای انجام پروژه های اضافی برای اکوسیستم ClickHouse هستیم.

می خواهم در مورد یکی از این پروژه ها به شما بگویم. این مربوط به ClickHouse-operator برای Kubernetes است.

در گزارش خود می خواهم به دو موضوع بپردازم:

• اولین موضوع این است که اپراتور مدیریت پایگاه داده ClickHouse ما در Kubernetes چگونه کار می کند.
• موضوع دوم این است که هر اپراتور چگونه کار می کند، یعنی چگونه با Kubernetes تعامل می کند.

با این حال، این دو سوال در سراسر گزارش من تلاقی می کنند.

چه کسی علاقه مند به گوش دادن به آنچه من می خواهم بگویم؟

• برای کسانی که اپراتورها را اداره می کنند بسیار مورد علاقه خواهد بود.
• یا برای کسانی که می‌خواهند خود را بسازند تا بفهمند چگونه در داخل کار می‌کند، چگونه اپراتور با Kubernetes تعامل می‌کند و چه مشکلاتی ممکن است ظاهر شود.

برای درک بهتر آنچه که امروز در مورد آن صحبت خواهیم کرد، بهتر است بدانید Kubernetes چگونه کار می کند و آموزش های اولیه ابری داشته باشید.

کلیک هاوس چیست؟ این یک پایگاه داده ستونی با ویژگی های خاص برای پردازش آنلاین پرس و جوهای تحلیلی است. و کاملا متن باز است.

و دانستن تنها دو چیز برای ما مهم است. باید بدانید که این یک پایگاه داده است، بنابراین آنچه به شما خواهم گفت تقریباً برای هر پایگاه داده قابل اجرا خواهد بود. و این واقعیت که ClickHouse DBMS بسیار خوب مقیاس می شود، مقیاس پذیری تقریباً خطی می دهد. و بنابراین، حالت خوشه یک حالت طبیعی برای ClickHouse است. و ما بیشتر علاقه مند به بحث در مورد نحوه سرویس دهی به خوشه ClickHouse در Kubernetes هستیم.

چرا او آنجا مورد نیاز است؟ چرا خودمان نمی توانیم به کار خود ادامه دهیم؟ و پاسخ ها بخشی فنی و بخشی سازمانی است.

• در عمل، ما به طور فزاینده‌ای با وضعیتی مواجه می‌شویم که در شرکت‌های بزرگ، تقریباً همه اجزا در حال حاضر در Kubernetes هستند. پایگاه های داده در خارج باقی می مانند.
• و این سوال به طور فزاینده ای پرسیده می شود: "آیا می توان این را در داخل قرار داد؟" بنابراین، شرکت های بزرگ در تلاش هستند تا حداکثر یکسان سازی مدیریت را به دست آورند تا بتوانند به سرعت انبارهای داده خود را مدیریت کنند.
• و این به ویژه اگر به حداکثر فرصت برای تکرار همان چیز در یک مکان جدید نیاز دارید، یعنی حداکثر قابلیت حمل، کمک می کند.

چقدر آسان یا سخت است؟ البته این کار با دست هم قابل انجام است. اما این خیلی ساده نیست، زیرا ما پیچیدگی بیشتری برای مدیریت خود Kubernetes داریم، اما در عین حال ویژگی های ClickHouse روی هم قرار می گیرند. و چنین تجمعی نتیجه می دهد.

و همه اینها مجموعه نسبتاً بزرگی از فناوری ها را ارائه می دهد که مدیریت آنها بسیار دشوار می شود ، زیرا Kubernetes مسائل روزمره خود را به کار می گیرد و ClickHouse مسائل مربوط به خود را به عملیات روزمره می آورد. به خصوص اگر ما چندین ClickHouse داشته باشیم و دائماً نیاز به انجام کاری با آنها داشته باشیم.

با یک پیکربندی پویا، ClickHouse دارای تعداد نسبتاً زیادی مشکل است که بار ثابتی را روی DevOps ایجاد می کند:

• وقتی می خواهیم چیزی را در ClickHouse تغییر دهیم، مثلاً یک replica یا shard اضافه کنیم، سپس باید پیکربندی را مدیریت کنیم.
• سپس طرح داده را تغییر دهید، زیرا ClickHouse یک روش اشتراک گذاری خاص دارد. در آنجا باید نمودار داده را بچینید، تنظیمات را بچینید.
• باید نظارت را تنظیم کنید.
• جمع آوری سیاههها برای خرده های جدید، برای کپی های جدید.
• مراقب ترمیم باشید
• و راه اندازی مجدد کنید.

اینها کارهای معمولی هستند که من واقعاً دوست دارم استفاده از آنها را آسانتر کنم.

خود Kubernetes به خوبی در عملیات کمک می کند، اما در موارد اساسی سیستم.

Kubernetes در تسهیل و خودکارسازی مواردی مانند:

• بهبود.
• راه اندازی مجدد.
• مدیریت سیستم ذخیره سازی

این خوب است، این مسیر درستی است، اما او در مورد نحوه عملکرد یک کلاستر پایگاه داده کاملاً بی اطلاع است.

ما بیشتر می خواهیم، ​​می خواهیم کل پایگاه داده در Kubernetes کار کند.

من می‌خواهم چیزی شبیه یک دکمه قرمز جادویی بزرگ را دریافت کنم که شما آن را فشار می‌دهید و خوشه‌ای با کارهای روزمره که باید حل شوند در کل چرخه زندگی خود مستقر شده و نگهداری می‌شوند. خوشه ClickHouse در Kubernetes.

و ما سعی کردیم راه حلی بسازیم که به سهولت کار کمک کند. این یک اپراتور ClickHouse برای Kubernetes از Altinity است.

اپراتور برنامه ای است که وظیفه اصلی آن مدیریت برنامه های دیگر است، یعنی مدیر است.

و حاوی الگوهای رفتاری است. شما می توانید این دانش مدون را در مورد حوزه موضوعی بنامید.

و وظیفه اصلی او آسان کردن زندگی DevOps و کاهش مدیریت میکرو است، به طوری که او (DevOps) قبلاً در سطوح بالا فکر می کند، به عنوان مثال، به طوری که او (DevOps) درگیر میکرومدیریت نمی شود، به طوری که پیکربندی نمی کند. تمام جزئیات به صورت دستی

و فقط اپراتور یک دستیار رباتیک است که با ریزکارها سروکار دارد و به DevOps کمک می کند.

چرا به اپراتور نیاز دارید؟ او به ویژه در دو زمینه عملکرد خوبی دارد:

• وقتی متخصصی که با ClickHouse سر و کار دارد، تجربه کافی نداشته باشد، اما قبلاً نیاز به کار با ClickHouse داشته باشد، اپراتور عملیات را تسهیل می کند و به شما اجازه می دهد تا یک خوشه ClickHouse را با پیکربندی نسبتاً پیچیده، بدون پرداختن به جزئیات زیاد درباره نحوه کارکرد آن، کار کنید. داخل. شما فقط به او وظایف سطح بالا می دهید، و این کار می کند.
• و دومین وظیفه ای که در آن بهترین عملکرد را دارد زمانی است که لازم است تعداد زیادی از وظایف معمولی را خودکار کنید. ریزکارها را از مدیران سیستم حذف می کند.

این مورد بیشتر مورد نیاز کسانی است که به تازگی سفر خود را شروع کرده اند یا کسانی که نیاز به اتوماسیون زیادی دارند.

رویکرد مبتنی بر اپراتور چه تفاوتی با سایر سیستم ها دارد؟ هلم وجود دارد. همچنین به نصب ClickHouse کمک می کند؛ شما می توانید نمودارهای فرمان ترسیم کنید، که حتی کل خوشه ClickHouse را نصب می کند. پس تفاوت بین اپراتور و همان مثلا Helm چیست؟

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

این قسمت مقدماتی بود، بیایید ادامه دهیم.

چگونه اپراتور خود را بسازیم؟ ما سعی می کنیم به این مسئله نزدیک شویم تا خوشه ClickHouse را به عنوان یک منبع واحد مدیریت کنیم.

در اینجا ما داده های ورودی را در سمت چپ تصویر داریم. این YAML با مشخصات خوشه ای است که به روش کلاسیک از طریق kubectl به Kubernetes منتقل می شود. در آنجا اپراتور ما آن را برمی دارد و جادوی خود را انجام می دهد. و در خروجی، طرح زیر را دریافت می کنیم. این یک پیاده سازی از ClickHouse در Kubernetes است.

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

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

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

بیایید با یک مشکل عملی شروع کنیم. اولین کار، جایی که همه ما می خواهیم شروع کنیم، اجرای مثال اول به نحوی است. چگونه می توانم ClickHouse را با استفاده از اپراتور راه اندازی کنم، حتی اگر واقعاً ندانم که چگونه کار می کند؟ ما در حال نوشتن یک مانیفست هستیم، زیرا ... تمام ارتباطات با k8s ارتباط از طریق مانیفست است.

این یک مانیفست بسیار پیچیده است. آنچه ما با رنگ قرمز برجسته کرده ایم، چیزی است که باید روی آن تمرکز کنیم. از اپراتور می خواهیم که یک خوشه به نام دمو ایجاد کند.

اینها در حال حاضر نمونه های اساسی هستند. ذخیره سازی هنوز توضیح داده نشده است، اما کمی بعد به ذخیره سازی باز خواهیم گشت. در حال حاضر، ما پویایی توسعه خوشه را مشاهده خواهیم کرد.

ما این مانیفست را ایجاد کردیم. ما آن را به اپراتور خود می دهیم. او کار کرد، او جادو کرد.

ما به کنسول نگاه می کنیم. سه جزء مورد توجه هستند: یک Pod، دو سرویس و یک StatefulSet.

اپراتور کار کرده است، و ما می توانیم ببینیم که او دقیقا چه چیزی را ایجاد کرده است.

او چیزی شبیه به این خلق می کند. ما یک StatefulSet، Pod، ConfigMap برای هر replica، ConfigMap برای کل خوشه داریم. خدمات به عنوان نقاط ورود به خوشه مورد نیاز است.

سرویس ها سرویس Load Balancer مرکزی هستند و همچنین می توانند برای هر ماکت، برای هر خرده استفاده شوند.

خوشه اصلی ما چیزی شبیه به این است. از یک گره منفرد است.

بیایید جلوتر برویم و مسائل را پیچیده کنیم. ما باید خوشه را خرد کنیم.

وظایف ما در حال رشد است، پویایی شروع می شود. ما می خواهیم یک تکه اضافه کنیم. توسعه را دنبال می کنیم. ما در حال تغییر مشخصات خود هستیم. ما نشان می دهیم که دو خرده می خواهیم.

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

ما اپراتور YAML را تغذیه می کنیم و می بینیم چه اتفاقی می افتد.

اپراتور فکر کرد و موجودیت های زیر را ساخت. ما در حال حاضر دو پاد، سه سرویس و ناگهان 2 StatefulSets داریم. چرا 2 StatefulSets؟

در نمودار به این صورت بود - این حالت اولیه ما است، زمانی که یک غلاف داشتیم.

اینجوری شد تا اینجا همه چیز ساده است، تکراری شده است.

و چرا دو StatefulSets شدند؟ در اینجا باید به این سوال بپردازیم که چگونه Pods در Kubernetes مدیریت می شود.

یک شی به نام StatefulSet وجود دارد که به شما امکان می دهد مجموعه ای از Pods را از یک الگو ایجاد کنید. عامل کلیدی در اینجا قالب است. و می توانید پادهای زیادی را با استفاده از یک الگو در یک StatefulSet راه اندازی کنید. و عبارت کلیدی در اینجا "بسیاری از پادها برای یک الگو" است.

و وسوسه بزرگی برای ایجاد کل خوشه وجود داشت و آن را در یک StatefulSet قرار داد. کار میکنه مشکلی نداره اما یک اخطار وجود دارد. اگر بخواهیم یک خوشه ناهمگن، یعنی از چندین نسخه ClickHouse جمع آوری کنیم، سؤالات شروع می شود. بله، StatefulSet می‌تواند یک به‌روزرسانی را انجام دهد، و در آنجا می‌توانید نسخه جدیدی را ارائه کنید، توضیح دهید که نباید بیش از تعداد زیادی گره را همزمان امتحان کنید.

اما اگر کار را برون یابی کنیم و بگوییم که می‌خواهیم یک خوشه کاملاً ناهمگن بسازیم و نمی‌خواهیم با استفاده از یک به‌روزرسانی از نسخه قدیمی به نسخه جدید تغییر کنیم، بلکه فقط می‌خواهیم یک خوشه ناهمگن ایجاد کنیم. از نسخه های مختلف ClickHouse و از نظر فضای ذخیره سازی متفاوت. مثلاً می‌خواهیم چند کپی روی دیسک‌های جداگانه بسازیم، روی دیسک‌های کند، به طور کلی، یک خوشه ناهمگن را کاملاً بسازیم. و با توجه به این واقعیت که StatefulSet یک راه حل استاندارد از یک الگو ایجاد می کند، هیچ راهی برای انجام این کار وجود ندارد.

پس از اندکی فکر، تصمیم گرفته شد که این کار را به این صورت انجام دهیم. ما هر کپی را در StatefulSet خود داریم. اشکالاتی در این راه حل وجود دارد، اما در عمل همه آن به طور کامل توسط اپراتور کپسوله می شود. و مزایای زیادی دارد. ما می‌توانیم خوشه‌ای را که می‌خواهیم، ​​برای مثال، یک خوشه کاملاً ناهمگن بسازیم. بنابراین، در خوشه ای که در آن دو خرده با یک ماکت داریم، 2 StatefulSets و 2 Pods خواهیم داشت دقیقاً به این دلیل که ما این رویکرد را به دلایل ذکر شده در بالا انتخاب کردیم تا بتوانیم یک خوشه ناهمگن بسازیم.

به مشکلات عملی برگردیم. در خوشه ما باید کاربران را پیکربندی کنیم، یعنی. شما باید پیکربندی ClickHouse را در Kubernetes انجام دهید. اپراتور تمام امکانات را برای این کار فراهم می کند.

ما می توانیم آنچه را که می خواهیم مستقیماً در YAML بنویسیم. همه گزینه‌های پیکربندی مستقیماً از این YAML به تنظیمات ClickHouse نگاشت می‌شوند، که سپس در سراسر خوشه توزیع می‌شوند.

می توانید آن را اینگونه بنویسید. این برای مثال است. رمز عبور را می توان رمزگذاری کرد. کاملاً همه گزینه های پیکربندی ClickHouse پشتیبانی می شوند. در اینجا فقط یک مثال است.

پیکربندی خوشه به صورت ConfigMap توزیع می شود. در عمل، به‌روزرسانی ConfigMap فوراً رخ نمی‌دهد، بنابراین اگر خوشه بزرگ باشد، فرآیند فشار دادن پیکربندی مدتی طول می‌کشد. اما همه اینها برای استفاده بسیار راحت است.

بیایید کار را پیچیده کنیم. خوشه در حال توسعه است. ما می خواهیم داده ها را تکرار کنیم. یعنی ما در حال حاضر دو خرده داریم، هر کدام یک کپی، و کاربران پیکربندی شده اند. ما در حال رشد هستیم و می خواهیم تکرار کنیم.

برای تکرار به چه چیزی نیاز داریم؟

به ZooKeeper نیازمندیم در ClickHouse، Replication با استفاده از ZooKeeper ساخته می شود. ZooKeeper مورد نیاز است تا نسخه‌های مختلف ClickHouse درباره اینکه کدام بلوک‌های داده در کدام ClickHouse هستند اتفاق نظر داشته باشند.

ZooKeeper می تواند توسط هر کسی استفاده شود. اگر شرکت دارای ZooKeeper خارجی باشد، می توان از آن استفاده کرد. اگر نه، می توانید آن را از مخزن ما نصب کنید. یک نصب کننده وجود دارد که این کار را آسان تر می کند.

و نمودار تعامل کل سیستم به این صورت است. ما Kubernetes را به عنوان یک پلت فرم داریم. اپراتور ClickHouse را اجرا می کند. من ZooKeeper را اینجا تصویر کردم. و اپراتور با ClickHouse و ZooKeeper تعامل دارد. یعنی نتیجه تعامل.

و همه اینها برای ClickHouse لازم است تا داده ها را با موفقیت در k8s تکرار کند.

بیایید اکنون به خود وظیفه نگاه کنیم، که مانیفست برای تکرار چگونه خواهد بود.

ما دو بخش را به مانیفست خود اضافه می کنیم. اولین مورد این است که ZooKeeper را از کجا تهیه کنید، که می تواند در داخل Kubernetes یا خارجی باشد. این فقط یک توصیف است. و ماکت سفارش می دهیم. آن ها ما دو کپی می خواهیم در کل باید 4 غلاف در خروجی داشته باشیم. ما در مورد ذخیره سازی به یاد داریم، کمی بعد باز خواهد گشت. ذخیره سازی یک داستان جداگانه است.

اینجوری بود

اینجوری میشه کپی اضافه شده است. مورد چهارم مناسب نبود، ما معتقدیم که می تواند تعداد زیادی از آنها آنجا باشد. و ZooKeeper به کنار اضافه شده است. طرح ها پیچیده تر می شوند.

و زمان اضافه کردن کار بعدی فرا رسیده است. ما ذخیره سازی دائمی را اضافه خواهیم کرد.

برای ذخیره سازی مداوم گزینه های مختلفی داریم.

اگر در یک ارائه دهنده ابری اجرا می کنیم، به عنوان مثال، از آمازون، گوگل استفاده می کنیم، وسوسه بزرگی برای استفاده از فضای ذخیره سازی ابری وجود دارد. خیلی راحته خوبه

و یک گزینه دوم وجود دارد. این برای ذخیره سازی محلی است، زمانی که دیسک های محلی در هر گره داریم. اجرای این گزینه بسیار دشوارتر است، اما در عین حال سازنده تر است.

بیایید ببینیم چه چیزی در مورد ذخیره سازی ابری داریم.

مزایایی وجود دارد. پیکربندی آن بسیار آسان است. ما به سادگی از ارائه دهنده ابر سفارش می دهیم که لطفاً ظرفیت فلان و فلان کلاس را در اختیار ما قرار دهد. کلاس ها توسط ارائه دهندگان به طور مستقل برنامه ریزی می شوند.

و یک ایراد دارد. برای برخی، این یک اشکال غیر بحرانی است. البته برخی مشکلات عملکردی نیز وجود خواهد داشت. استفاده از آن بسیار راحت و قابل اعتماد است، اما برخی از اشکالات عملکردی بالقوه وجود دارد.

و چون ClickHouse به طور خاص بر بهره وری تمرکز دارد، حتی می توان گفت که هر چیزی را که می تواند از بین می برد، به همین دلیل است که بسیاری از مشتریان سعی می کنند حداکثر بهره وری را کاهش دهند.

و برای استفاده حداکثری از آن، به ذخیره سازی محلی نیاز داریم.

Kubernetes سه انتزاع برای استفاده از ذخیره سازی محلی در Kubernetes ارائه می دهد. این:

• EmptyDir
• HostPath.
• محلی

بیایید ببینیم که چگونه آنها متفاوت هستند و چگونه آنها مشابه هستند.

اولا، در هر سه رویکرد ما ذخیره سازی داریم - این ها دیسک های محلی هستند که در همان گره فیزیکی k8s قرار دارند. اما تفاوت هایی با هم دارند.

بیایید با ساده ترین آن، یعنی valaDir شروع کنیم. این در عمل چیست؟ در مشخصات خود، از سیستم کانتینری‌سازی (اغلب Docker) می‌خواهیم تا دسترسی به پوشه‌ای در دیسک محلی را برای ما فراهم کند.

در عمل، داکر یک پوشه موقت در جایی در مسیرهای خود ایجاد می کند و آن را هش طولانی می نامد. و یک رابط برای دسترسی به آن فراهم می کند.

این از نظر عملکرد چگونه کار خواهد کرد؟ این با سرعت دیسک محلی کار خواهد کرد، یعنی. این دسترسی کامل به پیچ شماست.

اما این مورد ایرادی دارد. مداوم در این مورد کاملا مشکوک است. اولین باری که داکر با کانتینرها حرکت می کند، Persistent گم می شود. اگر Kubernetes به دلایلی بخواهد این Pod را به دیسک دیگری منتقل کند، داده ها از بین می روند.

این رویکرد برای تست ها خوب است، زیرا از قبل سرعت عادی را نشان می دهد، اما برای موارد جدی این گزینه مناسب نیست.

بنابراین رویکرد دوم وجود دارد. این hostPath است. اگر به اسلاید قبلی و این اسلاید نگاه کنید، فقط یک تفاوت را می بینید. پوشه ما مستقیماً از Docker به گره Kubernetes منتقل شد. اینجا کمی ساده تر است. ما مستقیماً مسیری را در سیستم فایل محلی که می خواهیم داده های خود را در آن ذخیره کنیم، مشخص می کنیم.

این روش مزایایی دارد. این در حال حاضر یک Persistent واقعی و کلاسیک است. ما داده هایی را در آدرسی روی دیسک ضبط خواهیم کرد.

معایبی هم دارد. این پیچیدگی مدیریت است. Kubernetes ما ممکن است بخواهند Pod را به گره فیزیکی دیگری منتقل کنند. و اینجاست که DevOps وارد عمل می شود. او باید به درستی به کل سیستم توضیح دهد که این غلاف‌ها را فقط می‌توان به گره‌هایی منتقل کرد که روی آن‌ها چیزی در امتداد این مسیرها نصب شده است، و نه بیشتر از یک گره در یک زمان. خیلی سخته

به خصوص برای این اهداف، ما قالب هایی را در اپراتور خود ساختیم تا این همه پیچیدگی را پنهان کنیم. و شما می توانید به سادگی بگویید: "من می خواهم یک نمونه از ClickHouse برای هر گره فیزیکی و در طول فلان مسیر داشته باشم."

اما ما تنها کسانی نیستیم که به این نیاز نیاز داریم، بنابراین آقایان خود کوبرنتیس نیز می‌دانند که مردم می‌خواهند به دیسک‌های فیزیکی دسترسی داشته باشند، بنابراین لایه سومی را ارائه می‌کنند.

به آن محلی می گویند. عملا هیچ تفاوتی با اسلاید قبلی ندارد. فقط قبل از تأیید دستی لازم بود که ما نمی توانیم این غلاف ها را از گره به گره منتقل کنیم، زیرا آنها باید در مسیری به یک دیسک فیزیکی محلی متصل شوند، اما اکنون تمام این دانش در خود Kubernetes کپسوله شده است. و به نظر می رسد که پیکربندی آن بسیار ساده تر است.

به مشکل عملی خود برگردیم. بیایید به قالب YAML برگردیم. در اینجا ما ذخیره سازی واقعی داریم. ما به آن بازگشته ایم. ما قالب کلاسیک VolumeClaim را مانند k8s تنظیم کردیم. و ما توضیح می دهیم که چه نوع ذخیره سازی می خواهیم.

پس از این، k8s درخواست ذخیره سازی می کند. آن را در StatefulSet به ما اختصاص خواهد داد. و در نهایت در اختیار ClickHouse قرار خواهد گرفت.

ما این طرح را داشتیم. ذخیره‌سازی دائمی ما قرمز بود، که به نظر می‌رسد نشان می‌دهد که باید انجام شود.

و سبز می شود. اکنون طرح خوشه ClickHouse در k8s کاملاً نهایی شده است. ما خرده‌ها، کپی‌ها، ZooKeeper داریم، ما یک Persistent واقعی داریم که به هر طریقی پیاده‌سازی می‌شود. این طرح در حال حاضر به طور کامل عملیاتی شده است.

ما به زندگی ادامه می دهیم. خوشه ما در حال توسعه است. و الکسی تلاش می کند و نسخه جدیدی از ClickHouse را منتشر می کند.

یک کار عملی ایجاد می شود - آزمایش نسخه جدید ClickHouse در خوشه ما. و، طبیعتا، شما نمی‌خواهید همه آن را منتشر کنید؛ می‌خواهید یک نسخه جدید را در یک ماکت در جایی در گوشه‌ای دورتر قرار دهید، و شاید نه یک نسخه جدید، بلکه دو نسخه در آن واحد، زیرا اغلب منتشر می‌شوند.

در این مورد چه بگوییم؟

در اینجا ما دقیقاً چنین فرصتی داریم. اینها قالب های پاد هستند. می توانید بنویسید که اپراتور ما به طور کامل به شما امکان می دهد یک خوشه ناهمگن بسازید. آن ها پیکربندی کنید، از همه کپی‌ها در یک دسته شروع کنید، به هر ماکت شخصی پایان دهید، کدام نسخه را می‌خواهیم ClickHouse، کدام نسخه را ذخیره می‌خواهیم. ما می توانیم به طور کامل خوشه را با پیکربندی مورد نیاز خود پیکربندی کنیم.

بیایید کمی عمیق تر به درون برویم. قبل از این، ما در مورد نحوه عملکرد ClickHouse-operator در رابطه با ویژگی های ClickHouse صحبت کردیم.

اکنون می خواهم چند کلمه در مورد نحوه عملکرد هر اپراتور به طور کلی و همچنین نحوه تعامل آن با K8 بگویم.

بیایید ابتدا به تعامل با K8s نگاه کنیم. چه اتفاقی می‌افتد وقتی کوبکتل را اعمال می‌کنیم؟ اشیاء ما در etcd از طریق API ظاهر می شوند.

به عنوان مثال، اشیاء اصلی Kubernetes: pod، StatefulSet، service، و غیره در لیست قرار دارند.

در عین حال، هنوز هیچ اتفاق فیزیکی نمی افتد. این اشیاء باید در خوشه مادی شوند.

برای این منظور یک کنترلر ظاهر می شود. کنترلر یک جزء ویژه k8s است که می تواند این توضیحات را تحقق بخشد. او می داند که چگونه و چه کاری باید انجام دهد. او می داند که چگونه کانتینرها را اجرا کند، چه چیزی باید در آنجا پیکربندی شود تا سرور کار کند.

و اشیاء ما را در K8s مادیت می کند.

اما ما می‌خواهیم نه تنها با pods و StatefulSets کار کنیم، بلکه می‌خواهیم یک ClickHouseInstallation، یعنی یک شی از نوع ClickHouse ایجاد کنیم تا با آن به عنوان یک کل کار کنیم. تاکنون چنین امکانی وجود ندارد.

اما K8s چیز خوب زیر را دارد. ما می خواهیم جایی مانند این موجودیت پیچیده داشته باشیم که در آن خوشه ما از pods و StatefulSet جمع آوری شود.

و برای این کار چه باید کرد؟ ابتدا، تعریف منابع سفارشی وارد تصویر می شود. آن چیست؟ این یک توضیح برای K8 است، که شما یک نوع داده دیگر خواهید داشت، که می‌خواهیم یک منبع سفارشی به pod اضافه کنیم، StatefulSet، که در داخل پیچیده خواهد بود. این توضیحی از ساختار داده است.

ما همچنین آن را از طریق kubectl application به آنجا ارسال می کنیم. Kubernetes با خوشحالی آن را گرفت.

و اکنون در فضای ذخیره سازی ما، شیء موجود در etcd این فرصت را دارد که یک منبع سفارشی به نام ClickHouseInstallation را ضبط کند.

اما در حال حاضر هیچ اتفاق دیگری نخواهد افتاد. یعنی اگر اکنون فایل YAML را که در توصیف خرده‌ها و کپی‌ها نگاه کردیم ایجاد کنیم و بگوییم «kubectl application»، Kubernetes آن را می‌پذیرد، آن را در etcd قرار می‌دهد و می‌گوید: «عالی است، اما نمی‌دانم چه کار کنم. با آن. من نمی دانم چگونه ClickHouseInstallation را حفظ کنم."

بر این اساس، ما به کسی نیاز داریم که به Kubernetes در ارائه نوع داده جدید کمک کند. در سمت چپ یک کنترلر بومی Kubernetes داریم که با انواع داده های بومی کار می کند. و در سمت راست باید یک کنترلر سفارشی داشته باشیم که بتواند با انواع داده های سفارشی کار کند.

و به نوعی دیگر عملگر نامیده می شود. من به طور خاص آن را در اینجا به عنوان Kubernetes گنجانده ام، زیرا می توان آن را خارج از K8s نیز اجرا کرد. البته اغلب اوقات، همه عملگرها در Kubernetes اجرا می شوند، اما هیچ چیز مانع از ایستادن آن در خارج نمی شود، بنابراین در اینجا به طور خاص به بیرون منتقل می شود.

و به نوبه خود، کنترلر سفارشی، که به عنوان اپراتور نیز شناخته می شود، از طریق API با Kubernetes تعامل می کند. از قبل می داند که چگونه با API تعامل کند. و او از قبل می‌داند که چگونه مدار پیچیده‌ای را که می‌خواهیم از یک منبع سفارشی بسازیم، تحقق بخشد. این دقیقاً همان کاری است که اپراتور انجام می دهد.

اپراتور چگونه کار می کند؟ بیایید به سمت راست نگاه کنیم تا ببینیم او چگونه این کار را انجام می دهد. بیایید دریابیم که چگونه اپراتور همه اینها را تحقق می بخشد و چگونه تعامل بیشتر با K8 ها رخ می دهد.

اپراتور یک برنامه است. او رویداد محور است. اپراتور با استفاده از Kubernetes API در رویدادها مشترک می شود. Kubernetes API دارای نقاط ورودی است که می توانید در رویدادها مشترک شوید. و اگر چیزی در K8s تغییر کند، Kubernetes رویدادها را برای همه ارسال می کند، یعنی. هرکسی که در این نقطه API مشترک شده است اعلان هایی دریافت خواهد کرد.

اپراتور در رویدادها مشترک است و باید نوعی واکنش نشان دهد. وظیفه آن پاسخگویی به رویدادهای نوظهور است.

رویدادها توسط به روز رسانی های خاص ایجاد می شوند. فایل YAML ما با توضیحات ClickHouseInstallation می رسد. او از طریق kubectl application به etcd رفت. یک رویداد در آنجا راه اندازی شد و در نتیجه این رویداد به اپراتور ClickHouse رسید. اپراتور این توضیحات را دریافت کرد. و او باید کاری انجام دهد. اگر به‌روزرسانی برای شی ClickHouseInstallation رسیده است، باید خوشه را به‌روزرسانی کنید. و وظیفه اپراتور به روز رسانی کلاستر است.

داره چیکار میکنه؟ ابتدا باید یک برنامه عملیاتی برای کارهایی که با این به روز رسانی انجام خواهیم داد، تهیه کنیم. به روز رسانی ها می توانند بسیار کوچک باشند، به عنوان مثال. در اجرای YAML کوچک است، اما می تواند تغییرات بسیار بزرگی را در خوشه ایجاد کند. بنابراین، اپراتور یک طرح ایجاد می کند، و سپس به آن پایبند است.

طبق این طرح، او شروع به پختن این سازه در داخل می کند تا غلاف ها، خدمات، یعنی. وظیفه اصلی او را انجام دهد. این نحوه ساخت یک خوشه ClickHouse در Kubernetes است.

حالا بیایید به موضوع جالبی بپردازیم. این یک تقسیم مسئولیت بین Kubernetes و اپراتور است، یعنی. Kubernetes چه می کند، اپراتور چه می کند، و چگونه آنها با یکدیگر تعامل دارند.

Kubernetes مسئول چیزهای سیستم است، به عنوان مثال. برای مجموعه ای اساسی از اشیاء که می توانند به عنوان دامنه سیستم تفسیر شوند. Kubernetes می داند که چگونه پادها را راه اندازی کند، چگونه کانتینرها را مجددا راه اندازی کند، چگونه حجم ها را نصب کند، چگونه با ConfigMap کار کند، به عنوان مثال. هر چیزی که بتوان آن را سیستم نامید.

اپراتورها در دامنه ها فعالیت می کنند. هر اپراتور برای حوزه موضوعی خود ساخته شده است. ما این کار را برای ClickHouse انجام دادیم.

و اپراتور دقیقاً بر حسب منطقه موضوع تعامل دارد، مانند اضافه کردن یک ماکت، ایجاد نمودار، تنظیم نظارت. این منجر به تقسیم می شود.

بیایید به یک مثال عملی نگاه کنیم که چگونه این تقسیم مسئولیت هنگام انجام عمل اضافه کردن replica رخ می دهد.

اپراتور وظیفه ای را دریافت می کند - اضافه کردن یک ماکت. اپراتور چه می کند؟ اپراتور محاسبه خواهد کرد که یک StatefulSet جدید باید ایجاد شود، که در آن فلان الگو، ادعای حجم، باید توضیح داده شود.

او همه را آماده کرد و به K8s منتقل کرد. او می گوید که به ConfigMap، StatefulSet، Volume نیاز دارد. Kubernetes در حال کار است. او واحدهای اساسی را که با آن ها کار می کند، مادی می کند.

و سپس ClickHouse-operator دوباره وارد بازی می شود. او در حال حاضر یک غلاف فیزیکی دارد که می تواند کاری انجام دهد. و ClickHouse-operator دوباره در شرایط دامنه کار می کند. آن ها به طور خاص ClickHouse، برای گنجاندن یک ماکت در یک خوشه، ابتدا باید طرح داده ای را که در این خوشه وجود دارد، پیکربندی کنید. و ثانیاً این ماکت باید در مانیتورینگ لحاظ شود تا به وضوح قابل ردیابی باشد. اپراتور قبلاً این را پیکربندی کرده است.

و تنها پس از آن خود ClickHouse وارد بازی می شود، یعنی. یک موجود سطح بالاتر دیگر این قبلاً یک پایگاه داده است. این نمونه خود را دارد، یک کپی پیکربندی شده دیگر که آماده پیوستن به خوشه است.

به نظر می رسد که زنجیره اجرا و تقسیم مسئولیت هنگام اضافه کردن یک ماکت بسیار طولانی است.

ما به وظایف عملی خود ادامه می دهیم. اگر از قبل یک خوشه دارید، می توانید پیکربندی را انتقال دهید.

ما آن را به گونه‌ای ساخته‌ایم که می‌توانید از طریق xml موجود، که ClickHouse آن را درک می‌کند، جای‌گذاری کنید.

شما می توانید ClickHouse را به خوبی تنظیم کنید. استقرار فقط منطقه‌ای همان چیزی است که هنگام توضیح hostPath، ذخیره‌سازی محلی، درباره آن صحبت کردم. این نحوه انجام صحیح استقرار منطقه ای است.

وظیفه عملی بعدی نظارت است.

اگر خوشه ما تغییر کند، باید به طور دوره ای نظارت را پیکربندی کنیم.

بیایید به نمودار نگاه کنیم. ما قبلاً در اینجا به فلش های سبز نگاه کرده ایم. حالا بیایید به فلش های قرمز نگاه کنیم. اینگونه است که می خواهیم خوشه خود را نظارت کنیم. چگونه معیارهای خوشه ClickHouse به Prometheus و سپس به Grafana می رسند.

مشکل نظارت چیست؟ چرا این به عنوان نوعی دستاورد معرفی می شود؟ مشکل در پویایی است. وقتی یک خوشه داریم و ایستا است، می توانیم یک بار نظارت را راه اندازی کنیم و دیگر مزاحم نباشیم.

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

خوشه ما چگونه توسعه یافت؟ در ابتدا او اینطور بود.

بعد اون اینجوری شد

آخرش اینجوری شد.

و نظارت به صورت خودکار توسط اپراتور انجام می شود. تنها نقطه ورود

و درست در خروجی به داشبورد Grafana نگاه می کنیم تا ببینیم که چگونه زندگی خوشه ما در داخل می جوشد.

به هر حال، داشبورد گرافانا نیز با اپراتور ما به طور مستقیم در کد منبع توزیع شده است. می توانید متصل شوید و استفاده کنید. DevOps ما این اسکرین شات را به من داد.

دوست داریم بعد کجا برویم؟ این:

• اتوماسیون تست را توسعه دهید. وظیفه اصلی تست خودکار نسخه های جدید است.
• ما همچنین واقعاً می خواهیم ادغام با ZooKeeper را خودکار کنیم. و برنامه هایی برای ادغام با ZooKeeper-operator وجود دارد. آن ها یک اپراتور برای ZooKeeper نوشته شده است و منطقی است که این دو اپراتور شروع به ادغام برای ایجاد راه حل راحت تری کنند.
• ما می خواهیم علائم حیاتی پیچیده تری را انجام دهیم.
• من با رنگ سبز مشخص کردم که به ارث بردن الگوها نزدیک می شویم - انجام شد، یعنی با انتشار بعدی اپراتور، ما قبلاً به ارث بردن الگوها خواهیم رسید. این یک ابزار قدرتمند است که به شما امکان می دهد پیکربندی های پیچیده را از قطعات بسازید.
• و ما خواهان اتوماسیون کارهای پیچیده هستیم. اصلی‌ترین آن، اشتراک‌گذاری مجدد است.

بیایید برخی از نتایج متوسط ​​را در نظر بگیریم.

در نتیجه چه چیزی بدست می آوریم؟ و آیا ارزش انجام آن را دارد یا خیر؟ آیا حتی لازم است که سعی کنیم پایگاه داده را به Kubernetes بکشیم و از عملگر به طور کلی و از عملگر Alitnity به طور خاص استفاده کنیم؟

در خروجی دریافت می کنیم:

• ساده سازی و اتوماسیون قابل توجه پیکربندی، استقرار و نگهداری.
• مانیتورینگ فوری داخلی.
• و قالب های مدون آماده استفاده برای موقعیت های پیچیده. اقدامی مانند افزودن ماکت نیازی به انجام دستی ندارد. اپراتور این کار را انجام می دهد.

فقط یک سوال آخر باقی مانده است ما قبلاً یک پایگاه داده در Kubernetes داریم، مجازی سازی. در مورد عملکرد چنین راه حلی، به خصوص که ClickHouse برای عملکرد بهینه شده است، چطور؟

پاسخ این است که همه چیز خوب است! من وارد جزئیات نمی شوم؛ این موضوع در گزارشی جداگانه است.

اما پروژه ای به عنوان TSBS وجود دارد. وظیفه اصلی آن چیست؟ این یک تست عملکرد پایگاه داده است. این تلاشی است برای مقایسه گرم با گرم، نرم با نرم.

او چگونه کار می کند؟ یک مجموعه داده تولید می شود. سپس این مجموعه داده بر روی پایگاه داده های مختلف با استفاده از مجموعه آزمایش های مشابه اجرا می شود. و هر پایگاه داده یک مشکل را به روشی که می داند حل می کند. و سپس می توانید نتایج را با هم مقایسه کنید.

در حال حاضر از یک دسته بزرگ از پایگاه های داده پشتیبانی می کند. من سه مورد اصلی را شناسایی کرده ام. این:

• TimescaleDB.
• InfluxDB.
• کلیک هاوس.

مقایسه ای نیز با راه حل مشابه دیگری انجام شد. مقایسه با RedShift. مقایسه در آمازون انجام شد. ClickHouse نیز در این زمینه از همه جلوتر است.

از آنچه گفتم چه نتیجه ای می توان گرفت؟

• DB در Kubernetes امکان پذیر است. احتمالاً هر یک ممکن است، اما در کل به نظر می رسد که ممکن است. ClickHouse در Kubernetes قطعاً با کمک اپراتور ما امکان پذیر است.
• اپراتور به خودکارسازی فرآیندها کمک می کند و واقعاً زندگی را آسان تر می کند.
• عملکرد عادی است.
• و به نظر ما این است که می توان و باید از آن استفاده کرد.

منبع باز - به ما بپیوندید!

همانطور که قبلاً گفتم، اپراتور یک محصول کاملاً متن باز است، بنابراین اگر حداکثر تعداد افراد از آن استفاده کنند بسیار خوب است. به ما بپیوند! ما منتظر همه شما هستیم!

از همه شما متشکرم

پرسش

با تشکر از گزارش! اسم من آنتون است. من از SEMrush هستم. من تعجب می کنم که چه خبر از ورود به سیستم. ما در مورد نظارت می شنویم، اما هیچ چیز در مورد ورود به سیستم، اگر در مورد کل خوشه صحبت کنیم. به عنوان مثال، ما یک کلاستر در مورد سخت افزار را مطرح کرده ایم. و ما از ورود به سیستم متمرکز استفاده می کنیم و آنها را با استفاده از وسایل استاندارد در یک پشته مشترک جمع آوری می کنیم. و سپس از آنجا داده‌هایی را دریافت می‌کنیم که مورد علاقه ما هستند.

سوال خوبی است، یعنی وارد شدن به لیست کارهای انجام شده. اپراتور ما هنوز این را خودکار نکرده است. هنوز در حال توسعه است، پروژه هنوز کاملا جوان است. ما نیاز به ورود به سیستم را درک می کنیم. این نیز موضوع بسیار مهمی است. و احتمالاً اهمیت آن کمتر از نظارت نیست. اما اولین بار در لیست برای اجرا نظارت بود. قطع درختان وجود خواهد داشت. به طور طبیعی، ما سعی می کنیم تمام جنبه های زندگی خوشه را خودکار کنیم. بنابراین، پاسخ این است که در حال حاضر متأسفانه اپراتور نمی داند چگونه این کار را انجام دهد، اما در برنامه است، ما این کار را انجام خواهیم داد. اگر می‌خواهید بپیوندید، لطفاً درخواست خود را بکشید.

سلام! با تشکر از گزارش! من یک سوال استاندارد مربوط به Persistent Volumes دارم. هنگامی که ما یک پیکربندی با این عملگر ایجاد می کنیم، اپراتور چگونه تعیین می کند که دیسک یا پوشه خاصی روی کدام گره متصل است؟ ابتدا باید به او توضیح دهیم که لطفا کلیک هاوس ما را روی این گره هایی که دیسک دارند قرار دهید؟

تا جایی که من متوجه شدم، این سوال ادامه ذخیره سازی محلی، به خصوص قسمت hostPath آن است. این مانند توضیح دادن به کل سیستم است که پاد باید روی فلان گره راه اندازی شود، که ما یک دیسک متصل فیزیکی به آن داریم که در امتداد فلان مسیر نصب شده است. این یک بخش کامل است که من خیلی سطحی به آن دست زدم زیرا پاسخ در آنجا بسیار بزرگ است.

به طور خلاصه اینگونه به نظر می رسد. طبیعتاً باید این حجم ها را تهیه کنیم. در حال حاضر، هیچ منبع پویایی در ذخیره سازی محلی وجود ندارد، بنابراین DevOps باید خود دیسک ها، این حجم ها را قطع کند. و آنها باید در مورد ارائه Kubernetes توضیح دهند که شما حجم های Persistent از فلان کلاس را خواهید داشت که روی فلان گره قرار دارند. سپس باید به Kubernetes توضیح دهید که پادهایی که به فلان کلاس ذخیره محلی نیاز دارند باید فقط با استفاده از برچسب ها به فلان گره هدایت شوند. برای این منظور، اپراتور این توانایی را دارد که نوعی برچسب و یک برچسب برای هر نمونه میزبان اختصاص دهد. و به نظر می رسد که پادها توسط Kubernetes هدایت می شوند تا فقط روی گره هایی اجرا شوند که الزامات، برچسب ها را به زبان ساده برآورده می کنند. مدیران برچسب ها و دیسک های تهیه را به صورت دستی اختصاص می دهند. و سپس مقیاس می شود.

و این سومین گزینه است، محلی، که کمک می کند این کار کمی آسان تر شود. همانطور که قبلاً تأکید کردم، این کار پر زحمت در تنظیم است که در نهایت به دستیابی به حداکثر کارایی کمک می کند.

من یک سوال دوم در این رابطه دارم. Kubernetes به گونه ای طراحی شده است که برای ما مهم نیست که یک گره را از دست می دهیم یا نه. اگر گره‌ای را که خرده‌مان آویزان است از دست داده‌ایم، در این صورت باید چه کنیم؟

بله، Kubernetes در ابتدا این گونه بود که رابطه ما با غلاف هایمان مانند گاو است، اما در اینجا با ما هر دیسک چیزی شبیه به یک حیوان خانگی می شود. چنین مشکلی وجود دارد که نمی توانیم آنها را به سادگی دور بریزیم. و توسعه Kubernetes به سمتی می رود که نمی توان به طور کامل با آن از نظر فلسفی برخورد کرد، گویی یک منبع کاملاً دور ریخته شده است.

حالا برای یک سوال کاربردی. اگر گره ای را که دیسک در آن قرار داشت از دست دادید چه باید کرد؟ در اینجا مشکل در سطح بالاتری حل می شود. در مورد ClickHouse، ما کپی هایی داریم که در سطح بالاتری کار می کنند، یعنی. در سطح ClickHouse

گرایش حاصل چیست؟ DevOps مسئول اطمینان از از بین رفتن داده ها است. او باید Replication را به درستی تنظیم کند و باید از اجرای replication اطمینان حاصل کند. ماکت در سطح ClickHouse باید داده های تکراری داشته باشد. این وظیفه ای نیست که اپراتور آن را حل کند. و نه مشکلی که خود Kubernetes حل می کند. این در سطح ClickHouse است.

اگر گره آهنی شما افتاد چه باید کرد؟ و معلوم می شود که باید یک دومی را نصب کنید، دیسک را به درستی روی آن تهیه کنید و برچسب ها را اعمال کنید. و پس از آن، الزاماتی را برآورده می کند که Kubernetes می تواند یک پاد نمونه روی آن راه اندازی کند. Kubernetes آن را راه اندازی خواهد کرد. تعداد غلاف های شما برای رسیدن به تعداد مشخص شده کافی نیست. چرخه ای را که من نشان دادم طی خواهد کرد. و در بالاترین سطح، ClickHouse متوجه می شود که ما یک نسخه را وارد کرده ایم، هنوز خالی است و باید انتقال داده ها را به آن شروع کنیم. آن ها این فرآیند هنوز به خوبی خودکار نشده است.

با تشکر از گزارش! وقتی انواع و اقسام اتفاقات ناخوشایند رخ می دهد، اپراتور از کار می افتد و دوباره راه اندازی می شود، و در آن لحظه حوادثی از راه می رسند، آیا به نحوی با این موضوع کنار می آیید؟

اگر اپراتور از کار بیفتد و دوباره راه اندازی شود چه اتفاقی می افتد، درست است؟

آره. و در آن لحظه وقایع فرا رسید.

وظیفه اینکه در این مورد چه باید کرد تا حدی بین اپراتور و Kubernetes مشترک است. Kubernetes توانایی پخش مجدد رویدادی را دارد که رخ داده است. او دوباره پخش می کند. و وظیفه اپراتور این است که مطمئن شود هنگامی که گزارش رویداد روی او پخش می شود، این رویدادها بی قدرت هستند. و تا تکرار مکرر همان اتفاق سیستم ما را خراب نکند. و اپراتور ما با این کار کنار می آید.

سلام! با تشکر از گزارش! دیمیتری زاویالوف، شرکت اسمدووا آیا برنامه ای برای اضافه کردن قابلیت پیکربندی با هاپروکسی به اپراتور وجود دارد؟ من به متعادل کننده دیگری غیر از استاندارد علاقه مند هستم تا هوشمند باشد و بفهمد که ClickHouse واقعاً وجود دارد.

آیا شما در مورد Ingress صحبت می کنید؟

بله، هاپروکسی را جایگزین Ingress کنید. در هاپروکسی می توانید توپولوژی خوشه را در جایی که کپی دارد مشخص کنید.

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

قبلا داشته است.

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

منبع: www.habr.com