آموزش Certified Kubernetes Application Developer (CKAD) جلد اول

۱. منشأ Kubernetes در Google

۱.۱ ظهور نیاز به مدیریت مقیاس‌پذیر در Google

✅ در اوایل دهه ۲۰۰۰، گوگل با چالش مدیریت میلیون‌ها کانتینر در سرورهای خود مواجه شد.
✅ برای حل این مشکل، گوگل سیستم Borg را توسعه داد که یک سیستم داخلی Orchestration برای مدیریت بارهای کاری در سطح بسیار بزرگ بود.
✅ Borg به گوگل کمک کرد تا برنامه‌های داخلی خود را مقیاس‌پذیر، پایدار و بهینه اجرا کند.

۱.۲ توسعه Kubernetes بر پایه تجربیات Borg

✅ در سال ۲۰۱۴، گوگل تصمیم گرفت تا تجربه خود در زمینه مدیریت کانتینرها را به صورت متن‌باز (Open Source) ارائه دهد.
✅ Kubernetes با الهام از Borg اما با طراحی ماژولارتر و انعطاف‌پذیرتر توسعه یافت.
✅ برخی از مهندسان کلیدی گوگل که در توسعه Borg نقش داشتند، پروژه Kubernetes را رهبری کردند، از جمله:

• Joe Beda
• Brendan Burns
• Craig McLuckie

✅ نام Kubernetes از یک واژه یونانی به معنی سکان‌دار کشتی گرفته شده است، که نمادی از هدایت و کنترل در مدیریت کانتینرهاست.

۲. انتقال Kubernetes به CNCF

۲.۱ تأسیس Cloud Native Computing Foundation (CNCF)

✅ در سال ۲۰۱۵، بنیاد Linux Foundation پروژه Cloud Native Computing Foundation (CNCF) را برای حمایت از فناوری‌های Cloud-Native ایجاد کرد.
✅ هدف CNCF، استانداردسازی و توسعه ابزارهای Cloud-Native مانند Kubernetes، Prometheus، Envoy و Helm بود.

۲.۲ سپرده شدن Kubernetes به CNCF

✅ در ژوئیه ۲۰۱۵، گوگل تصمیم گرفت پروژه Kubernetes را به CNCF منتقل کند تا از حمایت جامعه متن‌باز و شرکت‌های بزرگ برخوردار شود.
✅ Kubernetes به سرعت به عنوان محبوب‌ترین پروژه CNCF رشد کرد و امروزه بیش از ۱۵۰۰ مشارکت‌کننده فعال دارد.

۳. مراحل کلیدی در تاریخ Kubernetes

۳.۱ نسخه‌های اولیه (۲۰۱۵-۲۰۱۶)

✅ Kubernetes 1.0 در ژوئیه ۲۰۱۵ منتشر شد و پشتیبانی از Pods، Services و Replication Controllers را ارائه کرد.
✅ در ۲۰۱۶، ابزار Helm برای مدیریت ساده‌تر Deployments معرفی شد.

۳.۲ پذیرش گسترده و پیشرفت (۲۰۱۷-۲۰۱۹)

✅ در ۲۰۱۷، Kubernetes به سرعت به عنوان استاندارد صنعتی پذیرفته شد.
✅ شرکت‌های بزرگی مانند Microsoft، IBM، Red Hat و AWS از Kubernetes در سرویس‌های ابری خود پشتیبانی کردند.
✅ در ۲۰۱۸، Kubernetes به اولین پروژه CNCF تبدیل شد که به وضعیت پایدار (Graduated) رسید.

۳.۳ رشد و تکامل (۲۰۲۰ تاکنون)

✅ ویژگی‌هایی مانند Serverless Kubernetes (با Knative)، Service Mesh (با Istio) و مدیریت چندکلاستری (Multi-Cluster) به Kubernetes اضافه شدند.
✅ امروزه Kubernetes هسته اصلی بسیاری از پلتفرم‌های ابری مانند Google Kubernetes Engine (GKE)، Amazon Elastic Kubernetes Service (EKS) و Azure Kubernetes Service (AKS) است.

جمع‌بندی

✅ Kubernetes در ابتدا توسط گوگل بر اساس تجربیات سیستم Borg توسعه یافت و در سال ۲۰۱۵ به CNCF سپرده شد.
✅ Kubernetes به سرعت تبدیل به استاندارد مدیریت کانتینرها در دنیای Cloud-Native شد.
✅ این فناوری همچنان در حال تکامل است و به عنوان یکی از مهم‌ترین ابزارهای Cloud-Native مورد استفاده قرار می‌گیرد.

🚀 امروز Kubernetes هسته اصلی بسیاری از زیرساخت‌های Cloud-Native و DevOps در سراسر جهان است!

۱. چرا Orchestration در مدیریت کانتینرها ضروری است؟

✅ استقرار (Deployment) خودکار
✅ مدیریت مقیاس‌پذیری (Scaling)
✅ توزیع بار (Load Balancing)
✅ مدیریت سلامت (Health Monitoring)
✅ ارتباطات شبکه‌ای (Networking)

۲. وظایف اصلی یک Orchestrator در مدیریت کانتینرها

۲.۱ استقرار (Deployment) و زمان‌بندی کانتینرها

• مشخص کردن نود مناسب برای اجرای هر کانتینر
• کنترل تعداد نسخه‌های در حال اجرا
• مدیریت به‌روزرسانی و بازگشت به نسخه‌های قبلی

۲.۲ مقیاس‌پذیری خودکار (Auto-Scaling)

• افزایش خودکار تعداد کانتینرها در زمان افزایش ترافیک
• کاهش تعداد کانتینرها در زمان کاهش درخواست‌ها

۲.۳ توزیع بار و مدیریت ترافیک (Load Balancing & Networking)

• توزیع درخواست‌ها بین چندین کانتینر
• ارتباط امن و سریع بین سرویس‌های مختلف

۲.۴ بازیابی خودکار (Self-Healing)

• راه‌اندازی مجدد کانتینرهای ناسالم
• حذف و جایگزینی نودهای خراب

۲.۵ مدیریت تنظیمات و داده‌ها

• استفاده از ConfigMaps و Secrets برای تنظیمات
• ذخیره‌سازی پایدار داده‌ها با Persistent Volumes

۳. مقایسه Kubernetes با سایر Orchestratorها

۴. Orchestration در Kubernetes چگونه انجام می‌شود؟

✔ Scheduler → مدیریت زمان‌بندی اجرای Podها
✔ Controller Manager → مدیریت خودکار وضعیت سیستم
✔ Kubelet → بررسی سلامت کانتینرها
✔ Kube-proxy → مدیریت شبکه و مسیریابی
✔ API Server → ارتباط Kubernetes با کاربران

جمع‌بندی

✅ Orchestration، فرآیند مدیریت، هماهنگی و اجرای خودکار کانتینرها است.
✅ Kubernetes، محبوب‌ترین Orchestrator با قابلیت‌هایی مانند Auto-Scaling، Self-Healing و Load Balancing است.
✅ بدون Orchestration، مدیریت دستی هزاران کانتینر بسیار دشوار خواهد بود.
✅ مؤلفه‌های Scheduler، API Server و Kubelet در Kubernetes نقش کلیدی در Orchestration دارند.

🚀 یادگیری Kubernetes شما را برای مدیریت برنامه‌های Cloud-Native آماده می‌کند!

۱. مزایای Kubernetes در Cloud-Native

۱.۱ مقیاس‌پذیری خودکار (Auto-Scaling)

✅ Kubernetes می‌تواند به صورت خودکار تعداد کانتینرهای در حال اجرا را بر اساس مصرف منابع (CPU، RAM) یا میزان درخواست‌ها افزایش یا کاهش دهد.
✅ دو نوع مقیاس‌پذیری در Kubernetes وجود دارد:

• Horizontal Pod Autoscaler (HPA): افزایش یا کاهش تعداد Podها.
• Vertical Pod Autoscaler (VPA): تخصیص بیشتر یا کمتر منابع به یک Pod.

نمونه‌ای از مقیاس‌پذیری خودکار:

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50

📂 فایل YAML فوق را در مسیر /manifests/hpa.yaml ذخیره کرده و با دستور زیر اعمال کنید:

kubectl apply -f /manifests/hpa.yaml

۱.۲ مدیریت استقرار (Rolling Updates & Rollbacks)

✅ Kubernetes از به‌روزرسانی مرحله‌ای (Rolling Update) پشتیبانی می‌کند و در صورت بروز خطا، امکان برگشت (Rollback) به نسخه قبلی را فراهم می‌آورد.

مثال: به‌روزرسانی یک Deployment بدون قطعی سرویس

kubectl set image deployment/my-app my-app=nginx:1.21

✅ اگر مشکلی در نسخه جدید وجود داشته باشد، می‌توان با اجرای دستور زیر Rollback کرد:

kubectl rollout undo deployment/my-app

۱.۳ خود ترمیمی (Self-Healing)

✅ اگر یکی از Pods خراب شود، Kubernetes به طور خودکار یک Pod جدید جایگزین آن می‌کند.
✅ اگر یکی از نودهای Worker از کار بیفتد، Kubernetes بار کاری را به نودهای سالم منتقل می‌کند.

بررسی وضعیت سلامت یک Pod:

kubectl get pods -o wide

✅ در صورتی که یک Pod ناسالم باشد، می‌توان آن را حذف کرد تا Kubernetes آن را مجدداً ایجاد کند:

kubectl delete pod my-pod

۱.۴ مدیریت بار (Load Balancing) و توزیع ترافیک

✅ Kubernetes از Load Balancer داخلی برای توزیع بار بین چندین Pod پشتیبانی می‌کند.
✅ این قابلیت باعث افزایش دسترسی‌پذیری (High Availability) و کاهش زمان پاسخ‌دهی (Latency) می‌شود.

ایجاد یک LoadBalancer Service برای دسترسی خارجی به یک برنامه:

apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  type: LoadBalancer
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

📂 این فایل را در مسیر /manifests/service.yaml ذخیره کرده و اجرا کنید:

kubectl apply -f /manifests/service.yaml

۱.۵ انعطاف‌پذیری و پشتیبانی از Hybrid و Multi-Cloud

✅ Kubernetes به راحتی می‌تواند در محیط‌های ابری مختلف (AWS، GCP، Azure، OpenShift) یا دیتاسنترهای داخلی (On-Premises) اجرا شود.
✅ پشتیبانی از Hybrid-Cloud و Multi-Cloud باعث افزایش انعطاف‌پذیری و استقلال از یک ارائه‌دهنده ابری خاص می‌شود.

kubectl config use-context aws-cluster
kubectl config use-context gcp-cluster

✅ این قابلیت به شما اجازه می‌دهد میان چندین ارائه‌دهنده ابری جابه‌جا شوید.

۲. کاربردهای Kubernetes در Cloud-Native

۲.۱ مدیریت میکروسرویس‌ها (Microservices)

✅ Kubernetes با Service Discovery، Load Balancing و Networking داخلی، مدیریت میکروسرویس‌ها را آسان‌تر می‌کند.
✅ ترکیب Kubernetes با ابزارهایی مانند Istio و Linkerd باعث بهبود امنیت و مدیریت ترافیک بین سرویس‌ها می‌شود.

۲.۲ اجرای CI/CD و DevOps

✅ Kubernetes از ابزارهای CI/CD مانند Jenkins، ArgoCD و GitOps برای استقرار خودکار (Continuous Deployment) پشتیبانی می‌کند.

مثال: اجرای یک Job در Kubernetes برای CI/CD

apiVersion: batch/v1
kind: Job
metadata:
  name: build-job
spec:
  template:
    spec:
      containers:
        - name: build
          image: jenkins:latest
      restartPolicy: Never

۲.۳ اجرای Workloadهای مختلف (Batch Processing، AI/ML، Big Data)

✅ Kubernetes برای اجرای پردازش‌های Batch، هوش مصنوعی (AI/ML) و کلان داده (Big Data) با ابزارهایی مانند Kubeflow، Spark و TensorFlow Serving ایده‌آل است.

۲.۴ امنیت و ایزوله‌سازی منابع (Security & Multi-Tenancy)

✅ Kubernetes از Namespaces و Role-Based Access Control (RBAC) برای ایزوله‌سازی و افزایش امنیت در محیط‌های چندکاربره (Multi-Tenant) استفاده می‌کند.

ایجاد یک Namespace برای جداسازی منابع:

kubectl create namespace my-team

✅ تنظیم سطح دسترسی برای کاربران خاص:

kubectl create rolebinding dev-access --clusterrole=edit --user=developer --namespace=my-team

جمع‌بندی

✅ Kubernetes یک راه‌حل جامع برای مدیریت برنامه‌های Cloud-Native است که امکاناتی مانند Auto-Scaling، Self-Healing، Load Balancing و CI/CD را فراهم می‌کند.
✅ این پلتفرم به توسعه‌دهندگان کمک می‌کند تا برنامه‌های میکروسرویسی، پردازش داده، یادگیری ماشین و DevOps را به شکل مقیاس‌پذیر و انعطاف‌پذیر اجرا کنند.
✅ پشتیبانی از Hybrid-Cloud و Multi-Cloud باعث شده است که Kubernetes به استاندارد جهانی در دنیای Cloud-Native تبدیل شود.

🚀 Kubernetes، راهکاری برای آینده‌ی مقیاس‌پذیر و خودکارسازی مدیریت کانتینرها در Cloud-Native!

۱. Master Node

Master Node به عنوان مغز کنترل و مدیریت کلاستر در Kubernetes عمل می‌کند. وظایف اصلی این Node عبارتند از:

۱.۱. مدیریت و کنترل کلاستر

• Master Node مسئول مدیریت کلاستر است. این نود کنترل کلیه منابع و وضعیت کلاستر را بر عهده دارد و برای تصمیم‌گیری در مورد اجرای Pods و سایر منابع به کار می‌رود.

۱.۲. مسئولیت‌ مدیریت API Server

• API Server که به عنوان نقطه دسترسی اصلی برای تعامل با کلاستر عمل می‌کند، بر روی Master Node قرار دارد. این API تمامی درخواست‌ها را از کاربران و ابزارهای دیگر دریافت کرده و برای پردازش و ذخیره‌سازی به سایر اجزای سیستم منتقل می‌کند.

۱.۳. نظارت بر وضعیت منابع

• Controller Manager و Scheduler که در Master Node مستقر هستند، وضعیت منابع مختلف را بررسی کرده و تصمیم می‌گیرند که Pods باید در کدام Worker Node اجرا شوند.

۱.۴. اجزای اصلی Master Node

• API Server
• Controller Manager
• Scheduler
• etcd (پایگاه داده توزیع‌شده برای ذخیره وضعیت کلاستر)

۱.۵. وظایف اصلی Master Node

• تصمیم‌گیری برای مقیاس‌پذیری منابع
• هماهنگ‌سازی و مدیریت وضعیت منابع
• ذخیره‌سازی وضعیت کلی کلاستر در etcd
• ارتباط با Kubelet در Worker Node‌ها برای مدیریت منابع

۲. Worker Node

Worker Node (یا نود اجرایی) مسئول اجرای و ارائه منابع کلاستر است. این نودها در واقع محل اجرای Pods و کانتینرهای Kubernetes هستند و از طریق Master Node مدیریت می‌شوند.

۲.۱. اجرای Pods و Containers

• در Worker Node‌ها، کانتینرهای مختلف (که در قالب Pods بسته‌بندی می‌شوند) اجرا می‌شوند. هر Node می‌تواند چندین Pod را در خود میزبانی کند.

۲.۲. مسئولیت‌های زیرساختی

• Kubelet و Kube Proxy دو ابزار مهم در Worker Node‌ها هستند:
  • Kubelet وظیفه اجرای و نظارت بر وضعیت Pods و کانتینرها را در این نودها به عهده دارد.
  • Kube Proxy مسئولیت مدیریت شبکه و Load Balancing در بین Pods را انجام می‌دهد.

۲.۳. اجزای اصلی Worker Node

• Kubelet
• Kube Proxy
• Container Runtime (مانند Docker یا containerd)

۲.۴. وظایف اصلی Worker Node

• اجرای Pods و کانتینرها بر اساس دستورات دریافتی از Master Node
• ارتباط با Master Node برای دریافت وضعیت و اطلاعات جدید
• ارائه منابع لازم برای اجرای صحیح کانتینرها

۳. تفاوت‌های کلیدی Master Node و Worker Node

جمع‌بندی

Master Node و Worker Node در Kubernetes وظایف متفاوتی دارند که مکمل یکدیگر هستند. در حالی که Master Node به مدیریت و نظارت کلی کلاستر می‌پردازد، Worker Node‌ها به عنوان محل اجرایی برنامه‌ها و کانتینرها عمل می‌کنند. برای عملکرد بهینه کلاستر، همکاری میان این دو نوع Node ضروری است.

مدیریت کلاستر
یکی از وظایف اصلی Master Node، مدیریت وضعیت کلی کلاستر است. این نود به عنوان مرکز فرماندهی کلاستر عمل می‌کند و تمامی درخواست‌های مرتبط با کلاستر را از دیگر نودها (Worker Node‌ها) و ابزارهای کنترلی دریافت می‌کند. Master Node به هماهنگ‌سازی اجرای منابع مختلف در کلاستر می‌پردازد و تصمیم‌گیری‌های کلیدی در مورد تخصیص منابع و مقیاس‌پذیری را انجام می‌دهد.

نظارت و بررسی وضعیت کلاستر
Master Node وظیفه نظارت بر وضعیت کلی کلاستر را بر عهده دارد. این نود از etcd برای ذخیره‌سازی وضعیت جاری کلاستر استفاده می‌کند و تمامی اطلاعات مربوط به منابع مانند Pods، Nodes و تنظیمات مختلف را در آن ذخیره می‌نماید. در صورت بروز هرگونه تغییر، Master Node آن را پیگیری کرده و وضعیت را به‌روزرسانی می‌کند.

اجرای API Server
API Server که در Master Node قرار دارد، به عنوان دروازه اصلی ارتباطی بین کاربر، ابزارها و سایر اجزای کلاستر عمل می‌کند. تمام درخواست‌ها از طریق API Server به سایر اجزا ارسال می‌شود و Master Node با استفاده از API Server عملیات را انجام می‌دهد. این سرور درخواست‌های مختلفی مانند ایجاد، حذف یا بروزرسانی منابع را پردازش می‌کند.

مدیریت و نظارت بر Pods و منابع
Scheduler در Master Node وظیفه تخصیص Pods به Worker Node‌ها را بر عهده دارد. این بخش منابع سیستم را بررسی کرده و تصمیم می‌گیرد که کدام Node بهترین مکان برای اجرای یک Pod است. Controller Manager هم وظیفه نظارت بر وضعیت منابع موجود را دارد و در صورت نیاز، اقدام به اصلاح وضعیت می‌کند. این وظایف کمک می‌کنند تا برنامه‌ها به صورت خودکار و با بالاترین کارایی اجرا شوند.

اجرای و هماهنگ‌سازی تغییرات در کلاستر
هنگامی که تغییری در کلاستر اعمال می‌شود، مانند تغییر تعداد Replica‌ها یا اعمال یک Deployment جدید، این تغییرات ابتدا در Master Node پردازش و هماهنگ می‌شوند. این نود مسئول اطلاع‌رسانی به Kubelet در Worker Node‌ها است تا تغییرات اعمال شوند و وضعیت جدید کلاستر در اختیار همه اجزا قرار گیرد.

جمع‌بندی
در مجموع، Master Node به عنوان مرکز مدیریت و هماهنگی در کلاستر Kubernetes عمل می‌کند و تمامی فرآیندهای نظارت، مقیاس‌پذیری و تغییرات منابع را هدایت می‌کند. از طریق ابزارهایی مانند API Server، Scheduler، Controller Manager و etcd، Master Node به انجام وظایف خود در مدیریت کلاستر پرداخته و تضمین می‌کند که تمامی منابع به درستی و با کارایی بالا عمل کنند.

اجرای Pods
مهم‌ترین وظیفه Worker Node اجرای Pods است. هر Pod که شامل یکی یا چندین کانتینر است، به یک Worker Node اختصاص داده می‌شود تا به صورت عملیاتی و در شرایط واقعی اجرا شود. در حقیقت، Worker Node محلی است که کانتینرها و برنامه‌ها در آن اجرا می‌شوند و منابع سخت‌افزاری مانند CPU، حافظه و شبکه به آن‌ها تخصیص داده می‌شود.

مدیریت منابع و تخصیص آن‌ها
هر Worker Node دارای منابعی مانند CPU، حافظه و شبکه است که برای اجرای Pods تخصیص داده می‌شود. Kubelet که یک پروسه موجود در هر Worker Node است، مسئول نظارت و مدیریت این منابع است و به طور مداوم وضعیت هر Pod را بررسی می‌کند. در صورتی که منابع یا وضعیت یک Pod به مشکل بخورد، Kubelet اقدام به اطلاع‌رسانی به Master Node می‌کند.

نظارت و کنترل وضعیت Pods
Kubelet در هر Worker Node مسئول نظارت بر سلامت Pods است. این اجزا به صورت خودکار وضعیت اجرای Pods را کنترل می‌کنند و در صورت بروز مشکل مانند خرابی یک کانتینر، اقدام به راه‌اندازی مجدد آن می‌کنند. Kubelet به صورت دوره‌ای با Master Node ارتباط برقرار می‌کند و وضعیت موجود در Worker Node را به روز می‌کند تا هماهنگی با etcd حفظ شود.

مدیریت شبکه داخلی میان Pods
هر Worker Node مسئول مدیریت ارتباط شبکه‌ای میان Pods در داخل خود و همچنین با دیگر Pods در سایر Worker Node‌ها است. این وظیفه با استفاده از Kube-proxy انجام می‌شود که مسئول load balancing و network forwarding است. Kube-proxy وظیفه دارد ترافیک شبکه را به درستی میان Pods هدایت کند و اطمینان حاصل کند که ارتباطات به درستی برقرار می‌شوند.

گزارش‌دهی به Master Node
Kubelet در هر Worker Node به صورت مداوم گزارش‌های وضعیت Pod‌ها و منابع را به Master Node ارسال می‌کند. این اطلاعات شامل وضعیت اجرای کانتینرها، تخصیص منابع، سلامت و عملکرد کلی Pods است. بر اساس این گزارش‌ها، Master Node قادر خواهد بود تا وضعیت کلی کلاستر را پیگیری و هرگونه تغییر یا اصلاحات لازم را انجام دهد.

