معرفی Helm 3

توجه داشته باشید. ترجمه: 16 مه سال جاری نقطه عطف مهمی در توسعه مدیر بسته برای Kubernetes - Helm است. در این روز، اولین نسخه آلفا از نسخه اصلی آینده پروژه - 3.0 - ارائه شد. انتشار آن تغییرات قابل توجه و مورد انتظاری را در Helm به ارمغان خواهد آورد که بسیاری از جامعه Kubernetes به آن امید زیادی دارند. ما خودمان یکی از این موارد هستیم، زیرا به طور فعال از Helm برای استقرار برنامه استفاده می کنیم: ما آن را در ابزار خود برای پیاده سازی CI/CD ادغام کرده ایم. ورف و هر از گاهی ما سهم خود را در توسعه بالادستی ایفا می کنیم. این ترجمه ترکیبی از 7 یادداشت از وبلاگ رسمی Helm است که به اولین نسخه آلفای Helm 3 اختصاص دارد و در مورد تاریخچه پروژه و ویژگی های اصلی Helm 3 صحبت می کند. نویسنده آنها Matt “bacongobbler” Fisher، کارمند مایکروسافت است. و یکی از نگهبانان کلیدی هلم.

در 15 اکتبر 2015، پروژه ای که اکنون با نام هلم شناخته می شود متولد شد. تنها یک سال پس از تأسیس، انجمن Helm به Kubernetes پیوست، در حالی که فعالانه روی Helm 2 کار می کرد. در ژوئن 2018، Helm به CNCF پیوست به عنوان یک پروژه در حال توسعه (انکوباتور). سریع به جلو بروید و اولین نسخه آلفای Helm 3 جدید در راه است. (این نسخه قبلاً صورت گرفته است در اواسط ماه مه - تقریبا. ترجمه.).

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

خلاصه:

• تاریخ خلقت حلم;
• وداع با تیلر
• مخازن نمودار;
• مدیریت انتشار؛
• تغییرات در وابستگی نمودار.
• نمودارهای کتابخانه؛
• بعد چی

تاریخچه هلم

تولد

Helm 1 به عنوان یک پروژه منبع باز ایجاد شده توسط Deis آغاز شد. ما یک استارتاپ کوچک بودیم جذب شده است مایکروسافت در بهار 2017. پروژه منبع باز دیگر ما که Deis نیز نام داشت، یک ابزار داشت deisctl، که (از جمله موارد دیگر) برای نصب و راه اندازی پلت فرم Deis در خوشه ناوگان. در آن زمان، Fleet یکی از اولین سکوهای ارکستراسیون کانتینر بود.

در اواسط سال 2015، تصمیم گرفتیم مسیر خود را تغییر دهیم و Deis را (در آن زمان به Deis Workflow تغییر نام داد) از Fleet به Kubernetes منتقل کردیم. یکی از اولین مواردی که دوباره طراحی شد ابزار نصب بود. deisctl. ما از آن برای نصب و مدیریت Deis Workflow در خوشه Fleet استفاده کردیم.

Helm 1 در تصویر مدیران بسته های معروف مانند Homebrew، apt و yum ایجاد شده است. هدف اصلی آن ساده سازی وظایفی مانند بسته بندی و نصب برنامه ها در Kubernetes بود. Helm به طور رسمی در سال 2015 در کنفرانس KubeCon در سانفرانسیسکو معرفی شد.

اولین تلاش ما با هلم کارساز بود، اما بدون محدودیت های جدی نبود. او مجموعه‌ای از مانیفست‌های Kubernetes را انتخاب کرد که با ژنراتورها به‌عنوان بلوک‌های مقدماتی YAML طعم‌دار شده بودند. (موضوع جلویی)*، و نتایج را در Kubernetes بارگذاری کرد.

