دستگاه هلم و مشکلات آن

مفهوم باربری تایفون، آنتون سوانپول

نام من دیمیتری سوگروبوف است، من یک توسعه دهنده در Leroy Merlin هستم. در این مقاله به شما خواهم گفت که چرا Helm مورد نیاز است، چگونه کار با Kubernetes را ساده می کند، چه چیزی در نسخه سوم تغییر کرده است، و چگونه از آن برای به روز رسانی برنامه ها در تولید بدون توقف استفاده کنید.

این خلاصه بر اساس سخنرانی در یک کنفرانس است @Kubernetes کنفرانس by Mail.ru Cloud Solutions - اگر نمی‌خواهید بخوانید، ویدیو را تماشا کنید.

چرا ما از Kubernetes در تولید استفاده می کنیم

Leroy Merlin پیشرو در بازار خرده فروشی DIY در روسیه و اروپا است. شرکت ما بیش از صد توسعه دهنده، 33 کارمند داخلی و تعداد زیادی از مردمی دارد که از هایپرمارکت ها و وب سایت بازدید می کنند. برای اینکه همه آنها را خوشحال کنیم، تصمیم گرفتیم از رویکردهای استاندارد صنعت پیروی کنیم. توسعه برنامه های کاربردی جدید با استفاده از معماری میکروسرویس. از ظروف برای جداسازی محیط ها و اطمینان از تحویل مناسب استفاده کنید. و از Kubernetes برای ارکستراسیون استفاده کنید. قیمت استفاده از ارکستراتورها به سرعت در حال ارزان‌تر شدن است: تعداد مهندسان مسلط به فناوری در بازار در حال افزایش است و ارائه‌دهندگان ظاهر می‌شوند که Kubernetes را به عنوان یک سرویس ارائه می‌کنند.

هر کاری که Kubernetes انجام می دهد، البته، می تواند به روش های دیگری نیز انجام شود، مثلاً با پوشش چند جنکینز و docker-compose با اسکریپت، اما چرا اگر راه حل آماده و قابل اعتمادی وجود دارد، زندگی را پیچیده کنیم؟ به همین دلیل به Kubernetes آمدیم و یک سال است که از آن در تولید استفاده می کنیم. ما در حال حاضر بیست و چهار خوشه Kubernetes داریم که قدیمی ترین آنها بیش از یک سال قدمت دارد و حدود دویست غلاف دارد.

نفرین فایل های YAML بزرگ در Kubernetes

برای راه‌اندازی یک میکروسرویس در Kubernetes، حداقل پنج فایل YAML ایجاد می‌کنیم: برای Deployment، Service، Ingress، ConfigMap، Secrets - و آنها را به خوشه ارسال می‌کنیم. برای برنامه بعدی همان بسته جامب ها را می نویسیم، با سومی یکی دیگر و به همین ترتیب. اگر تعداد اسناد را در تعداد محیط‌ها ضرب کنیم، صدها فایل دریافت می‌کنیم، و این هنوز محیط‌های پویا را در نظر نمی‌گیرد.

آدام ریس، نگهدارنده اصلی Helm، مفهوم "چرخه توسعه در Kubernetes"، که به شکل زیر است:

1. کپی YAML - یک فایل YAML را کپی کنید.
2. چسباندن YAML - چسباندن آن.
3. رفع تورفتگی - رفع تورفتگی.
4. تکرار - دوباره تکرار کنید.

این گزینه کار می کند، اما باید چندین بار فایل های YAML را کپی کنید. برای تغییر این چرخه، Helm اختراع شد.

هلم چیست

اولا، هلم - مدیر بسته، که به شما کمک می کند برنامه های مورد نیاز خود را پیدا و نصب کنید. برای نصب، به عنوان مثال، MongoDB، نیازی به رفتن به وب سایت رسمی و دانلود فایل های باینری ندارید، فقط دستور را اجرا کنید. helm install stable/mongodb.

دوم، هلم - موتور قالب، به پارامترسازی فایل ها کمک می کند. بیایید به وضعیت پرونده های YAML در Kubernetes برگردیم. نوشتن همان فایل YAML آسان‌تر است، تعدادی متغیرهایی به آن اضافه کنید، که Helm مقادیر را در آنها جایگزین می‌کند. یعنی به جای مجموعه ای بزرگ از داربست ها، مجموعه ای از قالب ها وجود خواهد داشت که مقادیر مورد نیاز در زمان مناسب جایگزین می شوند.

سوم، هلم - استاد استقرار. با استفاده از آن می توانید برنامه ها را نصب، بازگردانی و به روز رسانی کنید. بیایید بفهمیم که چگونه این کار را انجام دهیم.

چگونه از Helm برای استقرار برنامه های خود استفاده کنید

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

• پوشه ای را با الگوها نشان دهید.
• آرشیو را در یک تار بسته بندی کنید و به آن اشاره کنید.
• قالب را در یک مخزن راه دور قرار دهید و یک پیوند به مخزن در مشتری Helm اضافه کنید.

شما همچنین به یک فایل با مقادیر - values.yaml نیاز دارید. داده ها از آنجا در قالب درج خواهند شد. بیایید آن را نیز ایجاد کنیم.