مدیریت Volume‌ها و ذخیره‌سازی داده‌ها
Worker Node‌ها همچنین مسئول مدیریت Volumes هستند که برای ذخیره‌سازی داده‌ها مورد استفاده قرار می‌گیرند. این نودها به PersistentVolumes و PersistentVolumeClaims دسترسی دارند و می‌توانند داده‌های دائمی را ذخیره کنند که در صورت نیاز به Pods متصل می‌شوند. این منابع ذخیره‌سازی به Pods اختصاص داده می‌شوند و اطمینان حاصل می‌کنند که داده‌های آن‌ها در شرایط مختلف پایدار بماند.

جمع‌بندی
در نهایت، Worker Node‌ها نقش حیاتی در اجرای و عملکرد برنامه‌ها در Kubernetes دارند. این نودها مسئول اجرای Pods، تخصیص منابع، نظارت بر وضعیت Pods و مدیریت ارتباطات شبکه‌ای بین Pods هستند. همچنین، از طریق Kubelet و Kube-proxy هماهنگی بین منابع و ارتباطات در سطح کلاستر را فراهم می‌کنند. Master Node از این نودها به عنوان منابع اجرایی استفاده می‌کند و Worker Node‌ها نقش کلیدی در عملیات روزمره برنامه‌ها در کلاستر دارند.

نحوه کار API Server

زمانی که یک کاربر یا سرویس داخلی در تلاش است تا با Kubernetes ارتباط برقرار کند، ابتدا درخواست خود را به API Server ارسال می‌کند. این درخواست‌ها می‌توانند شامل عملیات‌های مختلفی مانند ایجاد، حذف، یا به‌روزرسانی منابع کلاستر (مثلاً Pod، Service، Deployment و غیره) باشند.

پس از دریافت درخواست، API Server آن را پردازش کرده و در صورت صحت، درخواست را به اجزای دیگر کلاستر (مثل Scheduler، Controller Manager و Kubelet) ارسال می‌کند تا عملیات به‌درستی اجرا شود. به عبارت دیگر، API Server در اصل مسئولیت دریافت، اعتبارسنجی و پردازش درخواست‌ها را بر عهده دارد و آن‌ها را به سایر اجزای مناسب کلاستر منتقل می‌کند.

ارتباط با کاربران و سیستم‌ها

API Server تنها نقطه‌ای است که کاربران خارجی یا سرویس‌های داخلی می‌توانند با آن ارتباط برقرار کنند. به‌عبارت دیگر، هیچ‌گونه ارتباط مستقیم و مستقلی بین کاربران یا دیگر اجزای کلاستر و منابع داخلی کلاستر وجود ندارد. همه‌ی این ارتباطات از طریق API Server انجام می‌شود.

کاربران از طریق kubectl یا سایر ابزارهای CLI یا حتی سیستم‌های خودکار مانند CI/CD با API Server ارتباط برقرار می‌کنند. این درخواست‌ها می‌توانند به‌صورت دستورات مختلفی که نیاز به مدیریت منابع دارند، ارسال شوند. به طور مثال:

kubectl get pods
kubectl create -f pod.yaml

این دستورات از طرف kubectl به API Server ارسال می‌شوند. API Server آن‌ها را دریافت کرده و پردازش می‌کند.

امنیت و احراز هویت در API Server

یکی از ویژگی‌های بسیار مهم در API Server، بخش امنیت و احراز هویت آن است. هرگونه درخواست باید اعتبارسنجی شود و اطمینان حاصل شود که تنها کاربران و سرویس‌های مجاز قادر به تغییر وضعیت منابع کلاستر هستند. این فرآیند از طریق احراز هویت (Authentication) و کنترل دسترسی (Authorization) انجام می‌شود.

به طور معمول، این امنیت با استفاده از مکانیسم‌هایی مانند RBAC (Role-Based Access Control)، Service Accounts و OAuth Tokens پیاده‌سازی می‌شود.

تعامل API Server با سایر اجزای کلاستر

API Server در Kubernetes به‌عنوان نقطه‌ مرکزی برای مدیریت و هدایت درخواست‌ها و تعاملات در داخل کلاستر عمل می‌کند. این بخش از سیستم مسئول ارتباط مستقیم با سایر اجزای کلاستر و برقراری هماهنگی بین آن‌ها است. از آنجا که API Server درخواست‌ها را از کاربران یا سایر اجزا دریافت کرده و آن‌ها را به اجزای مختلف هدایت می‌کند، تعاملات میان API Server و سایر بخش‌ها برای عملکرد صحیح و بهینه کلاستر ضروری است.

نحوه تعامل API Server با اجزای مختلف کلاستر

1. Interaction with etcdetcd پایگاه داده توزیع‌شده‌ای است که وضعیت کلی کلاستر و منابع آن را ذخیره می‌کند. تمام تغییراتی که در منابع کلاستر ایجاد می‌شود، در etcd ثبت می‌شود. زمانی که API Server درخواست تغییر وضعیت یک منبع (مانند ایجاد یا به‌روزرسانی یک Pod) را دریافت می‌کند، این تغییرات به etcd ارسال می‌شود تا وضعیت کلاستر و منابع آن به‌روز شود. در واقع، etcd به‌عنوان یک منبع واحد برای ذخیره‌سازی و هماهنگی وضعیت منابع عمل می‌کند.برای مثال، وقتی یک Pod جدید ایجاد می‌شود، API Server درخواست را پردازش کرده و اطلاعات Pod را به etcd می‌فرستد تا وضعیت جدید کلاستر به‌روز شود.
2. Interaction with Controller ManagerController Manager مسئول اجرای کنترلرهای مختلف در کلاستر است. هر کنترلر وظیفه خاصی دارد، مانند کنترلر ReplicaSet که به‌صورت خودکار تعداد Replicas را در حالت مورد نظر نگه می‌دارد یا Deployment Controller که به‌روزرسانی‌های مستمر برای Deployment‌ها را انجام می‌دهد.وقتی API Server تغییرات جدیدی در وضعیت منابع دریافت می‌کند (مثلاً ایجاد یک Pod یا یک Deployment)، این اطلاعات را به Controller Manager می‌فرستد. سپس Controller Manager مسئول هماهنگی و نظارت بر وضعیت منابع طبق دستورهای داده‌شده است.
3. Interaction with SchedulerScheduler وظیفه دارد تا Pods را بر روی Worker Nodeها تخصیص دهد. زمانی که API Server درخواست جدیدی از کاربر برای ایجاد یک Pod دریافت می‌کند، Scheduler بررسی می‌کند که کدام Node مناسب‌ترین گزینه برای اجرای این Pod است.Scheduler با تحلیل منابع موجود در کلاستر، مثل ظرفیت CPU و حافظه، تعیین می‌کند که Pod باید روی کدام Node اجرا شود. پس از این بررسی‌ها، Scheduler اطلاعات مربوط به تخصیص Pod را به API Server ارسال می‌کند که در نهایت باعث می‌شود Pod به Node مشخص‌شده تخصیص داده شود.
4. Interaction with KubeletKubelet یک عامل اجرایی است که روی هر Worker Node قرار دارد و مسئول اجرای Pods روی Node است. وقتی API Server درخواست ایجاد یا به‌روزرسانی یک Pod را پردازش می‌کند، اطلاعات جدید به Kubelet ارسال می‌شود.Kubelet سپس وظیفه دارد که این تغییرات را به‌صورت محلی در Node اعمال کند. برای مثال، اگر Pod جدیدی باید اجرا شود، Kubelet آن را بر روی Node خود راه‌اندازی می‌کند. Kubelet به‌طور مرتب وضعیت سلامت Pods را بررسی کرده و گزارش‌های آن را به API Server ارسال می‌کند. این ارتباط دوطرفه به API Server این امکان را می‌دهد که وضعیت فعلی Pods را داشته باشد.
5. Interaction with Kube-proxyKube-proxy مسئول مدیریت شبکه داخلی و مسیریابی ترافیک بین Pods و سرویس‌ها در کلاستر است. زمانی که یک سرویس جدید در کلاستر ایجاد می‌شود یا تغییری در پیکربندی شبکه ایجاد می‌شود، API Server این اطلاعات را به Kube-proxy ارسال می‌کند.Kube-proxy سپس با استفاده از این داده‌ها، قوانین لازم برای مسیریابی ترافیک به Pods مناسب را تنظیم می‌کند. این تعامل به API Server کمک می‌کند که از وضعیت صحیح شبکه در کلاستر اطمینان حاصل کند.

جمع‌بندی

API Server در Kubernetes به‌عنوان مرکز ارتباطی میان اجزای مختلف کلاستر عمل می‌کند. این جزء حیاتی تمامی درخواست‌ها را از کاربران دریافت کرده و آن‌ها را به دیگر اجزای کلاستر، از جمله etcd، Controller Manager، Scheduler، Kubelet و Kube-proxy هدایت می‌کند. از این رو، تعامل API Server با این اجزا به‌طور مستقیم بر عملکرد کلی کلاستر تاثیر می‌گذارد و هماهنگی بین آن‌ها برای حفظ وضعیت پایدار و کارآمد کلاستر ضروری است.

etcd به دلیل طراحی ساده و سبک خود، قابلیت تحمل خطا و مقیاس‌پذیری بالایی دارد و معمولاً در معماری‌هایی که به هماهنگی و ذخیره‌سازی وضعیت در محیط‌های توزیع‌شده نیاز دارند، استفاده می‌شود.

ساختار و عملکرد etcd

etcd به‌عنوان یک پایگاه داده کلید-مقدار، داده‌ها را به‌صورت جفت‌های کلید-مقدار ذخیره می‌کند. این داده‌ها می‌توانند شامل هر نوع اطلاعاتی باشند که برای حفظ وضعیت سیستم و هماهنگی میان اجزای مختلف ضروری است. مهم‌ترین ویژگی‌های etcd شامل موارد زیر است:

1. کلیشه‌های داده‌ای ساده: داده‌ها به‌صورت جفت‌های کلید و مقدار ذخیره می‌شوند که این جفت‌ها می‌توانند هر نوع اطلاعاتی از جمله تنظیمات کلاستر، وضعیت Pods، نسخه‌های مختلف برنامه‌ها و تنظیمات شبکه باشند.
2. مدیریت و هماهنگی داده‌ها: etcd به‌طور مداوم داده‌ها را در میان نودهای مختلف کلاستر هماهنگ می‌کند تا از وضعیت یکسان و به‌روز در تمامی نودها اطمینان حاصل شود. در صورت تغییر وضعیت هر کدام از اجزای سیستم، این تغییر به‌طور فوری به تمامی نودهای کلاستر منتقل می‌شود.
3. پشتیبانی از نسخه‌بندی: etcd به شما این امکان را می‌دهد که تاریخچه تغییرات داده‌ها را بررسی کرده و در صورت نیاز به نسخه‌های قبلی بازگردید. این ویژگی به Kubernetes کمک می‌کند تا در صورت بروز مشکل یا خطا در سیستم، به وضعیت پایدار قبلی بازگردد.
4. تضمین تراکنش‌های ایمن و دقیق: etcd از الگوریتم Raft برای مدیریت هماهنگی و اجماع میان نودهای توزیع‌شده استفاده می‌کند. این الگوریتم تضمین می‌کند که داده‌ها در صورت بروز خطاها یا قطع ارتباط نودها، به‌صورت ایمن و قابل‌اعتماد باقی بمانند.

نقش etcd در Kubernetes

در Kubernetes، etcd نقش اساسی در ذخیره‌سازی و مدیریت وضعیت کلاستر ایفا می‌کند. تمامی اطلاعات مربوط به وضعیت منابع مختلف کلاستر، از جمله Pods، Deployments، Services، ConfigMaps و Secrets، در etcd ذخیره می‌شود. به همین دلیل، etcd به‌عنوان “منبع حقیقت” در Kubernetes شناخته می‌شود و هرگونه تغییر در وضعیت منابع در آن ثبت می‌شود.

مهم‌ترین وظایف etcd در Kubernetes به شرح زیر است:

1. ذخیره‌سازی وضعیت کلاستر: هر بار که یک تغییر در وضعیت منابع کلاستر اعمال می‌شود، مانند ایجاد یک Pod جدید یا تغییر در تعداد Replicas یک Deployment، این تغییرات در etcd ثبت می‌شود.
2. ایجاد همگام‌سازی در کلاستر: تمام اجزای مختلف Kubernetes (مانند API Server، Scheduler و Controller Manager) برای هماهنگ‌سازی و انجام عملیات‌های خود به etcd مراجعه می‌کنند. به‌عنوان مثال، زمانی که Scheduler تصمیم می‌گیرد که یک Pod را به کدام Node تخصیص دهد، این تصمیمات در etcd ذخیره می‌شود.
3. پشتیبان‌گیری از تنظیمات و وضعیت: etcd به‌عنوان مکانی برای پشتیبان‌گیری از تنظیمات و وضعیت‌های جاری کلاستر عمل می‌کند. به‌این‌ترتیب، در صورت بروز مشکل یا خرابی، می‌توان با بازیابی etcd به وضعیت قبلی کلاستر بازگشت.
4. پشتیبانی از دستورات API: API Server برای مدیریت درخواست‌ها و درخواست‌های تغییر وضعیت منابع، از etcd استفاده می‌کند. API Server درخواست‌ها را پردازش کرده و سپس تغییرات را به etcd ارسال می‌کند تا وضعیت به‌روز شود.

مزایای استفاده از etcd در Kubernetes

1. مقیاس‌پذیری و همگام‌سازی: etcd به‌خوبی مقیاس‌پذیر است و می‌تواند با رشد اندازه کلاستر، همچنان اطلاعات را به‌طور موثر ذخیره و همگام‌سازی کند.
2. پایداری و تحمل خطا: با استفاده از الگوریتم Raft برای اجماع داده‌ها، etcd قادر است در برابر خطاهای نود یا قطع ارتباط‌های موقتی ایمن و پایدار باقی بماند.
3. پشتیبانی از نسخه‌بندی و تاریخچه: قابلیت بازیابی نسخه‌های قبلی داده‌ها این امکان را به Kubernetes می‌دهد که در مواقع بحرانی از اطلاعات قبلی استفاده کرده و به وضعیت پایدار بازگردد.
4. امنیت داده‌ها: etcd برای اطمینان از امنیت داده‌ها از مکانیزم‌های رمزنگاری برای محافظت از اطلاعات حساس استفاده می‌کند.

ذخیره‌سازی وضعیت کلی کلاستر در etcd

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

نحوه ذخیره‌سازی وضعیت در etcd

1. ذخیره‌سازی اطلاعات منابع مختلف: etcd تمام منابع موجود در کلاستر مانند Pods، Deployments، Services، ReplicaSets، Namespaces و حتی تنظیمات کلاستر را به‌صورت جفت‌های کلید-مقدار ذخیره می‌کند. هر کدام از این منابع به‌عنوان یک ورودی مجزا در etcd در نظر گرفته می‌شود و تغییرات در آن‌ها در etcd ثبت می‌گردد.
2. ساختار داده‌ها در etcd: در etcd داده‌ها به‌صورت سلسله‌مراتبی ذخیره می‌شوند. این داده‌ها می‌توانند شامل کلیدهایی باشند که برای ذخیره‌سازی وضعیت کلاستر به‌طور مداوم تغییر می‌کنند. مثلاً در هنگام تغییر تعداد Pods یا اعمال تغییرات در تنظیمات یک Deployment، اطلاعات جدید در etcd ذخیره می‌شود و در صورت نیاز، وضعیت قبلی نیز قابل بازیابی است.
3. همگام‌سازی میان نودها: تمام نودهای موجود در کلاستر از etcd برای ذخیره‌سازی و همگام‌سازی وضعیت استفاده می‌کنند. در صورتی که یکی از نودها به‌روز نباشد یا درگیر خطا شود، سایر نودها به‌طور خودکار وضعیت جدید را از etcd دریافت کرده و همگام‌سازی می‌شوند.

چگونه وضعیت منابع در etcd ذخیره می‌شود؟

زمانی که تغییری در وضعیت یک منبع در کلاستر رخ می‌دهد، این تغییر در ابتدا به API Server ارسال می‌شود. سپس API Server تغییرات را به etcd منتقل کرده و اطلاعات جدید به‌روزرسانی می‌شود. این تغییرات می‌تواند شامل موارد زیر باشد:

• ایجاد منابع جدید: زمانی که یک Pod یا Deployment جدید ایجاد می‌شود، اطلاعات آن به etcd ارسال می‌شود.
• تغییر وضعیت منابع: اگر تعداد Replicas یک Deployment تغییر کند یا Pod جدیدی در یک Node قرار گیرد، این تغییرات در etcd ثبت می‌شود.
• حذف منابع: اگر یک Pod حذف شود یا یک سرویس از بین برود، اطلاعات مربوط به این حذف در etcd به‌روزرسانی خواهد شد.

نحوه استفاده از اطلاعات ذخیره‌شده در etcd

• API Server: API Server در Kubernetes همواره از etcd برای دریافت و به‌روزرسانی وضعیت منابع استفاده می‌کند. به‌عنوان مثال، زمانی که Controller Manager نیاز دارد که Pods جدیدی ایجاد کند یا یک Deployment را به‌روز کند، API Server از etcd برای بازیابی اطلاعات قبلی و ذخیره اطلاعات جدید استفاده می‌کند.
• Scheduler: Scheduler نیز برای تخصیص Pods به نودهای خاص در کلاستر از اطلاعات ذخیره‌شده در etcd استفاده می‌کند. این اطلاعات شامل وضعیت نودها، منابع در دسترس و نیازهای Pods می‌شود.
• Controller Manager: Controller Manager برای انجام عملیات خود، نظیر مقیاس‌پذیری Pods، پایش وضعیت منابع و اصلاح انحرافات در وضعیت، به اطلاعات ذخیره‌شده در etcd دسترسی پیدا می‌کند.

مثالی از نحوه ذخیره‌سازی اطلاعات در etcd

برای مثال، فرض کنید یک Pod جدید در کلاستر ایجاد می‌شود. در این شرایط، اطلاعات مربوط به Pod جدید به‌صورت زیر در etcd ذخیره خواهد شد:

• کلید: /pods/default/my-pod
• مقدار: وضعیت کامل Pod شامل تنظیمات، وضعیت فعلی و اطلاعات مرتبط با آن.

به همین شکل، اگر تغییرات جدیدی در وضعیت Pod ایجاد شود، etcd آن تغییرات را در همان کلید مربوطه به‌روز می‌کند. این کلید در هر لحظه نمایانگر وضعیت به‌روز و دقیق Pod است.

مزایای ذخیره‌سازی وضعیت در etcd

1. یکپارچگی داده‌ها: etcd به‌طور مداوم وضعیت منابع کلاستر را همگام‌سازی کرده و به‌روز نگه می‌دارد، که باعث یکپارچگی اطلاعات در تمامی نودهای کلاستر می‌شود.
2. توانایی بازیابی: در صورت بروز خطا یا خرابی، etcd این امکان را فراهم می‌آورد که وضعیت قبلی منابع را بازیابی کرده و کلاستر را به حالت پایدار بازگرداند.
3. پایداری و تحمل خطا: با استفاده از الگوریتم Raft و ویژگی‌های اجماع توزیع‌شده، etcd قادر است در برابر خطاها و خرابی‌ها تاب‌آوری نشان دهد و داده‌ها را با صحت و دقت در اختیار کلاستر قرار دهد.
4. مدیریت ساده: استفاده از etcd به‌عنوان یک سیستم ذخیره‌سازی مرکزی برای وضعیت منابع باعث می‌شود که مدیریت کلاستر ساده‌تر و عملیات‌های هماهنگی راحت‌تر انجام شوند.

جمع‌بندی

etcd پایگاه داده توزیع‌شده‌ای است که در Kubernetes به‌عنوان ذخیره‌ساز وضعیت کلاستر و منابع آن عمل می‌کند. این پایگاه داده با استفاده از الگوریتم Raft و قابلیت‌های همگام‌سازی، مقیاس‌پذیری و تحمل خطا، نقش حیاتی در هماهنگی و مدیریت داده‌ها در کلاستر ایفا می‌کند. تمامی تنظیمات و وضعیت منابع در etcd ذخیره می‌شود و از این رو، این پایگاه داده بخش بسیار مهمی از معماری Kubernetes محسوب می‌شود.

مدیریت کنترلرها برای اجرای منابع Kubernetes

کنترلرها در Kubernetes مجموعه‌ای از الگوریتم‌ها و عملیات‌هایی هستند که برای حفظ وضعیت مطلوب منابع طراحی شده‌اند. این منابع می‌توانند شامل Pods، Deployments، ReplicaSets و موارد مشابه باشند. Controller Manager به‌طور خودکار و مداوم وظیفه نظارت و اصلاح وضعیت این منابع را انجام می‌دهد تا وضعیت فعلی آن‌ها مطابق با وضعیت مطلوب و تعریف‌شده در فایل‌های پیکربندی باشد.

انواع کنترلرها در Kubernetes

1. ReplicaSet Controller:
   • ReplicaSet برای اطمینان از این‌که همیشه تعداد مشخصی از Pods در کلاستر در حال اجرا هستند، طراحی شده است. اگر یک Pod به هر دلیلی از کار بیفتد، ReplicaSet Controller مسئول ایجاد Pod جدیدی برای جایگزینی آن است.
   • وظیفه: حفظ تعداد مشخصی از Pods در هر زمان.
2. Deployment Controller:
   • Deployment به‌طور خودکار تعداد Pods را مدیریت کرده و نسخه‌های جدیدی از Pods را بدون وقفه و قطعی، در کلاستر به‌روز می‌کند. این کنترلر مسئول پیاده‌سازی Rolling Update ها است.
   • وظیفه: انجام به‌روزرسانی‌های مداوم در Pods و مدیریت مقیاس‌پذیری آن‌ها.
3. Node Controller:
   • Node Controller مسئول نظارت بر وضعیت نودهای کلاستر است و در صورتی که نودی از کلاستر حذف شود یا از دسترس خارج گردد، اقداماتی برای بازیابی آن انجام می‌دهد.
   • وظیفه: نظارت بر سلامت نودها و اطمینان از در دسترس بودن منابع.
4. Job Controller:
   • Job Controller وظیفه اجرای Jobs در کلاستر را بر عهده دارد. این کنترلر اطمینان می‌دهد که تعداد مشخصی از Taskها (وظایف) به‌طور کامل اجرا شوند.
   • وظیفه: مدیریت اجرای وظایف یک‌باره و اطمینان از تکمیل آن‌ها.