* توجه داشته باشید. ترجمه: از اولین نسخه Helm، نحو YAML برای توصیف منابع Kubernetes انتخاب شد و قالب‌های Jinja و اسکریپت‌های Python هنگام نوشتن پیکربندی‌ها پشتیبانی می‌شدند. در این مورد و به طور کلی ساختار اولین نسخه هلم را در فصل "تاریخچه مختصر هلم" نوشتیم. این مواد.

به عنوان مثال، برای جایگزینی یک فیلد در یک فایل YAML، باید ساختار زیر را به مانیفست اضافه کنید:

#helm:generate sed -i -e s|ubuntu-debootstrap|fluffy-bunny| my/pod.yaml

خیلی خوب است که موتورهای قالب امروزه وجود دارند، اینطور نیست؟

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

بر اساس تجربه اشتباهات گذشته، ما شروع به توسعه Helm 2 کردیم.

ساخت هلم 2

در پایان سال 2015، تیم گوگل با ما تماس گرفت. آنها روی ابزار مشابهی برای Kubernetes کار می کردند. Deployment Manager برای Kubernetes پورت یک ابزار موجود بود که برای Google Cloud Platform استفاده می‌شد. آنها پرسیدند: «آیا مایلیم چند روزی را صرف بحث درباره شباهت ها و تفاوت ها کنیم؟»

در ژانویه 2016، تیم Helm و Deployment Manager برای تبادل نظر در سیاتل گرد هم آمدند. مذاکرات با یک طرح بلندپروازانه به پایان رسید: ترکیب هر دو پروژه برای ایجاد Helm 2. همراه با Deis و Google، بچه های از SkippBox (اکنون بخشی از بیتنامی - تقریباً ترجمه شده است.)و کار بر روی Helm 2 را شروع کردیم.

ما می‌خواستیم سهولت استفاده Helm را حفظ کنیم، اما موارد زیر را اضافه کنید:

• قالب های نمودار برای سفارشی سازی؛
• مدیریت درون خوشه ای برای تیم ها؛
• مخزن نمودار در سطح جهانی؛
• قالب بسته پایدار با گزینه امضا؛
• تعهد قوی به نسخه‌سازی معنایی و حفظ سازگاری با نسخه‌ها.

برای دستیابی به این اهداف، عنصر دوم به اکوسیستم هلم اضافه شده است. این جزء درون خوشه ای Tiller نام داشت و وظیفه نصب و مدیریت نمودارهای Helm را بر عهده داشت.

از زمان انتشار Helm 2 در سال 2016، Kubernetes چندین نوآوری بزرگ اضافه کرده است. اضافه شدن کنترل دسترسی مبتنی بر نقش (RBAC) که در نهایت جایگزین کنترل دسترسی مبتنی بر ویژگی (ABAC) شد. انواع منابع جدید معرفی شدند (استقرار در آن زمان هنوز در نسخه بتا بود). تعاریف منابع سفارشی (که در ابتدا منابع شخص ثالث یا TPR نامیده می شدند) اختراع شدند. و مهمتر از همه، مجموعه ای از بهترین شیوه ها پدیدار شده است.

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

خداحافظی لطیف با تیلر

در طول توسعه Helm 2، ما تیلر را به عنوان بخشی از ادغام خود با Google's Deployment Manager معرفی کردیم. تیلر نقش مهمی برای تیم‌هایی داشت که در یک خوشه مشترک کار می‌کردند: به متخصصان مختلفی که زیرساخت را اداره می‌کردند اجازه می‌داد با مجموعه‌ای از نسخه‌های مشابه تعامل داشته باشند.

از آنجایی که کنترل دسترسی مبتنی بر نقش (RBAC) به طور پیش فرض در Kubernetes 1.6 فعال بود، کار با Tiller در تولید دشوارتر شد. با توجه به تعداد زیاد سیاست های امنیتی ممکن، موقعیت ما ارائه یک پیکربندی مجاز به صورت پیش فرض بوده است. این به تازه‌کاران اجازه می‌داد بدون نیاز به فرو رفتن در تنظیمات امنیتی ابتدا با Helm و Kubernetes آزمایش کنند. متأسفانه، این پیکربندی مجوز می‌تواند دامنه بسیار گسترده‌ای از مجوزها را به کاربر بدهد که به آن‌ها نیازی نداشت. مهندسان DevOps و SRE باید مراحل عملیاتی اضافی را هنگام نصب Tiller در یک خوشه چند مستاجر یاد بگیرند.