نسخه دوم Helm دارای یک برنامه سرور اضافی - Tiller است. خارج از Kubernetes آویزان می شود و منتظر درخواست های کلاینت Helm می شود و در صورت فراخوانی، مقادیر مورد نیاز را در قالب جایگزین می کند و آن را به Kubernetes ارسال می کند.

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

چطور کار میکند

دستور را اجرا کنید helm install. بیایید نام انتشار برنامه را مشخص کنیم و مسیر را به values.yaml بدهیم. در پایان مخزنی که نمودار در آن قرار دارد و نام نمودار را نشان خواهیم داد. در مثال، اینها به ترتیب "lmru" و "bestchart" هستند.

helm install --name bestapp --values values.yaml lmru/bestchart

این فرمان فقط یک بار و زمانی که دوباره اجرا شود می تواند اجرا شود install نیاز به استفاده upgrade. برای سادگی، به جای دو دستور، می توانید دستور را اجرا کنید upgrade با کلید اضافی --install. هنگامی که برای اولین بار اجرا می شود، Helm دستوری برای نصب نسخه ارسال می کند و در آینده آن را به روز می کند.

helm upgrade --install bestapp --values values.yaml lmru/bestchart

مشکلات استقرار نسخه های جدید برنامه با Helm

در این مرحله از داستان، من در حال بازی Who Wants to Be a Millionaire با تماشاگران هستم و در حال بررسی چگونگی به روز رسانی نسخه برنامه از Helm هستیم. فیلم را تماشا کنید.

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

روش 1. اطلاعات را از آخرین راه اندازی تغییر ندهید

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

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

روش 2. LABEL را در تصویر به روز کنید

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

روش 3: از یک کلید استفاده کنید --force

بیایید به دفترچه راهنما رجوع کنیم و به دنبال کلید مورد نیاز بگردیم. کلید بیشترین معنا را دارد --force. با وجود نام واضح، رفتار با آنچه انتظار می رفت متفاوت است. به جای اجبار به روز رسانی برنامه، هدف واقعی آن بازیابی نسخه ای است که در وضعیت FAILED است. اگر از این کلید استفاده نمی کنید، باید دستورات را به صورت متوالی اجرا کنید helm delete && helm install --replace. پیشنهاد می شود به جای آن از کلید استفاده کنید --force، که اجرای متوالی این دستورات را خودکار می کند. اطلاعات بیشتر در این درخواست کشش. برای اینکه به Helm بگوییم نسخه برنامه را به روز کند، متاسفانه این کلید کار نمی کند.

روش 4. برچسب ها را مستقیماً در Kubernetes تغییر دهید

به‌روزرسانی برچسب مستقیماً در خوشه با استفاده از دستور kubectl edit - ایده بد. این اقدام منجر به ناهماهنگی اطلاعات بین برنامه در حال اجرا و برنامه ای می شود که در ابتدا برای استقرار ارسال شده است. رفتار Helm در حین استقرار در این مورد با نسخه آن متفاوت است: Helm 2 کاری انجام نمی دهد و Helm 3 نسخه جدید برنامه را مستقر می کند. برای درک دلیل، باید بدانید که Helm چگونه کار می کند.

هلم چگونه کار می کند؟

برای تعیین اینکه آیا یک برنامه از آخرین نسخه آن تغییر کرده است یا خیر، Helm می تواند از موارد زیر استفاده کند:

• اجرای برنامه در Kubernetes؛
• new values.yaml و نمودار فعلی;
• اطلاعات انتشار داخلی Helm.

برای کنجکاوتر: Helm اطلاعات داخلی در مورد نسخه ها را در کجا ذخیره می کند؟با اجرای دستور helm history، ما تمام اطلاعات مربوط به نسخه های نصب شده با استفاده از Helm را دریافت خواهیم کرد.

همچنین اطلاعات دقیقی در مورد الگوها و مقادیر ارسال شده وجود دارد. ما می توانیم آن را درخواست کنیم:

در نسخه دوم Helm، این اطلاعات در همان فضای نامی که Tiller در حال اجراست (kube-system به طور پیش‌فرض)، در ConfigMap قرار دارد که با برچسب "OWNER=TILLER" مشخص شده است:

هنگامی که نسخه سوم Helm ظاهر شد، اطلاعات به اسرار و به همان فضای نامی که برنامه در حال اجرا بود منتقل شد. به لطف این، امکان اجرای چندین برنامه به طور همزمان در فضای نام مختلف با نام انتشار یکسان فراهم شد. در نسخه دوم، زمانی که فضاهای نام ایزوله می شوند اما می توانند بر یکدیگر تأثیر بگذارند، سردرد جدی بود.

Helm دوم، هنگامی که سعی می‌کند بفهمد آیا به‌روزرسانی نیاز است یا خیر، تنها از دو منبع اطلاعاتی استفاده می‌کند: آنچه اکنون در اختیار آن قرار می‌گیرد، و اطلاعات داخلی در مورد نسخه‌ها، که در ConfigMap نهفته است.