5. CronJob Controller:
   • مشابه با Job Controller، اما CronJob برای انجام وظایف زمان‌بندی‌شده به‌کار می‌رود. این کنترلر وظیفه اجرای تسک‌ها را بر اساس یک زمان‌بندی ثابت بر عهده دارد.
   • وظیفه: مدیریت وظایف زمان‌بندی‌شده و اجرای آن‌ها در زمان‌های مشخص.
6. Endpoint Controller:
   • Endpoint Controller مسئول نگهداری و به‌روزرسانی اطلاعات مربوط به نقاط پایان (EndPoints) سرویس‌ها است. این کنترلر برای مدیریت مقیاس‌دهی و به‌روزرسانی سرویس‌ها به کار می‌رود.
   • وظیفه: مدیریت نقاط پایان سرویس‌ها و اطمینان از اتصال درست آن‌ها به Pods و سایر منابع.

عملکرد کلی Controller Manager

Controller Manager در حقیقت به‌عنوان یک فرآیند پس‌زمینه در کلاستر Kubernetes اجرا می‌شود که به‌طور مداوم وضعیت کلاستر و منابع آن را بررسی می‌کند. این بررسی‌ها معمولاً شامل موارد زیر است:

1. مقایسه وضعیت واقعی با وضعیت مطلوب:
   • Controller Manager به‌طور مداوم وضعیت منابع را با وضعیت مطلوب مقایسه می‌کند. به‌عنوان مثال، اگر تعداد Pods در یک ReplicaSet کمتر از مقدار تعیین‌شده باشد، کنترلر آن را اصلاح می‌کند.
2. اجرای اقدامات اصلاحی:
   • در صورتی که وضعیت واقعی با وضعیت مطلوب تطابق نداشته باشد، کنترلرها اقداماتی را برای اصلاح آن انجام می‌دهند. این اقدامات می‌توانند شامل ایجاد منابع جدید، حذف منابع اضافی یا انجام به‌روزرسانی‌ها باشند.
3. پشتیبانی از افزونگی:
   • بسیاری از کنترلرها به‌صورت خودکار از افزونگی و مقیاس‌پذیری در کلاستر پشتیبانی می‌کنند. به‌عنوان مثال، اگر یک Pod خراب شود، ReplicaSet Controller به‌طور خودکار آن را بازسازی می‌کند.
4. نظارت بر منابع کلاستر:
   • Controller Manager علاوه بر مدیریت منابع، بر وضعیت کلی کلاستر نیز نظارت دارد تا در صورت بروز هرگونه مشکل (مانند خراب شدن نودها)، به‌سرعت اقدامات اصلاحی انجام شود.

ارتباط Controller Manager با اجزای دیگر Kubernetes

• API Server: Controller Manager به‌طور مداوم از API Server برای دسترسی به وضعیت منابع کلاستر استفاده می‌کند. از آنجا که API Server به‌عنوان نقطه مرکزی ارتباط بین اجزای مختلف کلاستر عمل می‌کند، Controller Manager از آن برای دریافت اطلاعات و به‌روزرسانی وضعیت منابع بهره می‌برد.
• etcd: اطلاعات ذخیره‌شده در etcd وضعیت فعلی منابع را به‌صورت پایدار نگه‌می‌دارد. Controller Manager از این اطلاعات برای اصلاح و به‌روزرسانی منابع در کلاستر استفاده می‌کند.
• Scheduler: Scheduler وظیفه تخصیص Pods به نودها را بر عهده دارد. Controller Manager ممکن است از Scheduler برای تخصیص Pods به نودهای خاص بر اساس نیازهای منابع استفاده کند.

مزایای استفاده از Controller Manager در Kubernetes

1. اتوماتیک کردن عملیات‌ها: Controller Manager تمامی عملیات‌های اصلاحی را به‌صورت خودکار انجام می‌دهد، که باعث کاهش نیاز به مداخله دستی و افزایش کارایی در مدیریت منابع می‌شود.
2. مقیاس‌پذیری و افزونگی: به دلیل ویژگی‌های کنترل‌کننده‌ها برای ایجاد منابع جدید به‌طور خودکار و حذف منابع خراب، کلاستر همیشه در وضعیت بهینه قرار دارد.
3. پایداری: استفاده از کنترلرها کمک می‌کند که در صورت بروز مشکلات یا خرابی‌ها، وضعیت منابع به‌طور سریع و بدون قطعی به حالت پایدار بازگردد.
4. ساده‌سازی مدیریت منابع: Controller Manager به‌طور مداوم منابع کلاستر را مدیریت می‌کند و کاربران فقط باید وضعیت مطلوب منابع را تعریف کنند.

جمع‌بندی

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

وظیفه Scheduler

وظیفه اصلی Scheduler در Kubernetes، تخصیص Pods به نودهای مناسب کلاستر با توجه به منابع و شرایط مختلف است. این کار با استفاده از الگوریتم‌های خاصی انجام می‌شود که مطمئن می‌شوند Pods در نودهای مناسب قرار می‌گیرند تا هم منابع بهینه استفاده شوند و هم عملکرد کلی کلاستر حفظ گردد.

چگونگی عملکرد Scheduler

زمانی که یک Pod جدید ایجاد می‌شود، این Pod در وضعیت “Pending” قرار می‌گیرد و تا زمانی که به نود مناسبی اختصاص نیابد، در همین وضعیت باقی می‌ماند. در این مرحله، Scheduler مسئول تصمیم‌گیری است که این Pod به کدام نود تخصیص یابد. برای انجام این کار، Scheduler به فاکتورهای مختلفی توجه می‌کند:

1. منابع موجود در نودها:
   • Scheduler ابتدا میزان CPU، RAM و دیگر منابع موجود در نودها را بررسی می‌کند تا نودی که منابع کافی برای اجرای Pod را دارد، شناسایی کند.
   • اگر نودی نتواند منابع کافی را برای Pod تأمین کند، Scheduler آن Pod را به نود دیگری تخصیص می‌دهد.
2. برچسب‌ها (Labels) و انتخاب‌ها (Selectors):
   • Kubernetes به نودها و Pods برچسب‌هایی را اختصاص می‌دهد که به Scheduler کمک می‌کند تا Pod را به نودی با ویژگی‌های خاص مانند نوع سخت‌افزار، نسخه سیستم‌عامل، یا محیطی که در آن اجرا می‌شود، تخصیص دهد.
   • برچسب‌ها و انتخاب‌ها به Scheduler کمک می‌کنند تا تصمیمات دقیق‌تری بگیرد.
3. Constraints یا محدودیت‌ها:
   • ممکن است محدودیت‌های خاصی برای تخصیص Pods به نودها وجود داشته باشد، مانند محدودیت در تخصیص منابع، مجوزهای امنیتی یا شرایط ویژه (مثل نیازی به اتصال به یک سرویس خاص).
   • Scheduler این محدودیت‌ها را در نظر می‌گیرد و Pods را به نودهایی تخصیص می‌دهد که این محدودیت‌ها را برآورده کنند.
4. Affinity و Anti-affinity:
   • Node Affinity به Scheduler می‌گوید که Pod باید روی نودی با ویژگی‌های خاص قرار گیرد.
   • Pod Affinity یا Anti-Affinity این امکان را به Scheduler می‌دهد که Pods را بر اساس نزدیکی به Pods دیگر تخصیص دهد. این ویژگی‌ها برای بهینه‌سازی مکانیزم‌های مقیاس‌پذیری و بهبود عملکرد مفید هستند.
5. Taints و Tolerations:
   • Scheduler از مفهوم Taints و Tolerations برای جلوگیری از تخصیص Pods به نودهایی که دارای مشکلات خاص هستند استفاده می‌کند. اگر یک نود “taint” شود، فقط Pods با toleration مرتبط می‌توانند روی آن اجرا شوند.
   • این مکانیزم برای مدیریت نودهایی که نیاز به نگهداری دارند یا در شرایط خاص قرار دارند، مفید است.

مراحل تخصیص منابع توسط Scheduler

1. جستجو برای نود مناسب:
   • Scheduler تمامی نودهای موجود در کلاستر را بررسی می‌کند تا نودی که ظرفیت کافی برای اجرای Pod را داشته باشد، شناسایی کند.
2. اعمال محدودیت‌ها و انتخاب‌ها:
   • با استفاده از برچسب‌ها، انتخاب‌ها، محدودیت‌ها، و قوانین مختلف (مثل Affinity و Anti-affinity)، تصمیم‌گیری برای تخصیص Pod دقیق‌تر می‌شود.
3. انتخاب نود بهینه:
   • Scheduler نودی را که بهترین منابع، امنیت، و شرایط را برای اجرای Pod فراهم می‌کند، انتخاب می‌کند.
4. قرار دادن Pod روی نود:
   • پس از شناسایی نود مناسب، Pod به این نود اختصاص می‌یابد و این نود مسئول اجرای آن می‌شود.

معیارهای انتخاب نود مناسب برای اجرای یک Pod

در Kubernetes، فرآیند انتخاب نود برای اجرای یک Pod توسط Scheduler انجام می‌شود. این فرآیند یکی از جنبه‌های حیاتی در بهینه‌سازی عملکرد و تخصیص منابع به حساب می‌آید. Scheduler برای تخصیص Pods به نودها، معیارهای مختلفی را بررسی می‌کند تا مطمئن شود که Pod به نودی اختصاص یابد که منابع کافی و شرایط مناسب را برای اجرای آن فراهم می‌کند.

در اینجا به توضیح برخی از معیارهای اصلی انتخاب نود مناسب برای اجرای Pod پرداخته شده است:

1. منابع موجود (CPU، Memory)

• Kubernetes به منابع موجود در نودها توجه زیادی دارد. Scheduler ابتدا میزان CPU و Memory (حافظه) هر نود را بررسی می‌کند و مطمئن می‌شود که نود انتخاب شده می‌تواند منابع لازم برای اجرای Pod را فراهم کند.
• اگر Pod درخواست منابع بیشتری از آنچه که نود در دسترس دارد داشته باشد، آن نود به عنوان گزینه انتخاب نمی‌شود.
• از آنجا که Pods می‌توانند درخواست منابع خاصی مانند CPU و حافظه را داشته باشند، Scheduler منابع موجود در نودها را بر اساس این درخواست‌ها و محدودیت‌های مشخص شده (مانند Resource Requests و Limits) مقایسه می‌کند.

2. برچسب‌ها (Labels) و انتخاب‌ها (Selectors)

• Kubernetes به نودها و Pods برچسب‌هایی (labels) اختصاص می‌دهد که به Scheduler کمک می‌کند تا Pods را به نودهایی با ویژگی‌های خاص اختصاص دهد.
• برای مثال، یک نود ممکن است برچسبی مانند zone=us-east داشته باشد. در این صورت، Scheduler می‌تواند از Node Selector برای تخصیص Pods به نودهایی با این برچسب خاص استفاده کند.
• Scheduler همچنین می‌تواند از Node Affinity برای تعیین نودهای مورد نظر بر اساس ویژگی‌های مختلف (مانند مکان جغرافیایی یا نوع سخت‌افزار) استفاده کند.

3. Affinity و Anti-affinity

• Node Affinity: این ویژگی به Scheduler می‌گوید که Pod باید روی نودی با ویژگی‌های خاص قرار گیرد. برای مثال، Pod ممکن است نیاز داشته باشد که فقط روی نودی با پردازنده خاص یا در یک منطقه خاص اجرا شود.
• Pod Affinity و Anti-affinity: این ویژگی‌ها به Scheduler اجازه می‌دهند که Pods را بر اساس نزدیک بودن یا دور بودن از Pods دیگر تخصیص دهد. این ویژگی برای مدیریت عملکرد و مقیاس‌پذیری کاربرد دارد.
  • Pod Affinity: به Scheduler می‌گوید که Pod باید در نزدیکی Pods خاصی قرار گیرد.
  • Pod Anti-affinity: به Scheduler می‌گوید که Pod باید از Pods خاصی فاصله داشته باشد (مثلاً برای جلوگیری از شلوغ شدن یک نود خاص).

4. Taints و Tolerations

• Taints در نودها باعث می‌شود که Pods به طور پیش‌فرض نتوانند به آن نودها تخصیص یابند، مگر اینکه Pod دارای Tolerations مناسب باشد.
• برای مثال، یک نود می‌تواند taint شود به این صورت که:

  kubectl taint nodes <node-name> key=value:NoSchedule
  

  این به این معنی است که Pods نمی‌توانند روی این نود اجرا شوند مگر اینکه toleration خاصی برای این taint داشته باشند.

  Tolerations به Pods اجازه می‌دهد که این محدودیت‌ها را رد کنند و روی نودهای tainted قرار گیرند.

5. وضعیت سلامت نود (Node Health)

• Scheduler به وضعیت سلامت نودها توجه دارد. اگر نودی غیرقابل دسترسی یا مشکل‌دار باشد، Scheduler آن را به عنوان یک گزینه برای تخصیص Pod در نظر نخواهد گرفت.
• این ویژگی معمولاً با استفاده از Liveness Probes و Readiness Probes برای بررسی وضعیت سلامت نود و Pods فعال می‌شود. اگر نودی با مشکل مواجه شود، Scheduler تلاش خواهد کرد تا Pods را به نود دیگری منتقل کند.

6. حجم ذخیره‌سازی (Storage)

• یکی دیگر از معیارهای مهم در انتخاب نود، نیاز به حجم ذخیره‌سازی است. اگر Pod نیاز به ذخیره‌سازی دائم یا خاصی داشته باشد، Scheduler باید نودهایی را که قابلیت دسترسی به منابع ذخیره‌سازی لازم را دارند، شناسایی کند.
• برای مثال، اگر Pod به یک PersistentVolumeClaim (PVC) خاص نیاز داشته باشد، Scheduler نودهایی را که با این حجم سازگار هستند انتخاب می‌کند.

7. مجوزهای امنیتی (Security Policies)

• Scheduler همچنین باید از نظر امنیتی نودها را بررسی کند. به این معنا که اگر Pod نیاز به ویژگی‌های امنیتی خاصی مانند SecurityContext یا PodSecurityPolicy داشته باشد، Scheduler نودهایی که این سیاست‌ها را پشتیبانی می‌کنند، انتخاب می‌کند.

8. تنظیمات شبکه (Network Configurations)

• Pods ممکن است به ویژگی‌های خاص شبکه نیاز داشته باشند. به عنوان مثال، Pod ممکن است نیاز به اتصال به یک شبکه خاص یا استفاده از یک Network Policy داشته باشد. Scheduler باید نودهایی را که این ویژگی‌ها را دارند انتخاب کند.
• نودهایی که به شبکه خاصی متصل هستند یا نیاز به مدیریت ترافیک از طریق Kube-proxy دارند، ممکن است انتخاب شوند.

جمع بندی

Scheduler در کوبرنتیز نقش حیاتی در تخصیص منابع به Pods ایفا می‌کند. وظیفه اصلی این کنترلر، یافتن نود مناسب برای اجرای Pods است تا منابع بهینه‌ استفاده شوند و کلاستر عملکرد مطلوبی داشته باشد. با در نظر گرفتن عواملی مانند منابع موجود، برچسب‌ها، محدودیت‌ها، Affinity/Anti-affinity و Taints/Tolerations، Scheduler تصمیم می‌گیرد که هر Pod روی کدام نود قرار گیرد. این فرآیند، یکی از ارکان اساسی در مدیریت کارآمد کلاستر و مقیاس‌پذیری آن است.

مسئول اجرای کانتینرها روی Worker Node

Kubelet یکی از اجزای کلیدی در Kubernetes است که مسئول اجرای کانتینرها روی Worker Node است. این سرویس با نظارت و مدیریت فرآیندهای مربوط به Pods و کانتینرها بر روی هر نود، نقش حیاتی در عملکرد صحیح کلاستر ایفا می‌کند.

• عملکرد اصلی Kubelet این است که اطمینان حاصل کند که کانتینرهای مورد نظر در هر Pod در وضعیت سالم و در حال اجرا هستند. Kubelet به محض دریافت دستور برای اجرای یک Pod، آن را روی نود خود راه‌اندازی می‌کند و کانتینرهای داخل آن را در وضعیت مطلوب اجرا می‌سازد.
• Kubelet از فایل‌های پیکربندی مانند YAML برای تنظیم و مدیریت Pods استفاده می‌کند. زمانی که یک Pod از طریق API Server به نودها تخصیص می‌یابد، Kubelet مسئول استارت کردن کانتینرها طبق مشخصات موجود در فایل‌های پیکربندی است.
• Kubelet به صورت مداوم وضعیت کانتینرها را بررسی می‌کند و اطمینان حاصل می‌کند که اگر کانتینری متوقف یا با خطا مواجه شود، آن را مجدداً راه‌اندازی می‌کند. این عمل به طور خودکار انجام می‌شود و از نودهای Worker در برابر خطاهای ناشی از کانتینرها محافظت می‌کند.
• به طور کلی، Kubelet نقش هماهنگ‌کننده‌ای در مدیریت کانتینرها در Worker Node دارد و به مستندات کلاستر Kubernetes کمک می‌کند تا همواره عملکرد بهینه داشته باشد.

بررسی سلامت Pods و گزارش‌دهی به Master Node

یکی از وظایف دیگر Kubelet نظارت و بررسی سلامت Pods است. Kubelet با استفاده از Readiness Probes و Liveness Probes از صحت عملکرد کانتینرها و Pods اطمینان حاصل می‌کند.

• Liveness Probe: این بررسی به Kubelet کمک می‌کند تا تشخیص دهد که آیا یک کانتینر زنده است یا نه. اگر Liveness Probe نشان دهد که کانتینر مرده است، Kubelet مسئولیت راه‌اندازی مجدد آن کانتینر را بر عهده دارد.
• Readiness Probe: این ابزار به Kubelet می‌گوید که آیا کانتینر آماده دریافت ترافیک است یا نه. این پروب اطمینان می‌دهد که زمانی که یک کانتینر به طور کامل راه‌اندازی نشده است، هیچ ترافیکی به آن ارسال نمی‌شود.
• پس از انجام این بررسی‌ها، Kubelet وضعیت سلامت Pods را به Master Node گزارش می‌دهد. این اطلاعات از طریق API Server به Controller Manager ارسال می‌شود تا وضعیت کلی سیستم مدیریت و نظارت شود.
• اگر مشکلی در سلامت Podها شناسایی شود، Kubelet به صورت خودکار اقدام به بازنشانی یا حذف کانتینرهایی می‌کند که مشکل دارند. در صورتی که Pod نتواند به درستی عمل کند، اطلاعات مربوط به آن به Master Node ارسال شده و اقداماتی مانند Pod Rescheduling به نودهای دیگر انجام می‌شود.

در مجموع، Kubelet نقش کلیدی در حفظ سلامت و کارکرد Pods در Kubernetes دارد و از طریق بررسی مداوم وضعیت کانتینرها، به رفع مشکلات و جلوگیری از بروز مشکلات در سطح کلاستر کمک می‌کند.

• Kube-proxy هر نود را برای مدیریت ترافیک شبکه‌ای در سطح کلاستر پیکربندی می‌کند. این ابزار از سه روش مختلف برای برقراری ارتباط میان Pods و Nodeها استفاده می‌کند:
  • iptables: که قوانین فایروال برای ارسال درخواست‌ها به مقصد مناسب را تنظیم می‌کند.
  • ipvs: که بهبود عملکرد ارسال ترافیک را فراهم می‌آورد.
  • userspace proxying: در حال حاضر از آن کمتر استفاده می‌شود.
• Kube-proxy به هر Pod یک IP یکتا تخصیص می‌دهد که به کمک آن Pods قادر به ارتباط با یکدیگر و همچنین ارتباط با منابع خارج از کلاستر می‌باشند.
• این پروکسی برای هر Service یک آدرس IP مشخص در سطح کلاستر ایجاد می‌کند و ترافیک ارسالی به این IP را به Pods مرتبط با آن Service می‌فرستد. به عبارت دیگر، Kube-proxy مسیریابی ترافیک به Pods را از طریق IP ثابت سرویس‌ها امکان‌پذیر می‌سازد.
• Kube-proxy مسئول به‌روزرسانی و نگهداری قوانین مسیریابی در هنگام ایجاد یا حذف Pods است. زمانی که Pods جدیدی اضافه می‌شوند یا حذف می‌شوند، Kube-proxy قوانین مسیریابی را به‌روزرسانی می‌کند تا اطمینان حاصل شود که ترافیک به مقصد صحیح هدایت می‌شود.

نقش در Forwarding و Load Balancing ترافیک

Kube-proxy نقش اساسی در load balancing و forwarding ترافیک شبکه در کلاستر Kubernetes ایفا می‌کند.

• Load balancing: زمانی که یک Service در Kubernetes درخواست‌هایی از کاربران دریافت می‌کند، Kube-proxy مسئول توزیع ترافیک بین Pods مختلف است که آن Service را پیاده‌سازی کرده‌اند. این فرآیند به صورت تصادفی (Round Robin) یا مبتنی بر وضعیت Pods انجام می‌شود. در صورتی که Podهایی با وضعیت غیرقابل استفاده یا crash شده وجود داشته باشند، Kube-proxy فقط ترافیک را به Pods سالم ارسال می‌کند.
• Forwarding: Kube-proxy درخواست‌ها را از Service IP به Pod IP ارسال می‌کند. این فرآیند در سطح نود توسط iptables یا ipvs انجام می‌شود. درخواست‌هایی که به سرویس ارسال می‌شوند به طور مستقیم به یکی از Pods موجود در نود هدایت می‌شود. این پروسه به Kubernetes اجازه می‌دهد که بدون نیاز به درک پیچیدگی‌های داخلی شبکه، ترافیک را به طور خودکار به مقصد صحیح هدایت کند.

در صورتی که یک Pod در حال انجام عملیات خاصی باشد یا ترافیک زیادی دریافت کند، Kube-proxy به صورت خودکار بار را بین Pods متوازن می‌کند و اطمینان می‌دهد که هیچ Pod یا نودی تحت فشار بیش از حد قرار نگیرد.

در نهایت، Kube-proxy نقشی اساسی در مدیریت و هدایت ترافیک در کلاستر Kubernetes ایفا می‌کند و با forwarding و load balancing مؤثر، عملکرد و مقیاس‌پذیری کلاستر را بهبود می‌بخشد.

Namespace‌ها به ویژه در محیط‌های چند کاربری یا در کلاسترهای بزرگ که منابع زیادی دارند، مفید هستند. آن‌ها به این امکان می‌دهند که منابع یک محیط خاص، مانند یک اپلیکیشن یا تیم، از سایر منابع جدا شوند، بدون اینکه به دیگر منابع در کلاستر آسیبی وارد شود.

