مقدمه ای کوتاه برای Kustomize

توجه داشته باشید. ترجمه: مقاله توسط Scott Lowe، مهندس با تجربه گسترده در IT، که نویسنده/نویسنده هفت کتاب چاپی (عمدتاً در VMware vSphere) است، نوشته شده است. او اکنون برای زیرمجموعه VMware Heptio (که در سال 2016 خریداری شد) کار می کند و متخصص در رایانش ابری و Kubernetes است. خود متن به عنوان مقدمه ای مختصر و قابل درک برای مدیریت پیکربندی برای Kubernetes با استفاده از فناوری عمل می کند. شخصی سازی، که به تازگی بخشی از K8s شده است.

Kustomize ابزاری است که به کاربران اجازه می‌دهد فایل‌های YAML ساده و بدون الگو را برای اهداف مختلف سفارشی کنند و YAML اصلی را دست نخورده و قابل استفاده باقی بگذارند (توضیحات مستقیماً از مخزن را در GitHub شخصی سازی کنید). Kustomize را می توان مستقیماً اجرا کرد یا از Kubernetes 1.14 استفاده کرد kubectl -k برای دسترسی به عملکرد آن (اگرچه در Kubernetes 1.15، باینری جداگانه جدیدتر از قابلیت های ساخته شده در kubectl است). (توجه داشته باشید. ترجمه: و با انتشار اخیر Kubernetes 1.16 سفارشی کردن پشتیبانی شده توسط همچنین در ابزار kubeadm.) در این پست می خواهم خوانندگان را با اصول کوستومیز آشنا کنم.

در ساده‌ترین شکل/کاربرد، kustomize صرفاً مجموعه‌ای از منابع است (فایل‌های YAML که اشیاء Kubernetes را تعریف می‌کنند: Deployments، Services، و غیره) به‌علاوه فهرستی از دستورالعمل‌ها برای تغییراتی که باید در آن منابع انجام شود. همانطور که make از مجموعه دستورالعمل موجود در استفاده می کند Makefile، و داکر کانتینر را بر اساس دستورالعمل های دریافت شده می سازد Dockerfile، استفاده های سفارشی کنید kustomization.yaml برای ذخیره دستورالعمل های مربوط به تغییراتی که کاربر می خواهد در مجموعه ای از منابع ایجاد کند.

در اینجا یک فایل نمونه است kustomization.yaml:

resources:
- deployment.yaml
- service.yaml
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

من سعی نمی کنم در مورد تمام زمینه های ممکن در فایل صحبت کنم. kustomization.yaml (در این مورد به خوبی نوشته شده است اینجا) اما توضیح مختصری در مورد یک مثال خاص می دهم:

• رشته resources نشان می دهد که چه چیزی (کدام منابع) kustomize تغییر خواهد کرد. در این صورت به دنبال منابع موجود در فایل ها می گردد deployment.yaml и service.yaml در دایرکتوری خود (در صورت لزوم می توانید مسیرهای کامل یا نسبی را مشخص کنید).
• رشته namePrefix به kustomize دستور می دهد یک پیشوند خاص اضافه کند (در این مورد - dev-) نسبت دادن name تمام منابع تعریف شده در این زمینه resources. بنابراین، اگر استقرار داشته باشد name با معنی nginx-deployment، سفارشی کردن آن را می سازد dev-nginx-deployment.
• رشته namespace به kustomize دستور می دهد تا فضای نام داده شده را به همه منابع اضافه کند. در این حالت Deployment and Service در فضای نام قرار می گیرند development.
• بالاخره میدان commonLabels شامل مجموعه ای از برچسب ها است که به همه منابع اضافه می شود. در مثال ما، kustomize یک برچسب به منابع با نام اختصاص می دهد environment و معنی development.