Helm سوم از یک استراتژی ادغام سه طرفه استفاده می کند: علاوه بر این اطلاعات، برنامه ای را که در حال حاضر در Kubernetes در حال اجرا است نیز در نظر می گیرد.

به همین دلیل، نسخه قدیمی Helm هیچ کاری انجام نمی دهد، زیرا اطلاعات برنامه در کلاستر را در نظر نمی گیرد، اما Helm 3 تغییرات را دریافت کرده و برنامه جدید را برای استقرار ارسال می کند.

روش 5. از کلید --recreate-pods استفاده کنید

با یک کلید --recreate-pods شما می توانید با کلید به آنچه در ابتدا برنامه ریزی کرده اید دست پیدا کنید --force. کانتینرها مجددا راه اندازی می شوند و با توجه به سیاست imagePullPolicy: همیشه برای آخرین برچسب (در مورد این موضوع در پانویس بالا)، Kubernetes نسخه جدیدی از تصویر را دانلود و راه اندازی می کند. این به بهترین شکل انجام نخواهد شد: بدون در نظر گرفتن StrategyType از استقرار، به طور ناگهانی تمام نمونه های برنامه قدیمی را خاموش می کند و شروع به راه اندازی موارد جدید می کند. در طول راه اندازی مجدد، سیستم کار نخواهد کرد، کاربران متضرر خواهند شد.

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

Helm به سادگی همه برنامه ها را خاموش می کند و کانتینرهای جدید را در نزدیکی راه اندازی می کند. شما نمی توانید این کار را در تولید انجام دهید تا باعث خرابی برنامه نشود. این فقط برای نیازهای توسعه مورد نیاز است و فقط در محیط های مرحله اجرا می شود.

چگونه با استفاده از Helm نسخه برنامه را به روز کنیم؟

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

1. مقدار تصادفی با استفاده از تابع استاندارد - {{ randAlphaNum 6 }}.
   یک هشدار وجود دارد: پس از هر استقرار با استفاده از نموداری با چنین متغیری، مقدار حاشیه نویسی منحصر به فرد خواهد بود و Helm تغییراتی را در نظر می گیرد. معلوم می شود که ما همیشه برنامه را راه اندازی مجدد می کنیم، حتی اگر نسخه آن را تغییر نداده باشیم. این مهم نیست، زیرا هیچ خرابی وجود نخواهد داشت، اما هنوز هم ناخوشایند است.
2. جریان را بچسبانید تاریخ و زمان - {{ .Release.Date }}.
   یک نوع شبیه به یک مقدار تصادفی با یک متغیر دائمی منحصر به فرد است.
3. یک راه صحیح تر استفاده است چک جمع ها. این SHA تصویر یا SHA آخرین commit در git است - {{ .Values.sha }}.
   آنها باید شمارش شوند و به مشتری Helm در طرف تماس گیرنده ارسال شوند، برای مثال در جنکینز. اگر برنامه تغییر کرده باشد، جمع چک تغییر خواهد کرد. بنابراین، Helm فقط در صورت نیاز برنامه را به روز می کند.

بیایید تلاش هایمان را خلاصه کنیم

• Helm تغییرات را به حداقل روش تهاجمی انجام می دهد، بنابراین هر تغییری در سطح تصویر برنامه در رجیستری Docker منجر به به روز رسانی نمی شود: پس از اجرای دستور هیچ اتفاقی نمی افتد.
• کلید --force برای بازیابی نسخه های مشکل ساز استفاده می شود و با به روز رسانی های اجباری مرتبط نیست.
• کلید --recreate-pods برنامه ها را به اجبار به روز می کند، اما این کار را به شیوه ای خرابکارانه انجام می دهد: به طور ناگهانی همه کانتینرها را خاموش می کند. کاربران از این موضوع رنج خواهند برد؛ شما نباید این کار را در تولید انجام دهید.
• با استفاده از دستور مستقیماً تغییراتی در خوشه Kubernetes ایجاد کنید kubectl edit انجام نده: ما یکپارچگی را از بین می بریم، و رفتار بسته به نسخه Helm متفاوت خواهد بود.
• با انتشار نسخه جدید Helm، تفاوت های ظریف بسیاری ظاهر شده است. مسائل موجود در مخزن Helm به زبان واضح توضیح داده شده است، آنها به شما در درک جزئیات کمک می کنند.
• اضافه کردن یک حاشیه نویسی قابل ویرایش به نمودار، آن را انعطاف پذیرتر می کند. این به شما این امکان را می دهد که برنامه را به درستی و بدون توقف اجرا کنید.

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

سایر لینک های مرتبط:

1. آشنایی با سکان 3
2. وب سایت رسمی Helm
3. مخزن Helm در GitHub
4. 25 ابزار مفید Kubernetes: استقرار و مدیریت

این گزارش برای اولین بار در @Kubernetes کنفرانس توسط Mail.ru Cloud Solutions. نگاه کن تصویری اجراهای دیگر و مشترک شدن در اطلاعیه رویدادها در تلگرام در اطراف Kubernetes در Mail.ru Group.

منبع: www.habr.com