به طور پیش‌فرض، Kubernetes یک Namespace اصلی به نام default دارد. به علاوه، برای اهداف خاص مانند سیستم یا کنترل، Namespaceهای دیگری نظیر kube-system، kube-public نیز وجود دارند.

برای ایجاد و استفاده از Namespaceها در Kubernetes، باید از دستورات kubectl و فایل‌های YAML برای پیکربندی استفاده کنیم.

ایجاد یک Namespace

برای ایجاد یک Namespace جدید در Kubernetes، می‌توانید از دستور kubectl create namespace استفاده کنید:

kubectl create namespace my-namespace

این دستور یک Namespace به نام my-namespace ایجاد می‌کند.

مشاهده Namespaceها

برای مشاهده تمامی Namespaceها در کلاستر، از دستور زیر استفاده می‌کنید:

kubectl get namespaces

استفاده از Namespace در منابع

برای تعیین یک Namespace خاص در هنگام ایجاد منابع مختلف (مثل Pods یا Services)، می‌توانید آن را در فایل YAML منابع خود مشخص کنید یا از گزینه --namespace در دستور kubectl استفاده کنید.

برای مثال، برای ایجاد یک Pod در یک Namespace خاص، می‌توانید از دستور زیر استفاده کنید:

kubectl run mypod --image=nginx --namespace=my-namespace

یا در فایل YAML، به این صورت:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: my-namespace
spec:
  containers:
  - name: nginx
    image: nginx

تغییر Namespace فعلی

برای تغییر Namespace پیش‌فرض در دستورات kubectl، می‌توانید از دستور kubectl config set-context استفاده کنید تا Namespace پیش‌فرض را برای محیط کاری تنظیم کنید:

kubectl config set-context --current --namespace=my-namespace

پس از انجام این کار، تمام دستورات kubectl به صورت پیش‌فرض در my-namespace اجرا خواهند شد، مگر اینکه به طور خاص Namespace دیگری را مشخص کنید.

حذف یک Namespace

برای حذف یک Namespace و تمامی منابع آن، از دستور زیر استفاده کنید:

kubectl delete namespace my-namespace

جمع بندی

Namespace در Kubernetes یک ابزار قدرتمند برای مدیریت منابع است که امکان جداسازی و مدیریت منابع را در سطح کلاستر فراهم می‌کند. استفاده از Namespace باعث می‌شود که منابع به طور مؤثرتر و مقیاس‌پذیرتر در کلاستر مدیریت شوند، به ویژه در محیط‌های چند کاربری یا کلاسترهای بزرگ.

1. مدیریت منابع به‌طور مؤثرتر

یکی از مزایای اصلی استفاده از Namespaces، مدیریت مؤثرتر منابع در Kubernetes است. در یک کلاستر بزرگ که تیم‌ها یا اپلیکیشن‌های مختلف در حال استفاده از منابع هستند، Namespaces به شما امکان می‌دهد که منابع هر اپلیکیشن یا تیم را به‌طور جداگانه و بدون تداخل مدیریت کنید.

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

2. جداسازی و محدود کردن دسترسی

Namespaces به شما این امکان را می‌دهند که منابع و سرویس‌ها را از یکدیگر جدا کنید. این جدا‌سازی می‌تواند از منظر امنیتی و مدیریتی مهم باشد، به‌ویژه در محیط‌های چند کاربری. برای مثال، می‌توانید محدودیت‌هایی برای دسترسی به منابع بین Namespaces مختلف ایجاد کنید. این ویژگی باعث می‌شود که تیم‌ها یا اپلیکیشن‌ها تنها به منابع مخصوص به خود دسترسی داشته باشند و از تغییرات غیرمجاز در سایر منابع جلوگیری شود.

3. مدیریت منابع تخصیص یافته

Kubernetes به شما این امکان را می‌دهد که از Resource Quotas برای تخصیص منابع خاص به Namespaces استفاده کنید. با این ویژگی، می‌توانید برای هر Namespace میزان مشخصی از منابع (مثل CPU و حافظه) اختصاص دهید. این باعث می‌شود که هر تیم یا اپلیکیشن تنها از منابع تخصیص یافته به خود استفاده کند و به منابع سایر تیم‌ها دسترسی نداشته باشد. این ویژگی به‌ویژه در محیط‌های پرکاربرد مفید است.

برای مثال، می‌توانید یک ResourceQuota برای یک Namespace به‌صورت زیر تعریف کنید:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
  namespace: my-namespace
spec:
  hard:
    cpu: "4"
    memory: 8Gi
    pods: "10"

4. ساده‌سازی توسعه و تست

در محیط‌های توسعه و تست، استفاده از Namespaces باعث می‌شود که بتوانید نسخه‌های مختلف یک اپلیکیشن را به‌طور جداگانه در یک کلاستر مستقر کنید. هر تیم می‌تواند Namespace خاص خود را داشته باشد که منابع و تنظیمات مخصوص به خود را دارد، بنابراین هیچ‌گونه تداخلی در منابع نخواهد بود.

این ویژگی به‌ویژه زمانی مفید است که تیم‌ها بخواهند در یک کلاستر مشترک کار کنند، اما نیاز به جداسازی محیط‌های مختلف برای توسعه، تست، و تولید داشته باشند.

5. مقیاس‌پذیری و انعطاف‌پذیری

استفاده از Namespaces به شما امکان می‌دهد که منابع را در مقیاس بزرگ‌تری مدیریت کنید. هر Namespace می‌تواند منابع متفاوتی را در خود جای دهد و به این ترتیب می‌توانید تعداد زیادی از اپلیکیشن‌ها یا پروژه‌ها را در یک کلاستر مدیریت کنید. این امر باعث بهبود مقیاس‌پذیری کلاستر و همچنین افزایش انعطاف‌پذیری در استفاده از منابع می‌شود.

6. پشتیبانی از چندین محیط

در بسیاری از سازمان‌ها، از چندین محیط مانند Development، Staging و Production استفاده می‌شود. با ایجاد Namespaces مختلف برای هر محیط، می‌توانید منابع مربوط به هر محیط را به‌طور جداگانه مدیریت کنید. این کار به کاهش اشتباهات در زمان استقرار و تست کمک می‌کند و باعث می‌شود که منابع محیط‌های مختلف تحت تأثیر تغییرات یکدیگر قرار نگیرند.

7. آسان‌تر شدن مستندسازی و نظارت

زمانی که از Namespaces برای جداسازی منابع استفاده می‌کنید، نظارت و مستندسازی منابع در کلاستر به‌طور قابل‌توجهی ساده‌تر می‌شود. از آنجا که منابع مرتبط به یک Namespace خاص به هم نزدیک‌تر هستند، ابزارهای نظارتی مانند Prometheus یا Grafana می‌توانند آسان‌تر به جمع‌آوری اطلاعات و مانیتورینگ وضعیت منابع بپردازند.

برای مثال، می‌توانید از kubectl برای مشاهده وضعیت منابع در یک Namespace خاص استفاده کنید:

kubectl get pods --namespace=my-namespace

جمع بندی

استفاده از Namespaces در Kubernetes، علاوه بر جداسازی منابع، امکانات مختلفی برای مدیریت بهینه و مؤثر منابع فراهم می‌کند. این ویژگی به‌ویژه در محیط‌های چند کاربری یا در کلاسترهایی که منابع زیادی دارند، بسیار مفید است. از جمله مزایای اصلی Namespaces می‌توان به مدیریت منابع تخصیص یافته، محدودیت دسترسی، مقیاس‌پذیری بهتر، و تسهیل در توسعه و تست اشاره کرد.

1. مشاهده Namespaces موجود در کلاستر

برای مشاهده Namespaces موجود در کلاستر، از دستور زیر استفاده می‌شود:

kubectl get namespaces

این دستور لیستی از تمامی Namespaces موجود در کلاستر را نمایش می‌دهد.

2. ایجاد یک Namespace جدید

برای ایجاد یک Namespace جدید، می‌توانید از دستور زیر استفاده کنید:

kubectl create namespace <namespace-name>

در این دستور، <namespace-name> نام Namespace جدیدی است که قصد دارید ایجاد کنید. برای مثال، برای ایجاد یک Namespace به نام dev، از دستور زیر استفاده می‌شود:

kubectl create namespace dev

3. مشاهده منابع در یک Namespace خاص

اگر می‌خواهید منابع داخل یک Namespace خاص را مشاهده کنید، از دستور زیر استفاده کنید:

kubectl get <resource-type> --namespace=<namespace-name>

به‌طور مثال، برای مشاهده تمامی Pods در Namespace dev، دستور زیر را اجرا می‌کنید:

kubectl get pods --namespace=dev

4. تغییر Namespace پیش‌فرض برای دستورات

برای تعیین Namespace پیش‌فرض به‌طور موقت، می‌توانید از دستور زیر استفاده کنید:

kubectl config set-context --current --namespace=<namespace-name>

برای مثال، برای تنظیم Namespace پیش‌فرض به dev، از دستور زیر استفاده کنید:

kubectl config set-context --current --namespace=dev

این دستور باعث می‌شود تا دیگر نیاز نباشد برای هر دستور، Namespace را مشخص کنید و تمامی دستورات به‌طور پیش‌فرض در Namespace تعیین‌شده اجرا شوند.

5. حذف یک Namespace

برای حذف یک Namespace و تمامی منابع موجود در آن، از دستور زیر استفاده کنید:

kubectl delete namespace <namespace-name>

در اینجا، <namespace-name> نام Namespace موردنظر است. برای حذف Namespace به نام dev، از دستور زیر استفاده می‌شود:

kubectl delete namespace dev

6. مشاهده جزئیات یک Namespace

برای مشاهده جزئیات یک Namespace خاص، می‌توانید از دستور زیر استفاده کنید:

kubectl describe namespace <namespace-name>

به‌طور مثال، برای مشاهده جزئیات Namespace dev، دستور زیر را اجرا کنید:

kubectl describe namespace dev

7. اعمال تغییرات بر روی منابع در Namespace خاص

اگر بخواهید منابع را در یک Namespace خاص ویرایش یا به‌روزرسانی کنید، باید به‌طور صریح Namespace را در دستور وارد کنید. برای مثال، برای اعمال یک Deployment در Namespace dev، دستور زیر را اجرا می‌کنید:

kubectl apply -f deployment.yaml --namespace=dev

در اینجا، deployment.yaml فایل پیکربندی است که منابع را در Namespace dev ایجاد می‌کند.

8. انتقال منابع بین Namespaces

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

جمع بندی

استفاده از دستورات kubectl برای مدیریت Namespaces به شما این امکان را می‌دهد که منابع را به‌طور مؤثر در کلاستر خود سازماندهی کنید. این دستورات شامل ایجاد Namespaces جدید، مشاهده منابع، حذف Namespaces و مدیریت پیش‌فرض Namespace است. استفاده از Namespaces باعث جداسازی منابع و مدیریت بهتر در محیط‌های پیچیده و چند تیمی می‌شود.

نحوه استفاده از دستور kubectl create namespace

فرم کلی دستور به شرح زیر است:

kubectl create namespace <namespace-name>

در اینجا:

• <namespace-name> نام Namespace جدیدی است که قصد دارید ایجاد کنید.

برای مثال، برای ایجاد یک Namespace جدید به نام dev، دستور زیر را وارد کنید:

kubectl create namespace dev

این دستور یک Namespace جدید با نام dev در کلاستر ایجاد می‌کند.

مشاهده Namespace جدید ایجاد شده

پس از ایجاد Namespace، می‌توانید با دستور زیر از وجود آن اطمینان حاصل کنید:

kubectl get namespaces

این دستور لیستی از تمامی Namespaces موجود در کلاستر را نمایش می‌دهد. در این لیست باید Namespace جدید dev را مشاهده کنید.

استفاده از Namespace جدید برای منابع

پس از ایجاد Namespace جدید، می‌توانید منابع مختلف مانند Pods، Deployments، Services و غیره را در آن ایجاد کنید. برای انجام این کار، باید Namespace موردنظر را در دستورات خود مشخص کنید.

برای مثال، برای ایجاد یک Pod در Namespace dev، دستور زیر را وارد کنید:

kubectl run my-pod --image=nginx --namespace=dev

این دستور یک Pod جدید با نام my-pod در Namespace dev ایجاد می‌کند که از تصویر nginx استفاده می‌کند.

جمع بندی

با استفاده از دستور kubectl create namespace، می‌توانید Namespace های جدیدی در کلاستر Kubernetes ایجاد کنید و منابع را به‌طور مؤثر سازماندهی کنید. ایجاد Namespace باعث می‌شود که بتوانید منابع مختلف را در کلاستر جداگانه و به‌صورت منطقی مدیریت کنید.

نحوه استفاده از دستور kubectl delete namespace

فرم کلی دستور به شرح زیر است:

kubectl delete namespace <namespace-name>

در اینجا:

• <namespace-name> نام Namespace ای است که می‌خواهید حذف کنید.

برای مثال، برای حذف Namespace به نام dev، دستور زیر را وارد کنید:

kubectl delete namespace dev

این دستور Namespace dev و تمامی منابعی که در آن وجود دارند (مانند Pods، Deployments، Services و غیره) را حذف می‌کند.

بررسی وضعیت حذف Namespace

برای اطمینان از حذف شدن Namespace، می‌توانید لیست Namespaces موجود را با دستور زیر مشاهده کنید:

kubectl get namespaces

اگر Namespace dev به درستی حذف شده باشد، دیگر در لیست نمایش داده نخواهد شد.

نکات مهم در حذف Namespace

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

جمع بندی

با استفاده از دستور kubectl delete namespace، می‌توانید یک Namespace را از کلاستر Kubernetes حذف کنید. این دستور علاوه بر حذف Namespace، تمامی منابع موجود در آن را نیز از بین می‌برد. بنابراین، مهم است که قبل از حذف یک Namespace، از حذف شدن منابع آن آگاهی داشته باشید.

نحوه استفاده از دستور kubectl get namespaces

فرم کلی دستور به شرح زیر است:

kubectl get namespaces

این دستور لیستی از تمامی Namespaces موجود در کلاستر را نمایش می‌دهد.

مثال اجرای دستور

فرض کنید در کلاستر Kubernetes خود چندین Namespace مانند default، dev، و production دارید. برای مشاهده آن‌ها، دستور زیر را وارد کنید:

kubectl get namespaces

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

NAME              STATUS   AGE
default           Active   12d
dev               Active   5d
production        Active   8d

در این خروجی:

• NAME: نام Namespace ها
• STATUS: وضعیت Namespace ها (مثلاً Active برای Namespace های فعال)
• AGE: مدت زمانی که از ایجاد Namespace گذشته است

مشاهده جزئیات بیشتر از Namespace

برای مشاهده جزئیات بیشتر در مورد یک Namespace خاص، می‌توانید از دستور kubectl describe استفاده کنید. برای مثال، برای مشاهده جزئیات Namespace dev دستور زیر را وارد کنید:

kubectl describe namespace dev

این دستور اطلاعات بیشتری از جمله برچسب‌ها، انوتیشن‌ها و وضعیت کلی Namespace را نمایش می‌دهد.

جمع بندی

با استفاده از دستور kubectl get namespaces می‌توانید تمامی Namespaces موجود در کلاستر خود را مشاهده کنید. این دستور کمک می‌کند تا به‌راحتی از وضعیت و جزئیات Namespace ها باخبر شوید و در صورت نیاز، اقدامات مدیریتی خود را انجام دهید.

مفهوم Context در Kubernetes

یک Context در فایل پیکربندی Kubernetes (معمولاً kubeconfig) شامل موارد زیر است:

• Cluster: نام کلاستری که به آن متصل هستید.
• User: کاربری که از آن برای دسترسی به کلاستر استفاده می‌شود.
• Namespace: نام Namespace ای که به طور پیش‌فرض در آن فعالیت می‌کنید.

تنظیم Context برای یک Namespace خاص

برای تنظیم یک Context که به یک Namespace خاص اشاره دارد، از دستور kubectl config set-context استفاده می‌کنیم. این دستور اجازه می‌دهد که یک Context جدید ایجاد کنید که شامل Namespace مورد نظر شما باشد.

فرم کلی دستور به این صورت است:

kubectl config set-context <context-name> --namespace=<namespace-name>

در اینجا:

• <context-name> نام Context جدیدی است که می‌خواهید ایجاد کنید.
• <namespace-name> نام Namespace ای است که می‌خواهید به آن متصل شوید.

برای مثال، اگر می‌خواهید یک Context به نام dev-context ایجاد کنید که به Namespace dev متصل باشد، از دستور زیر استفاده کنید:

kubectl config set-context dev-context --namespace=dev

تغییر Context فعال به یک Namespace خاص

بعد از ایجاد Context، برای استفاده از آن به عنوان Context فعال، از دستور kubectl config use-context استفاده می‌شود. به این ترتیب، تمام دستورات بعدی شما به طور پیش‌فرض در Namespace ای که در Context مشخص کرده‌اید اجرا خواهند شد.

برای مثال، برای استفاده از Context dev-context به عنوان Context فعال، دستور زیر را وارد کنید:

kubectl config use-context dev-context

مشاهده Contexts موجود

برای مشاهده لیست تمامی Contexts موجود و همچنین Context فعال فعلی، از دستور زیر استفاده کنید:

kubectl config get-contexts

خروجی این دستور به شما لیستی از Contexts موجود را نمایش می‌دهد. در این خروجی، Context فعال با علامت ستاره (*) مشخص می‌شود.

تغییر Namespace در Context فعال

اگر بخواهید Namespace در Context فعال را تغییر دهید، می‌توانید از دستور زیر استفاده کنید:

kubectl config set-context --current --namespace=<new-namespace>

در اینجا:

• --current: به معنای اعمال تغییرات بر روی Context فعال است.
• <new-namespace> نام Namespace جدیدی است که می‌خواهید به آن تغییر دهید.

برای مثال، برای تغییر Namespace به production در Context فعال، دستور زیر را وارد کنید:

kubectl config set-context --current --namespace=production

جمع بندی

با استفاده از Contexts در Kubernetes، می‌توانید به راحتی Namespace های مختلف را مدیریت کرده و از آن‌ها در دستورات kubectl استفاده کنید. این روش به شما این امکان را می‌دهد که به سرعت میان Namespaces مختلف جابجا شوید و از نوشتن دستی نام Namespace در هر دستور جلوگیری کنید. استفاده از Context ها به ویژه در محیط‌های چندکلاستری و پیچیده که نیاز به مدیریت Namespaces مختلف دارند، بسیار مفید و کارآمد است.

یک Pod معمولاً برای اجرا و مدیریت یک یا چند برنامه کاربردی (مثل یک سرویس یا میکروسرویس) طراحی می‌شود و تمامی کانتینرهای موجود در یک Pod با هم به‌صورت نزدیک‌تری همکاری می‌کنند. Podها به‌طور کلی برای مدیریت کانتینرهای مربوط به یک اپلیکیشن در کلاستر استفاده می‌شوند.

در حالی که می‌توانیم کانتینرهای جداگانه‌ای را در Kubernetes ایجاد کنیم، استفاده از Pod به دلیل اشتراک منابع و قابلیت مقیاس‌پذیری بهتری که دارد، روش مطلوب‌تر است. به عنوان مثال، وقتی که دو یا چند کانتینر نیاز به اشتراک‌گذاری منابع یا ارتباط نزدیکی با یکدیگر دارند، می‌توان آن‌ها را در یک Pod قرار داد.

ساختار یک Pod

یک Pod در Kubernetes شامل اجزای زیر است:

• Containers: کانتینرهایی که در Pod اجرا می‌شوند.
• Shared Storage Volumes: فضایی که برای ذخیره داده‌های کانتینرها استفاده می‌شود.
• Networking: یک آدرس IP مشترک برای تمام کانتینرهای داخل Pod.
• Metadata: اطلاعاتی مانند نام Pod، Namespace، برچسب‌ها (labels) و غیره.

ایجاد یک Pod با استفاده از YAML

برای ایجاد یک Pod، می‌توانیم از فایل YAML استفاده کنیم. در اینجا یک نمونه ساده از فایل YAML برای تعریف یک Pod آمده است:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx:latest

در این فایل:

• apiVersion: نسخه API که برای ایجاد Pod استفاده می‌شود.
• kind: نوع منبع که در اینجا “Pod” است.
• metadata: اطلاعات متادیتا شامل نام Pod.
• spec: مشخصات اصلی Pod، که شامل لیست کانتینرها است.

ایجاد Pod از فایل YAML

برای ایجاد Pod از این فایل YAML، ابتدا باید فایل را با نامی مانند pod-example.yaml ذخیره کرده و سپس دستور زیر را اجرا کنید:

kubectl apply -f pod-example.yaml

این دستور Pod را در کلاستر Kubernetes ایجاد می‌کند.

بررسی وضعیت Pod

برای مشاهده وضعیت Pod که ایجاد کرده‌اید، از دستور زیر استفاده می‌کنیم:

kubectl get pods

این دستور لیستی از Podها را نمایش می‌دهد که شامل وضعیت هر یک است. برای دریافت جزئیات بیشتر در مورد یک Pod خاص، می‌توانید از دستور kubectl describe استفاده کنید:

kubectl describe pod example-pod

این دستور اطلاعات دقیق‌تری از Pod مانند وضعیت کانتینرها، رویدادها و پیکربندی‌ها را نمایش می‌دهد.

حذف Pod

برای حذف یک Pod، از دستور زیر استفاده کنید:

kubectl delete pod example-pod

این دستور Pod مشخص شده را از کلاستر حذف می‌کند.

جمع‌بندی

Pod به عنوان کوچک‌ترین واحد قابل مدیریت در Kubernetes، نقش بسیار مهمی در مدیریت و مقیاس‌پذیری کانتینرها ایفا می‌کند. ایجاد Pod با استفاده از فایل‌های YAML و دستورات kubectl بسیار ساده است و می‌تواند پایه‌ای برای مدیریت کانتینرها و منابع در Kubernetes باشد.

در این بخش، شما یاد خواهید گرفت که چگونه یک Pod را با استفاده از فایل YAML تعریف کرده و سپس آن را در کلاستر Kubernetes ایجاد کنید.

ساختار یک فایل YAML برای تعریف Pod

یک فایل YAML برای تعریف Pod باید شامل برخی از اطلاعات اصلی باشد. این اطلاعات عبارتند از:

• apiVersion: نسخه API که باید برای منابع استفاده شود.
• kind: نوع منبع (در اینجا “Pod”).
• metadata: اطلاعات متادیتا مانند نام و برچسب‌های Pod.
• spec: مشخصات Pod که شامل جزئیات کانتینرها، منابع و سایر تنظیمات است.

در اینجا یک مثال ساده از یک فایل YAML برای تعریف یک Pod آورده شده است:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80

در این مثال:

• apiVersion: نسخه‌ای که برای تعریف منابع استفاده می‌شود (در اینجا v1 برای Pod).
• kind: نوع منبع که در اینجا “Pod” است.
• metadata: شامل نام Pod به نام nginx-pod.
• spec: مشخصات Pod که در اینجا شامل یک کانتینر است که تصویر آن از nginx:latest است. همچنین پورت 80 برای ارتباطات درون کانتینر باز شده است.

گام‌های ایجاد Pod با استفاده از فایل YAML

1. ایجاد فایل YAML: ابتدا فایل YAML خود را با استفاده از ویرایشگر متنی دلخواه ایجاد کنید. به عنوان مثال، نام فایل را nginx-pod.yaml قرار دهید.

   nano nginx-pod.yaml
   

   سپس محتویات YAML تعریف شده را داخل این فایل وارد کنید.

2. **اعمال فایل YAML برای ایجاد Pod: پس از ذخیره کردن فایل، از دستور kubectl apply برای ایجاد Pod استفاده کنید. دستور زیر Pod را در کلاستر شما ایجاد می‌کند:

   kubectl apply -f nginx-pod.yaml
   

   این دستور Pod را طبق پیکربندی که در فایل YAML مشخص کرده‌اید، در کلاستر Kubernetes ایجاد می‌کند.

3. **بررسی وضعیت Pod: پس از ایجاد Pod، می‌توانید از دستور زیر برای بررسی وضعیت Pod خود استفاده کنید:

   kubectl get pods
   

   این دستور لیستی از تمامی Podها را به شما نشان می‌دهد و وضعیت هر یک از آن‌ها را نمایش می‌دهد.

   برای مشاهده جزئیات بیشتر در مورد Pod خاص خود، از دستور kubectl describe استفاده کنید:

   kubectl describe pod nginx-pod
   

   این دستور اطلاعات دقیق‌تری مانند وضعیت کانتینرها، پورت‌ها و رویدادهای Pod را ارائه می‌دهد.

4. **حذف Pod: در صورت نیاز به حذف Pod، می‌توانید از دستور زیر استفاده کنید:

   kubectl delete pod nginx-pod
   

   این دستور Pod مشخص شده را از کلاستر Kubernetes حذف می‌کند.

جمع‌بندی

استفاده از فایل‌های YAML برای ایجاد Pod در Kubernetes یک روش ساده و مؤثر برای مدیریت منابع است. شما می‌توانید فایل YAML خود را با تنظیمات دلخواه بنویسید و سپس آن را به کلاستر اعمال کنید. با استفاده از دستورات kubectl می‌توانید وضعیت، جزئیات و حتی حذف Podها را مدیریت کنید.

دستور kubectl get pods

دستور kubectl get pods برای نمایش وضعیت کلی تمامی Podها یا یک Pod خاص در کلاستر Kubernetes استفاده می‌شود. این دستور اطلاعاتی مانند نام Pod، وضعیت آن (Running، Pending، Failed، etc.)، تعداد Replicas و مدت زمان اجرا را نشان می‌دهد.

گام‌ها:

1. مشاهده وضعیت تمامی Podها: برای مشاهده وضعیت تمامی Podها در کلاستر، دستور زیر را وارد کنید:

   kubectl get pods
   

   این دستور لیستی از تمامی Podها و وضعیت آنها را به شما نمایش می‌دهد. به طور پیش‌فرض، خروجی شامل نام Podها، وضعیت، تعداد کانتینرها، مدت زمان فعالیت و سایر جزئیات مربوط به Podها خواهد بود.

   مثال خروجی:

   NAME            READY   STATUS    RESTARTS   AGE
   nginx-pod       1/1     Running   0          5m
   mysql-pod       1/1     Running   0          10m
   

   در اینجا:

   • READY نشان‌دهنده تعداد کانتینرهای آماده برای اجرا در هر Pod است.
   • STATUS وضعیت کلی Pod را نشان می‌دهد (مانند Running, Pending, CrashLoopBackOff).
   • RESTARTS تعداد دفعاتی که کانتینر Pod مورد نظر دوباره راه‌اندازی شده است.
   • AGE مدت زمانی است که Pod در حال اجراست.
2. مشاهده وضعیت یک Pod خاص: اگر بخواهید وضعیت یک Pod خاص را بررسی کنید، کافیست نام آن Pod را به دستور اضافه کنید:

   kubectl get pod nginx-pod
   

   این دستور وضعیت Pod به نام nginx-pod را نمایش می‌دهد.

دستور kubectl describe pod

دستور kubectl describe pod برای مشاهده اطلاعات دقیق‌تر و جزئیات در مورد یک Pod خاص استفاده می‌شود. این دستور اطلاعات بیشتری در مورد وضعیت Pod ارائه می‌دهد، از جمله جزئیات مربوط به کانتینرها، Volumeها، و رویدادهایی که ممکن است در طول عمر Pod رخ داده باشد.

گام‌ها:

1. مشاهده جزئیات یک Pod خاص: برای مشاهده جزئیات کامل یک Pod خاص، دستور زیر را وارد کنید:

   kubectl describe pod nginx-pod
   

   این دستور اطلاعات کاملی درباره Pod به نام nginx-pod نمایش می‌دهد. اطلاعات شامل موارد زیر می‌باشد:

   • Container Details: شامل نام کانتینرها، وضعیت آنها، و پیکربندی مربوط به هر کانتینر.
   • Events: تمامی رویدادهایی که برای Pod اتفاق افتاده است (مثلاً زمان‌هایی که کانتینر راه‌اندازی یا متوقف شده است).
   • Volumes: اطلاعات مربوط به حجم‌های مورد استفاده توسط Pod.
   • Conditions: شرایط مختلف Pod مانند Ready, Initialized, PodScheduled و وضعیت آنها.

   مثال خروجی:

   Name:           nginx-pod
   Namespace:      default
   Node:           node1/192.168.1.100
   Start Time:     Thu, 09 Feb 2025 14:00:00 +0000
   Containers:
     nginx-container:
       Container ID:   docker://abc123xyz
       Image:          nginx:latest
       Image ID:       docker-pullable://nginx@sha256:abc123xyz
       Port:           80/TCP
       State:          Running
         Started:      Thu, 09 Feb 2025 14:00:05 +0000
       Ready:          True
       Restart Count:  0
   Events:
     Type    Reason     Age   From               Message
     ----    ------     ----  ----               -------
     Normal  Scheduled  10m   default-scheduler  Successfully assigned default/nginx-pod to node1
     Normal  Pulling    10m   kubelet, node1     Pulling image "nginx:latest"
     Normal  Pulled     10m   kubelet, node1     Successfully pulled image "nginx:latest"
     Normal  Created    10m   kubelet, node1     Created container nginx-container
     Normal  Started    10m   kubelet, node1     Started container nginx-container
   

   در اینجا:

   • Containers: اطلاعات مربوط به هر کانتینر از جمله وضعیت (Running، Terminated)، تاریخ شروع و زمان‌های راه‌اندازی.
   • Events: تاریخچه‌ای از رویدادهایی که در طول عمر Pod رخ داده است.

جمع‌بندی

با استفاده از دستورات kubectl get pods و kubectl describe pod، شما می‌توانید وضعیت و جزئیات دقیق هر Pod را در Kubernetes بررسی کنید. دستور kubectl get pods برای دریافت وضعیت کلی و ساده استفاده می‌شود، در حالی که دستور kubectl describe pod جزئیات بیشتری مانند وضعیت کانتینرها، رویدادها و پیکربندی‌ها را در اختیار شما قرار می‌دهد. این دستورات ابزارهایی ضروری برای مدیریت و نظارت بر Podها در کلاسترهای Kubernetes هستند.

حذف Pod

برای حذف یک Pod، می‌توانید از دستور kubectl delete pod استفاده کنید. با این دستور، Pod از کلاستر Kubernetes حذف می‌شود.

گام‌ها:

1. حذف یک Pod خاص: برای حذف یک Pod خاص با نام مشخص، دستور زیر را وارد کنید:

   kubectl delete pod <pod-name>
   

   به عنوان مثال، برای حذف Pod به نام nginx-pod:

   kubectl delete pod nginx-pod
   

2. حذف تمامی Podها در یک Namespace خاص: برای حذف تمامی Podها در یک Namespace خاص (مثلاً default)، دستور زیر را وارد کنید:

   kubectl delete pods --all --namespace=default
   

   این دستور تمامی Podها را در Namespace default حذف خواهد کرد.

به‌روزرسانی Pod

برای به‌روزرسانی Podها، معمولاً روش‌هایی مانند استفاده از Deploymentها یا StatefulSetها برای به‌روزرسانی خودکار Podها استفاده می‌شود، چرا که Podها به‌طور طبیعی به‌طور مستقیم قابل به‌روزرسانی نیستند. وقتی که نیاز به تغییر Pod دارید، باید یک Pod جدید ایجاد کرده و قدیمی را حذف کنید.

گام‌ها:

1. به‌روزرسانی یک Pod با تغییر فایل YAML: اگر برای ایجاد Podها از فایل‌های YAML استفاده کرده‌اید، می‌توانید فایل YAML را تغییر داده و سپس دستور زیر را برای اعمال تغییرات وارد کنید:

   kubectl apply -f <path-to-pod-yaml>
   

   این دستور تغییرات را در Pod به‌روز می‌کند.

2. به‌روزرسانی یک Pod در یک Deployment: در صورتی که Pod به‌عنوان بخشی از یک Deployment اجرا شده باشد، برای به‌روزرسانی آن باید به‌روزرسانی Deployment انجام دهید. به‌طور مثال، برای تغییر تصویر Container یک Pod در Deployment:

   kubectl set image deployment/<deployment-name> <container-name>=<new-image>
   

   مثال:

   kubectl set image deployment/nginx-deployment nginx-container=nginx:latest
   

   این دستور باعث به‌روزرسانی Deployment به نسخه جدید تصویر می‌شود و Kubernetes به‌طور خودکار Podهای قدیمی را حذف و Podهای جدید را ایجاد خواهد کرد.

بررسی وضعیت Pod

برای بررسی وضعیت یک Pod، می‌توانید از دستوراتی مانند kubectl get pods و kubectl describe pod استفاده کنید. این دستورات اطلاعات دقیق و کلی در مورد وضعیت و عملکرد Podها در اختیار شما قرار می‌دهند.

گام‌ها:

1. بررسی وضعیت تمامی Podها: برای مشاهده وضعیت کلی تمامی Podها در کلاستر، دستور زیر را وارد کنید:

   kubectl get pods
   

   این دستور اطلاعات کلی از جمله وضعیت، تعداد کانتینرهای آماده، و مدت زمان اجرا را برای تمامی Podها نمایش می‌دهد.

2. بررسی وضعیت یک Pod خاص: برای مشاهده وضعیت دقیق یک Pod خاص، دستور زیر را وارد کنید:

   kubectl get pod <pod-name>
   

   به عنوان مثال:

   kubectl get pod nginx-pod
   

3. مشاهده جزئیات کامل یک Pod خاص: برای دریافت اطلاعات دقیق‌تری در مورد وضعیت Pod، از دستور kubectl describe pod استفاده کنید:

   kubectl describe pod <pod-name>
   

   به عنوان مثال:

   kubectl describe pod nginx-pod
   

   این دستور اطلاعاتی مانند وضعیت کانتینرها، رویدادها، حجم‌ها و خطاهای احتمالی را در اختیار شما قرار می‌دهد.

جمع‌بندی

مدیریت Podها در Kubernetes شامل عملیات‌های مختلفی از جمله حذف، به‌روزرسانی و بررسی وضعیت است. دستورات kubectl delete pod، kubectl apply -f <path-to-pod-yaml> و kubectl set image ابزارهای اصلی برای انجام این عملیات‌ها هستند. علاوه بر این، دستورات kubectl get pods و kubectl describe pod برای نظارت و بررسی وضعیت Podها استفاده می‌شوند. این دستورات به شما کمک می‌کنند تا به‌راحتی Podها را مدیریت کرده و وضعیت کلاستر خود را به‌طور دقیق پیگیری کنید.

انواع Pods چند کانتینری

در Kubernetes، چندین مدل برای استفاده از چند کانتینر در یک Pod وجود دارد:

1. Sidecar Pattern: در این الگو، یک کانتینر اصلی وجود دارد که به انجام وظایف اصلی می‌پردازد و یک یا چند کانتینر کمکی (sidecar) برای انجام وظایف تکمیلی مانند لاگ‌گیری، نظارت، یا کشینگ داده‌ها اضافه می‌شود.
2. Ambassador Pattern: در این الگو، کانتینرهای کمکی معمولاً برای تعامل با سرویس‌های خارجی (مثل API‌ها) یا پروکسی کردن ترافیک استفاده می‌شوند.
3. Adapter Pattern: در این الگو، کانتینرهای کمکی می‌توانند به عنوان یک پل میان سرویس‌های مختلف عمل کنند که فرمت داده‌ها را تطبیق می‌دهند.

مزایای Pods چند کانتینری

1. ارتباط نزدیک بین کانتینرها: کانتینرهای داخل یک Pod می‌توانند فضای شبکه و منابع ذخیره‌سازی مشترک داشته باشند. این ویژگی باعث می‌شود که ارتباط بین کانتینرها سریع و بهینه باشد. به عنوان مثال، کانتینرها می‌توانند به راحتی فایل‌ها یا اطلاعات را از طریق Volumeها به اشتراک بگذارند.
2. مدیریت ساده: زمانی که چند کانتینر در یک Pod قرار دارند، مدیریت و نظارت بر آن‌ها ساده‌تر می‌شود. زیرا Kubernetes برای این Pod یک شناسه یکتا ایجاد کرده و تمام کانتینرها را به‌عنوان یک واحد مدیریت می‌کند.
3. پایداری بالاتر: کانتینرهایی که در یک Pod قرار دارند، اگر یکی از کانتینرها خراب شود، سایر کانتینرها هم می‌توانند تا حدی به وظایف خود ادامه دهند. همچنین، اگر یکی از کانتینرها نیاز به راه‌اندازی مجدد داشته باشد، Kubernetes این کار را برای همه کانتینرها انجام خواهد داد.
4. کاهش نیاز به استقرار مجدد: در مدل‌های سنتی، اگر یک کانتینر جدید نیاز به استقرار داشته باشد، ممکن است نیاز به راه‌اندازی یک Pod جدید باشد. اما در Pods چند کانتینری، چون کانتینرها در یک فضای مشترک قرار دارند، می‌توان آن‌ها را بدون نیاز به استقرار دوباره راه‌اندازی کرد.
5. اشتراک منابع: همه کانتینرهای یک Pod می‌توانند از یک Volume برای ذخیره‌سازی داده‌ها استفاده کنند. این قابلیت باعث می‌شود که کانتینرها به‌راحتی اطلاعات خود را به اشتراک بگذارند و از منابعی که در Pod تعریف شده، بهره‌برداری کنند.
6. مقیاس‌پذیری بهتر: اگر چند کانتینر در یک Pod برای انجام یک عملیات خاص نیاز به مقیاس‌گذاری داشته باشند، می‌توانند به صورت همزمان مقیاس داده شوند. به عنوان مثال، اگر نیاز به مقیاس‌گذاری یک سرویس و یک کانتینر جانبی باشد، این عملیات به صورت همزمان بر روی تمامی کانتینرهای آن Pod اعمال خواهد شد.

نمونه‌ای از Pod چند کانتینری در YAML

در ادامه یک مثال از تعریف یک Pod چند کانتینری با استفاده از YAML آورده شده است:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: app-container
    image: nginx:latest
    ports:
    - containerPort: 80
  - name: log-sidecar
    image: busybox
    command: ['sh', '-c', 'tail -f /var/log/app.log']
    volumeMounts:
    - mountPath: /var/log
      name: log-volume
  volumes:
  - name: log-volume
    emptyDir: {}

در این مثال، Pod دارای دو کانتینر است:

• app-container: یک کانتینر Nginx است که به عنوان سرویس اصلی اجرا می‌شود.
• log-sidecar: یک کانتینر busybox که به عنوان کانتینر کمکی (sidecar) برای مشاهده و مدیریت لاگ‌ها اجرا می‌شود.

این دو کانتینر از یک Volume مشترک به نام log-volume استفاده می‌کنند که به آن‌ها این امکان را می‌دهد که لاگ‌های مشترک را ذخیره کرده و به آن دسترسی داشته باشند.

جمع بندی

Pods چند کانتینری در Kubernetes به شما این امکان را می‌دهند که چند کانتینر با وظایف مختلف را در یک محیط مشترک اجرا کنید و مزایای زیادی از جمله ارتباط نزدیک، اشتراک منابع، و مدیریت ساده‌تر بدست آورید. این نوع طراحی، به ویژه در مواقعی که کانتینرها نیاز به همکاری دارند، می‌تواند یک معماری مؤثر و مقیاس‌پذیر باشد.

Sidecar Pattern (کانتینر کمکی برای logging، monitoring، و غیره)

الگوی Sidecar Pattern به شما این امکان را می‌دهد که کانتینر اصلی خود را با کانتینرهای کمکی (sidecar) احاطه کنید. کانتینرهای کمکی به طور معمول وظایف کمکی مانند لاگ‌گیری، نظارت، یا پردازش داده‌ها را انجام می‌دهند. به عبارت دیگر، این کانتینرها به کانتینر اصلی خدمات پشتیبانی می‌دهند و در همان Pod اجرا می‌شوند.

مزایا:

• ساده‌سازی عملکردهای کمکی مانند logging و monitoring که نیاز به منابع مشترک دارند.
• تسهیل ارتباط و هماهنگی بین کانتینرهای اصلی و کمکی از طریق فضای ذخیره‌سازی یا شبکه مشترک.

مثال YAML برای پیاده‌سازی Sidecar Pattern:

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-pattern-pod
spec:
  containers:
  - name: main-container
    image: nginx:latest
    ports:
    - containerPort: 80
  - name: log-sidecar
    image: busybox
    command: ['sh', '-c', 'tail -f /var/log/nginx/access.log']
    volumeMounts:
    - mountPath: /var/log
      name: log-volume
  volumes:
  - name: log-volume
    emptyDir: {}

در این مثال، کانتینر nginx به عنوان کانتینر اصلی و کانتینر busybox به عنوان کانتینر کمکی برای مشاهده لاگ‌ها اجرا می‌شود.

Ambassador Pattern (کانتینر برای پروکسی و ارتباطات خارجی)

Ambassador Pattern به شما کمک می‌کند تا یک کانتینر کمکی به عنوان پروکسی یا ترمینال ورودی برای تعامل با منابع خارجی و سایر سرویس‌ها در خارج از Cluster عمل کند. این الگو برای مدیریت ترافیک ورودی و خروجی به یک Pod مفید است و می‌تواند به طور خاص در مواقعی که نیاز به یک نقطه ورودی یکتا برای خدمات موجود در Cluster دارید، مورد استفاده قرار گیرد.

مزایا:

• ساده‌سازی اتصال به سرویس‌های خارجی.
• امنیت بیشتر از طریق جداسازی ارتباطات داخلی و خارجی.
• افزایش مقیاس‌پذیری و انعطاف‌پذیری در ارتباطات.

مثال YAML برای پیاده‌سازی Ambassador Pattern:

apiVersion: v1
kind: Pod
metadata:
  name: ambassador-pattern-pod
spec:
  containers:
  - name: main-container
    image: nginx:latest
    ports:
    - containerPort: 80
  - name: ambassador
    image: envoyproxy/envoy:v1.18-latest
    ports:
    - containerPort: 8080
    args:
      - "/usr/local/bin/envoy"
      - "--config-path=/etc/envoy/envoy.yaml"
      - "--service-cluster=main-service"
      - "--service-node=ambassador"

در این مثال، کانتینر envoy به عنوان پروکسی برای مدیریت ترافیک ورودی و خروجی به nginx عمل می‌کند.

Adapter Pattern (کانتینر برای تبدیل داده‌ها یا فرمت‌ها)

Adapter Pattern در Kubernetes زمانی مفید است که شما نیاز دارید داده‌ها یا فرمت‌های مختلف را به یکدیگر تبدیل کنید. این الگو معمولاً شامل استفاده از یک کانتینر کمکی برای تبدیل فرمت داده‌ها، پردازش داده‌ها یا ایجاد سازگاری بین سرویس‌ها است.

مزایا:

• تطبیق با فرمت‌های مختلف داده‌ها بدون نیاز به تغییر در سرویس‌های اصلی.
• یکپارچگی سرویس‌ها و داده‌ها با یک لایه تطبیق.

مثال YAML برای پیاده‌سازی Adapter Pattern:

apiVersion: v1
kind: Pod
metadata:
  name: adapter-pattern-pod
spec:
  containers:
  - name: main-container
    image: python:3.8
    command: ["python3", "main.py"]
    volumeMounts:
    - mountPath: /data
      name: data-volume
  - name: adapter
    image: busybox
    command: ["sh", "-c", "cat /data/input.json | jq ."]
    volumeMounts:
    - mountPath: /data
      name: data-volume
  volumes:
  - name: data-volume
    emptyDir: {}

در این مثال، کانتینر python به عنوان سرویس اصلی است و کانتینر busybox به عنوان adapter برای پردازش و تبدیل داده‌ها از فرمت JSON به فرمت قابل استفاده در سرویس اصلی عمل می‌کند.

جمع بندی

الگوهای طراحی مانند Sidecar Pattern، Ambassador Pattern و Adapter Pattern در Kubernetes به شما این امکان را می‌دهند که پیچیدگی‌های مختلف را به شکل مؤثری مدیریت کنید. با استفاده از این الگوها می‌توانید سرویس‌ها و کانتینرهای خود را به صورت مؤثری مدیریت کرده و قابلیت‌های اضافی مانند لاگ‌گیری، نظارت، پروکسی کردن ترافیک و تبدیل فرمت داده‌ها را به سادگی پیاده‌سازی کنید.

یکی از مزایای استفاده از Multi-Container Pods این است که کانتینرها می‌توانند وظایف مختلفی را انجام دهند، اما همچنان به عنوان بخشی از یک سرویس در نظر گرفته می‌شوند. معمولاً از این نوع Pods برای پیاده‌سازی الگوهای طراحی مانند Sidecar Pattern، Ambassador Pattern و Adapter Pattern استفاده می‌شود.