اگر کاربر انجام دهد kustomize build . در دایرکتوری با فایل kustomization.yaml و منابع لازم (یعنی فایل ها deployment.yaml и service.yaml، سپس در خروجی متنی با تغییرات مشخص شده دریافت می کند kustomization.yaml.

توجه داشته باشید. ترجمه: تصویری از مستندات پروژه در مورد استفاده "ساده" از kustomize

در صورت نیاز به انجام تغییرات، خروجی می تواند تغییر مسیر دهد:

kustomize build . > custom-config.yaml

داده‌های خروجی قطعی هستند (همان داده‌های ورودی همان نتایج خروجی را ایجاد می‌کنند)، بنابراین لازم نیست نتیجه را در یک فایل ذخیره کنید. در عوض، می توان آن را مستقیماً به دستور دیگری ارسال کرد:

kustomize build . | kubectl apply -f -

ویژگی‌های Kustomize نیز از طریق قابل دسترسی هستند kubectl -k (از نسخه Kubernetes 1.14). با این حال، به خاطر داشته باشید که بسته Kustomize مستقل سریعتر از بسته Kubectl یکپارچه به روز می شود (حداقل این مورد در مورد نسخه Kubernetes 1.15 صادق است).

خوانندگان ممکن است بپرسند: "اگر می توانید مستقیماً فایل ها را ویرایش کنید، چرا این همه پیچیدگی؟" سوال عالی در مثال ما، در واقع می توان فایل ها را اصلاح کنید deployment.yaml и service.yaml به طور مستقیم، اما اگر آنها انشعابی از پروژه شخص دیگری باشند چه؟ تغییر مستقیم فایل‌ها، زمانی که تغییراتی در مبدأ/منبع انجام می‌شود، تغییر مجدد فورک را دشوار (اگر نه غیرممکن) می‌کند. استفاده از kustomize به شما امکان می دهد این تغییرات را در یک فایل متمرکز کنید kustomization.yaml، فایل های اصلی را دست نخورده باقی می گذارند و در نتیجه در صورت لزوم، بازپایه مجدد فایل های اصلی را آسان تر می کنند.

مزایای kustomize در موارد استفاده پیچیده تر آشکار می شود. در مثال بالا kustomization.yaml و منابع در همان دایرکتوری هستند. با این حال، kustomize از موارد استفاده پشتیبانی می کند که در آن یک پیکربندی پایه و انواع مختلفی از آن وجود دارد، همچنین به عنوان شناخته شده است. پوشش. برای مثال، کاربری می‌خواست Deployment and Service را برای nginx که من به عنوان مثال استفاده کردم، بگیرد و نسخه‌های توسعه، مرحله‌بندی و تولید (یا انواع) آن فایل‌ها را ایجاد کند. برای این کار او به پوشش های فوق الذکر و در واقع خود منابع اولیه نیاز دارد.

برای نشان دادن ایده همپوشانی ها و منابع زیربنایی (منابع پایه)، فرض می کنیم که دایرکتوری ها ساختار زیر را دارند:

- base
  - deployment.yaml
  - service.yaml
  - kustomization.yaml
- overlays
  - dev
    - kustomization.yaml
  - staging
    - kustomization.yaml
  - prod
    - kustomization.yaml

در پرونده base/kustomization.yaml کاربرانی که از این زمینه استفاده می کنند resources به سادگی منابعی را که kustomize باید شامل شود، اعلام کنید.

در هر یک از فایل ها overlays/{dev,staging,prod}/kustomization.yaml کاربران به پیکربندی پایه در فیلد مراجعه می کنند resourcesو سپس تغییرات خاصی را برای آن نشان دهید محیط داده شده. مثلا فایل overlays/dev/kustomization.yaml ممکن است شبیه مثالی باشد که قبلا داده شد:

resources:
- ../../base
namePrefix: dev-
namespace: development
commonLabels:
  environment: development

در این مورد فایل overlays/prod/kustomization.yaml می تواند کاملا متفاوت باشد:

resources:
- ../../base
namePrefix: prod-
namespace: production
commonLabels:
  environment: production
  sre-team: blue

هنگامی که کاربر اجرا می شود kustomize build . در کاتالوگ overlays/dev، kustomize گزینه توسعه را ایجاد می کند. اگر بدوید kustomize build . در کاتالوگ overlays/prod - شما گزینه تولید را دریافت می کنید. و همه اینها - بدون ایجاد هیچ تغییری در نسخه اصلی (پایه) فایل ها، همه به شیوه ای اعلامی و قطعی. می‌توانید پیکربندی پایه و دایرکتوری‌های همپوشانی را مستقیماً به کنترل نسخه اختصاص دهید، با دانستن اینکه بر اساس این فایل‌ها می‌توانید پیکربندی مورد نظر را در هر زمان تکرار کنید.

توجه داشته باشید. ترجمه: تصویری از مستندات پروژه در مورد استفاده از همپوشانی در kustomize

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

منابع اضافی

مقالات و نشریات خوب زیادی در مورد kustomize وجود دارد. در اینجا چند مورد وجود دارد که به نظر من به خصوص مفید بود:

• تنظیمات پایه YAML را برای محیط های مختلف با استفاده از Kustomize تغییر دهید;
• Kustomize - روش درست برای انجام قالب در Kubernetes;
• مدیریت اعلانی اشیاء Kubernetes با استفاده از Customize;
• سفارشی کردن نمودارهای هلم بالادست با Customize.

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

اگر سؤال یا پیشنهادی برای بهبود این مطالب دارید، من همیشه آماده بازخورد هستم. می توانید با من تماس بگیرید توییتر یا کانال Kubernetes Slack. از تغییر مانیفست های خود با kustomize لذت ببرید!

PS از مترجم

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

• «ابزارهایی برای توسعه دهندگان برنامه های در حال اجرا در Kubernetes"؛
• «Kubernetes 1.14: نکات برجسته از آنچه جدید است"؛
• «پنج نتیجه اصلی Helm Summit 2019 در آمستردام"؛
• «معرفی عملی مدیر بسته برای Kubernetes - Helm'.

منبع: www.habr.com