
کوبرنتیز رو از کجا شروع کنیم؟ (پایهها + Helm Chart)
اگه تازه داری وارد کوبرنتیز میشی، احتمالاً یه عالمه کلمه میبینی که اولش گیجکنندهست:
پاد، دیپلویمنت، سرویس، اینگرس… بعدشم kubectl که حس میکنی یه زبان جدیده 😄
ولی واقعیت اینه که برای شروع، لازم نیست همهچیز رو بلد باشی.
فقط باید چند تا مفهوم اصلی رو درست بفهمی و بدونی تو پروژه واقعی به چه دردت میخوره.
به زبان ساده: تو یه سرویس داری (مثلاً یه API) و میخوای:
● همیشه بالا باشه
● اگه کرش کرد خودش بیاد بالا
● اگه ترافیک زیاد شد چند نسخه ازش داشته باشی
● نسخه جدید رو بدون دردسر دیپلوی کنی
کوبرنتیز یه سیستم مدیریت اجرای کانتینرهاست که این کارها رو استاندارد و اتومات میکنه.
Pod رو مثل یه “جعبه” تصور کن که داخلش کانتینر(های) برنامهات اجرا میشن.
● برنامهات داخل Pod ران میشه
● پادها ممکنه هر لحظه از بین برن و دوباره ساخته بشن
● پس پاد “سرور ثابت” نیست، یه واحد موقتیه
حالا سوال: اگه پاد مُرد چی؟ اگه بخوای ۳ تا نسخه از سرویس داشته باشی چی؟
اینجاست که Deployment میاد وسط:
● تعداد Replicaها رو مدیریت میکنه
● اگر یکی افتاد، یکی دیگه میسازه
● دیپلوی نسخه جدید / برگشت به نسخه قبل (Rollout / Rollback) رو هندل میکنه
از اونجا که پادها ثابت نیستن (IP عوض میشه و …)، ما یه آدرس “پایدار” میخوایم. این همون Service هست:
● یه راه ثابت برای دسترسی میده
● ترافیک رو بین پادها پخش میکنه (Load balancing ساده)
اگه بخوای از بیرون اینترنت یا از طریق دامنه به سرویسات دسترسی داشته باشی، معمولاً Ingress وارد بازی میشه:
● دامنه/مسیرها رو روت میکنه (مثلاً /api بره سمت سرویس A)
● معمولاً SSL/TLS هم همینجا مدیریت میشه (بسته به setup)
برنامه بدون کانفیگ هیچیه: URL دیتابیس، توکنها، کلیدها، اسم سرویسها و…
● ConfigMap برای تنظیمات معمولی
● Secret برای اطلاعات حساس (پسورد، توکن، کلید)
نکته مهم: تنظیمات رو از کد جدا نگه داری، تو محیطهای مختلف (dev/stage/prod) نجاتت میده.
kubectl چی کارهست؟kubectl ریموت کنترل کوبره. باهاش:
● وضعیت منابع رو میبینی
● لاگ میخونی
● دیباگ میکنی
● دیپلویمنت/سرویس رو چک میکنی
(توی پست بعدی دقیقاً همینارو کاربردی میگم که تو پروژه واقعی چطور استفاده کنی.)
حالا برسیم به جایی که تو کار واقعی خیلی میبینیش: Helm.
Helm رو میگن “Package Manager کوبرنتیز”. یعنی به جای اینکه کلی فایل YAML جدا جدا داشته باشی (deployment, service, ingress, configmap, …)
همهش رو میذاری توی یه پکیج مرتب به اسم Chart و با یه دستور نصب/آپدیتش میکنی.
Helm Chart معمولاً شامل ایناست:
● templateهای YAML (قابل پارامتری شدن)
● یه فایل values.yaml برای تنظیمات
● نسخهبندی و قابلیت reuse
چرا Helm تو تیمها مهمه؟
چون تو عمل این اتفاق میافته:
● شما dev/stage/prod داری
● برای هر محیط یه سری مقدار فرق میکنه (replica، آدرس DB، منابع، دامنه، …)
● اگه همهچی YAML خام باشه، مدیریت و نگهداریش دردسر میشه
Helm کمک میکنه:
● با یک چارت چند محیط رو مدیریت کنی
● تنظیمات رو تو values.yaml کنترل کنی
● دیپلوی و آپگریدت استاندارد و قابل تکرار باشه
جمعبندی خودمونی
برای شروع کوبرنتیز لازم نیست بری سراغ بحثهای خیلی سنگین. اگر اینا رو درست بفهمی، پایهات محکمه:
● Pod
● Deployment
● Service
● Ingress
● ConfigMap/Secret
● و بعدش Helm Chart برای دیپلوی تمیز و تیمی
من توی پستهای بعدی:
● kubectl رو برای دیباگ واقعی میگم
● یه سرویس ساده رو دیپلوی میکنیم
● بعدش هم همون رو با Helm Chart پکیج میکنیم
و سمپلها رو توی گیت میذارم که بشه تمرین کرد.