ایجاد Multi-Container Pod با YAML

برای ایجاد یک Multi-Container Pod در Kubernetes، شما می‌توانید از یک فایل YAML استفاده کنید که در آن تمامی کانتینرها را تعریف کرده‌اید. در اینجا یک مثال برای ایجاد یک Multi-Container Pod آورده شده است که در آن یک کانتینر برای اجرای سرویس و یک کانتینر کمکی برای نظارت بر لاگ‌ها وجود دارد.

مثال YAML برای ایجاد Multi-Container Pod:

apiVersion: v1
kind: Pod
metadata:
  name: multi-container-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
  - name: log-sidecar
    image: busybox
    command: ['sh', '-c', 'tail -f /var/log/nginx/access.log']
    volumeMounts:
    - mountPath: /var/log
      name: log-volume
  volumes:
  - name: log-volume
    emptyDir: {}

توضیحات:

• در این مثال، nginx به عنوان کانتینر اصلی در نظر گرفته شده است که سرویس وب را ارائه می‌دهد.
• کانتینر log-sidecar برای مشاهده و نظارت بر لاگ‌های کانتینر nginx ایجاد شده است.
• این دو کانتینر از یک Volume به نام log-volume استفاده می‌کنند که لاگ‌ها در آن ذخیره می‌شود و کانتینر log-sidecar قادر به مشاهده و پردازش آن‌ها خواهد بود.

پیکربندی و اجرا

1. فایل YAML را در سیستم خود با نام multi-container-pod.yaml ذخیره کنید.
2. برای ایجاد Pod با استفاده از فایل YAML، دستور زیر را اجرا کنید:

   kubectl apply -f multi-container-pod.yaml
   

3. برای بررسی وضعیت Pod و اطمینان از اجرای صحیح کانتینرها، از دستور زیر استفاده کنید:

   kubectl get pods
   

4. برای مشاهده جزئیات بیشتر و بررسی وضعیت کانتینرها، از دستور زیر استفاده کنید:

   kubectl describe pod multi-container-pod
   

جمع بندی

Multi-Container Pods در Kubernetes برای مواردی که نیاز به اجرای چند کانتینر در کنار یکدیگر دارند، بسیار مفید هستند. با استفاده از فایل‌های YAML می‌توانید به راحتی چندین کانتینر را در یک Pod مدیریت کنید. این قابلیت به ویژه برای پیاده‌سازی الگوهای طراحی مختلف مانند Sidecar Pattern و Ambassador Pattern ضروری است.

مفهوم Init Containers

• Init Containers مانند کانتینرهای معمولی هستند، اما وظیفه آنها تنها قبل از شروع کانتینرهای اصلی است. هر Pod می‌تواند چندین Init Container داشته باشد که به ترتیب اجرا می‌شوند و تنها زمانی که یک Init Container به درستی به اتمام برسد، کانتینر بعدی اجرا خواهد شد.
• این کانتینرها به صورت موازی با یکدیگر اجرا نمی‌شوند بلکه به ترتیب و یکی پس از دیگری اجرا می‌شوند.

مزایای استفاده از Init Containers

1. ایجاد محیط آماده برای کانتینرهای اصلی:
   • Init Containers به شما این امکان را می‌دهند که قبل از اجرای کانتینرهای اصلی، کارهایی مانند بررسی وجود فایل‌ها، بارگذاری داده‌ها، یا تنظیمات شبکه را انجام دهید.
   • به عنوان مثال، می‌توانید قبل از اجرای اپلیکیشن اصلی، دیتابیس را راه‌اندازی یا فایل‌های پیکربندی را دانلود کنید.
2. جداسازی وظایف اولیه از وظایف اصلی:
   • انجام کارهایی مانند نصب وابستگی‌ها، پیکربندی شبکه یا بارگذاری داده‌ها به کانتینرهای Init اختصاص می‌یابد، بنابراین کانتینرهای اصلی تنها بر روی انجام وظایف اصلی تمرکز خواهند کرد.
3. ساده‌تر شدن مدیریت خطاها:
   • اگر یکی از Init Containers با مشکل مواجه شود، خطای آن به وضوح مشخص خواهد شد و می‌توان آن را به راحتی برطرف کرد. اگر کانتینر اصلی با مشکلی مواجه شود، دلیل اصلی را می‌توان در Init Container جستجو کرد.
4. امکان اجرای چندین مرحله پیکربندی:
   • می‌توانید چندین مرحله پیکربندی مختلف را در Init Containers انجام دهید که نیاز به ترتیب دارند. به این ترتیب، هر مرحله به طور مستقل از دیگر مراحل انجام می‌شود و باعث می‌شود مدیریت پروژه‌ها ساده‌تر گردد.
5. کاهش پیچیدگی در کانتینرهای اصلی:
   • با استفاده از Init Containers، کانتینرهای اصلی می‌توانند کار خود را ساده‌تر و با تمرکز بیشتری انجام دهند، چرا که تمامی وظایف اولیه را می‌توان به صورت مستقل از آنها به Init Containers واگذار کرد.

نحوه تعریف Init Containers در YAML

در فایل YAML برای تعریف یک Pod، می‌توانید Init Containers را به راحتی قبل از تعریف کانتینرهای اصلی اضافه کنید. در اینجا یک مثال ساده برای استفاده از Init Containers آورده شده است:

مثال YAML برای استفاده از Init Containers:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-init-containers
spec:
  initContainers:
  - name: init-container
    image: busybox
    command: ['sh', '-c', 'echo "Initializing resources..."']
  containers:
  - name: main-container
    image: nginx
    ports:
    - containerPort: 80

توضیحات:

• در این مثال، یک Init Container به نام init-container داریم که در ابتدا با اجرای دستور echo پیامی را نمایش می‌دهد.
• پس از اتمام اجرای Init Container، کانتینر اصلی nginx اجرا خواهد شد.

پیکربندی و اجرا

1. فایل YAML را در سیستم خود با نام pod-with-init-containers.yaml ذخیره کنید.
2. برای ایجاد Pod با استفاده از فایل YAML، دستور زیر را اجرا کنید:

   kubectl apply -f pod-with-init-containers.yaml
   

3. برای بررسی وضعیت Pod و اطمینان از اینکه Init Containers به درستی اجرا شده‌اند، از دستور زیر استفاده کنید:

   kubectl get pods
   

4. برای مشاهده جزئیات بیشتر و بررسی وضعیت کانتینرها، از دستور زیر استفاده کنید:

   kubectl describe pod pod-with-init-containers
   

جمع بندی

Init Containers در Kubernetes به شما این امکان را می‌دهند که پیش از شروع اجرای کانتینرهای اصلی، کارهای ضروری را انجام دهید. این ویژگی باعث بهبود انعطاف‌پذیری و مدیریت بهتر محیط‌های پیچیده می‌شود. با استفاده از Init Containers، می‌توانید وظایف اولیه را از کانتینرهای اصلی جدا کرده و مشکلات را به سادگی مدیریت کنید.

چرا از Init Containers برای آماده‌سازی محیط استفاده کنیم؟

1. آماده‌سازی محیط قبل از شروع کانتینر اصلی
2. مدیریت وابستگی‌ها
3. اجرای اسکریپت‌های یک‌بار مصرف
4. گزارش‌دهی و لاگ‌گیری قبل از شروع اپلیکیشن

نحوه استفاده از Init Containers برای آماده‌سازی محیط

برای استفاده از Init Containers، آنها را باید در فایل YAML مربوط به Pod تعریف کنید. این Init Containers باید قبل از شروع کانتینرهای اصلی اجرا شوند و می‌توانند به صورت موازی با یکدیگر اجرا نشوند.

مثال استفاده از Init Containers برای آماده‌سازی محیط

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-init-container
spec:
  initContainers:
  - name: init-container
    image: busybox
    command: ['sh', '-c', 'echo "Starting setup..."; sleep 5; echo "Setup completed!"']
  containers:
  - name: main-container
    image: nginx
    ports:
    - containerPort: 80

اجرای Pod و مشاهده وضعیت

1. برای ایجاد Pod با استفاده از فایل YAML، دستور زیر را اجرا کنید:

   kubectl apply -f pod-with-init-container.yaml
   

2. برای مشاهده وضعیت Pod و اطمینان از اینکه Init Container به درستی اجرا شده است، از دستور زیر استفاده کنید:

   kubectl get pods
   

3. برای مشاهده جزئیات بیشتر و بررسی وضعیت Init Container و کانتینر اصلی، از دستور زیر استفاده کنید:

   kubectl describe pod pod-with-init-container
   

جمع بندی

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

ویژگی‌های Init Containers

1. اجرای یک یا چند وظیفه پیش‌نیاز: می‌توانید از Init Containers برای انجام کارهایی مانند دانلود داده‌ها، راه‌اندازی فایل‌ها یا سرویس‌ها، و بررسی پیش‌نیازها استفاده کنید.
2. اجرای موازی: Init Containers به‌صورت متوالی اجرا می‌شوند و تنها پس از اتمام اجرای همه Init Containers، کانتینرهای اصلی شروع به کار می‌کنند.
3. محدودیت‌ها: Init Containers می‌توانند از منابع مشابه با کانتینرهای اصلی استفاده کنند، اما هر Init Container به‌طور مستقل از دیگران اجرا می‌شود.

ساختار پایه برای استفاده از Init Containers در فایل YAML

برای تعریف Init Containers، آن‌ها را باید در بخش initContainers در فایل YAML مربوط به Pod خود اضافه کنید. در ادامه، یک ساختار پایه برای استفاده از Init Containers ارائه می‌شود:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-init-containers
spec:
  initContainers:
  - name: init-container-1
    image: busybox
    command: ['sh', '-c', 'echo "Initializing environment..."; sleep 10']
  containers:
  - name: main-container
    image: nginx
    ports:
    - containerPort: 80

در این مثال، یک Init Container با نام init-container-1 و یک دستور ساده برای چاپ پیام و معطل کردن ۱۰ ثانیه تا اجرای بعدی قرار داده شده است.

مثال‌های کاربردی

1. دانلود فایل قبل از شروع اجرای کانتینر اصلی

فرض کنید که قبل از شروع کانتینر اصلی، نیاز به دانلود یک فایل پیکربندی از یک سرور دارید. می‌توانید از Init Containers برای این کار استفاده کنید:

apiVersion: v1
kind: Pod
metadata:
  name: download-file-pod
spec:
  initContainers:
  - name: download-config
    image: curlimages/curl
    command: ['curl', '-o', '/tmp/config.yaml', 'http://example.com/config.yaml']
    volumeMounts:
    - name: config-volume
      mountPath: /tmp
  containers:
  - name: main-container
    image: nginx
    ports:
    - containerPort: 80
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    emptyDir: {}

در این مثال:

• از Init Container برای دانلود فایل config.yaml از سرور استفاده شده است.
• فایل دانلودشده در یک Volume به نام config-volume ذخیره می‌شود.
• پس از اتمام کار Init Container، کانتینر اصلی که در اینجا یک nginx است، فایل پیکربندی را در مسیر /etc/config بارگذاری می‌کند.

2. بررسی و آماده‌سازی پایگاه‌داده قبل از شروع کانتینر اصلی

فرض کنید که کانتینر اصلی شما نیاز دارد قبل از اجرا، اتصال به پایگاه‌داده را بررسی کرده و اطمینان حاصل کند که پایگاه‌داده در دسترس است. این کار می‌تواند به‌صورت زیر انجام شود:

apiVersion: v1
kind: Pod
metadata:
  name: db-check-pod
spec:
  initContainers:
  - name: db-check
    image: busybox
    command: ['sh', '-c', 'until nc -z db-service 3306; do echo "Waiting for DB"; sleep 5; done']
  containers:
  - name: main-container
    image: app-container
    ports:
    - containerPort: 8080

در این مثال:

• از Init Container برای بررسی وضعیت پایگاه‌داده (از طریق بررسی پورت 3306) استفاده می‌شود.
• تا زمانی که پایگاه‌داده در دسترس نباشد، Init Container در حال اجرای دستور nc -z db-service 3306 باقی می‌ماند.
• بعد از موفقیت در بررسی پایگاه‌داده، کانتینر اصلی که حاوی اپلیکیشن شما است، شروع به کار می‌کند.

3. اعمال تنظیمات پیکربندی پیش از شروع اپلیکیشن

در برخی موارد، ممکن است نیاز به اعمال تنظیمات خاص به سیستم قبل از شروع کانتینر اصلی باشد. این کار می‌تواند شامل تغییرات در فایل‌ها یا محیط باشد.

apiVersion: v1
kind: Pod
metadata:
  name: setup-config-pod
spec:
  initContainers:
  - name: setup-config
    image: busybox
    command: ['sh', '-c', 'echo "Setting up environment"; echo "app_mode=production" > /config/settings.conf']
    volumeMounts:
    - name: config-volume
      mountPath: /config
  containers:
  - name: main-container
    image: myapp
    ports:
    - containerPort: 8080
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    emptyDir: {}

در اینجا:

• Init Container به عنوان یک اسکریپت تنظیمات عمل کرده و متغیر محیطی app_mode=production را در فایل settings.conf ذخیره می‌کند.
• سپس این فایل در یک Volume مشترک با کانتینر اصلی به اشتراک گذاشته می‌شود.

دستورات برای پیاده‌سازی و اجرای Pod با Init Container

1. برای ایجاد Pod با استفاده از فایل YAML که شامل Init Container است، از دستور زیر استفاده کنید:

   kubectl apply -f setup-config-pod.yaml
   

2. برای مشاهده وضعیت Pod و اطمینان از اجرای صحیح Init Containers، از دستور زیر استفاده کنید:

   kubectl get pods
   

3. برای بررسی جزئیات بیشتر در خصوص وضعیت Init Containers و کانتینر اصلی، از دستور زیر استفاده کنید:

   kubectl describe pod setup-config-pod
   

جمع بندی

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

تعریف ReplicaSet

ReplicaSet به مجموعه‌ای از پادها اشاره دارد که همگی از یک تصویر (Image) یکسان برای اجرا استفاده می‌کنند و معمولاً به‌منظور حفظ تعداد مشخصی از نمونه‌ها (Pods) از یک سرویس، در کلاستر Kubernetes تنظیم می‌شوند. در واقع، ReplicaSet مسئول نظارت و مدیریت تعدادی از پادها است تا اطمینان حاصل شود که همیشه تعداد مشخصی از پادها در حال اجرا هستند.

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

اهمیت ReplicaSets در مقیاس‌پذیری و در دسترس بودن

1. مقیاس‌پذیری (Scalability):
   • ReplicaSets به شما این امکان را می‌دهند که به‌راحتی تعداد پادهای موردنیاز خود را تغییر دهید. با افزایش یا کاهش تعداد پادها در ReplicaSet، شما می‌توانید بار ترافیک را به‌طور موثر توزیع کنید.
   • به عنوان مثال، اگر ترافیک ورودی به سیستم افزایش یابد، شما می‌توانید تعداد پادها را افزایش دهید تا سیستم بتواند درخواست‌ها را بهتر مدیریت کند.
   • دستورات Kubernetes برای مقیاس‌پذیری ReplicaSets به‌راحتی قابل اجرا هستند و شما می‌توانید با استفاده از دستور kubectl scale تعداد پادها را به دلخواه تغییر دهید.

   kubectl scale replicaset <replicaset-name> --replicas=<number-of-replicas>
   

2. در دسترس بودن (Availability):
   • ReplicaSets به شما این امکان را می‌دهند که از دسترس بودن بالا (High Availability) اطمینان حاصل کنید. اگر یکی از پادهای شما به هر دلیلی از کار بیفتد، ReplicaSet به‌طور خودکار یک پاد جدید راه‌اندازی می‌کند تا تعداد پادهای فعال در سیستم همیشه ثابت بماند.
   • این ویژگی باعث افزایش resilience اپلیکیشن شما می‌شود و از بروز اختلال در سرویس‌دهی به کاربران جلوگیری می‌کند.
   • همچنین، ReplicaSets به Kubernetes کمک می‌کنند تا از load balancing مناسب استفاده کند، به این صورت که ترافیک به‌طور یکنواخت بین پادهای مختلف توزیع می‌شود.
3. مدیریت و نظارت آسان:
   • ReplicaSets به‌راحتی مدیریت و نظارت می‌شوند. می‌توانید با استفاده از دستورات Kubernetes وضعیت ReplicaSet و تعداد پادهای آن را بررسی کنید.
   • به‌عنوان مثال، برای بررسی وضعیت ReplicaSet می‌توانید از دستور زیر استفاده کنید:

   kubectl get replicasets
   

   همچنین، برای مشاهده جزئیات بیشتر می‌توانید از دستور زیر استفاده کنید:

   kubectl describe replicaset <replicaset-name>
   

ساختار YAML برای تعریف یک ReplicaSet

در ادامه، یک مثال از نحوه تعریف یک ReplicaSet در فایل YAML آورده شده است:

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: my-replicaset
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: nginx:latest
        ports:
        - containerPort: 80

در این مثال:

• replicas: 3 به Kubernetes می‌گوید که باید ۳ پاد از این ReplicaSet در کلاستر فعال باشند.
• selector مشخص می‌کند که پادها باید دارای برچسب‌های مشابه با برچسب‌های تعیین‌شده باشند تا از مدیریت صحیح پادها اطمینان حاصل شود.
• template ساختار پاد را تعریف می‌کند که شامل اطلاعاتی مانند نام کانتینر، تصویر (Image) و پورت‌های در دسترس است.

دستور برای ایجاد ReplicaSet

برای ایجاد یک ReplicaSet با استفاده از فایل YAML تعریف‌شده، از دستور زیر استفاده می‌شود:

kubectl apply -f replicaset.yaml

جمع بندی

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

در این بخش، به پیاده‌سازی Deployment برای مدیریت بهینه نسخه‌ها و مقیاس‌پذیری پرداخته می‌شود.

مفهوم Deployment

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

مزایای استفاده از Deployments

1. مدیریت بهینه نسخه‌ها (Version Control):
   • با استفاده از Deployment می‌توانید نسخه‌های مختلف اپلیکیشن خود را به‌طور مؤثر مدیریت کنید. به این صورت که می‌توانید به‌راحتی نسخه‌های جدید را به‌روز کرده و در صورت بروز مشکلات، به نسخه‌های قبلی بازگردید.
2. Rolling Updates:
   • یکی از ویژگی‌های مهم Deployment، به‌روزرسانی‌های تدریجی یا rolling updates است. این ویژگی به شما این امکان را می‌دهد که به‌طور تدریجی نسخه جدید اپلیکیشن را مستقر کنید، بدون اینکه ترافیک و در دسترس بودن اپلیکیشن شما دچار اختلال شود.
3. Rollback به نسخه قبلی:
   • اگر به‌روزرسانی‌ای که انجام داده‌اید باعث بروز مشکلاتی شد، می‌توانید به‌راحتی به نسخه قبلی بازگردید. Deployment این قابلیت را فراهم می‌آورد که نسخه‌های قبلی به‌صورت خودکار ذخیره شده و به‌راحتی قابل برگشت باشند.
4. مقیاس‌پذیری (Scalability):
   • شما می‌توانید تعداد پادها را به‌راحتی افزایش یا کاهش دهید تا اپلیکیشن شما بتواند بار بیشتری را تحمل کند. این مقیاس‌پذیری به‌صورت خودکار مدیریت می‌شود.

ساختار YAML برای تعریف یک Deployment

برای ایجاد یک Deployment باید یک فایل YAML با ساختار زیر تعریف کنید:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: nginx:latest
        ports:
        - containerPort: 80

در این مثال:

• replicas: 3 به Kubernetes می‌گوید که باید ۳ پاد از این Deployment در کلاستر فعال باشند.
• selector برچسب‌هایی را مشخص می‌کند که برای شناسایی پادهای مربوط به این Deployment استفاده می‌شود.
• template ساختار پاد و اطلاعات مربوط به کانتینرهای آن را مشخص می‌کند.

دستور برای ایجاد Deployment

برای ایجاد Deployment از فایل YAML تعریف‌شده، دستور زیر را وارد کنید:

kubectl apply -f deployment.yaml

بررسی وضعیت Deployment

برای بررسی وضعیت Deployment و اطمینان از اینکه تعداد پادها طبق انتظار راه‌اندازی شده‌اند، می‌توانید از دستورات زیر استفاده کنید:

1. بررسی وضعیت Deployment:

   kubectl get deployments
   

2. بررسی وضعیت پادهای مربوط به Deployment:

   kubectl get pods
   

Rolling Update در Deployment

یکی از ویژگی‌های برجسته Deployment، قابلیت rolling updates است که به شما این امکان را می‌دهد که نسخه‌های جدید اپلیکیشن را بدون هیچ گونه قطعی سرویس به‌روزرسانی کنید.

برای به‌روزرسانی یک Deployment، شما کافی است که تصویر (Image) جدید را برای کانتینر تعریف کنید. به‌عنوان مثال، برای به‌روزرسانی تصویر nginx به نسخه جدید، دستور زیر را اجرا کنید:

kubectl set image deployment/my-deployment myapp-container=nginx:latest

Kubernetes به‌طور خودکار به‌روزرسانی را انجام می‌دهد و پادها را یکی‌یکی با نسخه جدید جایگزین می‌کند تا از قطع شدن سرویس جلوگیری شود.

Rollback به نسخه قبلی

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

kubectl rollout undo deployment/my-deployment

جمع بندی

Deployments در Kubernetes به شما این امکان را می‌دهند که به‌طور مؤثر نسخه‌های مختلف اپلیکیشن را مدیریت کنید، مقیاس‌پذیری را انجام دهید و به‌روزرسانی‌های تدریجی (rolling updates) را بدون ایجاد اختلال در سرویس‌دهی پیاده‌سازی کنید. همچنین، قابلیت rollback به شما این امکان را می‌دهد که در صورت بروز مشکلات در نسخه جدید، به نسخه قبلی بازگردید. با استفاده از Deployment می‌توانید کدهای خود را به‌راحتی مدیریت کرده و اطمینان حاصل کنید که اپلیکیشن‌ها در کلاستر Kubernetes همیشه در دسترس و به‌روز هستند.

در این بخش، نحوه ایجاد و مدیریت Deployments با استفاده از فایل‌های YAML توضیح داده خواهد شد.

1. ساختار فایل YAML برای ایجاد Deployment

برای ایجاد یک Deployment با استفاده از فایل YAML، باید ساختار خاصی را دنبال کنید که شامل اطلاعات مختلف مانند تعداد پادها (replicas)، کانتینرها، و برچسب‌ها (labels) است. این ساختار به Kubernetes می‌گوید که چگونه اپلیکیشن‌ها را مدیریت کند.

