معرفی
کاستومایز (Kustomize) ابزاری متنباز برای ساخت و سفارشیسازی مانیفستهای Kubernetes است. این ابزار منابع YAML پایه را نگه میدارد و تغییرات موردنیاز هر محیط را با استفاده از فایل kustomization.yaml و لایههای سفارشیسازی اعمال میکند. Kustomize در ابزار kubectl نیز پشتیبانی میشود و امکان ساخت خروجی نهایی پیکربندی را بدون نیاز به تعریف قالبهای متغیرمحور فراهم میکند. مستندات Kustomization در Kubernetes
در این الگو، base یا پایه شامل منابع مشترک، مانند Deployment و Service است. overlay یا لایه سفارشیسازی، تغییرات موردنیاز هر محیط، مانند development، staging یا production، را تعریف میکند. patch نیز بخشی از پیکربندی یک منبع را تغییر میدهد؛ برای نمونه، میتوان از آن برای تغییر تعداد replicaها یا تنظیمات دیگر یک Deployment استفاده کرد. برای تغییر نسخه تصویر کانتینر نیز میتوان از قابلیت images در Kustomize بهره برد.
برای انتخاب ابزار، ابتدا میزان تفاوت محیطها را بررسی کنید. اگر مانیفستهای مشخصی دارید و تفاوتها به تغییرهایی محدود مانند namespace، image، label، منابع پردازشی یا replica خلاصه میشود، کاستومایز انتخاب ساده و قابل بازبینی است. اما اگر باید یک نرمافزار را بهصورت بسته منتشر کنید، نسخه و وابستگیهای آن را مدیریت کنید، مقادیر پارامترهای فراوان به کاربر بدهید یا چرخه انتشار chart داشته باشید، Helm معمولاً مناسبتر است. Helm بر مبنای chart و release کار میکند. مستندات Chart در Helm مستندات استفاده از Helm
Kustomize جایگزین کامل Helm نیست و میتواند برای سفارشیسازی مانیفستهای تولیدشده توسط ابزارهای دیگر نیز به کار رود. در پروژههای بزرگ، افزایش تعداد Patchها و لایههای وابسته ممکن است ردیابی تغییرات را دشوار کند. در چنین شرایطی، بهتر است ساختار base و overlay را ساده نگه دارید و خروجی نهایی را پیش از اعمال در کلاستر بازبینی کنید. Kustomize نیز قابلیتهای بستهبندی، مدیریت وابستگیها و مدیریت release را که در Helm وجود دارد، ارائه نمیکند.
Kustomize از قابلیت generator برای ساخت ConfigMap و Secret از فایلها یا مقادیر مشخص پشتیبانی میکند. در حالت پیشفرض، نام منابع تولیدشده میتواند شامل هش محتوا باشد تا تغییر محتوای پیکربندی در نام منبع نیز بازتاب پیدا کند. همچنین میتوان منابع محلی و منابع راهدور پشتیبانیشده، از جمله منابع موجود در مخازن Git، را در پیکربندی وارد کرد. مرجع رسمی kustomization
برای تولید و مشاهده مانیفست نهایی میتوان از فرمان kubectl kustomize استفاده کرد. برای اعمال پیکربندی یک پوشه حاوی فایل kustomization.yaml نیز فرمان kubectl apply -k کاربرد دارد. بهتر است پیش از اجرای فرمان دوم، خروجی نهایی را بررسی کنید تا تغییرات ناخواسته به کلاستر اعمال نشوند. مرجع kubectl kustomize مرجع kubectl apply -k
Kustomize معمولاً در کنار مهارتهایی مانند Kubernetes، Helm، Git و CI/CD در فرایند مدیریت پیکربندی و استقرار نرمافزار به کار میرود. افرادی که در حوزههایی مانند مهندسی دواپس و مهندسی کلود فعالیت میکنند، میتوانند از یادگیری آن بهره ببرند. برای استفاده موثر از این ابزار، آشنایی با مانیفستهای Kubernetes و روش استقرار برنامههای کانتینری ضروری است.
ویژگیهای کلیدی
موارد زیر تصویری کلی از این بخش برای این ابزار ارائه میکنند.
-
مدیریت Base و Overlay
مانیفستهای مشترک در base یا پایه قرار میگیرند و تغییرات مخصوص هر محیط در overlay یا لایه محیطی اعمال میشوند؛ بنابراین از تکثیر فایلهای YAML جلوگیری میشود.
-
سفارشیسازی بدون قالبسازی متغیرمحور
تغییر نام منابع، namespace، label، annotation، image، replica و patchها بدون ساخت قالبهای متغیرمحور انجام میشود.
-
Patch کردن منابع Kubernetes
patch یا وصله تغییر میتواند بخشی از Deployment، Service یا منبع دیگر را تغییر دهد، بدون آنکه نسخه کامل و جداگانهای از مانیفست نگهداری شود.
-
تولید ConfigMap و Secret
generatorها ConfigMap و Secret را از فایل، مقدار literal یا فایل محیطی میسازند. نام منبع تولیدشده میتواند با هش محتوا تغییر کند. مرجع: kubectl.docs.kubernetes.io
-
یکپارچگی با kubectl
برای ساخت خروجی از kubectl kustomize و برای اعمال پیکربندی از kubectl apply -k استفاده میشود. مرجع: kubernetes.io
-
ترکیب منابع محلی و راهدور
هر kustomization میتواند منابع YAML محلی یا منابع یک مخزن Git را ترکیب کند تا اجزای مشترک میان سرویسها قابل استفاده مجدد باشند. مرجع: kubectl.docs.kubernetes.io
کاربردها
در ادامه، مهمترین موارد این بخش به تفکیک معرفی شدهاند.
-
تفکیک تنظیمات محیطهای توسعه و تولید
یک سرویس در همه محیطها Deployment مشترک دارد، اما در production به replica، منابع پردازشی و image tag متفاوت نیاز دارد.
-
نمونه پایه و لایه تولید
ساختار را بهصورت base/deployment.yaml، base/kustomization.yaml و overlays/production/kustomization.yaml بسازید. در overlay مقدار images و replicas را تغییر دهید، سپس kubectl kustomize overlays/production را اجرا کنید.
-
کنترل خروجی پیش از اعمال
خروجی YAML تولیدشده را با مانیفست مورد انتظار یا diff نسخه قبلی مقایسه کنید. فقط وقتی image، replica، namespace و منابع تغییرکرده همان مقادیر موردنظر هستند، kubectl apply -k overlays/production را اجرا کنید.
-
اعمال تغییرات محدود روی مانیفستهای آماده
وقتی مانیفست یک نرمافزار متنباز دریافت شده است، تیم میتواند namespace، image registry، label یا تنظیمات شبکه را با patch تغییر دهد.
-
استقرار GitOps با خروجی قابل بازبینی
پیش از اعمال تغییرات در کلاستر، خروجی نهایی YAML در Pull Request یا «درخواست ادغام» بررسی میشود تا تفاوت پیکربندیها شفاف بماند.
-
جایگزینی image در فرایند انتشار
در خط لوله CI/CD، overlay انتشار میتواند image جدید سرویس را تعیین کند، بدون آنکه فایل پایه Deployment تغییر کند.
پرسشهای رایج درباره کاستومایز
در این بخش، به تعدادی از پرسشهای رایج درباره این ابزار پاسخ داده شده است.
آیا کاستومایز جایگزین Helm است؟
نه همیشه. کاستومایز برای مدیریت تفاوتهای لایهای روی YAML مناسب است. Helm برای انتشار بسته، وابستگیهای chart، مقادیر پارامتری زیاد و مدیریت release امکانات بیشتری دارد. مستندات Helm: helm.sh
فایل kustomization.yaml چیست؟
فایل اصلی پیکربندی کاستومایز است. در آن منابع پایه، patchها، imageها، generatorها، labelها و دیگر تغییراتی که باید روی خروجی YAML اعمال شوند تعریف میشوند. مرجع: kubectl.docs.kubernetes.io
چگونه خروجی کاستومایز را بررسی کنم؟
با فرمان kubectl kustomize مسیر پوشه، YAML نهایی را تولید کنید. خروجی را پیش از kubectl apply -k با مانیفست مورد انتظار یا diff نسخه قبلی مقایسه کنید. مرجع: kubernetes.io
آیا کاستومایز برای نگهداری Secret امن است؟
خیر. تبدیل مقدار Secret به base64 آن را رمزنگاری نمیکند. برای دادههای حساس از سامانه مدیریت راز یا راهکارهایی مانند Sealed Secrets و External Secrets استفاده کنید. مستندات Kubernetes: kubernetes.io
پیشنیاز یادگیری کاستومایز چیست؟
باید ساختار منابع Kubernetes، YAML، namespace، Deployment، Service و کار با kubectl را بشناسید. بدون درک مانیفستهای پایه، تشخیص اثر patchها دشوار میشود.
چه زمانی patchهای کاستومایز دشوار میشوند؟
وقتی تعداد overlayها و patchهای وابسته زیاد شود، یافتن منشأ هر تغییر و پیشبینی خروجی نهایی دشوارتر میشود. در این حالت baseها را کوچک نگه دارید، overlayها را محدود کنید و خروجی تولیدشده را در بازبینی کد کنترل کنید.