پس از یادگیری نحوه استفاده جامعه از Helm در موقعیت‌های خاص، متوجه شدیم که سیستم مدیریت انتشار تیلر نیازی به تکیه بر یک جزء درون خوشه‌ای برای حفظ حالت یا عملکرد به عنوان یک مرکز مرکزی برای اطلاعات انتشار ندارد. در عوض، ما به سادگی می‌توانیم اطلاعاتی را از سرور API Kubernetes دریافت کنیم، نموداری را در سمت کلاینت ایجاد کنیم و رکوردی از نصب را در Kubernetes ذخیره کنیم.

هدف اصلی تیلر می توانست بدون تیلر محقق شود، بنابراین یکی از اولین تصمیمات ما در مورد Helm 3 این بود که تیلر را به طور کامل کنار بگذاریم.

با رفتن تیلر، مدل امنیتی هلم به طور اساسی ساده شده است. Helm 3 اکنون از تمام روش های امنیتی مدرن، هویت و مجوز Kubernetes فعلی پشتیبانی می کند. مجوزهای هلم با استفاده از آن تعیین می شود فایل kubeconfig. مدیران کلاستر می توانند حقوق کاربر را به هر سطحی از جزئیات محدود کنند. نسخه‌های منتشر شده همچنان در این خوشه ذخیره می‌شوند و بقیه عملکرد Helm دست نخورده باقی می‌ماند.

مخازن نمودار

در سطح بالا، مخزن نمودار مکانی است که می توان نمودارها را ذخیره و به اشتراک گذاشت. کلاینت Helm نمودارها را بسته بندی می کند و به مخزن می فرستد. به زبان ساده، مخزن نمودارها یک سرور HTTP اولیه با یک فایل index.yaml و چند نمودار بسته بندی شده است.

اگرچه مزایایی برای Charts Repository API وجود دارد که نیازهای اولیه ذخیره سازی را برآورده می کند، چند معایب نیز وجود دارد:

• مخازن نمودار با اکثر پیاده سازی های امنیتی مورد نیاز در یک محیط تولید سازگار نیستند. داشتن یک API استاندارد برای احراز هویت و مجوز در سناریوهای تولید بسیار مهم است.
• ابزارهای منشأ نمودار هلم، که برای امضا، تأیید صحت و منشأ نمودار استفاده می‌شود، بخشی اختیاری از فرآیند انتشار نمودار است.
• در سناریوهای چند کاربره، همان نمودار را می توان توسط کاربر دیگری آپلود کرد و فضای مورد نیاز برای ذخیره همان محتوا را دو برابر می کند. مخازن هوشمندتر برای حل این مشکل توسعه یافته اند، اما آنها بخشی از مشخصات رسمی نیستند.
• استفاده از یک فایل فهرست واحد برای جستجو، ذخیره ابرداده، و بازیابی نمودارها، توسعه پیاده سازی های چند کاربره ایمن را دشوار کرده است.

پروژه توزیع داکر (همچنین به عنوان Docker Registry v2 شناخته می شود) جانشین Docker Registry است و اساساً به عنوان مجموعه ای از ابزارها برای بسته بندی، حمل و نقل، ذخیره و تحویل تصاویر Docker عمل می کند. بسیاری از سرویس های ابری بزرگ محصولات مبتنی بر توزیع را ارائه می دهند. به لطف این توجه فزاینده، پروژه Distribution از سال‌ها پیشرفت، بهترین شیوه‌های امنیتی و آزمایش میدانی بهره برده است که آن را به یکی از موفق‌ترین قهرمانان گمنام دنیای متن باز تبدیل کرده است.

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