نمونه فایل YAML برای ایجاد Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    app: myapp
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: nginx:latest
        ports:
        - containerPort: 80

در این فایل YAML:

• apiVersion: apps/v1: تعیین می‌کند که از نسخه‌ی جدیدتر API برای ایجاد Deployment استفاده می‌شود.
• kind: Deployment: نوع منبعی که قصد ایجاد آن را داریم.
• metadata: شامل اطلاعات متادیتا مانند نام Deployment و برچسب‌ها است.
• spec: مشخصات اصلی شامل تعداد پادها (replicas)، selector (برای شناسایی پادهای مرتبط با این Deployment) و قالب پاد (که حاوی اطلاعاتی مانند نام کانتینر، تصویر کانتینر و پورت‌ها است).
• replicas: 3: به Kubernetes می‌گوید که باید 3 پاد از این Deployment اجرا شوند.
• image: nginx:latest: تصویر کانتینر که قرار است در پاد اجرا شود.
• containerPort: 80: پورت داخل کانتینر که برای ارتباط با خارج از پاد مورد استفاده قرار می‌گیرد.

2. ایجاد Deployment با استفاده از فایل YAML

پس از ایجاد فایل YAML، می‌توانید از دستور زیر برای ایجاد Deployment در Kubernetes استفاده کنید:

kubectl apply -f deployment.yaml

این دستور فایل deployment.yaml را به Kubernetes ارسال کرده و Deployment جدیدی را ایجاد می‌کند.

3. مشاهده وضعیت Deployment

برای بررسی وضعیت Deployment و تعداد پادهای فعال، از دستور زیر استفاده کنید:

kubectl get deployments

این دستور وضعیت Deployment را به شما نمایش می‌دهد، شامل تعداد پادهای در حال اجرا و تعداد پادهای مورد نیاز.

همچنین برای مشاهده جزئیات بیشتر می‌توانید از دستور زیر استفاده کنید:

kubectl describe deployment my-deployment

4. به‌روزرسانی یک Deployment

اگر بخواهید Deployment خود را به‌روزرسانی کنید، مانند تغییر تصویر کانتینر یا تعداد پادها، می‌توانید از دستور زیر استفاده کنید:

kubectl set image deployment/my-deployment myapp-container=nginx:latest

این دستور باعث می‌شود که Deployment با تصویر جدید nginx:latest به‌روزرسانی شود. Kubernetes به‌طور خودکار فرآیند rolling update را انجام می‌دهد تا بدون قطع سرویس، پادهای جدید با نسخه جدید اپلیکیشن مستقر شوند.

5. تغییر تعداد پادها در Deployment

برای تغییر تعداد پادهای اجرا شده توسط Deployment، می‌توانید تعداد replicas را تغییر دهید. به‌طور مثال، برای افزایش تعداد پادها به 5، دستور زیر را اجرا کنید:

kubectl scale deployment my-deployment --replicas=5

این دستور باعث می‌شود که Kubernetes به‌طور خودکار 5 پاد از Deployment شما را اجرا کند.

6. Rollback به نسخه قبلی

اگر به‌روزرسانی‌ای که انجام داده‌اید مشکلاتی ایجاد کرد، می‌توانید به نسخه قبلی Deployment بازگردید. برای انجام این کار از دستور زیر استفاده کنید:

kubectl rollout undo deployment/my-deployment

این دستور Deployment را به نسخه قبلی باز می‌گرداند.

7. حذف Deployment

اگر بخواهید Deployment خود را حذف کنید، می‌توانید از دستور زیر استفاده کنید:

kubectl delete -f deployment.yaml

این دستور باعث می‌شود که Deployment شما به‌طور کامل حذف شود و پادهای مربوط به آن نیز از کلاستر Kubernetes حذف شوند.

جمع بندی

با استفاده از فایل‌های YAML، شما می‌توانید Deployments را در Kubernetes ایجاد کرده، آن‌ها را به‌روزرسانی کنید، تعداد پادها را مقیاس‌دهی کنید و در صورت نیاز به نسخه‌های قبلی بازگردید. این قابلیت‌ها باعث می‌شود که بتوانید اپلیکیشن‌های خود را به‌طور مؤثر مدیریت کنید و در صورت لزوم مقیاس‌پذیری و به‌روزرسانی‌های تدریجی را انجام دهید.

1. به‌روزرسانی تعداد Replicas در یک Deployment

برای تغییر تعداد پادها (replicas) در یک Deployment خاص، از دستور زیر استفاده می‌کنیم:

kubectl scale deployment <deployment-name> --replicas=<number-of-replicas>

مثال:

اگر بخواهید تعداد پادهای Deployment با نام my-deployment را به 5 افزایش دهید، دستور به‌صورت زیر خواهد بود:

kubectl scale deployment my-deployment --replicas=5

این دستور باعث می‌شود که Kubernetes به‌طور خودکار تعداد پادهای my-deployment را به 5 تغییر دهد. اگر تعداد پادهای فعلی کمتر از 5 باشد، Kubernetes پادهای جدید ایجاد می‌کند و اگر بیشتر از 5 باشد، برخی از پادها حذف می‌شوند.

2. به‌روزرسانی تعداد Replicas در یک ReplicaSet

برای تغییر تعداد پادها در یک ReplicaSet خاص، مشابه با Deployment عمل می‌کنیم. دستور به‌صورت زیر خواهد بود:

kubectl scale replicaset <replicaset-name> --replicas=<number-of-replicas>

مثال:

برای تنظیم تعداد پادها در ReplicaSet با نام my-replicaset به 3، دستور به‌صورت زیر خواهد بود:

kubectl scale replicaset my-replicaset --replicas=3

3. بررسی وضعیت بعد از تغییر تعداد Replicas

پس از به‌روزرسانی تعداد پادها با دستور kubectl scale، می‌توانید از دستور kubectl get pods برای بررسی وضعیت پادها و تعداد آن‌ها استفاده کنید:

kubectl get pods

همچنین، برای بررسی تعداد پادها در Deployment می‌توانید از دستور زیر استفاده کنید:

kubectl get deployment <deployment-name>

مثال:

kubectl get deployment my-deployment

این دستور تعداد پادهای موجود در Deployment و وضعیت آن‌ها را به شما نشان می‌دهد.

جمع بندی

دستور kubectl scale یک ابزار قوی و مفید برای تغییر تعداد replicas در Deployment یا ReplicaSet است که می‌تواند به‌راحتی تعداد پادها را بسته به نیازهای اپلیکیشن‌های شما مقیاس‌دهی کند. این روش بدون نیاز به ویرایش فایل YAML یا بازسازی منابع، امکان تغییر تعداد پادها را فراهم می‌کند و به شما اجازه می‌دهد تا به‌صورت داینامیک منابع خود را مدیریت کنید.

1. مفهوم Rolling Updates

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

به‌عنوان مثال، فرض کنید که یک Deployment با 5 پاد دارید. در هنگام به‌روزرسانی، Kubernetes تعدادی از پادهای قدیمی را حذف کرده و پادهای جدید را اضافه می‌کند تا مطمئن شود که حداقل تعدادی از پادها همیشه در دسترس هستند.

2. نحوه عملکرد Rolling Updates

هنگامی که به یک Deployment در Kubernetes یک نسخه جدید از یک کانتینر (مانند تغییر در تصویر Docker) اعمال می‌کنید، Kubernetes به‌طور خودکار یک Rolling Update انجام می‌دهد. این فرآیند به شرح زیر است:

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

3. پیکربندی Rolling Update در YAML

در فایل YAML مربوط به Deployment، شما می‌توانید نحوه انجام Rolling Update را با استفاده از مشخصات زیر تنظیم کنید:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1         # حداکثر تعداد پادهای جدید که می‌توانند همزمان راه‌اندازی شوند.
      maxUnavailable: 1    # حداکثر تعداد پادهای غیرفعال که می‌توانند همزمان باشند.
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: my-container:v2  # تصویر جدید کانتینر

• maxSurge: این مشخصه نشان می‌دهد که حداکثر چند پاد جدید می‌توانند در یک زمان ایجاد شوند. مقدار پیش‌فرض ۱ است.
• maxUnavailable: این مشخصه نشان می‌دهد که حداکثر چند پاد می‌توانند در یک زمان غیرفعال باشند (در حال به‌روزرسانی یا حذف).

4. دستور برای به‌روزرسانی Deployment

برای به‌روزرسانی Deployment با نسخه جدید تصویر کانتینر، شما می‌توانید از دستور kubectl set image استفاده کنید. این دستور تصویر جدید کانتینر را برای Deployment اعمال می‌کند و یک Rolling Update به‌طور خودکار انجام خواهد شد.

kubectl set image deployment/my-app my-container=my-container:v2

این دستور به Kubernetes می‌گوید که کانتینر my-container در Deployment my-app باید به نسخه v2 به‌روزرسانی شود.

5. نظارت بر فرآیند Rolling Update

برای نظارت بر وضعیت Rolling Update، می‌توانید از دستور kubectl rollout status استفاده کنید:

kubectl rollout status deployment/my-app

این دستور وضعیت به‌روزرسانی را نمایش می‌دهد و به شما اطلاع می‌دهد که آیا فرآیند به‌روزرسانی به درستی انجام شده است یا خیر.

6. بازگشت به نسخه قبلی (Rollback)

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

kubectl rollout undo deployment/my-app

این دستور به Kubernetes می‌گوید که Deployment را به آخرین نسخه پایدار بازگرداند.

جمع بندی

Rolling Updates در Kubernetes یک روش ایمن و کارآمد برای به‌روزرسانی برنامه‌ها بدون قطعی است. با این روش، شما می‌توانید نسخه‌های جدید برنامه‌ها را به‌صورت تدریجی پیاده‌سازی کنید، به‌طوری‌که هیچ‌گاه تمام پادهای شما به‌طور همزمان غیرقابل دسترس نمی‌شوند. این ویژگی به‌ویژه در محیط‌های production که نیاز به در دسترس بودن مداوم برنامه‌ها دارند، اهمیت زیادی دارد.

1. مفهوم Rollback در Kubernetes

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

2. استفاده از دستور kubectl rollout undo

دستور kubectl rollout undo به شما این امکان را می‌دهد که به آخرین نسخه پایدار بازگردید. به‌طور پیش‌فرض، این دستور آخرین revision موفق را به‌عنوان نسخه قبلی در نظر می‌گیرد و آن را بازمی‌گرداند.

kubectl rollout undo deployment/my-app

در این دستور:

• deployment/my-app: نام Deployment شما است. این دستور وضعیت به‌روزرسانی را برای my-app بررسی کرده و در صورت وجود مشکل، به نسخه قبلی بازمی‌گرداند.

3. بررسی تاریخچه به‌روزرسانی‌ها

قبل از انجام Rollback، شما می‌توانید تاریخچه به‌روزرسانی‌های Deployment خود را بررسی کنید تا ببینید که چه تغییراتی اعمال شده و به کدام نسخه‌ها می‌خواهید بازگردید. برای این کار از دستور kubectl rollout history استفاده می‌کنیم:

kubectl rollout history deployment/my-app

این دستور، تاریخچه به‌روزرسانی‌های انجام شده روی Deployment شما را نشان می‌دهد. شما می‌توانید هر revision را مشاهده کرده و نسخه‌های قبلی را بررسی کنید.

4. بازگشت به یک نسخه خاص

اگر نیاز دارید که به یک نسخه خاص بازگردید (نه صرفاً آخرین نسخه موفق)، می‌توانید از شناسه revision در دستور kubectl rollout undo استفاده کنید. مثلاً اگر می‌خواهید به revision شماره 3 بازگردید، دستور زیر را وارد می‌کنید:

kubectl rollout undo deployment/my-app --to-revision=3

5. نظارت بر وضعیت Rollback

پس از انجام Rollback، می‌توانید وضعیت Deployment خود را بررسی کنید تا مطمئن شوید که بازگشت به نسخه قبلی با موفقیت انجام شده است. از دستور kubectl rollout status برای نظارت بر وضعیت استفاده کنید:

kubectl rollout status deployment/my-app

این دستور به شما می‌گوید که آیا Rollback با موفقیت انجام شده است یا خیر.

جمع بندی

دستور kubectl rollout undo یکی از ابزارهای کلیدی برای مدیریت به‌روزرسانی‌ها در Kubernetes است که به شما اجازه می‌دهد تا در صورت بروز مشکل در نسخه جدید، به‌راحتی به نسخه قبلی بازگردید. با استفاده از این دستور و نظارت بر تاریخچه به‌روزرسانی‌ها، شما می‌توانید در هر زمان به‌صورت ایمن و بدون قطعی برنامه‌ها، عملیات بازگشت را انجام دهید.

1. نمایش تاریخچه به‌روزرسانی‌های Deployment

برای مشاهده تاریخچه به‌روزرسانی‌های یک Deployment خاص، از دستور kubectl rollout history به شکل زیر استفاده می‌شود:

kubectl rollout history deployment/my-app

در اینجا:

• deployment/my-app: نام Deployment شما است که می‌خواهید تاریخچه به‌روزرسانی‌های آن را مشاهده کنید.

این دستور فهرستی از revisions مختلف مربوط به Deployment شما را نشان می‌دهد، که هرکدام نمایانگر یک تغییر یا به‌روزرسانی خاص هستند.

2. مشاهده جزئیات هر revision

اگر بخواهید جزئیات بیشتری از یک revision خاص دریافت کنید، می‌توانید از گزینه --revision استفاده کنید. این دستور اطلاعات دقیقی را درباره هر revision مشخص شده نمایش می‌دهد:

kubectl rollout history deployment/my-app --revision=2

در اینجا:

• --revision=2: شناسه یا شماره revision است که می‌خواهید جزئیات آن را مشاهده کنید.

این دستور به شما اطلاعاتی از قبیل تغییرات در کانتینرها، تغییرات در تنظیمات و منابع مربوط به Deployment را نشان می‌دهد.

3. نمایش تاریخچه برای منابع دیگر

دستور kubectl rollout history نه تنها برای Deployment بلکه برای منابع دیگر Kubernetes مانند StatefulSet نیز کاربرد دارد. شما می‌توانید تاریخچه تغییرات منابع دیگر را نیز با استفاده از این دستور بررسی کنید:

kubectl rollout history statefulset/my-statefulset

4. نحوه استفاده در سناریوهای مختلف

• بررسی تاریخچه قبل از Rollback: با استفاده از تاریخچه، می‌توانید بررسی کنید که کدام revision به درستی کار می‌کند و کدام نسخه‌ها به مشکل برخوردند.
• شناسایی تغییرات غیرمطلوب: بررسی تاریخچه به شما این امکان را می‌دهد که تغییرات نامطلوب در تنظیمات یا کانتینرها را شناسایی کرده و اقدامات اصلاحی انجام دهید.

جمع بندی

دستور kubectl rollout history یکی از ابزارهای مفید در مدیریت Kubernetes است که به شما امکان می‌دهد تاریخچه تغییرات را در Deployment ها و دیگر منابع مشاهده کنید. با این اطلاعات، می‌توانید به‌راحتی مشکلات به‌روزرسانی‌ها را شناسایی کرده و به نسخه‌های پایدار قبلی بازگشت کنید.

1. مفهوم Job

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

2. ویژگی‌های اصلی Job

• یک‌بار اجرا: یک Job پس از شروع، تنها یک بار اجرا می‌شود و سپس پایان می‌یابد.
• مطمئن بودن از تکمیل وظیفه: اگر یک Pod با خطا مواجه شود یا از کار بیفتد، Kubernetes به طور خودکار تلاش می‌کند که Pod جدیدی برای تکمیل کار راه‌اندازی کند.
• امکان تنظیم تعداد تکرارها: شما می‌توانید تنظیم کنید که تعداد مشخصی از Podها برای انجام وظیفه ایجاد شوند و در صورت شکست، این تعداد تکرار شود.

3. ساختار YAML برای Job

برای ایجاد یک Job، باید از یک فایل YAML استفاده کنید. ساختار آن به این صورت است:

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  template:
    spec:
      containers:
      - name: my-container
        image: ubuntu
        command: ["echo", "Hello, Kubernetes!"]
      restartPolicy: Never
  backoffLimit: 4

در این فایل:

• apiVersion: batch/v1: تعیین نسخه API برای Jobها.
• kind: Job: نوع منبع به صورت Job.
• metadata: اطلاعات مربوط به Job مانند نام آن.
• spec: تنظیمات مربوط به Job.
  • template: مشخصات مربوط به Pod که باید اجرا شود.
    • containers: اطلاعات کانتینرهایی که باید اجرا شوند.
    • command: دستوری که باید در کانتینر اجرا شود.
  • restartPolicy: Never: به Kubernetes می‌گوید که پس از اتمام یا شکست، Pod نباید دوباره راه‌اندازی شود.
  • backoffLimit: حداکثر تعداد تلاش‌هایی که Kubernetes برای اجرای Job انجام می‌دهد قبل از اعلام شکست.

4. ایجاد Job با استفاده از فایل YAML

برای ایجاد Job با استفاده از فایل YAML، کافی است که فایل را با دستور kubectl apply اجرا کنید:

kubectl apply -f job.yaml

در اینجا:

• job.yaml: نام فایل YAML حاوی تعریف Job.

5. نظارت بر وضعیت Job

برای مشاهده وضعیت Job، از دستور زیر استفاده کنید:

kubectl get jobs

این دستور فهرستی از Jobs های موجود و وضعیت آن‌ها را نمایش می‌دهد.

برای مشاهده جزئیات بیشتر و بررسی وضعیت تکمیل شدن کار:

kubectl describe job my-job

6. مدیریت تکرار و خطاها

با استفاده از گزینه‌های backoffLimit و completions در spec، می‌توانید مدیریت دقیقی بر تکرار Jobها و نحوه برخورد با خطاها داشته باشید.

• backoffLimit: حداکثر تعداد تلاش‌ها برای راه‌اندازی مجدد Podهای Job در صورت شکست.
• completions: تعداد کل موفقیت‌های مورد نیاز برای تکمیل Job (مثلاً اگر بخواهید چندین Pod همزمان کارهای مختلف را انجام دهند).

جمع بندی

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

1. ایجاد یک Job با فایل YAML

برای ایجاد یک Job جدید، ابتدا باید یک فایل YAML ایجاد کنید که مشخصات Job را در آن تعریف کنید. ساختار فایل YAML برای Job به صورت زیر است:

apiVersion: batch/v1
kind: Job
metadata:
  name: my-job
spec:
  completions: 1
  parallelism: 1
  template:
    spec:
      containers:
      - name: my-container
        image: ubuntu
        command: ["echo", "Hello, Kubernetes!"]
      restartPolicy: Never

در این فایل:

• apiVersion: batch/v1: تعیین نسخه API که برای ایجاد Job از آن استفاده می‌شود.
• kind: Job: نشان‌دهنده نوع منبع (که در اینجا یک Job است).
• metadata: اطلاعات مرتبط با Job مانند نام آن.
• spec: تنظیمات مربوط به Job که شامل:
  • completions: تعداد کل دفعاتی که باید Job تکمیل شود (در اینجا فقط یک بار).
  • parallelism: تعداد Podهایی که همزمان باید برای اجرای Job اجرا شوند.
  • template: مشخصات Pod که شامل کانتینرها و دستوراتی است که باید اجرا شوند.
  • restartPolicy: Never: مشخص می‌کند که Pod نباید دوباره راه‌اندازی شود.

2. ایجاد Job با استفاده از دستور kubectl apply

پس از ایجاد فایل YAML، برای ایجاد Job در Kubernetes از دستور زیر استفاده می‌کنیم:

kubectl apply -f job.yaml

در اینجا:

• job.yaml: فایل YAML حاوی تعریف Job است.

این دستور باعث ایجاد Job در کلاستر Kubernetes می‌شود.

3. مشاهده وضعیت Job

برای مشاهده وضعیت و جزئیات مربوط به Job، از دستور زیر استفاده کنید:

kubectl get jobs

این دستور لیستی از Jobهای موجود در کلاستر را به شما نمایش می‌دهد. برای مشاهده جزئیات بیشتر و وضعیت دقیق یک Job خاص، از دستور زیر استفاده کنید:

kubectl describe job my-job

در اینجا:

• my-job: نام Job که به‌دنبال جزئیات آن هستید.

این دستور اطلاعات دقیق‌تری از جمله تعداد Podهای اجرا شده، تعداد موفقیت‌ها و تعداد شکست‌ها را نمایش می‌دهد.

4. مدیریت Jobها

• حذف Job: اگر Job دیگر به آن نیاز ندارید یا می‌خواهید آن را از کلاستر حذف کنید، از دستور زیر استفاده کنید:

  kubectl delete job my-job
  

  این دستور، Job با نام my-job را از کلاستر حذف می‌کند.

• نظارت بر Podهای Job: اگر می‌خواهید که وضعیت Podهای در حال اجرا که توسط Job راه‌اندازی شده‌اند را بررسی کنید، از دستور زیر استفاده کنید:

  kubectl get pods --selector=job-name=my-job
  

  این دستور فقط Podهای مربوط به my-job را نمایش می‌دهد.

5. به‌روزرسانی Job

اگر بخواهید Job را به‌روزرسانی کنید (مثلاً تغییر در دستور یا تصویر کانتینر)، باید فایل YAML مربوطه را ویرایش کنید و سپس آن را دوباره اعمال کنید:

kubectl apply -f job.yaml

کلاستر Kubernetes به‌طور خودکار تغییرات جدید را اعمال می‌کند.

جمع بندی

با استفاده از فایل‌های YAML، می‌توانید Jobهای خود را به راحتی در Kubernetes تعریف و مدیریت کنید. فایل YAML به شما این امکان را می‌دهد که تمام تنظیمات مربوط به Job را مانند تعداد تکرارها، تعداد Podهای همزمان و دستوراتی که باید اجرا شوند، تنظیم کنید. با استفاده از دستورات kubectl apply، kubectl get jobs، و kubectl describe job می‌توانید مدیریت کامل بر Jobها داشته باشید و از امکانات قدرتمند Kubernetes بهره‌برداری کنید.

ساختار CronJob در Kubernetes

CronJob در Kubernetes با استفاده از یک فایل YAML مشابه با Jobs تعریف می‌شود. تفاوت اصلی در آن است که در CronJob، شما زمان‌بندی اجرای Job را مشخص می‌کنید.

1. ساختار یک فایل YAML برای CronJob

در زیر یک مثال از فایل YAML برای ایجاد یک CronJob آورده شده است:

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "0 0 * * *"  # زمان‌بندی اجرای CronJob (هر شب ساعت 12 شب)
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: ubuntu
            command: ["echo", "Hello, Kubernetes!"]
          restartPolicy: OnFailure

در این فایل:

• apiVersion: batch/v1: نسخه API برای تعریف CronJob.
• kind: CronJob: نوع منبع که به Kubernetes می‌گوید که این یک CronJob است.
• metadata: شامل اطلاعات متا مانند نام CronJob.
• schedule: زمان‌بندی اجرای CronJob که مطابق با فرمت Cron است. در اینجا، این تنظیمات باعث می‌شود که CronJob هر شب در ساعت 12 شب اجرا شود.
• jobTemplate: شامل مشخصات Job که توسط CronJob اجرا می‌شود. مشابه Job معمولی، شما باید Podهایی را که می‌خواهید اجرا کنید، تعریف کنید.
  • restartPolicy: OnFailure: تعیین می‌کند که اگر Job شکست بخورد، Pod دوباره راه‌اندازی شود.

2. زمان‌بندی‌های مختلف در CronJob

فرمت زمان‌بندی Cron شامل پنج فیلد است:

* * * * *  <command-to-be-executed>
- - - - -
| | | | |
| | | | +--- روز هفته (0 - 6) (یکشنبه = 0)
| | | +----- ماه (1 - 12)
| | +------- روز ماه (1 - 31)
| +--------- ساعت (0 - 23)
+----------- دقیقه (0 - 59)

مثال‌ها:

• "0 0 * * *": این زمان‌بندی، Job را هر روز در ساعت 12 شب اجرا می‌کند.
• "*/5 * * * *": این زمان‌بندی، Job را هر 5 دقیقه یک‌بار اجرا می‌کند.
• "0 9 * * 1": این زمان‌بندی، Job را هر هفته در ساعت 9 صبح روز دوشنبه اجرا می‌کند.

3. ایجاد CronJob با استفاده از دستور kubectl apply

پس از ایجاد فایل YAML، برای ایجاد CronJob در Kubernetes، از دستور زیر استفاده می‌کنید:

kubectl apply -f cronjob.yaml

در اینجا:

• cronjob.yaml: فایل YAML حاوی تعریف CronJob شما.

4. مشاهده وضعیت CronJobs

برای مشاهده وضعیت CronJobها و اینکه چه زمان‌هایی در حال اجرا هستند، از دستور زیر استفاده کنید:

kubectl get cronjobs

این دستور لیستی از CronJobهای موجود در کلاستر را نمایش می‌دهد.

5. مشاهده Jobs ایجاد شده توسط CronJob

CronJob به‌طور خودکار Jobs را در زمان‌های تعیین‌شده ایجاد می‌کند. برای مشاهده Jobهای ایجاد شده توسط یک CronJob خاص، از دستور زیر استفاده کنید:

kubectl get jobs --selector=job-name=my-cronjob

6. حذف CronJob

برای حذف یک CronJob از کلاستر Kubernetes، می‌توانید از دستور زیر استفاده کنید:

kubectl delete cronjob my-cronjob

این دستور CronJob به نام my-cronjob را از کلاستر حذف می‌کند.

جمع بندی

CronJobs در Kubernetes به شما این امکان را می‌دهند که وظایف خاصی را به‌طور منظم و زمان‌بندی شده اجرا کنید. این ویژگی مشابه Cron در سیستم‌عامل‌های لینوکس است و برای وظایفی مانند پشتیبان‌گیری و نظارت بسیار مفید است. با استفاده از فایل‌های YAML و دستوراتی مانند kubectl apply، kubectl get cronjobs و kubectl delete cronjob می‌توانید CronJobهای خود را به راحتی مدیریت کنید و زمان‌بندی دقیق برای انجام وظایف مختلف تنظیم کنید.

برای ایجاد یک CronJob در Kubernetes، شما نیاز به استفاده از فرمت YAML دارید که شامل تنظیمات زمان‌بندی، الگوهای Job و مشخصات کانتینرها است.

ساختار کلی CronJob

apiVersion: batch/v1
kind: CronJob
metadata:
  name: <cronjob-name>
spec:
  schedule: "<cron-schedule>"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: <container-name>
            image: <container-image>
            command: [<command>]
          restartPolicy: OnFailure

• apiVersion: نسخه API برای تعریف CronJob.
• kind: نوع منبع که در اینجا CronJob است.
• metadata: اطلاعات مربوط به منبع مانند نام CronJob.
• spec: مشخصات CronJob که شامل زمان‌بندی و الگوی Job است.
  • schedule: زمان‌بندی اجرای CronJob (فرمت مشابه با Cron در لینوکس).
  • jobTemplate: تعریف الگو و ویژگی‌های Job که توسط CronJob اجرا می‌شود.

مثال‌های کاربردی

1. اجرای یک Job هر روز در ساعت 12 شب

در این مثال، یک CronJob ساخته می‌شود که هر روز ساعت 12 شب یک Job اجرا می‌کند. این Job یک پیام ساده چاپ می‌کند.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: daily-job
spec:
  schedule: "0 0 * * *"  # هر روز ساعت 12 شب
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello-container
            image: ubuntu
            command: ["echo", "Good night, Kubernetes!"]
          restartPolicy: OnFailure

در اینجا:

• schedule: "0 0 * * *": زمان‌بندی اجرای Job که هر روز ساعت 12 شب است.
• command: ["echo", "Good night, Kubernetes!"]: دستوری که در کانتینر اجرا می‌شود، در اینجا پیام “Good night, Kubernetes!” چاپ می‌شود.
• restartPolicy: OnFailure: اگر Job شکست بخورد، کانتینر دوباره راه‌اندازی می‌شود.

2. اجرای یک Job هر 5 دقیقه یک‌بار

در این مثال، CronJob به‌طور دوره‌ای هر 5 دقیقه یک‌بار اجرا می‌شود و یک پیام ساده چاپ می‌کند.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: every-5-minutes-job
spec:
  schedule: "*/5 * * * *"  # هر 5 دقیقه یک‌بار
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello-container
            image: ubuntu
            command: ["echo", "This job runs every 5 minutes."]
          restartPolicy: OnFailure

در اینجا:

• schedule: "*/5 * * * *": زمان‌بندی که باعث می‌شود Job هر 5 دقیقه یک‌بار اجرا شود.
• command: ["echo", "This job runs every 5 minutes."]: دستوری که در کانتینر اجرا می‌شود و پیامی را چاپ می‌کند.

3. اجرای یک Job هر دوشنبه ساعت 9 صبح

در این مثال، CronJob یک‌بار در هفته، در ساعت 9 صبح روز دوشنبه اجرا می‌شود و یک پیام ساده چاپ می‌کند.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: weekly-job
spec:
  schedule: "0 9 * * 1"  # هر دوشنبه ساعت 9 صبح
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello-container
            image: ubuntu
            command: ["echo", "Happy Monday, Kubernetes!"]
          restartPolicy: OnFailure

در اینجا:

• schedule: "0 9 * * 1": زمان‌بندی که Job را هر دوشنبه ساعت 9 صبح اجرا می‌کند.
• command: ["echo", "Happy Monday, Kubernetes!"]: دستوری که پیامی را در کانتینر چاپ می‌کند.

4. اجرای Job در یک روز خاص از ماه

در این مثال، CronJob هر ماه در روز 15، ساعت 10 صبح اجرا می‌شود.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: monthly-job
spec:
  schedule: "0 10 15 * *"  # هر ماه در روز 15 ساعت 10 صبح
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello-container
            image: ubuntu
            command: ["echo", "Running monthly job."]
          restartPolicy: OnFailure

در اینجا:

• schedule: "0 10 15 * *": زمان‌بندی که باعث می‌شود Job هر ماه در روز 15 ساعت 10 صبح اجرا شود.
• command: ["echo", "Running monthly job."]: دستوری که پیامی را در کانتینر چاپ می‌کند.

جمع بندی

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

ConfigMap می‌تواند شامل متغیرهای محیطی، فایل‌های پیکربندی، دستورالعمل‌های خط فرمان و دیگر اطلاعات تنظیماتی باشد که برنامه‌ها به آن‌ها نیاز دارند. این اطلاعات را می‌توان از طریق Volumes یا متغیرهای محیطی به کانتینرها تزریق کرد.

کاربردهای ConfigMap

1. جداسازی پیکربندی از کد: با استفاده از ConfigMap، می‌توانید تنظیمات و پیکربندی‌های مورد نیاز برنامه‌ها را از کد آن‌ها جدا کنید. این امر باعث می‌شود که کد برنامه نیاز به تغییرات نداشته باشد و تنها پیکربندی‌ها به‌روز شوند.
2. قابلیت به‌روزرسانی پیکربندی بدون نیاز به تغییرات کد: ConfigMap به شما این امکان را می‌دهد که تنها با تغییر تنظیمات پیکربندی، برنامه‌ها را به‌روز کنید.
3. مدیریت مقیاس‌پذیری: در صورتی که نیاز باشد تعداد زیادی از Pods یا کانتینرها پیکربندی مشابهی را داشته باشند، می‌توان ConfigMap را یک‌بار ایجاد کرد و آن را در تمام Pods استفاده نمود.
4. قابلیت انتقال تنظیمات به دیگر سیستم‌ها: می‌توانید ConfigMap را برای پیکربندی‌های مشابه در سیستم‌های مختلف استفاده کنید.

ساختار یک ConfigMap

یک ConfigMap را می‌توان به روش‌های مختلفی تعریف کرد: به‌صورت مستقیم در فایل YAML، از طریق kubectl، یا با استفاده از پیکربندی‌های فایل.

تعریف ConfigMap در فایل YAML

apiVersion: v1
kind: ConfigMap
metadata:
  name: example-config
data:
  config_key_1: value_1
  config_key_2: value_2

• apiVersion: نسخه API برای استفاده از ConfigMap.
• kind: نوع منبع که در اینجا ConfigMap است.
• metadata: اطلاعات مربوط به منبع مانند نام ConfigMap.
• data: حاوی کلیدها و مقادیر تنظیمات.

جمع بندی

ConfigMap به شما این امکان را می‌دهد تا پیکربندی‌ها و تنظیمات را به‌صورت مجزا از کد برنامه مدیریت کنید و از طریق Kubernetes آن‌ها را به کانتینرها تزریق کنید. این جداسازی باعث ساده‌تر شدن فرآیند مدیریت و به‌روزرسانی برنامه‌ها می‌شود و قابلیت مقیاس‌پذیری و انعطاف‌پذیری بیشتری را فراهم می‌آورد.

ایجاد یک ConfigMap

برای ایجاد ConfigMap می‌توانید از فایل YAML استفاده کنید یا با استفاده از دستور kubectl create configmap این کار را انجام دهید.

1. ساخت ConfigMap از فایل YAML

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  DATABASE_URL: "postgres://db:5432/mydatabase"
  LOG_LEVEL: "debug"
  MAX_RETRIES: "5"

در این فایل YAML، پیکربندی‌های مختلف مانند DATABASE_URL، LOG_LEVEL، و MAX_RETRIES به صورت کلید و مقدار در بخش data تعریف شده‌اند.

برای ایجاد ConfigMap با این فایل YAML، دستور زیر را اجرا کنید:

kubectl apply -f configmap.yaml

2. ساخت ConfigMap با استفاده از kubectl

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

kubectl create configmap app-config \
  --from-literal=DATABASE_URL="postgres://db:5432/mydatabase" \
  --from-literal=LOG_LEVEL="debug" \
  --from-literal=MAX_RETRIES="5"

استفاده از ConfigMap در Pod

بعد از اینکه ConfigMap را ایجاد کردید، می‌توانید آن را در یک Pod برای تنظیمات پیکربندی استفاده کنید. می‌توانید پیکربندی‌ها را به‌صورت متغیرهای محیطی یا Volume به کانتینرها تزریق کنید.

1. استفاده از ConfigMap به‌عنوان متغیر محیطی

در این روش، مقادیر پیکربندی به‌صورت متغیرهای محیطی به کانتینرها داده می‌شوند.

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app-container
    image: my-app-image
    envFrom:
    - configMapRef:
        name: app-config

در این پیکربندی YAML، ConfigMap به‌طور کامل به‌عنوان متغیر محیطی به کانتینر تزریق می‌شود.

2. استفاده از ConfigMap به‌عنوان Volume

در این روش، پیکربندی‌ها به‌عنوان فایل‌های موجود در Volume به کانتینرها تزریق می‌شوند.

apiVersion: v1
kind: Pod
metadata:
  name: app-pod
spec:
  containers:
  - name: app-container
    image: my-app-image
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: app-config

در این پیکربندی، ConfigMap به‌عنوان یک Volume به Pod متصل می‌شود و محتوای آن در دایرکتوری /etc/config در کانتینر قرار می‌گیرد.

جمع بندی

با استفاده از ConfigMap، می‌توان پیکربندی‌های غیرحساس را از کد برنامه جدا کرده و آن‌ها را به صورت متمرکز مدیریت کرد. این روش باعث ساده‌تر شدن فرآیند به‌روزرسانی و مقیاس‌پذیری می‌شود و به راحتی می‌توان پیکربندی‌های مختلف را به Pods و کانتینرها تزریق کرد. ConfigMap‌ها برای پیکربندی‌هایی که نیاز به امنیت ندارند، ایده‌آل هستند و در بسیاری از سناریوهای عملیاتی Kubernetes استفاده می‌شوند.

به‌طور پیش‌فرض، Kubernetes Secrets را به‌صورت رمزگذاری‌شده ذخیره می‌کند تا از افشای تصادفی اطلاعات جلوگیری شود. همچنین، می‌توان از Secrets به‌صورت متغیرهای محیطی یا Volume در Pods استفاده کرد.

انواع Secrets

1. Opaque Secret: این نوع Secret، داده‌های عمومی مانند رمزعبور و اطلاعات مشابه را در قالب کلید/مقدار ذخیره می‌کند.
2. docker-registry Secret: برای ذخیره اطلاعات مربوط به احراز هویت در هنگام دسترسی به Docker Registry مورد استفاده قرار می‌گیرد.
3. tls Secret: برای ذخیره گواهینامه‌های TLS و کلید خصوصی استفاده می‌شود.

ایجاد یک Secret

Secrets را می‌توان به‌طور مستقیم از طریق خط فرمان یا با استفاده از فایل‌های YAML ایجاد کرد.

1. ساخت Secret با استفاده از خط فرمان
   برای ایجاد یک Secret از خط فرمان می‌توانید از دستور kubectl create secret استفاده کنید. به عنوان مثال:

kubectl create secret generic my-secret \
  --from-literal=DB_PASSWORD="supersecretpassword" \
  --from-literal=API_KEY="abcdef123456"

در این دستور، یک Secret به نام my-secret ایجاد می‌شود که شامل دو کلید DB_PASSWORD و API_KEY است.

2. ساخت Secret از فایل YAML

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  DB_PASSWORD: c3VwZXJzZWNyZXRwYXNzd29yZA==  # Base64 encoded value
  API_KEY: YWJjZGVmMTIzNDU2  # Base64 encoded value

در این فایل YAML، مقادیر اطلاعات حساس باید به‌صورت Base64 رمزگذاری شوند. برای رمزگذاری متن به Base64 می‌توانید از دستور زیر استفاده کنید:

echo -n "supersecretpassword" | base64

برای ایجاد Secret از این فایل YAML، از دستور زیر استفاده کنید:

kubectl apply -f secret.yaml

استفاده از Secrets در Pods

بعد از ایجاد Secret، می‌توانید از آن در Pods استفاده کنید. Secrets می‌توانند به‌عنوان متغیرهای محیطی یا Volume به Pods تزریق شوند.

1. استفاده از Secret به‌عنوان متغیر محیطی

در این روش، اطلاعات حساس به‌عنوان متغیرهای محیطی به کانتینرها داده می‌شود.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: DB_PASSWORD

در این پیکربندی، Secret my-secret به‌عنوان متغیر محیطی DB_PASSWORD به کانتینر تزریق می‌شود.

2. استفاده از Secret به‌عنوان Volume

در این روش، اطلاعات حساس به‌عنوان فایل‌های موجود در Volume به کانتینر تزریق می‌شود.

apiVersion: v1
kind: Pod
metadata:
  name: my-app-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secrets
  volumes:
  - name: secret-volume
    secret:
      secretName: my-secret

در این پیکربندی، Secret my-secret به‌عنوان Volume به Pod متصل می‌شود و محتوای آن به‌عنوان فایل‌های موجود در /etc/secrets در کانتینر قرار می‌گیرد.

جمع بندی

Secrets ابزار مهمی در Kubernetes هستند که برای ذخیره و مدیریت اطلاعات حساس مانند رمزعبور، کلیدها، و گواهینامه‌ها استفاده می‌شوند. با استفاده از Secrets، می‌توانید از اطلاعات حساس به‌صورت ایمن در Pods استفاده کنید و از افشای تصادفی آن‌ها جلوگیری کنید. همچنین، Secrets به شما این امکان را می‌دهند که پیکربندی‌های حساس را از کد برنامه جدا کرده و به‌صورت متمرکز مدیریت کنید.

متغیرهای محیطی

در Kubernetes می‌توان از ConfigMaps و Secrets به‌عنوان متغیرهای محیطی برای کانتینرها استفاده کرد. این روش به کانتینر این امکان را می‌دهد که پیکربندی‌ها یا اطلاعات حساس را از منابع خارجی دریافت کند بدون آنکه نیاز به تغییر کد برنامه باشد.

1. اتصال ConfigMap به‌عنوان متغیر محیطی

در این روش، مقادیر موجود در یک ConfigMap به‌عنوان متغیرهای محیطی در کانتینرها قرار می‌گیرند. برای این کار باید از بخش envFrom یا env در فایل YAML Pod استفاده کنید.

• مثال اتصال ConfigMap به‌عنوان متغیر محیطی:

apiVersion: v1
kind: Pod
metadata:
  name: my-configmap-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    envFrom:
    - configMapRef:
        name: my-configmap

در این پیکربندی، تمامی داده‌های موجود در ConfigMap با نام my-configmap به‌عنوان متغیرهای محیطی در کانتینر my-app-container قرار می‌گیرند.

2. اتصال Secret به‌عنوان متغیر محیطی

همانند ConfigMap، می‌توانید از Secrets به‌عنوان متغیر محیطی در کانتینرها استفاده کنید. این کار برای ذخیره اطلاعات حساس مانند رمزعبور، کلیدها و گواهینامه‌ها مفید است.

• مثال اتصال Secret به‌عنوان متغیر محیطی:

apiVersion: v1
kind: Pod
metadata:
  name: my-secret-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    env:
    - name: DB_PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: DB_PASSWORD

در این مثال، Secret با نام my-secret و کلید DB_PASSWORD به‌عنوان متغیر محیطی به کانتینر my-app-container تزریق می‌شود.

فایل‌های Mount شده

ConfigMaps و Secrets همچنین می‌توانند به‌عنوان Volume در Pods استفاده شوند تا داده‌ها به‌صورت فایل در کانتینرها قرار بگیرند. این روش بیشتر زمانی مفید است که می‌خواهید اطلاعات از یک منبع خارجی به‌صورت فایل در کانتینر در دسترس باشد.

1. اتصال ConfigMap به‌عنوان Volume

برای استفاده از ConfigMap به‌عنوان فایل در کانتینر، می‌توانید آن را به‌عنوان یک Volume Mount کنید. در این حالت، ConfigMap به‌عنوان فایل‌های متنی در مسیر مشخص‌شده در کانتینر در دسترس خواهد بود.

• مثال اتصال ConfigMap به‌عنوان Volume:

apiVersion: v1
kind: Pod
metadata:
  name: my-configmap-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    volumeMounts:
    - name: config-volume
      mountPath: /etc/config
  volumes:
  - name: config-volume
    configMap:
      name: my-configmap

در این مثال، ConfigMap با نام my-configmap به‌عنوان Volume در مسیر /etc/config در کانتینر my-app-container Mount می‌شود. این داده‌ها به‌صورت فایل در دسترس خواهند بود.

2. اتصال Secret به‌عنوان Volume

مانند ConfigMap، می‌توان از Secrets به‌عنوان Volume برای نگهداری اطلاعات حساس به‌صورت فایل استفاده کرد. این روش برای ذخیره‌سازی داده‌هایی مانند کلیدهای خصوصی، گواهینامه‌ها و رمزعبور بسیار مناسب است.

• مثال اتصال Secret به‌عنوان Volume:

apiVersion: v1
kind: Pod
metadata:
  name: my-secret-pod
spec:
  containers:
  - name: my-app-container
    image: my-app-image
    volumeMounts:
    - name: secret-volume
      mountPath: /etc/secrets
  volumes:
  - name: secret-volume
    secret:
      secretName: my-secret

در این پیکربندی، Secret با نام my-secret به‌عنوان Volume در مسیر /etc/secrets در کانتینر my-app-container Mount می‌شود. محتویات Secret به‌صورت فایل‌های موجود در این مسیر قابل دسترسی خواهند بود.

جمع بندی

با استفاده از ConfigMaps و Secrets در Kubernetes می‌توان پیکربندی‌ها و اطلاعات حساس را به‌صورت متغیرهای محیطی یا فایل‌های Mount شده به کانتینرها تزریق کرد. این روش‌ها کمک می‌کنند که پیکربندی‌ها به‌صورت متمرکز و ایمن مدیریت شوند و همچنین تغییرات بدون نیاز به تغییر در کد برنامه‌نویسی اعمال گردند.

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

پشتیبانی دائمی و در لحظه:
تیم ما همواره آماده پاسخگویی به سوالات شماست. هدف ما این است که شما با خیالی آسوده بتوانید مهارت‌های خود را به کار بگیرید و پروژه‌های واقعی را با اعتماد به نفس کامل انجام دهید.

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

حرف آخر

با ما همراه باشید تا نه تنها به مشکلات شما پاسخ دهیم، بلکه در مسیر یادگیری و پیشرفت حرفه‌ای، شما را پشتیبانی کنیم. هدف ما این است که شما به یک متخصص حرفه‌ای و قابل‌اعتماد تبدیل شوید و بتوانید با اطمینان پروژه‌های واقعی را بپذیرید و انجام دهید.

📩 اگر سوالی دارید یا به مشکلی برخوردید، همین حالا مطرح کنید!
ما در کوتاه‌ترین زمان ممکن پاسخ شما را ارائه خواهیم داد. 🙌