با تشکر از زحمات ابتکار کانتینر باز (یا OCI)، نمودارهای هلم را می توان در هر نمونه توزیع قرار داد. در حال حاضر، این فرآیند آزمایشی است. پشتیبانی لاگین و سایر ویژگی‌های مورد نیاز برای یک Helm 3 کامل در حال انجام است، اما ما هیجان‌زده هستیم که از اکتشافاتی که تیم OCI و Distribution در طول سال‌ها انجام داده‌اند یاد بگیریم. و از طریق راهنمایی و راهنمایی آنها، می آموزیم که عملکرد یک سرویس بسیار در دسترس در مقیاس چگونه است.

شرح دقیق‌تری از برخی تغییرات آتی در مخازن نمودار Helm در دسترس است по ссылке.

مدیریت انتشار

در Helm 3، وضعیت برنامه در داخل خوشه توسط یک جفت شی ردیابی می شود:

• انتشار شی - یک نمونه برنامه را نشان می دهد.
• نسخه مخفی انتشار - نشان دهنده وضعیت مطلوب برنامه در یک نقطه خاص از زمان (به عنوان مثال، انتشار یک نسخه جدید).

تماس بگیرید helm install یک شیء انتشار و نسخه نسخه مخفی ایجاد می کند. زنگ زدن helm upgrade به یک شیء انتشار نیاز دارد (که می تواند آن را تغییر دهد) و یک نسخه مخفی نسخه انتشار جدید حاوی مقادیر جدید و یک مانیفست آماده ایجاد می کند.

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

نسخه مخفی انتشار یک نسخه را با یک سری از تجدید نظرها (نصب، به روز رسانی، بازگرداندن، حذف) مرتبط می کند.

در Helm 2، تجدید نظرها بسیار سازگار بود. زنگ زدن helm install ایجاد v1، به روز رسانی بعدی (ارتقا) - v2، و غیره. نسخه مخفی انتشار و انتشار در یک شیء واحد به نام revision جمع شده است. ویرایش‌ها در فضای نامی مشابه با Tiller ذخیره می‌شد، به این معنی که هر نسخه از نظر فضای نام «جهانی» بود. در نتیجه، تنها یک نمونه از نام می تواند استفاده شود.

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

پس از رها شدن تیلر، Helm 3 داده‌های انتشار را در فضای نامی مشابه با نسخه ذخیره می‌کند. این تغییر به شما امکان می‌دهد نموداری با همان نام انتشار را در فضای نام متفاوتی نصب کنید و داده‌ها بین به‌روزرسانی‌ها/راه‌اندازی مجدد کلاستر در etcd ذخیره می‌شوند. به عنوان مثال، می توانید وردپرس را در فضای نام "foo" و سپس در فضای نام "بار" نصب کنید و هر دو نسخه را می توان "وردپرس" نامید.

تغییرات در وابستگی های نمودار

نمودارها بسته بندی شده (با استفاده از helm package) برای استفاده با Helm 2 را می توان با Helm 3 نصب کرد، با این حال گردش کار توسعه نمودار کاملاً بازنگری شده است، بنابراین برای ادامه توسعه نمودار با Helm 3 باید تغییراتی ایجاد شود. به ویژه، سیستم مدیریت وابستگی نمودار تغییر کرده است.

سیستم مدیریت وابستگی نمودار تغییر کرده است requirements.yaml и requirements.lock بر Chart.yaml и Chart.lock. این به این معنی است که نمودارهایی که از دستور استفاده می کنند helm dependency، برای کار در Helm 3 به تنظیمات نیاز دارد.

بیایید به یک مثال نگاه کنیم. بیایید یک وابستگی به نمودار در Helm 2 اضافه کنیم و ببینیم هنگام انتقال به Helm 3 چه تغییری می کند.

در هلم 2 requirements.yaml شبیه این بود:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

در Helm 3، همین وابستگی در شما منعکس خواهد شد Chart.yaml:

dependencies:
- name: mariadb
  version: 5.x.x
  repository: https://kubernetes-charts.storage.googleapis.com/
  condition: mariadb.enabled
  tags:
    - database

نمودارها هنوز دانلود و در فهرست قرار می گیرند charts/بنابراین نمودارهای فرعی (نمودار فرعی)، در کاتالوگ قرار دارد charts/، بدون تغییر به کار خود ادامه خواهد داد.

معرفی نمودارهای کتابخانه

Helm 3 از دسته ای از نمودارها به نام نمودارهای کتابخانه ای پشتیبانی می کند (نمودار کتابخانه). این نمودار توسط نمودارهای دیگر استفاده می شود، اما به تنهایی هیچ گونه مصنوعات انتشار ایجاد نمی کند. الگوهای نمودار کتابخانه فقط می توانند عناصر را اعلام کنند define. سایر مطالب به سادگی نادیده گرفته می شوند. این به کاربران اجازه می‌دهد تا از کدهایی که می‌توانند در چندین نمودار استفاده شوند، دوباره استفاده کرده و به اشتراک بگذارند، در نتیجه از تکرار و رعایت اصل جلوگیری می‌کنند. خشک.

نمودارهای کتابخانه در بخش اعلام شده است dependencies در پرونده Chart.yaml. نصب و مدیریت آنها هیچ تفاوتی با نمودارهای دیگر ندارد.

dependencies:
  - name: mylib
    version: 1.x.x
    repository: quay.io

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

گام بعدی چیست؟

Helm 3.0.0-alpha.1 پایه ای است که بر اساس آن شروع به ساختن نسخه جدیدی از Helm می کنیم. در مقاله برخی از ویژگی های جالب Helm 3 را شرح دادم. بسیاری از آنها هنوز در مراحل اولیه توسعه هستند و این طبیعی است. هدف انتشار آلفا آزمایش ایده، جمع‌آوری بازخورد از کاربران اولیه و تأیید فرضیات ما است.

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

من سعی کردم برخی از پیشرفت‌های اصلی Helm 3 را برجسته کنم، اما این فهرست به هیچ وجه کامل نیست. نقشه راه کامل Helm 3 شامل ویژگی‌هایی مانند استراتژی‌های به‌روزرسانی بهبودیافته، ادغام عمیق‌تر با رجیستری‌های OCI و استفاده از طرح‌واره‌های JSON برای اعتبارسنجی مقادیر نمودار است. همچنین قصد داریم پایگاه کد را پاکسازی کنیم و بخش‌هایی از آن را که در سه سال گذشته مورد غفلت قرار گرفته‌اند، به‌روزرسانی کنیم.

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

به بحث ما بپیوندید کانال های شل:

• #helm-users برای سوالات و ارتباط ساده با جامعه؛
• #helm-dev برای بحث در مورد درخواست های کشش، کد و اشکالات.

همچنین می‌توانید در تماس‌های هفتگی برنامه‌نویس عمومی ما، پنجشنبه‌ها در ساعت 19:30 MSK چت کنید. جلسات به بحث در مورد موضوعاتی که توسعه دهندگان کلیدی و جامعه روی آن کار می کنند و همچنین موضوعات مورد بحث در هفته اختصاص داده شده است. همه می توانند در جلسه شرکت کنند و در آن شرکت کنند. لینک در کانال Slack موجود است #helm-dev.

PS از مترجم

در وبلاگ ما نیز بخوانید:

• «مدیر بسته برای Kubernetes - Helm: گذشته، حال، آینده"؛
• «نگاهی هشیارانه به هلم 2: "این چیزی است که...""؛
• «معرفی عملی مدیر بسته برای Kubernetes - Helm"؛
• «نکات و ترفندهای Kubernetes: انتقال منابع در حال اجرا در یک کلاستر به مدیریت Helm 2"؛
• «با dapp تمرین کنید. قسمت 2. استقرار تصاویر Docker در Kubernetes با استفاده از Helm'.

منبع: www.habr.com