دانلود کتاب آموزشی Certified Kubernetes Application Developer (CKAD) جلد اول

[cdb_course_lessons title=”بخش 1. مبانی Kubernetes”][cdb_course_lesson title=”فصل 1. معرفی Kubernetes و معماری آن”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تاریخچه Kubernetes و منشأ آن (Google و CNCF)” subtitle=”توضيحات کامل”]Kubernetes که به اختصار K8s نامیده می‌شود، یکی از محبوب‌ترین پلتفرم‌های مدیریت کانتینرها است. این پروژه در ابتدا توسط Google توسعه یافت و سپس به بنیاد Cloud Native Computing Foundation (CNCF) سپرده شد. Kubernetes تحول بزرگی در مدیریت و Orchestration کانتینرها ایجاد کرد و امروزه استانداردی در دنیای Cloud-Native محسوب می‌شود.

---

۱. منشأ 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 در سراسر جهان است![/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفهوم Orchestration در مدیریت کانتینرها” subtitle=”توضيحات کامل”]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Orchestrator	ویژگی‌ها	نقاط ضعف
Docker Swarm	راه‌اندازی آسان، ادغام با Docker	امکانات کمتر از Kubernetes
Apache Mesos	مقیاس‌پذیری بالا، مناسب برای Big Data	پیچیدگی زیاد
Nomad (HashiCorp)	پشتیبانی از انواع Workloadها	عدم پشتیبانی شبکه‌ای پیشرفته
Kubernetes	انعطاف‌پذیری، مقیاس‌پذیری بالا	پیچیدگی در راه‌اندازی اولیه

۴. 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 آماده می‌کند!

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مزایا و کاربردهای Kubernetes در دنیای Cloud-Native” subtitle=”توضيحات کامل”]Kubernetes به عنوان محبوب‌ترین پلتفرم Orchestration کانتینرها، نقش کلیدی در دنیای Cloud-Native ایفا می‌کند. این فناوری امکان مدیریت، مقیاس‌پذیری و استقرار خودکار برنامه‌های مبتنی بر کانتینر را فراهم می‌کند و با ارائه قابلیت‌های متنوع، توسعه‌دهندگان و تیم‌های DevOps را قادر می‌سازد تا برنامه‌های پایدار، انعطاف‌پذیر و کارآمد را پیاده‌سازی کنند.

---

۱. مزایای 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![/cdb_course_lesson][cdb_course_lesson title=”فصل 2. درک نقش و عملکرد Master Node و Worker Nodes”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تفاوت میان Master Node و Worker Node” subtitle=”توضيحات کامل”]در Kubernetes، مفهوم Node نقش اساسی در معماری و اجرای برنامه‌ها دارد. Node‌ها در واقع ماشین‌هایی هستند که برای اجرای منابع مختلف Kubernetes استفاده می‌شوند. این منابع می‌توانند شامل Pods، Containers و سایر اجزای سیستم باشند. دو نوع اصلی Node در Kubernetes وجود دارد: Master Node و Worker Node. درک تفاوت‌های این دو نوع Node برای مدیریت صحیح کلاستر و اطمینان از عملکرد بهینه آن ضروری است.

---

۱. 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
وظیفه اصلی	مدیریت و کنترل کلاستر و منابع	اجرای Pods و کانتینرها
اجزای مهم	API Server، Controller Manager، Scheduler، etcd	Kubelet، Kube Proxy، Container Runtime
دسترسی به منابع	دسترسی کامل به وضعیت کلاستر و اطلاعات منابع	دسترسی به اطلاعات مربوط به Pods و کانتینرها
نظارت و کنترل	نظارت و مدیریت کلی وضعیت کلاستر و منابع	اجرای فرآیندها طبق دستورهای صادر شده از Master Node
پاسخ‌دهی به درخواست‌ها	دریافت درخواست‌ها و ارسال آنها به اجزای مختلف سیستم	فقط به دستورهای صادر شده از Master Node پاسخ می‌دهد

---

جمع‌بندی

Master Node و Worker Node در Kubernetes وظایف متفاوتی دارند که مکمل یکدیگر هستند. در حالی که Master Node به مدیریت و نظارت کلی کلاستر می‌پردازد، Worker Node‌ها به عنوان محل اجرایی برنامه‌ها و کانتینرها عمل می‌کنند. برای عملکرد بهینه کلاستر، همکاری میان این دو نوع Node ضروری است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”وظایف Master Node در مدیریت کلاستر” subtitle=”توضيحات کامل”]Master Node در Kubernetes نقش حیاتی در مدیریت و کنترل کلاستر دارد. تمامی فرآیندهای کلیدی که مربوط به نظارت، هماهنگی و مدیریت منابع کلاستر هستند، توسط Master 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 به انجام وظایف خود در مدیریت کلاستر پرداخته و تضمین می‌کند که تمامی منابع به درستی و با کارایی بالا عمل کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”وظایف Worker Node در اجرای Pods” subtitle=”توضيحات کامل”]Worker Node‌ها در Kubernetes وظیفه اصلی اجرای واقعی کانتینرها را در کلاستر بر عهده دارند. این نودها بخشی از منابع فیزیکی یا مجازی سیستم را تخصیص داده و مسئول اجرای Pods و سرویس‌های مختلف هستند که توسط Master Node مدیریت می‌شوند. هر Worker 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‌ها نقش کلیدی در عملیات روزمره برنامه‌ها در کلاستر دارند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. آشنایی با اجزای اصلی Kubernetes”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”API Server” subtitle=”توضيحات کامل”]در Kubernetes، API Server به‌عنوان دروازه اصلی برای تمامی تعاملات بین کاربران و کلاستر عمل می‌کند. تمامی درخواست‌ها و دستورات ارسال‌شده از طرف کاربران، سیستم‌ها و اجزای دیگر کلاستر، ابتدا باید از این مسیر عبور کنند تا در نهایت به سیستم مقصد برسند. این جزء حیاتی، به‌عنوان مرکزی‌ترین نقطه برای مدیریت و کنترل درخواست‌های کلاستر شناخته می‌شود.

---

نحوه کار 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 با این اجزا به‌طور مستقیم بر عملکرد کلی کلاستر تاثیر می‌گذارد و هماهنگی بین آن‌ها برای حفظ وضعیت پایدار و کارآمد کلاستر ضروری است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”etcd” subtitle=”توضيحات کامل”]etcd یک پایگاه داده توزیع‌شده و کلید-مقدار است که به‌طور خاص برای ذخیره‌سازی و هماهنگی اطلاعات در سیستم‌های توزیع‌شده طراحی شده است. این پایگاه داده در Kubernetes به‌عنوان یک ذخیره‌ساز وضعیت مرکزی برای کلاستر عمل می‌کند و اطلاعات مهم مربوط به وضعیت منابع و تنظیمات مختلف را ذخیره می‌کند.

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 محسوب می‌شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”Controller Manager” subtitle=”توضيحات کامل”]Controller Manager یکی از اجزای حیاتی در معماری Kubernetes است که به‌طور مداوم وضعیت منابع مختلف کلاستر را نظارت کرده و در صورت لزوم آن‌ها را به‌روزرسانی یا اصلاح می‌کند. این بخش از Kubernetes وظیفه مدیریت و اجرای کنترلرهای مختلف را بر عهده دارد. هر کنترلر در Controller Manager مسئول نظارت و هماهنگی وضعیت یک منبع خاص در کلاستر است و در صورت مشاهده انحراف از وضعیت مطلوب، اقداماتی برای اصلاح آن انجام می‌دهد.

---

مدیریت کنترلرها برای اجرای منابع 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 ابزار کلیدی برای حفظ وضعیت مطلوب و پایداری منابع است. با استفاده از کنترلرهای مختلف، این اجزا وظیفه نظارت و اصلاح وضعیت منابع کلاستر را به‌طور خودکار انجام می‌دهند. این مدیریت خودکار منابع در کنار مقیاس‌پذیری و افزونگی موجود در کلاستر، باعث افزایش پایداری و بهینه‌سازی عملکرد کلاستر می‌شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”Scheduler” subtitle=”توضيحات کامل”]در کوبرنتیز، Scheduler یکی از اجزای حیاتی است که مسئول تخصیص منابع به Pods در نودهای مختلف کلاستر است. این کنترلر به‌طور مستقیم تأثیر زیادی بر عملکرد، مقیاس‌پذیری، و استفاده بهینه از منابع دارد.

وظیفه 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 روی کدام نود قرار گیرد. این فرآیند، یکی از ارکان اساسی در مدیریت کارآمد کلاستر و مقیاس‌پذیری آن است.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”Kubelet” subtitle=”توضيحات کامل”]

مسئول اجرای کانتینرها روی 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 دارد و از طریق بررسی مداوم وضعیت کانتینرها، به رفع مشکلات و جلوگیری از بروز مشکلات در سطح کلاستر کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”Kube-proxy” subtitle=”توضيحات کامل”]Kube-proxy یکی از اجزای حیاتی در کلاستر Kubernetes است که وظیفه مدیریت ترافیک شبکه‌ای میان Pods و Nodes را بر عهده دارد. این سرویس به عنوان یک پروکسی شبکه در سطح نودها عمل می‌کند و اطمینان حاصل می‌کند که درخواست‌ها به درستی به Pods هدایت می‌شوند.

• 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 مؤثر، عملکرد و مقیاس‌پذیری کلاستر را بهبود می‌بخشد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. آشنایی با مفهوم Namespaces و مدیریت آن‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف Namespace در Kubernetes” subtitle=”توضيحات کامل”]در Kubernetes، Namespace یک مکانیزم منطقی برای جداسازی منابع مختلف در کلاستر است. این امکان را فراهم می‌آورد که منابع مختلف (مانند Pods، Services، و دیگر منابع) را در بخش‌های مختلف تقسیم‌بندی کرده و از آن‌ها به صورت جداگانه استفاده کنیم. به عبارت دیگر، Namespace به کاربران و تیم‌ها اجازه می‌دهد تا منابع و خدمات خود را در یک کلاستر با وضوح و جداسازی بیشتری مدیریت کنند.

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 باعث می‌شود که منابع به طور مؤثرتر و مقیاس‌پذیرتر در کلاستر مدیریت شوند، به ویژه در محیط‌های چند کاربری یا کلاسترهای بزرگ.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مزایای استفاده از Namespaces برای جداسازی منابع” subtitle=”توضيحات کامل”]استفاده از Namespaces در Kubernetes مزایای بسیاری دارد که باعث بهبود مدیریت منابع و افزایش بهره‌وری در محیط‌های پیچیده و مقیاس‌پذیر می‌شود. در اینجا به بررسی مزایای اصلی استفاده از Namespaces برای جداسازی منابع می‌پردازیم.

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 می‌توان به مدیریت منابع تخصیص یافته، محدودیت دسترسی، مقیاس‌پذیری بهتر، و تسهیل در توسعه و تست اشاره کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”دستورات kubectl برای مدیریت Namespaces” subtitle=”توضيحات کامل”]در Kubernetes، برای مدیریت و کار با Namespaces از دستورات مختلفی استفاده می‌شود. این دستورات به شما کمک می‌کنند تا Namespaces را ایجاد، مشاهده، حذف و تغییر دهید. در ادامه، برخی از مهم‌ترین دستورات kubectl برای مدیریت 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 باعث جداسازی منابع و مدیریت بهتر در محیط‌های پیچیده و چند تیمی می‌شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد Namespace با دستور kubectl create namespace” subtitle=”توضيحات کامل”]برای ایجاد یک Namespace جدید در Kubernetes، از دستور kubectl create namespace استفاده می‌شود. این دستور به شما این امکان را می‌دهد که Namespace خاص خود را برای سازماندهی منابع مختلف در کلاستر ایجاد کنید. استفاده از Namespace کمک می‌کند تا منابع جداگانه‌ای برای پروژه‌ها، محیط‌ها یا تیم‌های مختلف داشته باشید.

---

نحوه استفاده از دستور 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 باعث می‌شود که بتوانید منابع مختلف را در کلاستر جداگانه و به‌صورت منطقی مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”حذف Namespace با دستور kubectl delete namespace” subtitle=”توضيحات کامل”]برای حذف یک Namespace در Kubernetes، از دستور kubectl delete namespace استفاده می‌شود. این دستور به شما این امکان را می‌دهد که یک 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، از حذف شدن منابع آن آگاهی داشته باشید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مشاهده Namespaces با دستور kubectl get namespaces” subtitle=”توضيحات کامل”]برای مشاهده لیست تمامی Namespaces موجود در کلاستر Kubernetes، از دستور kubectl get namespaces استفاده می‌شود. این دستور به شما این امکان را می‌دهد که تمامی Namespaces موجود را بررسی کنید و از وضعیت آن‌ها آگاهی یابید.

---

نحوه استفاده از دستور 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 ها باخبر شوید و در صورت نیاز، اقدامات مدیریتی خود را انجام دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از Contexts برای مدیریت Namespaces” subtitle=”توضيحات کامل”]در Kubernetes، Contexts برای مدیریت پیکربندی‌های مختلف کلاستر و منابع آن به کار می‌روند. یک Context ترکیبی از Cluster، User، و Namespace است که به شما این امکان را می‌دهد که به راحتی میان کلاسترها و Namespaces مختلف جابجا شوید. به عبارت دیگر، با استفاده از Context می‌توانید به طور موثری از یک Namespace خاص در هر کلاستر کار کنید بدون اینکه مجبور باشید هر بار نام 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 مختلف دارند، بسیار مفید و کارآمد است.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 2. طراحی و پیاده‌سازی برنامه‌های کاربردی”][cdb_course_lesson title=”فصل 1. ایجاد و مدیریت Pods”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف مفهوم Pod به عنوان کوچک‌ترین واحد قابل مدیریت در Kubernetes” subtitle=”توضيحات کامل”]در کوبرنتیز، Pod کوچک‌ترین واحدی است که می‌توان آن را در کلاستر ایجاد، مدیریت و مقیاس‌گذاری کرد. هر Pod می‌تواند شامل یک یا چند Container باشد که همه آن‌ها از منابع مشترک مانند شبکه و فضای ذخیره‌سازی استفاده می‌کنند.

یک 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 باشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد یک Pod با استفاده از فایل YAML” subtitle=”توضيحات کامل”]در Kubernetes، یکی از بهترین روش‌ها برای تعریف و ایجاد منابع مختلف مانند Pod، استفاده از فایل‌های YAML است. این فایل‌ها به شما این امکان را می‌دهند که پیکربندی دقیق و قابل تنظیمی را برای منابع خود بنویسید و سپس آن‌ها را به سادگی در کلاستر خود اعمال کنید.

در این بخش، شما یاد خواهید گرفت که چگونه یک 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ها را مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی وضعیت یک Pod با استفاده از دستورات kubectl get pods و kubectl describe pod” subtitle=”توضيحات کامل”]برای مدیریت و نظارت بر وضعیت Podها در Kubernetes، از دستورات مختلف kubectl استفاده می‌شود. در این بخش، دو دستور اصلی برای بررسی وضعیت یک Pod معرفی می‌شوند: kubectl get pods و kubectl describe 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 هستند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مدیریت Pods در Kubernetes: حذف، به‌روزرسانی و بررسی وضعیت” subtitle=”توضيحات کامل”]در Kubernetes، مدیریت Podها جزء کارهای اصلی در فرآیند مدیریت کلاستر است. این مدیریت شامل حذف Podها، به‌روزرسانی آنها، و بررسی وضعیت آنها می‌شود. در ادامه، توضیحاتی در مورد هر کدام از این عملیات به همراه دستورات مرتبط آورده شده است.

---

حذف 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ها را مدیریت کرده و وضعیت کلاستر خود را به‌طور دقیق پیگیری کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. کار با Multi-Container Pods”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”معرفی Pods چند کانتینری و مزایای آن‌ها” subtitle=”توضيحات کامل”]در Kubernetes، یک Pod می‌تواند شامل یک یا چند کانتینر باشد که در یک Node و در همان فضای شبکه به اشتراک گذاشته می‌شوند. Pods چند کانتینری به این معنی است که چند کانتینر مختلف می‌توانند در یک 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 به شما این امکان را می‌دهند که چند کانتینر با وظایف مختلف را در یک محیط مشترک اجرا کنید و مزایای زیادی از جمله ارتباط نزدیک، اشتراک منابع، و مدیریت ساده‌تر بدست آورید. این نوع طراحی، به ویژه در مواقعی که کانتینرها نیاز به همکاری دارند، می‌تواند یک معماری مؤثر و مقیاس‌پذیر باشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیاده‌سازی الگوهای طراحی در Kubernetes” subtitle=”توضيحات کامل”]در Kubernetes، می‌توان از الگوهای طراحی مختلفی برای مدیریت Pods چند کانتینری استفاده کرد. این الگوها به شما کمک می‌کنند تا معماری‌های مقیاس‌پذیر، قابل نگهداری و مدیریت‌پذیر بسازید. در اینجا به سه الگوی طراحی رایج پرداخته می‌شود: Sidecar Pattern، Ambassador Pattern و Adapter Pattern.

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 به شما این امکان را می‌دهند که پیچیدگی‌های مختلف را به شکل مؤثری مدیریت کنید. با استفاده از این الگوها می‌توانید سرویس‌ها و کانتینرهای خود را به صورت مؤثری مدیریت کرده و قابلیت‌های اضافی مانند لاگ‌گیری، نظارت، پروکسی کردن ترافیک و تبدیل فرمت داده‌ها را به سادگی پیاده‌سازی کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف و ایجاد Multi-Container Pods با YAML” subtitle=”توضيحات کامل”]در کوبرنتیز، Multi-Container Pods به Pods اطلاق می‌شود که حاوی بیش از یک کانتینر هستند. این نوع Pods به شما این امکان را می‌دهند که کانتینرهای مختلف را در یک واحد منطقی اجرا کنید. تمامی کانتینرها در داخل یک Pod به اشتراک‌گذاری می‌کنند فضای شبکه و سیستم فایل مشترک، به این معنی که آن‌ها می‌توانند به راحتی از طریق آدرس‌های IP یا نقاط mount مشترک با هم تعامل کنند.

یکی از مزایای استفاده از 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 ضروری است.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. استفاده از Init Containers”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفهوم و مزایای Init Containers” subtitle=”توضيحات کامل”]Init Containers در Kubernetes نوعی کانتینر ویژه هستند که قبل از شروع اجرای کانتینرهای اصلی در Pod اجرا می‌شوند. این کانتینرها معمولاً برای انجام تنظیمات اولیه، بررسی پیش‌نیازها یا آماده‌سازی محیط پیش از آغاز کار کانتینرهای اصلی استفاده می‌شوند.

مفهوم 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، می‌توانید وظایف اولیه را از کانتینرهای اصلی جدا کرده و مشکلات را به سادگی مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از Init Containers برای آماده‌سازی محیط قبل از اجرای کانتینر اصلی” subtitle=”توضيحات کامل”]Init Containers در Kubernetes به شما این امکان را می‌دهند که عملیات ضروری قبل از اجرای کانتینرهای اصلی در Pod را انجام دهید. این کانتینرها برای آماده‌سازی محیط و اطمینان از اینکه شرایط لازم برای اجرای کانتینرهای اصلی فراهم است، مورد استفاده قرار می‌گیرند.

چرا از 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 باعث بهبود انعطاف‌پذیری، کارایی و مدیریت بهتر اپلیکیشن‌ها می‌شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیاده‌سازی Init Containers در فایل‌های YAML و مثال‌های کاربردی” subtitle=”توضيحات کامل”]Init Containers در Kubernetes یک روش بسیار کاربردی برای اجرای وظایف اولیه قبل از شروع اجرای کانتینرهای اصلی هستند. این کانتینرها می‌توانند به شما کمک کنند تا پیش از شروع کانتینرهای اصلی، محیط‌های خاص یا پیش‌نیازهای موردنیاز برنامه‌ها را تنظیم کنید. در این بخش، نحوه پیاده‌سازی Init Containers را در فایل‌های YAML به همراه مثال‌های کاربردی بررسی خواهیم کرد.

ویژگی‌های 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 می‌توان برای کارهایی همچون دانلود فایل‌ها، بررسی وضعیت پایگاه‌داده، و اعمال تنظیمات پیکربندی استفاده کرد. استفاده صحیح از این قابلیت می‌تواند به شما کمک کند تا اپلیکیشن‌های خود را به صورت بهتر و مقیاس‌پذیرتر اجرا کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. کار با ReplicaSets و Deployments”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مفهوم ReplicaSets و اهمیت آن در مقیاس‌پذیری و در دسترس بودن” subtitle=”توضيحات کامل”]ReplicaSet یکی از مفاهیم کلیدی در Kubernetes است که به‌طور مستقیم به مقیاس‌پذیری و در دسترس بودن (availability) اپلیکیشن‌ها کمک می‌کند. این اجزا برای اطمینان از اینکه یک تعداد مشخص از پادها در هر زمان در حال اجرا هستند، طراحی شده‌اند. در ادامه به بررسی مفهوم ReplicaSet و اهمیت آن در مقیاس‌پذیری و در دسترس بودن می‌پردازیم.

تعریف 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 می‌توان تعداد مشخصی از پادها را نگه داشت و اطمینان حاصل کرد که در صورت وقوع خطا، تعداد پادها به‌طور خودکار بازسازی شود. این ویژگی‌ها به‌ویژه برای اپلیکیشن‌های حساس به در دسترس بودن و مقیاس‌پذیر حیاتی است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیاده‌سازی Deployments برای مدیریت بهینه نسخه‌ها و مقیاس‌پذیری” subtitle=”توضيحات کامل”]Deployments در Kubernetes ابزاری بسیار مهم و کاربردی برای مدیریت به‌روزرسانی‌ها، مقیاس‌پذیری و پایداری اپلیکیشن‌ها است. این ویژگی به شما امکان می‌دهد که به‌طور مؤثر نسخه‌های جدید اپلیکیشن را در کلاستر خود مدیریت کرده و با استفاده از ویژگی‌های خودکار Deployment مانند rolling updates و rollback به‌راحتی فرآیند به‌روزرسانی و مدیریت نسخه‌ها را انجام دهید.

در این بخش، به پیاده‌سازی 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 همیشه در دسترس و به‌روز هستند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد و مدیریت Deployments با فایل YAML” subtitle=”توضيحات کامل”]در Kubernetes، برای مدیریت بهینه و مقیاس‌پذیری اپلیکیشن‌ها از Deployments استفاده می‌شود. Deployment یک منبع عالی برای تعریف و مدیریت نسخه‌ها و مقیاس‌پذیری پادها است. شما می‌توانید با استفاده از فایل‌های YAML این Deployments را ایجاد کنید و آن‌ها را به‌راحتی مدیریت کنید.

در این بخش، نحوه ایجاد و مدیریت 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 ایجاد کرده، آن‌ها را به‌روزرسانی کنید، تعداد پادها را مقیاس‌دهی کنید و در صورت نیاز به نسخه‌های قبلی بازگردید. این قابلیت‌ها باعث می‌شود که بتوانید اپلیکیشن‌های خود را به‌طور مؤثر مدیریت کنید و در صورت لزوم مقیاس‌پذیری و به‌روزرسانی‌های تدریجی را انجام دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”به‌روزرسانی تعداد Replicas با استفاده از kubectl scale” subtitle=”توضيحات کامل”]در Kubernetes، برای مقیاس‌دهی (Scaling) تعداد پادها در یک Deployment، ReplicaSet یا هر منبع دیگری که تعداد پادها را مدیریت می‌کند، می‌توان از دستور kubectl scale استفاده کرد. این دستور به شما اجازه می‌دهد که تعداد replicas را به‌صورت داینامیک و بدون نیاز به ویرایش فایل‌های YAML تغییر دهید.

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 یا بازسازی منابع، امکان تغییر تعداد پادها را فراهم می‌کند و به شما اجازه می‌دهد تا به‌صورت داینامیک منابع خود را مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. به‌روزرسانی و Rollback برنامه‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اصول Rolling Updates برای به‌روزرسانی بدون قطعی برنامه‌ها” subtitle=”توضيحات کامل”]در کوبرنتیز، Rolling Updates یک روش به‌روزرسانی بدون قطعی است که به شما اجازه می‌دهد برنامه‌ها یا سرویس‌ها را بدون توقف یا قطعی به نسخه‌های جدید ارتقا دهید. این روش به‌ویژه برای اپلیکیشن‌هایی که باید در دسترس باقی بمانند و به صورت ۲۴/۷ عمل کنند، بسیار مفید است.

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 که نیاز به در دسترس بودن مداوم برنامه‌ها دارند، اهمیت زیادی دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”انجام Rollback به نسخه قبلی با استفاده از kubectl rollout undo” subtitle=”توضيحات کامل”]یکی از ویژگی‌های قدرتمند Kubernetes امکان بازگشت به نسخه قبلی در صورت بروز مشکلات در زمان به‌روزرسانی است. این ویژگی به کمک دستور kubectl rollout undo امکان‌پذیر است و به شما اجازه می‌دهد تا به‌راحتی Deployment یا StatefulSet خود را به آخرین نسخه پایدار بازگردانید.

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 است که به شما اجازه می‌دهد تا در صورت بروز مشکل در نسخه جدید، به‌راحتی به نسخه قبلی بازگردید. با استفاده از این دستور و نظارت بر تاریخچه به‌روزرسانی‌ها، شما می‌توانید در هر زمان به‌صورت ایمن و بدون قطعی برنامه‌ها، عملیات بازگشت را انجام دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی تاریخچه Deployment‌ها با استفاده از kubectl rollout history” subtitle=”توضيحات کامل”]دستور kubectl rollout history ابزاری مفید برای بررسی تاریخچه تغییرات و نسخه‌های مختلف یک Deployment در Kubernetes است. با استفاده از این دستور، می‌توانید تغییرات و به‌روزرسانی‌هایی که بر روی یک Deployment اعمال شده است را مشاهده کنید، که به شما کمک می‌کند تا در صورت نیاز، بهترین نسخه را برای بازگشت (Rollback) انتخاب کنید.

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 ها و دیگر منابع مشاهده کنید. با این اطلاعات، می‌توانید به‌راحتی مشکلات به‌روزرسانی‌ها را شناسایی کرده و به نسخه‌های پایدار قبلی بازگشت کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. تعریف و مدیریت Jobs و Cron Jobs”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”معرفی Jobs برای اجرای وظایف یک‌باره و مدیریت تکرار آن‌ها” subtitle=”توضيحات کامل”]در کوبرنتیز، Jobs ابزاری است که برای اجرای وظایف یک‌باره (one-time tasks) یا فرآیندهایی که باید فقط یک بار اجرا شوند، طراحی شده است. این وظایف می‌توانند پردازش‌هایی مانند بکاپ‌گیری، پردازش داده‌ها، ارسال ایمیل‌ها، یا هر کار دیگری باشند که نیاز به اجرا و تکمیل به صورت یک‌باره دارند. یکی از مزایای استفاده از Job در Kubernetes، مدیریت و خودکارسازی اجرای وظایف است.

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 برای اجرای وظایف یک‌باره بهره‌برداری کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد و مدیریت Jobs با استفاده از فایل YAML” subtitle=”توضيحات کامل”]در Kubernetes، برای ایجاد و مدیریت Jobs می‌توانید از فایل‌های YAML استفاده کنید. این فایل‌ها به شما این امکان را می‌دهند که Jobها را با جزئیات دقیق و تنظیمات دلخواه تعریف کنید. در این بخش، نحوه ایجاد و مدیریت Jobs از طریق فایل YAML را بررسی خواهیم کرد.

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 بهره‌برداری کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”معرفی Cron Jobs برای زمان‌بندی وظایف” subtitle=”توضيحات کامل”]در کوبرنتیز، CronJobs به شما این امکان را می‌دهند که وظایف یا Jobs را در زمان‌های مشخص و به‌طور دوره‌ای اجرا کنید. این ویژگی مشابه Cron در سیستم‌عامل‌های لینوکس است که به شما اجازه می‌دهد وظایف را در زمان‌های مشخص‌شده برنامه‌ریزی کنید. CronJobs در 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های خود را به راحتی مدیریت کنید و زمان‌بندی دقیق برای انجام وظایف مختلف تنظیم کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف Cron Jobs با مثال‌های کاربردی در YAML” subtitle=”توضيحات کامل”]CronJobs در Kubernetes به شما این امکان را می‌دهند که وظایف (Jobs) را به‌طور خودکار و در زمان‌های خاص اجرا کنید. این ویژگی مشابه با Cron در سیستم‌های Unix/Linux است که وظایف را بر اساس زمان‌بندی معین اجرا می‌کند.

برای ایجاد یک 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 در سیستم‌های لینوکس، به راحتی می‌توان زمان‌بندی دلخواه را مشخص کرد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. استفاده از ConfigMaps و Secrets”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف ConfigMaps و کاربرد آن در جداسازی پیکربندی از کد برنامه” subtitle=”توضيحات کامل”]ConfigMap در Kubernetes ابزاری است که به شما این امکان را می‌دهد تا تنظیمات پیکربندی را از کد برنامه جدا کنید و آن‌ها را به‌صورت متمرکز مدیریت کنید. این ویژگی به ویژه در محیط‌های مقیاس‌پذیر و در حال تغییر مانند Kubernetes بسیار مفید است، زیرا به شما اجازه می‌دهد بدون نیاز به تغییر کد برنامه، تنظیمات را به‌راحتی به‌روز کنید.

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 آن‌ها را به کانتینرها تزریق کنید. این جداسازی باعث ساده‌تر شدن فرآیند مدیریت و به‌روزرسانی برنامه‌ها می‌شود و قابلیت مقیاس‌پذیری و انعطاف‌پذیری بیشتری را فراهم می‌آورد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد و استفاده از ConfigMaps برای ذخیره پیکربندی‌های غیرحساس” subtitle=”توضيحات کامل”]ConfigMap در Kubernetes ابزاری قدرتمند برای ذخیره پیکربندی‌های غیرحساس است که می‌تواند به راحتی در Pods و سایر منابع Kubernetes استفاده شود. این ابزار به شما این امکان را می‌دهد که پیکربندی‌ها را از کد برنامه جدا کرده و به صورت متمرکز و در یک مکان مدیریت کنید. همچنین ConfigMap‌ها می‌توانند به کانتینرها تزریق شوند تا برنامه‌ها به پیکربندی‌ها دسترسی داشته باشند، بدون اینکه نیاز به تغییر کد برنامه باشد.

ایجاد یک 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 استفاده می‌شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف Secrets برای مدیریت اطلاعات حساس مانند رمزعبور و کلیدها” subtitle=”توضيحات کامل”]Secrets در Kubernetes ابزاری برای ذخیره و مدیریت اطلاعات حساس است که نمی‌توان آن‌ها را به‌صورت متن ساده در پیکربندی‌ها یا فایل‌های YAML ذخیره کرد. اطلاعات حساس شامل رمزعبور، کلیدهای API، گواهینامه‌های SSL، و سایر داده‌های حساس می‌شود که نباید به‌صورت واضح یا عمومی در دسترس قرار بگیرند. Secrets امکان نگهداری ایمن این اطلاعات را فراهم می‌کند و از آن‌ها می‌توان در Pods و کانتینرها استفاده کرد.

به‌طور پیش‌فرض، 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 به شما این امکان را می‌دهند که پیکربندی‌های حساس را از کد برنامه جدا کرده و به‌صورت متمرکز مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اتصال ConfigMaps و Secrets به کانتینرها” subtitle=”توضيحات کامل”]

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

در 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 شده به کانتینرها تزریق کرد. این روش‌ها کمک می‌کنند که پیکربندی‌ها به‌صورت متمرکز و ایمن مدیریت شوند و همچنین تغییرات بدون نیاز به تغییر در کد برنامه‌نویسی اعمال گردند.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 3. مدیریت Networking و Services”][cdb_course_lesson title=”فصل 1. مفاهیم پایه شبکه در Kubernetes”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”درک اصول شبکه در Kubernetes” subtitle=”توضيحات کامل”]شبکه در Kubernetes یک جزء اساسی و پیچیده است که برای ارتباط میان اجزای مختلف کلاستر طراحی شده است. این اصول شبکه‌ای به نحوی طراحی شده‌اند که بتوانند مقیاس‌پذیری، انعطاف‌پذیری و دسترس‌پذیری سرویس‌ها و اپلیکیشن‌ها را در محیط‌های پویا و توزیع‌شده تأمین کنند.

مدل شبکه‌ای Kubernetes

مدل شبکه‌ای Kubernetes، مبتنی بر یک سری قوانین و اصول است که شامل موارد زیر می‌شود:

• IP های منحصر به فرد برای هر Pod: در Kubernetes، هر Pod یک آدرس IP منحصر به فرد دارد که به آن اجازه می‌دهد به‌صورت مستقیم با سایر Pods و سرویس‌ها ارتباط برقرار کند.
• اتصال مستقیم بین Pods: Pods می‌توانند به‌طور مستقیم و بدون نیاز به Network Address Translation (NAT) با یکدیگر ارتباط برقرار کنند.
• خدمات (Services): Kubernetes از مفهوم سرویس‌ها برای انتساب IP ثابت به یک گروه از Pods استفاده می‌کند که امکان دسترسی پایدار به آنها را فراهم می‌آورد.

اجزای شبکه‌ای در Kubernetes

• Pod Networking: Pods به‌طور پیش‌فرض یک آدرس IP اختصاصی دارند. Kubernetes به‌طور خودکار شبکه را به نحوی تنظیم می‌کند که این IPها به‌صورت مستقیم با هم در ارتباط باشند.
• Service Networking: یک سرویس در Kubernetes، یک لایه انتزاعی است که روی مجموعه‌ای از Pods ایجاد می‌شود و از طریق آن می‌توان به‌طور ثابت و مداوم به Pods خاص دسترسی پیدا کرد. این سرویس‌ها به‌طور پیش‌فرض از DNS برای شناسایی استفاده می‌کنند.

شبکه‌های شبکه‌بندی در Kubernetes

Kubernetes اجازه می‌دهد که نودها و Pods به‌طور مستقیم با یکدیگر ارتباط برقرار کنند، اما برای مدیریت پیچیدگی‌های شبکه و مقیاس‌پذیری، از ابزارها و فناوری‌های مختلفی مانند CNI (Container Network Interface) استفاده می‌شود. این ابزارها شامل:

• Calico: یک شبکه‌بندی سبک و سریع که امنیت و مقیاس‌پذیری را فراهم می‌آورد.
• Weave: یک شبکه‌بندی ساده و مقیاس‌پذیر برای Kubernetes است که به‌طور خودکار یک شبکه مجازی ایجاد می‌کند.
• Flannel: شبکه‌بندی لایه ۳ برای Kubernetes است که به‌طور خودکار یک شبکه IP برای Pods ایجاد می‌کند.

دستورات شبکه‌ای در Kubernetes

برای بررسی وضعیت شبکه در Kubernetes، می‌توان از دستورات kubectl استفاده کرد. در ادامه چند دستور شبکه‌ای مهم آورده شده است:

• نمایش وضعیت سرویس‌ها:

kubectl get svc

• نمایش وضعیت Pods و آدرس‌های IP آن‌ها:

kubectl get pods -o wide

• اتصال به یک Pod برای بررسی ارتباطات شبکه‌ای:

kubectl exec -it <pod-name> -- /bin/sh

تنظیمات شبکه‌ای در Kubernetes

برای تغییر و مدیریت تنظیمات شبکه در Kubernetes، از پیکربندی‌های مختلف استفاده می‌شود. به عنوان مثال برای تنظیم یک سرویس یا NetworkPolicy می‌توانید از فایل‌های YAML استفاده کنید. مسیر فایل‌ها به‌طور معمول در پوشه‌های پروژه Kubernetes یا در دایرکتوری /etc/kubernetes/ قرار دارند.

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

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

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

kubectl apply -f my-service.yaml

در این تنظیمات، سرویس به‌طور خودکار بر اساس Selector که با label Pods همخوانی دارد، به آنها متصل می‌شود.

جمع بندی

درک اصول شبکه در Kubernetes برای ایجاد، مدیریت و مقیاس‌پذیری برنامه‌ها در یک کلاستر Kubernetes ضروری است. Kubernetes با استفاده از مدل‌های شبکه‌ای پیشرفته و ابزارهای مختلف شبکه‌بندی، ارتباط میان اجزای مختلف سیستم را تسهیل می‌کند و به مدیران سیستم این امکان را می‌دهد که برنامه‌ها را به‌صورت مقیاس‌پذیر و پایدار اجرا کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”Cluster Networking Model: نحوه ارتباط بین Pods” subtitle=”توضيحات کامل”]در Kubernetes، مدل شبکه‌ای کلاستر (Cluster Networking Model) به‌طور خاص برای تسهیل ارتباطات میان اجزای مختلف کلاستر طراحی شده است. هدف اصلی این مدل این است که Pods، حتی اگر در نودهای مختلف قرار داشته باشند، به‌طور مستقیم با یکدیگر ارتباط برقرار کنند. این ارتباط بدون نیاز به ترجمه آدرس شبکه (NAT) صورت می‌گیرد و از طریق آدرس‌های IP منحصر به فرد برای هر Pod انجام می‌شود.

اصول مدل شبکه‌ای Kubernetes

1. هر Pod دارای IP منحصر به فرد است:
   • در Kubernetes، هر Pod در کلاستر یک آدرس IP اختصاصی دارد. این آدرس IP برای آن Pod به‌طور دائمی و در طول عمر آن ثابت باقی می‌ماند.
   • این بدان معنی است که هیچ نیازی به استفاده از NAT برای ارتباطات میان Pods وجود ندارد.
2. Pods می‌توانند با یکدیگر ارتباط مستقیم برقرار کنند:
   • این ویژگی از مدل شبکه‌ای Kubernetes به این معنی است که Pods مختلف در نودهای مختلف می‌توانند بدون نیاز به تداخلات اضافی با یکدیگر ارتباط برقرار کنند. آنها می‌توانند به‌طور مستقیم از طریق آدرس‌های IP خود با هم ارتباط داشته باشند.
   • ارتباطات میان Pods از طریق شبکه داخلی کلاستر Kubernetes صورت می‌گیرد.
3. Services برای تسهیل دسترسی به Pods:
   • Services در Kubernetes آدرس‌های IP ثابت را برای مجموعه‌ای از Pods اختصاص می‌دهند. این آدرس ثابت به‌عنوان یک نقطه دسترسی به Pods مختلف عمل می‌کند.
   • اگر Pods جدیدی به سرویس اضافه شوند، Service به‌طور خودکار آدرس‌های IP جدید آنها را نیز به‌روز می‌کند.
4. پشتیبانی از Network Policies:
   • Kubernetes به‌طور پیش‌فرض تمامی Pods را به‌صورت آزادانه قادر به برقراری ارتباط با یکدیگر می‌کند، اما مدیران کلاستر می‌توانند با استفاده از Network Policies، دسترسی‌ها را محدود کرده و قوانین ارتباطی بین Pods و سرویس‌ها را تنظیم کنند.

اجزای اصلی شبکه‌ای در Kubernetes

1. Pod Networking:
   • هر Pod یک آدرس IP اختصاصی دارد که فقط توسط آن Pod قابل استفاده است.
   • Pods می‌توانند از طریق این IPهای منحصر به فرد به یکدیگر ارتباط برقرار کنند، به‌طوری‌که نیازی به NAT برای ارتباطات میان آنها نیست.
2. Service Networking:
   • سرویس‌ها به‌طور خودکار برای گروهی از Pods که نیاز به دسترسی به آنها دارند، آدرس IP ثابت و شناسه DNS ایجاد می‌کنند.
   • این سرویس‌ها می‌توانند با استفاده از selector Pods خاصی را انتخاب کنند تا دسترسی به آنها را فراهم کنند.
3. CNI (Container Network Interface):
   • Kubernetes برای مدیریت شبکه‌های مختلف از CNI استفاده می‌کند که استانداردی برای شبکه‌بندی کانتینرهاست. CNI اجازه می‌دهد که ابزارهای مختلف مانند Calico, Weave, یا Flannel برای ایجاد شبکه‌ها در Kubernetes استفاده شوند.

تنظیمات شبکه در Kubernetes

مدیریت ارتباطات شبکه‌ای در Kubernetes عمدتاً از طریق فایل‌های YAML برای ایجاد Services و Network Policies انجام می‌شود. در اینجا یک نمونه از فایل YAML برای ایجاد یک سرویس آورده شده است:

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

این سرویس می‌تواند به Pods مختلف که label app: my-app را دارند، متصل شود. تنظیمات این سرویس به‌طور خودکار به Pods متصل خواهد شد و آنها می‌توانند از طریق آدرس IP ثابت سرویس به یکدیگر دسترسی داشته باشند.

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

kubectl apply -f my-service.yaml

دستورات مرتبط با شبکه در Kubernetes

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

1. نمایش سرویس‌ها:

   kubectl get svc
   

2. نمایش وضعیت Pods و آدرس‌های IP آن‌ها:

   kubectl get pods -o wide
   

3. بررسی اتصال به یک Pod: برای بررسی ارتباطات شبکه‌ای و اتصال به یک Pod، از دستور زیر استفاده می‌کنیم:

   kubectl exec -it <pod-name> -- /bin/sh
   

جمع‌بندی

مدل شبکه‌ای Kubernetes به‌گونه‌ای طراحی شده است که ارتباطات میان Pods به‌صورت مستقیم و بدون نیاز به NAT انجام می‌شود. این مدل به هر Pod یک آدرس IP منحصر به فرد اختصاص می‌دهد و با استفاده از سرویس‌ها، ارتباطات را میان Pods مختلف در نودهای مختلف تسهیل می‌کند. همچنین، با استفاده از ابزارهای CNI و Network Policies، شبکه Kubernetes انعطاف‌پذیر و مقیاس‌پذیر است و می‌تواند به‌خوبی نیازهای پیچیده شبکه‌ای را در یک کلاستر Kubernetes مدیریت کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از CNI (Container Network Interface)” subtitle=”توضيحات کامل”]CNI (Container Network Interface) یک استاندارد برای پیکربندی و مدیریت شبکه در محیط‌های کانتینری است. در Kubernetes، CNI به‌عنوان مکانیزم اصلی برای مدیریت ارتباطات شبکه‌ای بین Pods و سایر اجزای کلاستر استفاده می‌شود. CNI به Kubernetes این امکان را می‌دهد که از انواع مختلفی از پلاگین‌های شبکه برای فراهم کردن ارتباطات شبکه‌ای میان کانتینرها استفاده کند.

اصول CNI در Kubernetes

1. مدیریت اتصال شبکه‌ای بین Pods:
   • CNI مسئول ایجاد و مدیریت اتصال شبکه‌ای بین Pods است. هر بار که یک Pod ایجاد می‌شود، CNI به‌طور خودکار شبکه آن Pod را پیکربندی کرده و آدرس IP اختصاصی برای آن تخصیص می‌دهد.
2. پلاگین‌های CNI:
   • CNI از طریق پلاگین‌های مختلف شبکه‌ای (مثل Calico, Flannel, Weave, Cilium, و غیره) پیاده‌سازی می‌شود. هر کدام از این پلاگین‌ها ویژگی‌های خاص خود را دارند و برای محیط‌های مختلف Kubernetes به‌کار می‌روند.
3. تعریف شبکه‌های مختلف برای Pods:
   • CNI امکان پیکربندی شبکه‌های مختلف را برای Pods فراهم می‌کند. این امر به مدیران کلاستر اجازه می‌دهد تا مدل‌های مختلف شبکه‌ای مانند bridge, overlay, یا host-local را انتخاب کنند.
4. استفاده از Network Policies:
   • CNI همچنین از پیکربندی و اعمال Network Policies پشتیبانی می‌کند. با استفاده از این ویژگی، می‌توان به طور دقیق تعیین کرد که کدام Pods اجازه برقراری ارتباط با یکدیگر را دارند.

پلاگین‌های معروف CNI در Kubernetes

1. Calico:
   • Calico یک پلاگین شبکه‌ای است که امنیت، مقیاس‌پذیری و عملکرد بالا را برای شبکه‌های Kubernetes فراهم می‌کند. این پلاگین از BGP (Border Gateway Protocol) برای پخش آدرس‌های IP استفاده می‌کند و امنیت شبکه را با استفاده از Network Policies فراهم می‌آورد.
   • برای نصب Calico در Kubernetes، دستور زیر را استفاده کنید:

   kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml
   

2. Flannel:
   • Flannel یک پلاگین شبکه‌ای ساده است که شبکه‌ای از نوع overlay برای Pods ایجاد می‌کند. این پلاگین اغلب برای محیط‌های کوچک یا توسعه‌ای استفاده می‌شود.
   • نصب Flannel در Kubernetes با دستور زیر انجام می‌شود:

   kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
   

3. Weave:
   • Weave یک پلاگین شبکه‌ای است که شبکه‌های مجازی overlay را برای Pods ایجاد می‌کند. Weave از یک پروتکل ویژه برای ارسال داده‌ها بین نودها استفاده می‌کند و به‌خوبی برای شبکه‌بندی multi-cloud یا hybrid-cloud مناسب است.
   • نصب Weave در Kubernetes با دستور زیر انجام می‌شود:

   kubectl apply -f https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')
   

4. Cilium:
   • Cilium از BPF (eBPF) برای ارائه قابلیت‌های پیشرفته شبکه‌ای در Kubernetes استفاده می‌کند. این پلاگین می‌تواند عملکرد و امنیت را با فیلترهای داده‌ی بسیار دقیق بهبود بخشد.
   • نصب Cilium در Kubernetes با دستور زیر انجام می‌شود:

   kubectl create -f https://github.com/cilium/cilium/releases/download/v1.12.0/cilium-operator.yaml
   

نحوه نصب و پیکربندی CNI در Kubernetes

برای نصب و پیکربندی CNI، شما معمولاً باید چند مرحله را دنبال کنید:

1. ایجاد فایل پیکربندی CNI:
   • فایل‌های پیکربندی CNI معمولاً در مسیر /etc/cni/net.d/ قرار دارند. این فایل‌ها تنظیمات مختلف شبکه‌ای مانند آدرس IP، نوع شبکه، و سایر ویژگی‌های شبکه‌ای را تعریف می‌کنند.

   برای مثال، یک فایل پیکربندی CNI برای Flannel به شکل زیر است:

   {
     "name": "flannel",
     "type": "flannel",
     "delegate": {
       "isDefaultGateway": true
     }
   }
   

   این فایل باید در مسیر /etc/cni/net.d/ قرار گیرد تا CNI بتواند آن را بارگذاری کند.

2. بارگذاری پلاگین CNI: پس از نصب پلاگین شبکه‌ای مانند Calico یا Flannel، Kubernetes به‌طور خودکار پلاگین را برای مدیریت شبکه‌های Pods بارگذاری می‌کند.
3. استفاده از Network Policies (اختیاری): پس از نصب CNI، می‌توانید از Network Policies برای کنترل دسترسی میان Pods استفاده کنید. برای نمونه، می‌توانید با استفاده از دستور زیر یک Policy برای محدود کردن دسترسی میان Pods ایجاد کنید:

   apiVersion: networking.k8s.io/v1
   kind: NetworkPolicy
   metadata:
     name: allow-ingress
   spec:
     podSelector:
       matchLabels:
         app: my-app
     ingress:
     - from:
       - podSelector:
           matchLabels:
             app: allowed-app
   

   این Network Policy فقط به Pods با label app: allowed-app اجازه دسترسی به Pods با label app: my-app را می‌دهد.

4. تست وضعیت شبکه: پس از نصب و پیکربندی CNI، می‌توانید با استفاده از دستور kubectl get pods -o wide وضعیت شبکه را بررسی کنید و از صحت آدرس‌دهی IP در Pods اطمینان حاصل کنید.

جمع‌بندی

CNI (Container Network Interface) به Kubernetes این امکان را می‌دهد که از پلاگین‌های مختلف برای مدیریت شبکه‌های Pods استفاده کند. این پلاگین‌ها می‌توانند انواع مختلفی از مدل‌های شبکه‌ای را پشتیبانی کنند و شبکه‌بندی پیچیده‌تری را برای کلاستر فراهم کنند. با استفاده از CNI، Kubernetes قادر است که ارتباطات مستقیم و بدون نیاز به NAT میان Pods را برقرار کند و در عین حال پشتیبانی از امنیت و مقیاس‌پذیری را فراهم آورد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”درک Pod-to-Pod Communication” subtitle=”توضيحات کامل”]در Kubernetes، یکی از اصول مهمی که برای ارتباط میان Pods رعایت می‌شود، تخصیص IP یکتا برای هر Pod است. این ویژگی اساساً به Pods این امکان را می‌دهد که به‌طور مستقیم و بدون نیاز به واسطه با یکدیگر ارتباط برقرار کنند.

IP یکتا برای هر Pod

Kubernetes برای هر Pod یک آدرس IP منحصر به فرد تخصیص می‌دهد که این آدرس مستقل از نود (Node) ای است که Pod روی آن اجرا می‌شود. این آدرس IP به Pods این امکان را می‌دهد که بدون توجه به نودهای میزبان، ارتباط مستقیم و هم‌زمان با دیگر Pods برقرار کنند. این مدل باعث ساده‌تر شدن مدیریت ارتباطات شبکه‌ای می‌شود.

ویژگی‌های کلیدی Pod-to-Pod Communication

1. IP ثابت برای هر Pod:
   • هر Pod در Kubernetes دارای یک IP اختصاصی است. این IP به‌طور مستقیم به یک کانتینر خاص در داخل Pod ارجاع داده نمی‌شود بلکه برای کل Pod است.
   • این IP ثابت باقی می‌ماند تا زمانی که Pod حذف شده و یک Pod جدید ایجاد شود.
2. عدم نیاز به NAT (Network Address Translation):
   • به دلیل اینکه هر Pod یک آدرس IP یکتا دارد، برقراری ارتباط بین Pods به‌طور مستقیم انجام می‌شود و نیازی به استفاده از NAT (که معمولاً در شبکه‌های پیچیده برای تبدیل آدرس‌ها استفاده می‌شود) نیست.
   • این امر منجر به کاهش پیچیدگی و افزایش کارایی در ارتباطات شبکه‌ای می‌شود.
3. استفاده از Cluster Network:
   • Kubernetes به‌طور پیش‌فرض از یک مدل شبکه‌ای برای کل کلاستر استفاده می‌کند که تمام Pods را به یکدیگر متصل می‌کند. این بدان معنی است که Pods می‌توانند با استفاده از آدرس‌های IP خود با یکدیگر ارتباط برقرار کنند، بدون توجه به اینکه روی چه نودی از کلاستر قرار دارند.
4. استفاده از DNS برای تسهیل ارتباط:
   • علاوه بر استفاده از IP یکتا، Kubernetes از DNS داخلی برای تسهیل نام‌گذاری و دسترسی به Pods استفاده می‌کند. با استفاده از DNS، می‌توان به‌جای استفاده از IP آدرس‌ها، از نام‌های دامنه برای ارتباط با Pods استفاده کرد.

نحوه عملکرد IP یکتا در Pod-to-Pod Communication

• وقتی که یک Pod جدید در Kubernetes ایجاد می‌شود، CNI (Container Network Interface) برای این Pod یک آدرس IP از رنج آدرس‌های شبکه‌ای که برای کلاستر تعیین شده است، تخصیص می‌دهد.
• این آدرس IP برای Pod ثابت است تا زمانی که Pod نابود شود و مجدداً ایجاد گردد.
• ارتباطات میان Pods از طریق این IP ها انجام می‌شود. به عنوان مثال، اگر Pod A بخواهد به Pod B متصل شود، از IP مربوط به Pod B استفاده می‌کند.

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

1. برقراری ارتباط مستقیم میان Pods: برای مثال، اگر شما دو Pod با نام‌های pod-a و pod-b دارید، می‌توانید به‌طور مستقیم به IP هر کدام از این Pods متصل شوید. فرض کنید IPهای pod-a و pod-b به ترتیب 10.244.0.5 و 10.244.0.6 باشند.برای برقراری ارتباط از Pod A به Pod B، می‌توانید از دستور curl یا هر ابزاری دیگر که از IP استفاده می‌کند، استفاده کنید:

   curl 10.244.0.6
   

   این دستور به Pod B در آدرس IP 10.244.0.6 ارسال می‌شود و اگر سرویس یا اپلیکیشنی در حال اجرا باشد، پاسخ از آن Pod دریافت می‌شود.

2. استفاده از DNS برای دسترسی به Pods: Kubernetes به‌طور خودکار به هر Pod یک رکورد DNS اختصاص می‌دهد که می‌توانید از آن برای دسترسی به Pod استفاده کنید.به‌طور مثال، اگر pod-a یک سرویس دارد، می‌توانید به جای استفاده از IP آن، از نام سرویس آن برای دسترسی استفاده کنید:

   curl pod-b.default.svc.cluster.local
   

   در اینجا pod-b.default.svc.cluster.local نام DNS مربوط به Pod B است که Kubernetes به‌طور خودکار آن را ایجاد می‌کند.

جمع‌بندی

تخصیص یک IP یکتا برای هر Pod در Kubernetes باعث می‌شود که Pods به‌طور مستقیم و بدون واسطه با یکدیگر ارتباط برقرار کنند. این ویژگی از پیچیدگی‌های شبکه‌سازی می‌کاهد و مدیریت ارتباطات میان Pods را ساده‌تر می‌کند. همچنین، استفاده از DNS در Kubernetes این امکان را فراهم می‌آورد که به‌جای استفاده از IP آدرس‌ها، از نام‌های دامنه برای برقراری ارتباط میان Pods استفاده شود، که این امر دسترسی به سرویس‌ها را راحت‌تر و انعطاف‌پذیرتر می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه تخصیص IP در Kubernetes” subtitle=”توضيحات کامل”]در Kubernetes، هر Pod یک آدرس IP منحصر به فرد از کلاستر دریافت می‌کند که به آن امکان می‌دهد تا به‌طور مستقیم با سایر Pods ارتباط برقرار کند. تخصیص IP به Pods بخشی از مدل شبکه‌ای Kubernetes است و از طریق یک استاندارد به نام CNI (Container Network Interface) انجام می‌شود. در اینجا فرآیند و نحوه تخصیص IP در Kubernetes توضیح داده شده است:

1. مدل شبکه Pods: در Kubernetes، هر Pod یک IP منحصر به فرد دریافت می‌کند که به آن اجازه می‌دهد تا با سایر Pods در همان کلاستر ارتباط برقرار کند. این IP از فضای آدرس‌دهی شبکه‌ای که توسط CNI مشخص شده است، گرفته می‌شود.
2. نقش CNI (Container Network Interface): CNI یک استاندارد است که به Kubernetes اجازه می‌دهد با شبکه‌های مختلف کار کند. در واقع، این استاندارد به Kubernetes اجازه می‌دهد تا از پلن‌های مختلف شبکه‌ای استفاده کند (مانند Flannel، Calico و Weave). CNI مسئول تخصیص آدرس‌های IP به Pods و مدیریت ارتباطات شبکه‌ای آنها است.
3. پیکربندی شبکه و Subnets: هر نود در کلاستر Kubernetes یک زیرشبکه (subnet) خاص خود را دارد. IPهای تخصیص داده شده به Pods در این زیرشبکه‌ها قرار می‌گیرند. پلاگین‌های CNI معمولاً این Subnetها را تنظیم می‌کنند. در صورتی که از CNI‌های خاص مانند Calico استفاده کنید، معمولاً تنظیمات subnet در فایل پیکربندی CNI تعیین می‌شود.
4. تخصیص IP‌های داینامیک: IPها به Pods به‌طور داینامیک تخصیص داده می‌شوند و این IP به مدت زمان زندگی Pod معتبر است. زمانی که یک Pod حذف شود، IP آن آزاد می‌شود و در صورت نیاز به Pod جدیدی تخصیص می‌یابد. بنابراین، تخصیص IP در Kubernetes پویاست و همیشه به‌طور خودکار صورت می‌گیرد.
5. پلاگین‌های شبکه و تخصیص IP: بسته به نوع پلاگین شبکه‌ای که استفاده می‌کنید، نحوه تخصیص IP ممکن است متفاوت باشد:
   • Flannel: یکی از ساده‌ترین و رایج‌ترین پلاگین‌ها برای تخصیص IP است. Flannel معمولاً از یک سری Subnetهای از پیش تعریف شده استفاده می‌کند تا IPهای منحصر به فردی برای Pods تخصیص دهد.
   • Calico: در پلاگین Calico، می‌توان از تنظیمات خاصی برای ایجاد Subnetهای مختلف برای Pods و مدیریت آدرس‌دهی IP استفاده کرد. این پلاگین می‌تواند IP‌های عمومی یا اختصاصی را برای Pods تخصیص دهد.
   • Weave: این پلاگین مشابه Flannel است، اما قابلیت‌های اضافی مانند امنیت و شبکه‌های پیچیده‌تری را نیز ارائه می‌دهد.
6. Pod-to-Pod Communication: هر Pod در Kubernetes دارای یک IP منحصر به فرد است که از دیگر Pods در همان کلاستر جداست. این امر به Pods این امکان را می‌دهد که به‌طور مستقیم با یکدیگر ارتباط برقرار کنند. هر Pod می‌تواند به Pods دیگر از طریق IP خودش دسترسی داشته باشد.
7. استفاده از Services برای دسترسی به Pods: اگر نیاز به دسترسی به یک یا چند Pod از بیرون از کلاستر دارید، Kubernetes از Service برای این کار استفاده می‌کند. Service می‌تواند به یک مجموعه از Pods متصل شود و دسترسی به آنها را مدیریت کند.

مثال‌های کد

در ادامه می‌توانید نمونه‌ای از پیکربندی Kubernetes را مشاهده کنید که از CNI برای تخصیص IP استفاده می‌کند:

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

در این مثال، پس از ایجاد Pod از دستور kubectl get pods -o wide استفاده کنید تا IP تخصیص داده شده به آن را مشاهده کنید.

مسیر پیکربندی‌ها

تنظیمات مربوط به تخصیص IP معمولاً در فایل‌های پیکربندی پلاگین CNI یا تنظیمات کلاستر Kubernetes قرار دارند. برای تنظیمات شبکه‌ای و تخصیص IP، شما باید از فایل‌های زیر استفاده کنید:

• /etc/cni/net.d/ (پیکربندی پلاگین CNI)
• /etc/kubernetes/ (پیکربندی‌های عمومی Kubernetes)

همچنین، اگر از Kubernetes در محیط‌هایی مانند AWS یا GCP استفاده می‌کنید، ممکن است تنظیمات تخصیص IP مربوط به هر پلتفرم خاص باشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مفاهیم Kube-proxy و نقش آن در شبکه” subtitle=”توضيحات کامل”]در کوبرنتیز، Kube-proxy یک جزء کلیدی برای مدیریت و هماهنگی ترافیک شبکه‌ای است که بین Pods و Services در کلاستر جریان دارد. Kube-proxy مسئولیت هدایت درخواست‌ها به درستی به Pods مناسب را دارد. این ابزار نقش مهمی در مدیریت شبکه و دسترسی به خدمات داخلی کلاستر ایفا می‌کند.

در ادامه، مفاهیم و نقش Kube-proxy در شبکه Kubernetes بررسی می‌شود:

1. وظیفه Kube-proxy: Kube-proxy یک پروکسی است که بر روی هر نود در کلاستر Kubernetes اجرا می‌شود و وظیفه هدایت ترافیک شبکه‌ای به Pods مربوطه را بر عهده دارد. وقتی که یک Service در Kubernetes ایجاد می‌شود، Kube-proxy مسیر درخواست‌ها را از کاربران یا سایر خدمات به Pods صحیح هدایت می‌کند.
2. انواع روش‌های مسیریابی توسط Kube-proxy: Kube-proxy از سه روش مختلف برای مسیریابی ترافیک به Pods استفاده می‌کند. این روش‌ها عبارتند از:
   • iptables: در این روش، Kube-proxy از ابزار iptables لینوکس برای هدایت ترافیک به Pods استفاده می‌کند. درخواست‌ها بر اساس قوانین و رجیستری‌های iptables به Pods مناسب ارسال می‌شوند. این روش کارآمدترین و سریع‌ترین گزینه است و معمولاً برای عملکرد بهتر توصیه می‌شود.
   • ipvs (IP Virtual Server): در این روش، Kube-proxy از فناوری IPVS برای مسیریابی ترافیک به Pods استفاده می‌کند. این روش مشابه iptables است، اما مقیاس‌پذیری بالاتری دارد و برای کلاسترهای بزرگ‌تر مناسب است.
   • userspace: در این روش قدیمی‌تر، Kube-proxy ترافیک را در فضای کاربری خود هدایت می‌کند. این روش کمترین کارایی را دارد و به‌طور معمول در کلاسترهای کوچک یا آزمایشی استفاده می‌شود.
3. عملکرد Kube-proxy: هنگامی که یک Service در Kubernetes ایجاد می‌شود، Kube-proxy برای آن Service قوانین مسیریابی خاصی ایجاد می‌کند. این قوانین مشخص می‌کنند که چگونه درخواست‌ها از منابع خارجی به Pods هدایت شوند. Kube-proxy به‌طور پیوسته وضعیت Pods را بررسی کرده و اطمینان می‌دهد که ترافیک به Pods فعال و سالم هدایت شود.
4. تعریف Service و نقش Kube-proxy در آن: وقتی یک Service در Kubernetes ایجاد می‌شود، Kube-proxy مسئول مسیریابی درخواست‌ها به Pods متصل به آن Service است. Service‌ها اغلب به عنوان یک لایه انتزاعی برای Pods عمل می‌کنند، که به کاربران اجازه می‌دهند بدون نیاز به آگاهی از جزئیات درون‌کلاستری به Pods دسترسی پیدا کنند.
   • برای مثال، اگر یک Service به نام my-service ایجاد شود که در پشت آن Pods متعددی قرار دارد، Kube-proxy درخواست‌ها به آدرس my-service را به یکی از این Pods هدایت می‌کند.

   نحوه ایجاد Service به‌صورت زیر است:

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

5. پیکربندی Kube-proxy: پیکربندی Kube-proxy معمولاً از طریق فایل پیکربندی /etc/kubernetes/manifests/kube-proxy.yaml انجام می‌شود. این فایل شامل تنظیمات مختلف مانند نوع مسیریابی (iptables یا ipvs) و پیکربندی‌های مربوط به نحوه رفتار Kube-proxy است.
   • برای بررسی وضعیت و پیکربندی Kube-proxy از دستور زیر استفاده می‌شود:

   kubectl get pods -n kube-system -l k8s-app=kube-proxy
   

6. نحوه عملکرد Kube-proxy در شبکه کلاستر:
   • تخصیص IP و DNS: Kube-proxy به‌طور خودکار آدرس‌های IP را به Pods اختصاص داده و دسترسی به DNS داخلی Kubernetes را فراهم می‌کند.
   • Load Balancing: Kube-proxy به‌عنوان یک load balancer عمل می‌کند و درخواست‌ها را به طور متوازن بین Pods متصل به یک Service توزیع می‌کند.
   • Firewalling: Kube-proxy با استفاده از iptables یا ipvs می‌تواند دسترسی به Services را محدود کرده و ترافیک‌های ناخواسته را مسدود کند.
7. آیا Kube-proxy برای امنیت شبکه اهمیت دارد؟: Kube-proxy به‌طور غیرمستقیم نقش امنیتی ایفا می‌کند، زیرا ترافیک شبکه را بین Pods مختلف مسیریابی کرده و به نوعی سیاست‌های شبکه‌ای مانند دسترسی به Services و Pods را پیاده‌سازی می‌کند.

مثال‌های کد

1. بررسی وضعیت Kube-proxy: برای مشاهده وضعیت Kube-proxy از دستور زیر استفاده کنید:

   kubectl get pods -n kube-system -l k8s-app=kube-proxy
   

2. تغییر تنظیمات Kube-proxy:برای تغییر تنظیمات Kube-proxy، فایل پیکربندی آن را ویرایش کنید:مسیر فایل: /etc/kubernetes/manifests/kube-proxy.yamlدر این فایل می‌توانید گزینه‌های مختلف مانند انتخاب نوع پروکسی (iptables یا ipvs) را تغییر دهید.
3. بررسی قوانین iptables ایجاد شده توسط Kube-proxy:برای مشاهده قوانین iptables که Kube-proxy ایجاد کرده است، از دستور زیر استفاده کنید:

   sudo iptables -t nat -L -n -v
   

جمع بندی

Kube-proxy نقش حیاتی در مدیریت شبکه کلاستر Kubernetes ایفا می‌کند و ترافیک شبکه را به درستی به Pods متصل به Services هدایت می‌کند. این ابزار از روش‌های مختلف مسیریابی مانند iptables و ipvs برای مدیریت بهتر ترافیک و مقیاس‌پذیری استفاده می‌کند.

 [/cdb_course_lesson][cdb_course_lesson title=”فصل 2. معرفی و پیکربندی انواع Services”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ClusterIP Service: معرفی و کاربرد” subtitle=”توضيحات کامل”]در Kubernetes، ClusterIP Service یک نوع Service است که برای فراهم کردن دسترسی به Pods از داخل کلاستر استفاده می‌شود. این Service تنها از داخل کلاستر قابل دسترسی است و به عنوان یک آدرس IP ثابت در داخل کلاستر عمل می‌کند که به Pods متصل به آن سرویس ارجاع می‌دهد.

معرفی ClusterIP Service

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

این نوع Service معمولاً برای ارتباطات داخلی بین Pods مختلف در یک کلاستر Kubernetes استفاده می‌شود و دسترسی به Service را برای کاربران خارجی محدود می‌کند.

کاربردهای ClusterIP

1. ارتباط داخلی بین Pods: زمانی که شما نیاز به برقراری ارتباط بین Pods مختلف در یک کلاستر دارید، از ClusterIP Service برای فراهم آوردن آدرس ثابت و دسترسی مستقیم استفاده می‌کنید.
2. مدیریت میکروسرویس‌ها: ClusterIP برای مدیریت و برقراری ارتباط میان سرویس‌های مختلفی که در Kubernetes مستقر شده‌اند، استفاده می‌شود. هر سرویس می‌تواند به صورت یک نقطه اتصال ثابت برای سایر سرویس‌ها عمل کند.
3. محدود کردن دسترسی به شبکه داخلی: ClusterIP فقط برای ارتباطات داخلی کلاستر استفاده می‌شود و اجازه نمی‌دهد که درخواست‌ها از خارج از کلاستر به این Service ارسال شود. بنابراین، امنیت بیشتری برای برنامه‌ها و سرویس‌های در حال اجرا داخل کلاستر فراهم می‌آورد.
4. Load Balancing داخلی: ClusterIP به طور خودکار درخواست‌ها را به صورت متوازن بین Pods مختلفی که تحت یک Service هستند توزیع می‌کند. این کار باعث افزایش کارایی و پایداری اپلیکیشن می‌شود.

ایجاد ClusterIP Service

برای ایجاد یک ClusterIP Service، می‌توان از یک فایل YAML استفاده کرد. این فایل به Kubernetes می‌گوید که یک Service از نوع ClusterIP ایجاد کند.

مثال YAML برای ایجاد یک ClusterIP Service:

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

در این مثال:

• selector: مشخص می‌کند که این Service به کدام Pods متصل خواهد شد (در اینجا به Pods با app: my-app).
• ports: نشان‌دهنده پورت‌هایی است که Service در دسترس قرار خواهد داد.
• clusterIP: آدرس IP داخلی کلاستر است که به Service اختصاص داده می‌شود (در صورت عدم تعیین، Kubernetes به طور خودکار یک آدرس IP تخصیص می‌دهد).

استفاده از ClusterIP Service

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

• استفاده از آدرس IP که به Service اختصاص داده شده است. برای مثال، در صورتی که IP 10.96.0.1 به Service اختصاص داده شود، هر Pod می‌تواند به این IP متصل شود.
• استفاده از نام DNS داخلی Kubernetes، که به طور خودکار برای هر Service ایجاد می‌شود. برای مثال، Service my-clusterip-service به صورت خودکار یک نام DNS مانند my-clusterip-service.default.svc.cluster.local خواهد داشت که از داخل کلاستر قابل دسترسی است.

مشاهده وضعیت Service‌های ClusterIP

برای مشاهده وضعیت و اطلاعات مرتبط با Service‌های ClusterIP از دستور زیر استفاده می‌شود:

kubectl get svc my-clusterip-service

این دستور اطلاعاتی مانند آدرس IP، پورت‌ها و نوع Service را نمایش خواهد داد.

دسترسی به Service از داخل کلاستر

یک Pod در داخل کلاستر می‌تواند از طریق IP یا نام DNS به Service دسترسی پیدا کند. به عنوان مثال:

curl my-clusterip-service.default.svc.cluster.local:80

جمع بندی

ClusterIP Service در Kubernetes به‌طور خاص برای فراهم آوردن دسترسی به Pods از داخل کلاستر طراحی شده است. این نوع Service یک آدرس IP داخلی را به Service اختصاص می‌دهد و فقط از داخل کلاستر قابل دسترسی است. استفاده از ClusterIP برای برقراری ارتباطات داخلی میان Pods و ارائه Load Balancing درون‌کلاستری بسیار مفید است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه ایجاد و مدیریت یک ClusterIP Service” subtitle=”توضيحات کامل”]برای ایجاد و مدیریت یک ClusterIP Service در Kubernetes، می‌توانید از ابزار kubectl و فایل‌های YAML استفاده کنید. در این قسمت، نحوه ایجاد، مشاهده، به‌روزرسانی و حذف یک ClusterIP Service را بررسی خواهیم کرد.

1. ایجاد یک ClusterIP Service

برای ایجاد یک ClusterIP Service، می‌توانید از فایل YAML استفاده کنید. این فایل به Kubernetes اطلاع می‌دهد که باید یک Service از نوع ClusterIP ایجاد کند و کدام Pods باید به آن متصل شوند.

مثال فایل YAML برای ایجاد ClusterIP Service:

apiVersion: v1
kind: Service
metadata:
  name: my-clusterip-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  clusterIP: 10.96.0.1  # این بخش اختیاری است و Kubernetes به طور خودکار IP را تخصیص می‌دهد.

در این مثال:

• selector: این فیلد مشخص می‌کند که این Service به کدام Pods متصل می‌شود (در اینجا Pods با برچسب app: my-app).
• ports: پورت‌هایی که برای Service در نظر گرفته شده است. در اینجا، پورت 80 برای دسترسی خارجی و پورت 8080 برای اتصال به Pod هدف است.
• clusterIP: آدرس IP که به طور داخلی برای این Service اختصاص داده می‌شود. این مقدار اختیاری است و در صورتی که تعیین نشود، Kubernetes به‌طور خودکار یک IP را تخصیص می‌دهد.

دستور برای ایجاد Service با استفاده از YAML:

برای ایجاد این Service، ابتدا فایل YAML را ذخیره کرده و سپس از دستور زیر استفاده کنید:

kubectl apply -f my-clusterip-service.yaml

این دستور Service را با پیکربندی تعریف شده در فایل YAML ایجاد خواهد کرد.

2. مشاهده وضعیت ClusterIP Service

برای مشاهده وضعیت و اطلاعات مربوط به Service‌هایی که در کلاستر دارید، از دستور زیر استفاده می‌شود:

kubectl get svc my-clusterip-service

این دستور اطلاعاتی مانند آدرس IP، پورت‌ها، و نوع Service را نمایش می‌دهد.

خروجی نمونه:

NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
my-clusterip-service     ClusterIP   10.96.0.1        <none>        80/TCP           2m

در اینجا، CLUSTER-IP نشان‌دهنده آدرس IP داخلی است که به این Service اختصاص داده شده است.

3. دسترسی به ClusterIP Service از داخل کلاستر

یک Pod در داخل کلاستر می‌تواند به این Service دسترسی پیدا کند از طریق نام DNS داخلی یا آدرس IP. به‌طور پیش‌فرض، Kubernetes برای هر Service یک نام DNS به شکل service-name.namespace.svc.cluster.local ایجاد می‌کند.

مثال دسترسی از داخل کلاستر:

curl my-clusterip-service.default.svc.cluster.local:80

این دستور به Service با نام my-clusterip-service در namespace default متصل می‌شود و درخواست HTTP را به پورت 80 ارسال می‌کند.

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

برای به‌روزرسانی یک ClusterIP Service، می‌توانید از دستور kubectl expose یا فایل‌های YAML استفاده کنید. به عنوان مثال، اگر بخواهید پورت‌های یک Service را تغییر دهید، باید فایل YAML را ویرایش کرده و دوباره آن را با دستور زیر اعمال کنید:

kubectl apply -f my-clusterip-service.yaml

5. حذف یک ClusterIP Service

برای حذف یک ClusterIP Service، از دستور زیر استفاده می‌شود:

kubectl delete svc my-clusterip-service

این دستور سرویس my-clusterip-service را از کلاستر حذف خواهد کرد.

جمع‌بندی

ایجاد و مدیریت یک ClusterIP Service در Kubernetes به شما این امکان را می‌دهد که بتوانید ارتباطات داخلی میان Pods مختلف را به‌صورت ساده و مؤثر برقرار کنید. این سرویس‌ها به‌طور خودکار یک آدرس IP ثابت داخلی برای ارتباطات درون کلاستری فراهم می‌کنند. با استفاده از دستورات kubectl می‌توانید این سرویس‌ها را ایجاد، مشاهده، به‌روزرسانی و حذف کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مثال عملی : تعریف یک ClusterIP Service را با استفاده از YAML” subtitle=”توضيحات کامل”]در این بخش، یک ClusterIP Service را با استفاده از فایل YAML تعریف می‌کنیم و نحوه استفاده از آن را برای ایجاد یک ارتباط داخلی بین Pods نشان خواهیم داد.

1. ایجاد فایل YAML برای ClusterIP Service

برای ایجاد یک ClusterIP Service، ابتدا باید یک فایل YAML بنویسید که مشخص کند کدام Pods باید به این Service متصل شوند و تنظیمات پورت‌ها به چه شکل باشد.

مثال فایل YAML برای ClusterIP Service:

apiVersion: v1
kind: Service
metadata:
  name: my-clusterip-service
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  clusterIP: 10.96.0.10  # این بخش اختیاری است و Kubernetes به طور خودکار IP را تخصیص می‌دهد.

در این فایل:

• name: نام Service که به آن اشاره خواهیم کرد.
• selector: Pods هایی که این Service به آنها متصل می‌شود. در اینجا Pods با برچسب app: my-app.
• ports: پورت‌هایی که برای دسترسی به Service استفاده می‌شود. در این مثال، درخواست‌ها به پورت 80 روی Service می‌آیند و به پورت 8080 در Pods هدف هدایت می‌شوند.
• clusterIP: آدرس IP که به Service اختصاص داده می‌شود. در اینجا از یک IP دستی (10.96.0.10) استفاده شده است که به طور پیش‌فرض Kubernetes این آدرس را خودکار تخصیص می‌دهد.

2. ایجاد ClusterIP Service

برای اعمال این فایل YAML و ایجاد Service در کلاستر، ابتدا آن را در فایلی به نام my-clusterip-service.yaml ذخیره کرده و سپس دستور زیر را اجرا کنید:

kubectl apply -f my-clusterip-service.yaml

این دستور Service با پیکربندی مشخص شده در فایل YAML را ایجاد خواهد کرد.

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

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

kubectl get svc my-clusterip-service

این دستور آدرس IP داخلی و پورت‌های سرویس را نمایش می‌دهد.

خروجی نمونه:

NAME                    TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)          AGE
my-clusterip-service     ClusterIP   10.96.0.10       <none>        80/TCP           2m

در اینجا:

• CLUSTER-IP آدرس IP اختصاصی به Service است (10.96.0.10).
• PORT(S) پورت‌های مرتبط با Service هستند (در اینجا پورت 80 برای دسترسی خارجی).

4. دسترسی به ClusterIP Service از داخل کلاستر

برای دسترسی به این Service از داخل کلاستر، می‌توانید از دستور curl یا ابزارهای مشابه استفاده کنید. به طور پیش‌فرض، Kubernetes برای هر Service یک DNS داخلی به شکل service-name.namespace.svc.cluster.local ایجاد می‌کند.

برای دسترسی به my-clusterip-service از یک Pod در داخل کلاستر:

curl my-clusterip-service.default.svc.cluster.local:80

این دستور درخواست HTTP را به پورت 80 از داخل کلاستر ارسال می‌کند.

5. حذف ClusterIP Service

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

kubectl delete svc my-clusterip-service

این دستور سرویس my-clusterip-service را از کلاستر حذف می‌کند.

جمع‌بندی

در این بخش، نحوه ایجاد یک ClusterIP Service را بررسی کردیم. این سرویس‌ها برای ارتباطات داخلی در کلاستر استفاده می‌شوند و به شما این امکان را می‌دهند که Pods مختلف به راحتی با یکدیگر ارتباط برقرار کنند. با استفاده از فایل YAML و دستورات kubectl می‌توان این سرویس‌ها را ایجاد، مشاهده، دسترسی به آن‌ها را از داخل کلاستر برقرار کرد و در نهایت آن‌ها را حذف کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”NodePort Service: نحوه عملکرد و کاربرد آن” subtitle=”توضيحات کامل”]NodePort یک نوع Service در Kubernetes است که به شما این امکان را می‌دهد که ترافیک را از خارج از کلاستر به یک پورت خاص روی هر نود در کلاستر هدایت کنید. این سرویس به طور خودکار یک پورت تصادفی در بازه‌ای مشخص را در نودهای کلاستر باز می‌کند و ترافیک از آن پورت را به Podها هدایت می‌کند.

نحوه عملکرد NodePort:

• در یک NodePort Service، Kubernetes یک پورت خاص را برای دسترسی به سرویس از خارج از کلاستر اختصاص می‌دهد. این پورت معمولاً از بازه پورت‌های 30000 تا 32767 انتخاب می‌شود.
• هنگامی که ترافیک به این پورت ارسال می‌شود، Kube-proxy آن را به Podهای مربوطه که در حال اجرای سرویس هستند هدایت می‌کند.
• این سرویس به صورت متمرکز از هر نود در کلاستر در دسترس است و می‌توانید با استفاده از آدرس IP هر نود به سرویس دسترسی پیدا کنید.

کاربرد NodePort:

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

نحوه ایجاد یک NodePort Service با YAML:

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

در این فایل YAML:

• port: پورتی است که سرویس از داخل کلاستر در دسترس خواهد بود.
• targetPort: پورتی که در داخل Pod برای سرویس‌دهی به درخواست‌ها باز است.
• nodePort: پورت خاصی که برای دسترسی از خارج کلاستر به سرویس اختصاص می‌یابد.

دستورات مربوطه:

• ایجاد NodePort Service با استفاده از فایل YAML:

  kubectl apply -f nodeport-service.yaml
  

  (فایل YAML در مسیر فعلی ذخیره شده است)

• مشاهده سرویس‌ها با نوع NodePort:

  kubectl get svc
  

• مشاهده جزئیات سرویس NodePort:

  kubectl describe svc my-nodeport-service
  

این تنظیمات به شما امکان می‌دهد که ترافیک ورودی را از هر نود در کلاستر با استفاده از آدرس IP نود و پورت مشخص شده به سرویس هدایت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”محدودیت‌های NodePort” subtitle=”توضيحات کامل”]هرچند که NodePort سرویس‌ها راه‌حلی ساده برای دسترسی به سرویس‌ها از خارج کلاستر فراهم می‌کنند، اما این نوع سرویس‌ها محدودیت‌هایی دارند که در نظر گرفتن آن‌ها می‌تواند در انتخاب بهترین نوع سرویس تأثیرگذار باشد:

1. محدودیت پورت‌ها:

• Kubernetes برای سرویس‌های NodePort تنها از پورت‌های خاصی در بازه 30000 تا 32767 استفاده می‌کند. این به این معناست که تعداد محدودی پورت برای سرویس‌ها در دسترس است و در صورت نیاز به تعداد بیشتری پورت ممکن است با مشکل روبه‌رو شوید.

2. امنیت:

• باز کردن پورت‌های NodePort در هر نود به طور مستقیم می‌تواند مشکلات امنیتی به همراه داشته باشد، زیرا این سرویس‌ها از هر کجا قابل دسترسی هستند و ممکن است دسترسی‌های غیرمجاز به شبکه کلاستر شما ایجاد کنند.
• در شرایطی که نودهای مختلف در معرض اینترنت هستند، ممکن است حملات DDoS یا تلاش‌های دسترسی غیرمجاز را تجربه کنید.

3. نبود Load Balancer:

• در NodePort هیچ قابلیت Load Balancer یکپارچه مانند سرویس‌های نوع LoadBalancer در دسترس نیست. در حالی که می‌توانید از Load Balancer خارجی استفاده کنید، این باعث پیچیدگی بیشتر در معماری و مدیریت می‌شود.

4. وابستگی به IP نود:

• دسترسی به سرویس‌های NodePort نیازمند استفاده از IP نودهای کلاستر است. اگر نودها به دلایلی از دسترس خارج شوند یا در محیط‌های پویا (مانند محیط‌های ابری با IPهای متغیر) قرار داشته باشید، دسترسی به سرویس‌ها می‌تواند مشکل‌ساز شود.

5. مقیاس‌پذیری:

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

6. ترافیک بیش از حد روی نودهای خاص:

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

جمع‌بندی:

در حالی که NodePort یک راه‌حل ساده برای دسترسی به سرویس‌ها از خارج کلاستر است، اما محدودیت‌های امنیتی، مقیاس‌پذیری، وابستگی به IP نود و بازه محدود پورت‌ها می‌تواند در موارد خاص مشکلاتی ایجاد کند. در محیط‌های با نیاز به دسترسی مقیاس‌پذیرتر یا امنیت بیشتر، استفاده از سرویس‌هایی مانند LoadBalancer یا Ingress می‌تواند جایگزین مناسب‌تری باشد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی Load Balancer و موارد استفاده” subtitle=”توضيحات کامل”]در Kubernetes، سرویس‌های LoadBalancer به شما این امکان را می‌دهند که ترافیک ورودی از خارج کلاستر را به‌طور خودکار بین پادهای مختلف در کلاستر توزیع کنید. این نوع سرویس از یک Load Balancer خارجی که توسط سرویس‌دهنده (مانند AWS ELB، GCP Load Balancer یا Azure Load Balancer) فراهم می‌شود، برای توزیع ترافیک استفاده می‌کند.

مفهوم Load Balancer:

Load Balancer یک نوع سرویس است که قادر است ترافیک ورودی را بین چندین سرور (یا در اینجا، پادهای Kubernetes) توزیع کند تا بتوانید بار کاری خود را بین آن‌ها متعادل کنید. در Kubernetes، وقتی یک سرویس از نوع LoadBalancer تعریف می‌شود، کلاستر یک آدرس IP خارجی به آن تخصیص می‌دهد که از طریق آن می‌توان به سرویس‌ها دسترسی پیدا کرد.

موارد استفاده LoadBalancer:

1. دسترسی خارجی به سرویس‌ها:
   • وقتی نیاز دارید سرویس‌های داخلی کلاستر را از خارج کلاستر در دسترس قرار دهید، سرویس‌های LoadBalancer یک راه‌حل ساده و کارآمد هستند. به طور مثال، اگر اپلیکیشن شما نیاز به دسترسی عمومی از اینترنت داشته باشد، استفاده از این نوع سرویس بهترین گزینه است.
2. توزیع ترافیک بین پادها:
   • Load Balancer به طور خودکار ترافیک ورودی را بین پادها توزیع می‌کند. این کمک می‌کند تا بار کاری به صورت یکنواخت بین پادها پخش شده و از بروز مشکلاتی همچون اشباع منابع جلوگیری شود.
3. مقیاس‌پذیری و دسترسی بالا:
   • در صورت نیاز به مقیاس‌پذیری بیشتر، سرویس‌های LoadBalancer می‌توانند به راحتی تعداد بیشتری پاد را در خود جای دهند. همچنین در صورت خرابی یک پاد، Load Balancer به طور خودکار ترافیک را به پادهای سالم دیگر هدایت می‌کند که موجب دسترسی بالا و جلوگیری از قطعی می‌شود.
4. مدیریت بار ترافیک در محیط‌های ابری:
   • در محیط‌های ابری مانند AWS، GCP و Azure، سرویس‌های LoadBalancer به صورت یکپارچه با این پلتفرم‌ها کار می‌کنند و می‌توانند به راحتی درخواست‌های ورودی را بین پادها توزیع کنند. این پلتفرم‌ها همچنین ویژگی‌های اضافی مانند SSL termination، اتوماسیون مقیاس‌پذیری و پشتیبانی از قوانین فایروال را فراهم می‌آورند.
5. امنیت و فایروال‌ها:
   • با استفاده از Load Balancer، شما می‌توانید ترافیک ورودی را از طریق یک آدرس IP خارجی مدیریت کنید و از مزایای امنیتی مانند فایروال‌های اعمال شده توسط ارائه‌دهندگان سرویس ابری بهره‌برداری کنید.

نحوه ایجاد LoadBalancer Service:

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

kubectl expose pod <pod-name> --type=LoadBalancer --name=<service-name>

این دستور یک سرویس از نوع LoadBalancer ایجاد می‌کند که به پاد شما متصل می‌شود و یک آدرس IP خارجی به آن اختصاص داده می‌شود. همچنین می‌توانید این سرویس را به کمک YAML نیز ایجاد کنید.

مثال YAML برای LoadBalancer Service:

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

در این مثال:

• type: LoadBalancer سرویس را به یک سرویس LoadBalancer تبدیل می‌کند.
• selector مشخص می‌کند که کدام پادها باید به این سرویس متصل شوند.
• ports مشخص می‌کند که درخواست‌ها باید به پورت 80 از سرویس برسند و سپس به پورت 8080 پادهای مربوطه هدایت شوند.

جمع‌بندی:

سرویس‌های LoadBalancer در Kubernetes برای توزیع ترافیک ورودی از خارج کلاستر به پادهای مختلف استفاده می‌شوند و راه‌حلی مناسب برای نیازهای مقیاس‌پذیر و دسترسی بالا به سرویس‌ها فراهم می‌کنند. این سرویس‌ها به ویژه در محیط‌های ابری با استفاده از سرویس‌دهندگان Load Balancer خارجی بسیار کارآمد هستند و می‌توانند قابلیت‌هایی مانند مدیریت ترافیک، امنیت و پشتیبانی از مقیاس‌پذیری را به سادگی در اختیار شما قرار دهند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از سرویس‌های ابری (Cloud Providers) برای Load Balancer” subtitle=”توضيحات کامل”]در Kubernetes، برای توزیع ترافیک ورودی به پادها از سرویس‌هایی به نام LoadBalancer استفاده می‌شود. بسیاری از سرویس‌های ابری مانند AWS, GCP و Azure ابزارهایی برای راه‌اندازی Load Balancer به طور خودکار دارند که به راحتی می‌توان از آن‌ها برای توزیع ترافیک بین پادهای Kubernetes استفاده کرد. این سرویس‌ها، به خصوص در محیط‌های تولیدی، نقش بسیار مهمی در مدیریت ترافیک ورودی، مقیاس‌پذیری و افزایش دسترسی دارند.

نحوه عملکرد Load Balancer در سرویس‌های ابری:

هنگامی که سرویس Kubernetes از نوع LoadBalancer تنظیم می‌شود، Kubernetes به طور خودکار یک سرویس خارجی Load Balancer برای شما ایجاد می‌کند و آن را به سرویس‌های ابری مختلف متصل می‌کند. این فرآیند شامل تخصیص یک IP عمومی به سرویس Kubernetes است که از آن طریق درخواست‌های خارجی به پادهای کلاستر ارسال می‌شود. در واقع، سرویس ابری Load Balancer در پشت صحنه مدیریت ترافیک ورودی را بر عهده دارد.

ویژگی‌های Load Balancer در سرویس‌های ابری:

1. IP عمومی اختصاصی: سرویس‌های Load Balancer در بسیاری از سرویس‌دهندگان ابری یک IP عمومی ثابت به سرویس Kubernetes اختصاص می‌دهند که از آن طریق درخواست‌ها به پادها هدایت می‌شود.
2. مقیاس‌پذیری خودکار: اکثر سرویس‌های ابری مانند AWS ELB، Google Cloud Load Balancer و Azure Load Balancer به طور خودکار مقیاس‌پذیری را انجام می‌دهند و در صورت افزایش یا کاهش بار ترافیکی، تعداد پادهای در حال خدمت را تنظیم می‌کنند.
3. ایمنی و فایروال‌ها: سرویس‌های ابری معمولاً از فایروال‌های داخلی برای محدود کردن دسترسی به سرویس‌های مختلف استفاده می‌کنند که می‌توانند به صورت خودکار تنظیم شوند. همچنین، می‌توانند از ویژگی‌های امنیتی اضافی مانند SSL termination (پایان SSL) و DDoS protection برای محافظت از سرویس‌ها بهره ببرند.
4. پشتیبانی از پروتکل‌های مختلف: سرویس‌های ابری معمولاً از انواع پروتکل‌ها مانند HTTP, HTTPS, TCP و UDP پشتیبانی می‌کنند و می‌توانند با درخواست‌های مختلف به درستی تعامل کنند.

نحوه استفاده از سرویس‌های ابری برای Load Balancer:

در زیر نحوه استفاده از سرویس‌های ابری مختلف برای راه‌اندازی Load Balancer در Kubernetes آورده شده است.

1. AWS (Elastic Load Balancer – ELB):

در AWS، هنگام ایجاد سرویس از نوع LoadBalancer، Kubernetes به طور خودکار یک Elastic Load Balancer (ELB) در AWS ایجاد می‌کند. ELB به طور خودکار ترافیک ورودی را به پادهای Kubernetes توزیع می‌کند.

مثال: اگر از AWS استفاده می‌کنید، به راحتی می‌توانید سرویس Load Balancer را در Kubernetes با دستور زیر ایجاد کنید:

kubectl expose deployment my-app --type=LoadBalancer --name=my-loadbalancer-service

AWS به طور خودکار یک ELB به این سرویس متصل می‌کند و IP عمومی را برای دسترسی به سرویس از خارج کلاستر ایجاد می‌کند.

2. GCP (Google Cloud Load Balancer):

در Google Cloud، Kubernetes به طور خودکار یک Google Cloud Load Balancer ایجاد می‌کند که ترافیک ورودی را به پادهای Kubernetes توزیع می‌کند. مشابه AWS، زمانی که سرویس از نوع LoadBalancer ایجاد می‌شود، Google Cloud خودکار عمل می‌کند.

مثال: برای استفاده از Google Cloud Load Balancer:

kubectl expose deployment my-app --type=LoadBalancer --name=my-loadbalancer-service

پس از اجرای این دستور، GCP یک Load Balancer ایجاد می‌کند که آدرس IP عمومی خود را به سرویس اختصاص می‌دهد.

3. Azure (Azure Load Balancer):

در Azure، Kubernetes به طور خودکار یک Azure Load Balancer ایجاد می‌کند که می‌تواند ترافیک ورودی را به پادهای مختلف توزیع کند.

مثال: برای استفاده از Azure Load Balancer:

kubectl expose deployment my-app --type=LoadBalancer --name=my-loadbalancer-service

این دستور مشابه دستورات دیگر سرویس‌دهندگان ابری عمل می‌کند و به طور خودکار یک Azure Load Balancer ایجاد می‌کند.

جمع‌بندی:

سرویس‌های ابری مانند AWS, GCP و Azure ابزارهایی برای راه‌اندازی Load Balancer به‌طور خودکار در Kubernetes فراهم می‌کنند که به‌طور شفاف ترافیک ورودی را بین پادها توزیع می‌کنند. این سرویس‌ها مقیاس‌پذیری، امنیت و دسترسی بالا را به راحتی برای اپلیکیشن‌های Kubernetes فراهم می‌آورند. استفاده از Load Balancer در محیط‌های ابری مزایای زیادی دارد و باعث بهبود عملکرد، امنیت و مقیاس‌پذیری در Kubernetes می‌شود.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”External Name Service: معرفی و استفاده برای DNS خارجی” subtitle=”توضيحات کامل”]در Kubernetes، سرویس‌های ExternalName به شما این امکان را می‌دهند که سرویس‌های داخلی کلاستر را به نام‌های DNS خارجی نقشه‌برداری کنید. این نوع سرویس‌ها به جای تخصیص یک IP داخلی به سرویس‌ها، از نام‌های DNS خارجی برای ارجاع به منابع خارج از کلاستر استفاده می‌کنند.

کاربردها و مزایای ExternalName Service:

• اتصال به منابع خارجی: از این سرویس‌ها می‌توان برای اتصال به سرویس‌های خارجی که خارج از کلاستر Kubernetes هستند، استفاده کرد. به‌عنوان مثال، اگر سرویس شما نیاز به اتصال به یک پایگاه داده خارجی یا سرویس‌های موجود در دیگر کلاسترها داشته باشد، می‌توانید از سرویس ExternalName استفاده کنید.
• پنهان کردن جزئیات اتصال: این سرویس‌ها کمک می‌کنند تا جزئیات مربوط به نحوه اتصال به منابع خارجی را مخفی نگه دارید و در عوض یک DNS ساده برای دسترسی فراهم کنید. این می‌تواند در فرآیند مدیریت شبکه مفید باشد، چرا که به‌راحتی می‌توانید نام DNS خارجی را تغییر دهید بدون اینکه نیاز به تغییر در تنظیمات یا کدهای داخلی اپلیکیشن‌ها باشد.
• سادگی در مدیریت DNS: به جای نگهداری لیست‌های پیچیده از آدرس‌های IP خارجی، می‌توانید از DNS برای مدیریت دسترسی به منابع خارجی استفاده کنید و تمام سرویس‌های Kubernetes می‌توانند به‌طور یکنواخت به آن دسترسی پیدا کنند.

نحوه پیاده‌سازی ExternalName Service:

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

apiVersion: v1
kind: Service
metadata:
  name: my-external-service
spec:
  type: ExternalName
  externalName: example.com

در اینجا، سرویس my-external-service به نام DNS خارجی example.com ارجاع داده شده است. در این مثال، به هر درخواست که به سرویس my-external-service فرستاده شود، به آدرس example.com منتقل خواهد شد.

مراحل ایجاد یک ExternalName Service:

1. تعریف سرویس در فایل YAML: برای ایجاد یک ExternalName service باید نوع سرویس را به ExternalName تنظیم کنید و نام خارجی DNS که می‌خواهید به آن ارجاع دهید را در فیلد externalName وارد کنید.
2. استفاده از سرویس: پس از ایجاد سرویس از نوع ExternalName، سرویس‌های داخل کلاستر می‌توانند به آن ارجاع دهند به‌گونه‌ای که به نام داخلی my-external-service متصل شده و درخواست‌های آن‌ها به آدرس DNS خارجی منتقل شود.
3. دستور kubectl برای ایجاد سرویس: پس از تهیه فایل YAML می‌توانید سرویس را با استفاده از دستور زیر ایجاد کنید:

   kubectl apply -f externalname-service.yaml
   

   در اینجا، فرض بر این است که فایل YAML شما با نام externalname-service.yaml ذخیره شده است.

نکات و محدودیت‌ها:

• سرویس‌های ExternalName نمی‌توانند برای سرویس‌هایی که داخل کلاستر هستند به کار بروند. تنها به منابع خارجی که از DNS قابل دسترسی هستند اشاره می‌کنند.
• ExternalName فقط می‌تواند به DNS‌های معتبر خارجی ارجاع دهد و از استفاده مستقیم از IP یا نام‌های غیر DNS پشتیبانی نمی‌کند.

جمع‌بندی:

سرویس ExternalName در Kubernetes یک راه‌حل مناسب برای دسترسی به منابع خارجی از طریق نام‌های DNS است. این سرویس‌ها به شما این امکان را می‌دهند که اتصال به منابع خارجی را به سادگی مدیریت کنید و دسترسی‌های پیچیده به IP‌ها را از بین ببرید. با استفاده از این سرویس‌ها، می‌توانید نام‌های DNS را در داخل کلاستر Kubernetes برای دسترسی به منابع خارجی معرفی کنید و به راحتی از آنها استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه انتخاب و مدیریت Service Selectors” subtitle=”توضيحات کامل”]در کوبرنتیز، Service Selectors یک ابزار برای انتخاب Pods خاص برای ارتباط با سرویس هستند. به‌عبارت دیگر، Service Selector مشخص می‌کند که کدام Pods باید به یک سرویس متصل شوند. از این روش می‌توان برای مدیریت ترافیک شبکه‌ای میان Pods و سرویس‌ها استفاده کرد.

مفهوم Service Selectors

Selector در سرویس Kubernetes یک مجموعه از برچسب‌ها (Labels) است که به Kubernetes کمک می‌کند تا منابع خاصی را از کلاستر پیدا کند. وقتی یک سرویس برای تعامل با Pods خاص تنظیم می‌شود، می‌توان از selector برای مشخص کردن Pods مورد نظر استفاده کرد. هر Pod می‌تواند برچسب‌های خاص خود را داشته باشد، و Kubernetes از این برچسب‌ها برای ارتباط با سرویس‌ها استفاده می‌کند.

نحوه استفاده از Service Selectors

زمانی که یک سرویس جدید ایجاد می‌کنید، می‌توانید از Selector برای مشخص کردن Pods مورد نظر برای اتصال به آن سرویس استفاده کنید. به طور کلی، سرویس‌ها با استفاده از برچسب‌ها به Pods متصل می‌شوند. برای این کار باید از spec.selector در فایل YAML استفاده کنید.

مثال عملی

در این مثال، ما یک سرویس از نوع ClusterIP را ایجاد می‌کنیم که تنها با Pods دارای برچسب خاصی ارتباط برقرار می‌کند.

Pod‌های مورد نظر با برچسب مشخص:

ابتدا یک Pod با برچسب مشخص تعریف می‌کنیم:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
spec:
  containers:
    - name: myapp-container
      image: nginx

در این فایل YAML، ما یک Pod با نام myapp-pod ایجاد کرده‌ایم که برچسب app: myapp دارد.

ایجاد سرویس با استفاده از Selector:

حالا یک سرویس ایجاد می‌کنیم که از برچسب app: myapp برای شناسایی Pods استفاده می‌کند:

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

در اینجا:

• در spec.selector، ما مشخص کرده‌ایم که سرویس myapp-service تنها با Pods که دارای برچسب app: myapp هستند، ارتباط برقرار کند.
• پورت 80 از سرویس به پورت 80 در Pods متصل می‌شود.

بررسی و مدیریت Service Selectors

مشاهده سرویس‌ها و Pod‌های متصل

برای مشاهده سرویس‌ها و Pods که به آنها متصل هستند، می‌توانید از دستور kubectl get استفاده کنید. به‌عنوان مثال:

kubectl get svc

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

kubectl get pods --selector=app=myapp

این دستور تمامی Pods که برچسب app=myapp دارند را نمایش می‌دهد.

ویرایش Selector بعد از ایجاد سرویس

اگر نیاز دارید Selector سرویس خود را تغییر دهید، می‌توانید از دستور kubectl edit استفاده کنید. به‌عنوان مثال:

kubectl edit svc myapp-service

با استفاده از این دستور، فایل YAML سرویس باز می‌شود و می‌توانید Selector را تغییر دهید.

مدیریت برچسب‌ها (Labels) در Pods

برای اعمال تغییرات در برچسب‌های یک Pod، می‌توانید از دستور kubectl label استفاده کنید. به‌عنوان مثال:

kubectl label pods myapp-pod app=myapp

این دستور برچسب app=myapp را به Pod myapp-pod اضافه می‌کند.

جمع‌بندی

در Kubernetes، Service Selectors ابزاری بسیار قدرتمند برای مدیریت ارتباطات میان سرویس‌ها و Pods هستند. با استفاده از Selector‌ها می‌توانیم Pods خاص را برای ارتباط با سرویس انتخاب کنیم. این قابلیت به ما کمک می‌کند تا کنترل بیشتری روی نحوه توزیع و مدیریت ترافیک شبکه‌ای میان Pods و سرویس‌ها داشته باشیم.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”درک Headless Services و کاربردهای آن” subtitle=”توضيحات کامل”]در Kubernetes، سرویس‌ها معمولاً برای فراهم کردن یک نقطه دسترسی ثابت به Pods استفاده می‌شوند. سرویس‌های Headless (بدون سر) یکی از ویژگی‌های خاص Kubernetes هستند که به شما امکان می‌دهند تا مستقیماً به Pods خاص بدون استفاده از Load Balancer یا IP ثابت سرویس دسترسی پیدا کنید. این سرویس‌ها به طور خاص زمانی مفید هستند که نیاز به کنترل دقیق‌تر بر نحوه اتصال و آدرس‌دهی به Pods دارید.

مفهوم Headless Service

یک Headless Service سرویس است که به جای استفاده از یک IP ثابت برای دسترسی به Pods، آدرس‌دهی DNS مستقیم به Pods را فراهم می‌کند. این نوع سرویس‌ها معمولاً برای کاربردهایی مانند کش، توزیع بار، و یا زمانی که نیاز به برقراری ارتباط مستقیم با هر Pod دارید، استفاده می‌شوند.

در سرویس‌های Headless، Kubernetes آدرس IP سرویس را حذف می‌کند و به‌جای آن، DNS به نام هر Pod اشاره می‌کند. این کار باعث می‌شود که هر Pod یک شناسه یکتای DNS داشته باشد.

نحوه ایجاد Headless Service

برای ایجاد یک سرویس Headless، شما باید clusterIP را به مقدار None تنظیم کنید. این کار باعث می‌شود که Kubernetes به جای تخصیص یک IP ثابت برای سرویس، به Pods DNS منحصر به فردی نسبت دهد.

مثال عملی از Headless Service

در اینجا یک مثال از ایجاد یک Headless Service آورده شده است که به یک سری Pod‌های مشخص متصل می‌شود.

تعریف Pods:

ابتدا، تعدادی Pod با برچسب مشابه ایجاد می‌کنیم:

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  labels:
    app: myapp
spec:
  containers:
    - name: myapp-container
      image: nginx
---
apiVersion: v1
kind: Pod
metadata:
  name: pod-2
  labels:
    app: myapp
spec:
  containers:
    - name: myapp-container
      image: nginx

در این مثال، ما دو Pod به نام‌های pod-1 و pod-2 ایجاد کرده‌ایم که هر کدام برچسب app: myapp دارند.

تعریف Headless Service:

سپس یک سرویس Headless ایجاد می‌کنیم که به Pods متصل می‌شود:

apiVersion: v1
kind: Service
metadata:
  name: myapp-headless
spec:
  clusterIP: None
  selector:
    app: myapp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

در این فایل YAML:

• clusterIP: None باعث می‌شود که این سرویس Headless باشد و هیچ آدرس IP ثابت برای سرویس تخصیص داده نشود.
• با استفاده از selector app: myapp، سرویس تمام Pods با این برچسب را انتخاب می‌کند.

کاربردهای Headless Services

1. DNS برای Pods به‌طور مستقل: در سرویس‌های Headless، هر Pod DNS خاص خود را دارد که امکان دسترسی مستقیم به آن فراهم می‌شود. به عنوان مثال، اگر دو Pod به نام‌های pod-1 و pod-2 داشته باشیم، می‌توانید به‌طور مستقیم به آنها از طریق DNS‌های pod-1.myapp.svc.cluster.local و pod-2.myapp.svc.cluster.local دسترسی پیدا کنید.
2. استفاده در StatefulSets: سرویس‌های Headless به‌ویژه در هنگام استفاده از StatefulSets مفید هستند. این نوع سرویس‌ها اجازه می‌دهند تا هر Pod یک شناسه DNS یکتا داشته باشد که برای اپلیکیشن‌هایی که به حالت (state) نیاز دارند، ضروری است. StatefulSets معمولاً در مواردی مانند بانک‌های اطلاعاتی یا کش‌ها که نیاز به حفظ حالت دارند، استفاده می‌شوند.
3. توزیع بار دستی و انتخاب Pods: در سرویس‌های معمولی Kubernetes، یک Load Balancer برای توزیع ترافیک به Pods استفاده می‌شود. اما در سرویس‌های Headless، شما می‌توانید خودتان تصمیم بگیرید که به کدام Pod دسترسی پیدا کنید و این امکان را دارید که ترافیک را به صورت دستی بین Pods توزیع کنید.
4. نظارت و کش: برخی از سیستم‌های کش و پایگاه‌های داده توزیع شده نیاز دارند که به Pods خاصی به‌طور مستقیم متصل شوند. Headless Services این امکان را فراهم می‌کنند تا نظارت یا کش بر روی یک Pod خاص انجام شود بدون اینکه نیاز به تنظیمات پیچیده در Load Balancer باشد.

جمع‌بندی

سرویس‌های Headless در Kubernetes به شما این امکان را می‌دهند که به Pods به صورت مستقیم و بدون استفاده از IP ثابت یا Load Balancer دسترسی پیدا کنید. این سرویس‌ها به‌ویژه زمانی که به DNS مستقل برای هر Pod نیاز دارید یا می‌خواهید از ویژگی‌هایی مانند StatefulSets یا توزیع بار دستی استفاده کنید، بسیار مفید هستند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. مدیریت Ingress”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”Ingress Controller: معرفی و نحوه راه‌اندازی” subtitle=”توضيحات کامل”]Ingress Controller یک بخش مهم از معماری Kubernetes است که به شما این امکان را می‌دهد تا ترافیک ورودی به داخل کلاستر را مدیریت کنید. این ابزار به شما کمک می‌کند تا بتوانید درخواست‌های HTTP و HTTPS را به سرویس‌های مختلف در کلاستر هدایت کنید. به عبارت ساده‌تر، Ingress Controller به عنوان یک دروازه برای مدیریت و هدایت ترافیک شبکه ورودی به کلاستر عمل می‌کند.

معرفی Ingress Controller

در Kubernetes، Ingress یک منبع (resource) است که به شما اجازه می‌دهد تا تنظیمات مربوط به دسترسی به سرویس‌های مختلف در کلاستر را از طریق HTTP و HTTPS پیکربندی کنید. Ingress Controller یک برنامه یا پاد است که از این تنظیمات استفاده می‌کند و ترافیک ورودی را مطابق با قوانین Ingress هدایت می‌کند.

Ingress Controller مسئولیت‌های زیادی دارد از جمله:

• مدیریت ترافیک ورودی به سرویس‌ها بر اساس قوانین تعریف‌شده در Ingress.
• پشتیبانی از توزیع بار و تنظیمات SSL برای امنیت بیشتر.
• قابلیت مسیریابی پیشرفته برای درخواست‌ها.

به طور پیش‌فرض، Kubernetes خودش هیچ Ingress Controller‌ای ندارد، اما شما می‌توانید از یکی از Ingress Controllerهای موجود استفاده کنید. این Ingress Controllerها می‌توانند به شکل‌های مختلفی پیاده‌سازی شوند، مثل Nginx، Traefik، HAProxy و دیگر گزینه‌ها.

نحوه راه‌اندازی Ingress Controller

برای راه‌اندازی Ingress Controller در Kubernetes، ابتدا باید یکی از Ingress Controllerها را انتخاب کرده و آن را در کلاستر خود پیاده‌سازی کنید. یکی از رایج‌ترین انتخاب‌ها برای Ingress Controller، استفاده از Nginx Ingress Controller است. در اینجا نحوه راه‌اندازی این Ingress Controller را توضیح می‌دهیم.

راه‌اندازی Nginx Ingress Controller

برای راه‌اندازی Nginx Ingress Controller، مراحل زیر را دنبال کنید:

1. نصب Nginx Ingress Controller:می‌توانید Nginx Ingress Controller را از طریق kubectl یا استفاده از Helm نصب کنید. در اینجا ما روش نصب با kubectl را نشان می‌دهیم.

   دستور زیر را برای نصب Nginx Ingress Controller وارد کنید:

   kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
   

   این دستور فایل YAML را که شامل تنظیمات لازم برای راه‌اندازی Nginx Ingress Controller است، اعمال می‌کند. این تنظیمات به طور خودکار تمامی منابع لازم مانند پادها، سرویس‌ها و ConfigMapها را در کلاستر ایجاد می‌کند.

2. بررسی وضعیت Ingress Controller:پس از نصب، می‌توانید وضعیت Nginx Ingress Controller را با استفاده از دستور زیر بررسی کنید:

   kubectl get pods -n ingress-nginx
   

   این دستور تمام پادهای مربوط به Ingress Controller را نمایش می‌دهد. اگر همه چیز به درستی نصب شده باشد، باید یک پاد با نام ingress-nginx-controller را مشاهده کنید.

3. ایجاد یک Ingress Resource:پس از نصب Ingress Controller، می‌توانید منابع Ingress خود را برای مسیریابی ترافیک ورودی به سرویس‌ها ایجاد کنید. در اینجا یک مثال از یک فایل YAML برای Ingress آمده است که درخواست‌های HTTP را به سرویس myapp هدایت می‌کند.

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: myapp-ingress
     namespace: default
   spec:
     rules:
     - host: myapp.example.com
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: myapp
               port:
                 number: 80
   

   در این فایل YAML:

   • host: myapp.example.com به این معنی است که درخواست‌هایی که به این دامنه ارسال می‌شوند، به سرویس myapp در پورت 80 هدایت خواهند شد.
   • مسیر / به‌طور پیش‌فرض تمام درخواست‌های ورودی را به سرویس myapp ارجاع می‌دهد.
4. مشاهده وضعیت Ingress:بعد از اینکه Ingress را ایجاد کردید، می‌توانید وضعیت آن را با دستور زیر مشاهده کنید:

   kubectl get ingress myapp-ingress
   

جمع‌بندی

Ingress Controller یکی از اجزای مهم Kubernetes است که به شما این امکان را می‌دهد تا ترافیک ورودی به کلاستر خود را مدیریت کنید. با استفاده از Ingress Controller، شما می‌توانید درخواست‌های HTTP و HTTPS را به سرویس‌های مختلف در کلاستر هدایت کنید و ویژگی‌هایی مانند Load Balancing و SSL Termination را پیکربندی کنید. برای راه‌اندازی Ingress Controller می‌توانید از ابزارهایی مانند Nginx Ingress Controller استفاده کنید که نصب آن از طریق kubectl یا Helm بسیار ساده است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تفاوت بین Load Balancer و Ingress” subtitle=”توضيحات کامل”]در کوبرنتیز، Load Balancer و Ingress هر دو به منظور مدیریت ترافیک ورودی به کلاستر استفاده می‌شوند، اما کاربردها و عملکرد متفاوتی دارند. در این بخش، به بررسی تفاوت‌های کلیدی بین این دو سرویس پرداخته خواهد شد.

Load Balancer

Load Balancer یک سرویس سطح 4 در مدل OSI است که به طور مستقیم ترافیک ورودی به کلاستر را مدیریت می‌کند. زمانی که یک سرویس از نوع LoadBalancer تعریف می‌شود، Kubernetes به طور خودکار یک IP عمومی برای آن سرویس اختصاص می‌دهد و درخواست‌ها را به سرویس مربوطه هدایت می‌کند. این روش معمولاً توسط ارائه‌دهندگان ابری مانند AWS، GCP و Azure پشتیبانی می‌شود و از طریق Load Balancerهای ابری این عملکرد فراهم می‌شود.

ویژگی‌ها:

• سطح 4 (L4): Load Balancer به درخواست‌ها بر اساس IP و پورت هدایت می‌کند و در سطح شبکه (Layer 4) عمل می‌کند.
• خدمات بدون نیاز به Ingress Controller: برای راه‌اندازی Load Balancer نیازی به نصب و پیکربندی Ingress Controller ندارید.
• مناسب برای خدمات عمومی: معمولاً برای سرویس‌هایی که نیاز به دسترسی عمومی دارند، مانند وب‌سایت‌ها یا APIها، از Load Balancer استفاده می‌شود.

نحوه ایجاد یک Load Balancer در Kubernetes: برای ایجاد یک سرویس از نوع LoadBalancer، کافی است در فایل YAML سرویس خود را به صورت زیر تنظیم کنید:

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

در این مثال، سرویس به طور خودکار یک IP عمومی از طرف ارائه‌دهنده ابری (در صورت پشتیبانی) دریافت می‌کند.

Ingress

Ingress یک منبع سطح 7 در مدل OSI است که به شما این امکان را می‌دهد تا ترافیک HTTP و HTTPS ورودی را به سرویس‌های مختلف در کلاستر هدایت کنید. برخلاف Load Balancer که فقط ترافیک سطح شبکه را مدیریت می‌کند، Ingress می‌تواند درخواست‌های HTTP را بر اساس URL، دامنه، مسیرها و دیگر ویژگی‌های لایه کاربرد مسیریابی کند.

ویژگی‌ها:

• سطح 7 (L7): Ingress برای مسیریابی ترافیک HTTP/HTTPS بر اساس URL، دامنه و مسیر عمل می‌کند.
• نیاز به Ingress Controller: برای استفاده از Ingress، باید یک Ingress Controller مانند Nginx یا Traefik را نصب کنید.
• مدیریت مسیریابی پیشرفته: Ingress قابلیت‌هایی مانند مسیریابی بر اساس URL، SSL Termination و مدیریت Load Balancing را برای درخواست‌های HTTP فراهم می‌کند.

نحوه ایجاد یک Ingress: برای ایجاد یک Ingress، باید یک منبع Ingress به شکل زیر تعریف کنید:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: myapp.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-service
            port:
              number: 80

در این مثال، درخواست‌هایی که به myapp.example.com ارسال می‌شوند، به سرویس my-service هدایت خواهند شد.

جمع‌بندی

• Load Balancer: بیشتر برای تقسیم بار ترافیک ورودی در سطح شبکه (L4) به سرویس‌ها در کلاستر استفاده می‌شود و معمولاً برای سرویس‌های عمومی به کار می‌رود. در Kubernetes، برای استفاده از Load Balancer نیازی به نصب Ingress Controller نیست.
• Ingress: برای مسیریابی ترافیک HTTP و HTTPS در سطح لایه کاربرد (L7) به سرویس‌های مختلف استفاده می‌شود. به Ingress Controller نیاز دارد و قابلیت‌های پیشرفته‌تری برای مدیریت URL، دامنه و مسیرها فراهم می‌کند.

در حالی که Load Balancer و Ingress هر دو ابزارهایی برای مدیریت ترافیک ورودی به کلاستر هستند، Load Balancer معمولاً برای ارائه دسترسی عمومی به سرویس‌ها و Ingress برای مدیریت پیشرفته‌تر ترافیک HTTP/HTTPS کاربرد دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Ingress Resources: تعریف و پیکربندی” subtitle=”توضيحات کامل”]در کوبرنتیز، Ingress Resources به شما این امکان را می‌دهند که ترافیک ورودی HTTP و HTTPS را به سرویس‌های مختلف در کلاستر هدایت کنید. این منابع معمولاً برای مسیریابی دقیق‌تر درخواست‌ها بر اساس URL، دامنه، و مسیرها استفاده می‌شوند. برای استفاده از Ingress، باید یک Ingress Controller را در کلاستر راه‌اندازی کرده باشید، زیرا این کنترلر است که در نهایت درخواست‌های ورودی را مدیریت کرده و آن‌ها را به سرویس‌های مورد نظر هدایت می‌کند.

تعریف Ingress Resource

یک Ingress Resource در Kubernetes معمولاً شامل قوانین و تنظیماتی است که به Kubernetes می‌گویند چگونه درخواست‌های ورودی را به سرویس‌ها هدایت کند. این تنظیمات می‌توانند شامل مسیریابی URL، SSL Termination، و هدایت ترافیک به سرویس‌های مختلف باشند.

برای ایجاد Ingress، شما باید یک فایل YAML بنویسید که در آن قوانین و تنظیمات مربوطه را تعریف کنید.

مثال پیکربندی Ingress

در اینجا یک مثال ساده از نحوه تعریف یک Ingress Resource آورده شده است. در این مثال، ترافیک ورودی به دامنه example.com بر اساس مسیرها به سرویس‌های مختلف هدایت می‌شود.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: app1-service
            port:
              number: 80
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port:
              number: 80

توضیح تنظیمات:

• apiVersion: نسخه API که برای ایجاد منبع Ingress استفاده می‌شود. در اینجا از networking.k8s.io/v1 استفاده شده است.
• kind: نوع منبع که در اینجا Ingress است.
• metadata: اطلاعات متادیتا مانند نام منبع (در اینجا my-ingress).
• spec: مشخصات پیکربندی Ingress که شامل قواعد و تنظیمات است.
  • rules: قوانین مسیریابی که مشخص می‌کند ترافیک ورودی به چه سرویس‌هایی هدایت شود. در این مثال، دو مسیر /app1 و /app2 برای هدایت ترافیک به دو سرویس مختلف (app1-service و app2-service) مشخص شده‌اند.
  • host: دامنه یا نام میزبان که ترافیک برای آن مسیریابی می‌شود. در این مثال، example.com است.
  • http: شامل تنظیمات برای مسیریابی HTTP که مشخص می‌کند مسیرهای URL به چه سرویس‌هایی هدایت شوند.

پیکربندی SSL با Ingress

یکی از قابلیت‌های قدرتمند Ingress، پشتیبانی از SSL Termination است که به شما این امکان را می‌دهد تا ترافیک HTTPS را مدیریت کنید. برای پیکربندی SSL، می‌توانید از یک Secret برای ذخیره گواهی‌نامه و کلید خصوصی استفاده کنید.

مثال پیکربندی SSL در Ingress:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/ssl-redirect: "true"
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: my-app-service
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: example-com-tls

در این پیکربندی:

• tls: بخش TLS که شامل تنظیمات گواهی SSL است.
  • hosts: دامنه‌هایی که باید SSL برای آن‌ها فعال باشد.
  • secretName: نام Secret که شامل گواهی‌نامه و کلید خصوصی است.
• annotations: تنظیماتی برای مشخص کردن رفتارهای خاص، مانند هدایت ترافیک HTTP به HTTPS.

ایجاد Ingress

پس از تعریف فایل YAML، شما می‌توانید Ingress Resource خود را با استفاده از دستور kubectl در کلاستر ایجاد کنید:

kubectl apply -f my-ingress.yaml

این دستور فایل YAML را به کلاستر Kubernetes ارسال کرده و Ingress را ایجاد می‌کند.

مشاهده Ingress ایجاد شده

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

kubectl get ingress my-ingress

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

جمع‌بندی

استفاده از Ingress Resources در Kubernetes به شما این امکان را می‌دهد که ترافیک ورودی HTTP و HTTPS را به صورت دقیق و با پیکربندی‌های پیشرفته مانند مسیریابی URL، SSL Termination، و دسترسی به سرویس‌های مختلف مدیریت کنید. برای راه‌اندازی Ingress در Kubernetes، باید یک Ingress Controller نصب کرده باشید و سپس از Ingress Resource برای پیکربندی قوانین مسیریابی استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Ingress Resources: مدیریت درخواست‌های HTTP/HTTPS” subtitle=”توضيحات کامل”]در کوبرنتیز، Ingress Resources ابزاری قدرتمند برای مدیریت درخواست‌های HTTP و HTTPS ورودی به کلاستر است. این منابع به شما این امکان را می‌دهند که ترافیک ورودی را به سرویس‌های مختلف در کلاستر هدایت کنید، بر اساس URL ها، دامنه‌ها، و حتی شرایط خاص درخواست‌ها. Ingress یک راه حل انعطاف‌پذیر و مقیاس‌پذیر برای مدیریت دسترسی به برنامه‌ها و سرویس‌ها است که می‌تواند به شما کمک کند تا از Load Balancer‌ها و درخواست‌های خارج از کلاستر به راحتی استفاده کنید.

مدیریت درخواست‌های HTTP/HTTPS با Ingress

با استفاده از Ingress Resources، شما می‌توانید قوانین مسیریابی پیچیده برای درخواست‌های HTTP و HTTPS بسازید. این درخواست‌ها می‌توانند به سرویس‌های مختلف هدایت شوند، بر اساس مسیر URL و حتی دامنه درخواست.

مثال پیکربندی Ingress برای مسیریابی HTTP/HTTPS

در اینجا یک مثال از یک Ingress Resource برای مدیریت درخواست‌های HTTP و HTTPS آورده شده است که درخواست‌ها را به دو سرویس مختلف هدایت می‌کند.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /app1
        pathType: Prefix
        backend:
          service:
            name: app1-service
            port:
              number: 80
      - path: /app2
        pathType: Prefix
        backend:
          service:
            name: app2-service
            port:
              number: 80
  tls:
  - hosts:
    - example.com
    secretName: example-com-tls

توضیحات:

• host: تعیین می‌کند که ترافیک برای کدام دامنه یا میزبان هدایت می‌شود. در اینجا، example.com است.
• http: این بخش شامل تنظیمات مسیریابی HTTP است. برای هر مسیر (path)، درخواست‌ها به سرویس خاصی هدایت می‌شوند.
  • path: مسیر URL برای مسیریابی درخواست‌ها. مثلا /app1 یا /app2.
  • pathType: نوع مسیر که می‌تواند Prefix یا Exact باشد. در اینجا از Prefix استفاده شده است، یعنی هر مسیری که با /app1 یا /app2 شروع شود، به سرویس مربوطه هدایت می‌شود.
  • backend: این بخش مشخص می‌کند که درخواست‌ها به کدام سرویس و پورت هدایت شوند.
• tls: تنظیمات SSL برای هدایت ترافیک HTTPS. در اینجا، یک Secret به نام example-com-tls برای نگهداری گواهی SSL استفاده می‌شود.

فعال‌سازی Ingress

پس از ایجاد فایل YAML مربوط به Ingress، می‌توانید آن را به کلاستر خود ارسال کنید:

kubectl apply -f my-ingress.yaml

این دستور Ingress Resource را به کلاستر شما اضافه می‌کند و مسیرها و قوانین تعیین‌شده را فعال می‌کند.

مشاهده وضعیت Ingress

برای بررسی وضعیت و جزئیات Ingress خود، از دستور زیر استفاده کنید:

kubectl get ingress my-ingress

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

جمع‌بندی

استفاده از Ingress Resources برای مدیریت درخواست‌های HTTP و HTTPS به شما این امکان را می‌دهد که ترافیک ورودی را به صورت دقیق‌تری مدیریت کنید. می‌توانید درخواست‌ها را بر اساس دامنه، مسیر، و حتی شرایط SSL به سرویس‌های مختلف هدایت کنید. Ingress یک ابزار بسیار کاربردی برای ساده‌تر کردن مسیریابی و مدیریت درخواست‌های ورودی در Kubernetes است و همچنین از امکاناتی مانند SSL Termination و مسیریابی پیشرفته پشتیبانی می‌کند.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از TLS برای امنیت بیشتر در Ingress” subtitle=”توضيحات کامل”]یکی از مهم‌ترین جنبه‌های امنیت در Kubernetes و به‌طور خاص در Ingress، استفاده از TLS (Transport Layer Security) است. با استفاده از TLS، ترافیک بین کاربران و سرویس‌ها می‌تواند به‌طور ایمن از طریق پروتکل HTTPS منتقل شود. این امر موجب محافظت در برابر حملات مانند Man-in-the-Middle (MITM) می‌شود و باعث رمزگذاری داده‌ها در مسیر ارتباطی می‌گردد. در این بخش، به نحوه پیکربندی TLS در Ingress Resources و استفاده از آن برای ایجاد یک ارتباط امن می‌پردازیم.

مراحل پیکربندی TLS در Ingress

1. ایجاد یک Secret برای گواهی SSLبرای استفاده از TLS در Kubernetes، ابتدا باید یک گواهی SSL معتبر ایجاد کنید و آن را به‌عنوان یک Secret در Kubernetes ذخیره کنید. این Secret شامل گواهی SSL و کلید خصوصی مربوط به آن خواهد بود.برای ایجاد یک Secret حاوی گواهی و کلید خصوصی، از دستور زیر استفاده می‌کنیم:

   kubectl create secret tls example-com-tls \
   --cert=/path/to/cert.crt \
   --key=/path/to/cert.key
   

   در اینجا:

   • example-com-tls نام Secret است.
   • --cert مسیر فایل گواهی SSL است.
   • --key مسیر فایل کلید خصوصی است.
2. پیکربندی TLS در Ingress Resourceپس از ایجاد Secret، باید آن را به Ingress Resource متصل کنید. در فایل YAML مربوط به Ingress، می‌توانید از بخش tls برای تعریف گواهی SSL استفاده کنید و درخواست‌های ورودی را از HTTP به HTTPS هدایت کنید.اینجا یک مثال از پیکربندی Ingress با TLS است:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: my-ingress
     annotations:
       nginx.ingress.kubernetes.io/rewrite-target: /
   spec:
     rules:
     - host: example.com
       http:
         paths:
         - path: /
           pathType: Prefix
           backend:
             service:
               name: my-service
               port:
                 number: 80
     tls:
     - hosts:
       - example.com
       secretName: example-com-tls
   

   در اینجا:

   • بخش tls شامل hosts است که نشان‌دهنده دامنه‌هایی است که از TLS استفاده می‌کنند.
   • secretName نام Secret است که شامل گواهی SSL و کلید خصوصی است.
3. فعال‌سازی Ingress با TLSپس از ایجاد فایل YAML برای Ingress، می‌توانید آن را با استفاده از دستور kubectl apply به Kubernetes اضافه کنید:

   kubectl apply -f my-ingress.yaml
   

   این دستور Ingress با پیکربندی TLS را به کلاستر اضافه می‌کند و از این پس درخواست‌های HTTP به HTTPS هدایت خواهند شد.

4. آزمایش و بررسی وضعیتبرای بررسی وضعیت Ingress و تأیید اینکه TLS به درستی پیکربندی شده است، از دستور زیر استفاده کنید:

   kubectl describe ingress my-ingress
   

   این دستور جزئیات مربوط به Ingress و وضعیت TLS را نمایش می‌دهد.

نکات مهم

• TLS Termination: با استفاده از TLS در Ingress، می‌توانید ترافیک HTTPS را در سطح Ingress متوقف کرده و آن را به صورت HTTP به سرویس‌ها ارسال کنید. این فرآیند به نام TLS Termination شناخته می‌شود.
• Self-signed Certificates: در صورتی که از گواهی‌نامه‌های خودامضا (self-signed) استفاده می‌کنید، باید اطمینان حاصل کنید که مرورگرها یا مشتریان قادر به اعتماد به این گواهی‌ها هستند.
• گواهی‌های معتبر از یک مرجع قابل اعتماد: برای جلوگیری از مشکلات امنیتی، توصیه می‌شود از گواهی‌های صادر شده توسط یک مرجع معتبر (CA) استفاده کنید.

جمع‌بندی

استفاده از TLS در Ingress Resources یکی از مهم‌ترین راه‌ها برای ایمن‌سازی ترافیک HTTP و HTTPS است. با تنظیم صحیح TLS در Ingress، می‌توانید اطمینان حاصل کنید که داده‌ها به صورت رمزگذاری‌شده و ایمن از کاربران به سرویس‌ها منتقل می‌شوند. این کار علاوه بر افزایش امنیت، همچنین امکان استفاده از SSL Termination را برای کاهش بار پردازشی بر روی سرویس‌ها فراهم می‌آورد.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مثال عملی: پیکربندی یک مسیر HTTP به چند Backend” subtitle=”توضيحات کامل”]در این مثال، قصد داریم یک مسیر HTTP واحد را به چندین Backend (سرویس) در Kubernetes هدایت کنیم. این می‌تواند برای تقسیم بار و ارائه خدمات مختلف در یک مسیر خاص مفید باشد. برای این کار از Ingress در Kubernetes استفاده می‌کنیم تا درخواست‌های ورودی HTTP را بر اساس مسیر یا ویژگی‌های دیگر به سرویس‌های مختلف هدایت کنیم.

سناریو

فرض کنید دو سرویس داریم:

1. web-service: این سرویس مربوط به صفحه اصلی وب‌سایت است.
2. api-service: این سرویس برای ارائه API است.

هدف ما این است که درخواست‌های ورودی HTTP را بر اساس مسیر URL به این دو سرویس هدایت کنیم:

• درخواست‌هایی که به /web می‌آیند، باید به web-service هدایت شوند.
• درخواست‌هایی که به /api می‌آیند، باید به api-service هدایت شوند.

مراحل پیکربندی

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

   web-service.yaml:

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

   api-service.yaml:

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

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

   kubectl apply -f web-service.yaml
   kubectl apply -f api-service.yaml
   

2. ایجاد Ingress Resourceحالا که سرویس‌ها را ایجاد کردیم، باید یک Ingress بسازیم که درخواست‌ها را بر اساس مسیر به سرویس‌های مختلف هدایت کند. در اینجا، از یک فایل YAML برای پیکربندی Ingress Resource استفاده می‌کنیم.

   ingress.yaml:

   apiVersion: networking.k8s.io/v1
   kind: Ingress
   metadata:
     name: multi-backend-ingress
   spec:
     rules:
     - host: example.com
       http:
         paths:
         - path: /web
           pathType: Prefix
           backend:
             service:
               name: web-service
               port:
                 number: 80
         - path: /api
           pathType: Prefix
           backend:
             service:
               name: api-service
               port:
                 number: 80
   

   در این پیکربندی:

   • درخواست‌هایی که به /web می‌آیند به web-service هدایت می‌شوند.
   • درخواست‌هایی که به /api می‌آیند به api-service هدایت می‌شوند.
3. استفاده از Ingress Controllerبرای اینکه Ingress بتواند درخواست‌ها را هدایت کند، باید Ingress Controller روی کلاستر Kubernetes شما نصب شده باشد. یکی از معروف‌ترین Ingress Controllerها، NGINX Ingress Controller است.

   اگر Ingress Controller نصب نشده باشد، می‌توانید از دستور زیر برای نصب آن استفاده کنید:

   kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/cloud/deploy.yaml
   

4. اعمال پیکربندی Ingressحالا که فایل Ingress آماده است، می‌توانیم آن را به کلاستر اعمال کنیم:

   kubectl apply -f ingress.yaml
   

5. آزمایش پیکربندیپس از اعمال پیکربندی، می‌توانید از دستور زیر برای بررسی وضعیت Ingress استفاده کنید:

   kubectl get ingress multi-backend-ingress
   

   اگر همه چیز به درستی پیکربندی شده باشد، باید آدرس IP یا URL Ingress را مشاهده کنید.

   سپس می‌توانید با استفاده از دستور curl یا مرورگر خود درخواست‌های HTTP به مسیرهای مختلف ارسال کنید و مطمئن شوید که درخواست‌ها به درستی به سرویس‌های مربوطه هدایت می‌شوند:

   curl http://example.com/web
   curl http://example.com/api
   

جمع‌بندی

در این مثال، نحوه پیکربندی یک مسیر HTTP به چند Backend مختلف را در Kubernetes بررسی کردیم. با استفاده از Ingress Resource و Ingress Controller، توانستیم درخواست‌های HTTP را بر اساس مسیرهای URL به سرویس‌های مختلف هدایت کنیم. این کار می‌تواند در مواردی مانند تقسیم بار و مدیریت درخواست‌های ورودی در اپلیکیشن‌های پیچیده بسیار مفید باشد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. DNS داخلی در Kubernetes”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نقش CoreDNS در Kubernetes” subtitle=”توضيحات کامل”]CoreDNS یکی از اجزای حیاتی و اساسی در کلاستر Kubernetes است که به عنوان سیستم DNS (Domain Name System) پیش‌فرض عمل می‌کند. DNS یکی از اجزای کلیدی برای برقراری ارتباط بین اجزای مختلف کلاستر Kubernetes است و CoreDNS این مسئولیت را به عهده دارد.

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

1. نقش CoreDNS در Kubernetes:

• نام‌گذاری سرویس‌ها و پادها: هر پاد و سرویس در Kubernetes معمولاً یک نام DNS مخصوص به خود دارد. CoreDNS مسئول ترجمه این نام‌ها به آدرس‌های IP مناسب است. برای مثال، زمانی که یک پاد به نام web-app در فضای default درخواست DNS می‌دهد، CoreDNS آدرس IP مرتبط با آن را برمی‌گرداند.
• پشتیبانی از سرویس‌های داخلی: یکی از ویژگی‌های مهم CoreDNS این است که درخواست‌های DNS که برای سرویس‌ها در داخل کلاستر ارسال می‌شوند را مدیریت می‌کند. وقتی پاد یا سرویس از داخل کلاستر به درخواست‌های DNS نیاز دارد، CoreDNS به عنوان یک سرور DNS داخلی عمل می‌کند.
• انتقال درخواست‌های DNS خارجی: علاوه بر پاسخ به درخواست‌های DNS داخلی، CoreDNS قادر است درخواست‌های DNS خارجی را به سرورهای DNS عمومی (مثل Google DNS یا Cloudflare DNS) هدایت کند. این به کاربران اجازه می‌دهد که پادها و سرویس‌های داخلی همزمان بتوانند به منابع خارجی دسترسی داشته باشند.

2. نحوه عملکرد CoreDNS:

CoreDNS به صورت یک پاد در کلاستر Kubernetes مستقر است. این پاد به صورت یک Deployment اجرا می‌شود و معمولاً در فضای نام kube-system قرار دارد.

• پیکربندی CoreDNS: پیکربندی CoreDNS از طریق یک ConfigMap انجام می‌شود که به نام coredns در فضای نام kube-system ذخیره می‌شود. این ConfigMap شامل قوانین و تنظیماتی است که CoreDNS برای پردازش درخواست‌های DNS باید دنبال کند.
• اجرای CoreDNS به عنوان سرویس: CoreDNS به عنوان یک سرویس DNS در Kubernetes عمل می‌کند و تمامی پادها و سرویس‌ها برای ارتباط با یکدیگر به آن متکی هستند. هر پاد باید آدرس DNS سرور CoreDNS را در تنظیمات خود داشته باشد تا بتواند به راحتی با سرویس‌های دیگر ارتباط برقرار کند.

3. پیکربندی CoreDNS در Kubernetes:

برای مشاهده پیکربندی CoreDNS و تغییرات لازم در آن، می‌توانید از دستور kubectl برای مشاهده ConfigMap استفاده کنید:

kubectl get configmap coredns -n kube-system -o yaml

در این پیکربندی، شما می‌توانید تنظیمات مختلفی از جمله قوانین برای مسیریابی درخواست‌های DNS، آدرس‌های DNS برای درخواست‌های خارجی، و سایر تنظیمات را مشاهده و تغییر دهید.

4. پیکربندی مثال: تغییر DNS Backend

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

برای مثال، به‌روزرسانی پیکربندی به این شکل که CoreDNS درخواست‌های DNS برای دامنه‌های خاصی را به سرورهای DNS خاصی هدایت کند:

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
      errors
      health
      redis
      forward . 8.8.8.8 8.8.4.4
      cache 30
      loop
      reload
      bind 0.0.0.0
      prometheus :9153
    }

در این پیکربندی:

• forward . 8.8.8.8 8.8.4.4 به این معناست که درخواست‌های DNS خارجی به سرورهای DNS گوگل (Google DNS) ارسال می‌شوند.

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

kubectl apply -f coredns-configmap.yaml

5. مانیتورینگ و نظارت بر CoreDNS:

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

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

kubectl get pods -n kube-system -l k8s-app=kube-dns

جمع‌بندی

CoreDNS در Kubernetes به عنوان سیستم DNS داخلی کلاستر عمل می‌کند و نقش کلیدی در فراهم کردن ارتباط بین پادها، سرویس‌ها و منابع خارجی دارد. پیکربندی و نظارت بر CoreDNS از طریق ConfigMapها و پورت‌های مانیتورینگ انجام می‌شود و این ابزار به طور مؤثری درخواست‌های DNS را مدیریت می‌کند. CoreDNS برای عملکرد مناسب کلاستر Kubernetes ضروری است و به مدیران کمک می‌کند تا درخواست‌ها را به صورت بهینه هدایت و مدیریت کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”درک DNS داخلی و نحوه دسترسی به سرویس‌ها” subtitle=”توضيحات کامل”]DNS داخلی در Kubernetes به عنوان یک سیستم مدیریت نام‌گذاری برای سرویس‌ها و پادها عمل می‌کند و امکان ارتباط میان اجزای مختلف کلاستر را فراهم می‌آورد. Kubernetes به‌طور خودکار برای هر سرویس یک رکورد DNS ایجاد می‌کند و این سرویس‌ها از طریق نام‌های DNS به جای استفاده از آدرس‌های IP به یکدیگر متصل می‌شوند. این قابلیت باعث می‌شود که پادها و سرویس‌ها بتوانند به راحتی و بدون نگرانی از تغییرات IP، با یکدیگر ارتباط برقرار کنند.

1. DNS داخلی در Kubernetes چیست؟

در Kubernetes، هر سرویس ایجاد شده یک نام DNS خاص دارد که به طور خودکار برای آن سرویس از طریق CoreDNS (یا سرویس DNS دیگر که انتخاب شده باشد) ترجمه می‌شود. این نام‌های DNS برای دسترسی به سرویس‌ها، پادها و دیگر منابع کلاستر از اهمیت بالایی برخوردار هستند.

نام DNS سرویس‌ها به این صورت است:

<service-name>.<namespace>.svc.cluster.local

• : نام سرویس که توسط Kubernetes ایجاد می‌شود.
• : فضای نام (namespace) که سرویس در آن قرار دارد.
• svc: این علامت به سرویس اشاره دارد.
• cluster.local: این دامنه به‌طور پیش‌فرض به تمام کلاسترهای Kubernetes اعمال می‌شود.

این ساختار به Kubernetes کمک می‌کند تا از طریق DNS داخلی به راحتی نام‌ها را به آدرس‌های IP تبدیل کرده و ترافیک شبکه را هدایت کند.

2. نحوه دسترسی به سرویس‌ها از طریق DNS داخلی

با استفاده از DNS داخلی، پادها و سرویس‌ها می‌توانند بدون نیاز به آدرس‌های IP سخت‌کد شده به یکدیگر دسترسی پیدا کنند. برای مثال، اگر سرویس web-service در فضای نام default قرار داشته باشد، سایر پادها می‌توانند به راحتی با استفاده از نام DNS زیر به آن دسترسی پیدا کنند:

web-service.default.svc.cluster.local

این امکان باعث می‌شود که نیاز به مدیریت دستی IPها کاهش یابد و Kubernetes این کار را به صورت خودکار انجام دهد.

3. روش‌های دسترسی به سرویس‌ها از طریق DNS داخلی

برای استفاده از DNS داخلی Kubernetes در پادها و سرویس‌ها، از روش‌های زیر می‌توان استفاده کرد:

• دسترسی از داخل کلاستر (بین پادها): هنگامی که یک پاد نیاز به دسترسی به سرویس‌ها و پادهای دیگر در همان کلاستر دارد، می‌تواند از نام DNS سرویس استفاده کند.
• دسترسی از خارج کلاستر (از طریق سرویس‌های NodePort یا LoadBalancer): اگر بخواهید سرویس‌ها را از خارج کلاستر دسترسی داشته باشید، می‌توانید از سرویس‌های مانند NodePort یا LoadBalancer استفاده کنید. در این حالت، ترافیک از طریق یک آدرس خارجی وارد می‌شود و Kubernetes آن را به سرویس‌های داخلی هدایت می‌کند.

4. پیکربندی DNS داخلی در Kubernetes

DNS داخلی به طور خودکار با استفاده از سرویس‌های kube-dns یا CoreDNS راه‌اندازی می‌شود. این سرویس‌ها معمولاً به طور پیش‌فرض در فضای نام kube-system قرار دارند و به صورت خودکار برای تمام کلاستر DNS داخلی ارائه می‌دهند.

اگر بخواهید پیکربندی DNS را بررسی کنید، می‌توانید از دستور زیر برای مشاهده وضعیت CoreDNS استفاده کنید:

kubectl get pods -n kube-system -l k8s-app=kube-dns

5. چگونه از DNS داخلی برای اتصال به سرویس‌ها استفاده کنیم؟

برای مثال، فرض کنید که یک سرویس به نام mysql-service دارید که در فضای نام default قرار دارد. اگر بخواهید از داخل پاد دیگری به این سرویس دسترسی پیدا کنید، کافی است از نام DNS آن استفاده کنید. برای مثال:

mysql-service.default.svc.cluster.local

این نام به‌طور خودکار به IP مربوط به سرویس mysql-service ترجمه می‌شود و ارتباط برقرار می‌کند.

6. پیکربندی DNS در CoreDNS

پیکربندی DNS در Kubernetes از طریق ConfigMap انجام می‌شود که به نام coredns در فضای نام kube-system ذخیره شده است. برای مشاهده پیکربندی DNS، از دستور زیر استفاده کنید:

kubectl get configmap coredns -n kube-system -o yaml

در این پیکربندی، می‌توانید تنظیمات مختلفی مانند مدیریت درخواست‌های DNS، Forwarding به DNS خارجی و Cache را مشاهده و تغییر دهید.

7. مشکلات رایج در DNS داخلی و نحوه رفع آن‌ها

• DNS Cache و تاخیر: برخی از مشکلات ممکن است ناشی از کش شدن نتایج DNS در پادها یا CoreDNS باشد. برای رفع این مشکل، می‌توان کش DNS را پاک کرده و یا تنظیمات کش را در CoreDNS تغییر داد.
• عدم اتصال سرویس‌ها: اگر پادی قادر به پیدا کردن سرویس‌ها از طریق DNS نیست، ممکن است مشکل در پیکربندی CoreDNS یا در پیکربندی سرویس‌ها وجود داشته باشد. برای بررسی مشکلات DNS، از دستور زیر برای مشاهده وضعیت CoreDNS استفاده کنید:

  kubectl logs -n kube-system -l k8s-app=kube-dns
  

جمع‌بندی

DNS داخلی در Kubernetes یک بخش حیاتی از معماری شبکه‌ای است که امکان اتصال سرویس‌ها و پادها را فراهم می‌آورد. با استفاده از نام‌های DNS خودکار که به پادها و سرویس‌ها اختصاص داده می‌شود، Kubernetes به مدیران این امکان را می‌دهد که بدون نیاز به مدیریت دستی IPها، ارتباطات شبکه‌ای میان اجزای کلاستر را ساده‌تر کنند. پیکربندی این DNS از طریق CoreDNS انجام می‌شود که می‌توان آن را سفارشی‌سازی کرده و مشکلات احتمالی را برطرف کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از FQDN (Fully Qualified Domain Name) برای Pods و Services” subtitle=”توضيحات کامل”]در Kubernetes، هر پاد (Pod) و سرویس (Service) به طور خودکار یک نام دامنه کامل (FQDN) دریافت می‌کند که برای شناسایی و ارتباط با سایر اجزا در کلاستر به کار می‌رود. این مفهوم از DNS داخلی Kubernetes بهره‌برداری می‌کند و به مدیریت ارتباطات شبکه‌ای بین پادها و سرویس‌ها کمک می‌کند.

1. FQDN چیست؟

FQDN یا Fully Qualified Domain Name یک نام دامنه است که به طور کامل و دقیق به یک میزبان (host) در یک شبکه اشاره می‌کند. این نام شامل همه قسمت‌های مسیر دامنه است که به‌طور خاص به یک سرویس یا پاد خاص در کلاستر اشاره دارد.

برای مثال، در Kubernetes، FQDN برای یک سرویس به صورت زیر خواهد بود:

<service-name>.<namespace>.svc.cluster.local

در این ساختار:

• : نام سرویس.
• : فضای نام که سرویس در آن قرار دارد.
• svc: اشاره به نوع منبع (Service).
• cluster.local: دامنه پیش‌فرض در Kubernetes برای دسترسی به منابع داخل کلاستر.

برای پادها، FQDN به شکل زیر خواهد بود:

<pod-name>.<namespace>.pod.cluster.local

• : نام پاد.
• : فضای نام که پاد در آن قرار دارد.
• pod: اشاره به نوع منبع (Pod).
• cluster.local: دامنه پیش‌فرض برای کلاستر.

2. نحوه استفاده از FQDN برای دسترسی به سرویس‌ها و پادها

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

برای مثال، اگر سرویس web-service در فضای نام default قرار داشته باشد، هر پادی که بخواهد به این سرویس دسترسی پیدا کند می‌تواند از FQDN زیر استفاده کند:

web-service.default.svc.cluster.local

این نام به‌طور خودکار به آدرس IP مربوط به سرویس web-service ترجمه می‌شود.

3. استفاده از FQDN برای برقراری ارتباط بین پادها

در صورتی که یک پاد بخواهد به پاد دیگری در همان کلاستر دسترسی داشته باشد، از FQDN مشابه استفاده می‌کند. اگر پاد app-1 در فضای نام default باشد و بخواهد به پاد app-2 در همان فضای نام دسترسی پیدا کند، می‌تواند از FQDN زیر استفاده کند:

app-2.default.pod.cluster.local

این نام به آدرس IP پاد app-2 ترجمه می‌شود.

4. پیکربندی FQDN در Kubernetes

Kubernetes به طور خودکار FQDN‌ها را برای سرویس‌ها و پادها به کمک سیستم DNS داخلی که معمولا توسط CoreDNS ارائه می‌شود، پیکربندی می‌کند. شما به طور مستقیم نیازی به انجام تنظیمات خاص برای ایجاد FQDN‌ها ندارید، زیرا این کار به‌طور خودکار هنگام ایجاد سرویس‌ها یا پادها انجام می‌شود.

برای مشاهده رکوردهای DNS برای سرویس‌ها و پادهای خود می‌توانید از دستورات زیر استفاده کنید:

برای مشاهده DNS سرویس‌ها:

kubectl get svc -n <namespace>

برای مشاهده DNS پادها:

kubectl get pods -n <namespace>

5. استفاده از FQDN در فایل‌های YAML

در هنگام پیکربندی سرویس‌ها یا پادها در فایل‌های YAML، نام‌ها به طور پیش‌فرض به‌عنوان FQDN مدیریت می‌شوند. برای مثال، اگر بخواهید سرویس mysql را در فضای نام default پیکربندی کنید، تعریف آن به این صورت خواهد بود:

apiVersion: v1
kind: Service
metadata:
  name: mysql
  namespace: default
spec:
  ports:
    - port: 3306
  selector:
    app: mysql

در این مثال، نام mysql.default.svc.cluster.local به‌طور خودکار به IP سرویس ترجمه خواهد شد و می‌توان از آن برای ارتباط با سرویس mysql استفاده کرد.

6. مدیریت FQDN در پیکربندی‌های DNS

اگر بخواهید تنظیمات DNS در Kubernetes را مشاهده و یا تغییر دهید، می‌توانید از دستور زیر برای بررسی پیکربندی DNS استفاده کنید:

kubectl get configmap coredns -n kube-system -o yaml

در این پیکربندی می‌توانید مواردی مانند مدیریت درخواست‌های DNS و تنظیمات مربوط به forwarding را مشاهده و اصلاح کنید.

7. مشکلات رایج FQDN

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

  kubectl logs -n kube-system -l k8s-app=kube-dns
  

• خطا در ترجمه FQDN: در صورتی که سرویس یا پاد نتوانند FQDN را به IP مربوطه ترجمه کنند، احتمالاً DNS در Kubernetes پیکربندی نشده یا مشکلی در آن وجود دارد. برای رفع این مشکل، باید بررسی‌های لازم را روی CoreDNS و پیکربندی آن انجام دهید.

جمع‌بندی

استفاده از FQDN در Kubernetes به‌طور مؤثر امکان ارتباط بین پادها و سرویس‌ها را فراهم می‌کند و نیازی به مدیریت دستی IPها نیست. Kubernetes به‌طور خودکار FQDN‌ها را برای هر سرویس و پاد ایجاد می‌کند و از DNS داخلی برای ترجمه این نام‌ها به IP استفاده می‌کند. این ویژگی باعث ساده‌تر شدن مدیریت ارتباطات شبکه‌ای در کلاستر می‌شود و مشکلات ناشی از تغییرات IP را حل می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دیباگ و رفع مشکلات DNS در Kubernetes” subtitle=”توضيحات کامل”]در Kubernetes، سیستم DNS به‌طور حیاتی برای عملکرد شبکه داخلی کلاستر و دسترسی به سرویس‌ها و پادها از طریق نام‌های دامنه استفاده می‌شود. مشکلات DNS می‌تواند به دلایل مختلفی مانند پیکربندی نادرست، مشکلات در CoreDNS، یا خطاهای شبکه‌ای ایجاد شود. در این بخش، به نحوه دیباگ و رفع مشکلات DNS در Kubernetes می‌پردازیم.

1. بررسی وضعیت CoreDNS

CoreDNS به عنوان سرویس DNS پیش‌فرض در Kubernetes عمل می‌کند. اولین قدم در دیباگ مشکلات DNS، بررسی وضعیت CoreDNS است. برای این کار می‌توانید از دستور زیر استفاده کنید تا وضعیت Pods مربوط به CoreDNS را بررسی کنید:

kubectl get pods -n kube-system -l k8s-app=kube-dns

این دستور تمام Pods مربوط به CoreDNS را نمایش می‌دهد. اگر Pods CoreDNS در وضعیت “CrashLoopBackOff” یا “Error” قرار دارد، به احتمال زیاد مشکل DNS به دلیل نقص در پیکربندی یا اجرای CoreDNS است.

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

kubectl describe pod <pod-name> -n kube-system

در اینجا <pod-name> نام پاد CoreDNS است که می‌خواهید وضعیت آن را بررسی کنید.

2. مشاهده لاگ‌های CoreDNS

اگر Pods CoreDNS به درستی اجرا می‌شوند، اما هنوز مشکل DNS وجود دارد، لاگ‌های CoreDNS می‌تواند اطلاعات مفیدی برای رفع مشکل فراهم کند. برای مشاهده لاگ‌ها، از دستور زیر استفاده کنید:

kubectl logs -n kube-system -l k8s-app=kube-dns

این دستور لاگ‌های تمام Pods مربوط به CoreDNS را نمایش می‌دهد. اگر مشکلی در پردازش درخواست‌های DNS وجود داشته باشد، لاگ‌ها معمولاً شامل پیغام‌های خطا یا هشدار خواهند بود.

3. بررسی پیکربندی CoreDNS

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

kubectl get configmap coredns -n kube-system -o yaml

این دستور پیکربندی CoreDNS را به‌صورت YAML نمایش می‌دهد. در این پیکربندی می‌توانید خطاهای رایج مانند مشکلات مربوط به forwarding، root DNS servers یا سایر تنظیمات را شناسایی کنید.

4. آزمایش DNS با استفاده از Pods

برای بررسی عملکرد DNS و رفع مشکلات، می‌توانید از یک پاد برای انجام آزمایش‌های DNS استفاده کنید. یک پاد ساده ایجاد کنید که قابلیت استفاده از ابزار nslookup یا dig را داشته باشد. برای مثال، شما می‌توانید یک Pod از نوع busybox ایجاد کنید و سپس از آن برای آزمایش DNS استفاده کنید.

برای ایجاد Pod از نوع busybox، از دستور زیر استفاده کنید:

kubectl run -i --tty busybox --image=busybox --restart=Never -- nslookup kubernetes.default.svc.cluster.local

این دستور به‌صورت موقت یک پاد از نوع busybox ایجاد می‌کند و از دستور nslookup برای بررسی نام دامنه kubernetes.default.svc.cluster.local استفاده می‌کند. اگر DNS به درستی پیکربندی شده باشد، خروجی باید IP مربوط به سرویس kubernetes را نمایش دهد.

5. بررسی سرویس‌های DNS در کلاستر

اگر مشکل مربوط به سرویس DNS است، باید بررسی کنید که سرویس‌های مربوط به DNS به درستی ایجاد شده‌اند. برای این کار می‌توانید از دستور زیر برای بررسی سرویس‌های موجود در فضای نام kube-system استفاده کنید:

kubectl get svc -n kube-system

این دستور لیستی از تمام سرویس‌ها را در فضای نام kube-system نمایش می‌دهد. سرویس DNS باید به‌طور پیش‌فرض با نام kube-dns یا coredns موجود باشد. اگر این سرویس‌ها در لیست نیستند، باید آنها را دوباره ایجاد کنید.

6. بررسی Policy‌های شبکه‌ای (Network Policies)

در برخی از موارد، مشکلات DNS ممکن است به دلیل اعمال Network Policies در Kubernetes باشد که دسترسی به CoreDNS را محدود می‌کنند. برای بررسی این مورد، می‌توانید از دستور زیر برای مشاهده Network Policies موجود در کلاستر استفاده کنید:

kubectl get networkpolicy --all-namespaces

در صورتی که یکی از Network Policies مانع از دسترسی به سرویس‌های DNS شده باشد، باید آن را به‌روزرسانی یا حذف کنید.

7. مشکلات DNS با سرویس‌های خارجی

اگر DNS به درستی در کلاستر کار می‌کند اما شما قادر به دسترسی به سرویس‌های خارجی نیستید، ممکن است تنظیمات DNS Forwarding در CoreDNS نیاز به بررسی داشته باشد. در این حالت، باید مطمئن شوید که CoreDNS به درستی به سرورهای DNS خارجی (مانند Google DNS یا OpenDNS) فوروارد می‌کند.

برای اضافه کردن یا تغییر این تنظیمات در CoreDNS، باید ConfigMap مربوطه را ویرایش کنید:

kubectl edit configmap coredns -n kube-system

سپس بخش مربوط به forwarding را به‌روزرسانی کنید. برای مثال:

forward . 8.8.8.8 8.8.4.4

این تنظیمات باعث می‌شود که درخواست‌های DNS به سرورهای DNS گوگل فوروارد شوند.

8. بررسی پادهایی که به DNS نیاز دارند

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

kubectl get pods --all-namespaces -o wide

اگر پادی که دچار مشکل DNS شده است در حال استفاده از DNS است، بررسی دقیق‌تر پیکربندی آن می‌تواند کمک‌کننده باشد.

جمع‌بندی

رفع مشکلات DNS در Kubernetes به مراحل مختلفی از جمله بررسی وضعیت CoreDNS، بررسی لاگ‌ها، و بررسی پیکربندی‌ها نیاز دارد. همچنین باید از ابزارهای تست مانند nslookup برای آزمایش عملکرد DNS استفاده کنید. مشکلات ممکن است ناشی از پیکربندی‌های نادرست یا محدودیت‌های شبکه‌ای باشند، بنابراین لازم است که پیکربندی CoreDNS و Network Policies را نیز مورد بررسی قرار دهید. با استفاده از این ابزارها و دستورات، می‌توانید مشکلات DNS را شناسایی و برطرف کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. مدیریت Traffic Routing”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه مدیریت ترافیک بین Pods و سرویس‌ها در Kubernetes” subtitle=”توضيحات کامل”]در Kubernetes، ترافیک میان Pods و سرویس‌ها (Services) با استفاده از سیستم‌های پیچیده‌ای از قوانین و مدل‌های شبکه مدیریت می‌شود. هدف این سیستم‌ها، توزیع صحیح ترافیک و همچنین ارائه دسترسی آسان به پادها از طریق سرویس‌ها است. در این بخش به نحوه مدیریت ترافیک بین Pods و سرویس‌ها پرداخته می‌شود.

1. مدل شبکه‌ای Kubernetes

در Kubernetes، هر Pod یک IP اختصاصی دارد که از طریق آن می‌تواند با سایر Pods و سرویس‌ها ارتباط برقرار کند. برای مدیریت و مسیریابی ترافیک میان این Pods، Kubernetes از مفاهیم مختلفی استفاده می‌کند.

• ClusterIP: در Kubernetes، هر سرویس به طور پیش‌فرض دارای یک IP اختصاصی به نام ClusterIP است. این IP تنها در داخل کلاستر قابل دسترسی است.
• DNS داخلی: Kubernetes از DNS داخلی برای شناسایی و ارتباط بین سرویس‌ها و Pods استفاده می‌کند. به این صورت که می‌توانید از اسم سرویس‌ها به جای IP ثابت استفاده کنید.
• Load Balancing: Kubernetes از Load Balancer برای توزیع ترافیک ورودی به سرویس‌ها استفاده می‌کند.

2. عملکرد سرویس‌ها (Services) برای مدیریت ترافیک

سرویس‌ها در Kubernetes ابزاری برای دسترسی به Pods هستند که از چندین نوع مختلف برای مدیریت ترافیک استفاده می‌شود. هر نوع سرویس دارای ویژگی‌های خاصی برای مدیریت ترافیک بین Pods است.

• ClusterIP: این سرویس تنها در داخل کلاستر دسترسی دارد و می‌تواند برای مدیریت ترافیک میان Pods مختلف در داخل یک کلاستر استفاده شود.مثال برای ایجاد یک سرویس ClusterIP:

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

• NodePort: این سرویس‌ها امکان دسترسی به سرویس از خارج کلاستر را فراهم می‌کنند. ترافیک از خارج به یک پورت خاص در نودها (Node) هدایت می‌شود و سپس به یکی از Pods ارسال می‌شود.برای ایجاد یک سرویس NodePort:

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

• LoadBalancer: این سرویس‌ها برای استفاده از Load Balancerهای خارجی (مانند آن‌هایی که توسط ارائه‌دهندگان خدمات ابری ارائه می‌شود) استفاده می‌شوند. به این ترتیب ترافیک ورودی از اینترنت به سرویس‌های داخلی Kubernetes هدایت می‌شود.برای ایجاد یک سرویس LoadBalancer:

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

3. توزیع ترافیک با استفاده از Labels و Selectors

Kubernetes از Labels و Selectors برای توزیع ترافیک بین Pods استفاده می‌کند. Selector در سرویس به Kubernetes می‌گوید که ترافیک ورودی باید به کدام پادها ارسال شود. این امکان به شما می‌دهد که فقط ترافیک را به Pods خاصی هدایت کنید.

مثال برای تعریف یک سرویس که ترافیک را به Pods با label خاص هدایت می‌کند:

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

در اینجا، ترافیک ورودی به سرویس my-service تنها به Pods با label app: my-app ارسال می‌شود.

4. استفاده از Kube-proxy برای مدیریت ترافیک

در Kubernetes، Kube-proxy وظیفه مسیریابی ترافیک میان Pods و سرویس‌ها را بر عهده دارد. Kube-proxy به سه روش مختلف می‌تواند ترافیک را مسیریابی کند:

• IPTables: تنظیمات پیش‌فرض که با استفاده از قوانین iptables در کلاستر برای مسیریابی ترافیک عمل می‌کند.
• IPVS: استفاده از تکنولوژی IPVS برای مسیریابی ترافیک با کارایی بالا.
• Userspace: یک روش قدیمی‌تر که در آن ترافیک به برنامه‌ای در فضای کاربر هدایت می‌شود.

5. استفاده از Ingress برای مدیریت ترافیک HTTP(S)

Ingress ابزاری برای مدیریت ترافیک HTTP و HTTPS ورودی به سرویس‌های Kubernetes است. این امکان را می‌دهد که چندین سرویس را با یک IP عمومی و پورت مشترک در معرض دسترسی قرار دهید و مسیریابی پیشرفته برای ترافیک HTTP/HTTPS انجام دهید.

برای پیکربندی یک Ingress برای مدیریت درخواست‌های HTTP:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
    - host: my-app.example.com
      http:
        paths:
          - path: /app
            pathType: Prefix
            backend:
              service:
                name: my-app-service
                port:
                  number: 80

در اینجا، درخواست‌های HTTP به آدرس my-app.example.com/app به سرویس my-app-service ارسال می‌شود.

6. مانیتورینگ و دیباگ ترافیک با kubectl

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

• بررسی وضعیت سرویس‌ها:

  kubectl get svc
  

• بررسی جزئیات سرویس خاص:

  kubectl describe svc my-service
  

• مشاهده لاگ‌های مربوط به Kube-proxy:

  kubectl logs -n kube-system -l k8s-app=kube-proxy
  

جمع‌بندی

مدیریت ترافیک بین Pods و سرویس‌ها در Kubernetes از اهمیت زیادی برخوردار است. از طریق استفاده از سرویس‌ها (ClusterIP، NodePort، LoadBalancer و Ingress)، Kubernetes امکان توزیع و مسیریابی ترافیک میان Pods را به طور موثر فراهم می‌آورد. علاوه بر این، با استفاده از ویژگی‌هایی مانند Labels، Selectors و Kube-proxy می‌توان ترافیک را به صورت هدفمند و بهینه هدایت کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Session Affinity” subtitle=”توضيحات کامل”]Session Affinity یا “چسبندگی نشست” یک ویژگی در Kubernetes است که در سرویس‌ها برای حفظ ارتباط کاربران با یک پاد خاص در طول مدت نشست (session) استفاده می‌شود. این ویژگی اطمینان می‌دهد که درخواست‌های مربوط به یک کاربر (یا یک کلاینت خاص) همیشه به همان پاد ارسال می‌شود تا پایداری و هماهنگی در طول نشست برقرار شود.

1. مفهوم Session Affinity

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

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

2. نحوه فعال‌سازی Session Affinity

برای فعال کردن Session Affinity در یک سرویس Kubernetes، باید ویژگی sessionAffinity را در فایل YAML سرویس تنظیم کنید. این ویژگی به صورت پیش‌فرض برابر با None است، به این معنی که ترافیک به صورت تصادفی بین پادها توزیع می‌شود. اگر بخواهید Session Affinity فعال شود، باید آن را به ClientIP تغییر دهید.

مثال YAML برای فعال‌سازی Session Affinity

در این مثال، یک سرویس با ویژگی Session Affinity به نام my-service ایجاد شده است. این سرویس به گونه‌ای پیکربندی شده که درخواست‌های هر کاربر (بر اساس آدرس IP) همیشه به همان پاد هدایت می‌شود.

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

در اینجا:

• sessionAffinity: ClientIP باعث می‌شود که تمام درخواست‌ها از یک IP خاص به یک پاد خاص هدایت شوند.
• selector برای انتخاب پادهای خاص با برچسب app: my-app استفاده می‌شود.

3. میزان تأثیر Session Affinity

وقتی Session Affinity فعال می‌شود، Kubernetes از IP کلاینت برای شناسایی و هدایت ترافیک استفاده می‌کند. این یعنی که Kubernetes تمام درخواست‌ها از یک IP مشابه را به یک پاد خاص ارسال می‌کند. این ویژگی برای سناریوهایی مفید است که نشست (session) باید در یک پاد خاص ذخیره شود، مانند:

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

4. بررسی و مدیریت Session Affinity با kubectl

پس از فعال‌سازی Session Affinity برای یک سرویس، می‌توانید وضعیت آن را با دستور kubectl describe بررسی کنید. دستور زیر به شما کمک می‌کند تا اطلاعات مربوط به سرویس و ویژگی‌های آن، از جمله Session Affinity، را مشاهده کنید:

kubectl describe svc my-service

این دستور اطلاعات مربوط به سرویس my-service را نشان می‌دهد و شما می‌توانید ویژگی sessionAffinity را بررسی کنید تا ببینید که آیا به درستی فعال شده است یا خیر.

5. مزایای استفاده از Session Affinity

• حفظ حالت نشست: برای برنامه‌هایی که نیاز دارند نشست‌های کاربر را حفظ کنند (مثل سیستم‌های ورود به حساب یا وب‌سایت‌های تجارت الکترونیک).
• سازگاری بهتر با پروتکل‌های stateful: برخی از پروتکل‌ها و برنامه‌ها ممکن است به یک پاد خاص برای پردازش داده‌های یک نشست نیاز داشته باشند.
• کاهش بار اضافی در مدیریت نشست: بدون نیاز به مدیریت نشست‌های مختلف در چندین پاد، تمام درخواست‌های یک کلاینت به یک پاد واحد ارسال می‌شود.

6. محدودیت‌های Session Affinity

• توازن بار غیر یکنواخت: زمانی که Session Affinity فعال باشد، ممکن است برخی از پادها بیشتر از بقیه بار دریافت کنند، زیرا درخواست‌های کاربران خاص همیشه به همان پاد ارسال می‌شود.
• عدم توزیع عادلانه بار: در مقایسه با سرویس‌هایی که از ویژگی sessionAffinity: None استفاده می‌کنند، استفاده از Session Affinity می‌تواند باعث شود که بار به طور مساوی بین پادها تقسیم نشود.
• پایداری با تغییرات IP: در صورتی که IP کلاینت تغییر کند (مثلاً به علت تغییر شبکه یا استفاده از پراکسی)، ممکن است ترافیک به پادهای دیگر هدایت شود که ممکن است مشکلاتی را ایجاد کند.

جمع‌بندی

ویژگی Session Affinity در Kubernetes به شما این امکان را می‌دهد که درخواست‌های یک کاربر خاص همیشه به یک پاد خاص هدایت شوند. این ویژگی برای برنامه‌هایی که به حالت نشست و حفظ ارتباطات دائمی نیاز دارند، مفید است. برای فعال‌سازی Session Affinity، تنها کافیست ویژگی sessionAffinity: ClientIP را در سرویس خود تنظیم کنید. به همین ترتیب، از این ویژگی برای کاهش مشکلات مربوط به توزیع نابرابر بار یا حفظ وضعیت نشست‌های کاربر بهره‌برداری کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Service Annotations برای کنترل رفتار ترافیک” subtitle=”توضيحات کامل”]در کوبرنتیز، Annotations برای افزودن متادیتا یا اطلاعات اضافی به منابع مختلف، مانند سرویس‌ها، استفاده می‌شود. این متادیتا می‌تواند اطلاعاتی در مورد پیکربندی، رفتار یا قابلیت‌های خاص سرویس‌ها باشد که نیاز به تغییر در رفتار آن‌ها دارند. در این بخش به استفاده از Service Annotations برای کنترل رفتار ترافیک پرداخته می‌شود.

1. Service Annotations چیست؟

Annotations در Kubernetes شبیه به Labels هستند، با این تفاوت که آن‌ها برای ذخیره اطلاعات بیشتر و پیچیده‌تر استفاده می‌شوند. این اطلاعات می‌تواند شامل پیکربندی‌های خارجی، تنظیمات مربوط به load balancing و تغییرات در رفتار سرویس‌ها باشد. Annotations هیچ تاثیری بر روی انتخاب یا توزیع ترافیک ندارند بلکه آن‌ها به عنوان ابزارهایی برای هدایت و کنترل رفتار سرویس‌ها به کار می‌روند.

2. استفاده از Service Annotations برای کنترل رفتار Load Balancer

یکی از رایج‌ترین استفاده‌های Annotations در Kubernetes، برای پیکربندی رفتار Load Balancer است که می‌تواند به طور خاص بر رفتار ترافیک و نحوه توزیع آن تأثیر بگذارد. برخی از ارائه‌دهندگان خدمات ابری (مانند AWS یا GCP) از annotations برای تنظیم ویژگی‌های خاص Load Balancer مانند سیاست‌های زمان‌بندی یا مقدار Timeout استفاده می‌کنند.

مثال عملی برای تنظیم رفتار Load Balancer با Annotation:

برای مثال، در سرویس‌هایی که در محیط‌های ابری مانند AWS قرار دارند، می‌توانید از annotation برای تنظیم مقدار Timeout استفاده کنید. در اینجا یک سرویس با Annotation برای تنظیم loadBalancer در AWS نشان داده شده است.

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600"
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

در این مثال، annotation service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout به Load Balancer در AWS اضافه شده و مقدار Timeout اتصال را به 3600 ثانیه تغییر می‌دهد. این تنظیم باعث می‌شود که در صورت عدم فعالیت، اتصال به مدت بیشتری برقرار بماند.

3. کنترل رفتار Session Affinity با Annotations

با استفاده از Session Affinity (یا Sticky Sessions) می‌توانید اطمینان حاصل کنید که ترافیک از یک کاربر خاص همیشه به یک Pod خاص ارسال می‌شود. این کار می‌تواند برای برنامه‌هایی که نیاز به حفظ ارتباط ثابت دارند، مفید باشد. در Kubernetes، این کار معمولاً با استفاده از Annotations انجام می‌شود.

برای مثال، در یک سرویس NodePort، می‌توانید از annotation برای تنظیم Session Affinity به صورت زیر استفاده کنید:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  annotations:
    service.kubernetes.io/session-affinity: "ClientIP"
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  sessionAffinity: ClientIP
  type: NodePort

در اینجا، service.kubernetes.io/session-affinity: "ClientIP" تعیین می‌کند که ترافیک به طور خاص بر اساس آدرس IP کلاینت هدایت شود. این بدان معناست که تمام درخواست‌های از یک IP خاص به همان Pod هدایت می‌شود.

4. استفاده از Annotations برای کنترل Load Balancer در GCP

در پلتفرم Google Cloud Platform (GCP)، annotations مشابهی برای پیکربندی رفتار HTTP(S) Load Balancer وجود دارد. برای مثال، می‌توانید یک annotation برای پیکربندی Backend Configuration در GCP استفاده کنید.

apiVersion: v1
kind: Service
metadata:
  name: my-gcp-service
  annotations:
    networking.gke.io/backend-config: '{"default": "my-backend-config"}'
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

در اینجا، networking.gke.io/backend-config یک annotation است که به GKE (Google Kubernetes Engine) می‌گوید از یک تنظیمات پیکربندی خاص برای Backend استفاده کند.

5. استفاده از Annotations برای پیکربندی Cross-Zone Load Balancing در AWS

اگر سرویس‌های شما در چندین Availability Zone در AWS قرار دارند، می‌توانید از annotations برای فعال یا غیرفعال کردن Cross-Zone Load Balancing استفاده کنید.

apiVersion: v1
kind: Service
metadata:
  name: my-cross-zone-service
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled: "true"
spec:
  selector:
    app: my-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer

در اینجا، annotation service.beta.kubernetes.io/aws-load-balancer-cross-zone-load-balancing-enabled به Load Balancer دستور می‌دهد که ترافیک را به طور متوازن بین نودهای مختلف در چندین Availability Zone توزیع کند.

6. مانیتورینگ و دیباگ Annotations

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

kubectl describe svc my-service

این دستور تمام جزئیات سرویس my-service شامل annotations آن را نمایش می‌دهد.

جمع‌بندی

Service Annotations در Kubernetes ابزاری قدرتمند برای کنترل و تنظیم رفتار ترافیک میان سرویس‌ها هستند. از طریق استفاده از annotations، می‌توان ویژگی‌هایی مانند تنظیمات Load Balancer، Session Affinity و Cross-Zone Load Balancing را به راحتی پیکربندی کرد. این ویژگی‌ها به شما امکان می‌دهند که به صورت دقیق‌تری نحوه توزیع ترافیک و مدیریت بار را کنترل کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مدیریت ترافیک بین نسخه‌های مختلف برنامه‌ها با استفاده از Canary Deployments” subtitle=”توضيحات کامل”]Canary Deployments یک استراتژی قدرتمند برای مدیریت ترافیک میان نسخه‌های مختلف برنامه‌ها در Kubernetes است. این روش به شما اجازه می‌دهد که نسخه جدیدی از برنامه خود را به تدریج و با درصدی محدود از ترافیک در محیط تولید آزمایش کنید. این استراتژی می‌تواند به شما کمک کند تا مشکلات احتمالی را قبل از اینکه بر روی تمام کاربران تأثیر بگذارد شناسایی و رفع کنید.

1. Canary Deployment چیست؟

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

در Kubernetes، این روند معمولاً با استفاده از Deployments و ReplicaSets انجام می‌شود.

2. مزایای Canary Deployments

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

3. نحوه پیاده‌سازی Canary Deployment در Kubernetes

برای پیاده‌سازی Canary Deployment در Kubernetes، شما می‌توانید از Deployments استفاده کنید و ترافیک را میان نسخه‌های مختلف به صورت دستی کنترل کنید. در اینجا یک مثال عملی برای پیاده‌سازی Canary Deployment آورده شده است.

4. ایجاد یک Canary Deployment با استفاده از YAML

در این مثال، ابتدا یک Deployment برای نسخه اصلی (Stable) و سپس یک Deployment برای نسخه جدید (Canary) ایجاد می‌کنیم.

ایجاد Deployment برای نسخه پایدار (Stable)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-stable
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app
      version: stable
  template:
    metadata:
      labels:
        app: my-app
        version: stable
    spec:
      containers:
        - name: my-app
          image: my-app:stable
          ports:
            - containerPort: 8080

در اینجا، تعداد replicas برای نسخه پایدار ۳ است.

ایجاد Deployment برای نسخه Canary

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-canary
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
      version: canary
  template:
    metadata:
      labels:
        app: my-app
        version: canary
    spec:
      containers:
        - name: my-app
          image: my-app:canary
          ports:
            - containerPort: 8080

در اینجا، تعداد replicas برای نسخه Canary فقط ۱ است که نشان‌دهنده حجم کم ترافیک است که به این نسخه هدایت می‌شود.

5. استفاده از Service برای مدیریت ترافیک بین نسخه‌ها

برای مدیریت ترافیک بین این دو نسخه، باید از یک Service استفاده کنیم که ترافیک را به دو نسخه مختلف توزیع کند. این کار معمولاً از طریق تنظیمات labels انجام می‌شود.

ایجاد Service برای توزیع ترافیک

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

این سرویس ترافیک را به هر دو نسخه stable و canary هدایت خواهد کرد. در مرحله بعد، ما می‌توانیم از Traffic Splitting یا روش‌های مختلف توزیع ترافیک برای تقسیم بار بین این دو نسخه استفاده کنیم.

6. توزیع ترافیک بین نسخه‌ها با استفاده از Labels

برای تقسیم ترافیک میان نسخه‌ها، باید از تنظیمات Traffic Splitting استفاده کنید. به طور معمول، این کار توسط ابزارهایی مانند Istio یا Argo Rollouts انجام می‌شود.

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

Istio VirtualService برای تقسیم ترافیک

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: my-app
spec:
  hosts:
    - my-app
  http:
    - route:
        - destination:
            host: my-app
            subset: stable
          weight: 90
        - destination:
            host: my-app
            subset: canary
          weight: 10

در این مثال، ۹۰٪ از ترافیک به نسخه stable و ۱۰٪ از ترافیک به نسخه canary هدایت می‌شود.

7. مراقبت از Canary Deployment

در حین انجام Canary Deployment، لازم است که نظارت دقیقی بر عملکرد نسخه جدید داشته باشید. ابزارهایی مانند Prometheus و Grafana می‌توانند برای نظارت بر متریک‌های مختلف و سلامت نسخه‌های مختلف استفاده شوند.

نظارت بر Canary Deployment با Prometheus

برای پیاده‌سازی نظارت با Prometheus، شما می‌توانید از سرویس‌های Istio یا Prometheus Operator استفاده کنید که به شما امکان می‌دهند تا متریک‌های ترافیک و سلامت Pods را پیگیری کنید.

جمع‌بندی

استفاده از Canary Deployment در Kubernetes یکی از بهترین روش‌ها برای تست نسخه‌های جدید به صورت تدریجی در محیط تولید است. این روش به شما کمک می‌کند که مشکلات احتمالی را شناسایی کرده و از بروز مشکلات بزرگتر جلوگیری کنید. با استفاده از تنظیمات Kubernetes مانند Deployments، Service و ابزارهایی مانند Istio، می‌توانید ترافیک را به صورت کارآمد بین نسخه‌های مختلف برنامه خود مدیریت کنید و به تدریج نسخه جدید را در دسترس کاربران قرار دهید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. Network Policies در Kubernetes”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تعریف و کاربرد Network Policies” subtitle=”توضيحات کامل”]Network Policies در Kubernetes مجموعه‌ای از قوانین (Rules) هستند که برای مدیریت و کنترل ارتباطات شبکه‌ای بین Pods و Services مختلف در داخل یک کلاستر Kubernetes به کار می‌روند. این قوانین به شما این امکان را می‌دهند که مشخص کنید کدام Pods یا منابع می‌توانند با یکدیگر ارتباط برقرار کنند و چه نوع ترافیکی مجاز است.

Network Policies به طور خاص برای ارتقای امنیت شبکه در Kubernetes طراحی شده‌اند و به شما کمک می‌کنند تا بتوانید دسترسی به Pods را محدود کنید و از این طریق ریسک‌های امنیتی ناشی از ارتباطات ناخواسته یا دسترسی غیرمجاز را کاهش دهید.

1. تعریف Network Policy

یک Network Policy در Kubernetes به مجموعه‌ای از قوانین گفته می‌شود که اجازه یا منع برقراری ارتباطات شبکه‌ای بین Pods را می‌دهد. این قوانین می‌توانند شامل:

• Ingress (ورودی): کنترل ترافیک وارد شده به یک Pod.
• Egress (خروجی): کنترل ترافیک خروجی از یک Pod.

این قوانین می‌توانند با استفاده از labels یا IP addresses مشخص شوند و تعیین کنند که کدام Pods یا منابع می‌توانند به یک Pod خاص دسترسی داشته باشند.

2. کاربرد Network Policies

• افزایش امنیت: شما می‌توانید تعیین کنید که فقط Pods خاص یا سرویس‌ها بتوانند به Pods شما دسترسی پیدا کنند.
• محدود کردن دسترسی‌ها: با استفاده از Network Policies، می‌توانید دسترسی به شبکه را محدود کنید و ترافیک‌های غیرضروری یا ناخواسته را مسدود کنید.
• جداسازی محیط‌ها: در محیط‌های چند tenant یا چند محیطی، شما می‌توانید Pods مختلف را از یکدیگر جدا کنید تا ترافیک‌ها به صورت مستقل و امن جریان داشته باشند.
• مدیریت ترافیک: شما می‌توانید ترافیک‌های ورودی و خروجی را برای Pods مختلف مدیریت کنید و از کنترل دقیق‌تری بر ترافیک‌های شبکه‌ای برخوردار شوید.

3. ساختار یک Network Policy

یک Network Policy شامل اطلاعات زیر است:

• Pod Selector: مشخص می‌کند که این Policy به کدام Pods اعمال می‌شود.
• Ingress/Egress Rules: قوانین مربوط به ترافیک‌های ورودی و خروجی.
• Namespace Selector: انتخاب namespace‌ای که این قوانین در آن اعمال می‌شوند.

4. نحوه ایجاد Network Policy

در Kubernetes، می‌توانید Network Policy را با استفاده از YAML تعریف کرده و آن را به یک Pod خاص اعمال کنید. در اینجا یک مثال ساده از تعریف یک Network Policy آورده شده است.

5. مثال ساده از ایجاد یک Network Policy

در این مثال، یک Network Policy ایجاد می‌کنیم که اجازه می‌دهد فقط Pods از namespace default به یک Pod خاص در namespace my-namespace دسترسی داشته باشند.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-default
  namespace: my-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: default
    ports:
    - protocol: TCP
      port: 80

توضیحات:

• podSelector: تعیین می‌کند که این Network Policy به تمام Pods در namespace my-namespace اعمال می‌شود.
• ingress: ترافیک ورودی را از Pods در namespace default اجازه می‌دهد.
• ports: تعیین می‌کند که تنها پورت ۸۰ برای ترافیک ورودی مجاز است.

6. فعال‌سازی Network Policies در Kubernetes

برای استفاده از Network Policies در Kubernetes، باید از یک پلاگین شبکه که از این ویژگی پشتیبانی می‌کند، مانند Calico، Cilium یا Weave استفاده کنید.

برای بررسی اینکه پلاگین شبکه شما از Network Policies پشتیبانی می‌کند یا خیر، می‌توانید از دستور زیر استفاده کنید:

kubectl get pods -n kube-system

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

7. پیاده‌سازی قوانین Egress

اگر بخواهید ترافیک خروجی (Egress) از یک Pod را کنترل کنید، می‌توانید از Network Policy مشابهی استفاده کنید. به عنوان مثال، در اینجا یک سیاست Egress داریم که از خروج ترافیک به internet جلوگیری می‌کند:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-egress
  namespace: my-namespace
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/8
    ports:
    - protocol: TCP
      port: 443

در این مثال، همه Pods در namespace my-namespace اجازه دارند فقط به آدرس‌های IP در محدوده 10.0.0.0/8 ارتباط برقرار کنند و تنها پورت ۴۴۳ (HTTPS) مجاز است.

جمع‌بندی

Network Policies ابزار قدرتمندی برای افزایش امنیت و کنترل دقیق‌تر بر ترافیک شبکه در Kubernetes هستند. این سیاست‌ها به شما امکان می‌دهند تا بر اساس نیازهای امنیتی خود ترافیک بین Pods و سرویس‌ها را کنترل کنید. با استفاده از Network Policies، می‌توانید ارتباطات را محدود کنید و از برقراری دسترسی‌های ناخواسته یا خطرناک جلوگیری کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”محدود سازی ترافیک ورودی و خروجی Pods” subtitle=”توضيحات کامل”]در Kubernetes، می‌توانید از Network Policies برای محدود کردن و کنترل ترافیک ورودی (Ingress) و خروجی (Egress) بین Pods استفاده کنید. این کار به شما کمک می‌کند تا امنیت شبکه را افزایش دهید و اطمینان حاصل کنید که فقط ترافیک مورد نظر به Pods شما وارد یا از آنها خارج می‌شود. در این بخش، نحوه محدودسازی ترافیک ورودی و خروجی را بررسی خواهیم کرد.

1. محدود سازی ترافیک ورودی (Ingress)

با استفاده از Ingress Rules در Network Policy می‌توانید ترافیک ورودی به یک Pod خاص را محدود کنید. این امکان به شما داده می‌شود که فقط برخی از منابع خاص یا آدرس‌های IP خاص به Pods شما دسترسی داشته باشند.

1.1 مثال: محدود کردن ترافیک ورودی به پورت خاص

در این مثال، ترافیک ورودی به پورت 80 فقط از Pods با label خاص مجاز خواهد بود. این کار می‌تواند برای جلوگیری از دسترسی‌های ناخواسته از سایر Pods انجام شود.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-specific-label
  namespace: my-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend
    ports:
    - protocol: TCP
      port: 80

توضیحات:

• podSelector: این بخش انتخاب می‌کند که این سیاست به تمام Pods در namespace my-namespace اعمال شود.
• ingress: محدودیت‌های ترافیک ورودی. تنها Pods با label role: frontend می‌توانند به پورت 80 در Pods در my-namespace دسترسی داشته باشند.

1.2 محدود کردن ترافیک ورودی از یک Namespace خاص

در این مثال، فقط Pods از namespace خاص my-app می‌توانند به Pods در namespace my-namespace دسترسی داشته باشند.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-ingress-from-my-app-namespace
  namespace: my-namespace
spec:
  podSelector: {}
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: my-app
    ports:
    - protocol: TCP
      port: 80

توضیحات:

• namespaceSelector: ترافیک ورودی فقط از Pods در namespace my-app مجاز است.
• ports: پورت 80 مجاز است.

2. محدود سازی ترافیک خروجی (Egress)

با استفاده از Egress Rules در Network Policy می‌توانید کنترل کنید که کدام Pods یا منابع اجازه دارند از یک Pod خاص ترافیک خروجی ارسال کنند. این کار برای جلوگیری از ارسال داده‌ها به منابع ناخواسته یا غیرمجاز مفید است.

2.1 مثال: محدود کردن ترافیک خروجی به یک IP خاص

در این مثال، تمام ترافیک خروجی از Pods به IP‌های خارج از محدوده 192.168.0.0/24 مسدود خواهد شد.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: block-egress-to-outside
  namespace: my-namespace
spec:
  podSelector: {}
  egress:
  - to:
    - ipBlock:
        cidr: 192.168.0.0/24
    ports:
    - protocol: TCP
      port: 443

توضیحات:

• ipBlock: ترافیک خروجی به آدرس‌های IP در محدوده 192.168.0.0/24 فقط مجاز است.
• ports: پورت 443 (HTTPS) برای ترافیک خروجی مجاز است.

2.2 محدود کردن ترافیک خروجی به یک سرویس خاص

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-cluster-services
  namespace: my-namespace
spec:
  podSelector: {}
  egress:
  - to:
    - podSelector: {}
    ports:
    - protocol: TCP
      port: 53  # DNS
  - to:
    - podSelector: {}
    ports:
    - protocol: TCP
      port: 80  # HTTP

توضیحات:

• این سیاست اجازه می‌دهد Pods در namespace my-namespace به سرویس‌های DNS (پورت 53) و HTTP (پورت 80) در داخل کلاستر دسترسی داشته باشند، ولی ترافیک به خارج از کلاستر مسدود می‌شود.

جمع‌بندی

استفاده از Network Policies برای محدودسازی ترافیک ورودی و خروجی در Kubernetes به شما این امکان را می‌دهد که دسترسی به Pods و سرویس‌ها را دقیقاً مطابق با نیازهای امنیتی خود کنترل کنید. می‌توانید ترافیک‌ها را بر اساس آدرس‌های IP، namespace‌ها، labels یا پورت‌ها محدود کنید تا از ارتباطات غیرمجاز جلوگیری کنید.

برای اعمال این Network Policies، مطمئن شوید که از پلاگین‌های شبکه‌ای مانند Calico یا Cilium که از Network Policies پشتیبانی می‌کنند، استفاده می‌کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مثال: ایجاد یک Network Policy برای محدود سازی دسترسی به یک Pod” subtitle=”توضيحات کامل”]در این مثال، یک Network Policy ایجاد می‌کنیم که دسترسی به یک Pod خاص را محدود کند. این سیاست به‌گونه‌ای تنظیم خواهد شد که فقط Pods با label خاص (مثلاً role: frontend) از namespace خاص (مثلاً my-app) بتوانند به Pod هدف دسترسی داشته باشند.

1. شبکه سیاست (Network Policy) برای محدود کردن دسترسی به Pod خاص

در این مثال، فرض می‌کنیم که می‌خواهیم دسترسی به یک Pod خاص را از سایر Pods در کلاستر محدود کنیم. تنها Pods با label role: frontend از namespace my-app مجاز به دسترسی به این Pod خواهند بود.

فایل YAML برای Network Policy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-access-to-specific-pod
  namespace: my-namespace
spec:
  podSelector:
    matchLabels:
      app: target-app  # Pod هدف که دسترسی به آن محدود می‌شود
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: frontend  # فقط Pods با label role: frontend می‌توانند به این Pod دسترسی پیدا کنند
      namespaceSelector:
        matchLabels:
          name: my-app  # فقط از namespace my-app می‌توانند دسترسی داشته باشند
    ports:
    - protocol: TCP
      port: 80  # پورت 80 فقط مجاز است

2. توضیحات:

• podSelector: این بخش انتخاب می‌کند که این Network Policy برای Pods با label app: target-app در namespace my-namespace اعمال شود. بنابراین، دسترسی به این Pod خاص محدود می‌شود.
• ingress: این بخش ترافیک ورودی به Pod را کنترل می‌کند. فقط Pods با label role: frontend که در namespace my-app قرار دارند، می‌توانند به Pod دسترسی پیدا کنند.
• ports: تنها ترافیک ورودی به پورت 80 (پورت HTTP) مجاز است. برای سایر پورت‌ها، ترافیک مسدود خواهد شد.

3. اعمال Network Policy:

پس از تعریف این فایل YAML، برای اعمال آن در کلاستر می‌توانید از دستور kubectl apply استفاده کنید.

kubectl apply -f network-policy.yaml

این دستور Network Policy را در کلاستر Kubernetes شما اعمال می‌کند و از این پس، ترافیک ورودی به Pod target-app در namespace my-namespace فقط از Pods با label role: frontend در namespace my-app مجاز خواهد بود.

جمع‌بندی

با استفاده از Network Policy، می‌توانید دسترسی به Pods خاص را محدود کنید و ترافیک ورودی را از منابع خاص (مانند Pods یا namespaces خاص) به آن Pod کنترل کنید. این کار امنیت کلاستر را افزایش می‌دهد و امکان پیاده‌سازی سیاست‌های دقیق در سطح شبکه را فراهم می‌کند.

توجه: برای استفاده از Network Policies، لازم است که از یک پلاگین شبکه‌ای مانند Calico یا Cilium استفاده کنید که از این ویژگی پشتیبانی می‌کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ابزارهای دیباگ و بررسی Network Policies” subtitle=”توضيحات کامل”]برای بررسی و دیباگ Network Policies در Kubernetes، چند ابزار و روش مختلف وجود دارد که می‌توانید برای تحلیل و شبیه‌سازی رفتار ترافیک شبکه بین Pods از آن‌ها استفاده کنید. این ابزارها به شما کمک می‌کنند تا اطمینان حاصل کنید که Network Policy به درستی پیاده‌سازی شده است و ترافیک مطابق با قوانین تنظیم شده مسدود یا مجاز می‌شود.

1. kubectl describe networkpolicy

با استفاده از این دستور، می‌توانید جزئیات دقیق Network Policy‌های اعمال‌شده روی Pods را مشاهده کنید. این دستور اطلاعاتی شامل قوانین ingress و egress، برچسب‌های انتخاب شده و پورت‌های مجاز را در اختیار شما قرار می‌دهد.

دستور برای مشاهده جزئیات Network Policy:

kubectl describe networkpolicy <network-policy-name>

مثال:

kubectl describe networkpolicy allow-frontend-to-myapp

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

2. kubectl get pods –show-labels

این دستور به شما این امکان را می‌دهد که برچسب‌های اعمال‌شده روی Pods را مشاهده کنید و اطمینان حاصل کنید که Pods مورد نظر به درستی برچسب‌گذاری شده‌اند تا Network Policy برای آن‌ها اعمال شود.

دستور برای مشاهده برچسب‌ها:

kubectl get pods --show-labels

مثال:

kubectl get pods --show-labels

این دستور لیستی از Pods موجود را همراه با برچسب‌های آن‌ها نشان می‌دهد که به شما کمک می‌کند تا برچسب‌های Pods را با Network Policy تطبیق دهید.

3. kubectl exec

در صورتی که بخواهید بررسی کنید که آیا ترافیک از Pods به Pods دیگر به درستی مسدود یا مجاز است، می‌توانید از دستور kubectl exec برای ورود به یک Pod و بررسی اتصال آن به دیگر Pods استفاده کنید. این روش می‌تواند برای دیباگ شبکه و بررسی اتصال‌های TCP/IP مفید باشد.

دستور برای ورود به Pod:

kubectl exec -it <pod-name> -- /bin/bash

مثال:

kubectl exec -it myapp-pod -- /bin/bash

پس از ورود به Pod، می‌توانید از دستوراتی مانند ping یا curl برای بررسی اتصال‌ها و ترافیک شبکه استفاده کنید.

4. Network Policy Logging

در صورتی که از ابزارهای Logging یا Monitoring مثل Prometheus و Grafana یا Fluentd استفاده می‌کنید، می‌توانید لاگ‌های شبکه و رفتار ترافیک در کلاستر را مانیتور کنید. این ابزارها می‌توانند به شما کمک کنند تا رفتار Network Policies را در سطح بالاتر بررسی کنید و مشکلات را شناسایی کنید.

5. Calico (برای شبکه‌های پیشرفته)

اگر از Calico برای مدیریت شبکه استفاده می‌کنید، این ابزار امکانات بیشتری برای بررسی Network Policies دارد. ابزارهایی مانند calicoctl و kubectl calico به شما این امکان را می‌دهند که وضعیت Network Policies را با جزئیات بیشتری بررسی کنید.

دستور برای بررسی وضعیت Network Policy با استفاده از calicoctl:

calicoctl get networkpolicy

این دستور می‌تواند وضعیت Network Policies پیاده‌سازی‌شده توسط Calico را نمایش دهد.

جمع‌بندی

ابزارهای مختلفی مانند kubectl describe, kubectl exec, و ابزارهای مانیتورینگ به شما این امکان را می‌دهند که به‌طور مؤثر Network Policies را در Kubernetes بررسی و دیباگ کنید. با استفاده از این ابزارها می‌توانید مطمئن شوید که ترافیک بین Pods مطابق با تنظیمات شما جریان دارد و قوانین دسترسی به درستی اعمال شده‌اند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. ابزارها و دستورات برای مدیریت شبکه”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl port-forward برای دسترسی به Pods از خارج از Cluster” subtitle=”توضيحات کامل”]ابزار kubectl port-forward یکی از ابزارهای کاربردی در Kubernetes است که به شما امکان می‌دهد تا به راحتی به Pods در داخل کلاستر دسترسی پیدا کنید، حتی اگر این Pods به‌طور مستقیم از طریق IP عمومی یا سرویس‌های Load Balancer قابل دسترسی نباشند.

با استفاده از kubectl port-forward می‌توانید ترافیک شبکه را از یک پورت در ماشین محلی خود به پورت مشابه در یک Pod در کلاستر منتقل کنید. این ابزار به‌طور ویژه برای توسعه‌دهندگان و تست‌کنندگان مفید است که نیاز دارند به‌طور موقت و به‌صورت امن به سرویس‌های در حال اجرا در کلاستر دسترسی پیدا کنند.

دستور پایه برای port-forward

برای انجام port-forwarding، ابتدا باید نام Pod یا Service و پورت‌های مبدا و مقصد را مشخص کنید. به‌طور پیش‌فرض، kubectl port-forward فقط ترافیک HTTP/HTTPS را از پورت مشخص‌شده به Pod شما هدایت می‌کند.

دستور پایه:

kubectl port-forward <pod-name> <local-port>:<pod-port>

مثال:

اگر بخواهید به یک Pod به نام myapp-pod که در پورت 8080 در حال اجرا است از ماشین محلی دسترسی پیدا کنید، دستور زیر را اجرا کنید:

kubectl port-forward myapp-pod 8080:8080

در این مثال، پورت 8080 از Pod myapp-pod به پورت 8080 در ماشین محلی شما هدایت می‌شود. حالا می‌توانید از طریق localhost:8080 در مرورگر خود به سرویس داخل کلاستر دسترسی داشته باشید.

استفاده از port-forward برای Services

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

kubectl port-forward service/<service-name> <local-port>:<service-port>

مثال:

اگر بخواهید به یک سرویس به نام myapp-service که در پورت 8080 در حال اجرا است از ماشین محلی دسترسی پیدا کنید، دستور زیر را اجرا کنید:

kubectl port-forward service/myapp-service 8080:8080

در این حالت، ترافیک از پورت 8080 ماشین محلی شما به پورت 8080 در سرویس myapp-service هدایت می‌شود.

چندین پورت برای port-forward

اگر بخواهید چندین پورت را از ماشین محلی به Pods هدایت کنید، می‌توانید چندین پارامتر <local-port>:<pod-port> را به دستور اضافه کنید.

دستور برای port-forward چندین پورت:

kubectl port-forward <pod-name> <local-port-1>:<pod-port-1> <local-port-2>:<pod-port-2>

مثال:

kubectl port-forward myapp-pod 8080:8080 9090:9090

در این مثال، پورت‌های 8080 و 9090 از Pod به پورت‌های مشابه در ماشین محلی هدایت می‌شوند.

محدودیت‌های kubectl port-forward

• محدودیت‌های امنیتی: استفاده از kubectl port-forward ممکن است محدودیت‌های امنیتی در سازمان شما داشته باشد زیرا دسترسی به Pods را از بیرون کلاستر فراهم می‌کند. بنابراین باید مراقب استفاده از آن باشید.
• زمان محدود: kubectl port-forward به‌صورت موقت و تنها برای مدت زمانی که دستور در حال اجرا است، فعال است. پس از اتمام دستور، دسترسی از بین می‌رود.
• کاربردهای توسعه و تست: این ابزار عمدتاً برای توسعه‌دهندگان و تست‌کنندگان مفید است و برای استفاده در محیط‌های تولیدی پیشنهاد نمی‌شود.

مسیر فایل‌ها برای استفاده از port-forward

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

جمع‌بندی

ابزار kubectl port-forward یکی از ابزارهای ساده و کاربردی برای دسترسی به Pods در داخل Kubernetes است. این ابزار به شما این امکان را می‌دهد تا ترافیک شبکه را به‌صورت امن از بیرون کلاستر به پورت‌های داخلی هدایت کنید. این روش برای توسعه و تست بسیار مفید است، ولی در محیط‌های تولیدی نیاز به بررسی‌های امنیتی دقیق‌تری دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دیباگ مشکلات شبکه” subtitle=”توضيحات کامل”]برای دیباگ و رفع مشکلات شبکه در Kubernetes، ابزارهایی همچون kubectl get services، kubectl describe services و kubectl get endpoints بسیار مفید هستند. این دستورات به شما امکان می‌دهند تا وضعیت سرویس‌ها، پیکربندی‌ها و نقاط پایانی (Endpoints) را بررسی کنید و مشکلات احتمالی را شناسایی کنید.

۱. kubectl get services

دستور kubectl get services اطلاعات کلی در مورد سرویس‌های موجود در کلاستر Kubernetes را نمایش می‌دهد. این دستور به شما کمک می‌کند تا ببینید سرویس‌ها در چه وضعیت‌هایی قرار دارند و اطلاعاتی مثل آدرس‌های IP داخلی و پورت‌ها را مشاهده کنید.

دستور:

kubectl get services

خروجی:

این دستور لیستی از سرویس‌ها را همراه با اطلاعات زیر نمایش می‌دهد:

• نام سرویس
• نوع سرویس (ClusterIP، NodePort، LoadBalancer، …)
• آدرس IP سرویس
• پورت‌های در دسترس برای سرویس
• پورت‌های داخلی و خارجی

مثال:

kubectl get services

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

NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)        AGE
myapp-service  ClusterIP   10.96.0.1        <none>        8080/TCP       5d

این خروجی نشان می‌دهد که سرویس myapp-service از نوع ClusterIP است و در آدرس 10.96.0.1 قرار دارد و روی پورت 8080 در حال اجرا است.

۲. kubectl describe services

دستور kubectl describe services اطلاعات دقیق‌تری را در مورد یک سرویس خاص در اختیار شما قرار می‌دهد. این دستور جزئیات بیشتری از وضعیت سرویس، انتخاب‌کننده‌ها (Selectors) و پیکربندی‌های مرتبط با آن سرویس را نمایش می‌دهد.

دستور:

kubectl describe services <service-name>

مثال:

kubectl describe services myapp-service

خروجی:

این دستور اطلاعاتی مانند موارد زیر را نشان می‌دهد:

• آدرس IP سرویس
• پورت‌های سرویس
• انتخاب‌کننده‌های مرتبط با سرویس
• سرویس‌های مرتبط
• وضعیت endpoint‌ها

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

Name:                     myapp-service
Namespace:                default
Labels:                   <none>
Annotations:              <none>
Selector:                 app=myapp
Type:                     ClusterIP
IP:                       10.96.0.1
Port:                     8080/TCP
Endpoints:                10.240.1.2:8080,10.240.1.3:8080
Session Affinity:         None
Events:                   <none>

این خروجی به شما کمک می‌کند تا بفهمید که سرویس myapp-service چه endpointهایی دارد و پیکربندی‌های آن چگونه است.

۳. kubectl get endpoints

دستور kubectl get endpoints برای نمایش نقاط پایانی (Endpoints) سرویس‌ها استفاده می‌شود. این دستور اطلاعات مربوط به آدرس‌های IP و پورت‌هایی که هر سرویس در کلاستر به آن‌ها متصل است را نمایش می‌دهد. در صورتی که سرویس شما به هیچ نقطه پایانی متصل نباشد، این اطلاعات می‌تواند به شما کمک کند تا مشکلات احتمالی را شناسایی کنید.

دستور:

kubectl get endpoints

مثال:

kubectl get endpoints myapp-service

خروجی:

این دستور لیستی از endpoint‌ها به همراه آدرس‌های IP و پورت‌های مربوطه را نمایش می‌دهد. اگر سرویس‌های شما به درستی به Pods متصل نباشند، این خروجی می‌تواند به شما کمک کند تا علت مشکل را پیدا کنید.

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

NAME             ENDPOINTS                                      AGE
myapp-service    10.240.1.2:8080,10.240.1.3:8080                5d

اگر در این خروجی هیچ endpoint‌ای نشان داده نشود، ممکن است نشان‌دهنده یک مشکل در نحوه پیکربندی سرویس‌ها یا مشکلات دیگر در کلاستر باشد.

جمع‌بندی

برای دیباگ مشکلات شبکه در Kubernetes، دستورات kubectl get services، kubectl describe services و kubectl get endpoints ابزارهای مفیدی هستند که می‌توانند به شما در شناسایی مشکلات سرویس‌ها و اتصال‌های شبکه کمک کنند. با استفاده از این دستورات، می‌توانید وضعیت سرویس‌ها، پیکربندی‌ها و نقاط پایانی آن‌ها را بررسی کرده و مشکلات احتمالی را رفع کنید.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از ابزارهای خارجی مانند K9s و Lens” subtitle=”توضيحات کامل”]ابزارهای خارجی مانند K9s و Lens ابزارهای مفیدی برای مدیریت و نظارت بر کلاسترهای Kubernetes هستند که رابط‌های کاربری گرافیکی یا CLI را برای تعامل آسان‌تر با منابع Kubernetes فراهم می‌آورند. این ابزارها امکان مشاهده و مدیریت منابع مختلف Kubernetes را بدون نیاز به خط فرمان پیچیده فراهم می‌کنند و تجربه کاربری بهتری را ارائه می‌دهند.

۱. K9s

K9s یک ابزار خط فرمان است که امکان مدیریت کلاسترهای Kubernetes را از طریق رابط کاربری متنی (TUI) فراهم می‌آورد. این ابزار، نمایشگر بسیار قدرتمند و راحتی برای تعامل با منابع مختلف کلاستر از جمله Pods، Deployments، Services و غیره است. به کمک K9s می‌توانید به سرعت وضعیت منابع خود را مشاهده و مشکلات را شناسایی کنید.

ویژگی‌های K9s:

• رابط کاربری متنی بسیار کاربرپسند
• پشتیبانی از عملیات‌های معمول Kubernetes مانند kubectl (ایجاد، حذف، به‌روزرسانی و مشاهده منابع)
• نظارت بر وضعیت منابع به صورت real-time
• قابلیت مدیریت چند کلاستر به صورت همزمان

نصب K9s:

برای نصب K9s در سیستم خود، می‌توانید از روش‌های مختلف بسته به سیستم‌عامل خود استفاده کنید. به عنوان مثال، برای نصب در سیستم‌های مبتنی بر macOS:

brew install k9s

برای سایر سیستم‌عامل‌ها، می‌توانید از لینک دانلود K9s استفاده کنید.

اجرای K9s:

برای اجرا کردن K9s در کلاستر Kubernetes خود، کافی است دستور زیر را در ترمینال وارد کنید:

k9s

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

۲. Lens

Lens یک ابزار گرافیکی است که به شما امکان می‌دهد تا به راحتی کلاسترهای Kubernetes خود را مشاهده، مدیریت و نظارت کنید. Lens به کاربران یک محیط گرافیکی غنی و کاربرپسند ارائه می‌دهد و به شما کمک می‌کند تا به سرعت منابع مختلف کلاستر را مشاهده کرده و مشکلات را شناسایی کنید. این ابزار با پشتیبانی از چند کلاستر به طور همزمان، بسیار مناسب برای تیم‌های بزرگ است.

ویژگی‌های Lens:

• رابط کاربری گرافیکی بسیار قدرتمند و کاربرپسند
• امکان مشاهده منابع مختلف از جمله Pods، Deployments، Services و سایر منابع
• مانیتورینگ real-time منابع و وضعیت کلاستر
• قابلیت اتصال به چند کلاستر به طور همزمان
• پشتیبانی از Kubernetes Dashboard و دیگر افزونه‌ها

نصب Lens:

برای نصب Lens می‌توانید از سایت رسمی Lens نسخه مناسب سیستم‌عامل خود را دانلود و نصب کنید. به عنوان مثال، برای macOS می‌توانید از Homebrew استفاده کنید:

brew install --cask lens

اجرای Lens:

پس از نصب، Lens را اجرا کرده و کلاستر Kubernetes خود را به آن اضافه کنید. برای این کار:

1. Lens را باز کنید.
2. در بخش “Cluster” بر روی “Add Cluster” کلیک کنید.
3. فایل kubeconfig کلاستری که می‌خواهید متصل شوید را انتخاب کنید.

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

جمع‌بندی

ابزارهای K9s و Lens هر دو ابزارهای مفیدی برای مدیریت و نظارت بر کلاسترهای Kubernetes هستند. K9s با رابط کاربری متنی خود، تجربه‌ای سریع و کاربرپسند برای کاربران حرفه‌ای و افرادی که با CLI راحت‌تر هستند فراهم می‌آورد. از طرفی، Lens با رابط گرافیکی خود برای افرادی که ترجیح می‌دهند از یک ابزار گرافیکی استفاده کنند، گزینه‌ای عالی است. انتخاب ابزار مناسب بستگی به نیاز و ترجیحات شما دارد.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 4. حجم‌ها و ذخیره‌سازی داده‌ها”][cdb_course_lesson title=”فصل 1. مفاهیم پایه‌ای Volume در Kubernetes”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی مفهوم Volume در Kubernetes” subtitle=”توضيحات کامل”]در Kubernetes، مفهوم Volume به یک ساختار ذخیره‌سازی اشاره دارد که برای ذخیره‌سازی داده‌ها در کلاستر Kubernetes استفاده می‌شود. این داده‌ها می‌توانند برای کانتینرها در داخل Pods موجود باشند. در Kubernetes، Volume‌ها می‌توانند اطلاعات را بین Podهای مختلف و بین کانتینرها حفظ کنند. این مفهوم به شما کمک می‌کند که بتوانید داده‌ها را بدون وابستگی به عمر یک کانتینر، ذخیره و مدیریت کنید.

در حالت عادی، وقتی یک کانتینر از بین می‌رود یا مجدداً راه‌اندازی می‌شود، داده‌هایی که داخل آن ذخیره شده‌اند از دست می‌روند. اما با استفاده از Volume‌ها، داده‌ها می‌توانند خارج از فضای هر کانتینر ذخیره شوند و حتی پس از راه‌اندازی مجدد یک کانتینر یا Pod همچنان در دسترس باشند.

انواع Volume‌ها در Kubernetes

1. emptyDir: این نوع Volume برای ذخیره‌سازی موقت داده‌ها در داخل یک Pod استفاده می‌شود. داده‌ها به محض اینکه Pod از بین می‌رود از دست می‌روند. این Volume برای استفاده‌های موقتی مانند کش یا داده‌های موقت مناسب است.
2. hostPath: این Volume به شما این امکان را می‌دهد که از سیستم فایل نود برای ذخیره‌سازی داده‌ها استفاده کنید. داده‌ها در مسیر خاصی روی ماشین فیزیکی ذخیره می‌شوند.
3. PersistentVolume (PV) و PersistentVolumeClaim (PVC): این دو نوع Volume برای ذخیره‌سازی دائمی داده‌ها استفاده می‌شوند. PV یک منبع ذخیره‌سازی است که می‌تواند مستقل از Pod‌ها زندگی کند. PVC به کاربر این امکان را می‌دهد که به طور دایمی به این منابع دسترسی داشته باشد.
4. NFS (Network File System): برای به اشتراک‌گذاری داده‌ها میان Pods در نودهای مختلف می‌توانید از این Volume استفاده کنید.
5. ConfigMap و Secrets: Kubernetes به شما این امکان را می‌دهد که فایل‌های پیکربندی (ConfigMap) و اطلاعات حساس (Secrets) را در داخل Volume‌ها قرار دهید تا کانتینرها بتوانند به آنها دسترسی داشته باشند.

نحوه تعریف Volume در YAML

در Kubernetes، Volume‌ها معمولاً در فایل‌های YAML برای یک Pod تعریف می‌شوند. در اینجا یک مثال ساده از نحوه تعریف یک Volume به نام emptyDir آورده شده است:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: example-volume
  volumes:
    - name: example-volume
      emptyDir: {}

در این مثال:

• یک emptyDir Volume به نام example-volume ایجاد می‌شود.
• کانتینر nginx این Volume را در مسیر /usr/share/nginx/html داخل کانتینر mount می‌کند.

جمع‌بندی

Volume‌ها ابزار بسیار مفیدی در Kubernetes هستند که به شما این امکان را می‌دهند که داده‌ها را خارج از فضای عمر کانتینر ذخیره کنید. استفاده از Volume‌ها به شما کمک می‌کند تا داده‌های خود را به طور مداوم در دسترس قرار دهید و حتی در صورت از بین رفتن یا راه‌اندازی مجدد Pod‌ها، داده‌ها حفظ شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”چرا و چگونه Volume‌ها در Kubernetes استفاده می‌شوند؟” subtitle=”توضيحات کامل”]در Kubernetes، استفاده از Volume‌ها برای ذخیره‌سازی داده‌ها به منظور مدیریت دائمی یا موقت داده‌ها در Pods و کانتینرها بسیار حیاتی است. در واقع، Volume‌ها به دلیل مشکلاتی که در ذخیره‌سازی داده‌ها به‌صورت محلی در کانتینرها وجود دارد، معرفی شده‌اند. در این بخش، دلایل استفاده از Volume‌ها و نحوه استفاده از آنها در Kubernetes را بررسی می‌کنیم.

چرا Volume‌ها در Kubernetes استفاده می‌شوند؟

1. حفظ داده‌ها در طول عمر کانتینرها:
   • وقتی یک کانتینر در Kubernetes راه‌اندازی می‌شود، تنها در صورتی که کانتینر دوباره راه‌اندازی یا حذف شود، داده‌های آن از بین می‌روند. این موضوع در صورتی که داده‌های شما به طور مداوم نیاز به ذخیره‌سازی داشته باشند، مشکل‌ساز است. با استفاده از Volume‌ها، می‌توان داده‌ها را خارج از فضای ذخیره‌سازی کانتینر ذخیره کرده و آنها را حتی پس از از بین رفتن کانتینر حفظ کرد.
2. اشتراک‌گذاری داده‌ها بین کانتینرها:
   • Volume‌ها به کانتینرهای مختلف داخل یک Pod این امکان را می‌دهند که داده‌ها را به اشتراک بگذارند. این به ویژه برای کانتینرهایی که نیاز به دسترسی به داده‌های مشترک دارند، مفید است.
3. داده‌های موقت و دائمی:
   • برای ذخیره داده‌هایی که در طول عمر یک Pod نیاز به حفظ شدن دارند، می‌توان از Volume‌های Persistent (پایدار) مانند PersistentVolume و PersistentVolumeClaim استفاده کرد. این Volume‌ها به شما امکان می‌دهند داده‌ها را پس از از بین رفتن Pods و یا راه‌اندازی مجدد آنها حفظ کنید.
4. پشتیبانی از Storage متنوع:
   • Kubernetes به شما این امکان را می‌دهد که از انواع مختلف ذخیره‌سازی مانند NFS، AWS EBS، Google Cloud Persistent Disk، Ceph و غیره استفاده کنید. این مزیت به شما این امکان را می‌دهد که در محیط‌های ابری یا فیزیکی مختلف، سیستم ذخیره‌سازی متناسب با نیاز خود را انتخاب کنید.
5. مدیریت داده‌های حساس:
   • می‌توانید از Volume‌ها برای ذخیره داده‌های حساس مانند اطلاعات کاربری، رمزعبور یا کلیدهای API استفاده کنید. Kubernetes ابزارهایی مانند Secrets را به شما می‌دهد تا داده‌های حساس را از سایر داده‌ها جدا کرده و در Volume‌ها قرار دهید.

چگونه Volume‌ها در Kubernetes استفاده می‌شوند؟

برای استفاده از Volume‌ها در Kubernetes، معمولاً نیاز به یک فایل YAML برای تعریف Pod دارید که در آن Volume‌ها و نحوه mount کردن آنها به کانتینرها مشخص می‌شود.

مثال عملی نحوه تعریف Volume در Kubernetes:

1. تعریف یک Volume از نوع emptyDir:

در این مثال، یک emptyDir Volume تعریف می‌شود که برای ذخیره داده‌های موقت در داخل یک Pod استفاده می‌شود.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: myvolume
  volumes:
    - name: myvolume
      emptyDir: {}

در اینجا:

• یک emptyDir Volume با نام myvolume تعریف شده است.
• این Volume به داخل کانتینر mycontainer به مسیر /usr/share/nginx/html mount می‌شود.
• داده‌هایی که در این مسیر ذخیره می‌شوند، در طول عمر Pod موجود خواهند بود، اما زمانی که Pod حذف یا راه‌اندازی مجدد شود، داده‌ها از بین می‌روند.

2. تعریف یک PersistentVolume و PersistentVolumeClaim:

برای استفاده از داده‌های پایدار که پس از از بین رفتن Podها حفظ شوند، از PersistentVolume و PersistentVolumeClaim استفاده می‌شود.

ابتدا یک PersistentVolume را تعریف می‌کنیم:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

سپس PersistentVolumeClaim را برای درخواست فضای ذخیره‌سازی از این Volume تعریف می‌کنیم:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

در اینجا:

• PersistentVolume به نام mypv با 1Gi ظرفیت و مسیر hostPath تعریف شده است.
• PersistentVolumeClaim به نام mypvc با درخواست 1Gi ذخیره‌سازی ایجاد شده است.
• این PVC می‌تواند در یک Pod به عنوان Volume mount شود.

3. استفاده از Volume در یک Pod:

در نهایت، برای استفاده از این Volume‌ها در داخل Pod، می‌توانیم تعریف زیر را داشته باشیم:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        claimName: mypvc

در اینجا:

• PersistentVolumeClaim به نام mypvc به Pod اضافه شده است.
• داده‌ها در مسیر /data در داخل کانتینر قرار می‌گیرند و این داده‌ها پس از از بین رفتن یا راه‌اندازی مجدد Pod حفظ می‌شوند.

جمع‌بندی

Volume‌ها در Kubernetes به شما کمک می‌کنند تا داده‌ها را به‌طور دائمی ذخیره کنید و در صورتی که Podها از بین بروند، این داده‌ها از دست نروند. همچنین Volume‌ها قابلیت اشتراک‌گذاری داده‌ها بین کانتینرهای مختلف داخل یک Pod را فراهم می‌کنند. با استفاده از انواع مختلف Volume‌ها مانند emptyDir، PersistentVolume، PersistentVolumeClaim و hostPath، می‌توانید نیازهای مختلف ذخیره‌سازی خود را در Kubernetes برآورده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تفاوت بین Volume‌های موقت و دائمی” subtitle=”توضيحات کامل”]در کوبرنتیز، Volume‌ها به طور کلی به دو دسته موقت و دائم تقسیم می‌شوند که هرکدام کاربرد و ویژگی‌های خاص خود را دارند. در این بخش، به تفاوت‌های کلیدی بین این دو نوع Volume پرداخته می‌شود.

Volume‌های موقت (Ephemeral Volumes)

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

1. داده‌های موقتی:
   • این نوع Volume‌ها به داده‌هایی اختصاص داده می‌شوند که نیازی به ذخیره‌سازی بلندمدت ندارند. به عنوان مثال، کش‌ها، داده‌های موقتی برنامه‌ها و فایل‌های لاگ موقتی.
2. عدم نگهداری داده‌ها پس از حذف Pod:
   • زمانی که Pod حذف یا راه‌اندازی مجدد شود، داده‌های ذخیره شده در این Volume‌ها از بین می‌روند.
3. نمونه‌ها:
   • emptyDir: یک Volume موقت است که وقتی Pod ایجاد می‌شود، فضای ذخیره‌سازی خالی را فراهم می‌کند. داده‌ها تنها در طول عمر Pod حفظ می‌شوند.
   • configMap و secret: این Volume‌ها برای ذخیره داده‌هایی مانند پیکربندی یا اطلاعات حساس به طور موقت استفاده می‌شوند.

مثال از emptyDir (Volume موقت):

apiVersion: v1
kind: Pod
metadata:
  name: temp-volume-pod
spec:
  containers:
    - name: mycontainer
      image: nginx
      volumeMounts:
        - mountPath: /tmp/data
          name: tempvolume
  volumes:
    - name: tempvolume
      emptyDir: {}

در اینجا:

• emptyDir برای ذخیره‌سازی موقت استفاده شده و داده‌ها در طول عمر Pod حفظ می‌شوند، اما بعد از حذف Pod از بین می‌روند.

Volume‌های دائمی (Persistent Volumes)

Volume‌های دائمی به داده‌هایی اختصاص دارند که نیاز به ذخیره‌سازی بلندمدت دارند و حتی پس از حذف Pod، باید حفظ شوند. این نوع Volume‌ها امکان ذخیره‌سازی داده‌ها را فراتر از زندگی یک Pod فراهم می‌کنند و داده‌ها در صورت حذف یا راه‌اندازی مجدد Pod، همچنان موجود خواهند بود. از جمله ویژگی‌ها و کاربردهای آنها عبارتند از:

1. حفظ داده‌ها پس از حذف Pod:
   • این Volume‌ها برای ذخیره داده‌هایی استفاده می‌شوند که باید حتی بعد از حذف Pod باقی بمانند. برای مثال، پایگاه‌های داده یا فایل‌های ذخیره‌شده که باید در طول زمان حفظ شوند.
2. دسترس‌پذیری دائمی:
   • Volume‌های دائمی معمولاً برای نیازهای ذخیره‌سازی بلندمدت استفاده می‌شوند و می‌توانند از منابع خارجی مانند سیستم‌های ذخیره‌سازی ابری (مثلاً EBS در AWS یا Persistent Disk در GCP) بهره ببرند.
3. PersistentVolume (PV) و PersistentVolumeClaim (PVC):
   • PersistentVolume (PV) یک منبع ذخیره‌سازی فیزیکی است که خارج از Podها تعریف می‌شود. این Volume‌ها می‌توانند از منابع مختلف ذخیره‌سازی مانند NFS، EBS، Ceph و غیره استفاده کنند.
   • PersistentVolumeClaim (PVC) درخواست برای استفاده از یک PersistentVolume است. Pod‌ها می‌توانند با استفاده از PVC به این Volume‌ها متصل شوند.

مثال از PersistentVolume و PersistentVolumeClaim (Volume دائمی):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

در اینجا:

• یک PersistentVolume با ظرفیت 1Gi و از نوع hostPath تعریف شده است.
• PersistentVolumeClaim به نام mypvc درخواست 1Gi ظرفیت از این Volume می‌کند.
• این Volume پس از حذف Pod باقی می‌ماند.

تفاوت‌های کلیدی بین Volume‌های موقت و دائمی

ویژگی	Volume‌های موقت	Volume‌های دائمی
داده‌ها پس از حذف Pod	از بین می‌روند	حفظ می‌شوند
کاربرد اصلی	داده‌های موقتی، کش‌ها، فایل‌های لاگ	داده‌های دائمی، پایگاه‌های داده، فایل‌های کاربر
نوع ذخیره‌سازی	معمولاً در داخل Node یا فضای ذخیره‌سازی محلی	از منابع ذخیره‌سازی خارجی مانند NFS یا EBS
نمونه‌ها	emptyDir، configMap، secret	PersistentVolume، PersistentVolumeClaim
دسترس‌پذیری پس از حذف Pod	داده‌ها از بین می‌روند	داده‌ها باقی می‌مانند و قابل بازیابی هستند

جمع‌بندی

در Kubernetes، Volume‌ها به دو نوع موقت و دائمی تقسیم می‌شوند. Volume‌های موقت برای ذخیره‌سازی داده‌های موقتی و ناپایدار استفاده می‌شوند و پس از حذف Pod از بین می‌روند. از طرف دیگر، Volume‌های دائمی برای ذخیره‌سازی داده‌های بلندمدت استفاده می‌شوند و حتی بعد از حذف Pod نیز داده‌ها حفظ می‌شوند. این تمایز به Kubernetes اجازه می‌دهد که هر نوع نیاز ذخیره‌سازی را با استفاده از منابع مختلف مدیریت کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نقش Volume در مدیریت داده‌های Stateful و Stateless” subtitle=”توضيحات کامل”]در کوبرنتیز، Volume‌ها نقش حیاتی در مدیریت داده‌ها ایفا می‌کنند و می‌توانند برای مدیریت داده‌های Stateful و Stateless مورد استفاده قرار گیرند. درک تفاوت‌های بین این دو نوع داده و نحوه استفاده از Volume‌ها برای هر کدام، به شما کمک می‌کند تا معماری پایدار و مقیاس‌پذیری بسازید که بتواند نیازهای مختلف اپلیکیشن‌ها را برآورده کند.

داده‌های Stateless

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

1. ویژگی‌ها:
   • بدون وابستگی به وضعیت: اپلیکیشن‌هایی که به صورت Stateless طراحی می‌شوند، نیازی به ذخیره‌سازی داده‌ها یا وضعیت خود ندارند.
   • توانایی مقیاس‌پذیری بالا: از آنجایی که هیچ داده‌ای برای ذخیره و مدیریت وجود ندارد، می‌توان به راحتی تعداد Replica‌ها را افزایش یا کاهش داد.
   • عملکرد بالا: این اپلیکیشن‌ها معمولاً سریع‌تر عمل می‌کنند چون نیازی به خواندن یا نوشتن به دیتابیس یا ذخیره‌سازی دائمی ندارند.
2. استفاده از Volume در داده‌های Stateless:
   • برای داده‌های Stateless معمولاً نیازی به استفاده از Volume‌های دائمی نیست، زیرا داده‌ها به هیچ عنوان نیاز به ذخیره‌سازی پایدار ندارند.
   • در این سناریو، Volume‌های موقت مانند emptyDir می‌توانند برای ذخیره‌سازی داده‌های موقتی (که پس از پایان فرآیند پاک می‌شوند) استفاده شوند.

مثال از Volume موقت در داده‌های Stateless:

apiVersion: v1
kind: Pod
metadata:
  name: stateless-pod
spec:
  containers:
    - name: mycontainer
      image: nginx
      volumeMounts:
        - mountPath: /tmp/data
          name: temp-volume
  volumes:
    - name: temp-volume
      emptyDir: {}

در این مثال:

• از یک Volume موقت (emptyDir) برای ذخیره‌سازی موقتی داده‌ها استفاده شده است.
• این Volume تنها در طول عمر Pod داده‌ها را حفظ می‌کند و پس از حذف Pod از بین می‌روند.

داده‌های Stateful

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

1. ویژگی‌ها:
   • وابسته به وضعیت: اپلیکیشن‌های Stateful به داده‌هایی نیاز دارند که باید بین Pod‌ها یا حتی پس از راه‌اندازی مجدد حفظ شوند.
   • نیاز به ذخیره‌سازی پایدار: این نوع اپلیکیشن‌ها به ذخیره‌سازی دائمی برای حفظ داده‌ها نیاز دارند.
   • پیچیدگی مقیاس‌پذیری: مدیریت داده‌های Stateful می‌تواند پیچیده باشد چون باید وضعیت و داده‌های مختلف بین Pod‌ها یا Replica‌ها حفظ شوند.
2. استفاده از Volume در داده‌های Stateful:
   • برای داده‌های Stateful باید از PersistentVolume (PV) و PersistentVolumeClaim (PVC) استفاده کرد.
   • PersistentVolume به ذخیره‌سازی دائمی اشاره دارد که می‌تواند از منابع مختلف ذخیره‌سازی مانند EBS، NFS یا Ceph برای حفظ داده‌ها استفاده کند.
   • StatefulSets یکی از منابع Kubernetes است که برای مدیریت Pod‌های Stateful و ایجاد Volume‌های دائمی به صورت خودکار استفاده می‌شود.

مثال از استفاده از PersistentVolume برای داده‌های Stateful:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: stateful-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: stateful-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: stateful-app
spec:
  serviceName: "stateful-service"
  replicas: 3
  selector:
    matchLabels:
      app: stateful-app
  template:
    metadata:
      labels:
        app: stateful-app
    spec:
      containers:
        - name: app-container
          image: my-stateful-app
          volumeMounts:
            - mountPath: /data
              name: data-storage
  volumeClaimTemplates:
    - metadata:
        name: data-storage
      spec:
        accessModes: [ "ReadWriteOnce" ]
        resources:
          requests:
            storage: 1Gi

در این مثال:

• از یک PersistentVolumeClaim برای درخواست یک Volume دائمی استفاده شده است.
• داده‌های ذخیره‌شده در Volume‌های مرتبط با این StatefulSet پس از راه‌اندازی مجدد یا حذف Pod‌ها همچنان حفظ می‌شوند.

تفاوت‌های کلیدی در مدیریت داده‌های Stateful و Stateless

ویژگی	Stateful	Stateless
ذخیره‌سازی داده‌ها	نیاز به ذخیره‌سازی دائمی	داده‌ها موقتی هستند و پس از حذف Pod از بین می‌روند
حفظ وضعیت پس از حذف Pod	بله، وضعیت حفظ می‌شود	خیر، وضعیت حفظ نمی‌شود
استفاده از Volume	از PersistentVolume استفاده می‌شود	از Volume‌های موقت مانند emptyDir استفاده می‌شود
نمونه‌ها	پایگاه داده‌ها، سیستم‌های کش، فایل‌های کاربر	وب‌سایت‌ها، API‌ها، سیستم‌های بدون حالت

جمع‌بندی

در Kubernetes، Volume‌ها ابزار قدرتمندی برای مدیریت داده‌ها هستند و می‌توانند برای نیازهای Stateful و Stateless استفاده شوند. در اپلیکیشن‌های Stateless معمولاً از Volume‌های موقت استفاده می‌شود زیرا داده‌ها نیازی به ذخیره‌سازی دائمی ندارند. در مقابل، برای اپلیکیشن‌های Stateful که نیاز به ذخیره‌سازی داده‌ها به طور دائمی دارند، از PersistentVolume و PersistentVolumeClaim استفاده می‌شود تا داده‌ها حتی پس از حذف Pod حفظ شوند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. انواع Volume‌ها و کاربردهای آنها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”EmptyDir” subtitle=”توضيحات کامل”]EmptyDir یکی از انواع Volume در Kubernetes است که برای ذخیره‌سازی موقتی داده‌ها در طول عمر یک Pod استفاده می‌شود. این Volume به‌طور موقت و تنها برای مدت زمانی که Pod در حال اجرا است، داده‌ها را ذخیره می‌کند. زمانی که Pod حذف می‌شود، محتوای Volume نیز از بین می‌رود.

ویژگی‌های EmptyDir:

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

کاربردها:

1. حافظه موقتی برای کانتینرها:
   • زمانی که نیاز به فضای موقت برای ذخیره‌سازی داده‌ها در داخل Pod دارید، از EmptyDir می‌توان برای ذخیره‌سازی داده‌های موقتی استفاده کرد.
   • برای مثال، زمانی که نیاز به ذخیره اطلاعات کش یا داده‌های پردازش‌شده موقت دارید، EmptyDir می‌تواند انتخاب مناسبی باشد.
2. مبادله داده بین کانتینرها:
   • اگر در یک Pod بیش از یک کانتینر داشته باشید و بخواهید داده‌ای را بین کانتینرها به اشتراک بگذارید، می‌توانید از EmptyDir استفاده کنید.
3. پردازش داده‌های موقت:
   • زمانی که نیاز به پردازش و ذخیره داده‌ها به‌طور موقت در یک کانتینر دارید و بعد از پایان پردازش نیازی به ذخیره داده‌ها برای آینده ندارید، EmptyDir می‌تواند برای ذخیره‌سازی این داده‌ها تا زمان اتمام پردازش استفاده شود.

محدودیت‌ها:

1. داده‌ها از بین می‌روند بعد از حذف Pod:
   • از آنجا که EmptyDir به عمر Pod وابسته است، داده‌ها پس از حذف Pod از بین می‌روند. این ویژگی می‌تواند یک محدودیت باشد اگر بخواهید داده‌ها را به‌طور دائمی ذخیره کنید.
2. عدم استفاده برای ذخیره‌سازی طولانی‌مدت:
   • EmptyDir برای ذخیره‌سازی طولانی‌مدت یا persistent داده‌ها مناسب نیست، زیرا داده‌ها فقط در مدت زمان اجرای Pod حفظ می‌شوند.
3. پشتیبانی از خوشه‌های multi-node:
   • اگر Pod در یک خوشه با چندین نود اجرا شود، EmptyDir تنها در نود محلی ذخیره می‌شود و داده‌ها در نودهای مختلف به اشتراک گذاشته نمی‌شوند. این ممکن است محدودیت‌هایی در سناریوهای پیچیده ایجاد کند.

مثال عملی استفاده از EmptyDir در YAML:

در زیر مثالی از نحوه پیکربندی EmptyDir در یک Pod آورده شده است:

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-example
spec:
  containers:
    - name: app-container
      image: nginx
      volumeMounts:
        - mountPath: /tmp/data
          name: temp-volume
  volumes:
    - name: temp-volume
      emptyDir: {}

در این مثال:

• یک Pod به نام emptydir-example ایجاد می‌شود.
• در این Pod، یک کانتینر با نام app-container اجرا می‌شود که از تصویر nginx استفاده می‌کند.
• EmptyDir با نام temp-volume به کانتینر متصل شده و داده‌ها در مسیر /tmp/data ذخیره می‌شوند.

جمع‌بندی

EmptyDir یک نوع Volume موقتی است که برای ذخیره داده‌ها در طول عمر یک Pod استفاده می‌شود. این Volume برای استفاده در سناریوهایی که داده‌ها به‌طور موقت باید ذخیره شوند، مانند پردازش‌های موقت یا اشتراک داده بین کانتینرها، مناسب است. این ویژگی امکان مدیریت حجم موقتی را فراهم می‌کند ولی پس از حذف Pod داده‌ها از بین می‌روند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”HostPath” subtitle=”توضيحات کامل”]HostPath یکی از انواع Volume در Kubernetes است که به Pod اجازه می‌دهد تا به فایل‌ها و پوشه‌های موجود در Host Node دسترسی داشته باشد. این Volume برای مواقعی که نیاز به دسترسی مستقیم به سیستم فایل نود (Node) باشد، مفید است. به عبارت دیگر، HostPath به شما این امکان را می‌دهد که فایل‌ها و داده‌هایی را که در نودهای فیزیکی یا مجازی ذخیره شده‌اند، در داخل Pods خود استفاده کنید.

ویژگی‌ها و کاربردهای HostPath:

1. دسترسی به فایل‌های محلی:
   • HostPath اجازه می‌دهد که فایل‌ها و دایرکتوری‌های موجود در Host Node به‌طور مستقیم در داخل Pod ها قابل دسترس باشند.
   • این ویژگی به‌ویژه زمانی که نیاز به استفاده از داده‌ها یا پیکربندی‌های موجود در نود دارید، مفید است.
2. مناسب برای استفاده‌های خاص:
   • برای سناریوهایی که نیاز به ذخیره‌سازی داده‌ها در سیستم فایل محلی نود دارند (مثلاً فایل‌های لاگ، داده‌های موقتی که نیاز به ذخیره‌سازی خارج از Pod دارند)، HostPath گزینه‌ای مناسب است.
   • برای مثال، می‌توان از HostPath برای ذخیره‌سازی داده‌های مربوط به Docker یا اطلاعات کش استفاده کرد.
3. دسترسی مستقیم به منابع سیستم:
   • با استفاده از HostPath، یک Pod می‌تواند به سیستم فایل Host Node (مانند /var/log یا /etc/config) دسترسی پیدا کند.
   • این ویژگی به‌ویژه زمانی که سیستم‌ها و پیکربندی‌های موجود در نود به‌طور مستقیم برای Pod مورد نیاز باشند، کاربرد دارد.

چالش‌ها و ریسک‌های امنیتی:

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

محدودیت‌ها:

1. وابستگی به نودهای خاص:
   • استفاده از HostPath باعث می‌شود که Podها به سیستم فایل نود خاصی وابسته شوند. این می‌تواند باعث ایجاد محدودیت‌های در مقیاس‌پذیری و انعطاف‌پذیری شود، زیرا برای اجرا نیاز به نود خاصی خواهید داشت.
   • به عبارت دیگر، HostPath به Pod اجازه نمی‌دهد که از یک نود به نود دیگر جابجا شود، بنابراین این ویژگی برای استفاده‌های با مقیاس بالا مناسب نیست.
2. ایزولاسیون ضعیف:
   • این نوع Volume برای کارهایی که نیاز به ایزولاسیون بالا دارند (مانند استفاده در محیط‌های چند سازمانی یا کاربری‌های حساس) مناسب نیست، چرا که دسترسی به فایل‌های سیستم عامل نود می‌تواند به هکرها یا برنامه‌های مخرب امکان دسترسی به فایل‌های حساس سیستم را بدهد.

مثال عملی استفاده از HostPath در YAML:

در این مثال، یک HostPath Volume به Pod اضافه می‌شود تا به دایرکتوری /data در نود دسترسی پیدا کند:

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-example
spec:
  containers:
    - name: app-container
      image: nginx
      volumeMounts:
        - mountPath: /mnt/data
          name: host-volume
  volumes:
    - name: host-volume
      hostPath:
        path: /data
        type: Directory

در این مثال:

• یک Pod به نام hostpath-example ایجاد می‌شود.
• یک کانتینر به نام app-container که از تصویر nginx استفاده می‌کند، به دایرکتوری /mnt/data در داخل Pod متصل می‌شود.
• Volume از نوع hostPath به مسیر /data در سیستم فایل Host Node متصل می‌شود.

جمع‌بندی

HostPath یکی از انواع Volume است که به Pods این امکان را می‌دهد که به فایل‌ها و پوشه‌های موجود در سیستم فایل نود دسترسی پیدا کنند. این ویژگی برای استفاده‌هایی که نیاز به ذخیره‌سازی و دسترسی به داده‌ها در داخل سیستم فایل نود دارند مفید است. اما این قابلیت چالش‌ها و ریسک‌های امنیتی نیز به همراه دارد، از جمله عدم ایزولاسیون مناسب و خطرات مربوط به دسترسی به فایل‌های حساس. همچنین، به دلیل وابستگی به نود خاص، این Volume برای سناریوهای با مقیاس بالا و در شرایطی که نیاز به انعطاف‌پذیری زیاد باشد مناسب نیست.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ConfigMap و Secret به‌عنوان Volume” subtitle=”توضيحات کامل”]ConfigMap و Secret می‌توانند به‌عنوان منابع پیکربندی و داده‌های حساس در Kubernetes به‌صورت Volume استفاده شوند. این امکان به شما می‌دهد که داده‌های پیکربندی و اطلاعات حساس مانند رمز عبور یا کلیدهای API را از کانتینرها جدا کرده و آن‌ها را به‌طور امن مدیریت کنید.

ایجاد ConfigMap به‌عنوان Volume

1. ابتدا یک ConfigMap ایجاد کنید. به‌عنوان مثال، یک پیکربندی ساده که شامل اطلاعات پیکربندی است:

   apiVersion: v1
   kind: ConfigMap
   metadata:
     name: my-config
   data:
     app-config: |
       key1=value1
       key2=value2
   

2. در Pod خود این ConfigMap را به‌عنوان یک Volume Mount کنید. به این صورت که از ConfigMap برای ذخیره‌سازی داده‌ها استفاده می‌کنید:

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

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

ایجاد Secret به‌عنوان Volume

1. ابتدا یک Secret ایجاد کنید:

   kubectl create secret generic my-secret --from-literal=password=my-password
   

2. برای استفاده از Secret به‌عنوان Volume در Pod، می‌توانید به شکل زیر عمل کنید:

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

   در این مثال، Secret به‌عنوان Volume به Pod متصل می‌شود و داده‌های آن به‌صورت فایل‌های متنی در مسیر /etc/secrets درون کانتینر قرار می‌گیرد.

مزایای استفاده از ConfigMap و Secret به‌عنوان Volume:

• جداسازی داده‌ها از کانتینرها: این امکان را می‌دهد که تنظیمات و داده‌های حساس خارج از کانتینر ذخیره شوند و به راحتی مدیریت شوند.
• امنیت بیشتر: اطلاعات حساس مانند رمز عبور یا کلیدهای API به‌صورت امن‌تر مدیریت می‌شوند و از محیط کانتینر خارج می‌شوند.
• قابلیت بروزرسانی: می‌توان ConfigMap و Secret را به‌راحتی بروزرسانی کرد بدون نیاز به تغییر کانتینرها.

---

این تنظیمات به‌صورت کامندی در Kubernetes به شما کمک می‌کند تا ConfigMap و Secret را به‌عنوان Volume به‌کار گیرید و به سادگی مدیریت داده‌ها و پیکربندی‌ها را در اپلیکیشن‌های خود انجام دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”PersistentVolume (PV)” subtitle=”توضيحات کامل”]

تعریف و کاربرد Persistent Volume

Persistent Volume (PV) یک منبع ذخیره‌سازی پایدار در Kubernetes است که به Pods اجازه می‌دهد داده‌های خود را به‌صورت دائمی ذخیره کنند. برخلاف Volumes معمولی که با حذف یک Pod از بین می‌روند، PVها مستقل از چرخه حیات Pods هستند و می‌توانند در سطح کلاستر مدیریت شوند.

مزایای استفاده از PV:

• ذخیره‌سازی پایدار: داده‌ها پس از حذف یا راه‌اندازی مجدد Pod حفظ می‌شوند.
• مدیریت مستقل از Pods: منابع ذخیره‌سازی به‌صورت جداگانه تخصیص داده می‌شوند.
• امکان استفاده در محیط‌های مختلف: در محیط‌های Cloud و On-Premises قابل استفاده است.

---

نحوه استفاده در محیط‌های Cloud و On-Premises

در محیط‌های Cloud:
ارائه‌دهندگان ابری مانند AWS, GCP, Azure پشتیبانی از Persistent Volume را با استفاده از سرویس‌های ذخیره‌سازی خود فراهم می‌کنند:

• AWS: استفاده از EBS (Elastic Block Store)
• Google Cloud: استفاده از Persistent Disk (PD)
• Azure: استفاده از Azure Disk Storage

در محیط‌های On-Premises:
در محیط‌های On-Premises می‌توان از راهکارهای مختلفی مانند:

• NFS (Network File System)
• iSCSI
• CephFS
• GlusterFS استفاده کرد.

---

ایجاد یک PersistentVolume در Kubernetes

برای ایجاد یک PV در Kubernetes، ابتدا باید یک منبع ذخیره‌سازی تعریف کنیم. مثال زیر یک PV را با استفاده از NFS نشان می‌دهد:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /mnt/data
    server: 192.168.1.100

📌 توضیح بخش‌های مهم:

• capacity.storage: مقدار فضای ذخیره‌سازی (در اینجا ۵ گیگابایت).
• accessModes: نوع دسترسی (مانند ReadWriteOnce یا ReadWriteMany).
• persistentVolumeReclaimPolicy: مشخص می‌کند که پس از حذف PV چه اتفاقی بیفتد (Retain = داده حفظ شود).
• nfs.server: آدرس NFS Server برای استفاده از ذخیره‌سازی شبکه.

---

ایجاد یک PersistentVolumeClaim (PVC)

Pods نمی‌توانند مستقیماً از PV استفاده کنند، بلکه باید یک PersistentVolumeClaim (PVC) ایجاد شود تا به PV متصل شود:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

پس از ایجاد PVC، یک Pod می‌تواند آن را به عنوان Volume استفاده کند:

apiVersion: v1
kind: Pod
metadata:
  name: pod-using-pv
spec:
  containers:
    - name: app-container
      image: nginx
      volumeMounts:
        - mountPath: "/data"
          name: storage
  volumes:
    - name: storage
      persistentVolumeClaim:
        claimName: pvc-example

📌 در اینجا:

• PVC به عنوان یک Volume در Pod قرار گرفته است.
• مسیر /data در کانتینر به PV متصل شده و داده‌ها در آن ذخیره می‌شوند.

---

مشاهده و مدیریت Persistent Volume در Kubernetes

1️⃣ ایجاد PV و PVC در کلاستر

kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml

2️⃣ مشاهده لیست PV و PVC

kubectl get pv
kubectl get pvc

3️⃣ مشاهده جزئیات یک PersistentVolume

kubectl describe pv pv-example

4️⃣ مشاهده جزئیات یک PersistentVolumeClaim

kubectl describe pvc pvc-example

5️⃣ حذف PV و PVC (در صورت نیاز)

kubectl delete pvc pvc-example
kubectl delete pv pv-example

---

با استفاده از Persistent Volume (PV)، Pods می‌توانند داده‌های خود را در یک فضای ذخیره‌سازی دائمی ذخیره کنند، که در محیط‌های Cloud و On-Premises یک قابلیت بسیار مهم برای اجرای برنامه‌های Stateful محسوب می‌شود. 🚀[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”PersistentVolumeClaim (PVC)” subtitle=”توضيحات کامل”]

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

PersistentVolumeClaim (PVC) یک درخواست برای PersistentVolume (PV) است که توسط کاربران یا Podها برای دریافت فضای ذخیره‌سازی مورد نیازشان استفاده می‌شود. PVC به صورت پویا یک PV را رزرو می‌کند یا به یک PV موجود متصل می‌شود.

مراحل درخواست و استفاده از PVC:

1. ایجاد یک PersistentVolume (PV) (در صورتی که PV به‌صورت دستی مدیریت شود).
2. ایجاد یک PersistentVolumeClaim (PVC) برای درخواست فضای ذخیره‌سازی.
3. اتصال PVC به یک Pod برای استفاده از فضای ذخیره‌سازی.

---

ایجاد یک PersistentVolumeClaim (PVC)

در این مثال، PVC برای درخواست ۵ گیگابایت فضای ذخیره‌سازی با قابلیت خواندن و نوشتن توسط چندین Pod ایجاد می‌شود:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

📌 توضیح بخش‌ها:

• accessModes: نحوه دسترسی به PV.
  • ReadWriteOnce: فقط یک Node می‌تواند بنویسد.
  • ReadWriteMany: چندین Node می‌توانند همزمان بخوانند و بنویسند.
  • ReadOnlyMany: چندین Node می‌توانند فقط بخوانند.
• resources.requests.storage: مقدار فضای ذخیره‌سازی مورد نیاز.

---

اتصال PVC به Podها

پس از ایجاد PVC، می‌توان آن را در یک Pod به عنوان Volume متصل کرد:

apiVersion: v1
kind: Pod
metadata:
  name: pod-using-pvc
spec:
  containers:
    - name: app-container
      image: nginx
      volumeMounts:
        - mountPath: "/data"
          name: storage
  volumes:
    - name: storage
      persistentVolumeClaim:
        claimName: pvc-example

📌 در اینجا:

• PVC pvc-example به عنوان یک Volume در Pod متصل شده است.
• داده‌های Pod در مسیر /data ذخیره می‌شوند.
• با حذف Pod، داده‌ها باقی می‌مانند، زیرا در PV ذخیره شده‌اند.

---

مشاهده و مدیریت PVC در Kubernetes

1️⃣ ایجاد PVC در کلاستر

kubectl apply -f pvc.yaml

2️⃣ مشاهده لیست PVCها

kubectl get pvc

3️⃣ مشاهده جزئیات یک PVC

kubectl describe pvc pvc-example

4️⃣ حذف PVC (در صورت نیاز)

kubectl delete pvc pvc-example

---

با استفاده از PVC، Pods می‌توانند بدون نگرانی از جزئیات ذخیره‌سازی، به Persistent Volume (PV) متصل شوند. این ویژگی امکان استفاده از فضای ذخیره‌سازی پایدار را در محیط‌های Cloud و On-Premises فراهم می‌کند. 🚀[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. مدیریت ذخیره‌سازی پویا”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی مفهوم Storage Class” subtitle=”توضيحات کامل”]Storage Class در Kubernetes مکانیزمی برای مدیریت پویا فضای ذخیره‌سازی است. این قابلیت امکان تخصیص Persistent Volume (PV) را به‌صورت خودکار فراهم می‌کند، بدون اینکه نیاز باشد مدیر کلاستر آن را به‌صورت دستی ایجاد کند.

---

چرا Storage Class مهم است؟

✅ تخصیص پویا (Dynamic Provisioning): به‌جای ایجاد دستی PV، Kubernetes به‌صورت خودکار آن را بر اساس StorageClass مشخص شده ایجاد می‌کند.
✅ مدیریت انواع Storage Backends: می‌توان فضای ذخیره‌سازی را از منابعی مانند AWS EBS، Google Persistent Disk، NFS، Ceph، GlusterFS و… تأمین کرد.
✅ امکان تعریف چندین کلاس ذخیره‌سازی: هر کلاس می‌تواند برای عملکردهای مختلف (SSD، HDD، سریع، ارزان و…) تنظیم شود.

---

تعریف یک StorageClass در Kubernetes

برای تعریف یک StorageClass، باید یک فایل YAML مانند زیر ایجاد کرد:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4
  iopsPerGB: "10"
  encrypted: "true"
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - discard

📌 توضیحات بخش‌های مهم:

• provisioner: مشخص می‌کند که این StorageClass از چه نوع ذخیره‌سازی استفاده کند (مثلاً kubernetes.io/aws-ebs برای AWS EBS).
• parameters: شامل تنظیمات مربوط به نوع دیسک، سیستم فایل (ext4)، رمزنگاری و… است.
• reclaimPolicy: نحوه مدیریت PV پس از حذف PVC را مشخص می‌کند:
  • Delete → با حذف PVC، PV نیز حذف می‌شود.
  • Retain → PV پس از حذف PVC باقی می‌ماند.
• allowVolumeExpansion: اجازه افزایش حجم فضای ذخیره‌سازی را می‌دهد.
• mountOptions: گزینه‌های اضافی هنگام Mount کردن دیسک را تعیین می‌کند.

---

استفاده از Storage Class در PVC

پس از ایجاد یک StorageClass، می‌توان آن را در PVC به کار برد:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-storage

📌 در اینجا:

• این PVC درخواست ۱۰ گیگابایت فضای ذخیره‌سازی می‌دهد.
• StorageClass fast-storage برای تخصیص خودکار فضای ذخیره‌سازی استفاده می‌شود.
• Kubernetes یک Persistent Volume (PV) را با توجه به مشخصات StorageClass ایجاد می‌کند.

---

بررسی و مدیریت Storage Class

✅ مشاهده لیست Storage Classes در کلاستر:

kubectl get storageclass

✅ بررسی جزئیات یک StorageClass:

kubectl describe storageclass fast-storage

✅ حذف StorageClass (در صورت نیاز):

kubectl delete storageclass fast-storage

---

نتیجه:
با استفاده از StorageClass، می‌توان فضای ذخیره‌سازی پویا و مدیریت‌شده برای Pods ایجاد کرد و آن را با PVCها مرتبط ساخت. این قابلیت به مدیریت خودکار، افزایش کارایی و کاهش پیچیدگی تنظیمات ذخیره‌سازی در Kubernetes کمک می‌کند. 🚀[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نقش Storage Class در مدیریت ذخیره‌سازی پویا” subtitle=”توضيحات کامل”]Storage Class در Kubernetes نقش کلیدی در مدیریت پویا فضای ذخیره‌سازی (Dynamic Provisioning) دارد. این قابلیت باعث می‌شود که Persistent Volume (PV) ها به‌صورت خودکار و بر اساس نیاز برنامه‌ها ایجاد شوند، بدون اینکه مدیر کلاستر نیاز به تخصیص دستی آن‌ها داشته باشد.

---

چرا Storage Class برای مدیریت پویا مهم است؟

✅ تخصیص خودکار فضای ذخیره‌سازی: Kubernetes هنگام ایجاد Persistent Volume Claim (PVC)، به‌صورت خودکار یک PV متناسب با مشخصات Storage Class موردنظر ایجاد می‌کند.
✅ انعطاف‌پذیری در استفاده از منابع ذخیره‌سازی: می‌توان Storage Class های مختلفی را برای SSD، HDD، NFS، Ceph، Google Persistent Disk، AWS EBS و… تعریف کرد.
✅ مدیریت بهینه حجم‌های ذخیره‌سازی: امکان تنظیم ویژگی‌هایی مانند افزایش حجم، کلاس عملکرد، سیاست نگهداری (Retain/Delete) و… فراهم است.
✅ کاهش پیچیدگی مدیریت دستی PVها: نیازی به ایجاد دستی PV برای هر درخواست PVC نیست، زیرا Kubernetes این کار را به‌صورت خودکار انجام می‌دهد.

---

تعریف و استفاده از Storage Class در Kubernetes

۱. ایجاد یک Storage Class برای AWS EBS

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4
  iopsPerGB: "10"
  encrypted: "true"
reclaimPolicy: Retain
allowVolumeExpansion: true

📌 توضیحات:

• provisioner → نوع فراهم‌کننده فضای ذخیره‌سازی (مثلاً kubernetes.io/aws-ebs برای AWS EBS).
• parameters → تنظیمات مربوط به نوع دیسک (gp3)، سیستم فایل (ext4)، میزان IOPS و رمزنگاری.
• reclaimPolicy → سیاست مدیریت حجم ذخیره‌سازی بعد از حذف PVC (Retain یا Delete).
• allowVolumeExpansion → امکان افزایش حجم دیسک را فراهم می‌کند.

۲. ایجاد PVC که از این Storage Class استفاده کند

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: dynamic-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
  storageClassName: fast-storage

📌 عملکرد این PVC:

• درخواست یک PV با حجم ۲۰ گیگابایت را ثبت می‌کند.
• از Storage Class fast-storage برای تخصیص پویا استفاده می‌کند.
• Kubernetes به‌صورت خودکار یک Persistent Volume (PV) متناسب با این PVC ایجاد می‌کند.

---

مدیریت Storage Class در Kubernetes

✅ مشاهده Storage Classes موجود در کلاستر:

kubectl get storageclass

✅ بررسی جزئیات یک Storage Class:

kubectl describe storageclass fast-storage

✅ حذف یک Storage Class (در صورت نیاز):

kubectl delete storageclass fast-storage

---

جمع‌بندی

Storage Class در Kubernetes امکان مدیریت پویا و خودکار فضای ذخیره‌سازی را فراهم می‌کند. این قابلیت باعث می‌شود PVها بدون نیاز به مداخله دستی ایجاد شده و بهینه‌سازی منابع ذخیره‌سازی به‌سادگی انجام شود. همچنین، می‌توان انواع مختلفی از ذخیره‌سازی (SSD، HDD، NFS و…) را متناسب با نیاز برنامه‌ها تعریف و مدیریت کرد. 🚀[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”انواع Storage Class در ارائه‌دهندگان Cloud (AWS EBS، GCP PD، Azure Disk)” subtitle=”توضيحات کامل”]در Kubernetes، هر ارائه‌دهنده‌ی Cloud دارای Storage Classهای مخصوص به خود است که به‌صورت پویا Persistent Volume (PV) ایجاد می‌کنند. در ادامه، نحوه‌ی تعریف Storage Class برای سه Cloud Provider محبوب آورده شده است.

---

۱. Storage Class در AWS EBS

در AWS، دیسک‌های Elastic Block Store (EBS) برای تخصیص فضای ذخیره‌سازی استفاده می‌شوند. Kubernetes می‌تواند به‌صورت خودکار EBS Volume ایجاد کند و به Pods متصل کند.

✅ نمونه Storage Class برای AWS EBS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: aws-ebs-gp3
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp3
  fsType: ext4
  encrypted: "true"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

📌 توضیحات:

• provisioner: kubernetes.io/aws-ebs → نوع Provisioner برای AWS EBS.
• type: gp3 → نوع دیسک (گزینه‌های دیگر: gp2, io1, sc1, st1).
• encrypted: "true" → فعال‌سازی رمزگذاری.
• reclaimPolicy: Delete → هنگام حذف PVC، فضای ذخیره‌سازی نیز حذف می‌شود.
• allowVolumeExpansion: true → امکان افزایش حجم را فعال می‌کند.
• volumeBindingMode: WaitForFirstConsumer → تا زمانی که Podی درخواست استفاده نکند، PV ایجاد نمی‌شود.

✅ مشاهده Storage Class‌های موجود در AWS:

kubectl get storageclass

✅ ایجاد PVC برای استفاده از AWS EBS:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: aws-ebs-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: aws-ebs-gp3

---

۲. Storage Class در Google Cloud Platform (GCP PD)

در GCP، فضای ذخیره‌سازی از نوع Persistent Disk (PD) استفاده می‌شود.

✅ نمونه Storage Class برای GCP Persistent Disk:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcp-pd-standard
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-standard
  replication-type: none
reclaimPolicy: Retain
allowVolumeExpansion: true

📌 توضیحات:

• provisioner: pd.csi.storage.gke.io → نوع Provisioner برای Google Persistent Disk.
• type: pd-standard → نوع دیسک (گزینه‌های دیگر: pd-ssd, pd-balanced).
• replication-type: none → بدون کپی اضافی.
• reclaimPolicy: Retain → حتی در صورت حذف PVC، داده‌ها باقی می‌مانند.

✅ ایجاد PVC برای استفاده از GCP Persistent Disk:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcp-pd-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: gcp-pd-standard

---

۳. Storage Class در Microsoft Azure Disk

در Azure، از Managed Disks برای ایجاد Persistent Volume استفاده می‌شود.

✅ نمونه Storage Class برای Azure Disk:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azure-disk-standard
provisioner: disk.csi.azure.com
parameters:
  skuName: Standard_LRS
reclaimPolicy: Delete
allowVolumeExpansion: true

📌 توضیحات:

• provisioner: disk.csi.azure.com → نوع Provisioner برای Azure Managed Disk.
• skuName: Standard_LRS → نوع دیسک (گزینه‌های دیگر: Premium_LRS, StandardSSD_LRS).
• reclaimPolicy: Delete → حذف PV پس از حذف PVC.

✅ ایجاد PVC برای استفاده از Azure Disk:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-disk-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 40Gi
  storageClassName: azure-disk-standard

---

جمع‌بندی

هر Cloud Provider مکانیزم مخصوص خود را برای مدیریت Storage Class دارد:

✅ AWS EBS: برای دیسک‌های Elastic Block Store (EBS) با گزینه‌های gp3، gp2 و io1.
✅ GCP PD: برای دیسک‌های Persistent Disk با گزینه‌های pd-standard، pd-ssd و pd-balanced.
✅ Azure Disk: برای Managed Disks با گزینه‌های Premium_LRS، Standard_LRS و StandardSSD_LRS.

Storage Class در این پلتفرم‌ها باعث تخصیص خودکار منابع ذخیره‌سازی شده و بهینه‌سازی مدیریت داده‌ها را در Kubernetes تسهیل می‌کند. 🚀[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تعریف و تنظیم Storage Class در فایل YAML” subtitle=”توضيحات کامل”]در کوبرنتیز، Storage Class برای مدیریت ذخیره‌سازی پویا (Dynamic Provisioning) استفاده می‌شود. با استفاده از Storage Class، می‌توان نوع Persistent Volume (PV) را بر اساس نیاز تعریف کرد تا به‌صورت خودکار در محیط‌های Cloud یا On-Premises ایجاد شود.

---

ایجاد یک Storage Class برای محیط On-Premises (NFS)

اگر در محیط‌های غیر ابری مانند دیتاسنتر محلی کار می‌کنید، می‌توانید از NFS (Network File System) استفاده کنید.

✅ نمونه فایل YAML برای Storage Class با NFS:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-storage
provisioner: nfs.csi.k8s.io
parameters:
  server: 192.168.1.100   # آدرس سرور NFS
  path: /data/k8s-storage  # مسیر به اشتراک‌گذاری شده روی سرور NFS
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
  - hard
  - nfsvers=4.1
volumeBindingMode: Immediate

📌 توضیحات:

• provisioner: nfs.csi.k8s.io → استفاده از NFS CSI Driver برای مدیریت Storage Class.
• server: 192.168.1.100 → آدرس NFS Server که فضا را ارائه می‌دهد.
• path: /data/k8s-storage → مسیر NFS Share که Kubernetes برای ذخیره‌سازی استفاده می‌کند.
• reclaimPolicy: Retain → حتی در صورت حذف PVC، داده‌ها روی NFS Server باقی می‌مانند.
• allowVolumeExpansion: true → امکان افزایش حجم فضای ذخیره‌سازی.
• mountOptions → گزینه‌های مربوط به مانت کردن Volume.

✅ ایجاد Storage Class در Kubernetes:

kubectl apply -f nfs-storageclass.yaml

✅ مشاهده Storage Classهای موجود:

kubectl get storageclass

✅ حذف Storage Class:

kubectl delete storageclass nfs-storage

---

ایجاد PVC (PersistentVolumeClaim) برای استفاده از Storage Class

بعد از تعریف Storage Class، می‌توانیم یک PVC ایجاد کنیم تا فضا از NFS Storage Class درخواست کند.

✅ نمونه PVC مرتبط با Storage Class NFS:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  storageClassName: nfs-storage

📌 توضیحات:

• accessModes: ReadWriteMany → امکان استفاده از این فضای ذخیره‌سازی توسط چندین Pod به‌صورت همزمان.
• storage: 10Gi → مقدار فضای ذخیره‌سازی درخواست‌شده.
• storageClassName: nfs-storage → استفاده از Storage Class ایجاد شده.

✅ ایجاد PVC در Kubernetes:

kubectl apply -f nfs-pvc.yaml

✅ بررسی وضعیت PVC ایجاد شده:

kubectl get pvc

✅ حذف PVC:

kubectl delete pvc nfs-pvc

---

جمع‌بندی

با استفاده از Storage Class، می‌توان فضای ذخیره‌سازی پویا را برای Pods مدیریت کرد. در این بخش، یک Storage Class برای NFS ایجاد کردیم و با استفاده از PVC، فضای ذخیره‌سازی را به یک Pod متصل کردیم. این روش برای دیتاسنترهای خصوصی و محیط‌های غیر ابری بسیار کاربردی است. 🚀[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. StatefulSets و مدیریت داده‌های پایدار”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی StatefulSets و تفاوت آن با Deployments” subtitle=”توضيحات کامل”]در کوبرنتیز، StatefulSet یکی از منابع مهم برای مدیریت Pods است که برای برنامه‌های Stateful طراحی شده است. درحالی‌که Deployment بیشتر برای برنامه‌های Stateless استفاده می‌شود، StatefulSet برای برنامه‌هایی که نیاز به شناسایی یکتا، ترتیب خاص راه‌اندازی، و ذخیره‌سازی پایدار دارند، به‌کار می‌رود.

---

ویژگی‌های StatefulSet

✅ نام یکتا برای هر Pod
هر Pod در یک StatefulSet دارای نام ثابت و یکتا است که پس از راه‌اندازی حفظ می‌شود.

✅ راه‌اندازی ترتیبی (Ordered Startup & Scaling)
Pods در StatefulSet یکی‌یکی و به ترتیب راه‌اندازی یا مقیاس‌بندی می‌شوند.

✅ حفظ داده‌ها در صورت حذف Pod
در StatefulSet، هر Pod معمولاً دارای Persistent Volume مختص به خود است که حتی بعد از حذف Pod، داده‌ها باقی می‌مانند.

✅ استفاده از Headless Service برای ارتباط داخلی
برای دسترسی به Pods در StatefulSet، از یک Headless Service استفاده می‌شود تا هر Pod آدرس DNS یکتا داشته باشد.

---

تفاوت‌های StatefulSet و Deployment

ویژگی	StatefulSet	Deployment
شناسه یکتا برای هر Pod	دارد (pod-0, pod-1, pod-2 و …)	ندارد (Pods با نام تصادفی ایجاد می‌شوند)
راه‌اندازی ترتیبی	بله (Pods یکی‌یکی اجرا می‌شوند)	خیر (Pods به‌صورت همزمان اجرا می‌شوند)
حفظ داده‌ها بعد از حذف Pod	بله (از PersistentVolume استفاده می‌کند)	خیر (پس از حذف، داده‌ها از بین می‌روند)
کاربرد	دیتابیس‌ها، پیام‌رسان‌ها (Kafka, Zookeeper, MySQL)	برنامه‌های Stateless، APIها، وب‌سرورها

---

ایجاد یک StatefulSet در Kubernetes

✅ نمونه فایل YAML برای راه‌اندازی MySQL با StatefulSet:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        ports:
        - containerPort: 3306
        volumeMounts:
        - name: mysql-storage
          mountPath: /var/lib/mysql
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "rootpassword"
  volumeClaimTemplates:
  - metadata:
      name: mysql-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi

📌 توضیحات:

• serviceName: "mysql" → ایجاد یک Headless Service برای ارتباط بین Pods.
• replicas: 3 → ایجاد سه Pod به ترتیب (mysql-0, mysql-1, mysql-2).
• volumeClaimTemplates → هر Pod یک PersistentVolumeClaim جداگانه دریافت می‌کند.

✅ اجرای StatefulSet در Kubernetes:

kubectl apply -f mysql-statefulset.yaml

✅ بررسی وضعیت StatefulSet:

kubectl get statefulsets

✅ مشاهده Pods ایجاد شده:

kubectl get pods -l app=mysql

✅ حذف StatefulSet بدون حذف داده‌ها:

kubectl delete statefulset mysql --cascade=orphan

✅ حذف کامل StatefulSet و داده‌های آن:

kubectl delete statefulset mysql
kubectl delete pvc -l app=mysql

---

جمع‌بندی

✅ اگر برنامه شما Stateful است (مانند دیتابیس‌ها)، از StatefulSet استفاده کنید.
✅ اگر برنامه شما Stateless است (مانند سرویس‌های وب)، از Deployment استفاده کنید.
✅ StatefulSet نام Pods و داده‌های ذخیره شده را حفظ می‌کند، اما Deployment این قابلیت را ندارد.

🚀 با این روش، برنامه‌های پایدار (Stateful) مانند MySQL، Kafka، Redis، MongoDB را به‌صورت مطمئن در Kubernetes اجرا می‌کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”کاربرد StatefulSets برای برنامه‌های پایدار” subtitle=”توضيحات کامل”]در کوبرنتیز، StatefulSet برای مدیریت برنامه‌های پایدار (Stateful Applications) که نیاز به شناسه یکتا، ذخیره‌سازی پایدار، و ترتیب خاص در راه‌اندازی دارند، استفاده می‌شود.

---

چرا از StatefulSet استفاده کنیم؟

✅ شناسه یکتا برای هر Pod
هر Pod در StatefulSet دارای یک نام ثابت و یکتا است، مانند:
pod-0, pod-1, pod-2

✅ حفظ داده‌ها حتی پس از حذف یا راه‌اندازی مجدد Pods
StatefulSet از PersistentVolumeClaim (PVC) استفاده می‌کند تا داده‌های هر Pod را حفظ کند.

✅ راه‌اندازی و مقیاس‌بندی ترتیبی
Pods به ترتیب مشخصی ایجاد، مقیاس‌بندی و حذف می‌شوند، که در دیتابیس‌های توزیع‌شده اهمیت دارد.

✅ دسترسی به Pods از طریق Headless Service
ارتباط بین Pods با DNS یکتا (FQDN) امکان‌پذیر است، مثل:
mysql-0.mysql.default.svc.cluster.local

---

برنامه‌هایی که از StatefulSet استفاده می‌کنند

🚀 دیتابیس‌های توزیع‌شده:

• MySQL
• PostgreSQL
• MongoDB
• Cassandra

🚀 پیام‌رسان‌ها و سیستم‌های صف:

• Kafka
• RabbitMQ
• NATS

🚀 سیستم‌های ذخیره‌سازی توزیع‌شده:

• Ceph
• GlusterFS
• MinIO

---

مثال: پیاده‌سازی Redis با StatefulSet در Kubernetes

✅ ایجاد فایل redis-statefulset.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: redis
spec:
  serviceName: "redis"
  replicas: 3
  selector:
    matchLabels:
      app: redis
  template:
    metadata:
      labels:
        app: redis
    spec:
      containers:
      - name: redis
        image: redis:6
        ports:
        - containerPort: 6379
        volumeMounts:
        - name: redis-storage
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: redis-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 5Gi

✅ اجرای StatefulSet در Kubernetes:

kubectl apply -f redis-statefulset.yaml

✅ بررسی Pods ایجاد شده:

kubectl get pods -l app=redis

✅ دسترسی به Redis Node خاص از طریق DNS:

redis-cli -h redis-0.redis.default.svc.cluster.local

---

جمع‌بندی

✅ StatefulSet برای برنامه‌های پایدار (Stateful) مناسب است، در حالی که Deployment برای برنامه‌های بدون وضعیت (Stateless) استفاده می‌شود.
✅ داده‌های Pods در StatefulSet با PVC ذخیره می‌شوند و حتی بعد از حذف Pod، از بین نمی‌روند.
✅ برای دیتابیس‌ها، پیام‌رسان‌ها و سیستم‌های ذخیره‌سازی توزیع‌شده، StatefulSet گزینه‌ای ایده‌آل است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ایجاد Volume برای هر Replica در StatefulSets” subtitle=”توضيحات کامل”]در StatefulSet، هر Replica (Pod) نیاز به فضای ذخیره‌سازی جداگانه و پایدار دارد. برای این کار از PersistentVolumeClaim (PVC) استفاده می‌کنیم تا هر Pod یک Volume اختصاصی داشته باشد که در صورت راه‌اندازی مجدد، داده‌های آن حفظ شود.

---

🔹 چرا هر Replica نیاز به Volume اختصاصی دارد؟

✅ ذخیره‌سازی دائمی داده‌ها: با حذف یا راه‌اندازی مجدد Pod، داده‌ها از بین نمی‌روند.
✅ شناسه یکتا برای هر Volume: هر Pod نام و Volume خاص خود را دارد، مانند:

• redis-0 → redis-storage-redis-0
• redis-1 → redis-storage-redis-1
  ✅ مدیریت مستقل هر Pod: برخلاف Deployment که تمام Pods از یک Volume مشترک استفاده می‌کنند، در StatefulSet هر Replica دارای Volume جداگانه است.

---

🔹 پیاده‌سازی StatefulSet با PersistentVolumeClaim (PVC)

✅ 📌 ایجاد فایل statefulset-volume.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-app
spec:
  serviceName: "my-app-service"
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: nginx
        volumeMounts:
        - name: data-storage
          mountPath: /data
  volumeClaimTemplates:
  - metadata:
      name: data-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 5Gi

---

🔹 اجرای StatefulSet و بررسی حجم‌های ایجاد شده

✅ 📌 اعمال تنظیمات در Kubernetes

kubectl apply -f statefulset-volume.yaml

✅ 📌 مشاهده Pods و PVCها

kubectl get pods
kubectl get pvc

✅ 📌 بررسی Volume متصل به هر Pod

kubectl describe pod my-app-0
kubectl describe pod my-app-1
kubectl describe pod my-app-2

✅ 📌 بررسی اطلاعات ذخیره‌شده در Volume هر Replica

kubectl exec -it my-app-0 -- ls /data

---

🔹 نحوه حذف StatefulSet بدون از دست دادن داده‌ها

📌 حذف StatefulSet بدون حذف PVC

kubectl delete statefulset my-app --cascade=orphan

📌 حذف StatefulSet به همراه PVCها

kubectl delete statefulset my-app
kubectl delete pvc -l app=my-app

---

🔹 جمع‌بندی

✅ در StatefulSet، هر Replica نیاز به یک Volume جداگانه دارد تا داده‌های آن مستقل باشد.
✅ با استفاده از volumeClaimTemplates، هر Pod به‌طور خودکار یک PVC دریافت می‌کند.
✅ برای مشاهده و بررسی داده‌های هر Pod می‌توان از kubectl exec و kubectl describe استفاده کرد.
✅ در صورت حذف StatefulSet، PVCها و داده‌ها همچنان باقی می‌مانند مگر اینکه به‌صورت دستی حذف شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از PersistentVolume برای StatefulSets” subtitle=”توضيحات کامل”]در StatefulSet، هر Replica (Pod) نیاز به یک PersistentVolume (PV) جداگانه دارد تا داده‌های آن پس از راه‌اندازی مجدد باقی بماند. این کار با استفاده از PersistentVolumeClaim (PVC) و Storage Class انجام می‌شود.

---

🔹 چرا از PersistentVolume در StatefulSets استفاده می‌کنیم؟

✅ ذخیره‌سازی دائمی داده‌ها: اطلاعات هر Pod حتی بعد از Restart یا انتقال باقی می‌ماند.
✅ حفظ یکتایی داده‌ها: هر Pod یک Volume اختصاصی دریافت می‌کند و به یکدیگر دسترسی ندارند.
✅ مدیریت بهتر منابع ذخیره‌سازی: می‌توان از PersistentVolume‌های Static یا Dynamic استفاده کرد.

---

🔹 پیاده‌سازی PersistentVolume و StatefulSet

✅ 📌 تعریف PersistentVolume (PV) و PersistentVolumeClaim (PVC)

ابتدا یک PV برای هر Replica تعریف می‌کنیم و سپس StatefulSet را تنظیم می‌کنیم که این PVها را استفاده کند.

📌 ایجاد فایل persistent-volume.yaml

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-mysql-0
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: "/mnt/data/mysql-0"

---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-mysql-1
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: "/mnt/data/mysql-1"

✅ 📌 اعمال PV در Kubernetes

kubectl apply -f persistent-volume.yaml

✅ 📌 بررسی وضعیت PVها

kubectl get pv

---

🔹 تعریف StatefulSet و استفاده از PVC

📌 ایجاد فایل statefulset-pv.yaml

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: "mysql"
  replicas: 2
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:5.7
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "password"
        volumeMounts:
        - name: mysql-storage
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: mysql-storage
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 5Gi
      storageClassName: manual

✅ 📌 اعمال StatefulSet در Kubernetes

kubectl apply -f statefulset-pv.yaml

✅ 📌 بررسی Pods، PVC و PV

kubectl get pods
kubectl get pvc
kubectl get pv

✅ 📌 بررسی Volume متصل به هر Pod

kubectl describe pod mysql-0
kubectl describe pod mysql-1

✅ 📌 مشاهده اطلاعات ذخیره‌شده در Volume

kubectl exec -it mysql-0 -- ls /var/lib/mysql

---

🔹 حذف StatefulSet بدون از بین رفتن داده‌ها

📌 حذف StatefulSet ولی نگه داشتن PVC و PV

kubectl delete statefulset mysql --cascade=orphan

📌 حذف StatefulSet و PVCها به همراه داده‌ها

kubectl delete statefulset mysql
kubectl delete pvc -l app=mysql

📌 حذف PVها به‌صورت دستی

kubectl delete pv pv-mysql-0 pv-mysql-1

---

🔹 جمع‌بندی

✅ در StatefulSet، هر Replica نیاز به PersistentVolume جداگانه دارد.
✅ PVها می‌توانند به‌صورت Static (از قبل تعریف‌شده) یا Dynamic (با StorageClass) ایجاد شوند.
✅ با استفاده از volumeClaimTemplates، هر Pod به‌طور خودکار یک PVC دریافت می‌کند.
✅ در صورت حذف StatefulSet، PV و PVC باقی می‌مانند مگر اینکه به‌صورت دستی حذف شوند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. Lifecycle مدیریت Volume‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مدیریت ایجاد و حذف Volume‌ها در Kubernetes” subtitle=”توضيحات کامل”]در کوبرنتیز، Volume‌ها اجزای اساسی برای ذخیره‌سازی داده‌ها هستند که می‌توانند به Pods متصل شوند. مدیریت ایجاد و حذف Volume‌ها به نحوی که داده‌ها به درستی ذخیره و مدیریت شوند، یک بخش مهم از فرآیند استقرار و پشتیبانی برنامه‌ها در Kubernetes می‌باشد. در این بخش، به طور جامع نحوه ایجاد، استفاده و حذف Volume‌ها در Kubernetes پرداخته خواهد شد.

---

🔹 مفاهیم پایه‌ای Volume‌ها در Kubernetes

• Volume: در Kubernetes، Volume یک منبع ذخیره‌سازی است که می‌تواند به Pods متصل شود. Volume‌ها می‌توانند انواع مختلفی داشته باشند، مانند emptyDir، HostPath، PersistentVolume (PV)، PersistentVolumeClaim (PVC)، NFS، Ceph و غیره.
• PersistentVolume (PV): یک منبع ذخیره‌سازی مستقل از Pods است که در Kubernetes تعریف می‌شود. PV‌ها برای ذخیره‌سازی داده‌های طولانی‌مدت استفاده می‌شوند.
• PersistentVolumeClaim (PVC): یک درخواست برای ذخیره‌سازی است که به یک PV خاص تخصیص داده می‌شود.

---

🔹 ایجاد Volume‌ها در Kubernetes

Volume‌ها می‌توانند به‌صورت دائمی و موقتی در Kubernetes ایجاد شوند. در اینجا دو نوع رایج Volume ایجاد می‌کنیم: PersistentVolume (برای ذخیره‌سازی دائمی) و emptyDir (برای ذخیره‌سازی موقت).

1. ایجاد PersistentVolume (PV) و PersistentVolumeClaim (PVC)

PersistentVolume (PV) نیاز به منابع ذخیره‌سازی خارجی دارد (مثل NFS، AWS EBS یا GCP PD).

📌 ایجاد PersistentVolume (PV) با HostPath

در اینجا یک PV با استفاده از HostPath برای ایجاد Volume در Node محلی ایجاد می‌کنیم.

فایل persistent-volume.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-hostpath
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: "/mnt/data/pv-hostpath"

اعمال PV در Kubernetes:

kubectl apply -f persistent-volume.yaml

2. ایجاد PersistentVolumeClaim (PVC)

PVC برای درخواست Volume در Kubernetes است که به یک Pod تخصیص داده می‌شود. PVC به یک PV موجود متصل می‌شود یا Kubernetes یک PV جدید ایجاد می‌کند (در صورت پیکربندی Dynamic Provisioning).

فایل persistent-volume-claim.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-hostpath
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: manual

اعمال PVC در Kubernetes:

kubectl apply -f persistent-volume-claim.yaml

3. استفاده از Volume در Pods

پس از ایجاد PVC، می‌توانیم آن را به یک Pod متصل کنیم.

فایل pod-with-pvc.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-pvc
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: pvc-storage
  volumes:
    - name: pvc-storage
      persistentVolumeClaim:
        claimName: pvc-hostpath

اعمال Pod در Kubernetes:

kubectl apply -f pod-with-pvc.yaml

---

🔹 حذف Volume‌ها در Kubernetes

1. حذف PersistentVolume (PV) و PersistentVolumeClaim (PVC)

زمانی که دیگر نیازی به Volume‌ها نداریم، باید آنها را حذف کنیم. حذف یک PVC معمولاً باعث حذف PV مربوطه نمی‌شود مگر اینکه سیاست ReclaimPolicy به‌صورت Delete تنظیم شده باشد.

حذف PVC:

kubectl delete pvc pvc-hostpath

حذف PV:

kubectl delete pv pv-hostpath

در صورتی که ReclaimPolicy به‌صورت Retain تنظیم شده باشد، حذف PVC باعث حذف PV نمی‌شود و باید PV به‌صورت دستی حذف شود.

2. حذف Pods همراه با Volume

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

حذف Pod و Volume آن:

kubectl delete pod pod-with-pvc

---

🔹 حذف Volume‌های موقتی (مثل emptyDir)

emptyDir یک Volume موقتی است که هنگام راه‌اندازی یک Pod ایجاد می‌شود و زمانی که Pod حذف شود، داده‌های داخل emptyDir نیز حذف می‌شوند.

حذف Pod با emptyDir:

kubectl delete pod pod-with-emptydir

در این حالت emptyDir و داده‌های داخل آن از بین خواهند رفت زیرا این Volume وابسته به عمر Pod است.

---

🔹 مدیریت استفاده از Volume‌ها

1. مشاهده وضعیت Volume‌ها

برای بررسی وضعیت PersistentVolume و PersistentVolumeClaim، از دستور زیر استفاده می‌کنیم.

مشاهده وضعیت PV و PVC:

kubectl get pv
kubectl get pvc

2. دیباگ مشکلات Volume‌ها

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

مشاهده وضعیت Pod و Volume‌ها:

kubectl describe pod pod-with-pvc

این دستور اطلاعاتی در مورد چگونگی اتصال Volume به Pod، وضعیت Volume و مشکلات مربوط به آن ارائه می‌دهد.

---

🔹 جمع‌بندی

• PersistentVolume (PV) یک منبع ذخیره‌سازی در Kubernetes است که به Pods اختصاص داده می‌شود.
• PersistentVolumeClaim (PVC) یک درخواست برای دریافت PV است و به Pods متصل می‌شود.
• emptyDir یک Volume موقتی است که فقط تا زمانی که Pod زنده باشد موجود است.
• پس از حذف یک PVC، باید توجه داشت که آیا PV به‌صورت خودکار حذف می‌شود یا نه.
• Volume‌ها می‌توانند به‌صورت دستی و یا به‌طور خودکار با استفاده از Storage Class مدیریت شوند.
• دیباگ و مدیریت Volume‌ها برای حل مشکلات ذخیره‌سازی و اطمینان از در دسترس بودن داده‌ها در Kubernetes ضروری است.

[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی گزینه‌های Retain، Delete، و Recycle برای PersistentVolume (PV)” subtitle=”توضيحات کامل”]در کوبرنتیز، PersistentVolume (PV) یک منبع ذخیره‌سازی است که به Pods متصل می‌شود و برای ذخیره‌سازی داده‌ها به کار می‌رود. پس از اینکه یک PersistentVolumeClaim (PVC) به PV متصل و استفاده شد، بعد از حذف PVC، نحوه برخورد با PV بستگی به پیکربندی ReclaimPolicy آن دارد.

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

• Retain
• Delete
• Recycle

در این بخش، به بررسی هرکدام از این گزینه‌ها می‌پردازیم و نحوه‌ی کاربرد آن‌ها را در مدیریت PersistentVolume توضیح می‌دهیم.

---

🔹 Retain

زمانی که ReclaimPolicy به Retain تنظیم شود، PV بعد از حذف PVC همچنان باقی می‌ماند. این گزینه به این معنی است که Kubernetes هیچ اقدامی برای پاک‌سازی یا تغییر وضعیت داده‌های موجود در PV انجام نمی‌دهد. این وضعیت معمولاً زمانی کاربرد دارد که بخواهید داده‌ها را حفظ کنید و به‌صورت دستی مدیریت کنید.

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

مثال: در صورتی که PV شما از نوع HostPath باشد و بخواهید داده‌ها را حفظ کنید، می‌توانید از Retain استفاده کنید.

تعریف PV با ReclaimPolicy به‌صورت Retain:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-hostpath
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data/pv-hostpath"

---

🔹 Delete

زمانی که ReclaimPolicy به Delete تنظیم شود، هنگام حذف PVC، Kubernetes به‌طور خودکار PV را حذف می‌کند. این حالت زمانی استفاده می‌شود که بخواهید پس از استفاده از PV و حذف PVC، داده‌ها به‌طور خودکار پاک شوند.

• مزایا:
  • بعد از حذف PVC، PV به‌صورت خودکار حذف می‌شود و دیگر نیازی به مدیریت دستی وجود ندارد.
  • برای کاربردهایی که نیازی به نگهداری داده‌ها بعد از حذف PVC ندارند، بسیار مفید است.
• معایب:
  • داده‌ها به‌طور خودکار از بین می‌روند، بنابراین اگر به اشتباه PVC حذف شود، داده‌ها به‌طور دائمی از بین خواهند رفت.

مثال: اگر از سرویس‌های ذخیره‌سازی ابری مانند AWS EBS یا GCP Persistent Disks استفاده می‌کنید، در اغلب موارد توصیه می‌شود که از Delete استفاده کنید، چرا که فضای ذخیره‌سازی به‌طور خودکار پس از حذف PVC آزاد می‌شود.

تعریف PV با ReclaimPolicy به‌صورت Delete:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-aws-ebs
spec:
  capacity:
    storage: 50Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  awsElasticBlockStore:
    volumeID: "vol-xxxxxxxx"
    fsType: ext4

---

🔹 Recycle

Recycle به این معناست که بعد از حذف PVC، Kubernetes یک عملیات پاک‌سازی ابتدایی روی PV انجام می‌دهد (مثل فرمت کردن Volume) و سپس آن را برای استفاده مجدد در دسترس قرار می‌دهد. این گزینه دیگر در Kubernetes پشتیبانی نمی‌شود و به‌طور کلی حذف شده است.

• مزایا:
  • PV پس از حذف PVC به‌صورت خودکار برای استفاده مجدد آماده می‌شود.
• معایب:
  • چون این گزینه دیگر در Kubernetes به‌طور رسمی پشتیبانی نمی‌شود، از آن استفاده نمی‌شود و نمی‌توان به‌طور موثری روی آن حساب کرد.

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

---

🔹 جمع‌بندی: تفاوت‌های ReclaimPolicy در PV

ReclaimPolicy	شرح	مزایا	معایب
Retain	PV پس از حذف PVC باقی می‌ماند و باید به‌صورت دستی مدیریت شود.	داده‌ها حفظ می‌شوند و می‌توان به‌صورت دستی مدیریت کرد.	مدیریت دستی لازم است و ممکن است PV بدون استفاده باقی بماند.
Delete	PV به‌طور خودکار بعد از حذف PVC حذف می‌شود.	حذف خودکار PV و آزادسازی منابع.	داده‌ها به‌طور دائم از بین می‌روند.
Recycle	این گزینه برای پاک‌سازی خودکار و آماده‌سازی مجدد PV است (دیگر پشتیبانی نمی‌شود).	–	دیگر در Kubernetes پشتیبانی نمی‌شود.

---

🔹 نحوه تنظیم ReclaimPolicy در فایل YAML

برای تنظیم ReclaimPolicy در هنگام تعریف PersistentVolume، کافی است که بخش persistentVolumeReclaimPolicy را به یکی از مقادیر Retain، Delete یا Recycle تنظیم کنید. در اینجا یک مثال از تنظیم ReclaimPolicy آورده شده است:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: example-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain   # یا Delete / Recycle
  hostPath:
    path: /mnt/data

---

🔹 حذف و مدیریت PV با ReclaimPolicy

در صورت استفاده از Retain، اگر PVC حذف شود، باید به‌صورت دستی عمل کنید تا PV را برای استفاده مجدد تنظیم یا حذف کنید. در صورت استفاده از Delete، تنها با حذف PVC، PV به‌طور خودکار حذف می‌شود.

حذف PV به‌صورت دستی:

kubectl delete pv example-pv

---

جمع‌بندی

• Retain مناسب زمانی است که نیاز دارید داده‌ها را حفظ کرده و به‌صورت دستی روی آن‌ها کار کنید.
• Delete معمولاً زمانی استفاده می‌شود که نیازی به نگهداری داده‌ها بعد از حذف PVC نباشد و می‌خواهید منابع ذخیره‌سازی آزاد شوند.
• Recycle در نسخه‌های قدیمی‌تر Kubernetes پشتیبانی می‌شد اما اکنون حذف شده است و دیگر مورد استفاده قرار نمی‌گیرد.

در نهایت، انتخاب گزینه مناسب به نیازهای ذخیره‌سازی و نحوه مدیریت داده‌ها بستگی دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه اطمینان از عدم از دست رفتن داده‌ها هنگام حذف Pod یا Node” subtitle=”توضيحات کامل”]در Kubernetes، یکی از چالش‌های اصلی مدیریت داده‌ها در صورتی که یک Pod یا Node حذف شود، جلوگیری از از دست رفتن داده‌ها است. در Kubernetes، Pods به‌طور پیش‌فرض موقت هستند، به این معنی که داده‌هایی که در داخل یک Pod ذخیره می‌شوند، در صورت حذف آن Pod از بین خواهند رفت. برای اطمینان از عدم از دست رفتن داده‌ها، باید از Volume‌ها استفاده کنید تا داده‌ها در خارج از Pod ذخیره شوند.

در اینجا چند روش برای محافظت از داده‌ها و اطمینان از عدم از دست رفتن آن‌ها آورده شده است:

---

🔹 استفاده از PersistentVolumes (PVs) و PersistentVolumeClaims (PVCs)

در Kubernetes، PersistentVolumes (PVs) و PersistentVolumeClaims (PVCs) به شما این امکان را می‌دهند که داده‌ها را به‌صورت دائمی ذخیره کنید. برخلاف Volumes معمولی که با Pod حذف می‌شوند، PVs و PVCs مستقل از عمر Pods عمل می‌کنند و به‌طور خودکار داده‌ها را حتی اگر Pod حذف شود حفظ می‌کنند.

چگونه از PVs و PVCs برای محافظت از داده‌ها استفاده کنیم؟

1. ایجاد PersistentVolume (PV): در ابتدا باید یک PersistentVolume (PV) ایجاد کنید که به یک فضای ذخیره‌سازی دائمی اشاره داشته باشد. این PV می‌تواند از انواع مختلف ذخیره‌سازی مانند NFS، AWS EBS، GCP PD یا Local Disk استفاده کند.
2. ایجاد PersistentVolumeClaim (PVC): پس از ایجاد PV، یک PersistentVolumeClaim (PVC) ایجاد می‌کنید که درخواست منابع ذخیره‌سازی از PV می‌کند. PVC به‌طور خودکار به PV متصل می‌شود و در صورت حذف Pod، داده‌ها حفظ می‌شوند.
3. اتصال PVC به Pod: زمانی که Pod راه‌اندازی می‌شود، می‌توانید PVC را به Pod متصل کنید تا داده‌ها در آن ذخیره شوند.

مثال: ایجاد PV و PVC

تعریف PersistentVolume (PV):

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  nfs:
    path: /mnt/data
    server: nfs-server.example.com

تعریف PersistentVolumeClaim (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

تعریف Pod با PVC:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: my-volume
  volumes:
    - name: my-volume
      persistentVolumeClaim:
        claimName: my-pvc

---

🔹 استفاده از StatefulSets برای حفظ داده‌ها در Pods با وضعیت

StatefulSet یک منبع مدیریت شده در Kubernetes است که برای برنامه‌های دارای وضعیت (Stateful) طراحی شده است. برخلاف Deployments که برای برنامه‌های بدون وضعیت (Stateless) مناسب هستند، StatefulSets به Pods اجازه می‌دهند تا وضعیت خود را حفظ کنند.

برای هر Pod در یک StatefulSet، Kubernetes یک Volume دائمی به‌صورت خودکار ایجاد می‌کند. این به این معناست که اگر یک Pod دوباره راه‌اندازی شود یا حذف شود، Kubernetes همان Volume را به Pod جدید متصل می‌کند، که باعث حفظ داده‌ها می‌شود.

چگونه از StatefulSets برای حفظ داده‌ها استفاده کنیم؟

1. تعریف StatefulSet: در فایل YAML، یک StatefulSet تعریف می‌کنید و از PVC برای درخواست فضای ذخیره‌سازی استفاده می‌کنید.
2. ایجاد PersistentVolumeClaim (PVC): مشابه با مراحل قبلی، از PVC برای درخواست فضای ذخیره‌سازی استفاده می‌کنید.

مثال: استفاده از StatefulSet برای حفظ داده‌ها

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: my-statefulset
spec:
  serviceName: "my-service"
  replicas: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: nginx
          volumeMounts:
            - name: my-volume
              mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
    - metadata:
        name: my-volume
      spec:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 10Gi

در این مثال، برای هر Replica یک PersistentVolume ایجاد می‌شود و به Pod اختصاص داده می‌شود، که باعث حفظ داده‌ها حتی پس از حذف یک Pod می‌شود.

---

🔹 استفاده از PodDisruptionBudgets (PDB) برای جلوگیری از حذف ناگهانی Pods

برای جلوگیری از حذف ناگهانی Pods به‌ویژه در زمان بروزرسانی‌ها یا خرابی‌های سیستم، می‌توانید از PodDisruptionBudget (PDB) استفاده کنید. این ابزار اطمینان می‌دهد که تعداد مشخصی از Pods همیشه در دسترس باشند.

مثال: تنظیم PodDisruptionBudget (PDB)

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-pdb
spec:
  minAvailable: 1
  selector:
    matchLabels:
      app: my-app

این تنظیمات به Kubernetes می‌گوید که همیشه حداقل یک Pod از برنامه در دسترس باشد و از حذف بیش از حد Pods جلوگیری می‌کند.

---

🔹 استفاده از Replication Controllers برای افزونگی داده‌ها

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

مثال: استفاده از ReplicaSet برای افزایش افزونگی

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

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

---

🔹 جمع‌بندی

برای اطمینان از عدم از دست رفتن داده‌ها هنگام حذف Pod یا Node، می‌توان از روش‌های مختلفی استفاده کرد:

1. استفاده از PersistentVolumes (PVs) و PersistentVolumeClaims (PVCs): با اتصال PVC به Pod، داده‌ها حتی اگر Pod حذف شوند حفظ می‌شوند.
2. استفاده از StatefulSets: برای برنامه‌های پایدار که نیاز به حفظ داده‌ها دارند، از StatefulSet استفاده کنید که برای هر Pod یک Volume دائمی ایجاد می‌کند.
3. استفاده از PodDisruptionBudgets (PDB): برای جلوگیری از حذف ناگهانی Pods و از دست رفتن داده‌ها، از PDB استفاده کنید.
4. استفاده از Replication Controllers یا ReplicaSets: برای اطمینان از افزونگی Pods و جلوگیری از از دست رفتن داده‌ها در صورت خرابی یا حذف Pods.

با این روش‌ها، می‌توانید اطمینان حاصل کنید که داده‌ها در هنگام حذف Pods یا Nodes از دست نمی‌روند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. Volume Mounts و SubPath”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تعریف Volume Mounts” subtitle=”توضيحات کامل”]در کوبرنتیز، Volume Mounts به فرآیند اتصال یک Volume به Container اشاره دارند. این عمل به کانتینرها این امکان را می‌دهد که به داده‌ها و اطلاعات ذخیره‌شده در Volume‌ها دسترسی داشته باشند. Volume‌ها به‌طور معمول برای ذخیره‌سازی دائمی داده‌ها یا اشتراک‌گذاری داده‌ها بین کانتینرها استفاده می‌شوند. اما Volume Mounts مسئول اتصال این داده‌ها به کانتینر هستند تا بتوانند از آن‌ها استفاده کنند.

وقتی یک Volume به کانتینرها متصل می‌شود، Volume Mounts برای مشخص کردن مسیرهایی که داده‌ها باید در داخل کانتینر قرار بگیرند، استفاده می‌شود. این مسیرها معمولاً در داخل کانتینرها به‌عنوان دایرکتوری‌های محلی عمل می‌کنند.

---

چگونه از Volume Mounts استفاده می‌شود؟

برای استفاده از Volume Mounts، ابتدا باید یک Volume تعریف کنید و سپس آن را به کانتینر در داخل Pod متصل کنید. در اینجا یک مثال برای روشن‌تر کردن مفهوم آورده شده است.

---

مثال: استفاده از Volume Mounts در Pod

در این مثال، یک emptyDir volume به کانتینر متصل شده است که داده‌ها را در داخل مسیر /data ذخیره می‌کند.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: myvolume
  volumes:
    - name: myvolume
      emptyDir: {}

در این مثال:

• mountPath: /data مسیر در داخل کانتینر است که داده‌ها از Volume به آن‌جا منتقل خواهند شد.
• name: myvolume نامی است که به Volume اختصاص داده شده است.
• emptyDir: {} نوع Volume است که برای ذخیره داده‌ها به‌طور موقت و در طول عمر Pod استفاده می‌شود.

---

چرا Volume Mounts مهم هستند؟

• اشتراک‌گذاری داده‌ها بین کانتینرها: با استفاده از Volume Mounts، کانتینرهای مختلف در یک Pod می‌توانند به‌طور مشترک از یک Volume استفاده کنند.
• داده‌های دائمی: اگر Volume به‌درستی Mount شود، داده‌ها می‌توانند از Pod‌ها و کانتینرهای حذف‌شده محفوظ بمانند.
• انعطاف‌پذیری در ذخیره‌سازی: Volume Mounts اجازه می‌دهند که داده‌ها از منابع مختلف ذخیره‌سازی (مثل NFS، EBS، GCP PD و غیره) به کانتینرهای Kubernetes متصل شوند.

---

محدودیت‌ها و چالش‌ها

• محدودیت در دسترسی: در صورتی که از Volume‌های با accessMode خاصی استفاده کنید (مثل ReadWriteOnce)، تنها یک کانتینر می‌تواند در یک زمان به آن دسترسی داشته باشد.
• محتوای همزمان: اگر چندین کانتینر به یک Volume با دسترسی همزمان (ReadWriteMany) متصل شوند، باید اطمینان حاصل کنید که داده‌ها به درستی مدیریت شوند.

---

جمع‌بندی

Volume Mounts در Kubernetes ابزاری مهم برای اتصال Volumes به کانتینرها هستند که به‌طور مستقیم بر نحوه ذخیره‌سازی و دسترسی به داده‌ها تأثیر می‌گذارند. این فرایند به شما امکان می‌دهد تا داده‌ها را به‌صورت مشترک بین کانتینرها به اشتراک بگذارید یا آن‌ها را به‌طور دائمی ذخیره کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از SubPath برای محدود کردن دسترسی به بخشی از Volume” subtitle=”توضيحات کامل”]در Kubernetes، می‌توان از ویژگی SubPath برای محدود کردن دسترسی یک کانتینر به بخش خاصی از یک Volume استفاده کرد. این ویژگی به شما این امکان را می‌دهد که فقط یک زیرمسیر (subdirectory) خاص از Volume را به یک کانتینر اختصاص دهید. این ویژگی زمانی مفید است که بخواهید چندین کانتینر به یک Volume مشترک دسترسی داشته باشند، اما هر کانتینر تنها به یک بخش خاص از آن Volume نیاز داشته باشد.

---

چرا از SubPath استفاده کنیم؟

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

---

نحوه استفاده از SubPath در YAML

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

---

مثال: استفاده از SubPath در فایل YAML

در این مثال، از emptyDir به‌عنوان Volume استفاده شده است و دو کانتینر داریم که هرکدام به یک زیرمسیر خاص از این Volume دسترسی دارند.

apiVersion: v1
kind: Pod
metadata:
  name: subpath-example
spec:
  containers:
    - name: container1
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: myvolume
          subPath: container1-data
    - name: container2
      image: nginx
      volumeMounts:
        - mountPath: /data
          name: myvolume
          subPath: container2-data
  volumes:
    - name: myvolume
      emptyDir: {}

در این مثال:

• subPath: container1-data و subPath: container2-data به‌طور خاص زیرمسیرهایی از Volume را به کانتینرها اختصاص داده است.
• mountPath: /data مسیر داخلی کانتینرها است که داده‌ها به آنجا متصل می‌شوند.
• name: myvolume نام Volume است که هر دو کانتینر از آن استفاده می‌کنند.

---

توضیحات بیشتر

• subPath به شما این امکان را می‌دهد که داده‌ها را در مسیرهای خاص ذخیره کرده و از تداخل داده‌ها بین کانتینرها جلوگیری کنید.
• برای هر کانتینر می‌توان یک subPath منحصر به فرد تنظیم کرد که باعث می‌شود کانتینرهای مختلف دسترسی محدود به یک Volume مشترک داشته باشند.

---

محدودیت‌ها و نکات

• SubPath تنها برای Volumes که از نوع persistent هستند مناسب نیست. در صورتی که بخواهید از SubPath برای Volumes موقت استفاده کنید، ممکن است چالش‌هایی در مقیاس‌پذیری یا بازیابی داده‌ها به وجود آید.
• برای هر کانتینر تنها یک subPath مجاز است، یعنی اگر کانتینر بخواهد به چند بخش مختلف از یک Volume دسترسی داشته باشد، باید از VolumeMounts مختلف به‌طور همزمان استفاده کند.

---

جمع‌بندی

استفاده از SubPath در Kubernetes به شما این امکان را می‌دهد که دسترسی به بخش‌های خاصی از Volume را برای هر کانتینر محدود کنید. این ویژگی در هنگام کار با Volume‌های مشترک و Containerهای متعدد بسیار مفید است و باعث جداسازی بهتر داده‌ها و بهینه‌سازی استفاده از منابع ذخیره‌سازی می‌شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”سناریوهای استفاده از SubPath در پروژه‌ها” subtitle=”توضيحات کامل”]استفاده از SubPath در Kubernetes می‌تواند در بسیاری از پروژه‌ها و کاربردهای عملی مفید باشد. این ویژگی به شما کمک می‌کند که داده‌ها را در بخش‌های خاصی از یک Volume ذخیره کرده و از تداخل داده‌ها میان کانتینرهای مختلف جلوگیری کنید. در اینجا چند سناریو برای استفاده از SubPath آورده شده است:

---

1. استفاده از SubPath برای مدیریت داده‌های پیکربندی مختلف در کانتینرها

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

سناریو:

• پروژه‌ای که در آن چندین کانتینر باید فایل‌های پیکربندی مختلفی را بارگذاری کنند، مانند یک سرویس وب که برای هر محیط (تولید، توسعه، آزمایش) فایل‌های پیکربندی متفاوت دارد.
• با استفاده از SubPath می‌توان هر کانتینر را به یک زیرمسیر خاص از Volume هدایت کرد که فایل پیکربندی مخصوص به خود را بارگذاری کند.

مثال YAML:

apiVersion: v1
kind: Pod
metadata:
  name: config-example
spec:
  containers:
    - name: web-server
      image: nginx
      volumeMounts:
        - mountPath: /etc/config
          name: config-volume
          subPath: web-config
    - name: api-server
      image: nginx
      volumeMounts:
        - mountPath: /etc/config
          name: config-volume
          subPath: api-config
  volumes:
    - name: config-volume
      configMap:
        name: app-config

---

2. استفاده از SubPath برای ذخیره داده‌های log در کانتینرهای مختلف

در سیستم‌های توزیع‌شده که چندین کانتینر به تولید لاگ می‌پردازند، SubPath می‌تواند برای ذخیره لاگ‌ها در مسیرهای مجزا از یک Volume مشترک استفاده شود. اینکار به شما این امکان را می‌دهد که هر کانتینر لاگ‌های خودش را در مسیر خاصی ذخیره کند.

سناریو:

• در یک سیستم تجزیه و تحلیل لاگ‌ها که کانتینرهای مختلف لاگ‌های مختلفی تولید می‌کنند (مانند لاگ‌های وب، لاگ‌های اپلیکیشن، و غیره).
• با استفاده از SubPath می‌توان هر کانتینر را به یک مسیر خاص برای ذخیره لاگ‌ها هدایت کرد تا از تداخل داده‌ها جلوگیری شود.

مثال YAML:

apiVersion: v1
kind: Pod
metadata:
  name: log-example
spec:
  containers:
    - name: web-container
      image: nginx
      volumeMounts:
        - mountPath: /var/log
          name: log-volume
          subPath: web-logs
    - name: api-container
      image: nginx
      volumeMounts:
        - mountPath: /var/log
          name: log-volume
          subPath: api-logs
  volumes:
    - name: log-volume
      emptyDir: {}

---

3. استفاده از SubPath برای ذخیره داده‌های پایگاه داده با جداکردن اطلاعات مختلف

در پروژه‌های پایگاه داده که نیاز است داده‌ها از هم جدا شوند، استفاده از SubPath برای هر دیتابیس یا جدول می‌تواند مفید باشد. این کار کمک می‌کند تا از اشتراک‌گذاری داده‌ها بین دیتابیس‌ها جلوگیری شود.

سناریو:

• یک سیستم مدیریت پایگاه داده توزیع‌شده که از چندین کانتینر برای مدیریت داده‌های مختلف استفاده می‌کند. برای مثال، یک کانتینر مسئول ذخیره اطلاعات مربوط به کاربران و کانتینر دیگر مسئول ذخیره اطلاعات مربوط به محصولات است.
• با استفاده از SubPath می‌توان هر کانتینر را به بخش خاصی از Volume هدایت کرد.

مثال YAML:

apiVersion: v1
kind: Pod
metadata:
  name: db-example
spec:
  containers:
    - name: user-db
      image: mysql
      volumeMounts:
        - mountPath: /var/lib/mysql
          name: db-volume
          subPath: user-db
    - name: product-db
      image: mysql
      volumeMounts:
        - mountPath: /var/lib/mysql
          name: db-volume
          subPath: product-db
  volumes:
    - name: db-volume
      emptyDir: {}

---

4. استفاده از SubPath برای مدیریت داده‌های موجود در حجم‌های مشترک با چندین کانتینر

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

سناریو:

• در پروژه‌های بزرگ که در آن‌ها چندین سرویس مختلف از یک Volume مشترک برای ذخیره داده‌ها استفاده می‌کنند. به جای اینکه داده‌ها به صورت یکپارچه ذخیره شوند، می‌توان هر سرویس را به یک بخش خاص از Volume هدایت کرد.

مثال YAML:

apiVersion: v1
kind: Pod
metadata:
  name: shared-volume-example
spec:
  containers:
    - name: app-container-1
      image: app-image
      volumeMounts:
        - mountPath: /data
          name: shared-volume
          subPath: app1-data
    - name: app-container-2
      image: app-image
      volumeMounts:
        - mountPath: /data
          name: shared-volume
          subPath: app2-data
  volumes:
    - name: shared-volume
      emptyDir: {}

---

جمع‌بندی

استفاده از SubPath در Kubernetes برای موارد مختلفی می‌تواند مفید باشد، از جمله برای مدیریت پیکربندی‌های مختلف، ذخیره‌سازی داده‌های لاگ، جداسازی داده‌های پایگاه داده و یا اشتراک‌گذاری داده‌ها بین چندین کانتینر در یک Volume مشترک. این قابلیت کمک می‌کند تا داده‌ها به‌صورت بهینه و از هم جدا ذخیره شوند و از تداخل آن‌ها جلوگیری شود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. Volumeهای شبکه‌ای”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی Volumeهای شبکه‌ای مانند NFS و Ceph” subtitle=”توضيحات کامل”]در Kubernetes، برای ذخیره‌سازی داده‌ها و اطلاعات، علاوه بر Volumeهای محلی، می‌توان از Volumeهای شبکه‌ای استفاده کرد که به این امکان می‌دهند داده‌ها از چندین Node قابل دسترس باشند. این نوع Volumeها بیشتر برای سیستم‌های توزیع‌شده و مقیاس‌پذیر مفید هستند. در این قسمت به بررسی NFS و Ceph به عنوان دو نمونه از Volumeهای شبکه‌ای خواهیم پرداخت.

---

1. NFS (Network File System)

NFS یک پروتکل شبکه‌ای است که به سیستم‌های مختلف اجازه می‌دهد به طور اشتراکی به فایل‌ها دسترسی پیدا کنند. در Kubernetes، می‌توان از NFS برای اشتراک‌گذاری فایل‌ها بین Pods و Nodes مختلف استفاده کرد.

ویژگی‌ها و کاربردها:

• اشتراک‌گذاری فایل‌ها: به شما این امکان را می‌دهد که داده‌ها را بین Pods مختلف در کلاستر Kubernetes به اشتراک بگذارید.
• قابلیت مقیاس‌پذیری: در محیط‌های مقیاس‌پذیر که نیاز به دسترسی به داده‌ها از چندین Node است، بسیار مفید است.
• دسترس‌پذیری بالا: اگر سرور NFS به درستی تنظیم شود، می‌تواند به عنوان یک راهکار پایدار برای ذخیره‌سازی داده‌ها عمل کند.

مزایا:

• امکان اشتراک‌گذاری فایل‌ها در بین چندین Pod.
• استفاده از یک سرور NFS متمرکز برای مدیریت داده‌ها.
• قابلیت استفاده از NFS به عنوان یک فایل سیستم شبکه‌ای.

محدودیت‌ها:

• ممکن است عملکرد پایین‌تری نسبت به برخی از دیگر سیستم‌های ذخیره‌سازی مانند Ceph داشته باشد.
• به‌طور معمول نیاز به تنظیمات شبکه‌ای دقیق دارد.

نحوه استفاده از NFS در Kubernetes:

برای استفاده از NFS در Kubernetes، ابتدا باید سرور NFS را راه‌اندازی کنید، سپس از آن به عنوان Volume در فایل‌های YAML استفاده کنید.

مثال YAML برای استفاده از NFS در Kubernetes:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  nfs:
    path: /exported/path
    server: nfs-server.example.com
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: nfs-example
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: nfs-volume
  volumes:
    - name: nfs-volume
      persistentVolumeClaim:
        claimName: nfs-pvc

---

2. Ceph

Ceph یک پلتفرم ذخیره‌سازی توزیع‌شده و مقیاس‌پذیر است که از ذخیره‌سازی ابری و فایل سیستم‌های بلوکی پشتیبانی می‌کند. در Kubernetes، از Ceph می‌توان برای فراهم کردن ذخیره‌سازی پایدار و مقیاس‌پذیر برای Pods استفاده کرد.

ویژگی‌ها و کاربردها:

• ذخیره‌سازی بلوکی و فایل: Ceph می‌تواند به عنوان یک block storage (برای ذخیره داده‌های مبتنی بر بلوک) یا file system (برای ذخیره داده‌های فایل‌محور) استفاده شود.
• مقیاس‌پذیری: این سیستم می‌تواند در مقیاس بزرگ مقیاس‌پذیر شود و به راحتی به چندین Node و Pod در کلاستر Kubernetes متصل شود.
• High Availability: با استفاده از الگوریتم‌های توزیع‌شده، Ceph به طور خودکار اطلاعات را بین چندین گره ذخیره می‌کند تا از خرابی داده‌ها جلوگیری کند.

مزایا:

• مقیاس‌پذیری بسیار بالا برای ذخیره‌سازی.
• قابلیت پشتیبانی از انواع مختلف ذخیره‌سازی (Block Storage و Object Storage).
• قابلیت مدیریت خودکار داده‌ها و توزیع آن‌ها برای افزایش دسترس‌پذیری.

محدودیت‌ها:

• تنظیم و نگهداری آن می‌تواند پیچیده باشد.
• نیاز به منابع سخت‌افزاری قدرتمند برای عملکرد بهتر دارد.

نحوه استفاده از Ceph در Kubernetes:

برای استفاده از Ceph در Kubernetes، ابتدا باید Ceph Cluster را راه‌اندازی کرده و سپس از آن به عنوان PersistentVolume در Kubernetes استفاده کنید.

مثال YAML برای استفاده از Ceph در Kubernetes:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ceph-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Block
  accessModes:
    - ReadWriteOnce
  cephfs:
    monitors:
      - 192.168.1.1:6789
    path: /volumes/pv1
    user: admin
    secretRef:
      name: ceph-secret
    fsType: ceph
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ceph-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: v1
kind: Pod
metadata:
  name: ceph-example
spec:
  containers:
    - name: app-container
      image: my-app
      volumeMounts:
        - mountPath: /data
          name: ceph-volume
  volumes:
    - name: ceph-volume
      persistentVolumeClaim:
        claimName: ceph-pvc

---

جمع‌بندی

NFS و Ceph هر دو راهکارهای قدرتمندی برای ذخیره‌سازی در Kubernetes هستند. NFS برای استفاده در سیستم‌های ساده‌تر که نیاز به اشتراک‌گذاری فایل‌ها دارند، مناسب است، در حالی که Ceph برای سیستم‌های بزرگ و مقیاس‌پذیر با نیاز به ذخیره‌سازی بلوکی یا فایل‌محور توصیه می‌شود. انتخاب بین این دو بستگی به نیازهای خاص پروژه و زیرساخت مورد نظر دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تنظیم و پیکربندی NFS Volume در Kubernetes” subtitle=”توضيحات کامل”]برای استفاده از NFS (Network File System) در Kubernetes، شما ابتدا نیاز به راه‌اندازی یک سرور NFS دارید که بتوانید از آن برای اشتراک‌گذاری داده‌ها بین Pods مختلف در کلاستر استفاده کنید. پس از تنظیم سرور NFS، می‌توانید PersistentVolume (PV) را در Kubernetes پیکربندی کنید تا از NFS به عنوان یک منبع ذخیره‌سازی استفاده شود.

در این بخش، مراحل پیکربندی NFS Volume در Kubernetes را بررسی خواهیم کرد.

---

1. تنظیم سرور NFS

قبل از استفاده از NFS در Kubernetes، باید سرور NFS را تنظیم کنید. این سرور باید در دسترس کلاستر Kubernetes باشد.

نصب NFS Server (در یک ماشین لینوکسی):

1. نصب بسته‌های مورد نیاز:

   sudo apt update
   sudo apt install nfs-kernel-server
   

2. ایجاد پوشه‌ای که قرار است به اشتراک گذاشته شود:

   sudo mkdir -p /exported/path
   sudo chown nobody:nogroup /exported/path
   

3. اضافه کردن مسیر به فایل exports برای اشتراک‌گذاری پوشه:

   sudo nano /etc/exports
   

   خط زیر را اضافه کنید تا پوشه /exported/path به تمامی ماشین‌ها قابل دسترسی باشد:

   /exported/path *(rw,sync,no_subtree_check)
   

4. راه‌اندازی مجدد سرویس NFS:

   sudo exportfs -a
   sudo systemctl restart nfs-kernel-server
   

5. بررسی اینکه NFS Server به درستی راه‌اندازی شده است:

   sudo systemctl status nfs-kernel-server
   

---

2. پیکربندی NFS Volume در Kubernetes

پس از راه‌اندازی NFS Server، می‌توانید در Kubernetes از آن به عنوان یک PersistentVolume (PV) استفاده کنید.

a. ایجاد PersistentVolume (PV)

در ابتدا باید یک PersistentVolume ایجاد کنید که به NFS Server متصل شود. در این مرحله، شما نیاز به اطلاعاتی مانند آدرس سرور NFS و مسیر اشتراک‌گذاری دارید.

مثال YAML برای ایجاد PersistentVolume از NFS:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  nfs:
    path: /exported/path  # مسیر اشتراک‌گذاری در NFS Server
    server: nfs-server.example.com  # آدرس NFS Server
  persistentVolumeReclaimPolicy: Retain

این PersistentVolume به سرور NFS که آدرس آن nfs-server.example.com است، متصل می‌شود و دسترسی ReadWriteMany به مسیر /exported/path را فراهم می‌کند.

b. ایجاد PersistentVolumeClaim (PVC)

بعد از تعریف PersistentVolume، شما باید یک PersistentVolumeClaim (PVC) بسازید که از این PersistentVolume درخواست کند.

مثال YAML برای ایجاد PersistentVolumeClaim (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 5Gi

این PVC از PersistentVolume با ظرفیت ۵ گیگابایت و دسترسی ReadWriteMany درخواست می‌کند.

c. استفاده از PVC در Pod

در نهایت، شما می‌توانید PersistentVolumeClaim را به یک Pod متصل کنید تا داده‌ها به صورت پایدار ذخیره شوند.

مثال YAML برای استفاده از PVC در Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nfs-example
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: nfs-volume
  volumes:
    - name: nfs-volume
      persistentVolumeClaim:
        claimName: nfs-pvc

در اینجا، یک Pod با کانتینر nginx ایجاد می‌شود و داده‌ها از NFS که از طریق PVC متصل شده است، در مسیر /usr/share/nginx/html روی کانتینر قرار می‌گیرند.

---

3. استفاده از NFS به‌عنوان Volume در Kubernetes

با این تنظیمات، شما می‌توانید از NFS به عنوان یک Volume برای ذخیره‌سازی داده‌ها در Kubernetes استفاده کنید. به یاد داشته باشید که NFS معمولاً برای کاربردهایی که نیاز به اشتراک‌گذاری داده‌ها بین Pods مختلف در Kubernetes دارند، مناسب است. همچنین از آن می‌توان برای ایجاد ReadWriteMany برای دسترسی چندگانه به داده‌ها استفاده کرد.

---

جمع‌بندی

تنظیم و پیکربندی NFS Volume در Kubernetes شامل مراحل مختلفی است که از راه‌اندازی سرور NFS شروع می‌شود و سپس با ایجاد PersistentVolume و PersistentVolumeClaim در Kubernetes ادامه می‌یابد. این روش به شما این امکان را می‌دهد که داده‌ها را به صورت مشترک بین Pods مختلف در کلاستر Kubernetes استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Volumeهای شبکه‌ای در محیط‌های Multi-Node” subtitle=”توضيحات کامل”]در Kubernetes، زمانی که شما نیاز دارید تا داده‌ها بین Pods که روی نودهای مختلف (Multi-Node) در حال اجرا هستند به اشتراک گذاشته شوند، استفاده از Volumeهای شبکه‌ای یک راهکار موثر و ضروری است. در این سناریو، Volumeها به جای آنکه به صورت فیزیکی به یک نود خاص متصل شوند، به صورت شبکه‌ای و از طریق شبکه بین نودها قابل دسترسی هستند.

در این بخش، مراحل استفاده از Volumeهای شبکه‌ای در محیط‌های Multi-Node، به ویژه با استفاده از فناوری‌هایی مثل NFS، Ceph، و GlusterFS، را بررسی خواهیم کرد.

---

1. استفاده از NFS در محیط‌های Multi-Node

NFS (Network File System) یک پروتکل استاندارد برای اشتراک‌گذاری فایل‌ها بین سیستم‌های مختلف در شبکه است. در Kubernetes، می‌توان از NFS Volume برای اشتراک‌گذاری داده‌ها بین Pods روی نودهای مختلف استفاده کرد.

الف. تنظیم سرور NFS

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

1. نصب و پیکربندی سرور NFS همانند دستورالعمل‌های قبلی.
2. ایجاد یک مسیر اشتراک‌گذاری در سرور NFS.
3. تنظیم اشتراک‌گذاری فایل و ارائه دسترسی به نودهای Kubernetes.

ب. پیکربندی NFS Volume در Kubernetes

پس از راه‌اندازی سرور NFS، شما می‌توانید از آن به عنوان یک Volume در Kubernetes استفاده کنید.

تعریف PersistentVolume با استفاده از NFS:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  nfs:
    path: /exported/path
    server: nfs-server.example.com
  persistentVolumeReclaimPolicy: Retain

تعریف PersistentVolumeClaim (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

استفاده از PVC در Pod:

apiVersion: v1
kind: Pod
metadata:
  name: nfs-example
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: nfs-volume
  volumes:
    - name: nfs-volume
      persistentVolumeClaim:
        claimName: nfs-pvc

این تنظیمات به شما این امکان را می‌دهند که داده‌ها را از NFS Volume روی نودهای مختلف کلاستر Kubernetes به اشتراک بگذارید.

---

2. استفاده از Ceph برای Volumeهای شبکه‌ای در محیط‌های Multi-Node

Ceph یک راهکار ذخیره‌سازی مقیاس‌پذیر و توزیع‌شده است که می‌تواند به عنوان یک Volume شبکه‌ای در Kubernetes مورد استفاده قرار گیرد. Ceph این امکان را می‌دهد که داده‌ها را بین نودهای مختلف کلاستر Kubernetes به اشتراک بگذارید.

الف. راه‌اندازی Ceph Cluster

برای استفاده از Ceph در Kubernetes، ابتدا باید یک کلاستر Ceph ایجاد کنید که شامل نودهای مختلف برای ذخیره‌سازی داده‌ها باشد.

1. نصب و راه‌اندازی Ceph Cluster.
2. تنظیم CephFS یا RBD (RADOS Block Device) برای استفاده به عنوان Volume در Kubernetes.
3. پیکربندی Ceph برای ایجاد دسترسی به Volumeها از طریق Kubernetes.

ب. پیکربندی Ceph Volume در Kubernetes

پس از راه‌اندازی Ceph Cluster، می‌توانید از CephFS یا RBD برای استفاده در Kubernetes به عنوان Volume استفاده کنید.

تعریف PersistentVolume با استفاده از Ceph:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: ceph-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  cephfs:
    monitors:
      - ceph-monitor1.example.com:6789
    path: /exported/path
    user: admin
    secretRef:
      name: ceph-secret
  persistentVolumeReclaimPolicy: Retain

تعریف PersistentVolumeClaim (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: ceph-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

استفاده از PVC در Pod:

apiVersion: v1
kind: Pod
metadata:
  name: ceph-example
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: ceph-volume
  volumes:
    - name: ceph-volume
      persistentVolumeClaim:
        claimName: ceph-pvc

---

3. استفاده از GlusterFS برای Volumeهای شبکه‌ای در محیط‌های Multi-Node

GlusterFS یک سیستم ذخیره‌سازی مقیاس‌پذیر و توزیع‌شده است که می‌تواند به عنوان یک Volume شبکه‌ای در Kubernetes استفاده شود.

الف. راه‌اندازی GlusterFS

برای استفاده از GlusterFS، ابتدا باید یک کلاستر GlusterFS ایجاد کنید که بتواند داده‌ها را به صورت توزیع‌شده بین نودهای مختلف کلاستر Kubernetes ذخیره کند.

1. نصب و راه‌اندازی GlusterFS Cluster.
2. ایجاد Volumeهای GlusterFS برای استفاده در Kubernetes.

ب. پیکربندی GlusterFS Volume در Kubernetes

تعریف PersistentVolume با استفاده از GlusterFS:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: glusterfs-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteMany
  glusterfs:
    endpoints: glusterfs-cluster
    path: gluster-volume
    readOnly: false
  persistentVolumeReclaimPolicy: Retain

تعریف PersistentVolumeClaim (PVC):

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: glusterfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi

استفاده از PVC در Pod:

apiVersion: v1
kind: Pod
metadata:
  name: glusterfs-example
spec:
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: glusterfs-volume
  volumes:
    - name: glusterfs-volume
      persistentVolumeClaim:
        claimName: glusterfs-pvc

---

جمع‌بندی

استفاده از Volumeهای شبکه‌ای مانند NFS، Ceph، و GlusterFS در محیط‌های Multi-Node در Kubernetes به شما این امکان را می‌دهد که داده‌ها را بین Pods که روی نودهای مختلف در کلاستر Kubernetes قرار دارند، به اشتراک بگذارید. این فناوری‌ها با فراهم کردن دسترسی به داده‌ها از نودهای مختلف به صورت شبکه‌ای، به شما این امکان را می‌دهند که داده‌ها را به صورت توزیع‌شده و با دسترسی‌های متنوع مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 8. استفاده از CSI (Container Storage Interface)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”معرفی استاندارد CSI (Container Storage Interface)” subtitle=”توضيحات کامل”]CSI یا Container Storage Interface یک استاندارد باز است که هدف آن فراهم کردن یک رابط یکپارچه برای اتصال انواع مختلف سیستم‌های ذخیره‌سازی (مانند SAN، NAS، و ذخیره‌سازی ابری) به پلتفرم‌های مدیریت کانتینر است. این استاندارد به‌ویژه برای کلاسترهای Kubernetes طراحی شده است، اما می‌تواند در دیگر سیستم‌های مدیریت کانتینر نیز مورد استفاده قرار گیرد.

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

---

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

1. یکپارچگی و استانداردسازی: CSI یک رابط استاندارد برای اتصال انواع مختلف سیستم‌های ذخیره‌سازی فراهم می‌کند. این باعث می‌شود که توسعه‌دهندگان نیازی به نوشتن کدهای خاص برای هر سیستم ذخیره‌سازی و پلتفرم کانتینری نداشته باشند.
2. پشتیبانی از ویژگی‌های پیشرفته ذخیره‌سازی: با CSI، سیستم‌های ذخیره‌سازی می‌توانند ویژگی‌های پیشرفته‌ای مانند تنظیمات مقیاس‌پذیری، حجم‌های داینامیک، و کوپت‌ها (Snapshots) را ارائه دهند.
3. مقیاس‌پذیری و انعطاف‌پذیری: به لطف CSI، استفاده از سیستم‌های ذخیره‌سازی مختلف به راحتی مقیاس‌پذیر می‌شود و می‌توان حجم‌ها را بین نودهای مختلف کلاستر انتقال داد.
4. پشتیبانی از انواع مختلف Volume: از آنجا که CSI به طور مستقیم با سیستم‌های ذخیره‌سازی ارتباط برقرار می‌کند، می‌تواند از انواع مختلف Volume ها مانند Volume های بلاک (Block Volumes)، فایل (File Volumes) و یا حتی Object Storage پشتیبانی کند.

---

نحوه کارکرد CSI در Kubernetes

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

1. تعریف یک CSI Driver: یک CSI Driver برای هر سیستم ذخیره‌سازی پیاده‌سازی می‌شود که قادر به انجام عملیات‌های ذخیره‌سازی مانند ایجاد، حذف، گسترش حجم‌ها، و کوپت‌ها باشد.
2. تعریف PersistentVolume (PV) با CSI: در Kubernetes، Volume‌ها از طریق PVC (PersistentVolumeClaim) و PV (PersistentVolume) مدیریت می‌شوند. در حالت استاندارد CSI، شما می‌توانید PersistentVolumeهایی تعریف کنید که از یک CSI Driver برای اتصال به سیستم ذخیره‌سازی استفاده می‌کنند.
3. ایجاد و استفاده از PVC (PersistentVolumeClaim): هنگامی که یک PVC برای درخواست حجم ذخیره‌سازی ایجاد می‌شود، Kubernetes از CSI برای ارتباط با سیستم ذخیره‌سازی استفاده می‌کند و یک PV جدید مطابق با درخواست PVC ایجاد می‌کند.

---

اجزای اصلی CSI

1. CSI Driver: این اجزا برنامه‌هایی هستند که قابلیت اتصال سیستم ذخیره‌سازی به کانتینرها را فراهم می‌کنند. به‌طور کلی، هر نوع سیستم ذخیره‌سازی که قصد استفاده از CSI را دارد، به یک CSI Driver نیاز دارد.
2. CSI Plugin: این پلاگین‌ها مجموعه‌ای از دستورات هستند که توسط سیستم‌های ذخیره‌سازی برای انجام عملیات مختلف ذخیره‌سازی استفاده می‌شوند. آن‌ها می‌توانند برای مدیریت عملیات‌هایی مانند اتصال Volumeها، جدا کردن آن‌ها، و ارائه ویژگی‌هایی همچون Snapshots و Volume Expansion استفاده شوند.
3. CSI Controller Service: این سرویس عملیات‌هایی مانند درخواست‌های ذخیره‌سازی، ایجاد Volumeها، و نظارت بر وضعیت‌های مختلف Volume را مدیریت می‌کند.
4. CSI Node Service: این سرویس عملیات‌هایی مانند اتصال و جدا کردن Volumeها از کانتینرهای داخل نودهای مختلف کلاستر Kubernetes را انجام می‌دهد.

---

تعریف یک PersistentVolume با استفاده از CSI در Kubernetes

برای استفاده از یک CSI Driver در Kubernetes، شما باید یک PersistentVolume تعریف کنید که به طور خاص از یک CSI Driver استفاده کند. در زیر یک مثال از نحوه تعریف یک PersistentVolume با استفاده از CSI آورده شده است:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: csi-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  csi:
    driver: my-csi-driver.example.com
    volumeHandle: unique-volume-id
    fsType: ext4
  persistentVolumeReclaimPolicy: Retain

در این تنظیمات:

• driver نام درایور CSI که برای سیستم ذخیره‌سازی انتخاب شده است را مشخص می‌کند.
• volumeHandle یک شناسه منحصر به فرد برای Volume است.
• fsType نوع سیستم فایل (در اینجا ext4) را مشخص می‌کند.

---

جمع‌بندی

CSI یک استاندارد مهم و کلیدی است که امکان تعامل یکپارچه و بدون درز سیستم‌های ذخیره‌سازی مختلف با Kubernetes را فراهم می‌کند. این استاندارد باعث کاهش پیچیدگی در مدیریت ذخیره‌سازی در کلاسترهای Kubernetes می‌شود و ویژگی‌های پیشرفته‌ای مانند مقیاس‌پذیری و گسترش حجم‌ها را به صورت یکپارچه ارائه می‌دهد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه کار CSI و مزایای آن” subtitle=”توضيحات کامل”]CSI (Container Storage Interface) یک استاندارد باز است که برای اتصال سیستم‌های ذخیره‌سازی به پلتفرم‌های کانتینری مانند Kubernetes طراحی شده است. این استاندارد هدفش ارائه یک رابط یکپارچه برای تعامل با انواع مختلف سیستم‌های ذخیره‌سازی در محیط‌های کانتینری است.

نحوه کارکرد CSI در Kubernetes

1. CSI Driver:
   • هر سیستم ذخیره‌سازی که از CSI پشتیبانی می‌کند، باید یک CSI Driver داشته باشد. این درایور مسئول پیاده‌سازی عملیات‌های ذخیره‌سازی مانند ایجاد، حذف، اتصال و جدا کردن Volume‌ها است.
   • CSI Driver به Kubernetes کمک می‌کند تا با سیستم‌های ذخیره‌سازی مختلف بدون نیاز به پلاگین‌های خاص برای هر سیستم ذخیره‌سازی کار کند.
2. PersistentVolume (PV) و PersistentVolumeClaim (PVC):
   • در Kubernetes، PersistentVolume (PV) یک منبع ذخیره‌سازی است که معمولاً از طریق CSI به یک سیستم ذخیره‌سازی فیزیکی متصل می‌شود.
   • PersistentVolumeClaim (PVC) یک درخواست از طرف کاربران برای تخصیص فضای ذخیره‌سازی است. Kubernetes از این درخواست‌ها برای تخصیص PVها استفاده می‌کند.
   • زمانی که یک PVC ایجاد می‌شود، اگر سیستم ذخیره‌سازی از CSI پشتیبانی کند، Kubernetes از CSI Driver برای ارتباط با سیستم ذخیره‌سازی و تخصیص PV استفاده می‌کند.
3. CSI Controller و CSI Node Services:
   • CSI Controller Service: این سرویس مسئول مدیریت عملیات‌هایی مانند ایجاد و حذف Volumeها، نظارت بر وضعیت‌ها و ایجاد Snapshots است.
   • CSI Node Service: این سرویس مسئول مدیریت اتصال و جدا کردن Volumeها از نودهای مختلف در کلاستر Kubernetes است.
   • این دو سرویس با هم همکاری می‌کنند تا اطمینان حاصل شود که حجم‌های ذخیره‌سازی به درستی به کانتینرها متصل و از آن‌ها جدا می‌شوند.
4. Volume Creation & Mounting:
   • هنگامی که یک PersistentVolumeClaim درخواست می‌شود، Kubernetes از CSI برای ایجاد و اتصال PersistentVolume استفاده می‌کند.
   • پس از اتصال PersistentVolume، Kubernetes آن را به کانتینرهای داخل Pod مربوطه متصل می‌کند تا داده‌ها ذخیره شوند.

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

1. یکپارچگی و استانداردسازی:
   • CSI یک رابط استاندارد باز است که برای تمامی سیستم‌های ذخیره‌سازی مناسب است. این یعنی سیستم‌های ذخیره‌سازی مختلف نیازی به طراحی رابط‌های خاص برای هر پلتفرم ندارند و به راحتی می‌توانند به Kubernetes متصل شوند.
   • به این ترتیب، توسعه‌دهندگان دیگر نیازی به نوشتن پلاگین‌های خاص برای اتصال سیستم ذخیره‌سازی با Kubernetes نخواهند داشت.
2. مقیاس‌پذیری و انعطاف‌پذیری:
   • استفاده از CSI باعث می‌شود که Kubernetes به راحتی بتواند سیستم‌های ذخیره‌سازی را مقیاس‌بندی کرده و به طور مؤثری از آن‌ها استفاده کند.
   • به طور مثال، سیستم‌های ذخیره‌سازی ابری (AWS, Azure, GCP) به راحتی می‌توانند به Kubernetes متصل شده و از منابع ذخیره‌سازی آن‌ها استفاده شود.
3. پشتیبانی از ویژگی‌های پیشرفته ذخیره‌سازی:
   • به کمک CSI، سیستم‌های ذخیره‌سازی می‌توانند ویژگی‌هایی مانند Snapshots, Volume Expansion و Backup را برای کانتینرها فراهم کنند.
   • این ویژگی‌ها می‌توانند در Kubernetes برای ایجاد نسخه‌های پشتیبان و مدیریت حجم‌های ذخیره‌سازی استفاده شوند.
4. دستگاه‌های ذخیره‌سازی متنوع:
   • CSI به Kubernetes این امکان را می‌دهد که از سیستم‌های ذخیره‌سازی مختلف مانند ذخیره‌سازی بلاک (Block Storage)، فایل سیستم (File System) و یا ذخیره‌سازی ابری (Cloud Storage) استفاده کند.
   • سیستم‌های مختلف ذخیره‌سازی از جمله NFS، Ceph، GlusterFS، iSCSI و دیگر تکنولوژی‌های ذخیره‌سازی به راحتی قابل ادغام هستند.
5. مدیریت اتوماتیک ذخیره‌سازی:
   • با استفاده از CSI, کاربران می‌توانند به طور خودکار فضای ذخیره‌سازی را مدیریت کنند. عملیات‌هایی مانند گسترش حجم‌ها، حذف و پشتیبان‌گیری از داده‌ها به راحتی از طریق سرویس‌های مختلف سیستم ذخیره‌سازی انجام می‌شود.
6. کاهش پیچیدگی در پیکربندی:
   • CSI این امکان را می‌دهد که پیکربندی‌ها به صورت مرکزی و در قالب یک استاندارد انجام شود، بنابراین کاربران نیازی به یادگیری نحوه پیکربندی هر نوع سیستم ذخیره‌سازی ندارند.

مثال پیاده‌سازی CSI در Kubernetes

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

apiVersion: v1
kind: PersistentVolume
metadata:
  name: csi-pv
spec:
  capacity:
    storage: 20Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  csi:
    driver: my-csi-driver.example.com
    volumeHandle: volume-id-12345
    fsType: ext4
  persistentVolumeReclaimPolicy: Retain

در این مثال:

• driver نام CSI Driver است که سیستم ذخیره‌سازی را معرفی می‌کند.
• volumeHandle شناسه منحصر به فرد برای Volume است.
• fsType نوع سیستم فایل را مشخص می‌کند.

جمع‌بندی

CSI یک استاندارد حیاتی در Kubernetes است که به پلتفرم‌های ذخیره‌سازی اجازه می‌دهد به طور یکپارچه و با یک رابط استاندارد به کانتینرها و Pods متصل شوند. این استاندارد باعث مقیاس‌پذیری، انعطاف‌پذیری و مدیریت مؤثرتر ذخیره‌سازی در کلاسترهای Kubernetes می‌شود و ویژگی‌های پیشرفته‌ای مانند پشتیبان‌گیری، گسترش حجم‌ها و تنظیمات پیچیده را به کاربران می‌دهد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”پیکربندی CSI در محیط‌های Kubernetes” subtitle=”توضيحات کامل”]پیکربندی Container Storage Interface (CSI) در Kubernetes به منظور استفاده از سیستم‌های ذخیره‌سازی مختلف و یکپارچه‌سازی آن‌ها با Pods انجام می‌شود. این پیکربندی به شما این امکان را می‌دهد که بتوانید به راحتی انواع سیستم‌های ذخیره‌سازی را به Kubernetes متصل کنید و از آن‌ها برای ذخیره‌سازی داده‌ها استفاده کنید. در این بخش، مراحل پیکربندی یک CSI Driver در Kubernetes و اتصال آن به PersistentVolume (PV) و PersistentVolumeClaim (PVC) به طور گام به گام توضیح داده می‌شود.

مراحل پیکربندی CSI در Kubernetes

1. نصب و پیکربندی CSI Driver

   قبل از اینکه بتوانید از CSI در Kubernetes استفاده کنید، باید CSI Driver مربوطه را نصب و پیکربندی کنید. CSI Driver می‌تواند برای سیستم‌های ذخیره‌سازی مختلف مانند NFS، Ceph، AWS EBS، GCP Persistent Disk و غیره وجود داشته باشد.

   برای نصب و پیکربندی CSI Driver، معمولا از دستورالعمل‌های موجود در مستندات رسمی Driver استفاده می‌شود. به عنوان مثال برای نصب Ceph CSI Driver در Kubernetes از دستورات زیر می‌توان استفاده کرد:

   kubectl apply -k github.com/ceph/ceph-csi/deploy/kubernetes/cephcsi-operator/
   

   یا برای نصب NFS CSI Driver:

   kubectl apply -k github.com/kubernetes-sigs/nfs-ganesha-csi/deploy/kubernetes/
   

2. تعریف PersistentVolume با استفاده از CSI Driver

   بعد از نصب و پیکربندی CSI Driver، شما باید یک PersistentVolume (PV) ایجاد کنید که از CSI برای اتصال به سیستم ذخیره‌سازی استفاده کند. در فایل YAML این تنظیمات به صورت زیر خواهد بود:

   apiVersion: v1
   kind: PersistentVolume
   metadata:
     name: my-csi-pv
   spec:
     capacity:
       storage: 50Gi
     accessModes:
       - ReadWriteOnce
     csi:
       driver: my-csi-driver.example.com
       volumeHandle: volume-id-12345
       fsType: ext4
     persistentVolumeReclaimPolicy: Retain
   

   • driver: نام درایور CSI است که به Kubernetes نشان می‌دهد کدام سیستم ذخیره‌سازی باید استفاده شود.
   • volumeHandle: شناسه منحصربه‌فرد Volume در سیستم ذخیره‌سازی.
   • fsType: نوع سیستم فایل (در این مثال ext4).
   • persistentVolumeReclaimPolicy: تعیین می‌کند که پس از حذف PersistentVolume، چه اقدامی انجام شود. گزینه‌ها شامل Retain، Delete یا Recycle هستند.
3. تعریف PersistentVolumeClaim (PVC)

   بعد از تعریف PV، شما باید یک PersistentVolumeClaim (PVC) ایجاد کنید تا یک درخواست برای استفاده از فضای ذخیره‌سازی فراهم کند. این درخواست به Kubernetes می‌گوید که فضای ذخیره‌سازی مورد نیاز با حجم و ویژگی‌های مشخص به چه صورت باشد.

   در فایل YAML برای PVC، شما باید به پیکربندی فضای ذخیره‌سازی که قبلاً با PV تعریف کرده‌اید، اشاره کنید. به عنوان مثال:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: my-pvc
   spec:
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         storage: 50Gi
     storageClassName: csi-storage-class
   

   • accessModes: نحوه دسترسی به فضای ذخیره‌سازی (به عنوان مثال ReadWriteOnce برای دسترسی به یک Node به طور همزمان).
   • resources.requests.storage: مقدار فضای ذخیره‌سازی درخواست‌شده.
   • storageClassName: نام کلاس ذخیره‌سازی که برای مدیریت ذخیره‌سازی پویا استفاده می‌شود (در صورت استفاده).
4. اتصال PVC به Podها

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

   apiVersion: v1
   kind: Pod
   metadata:
     name: my-pod
   spec:
     containers:
     - name: my-container
       image: my-image
       volumeMounts:
       - mountPath: /mnt/data
         name: my-storage
     volumes:
     - name: my-storage
       persistentVolumeClaim:
         claimName: my-pvc
   

   • volumeMounts: محلی است که فضای ذخیره‌سازی در داخل Pod در دسترس خواهد بود. در این مثال، فضای ذخیره‌سازی در /mnt/data موجود خواهد بود.
   • volumes.persistentVolumeClaim.claimName: به PVC که قبلاً ایجاد کرده‌اید، اشاره می‌کند تا فضای ذخیره‌سازی مرتبط با آن به Pod متصل شود.
5. بررسی و دیباگ پیکربندی CSI

   بعد از راه‌اندازی PV و PVC و اتصال آن‌ها به Pod، باید اطمینان حاصل کنید که همه چیز به درستی کار می‌کند. برای این منظور، از دستوراتی مانند kubectl get pvc, kubectl describe pv, kubectl describe pvc, و kubectl describe pod برای بررسی وضعیت استفاده کنید.

   برای مشاهده وضعیت PVC:

   kubectl get pvc my-pvc
   

   برای مشاهده وضعیت PV:

   kubectl get pv my-csi-pv
   

   برای بررسی وضعیت Pod:

   kubectl describe pod my-pod
   

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

6. حذف و مدیریت Volume

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

   kubectl delete pvc my-pvc
   

   با حذف PVC، Kubernetes به طور خودکار Volume مربوطه را آزاد می‌کند. اگر از گزینه ReclaimPolicy در PV استفاده کرده باشید، بر اساس تنظیمات آن، Volume به حالت Retain باقی خواهد ماند یا حذف خواهد شد.

---

جمع‌بندی

پیکربندی CSI در Kubernetes اجازه می‌دهد تا فضای ذخیره‌سازی خارجی به راحتی به کلاستر Kubernetes متصل شده و از آن در Podها و برنامه‌ها استفاده شود. این پیکربندی شامل نصب CSI Driver، تعریف PersistentVolume (PV)، ایجاد PersistentVolumeClaim (PVC) و اتصال آن‌ها به Pods برای مدیریت ذخیره‌سازی داده‌ها است. با استفاده از استاندارد CSI، Kubernetes قادر به استفاده از انواع مختلف سیستم‌های ذخیره‌سازی مانند NFS، Ceph، AWS EBS و دیگر منابع ذخیره‌سازی می‌شود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 9. نکات پیشرفته در مدیریت ذخیره‌سازی”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”اعمال Resource Requests و Limits برای ذخیره‌سازی ” subtitle=”توضيحات کامل”]در کوبرنتیز، Resource Requests و Resource Limits برای تخصیص منابع (مانند CPU و حافظه) به Podها و کانتینرها استفاده می‌شود. این منابع به Kubernetes کمک می‌کند تا برنامه‌ها و منابع زیرساختی را بهینه‌سازی کرده و از تعارض‌های احتمالی جلوگیری کند. با این حال، برای ذخیره‌سازی، اگرچه نمی‌توانیم از Resource Requests و Limits به صورت مستقیم برای حجم‌های ذخیره‌سازی استفاده کنیم، اما می‌توانیم مشابه با منابع دیگر (مثل CPU و حافظه) از Requests و Limits در سیستم ذخیره‌سازی استفاده کنیم تا مدیریت بهتری از منابع ذخیره‌سازی داشته باشیم.

در اینجا روش‌های استفاده از Resource Requests و Limits برای تخصیص فضای ذخیره‌سازی در Kubernetes آورده شده است.

1. درخواست منابع ذخیره‌سازی (Requests)

زمانی که می‌خواهیم فضای ذخیره‌سازی را برای یک Pod یا کانتینر درخواست کنیم، باید مقدار فضای ذخیره‌سازی که به طور پیش‌فرض برای Pod در نظر گرفته می‌شود را تعیین کنیم. این کار با استفاده از PersistentVolumeClaim (PVC) صورت می‌گیرد. Kubernetes از این درخواست به‌عنوان مقدار Request استفاده می‌کند.

در YAML برای PVC، از قسمت resources.requests.storage برای درخواست فضای ذخیره‌سازی استفاده می‌شود:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi  # درخواست فضای ذخیره‌سازی
  storageClassName: standard

در این مثال:

• resources.requests.storage: ۱۰ گیگابایت فضای ذخیره‌سازی را به عنوان درخواست مشخص کرده‌ایم.

Kubernetes با توجه به Request مشخص‌شده برای PVC، یک PersistentVolume (PV) متناسب با آن حجم پیدا کرده و به PVC اختصاص می‌دهد.

2. تعیین محدودیت‌های ذخیره‌سازی (Limits)

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

با این حال، می‌توانید از سیاست‌های مختلف ذخیره‌سازی و اعمال محدودیت‌ها از طریق سیستم‌های ذخیره‌سازی خود استفاده کنید. به عنوان مثال، بسیاری از ارائه‌دهندگان فضای ذخیره‌سازی ابری مانند AWS EBS یا GCP Persistent Disks قابلیت محدودسازی استفاده از حجم‌های ذخیره‌سازی را دارند.

3. اعمال محدودیت برای Pod‌ها و کانتینر‌ها

در Kubernetes، می‌توانید برای منابع دیگر مانند CPU و Memory، Resource Requests و Limits را به صورت زیر تعریف کنید. این تنظیمات اجازه می‌دهند که کانتینرها یا Podها مقدار مشخصی از منابع را درخواست کنند یا محدود کنند.

در فایل YAML برای Pod می‌توانید درخواست و محدودیت منابع برای CPU و Memory را به این صورت مشخص کنید:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

در اینجا:

• requests: مقدار حداقل منابعی است که کانتینر برای اجرا به آن نیاز دارد.
• limits: مقدار حداکثر منابعی است که کانتینر می‌تواند استفاده کند.

4. ذخیره‌سازی با استفاده از StorageClass

اگر از Dynamic Provisioning برای ذخیره‌سازی استفاده می‌کنید (که معمولا برای ایجاد Volumeهای پویا استفاده می‌شود)، می‌توانید StorageClass را برای تنظیمات پیشرفته‌تر و خودکار برای تخصیص فضای ذخیره‌سازی مشخص کنید.

مثال YAML برای تعریف StorageClass:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast-storage
provisioner: kubernetes.io/aws-ebs
parameters:
  type: gp2
  fsType: ext4

در اینجا:

• provisioner: تعیین‌کننده سیستم ذخیره‌سازی است (در این مثال، از EBS برای AWS استفاده شده است).
• parameters: پارامترهای اضافی برای پیکربندی ذخیره‌سازی، مانند نوع Volume و سیستم فایل.

5. دیباگ و نظارت بر منابع ذخیره‌سازی

برای نظارت بر درخواست‌های منابع ذخیره‌سازی، می‌توانید از دستورات زیر استفاده کنید تا وضعیت PVC و PV را بررسی کنید:

• بررسی وضعیت PVC:

kubectl get pvc my-pvc

• بررسی جزئیات PV:

kubectl describe pv my-pv

• بررسی جزئیات PVC:

kubectl describe pvc my-pvc

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

---

جمع‌بندی

در Kubernetes، به طور مستقیم نمی‌توانیم Limits را برای ذخیره‌سازی تعریف کنیم، اما می‌توانیم از Requests برای درخواست فضای ذخیره‌سازی در PVC استفاده کنیم. برای مدیریت موثر منابع ذخیره‌سازی و بهینه‌سازی آن، همچنین می‌توانیم از StorageClass و تنظیمات مربوط به سیستم‌های ذخیره‌سازی استفاده کنیم. در نهایت، برای نظارت بر فضای ذخیره‌سازی و دیباگ مشکلات مرتبط با آن، دستورات kubectl می‌توانند کمک‌کننده باشند.

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”Debugging و عیب‌یابی مشکلات ذخیره‌سازی ” subtitle=”توضيحات کامل”]در Kubernetes، مشکلات مربوط به ذخیره‌سازی می‌تواند بر عملکرد برنامه‌ها و پایداری کلی سیستم تأثیر بگذارد. عیب‌یابی مشکلات ذخیره‌سازی در Kubernetes به شناخت ابزارها، منابع و دستورات مختلف نیاز دارد تا بتوان مشکلات را شناسایی و حل کرد. در این بخش به بررسی روش‌ها و ابزارهای مختلف برای عیب‌یابی مشکلات ذخیره‌سازی خواهیم پرداخت.

۱. بررسی وضعیت PersistentVolume (PV) و PersistentVolumeClaim (PVC)

یکی از اولین کارهایی که برای عیب‌یابی مشکلات ذخیره‌سازی باید انجام دهید، بررسی وضعیت PersistentVolume (PV) و PersistentVolumeClaim (PVC) است. این منابع مسئول تخصیص فضای ذخیره‌سازی به Pod‌ها هستند.

• بررسی وضعیت PVC: برای بررسی وضعیت یک PVC از دستور زیر استفاده کنید:

  kubectl get pvc <pvc-name> -n <namespace>
  

  این دستور اطلاعاتی در مورد وضعیت PVC، مانند فضای درخواست‌شده و فضای تخصیص‌یافته، ارائه می‌دهد.

• بررسی وضعیت PV: برای بررسی وضعیت PV، می‌توانید از دستور زیر استفاده کنید:

  kubectl get pv <pv-name>
  

  این دستور وضعیت PersistentVolume را نشان می‌دهد، از جمله اینکه آیا این حجم در حال استفاده است یا نه، و همچنین شرایط آن مانند Bound یا Available.

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

  kubectl describe pvc <pvc-name> -n <namespace>
  

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

۲. بررسی مشکلات با Volume‌های شبکه‌ای (NFS، Ceph)

اگر از Volume‌های شبکه‌ای مانند NFS یا Ceph استفاده می‌کنید، ممکن است مشکلات مربوط به اتصال شبکه یا پیکربندی سرویس‌های ذخیره‌سازی ابری و محلی وجود داشته باشد.

برای NFS:

• بررسی اتصال به NFS server و بررسی وضعیت سرویس NFS در node:

  mount -t nfs <nfs-server-ip>:<nfs-directory> /mnt/test
  

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

برای Ceph:

• بررسی اتصال به Ceph Cluster:

  می‌توانید از ابزارهایی مانند radosgw-admin برای بررسی وضعیت اتصال به Ceph استفاده کنید.

  radosgw-admin status
  

۳. بررسی وضعیت Volume Mounts در Pods

گاهی اوقات مشکل می‌تواند ناشی از پیکربندی اشتباه Volume Mounts در Pods باشد. برای بررسی این موضوع، ابتدا وضعیت Pod و Volume Mounts آن را بررسی کنید.

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

kubectl describe pod <pod-name> -n <namespace>

در خروجی این دستور، به قسمت Volumes و Mounts توجه کنید تا مطمئن شوید که Volume‌ها به درستی به Pod متصل شده‌اند و مسیرهای Mount شده نیز درست هستند.

۴. بررسی لاگ‌های مربوط به سیستم ذخیره‌سازی

در صورتی که سیستم ذخیره‌سازی شما دچار مشکل شده باشد، بررسی لاگ‌های سیستم می‌تواند کمک‌کننده باشد.

برای مشاهده لاگ‌های مربوط به Kubelet که وظیفه مدیریت Volumes را دارد، از دستور زیر استفاده کنید:

kubectl logs <kubelet-pod-name> -n kube-system

این دستور به شما اجازه می‌دهد تا لاگ‌های مربوط به Kubernetes Kubelet را که در مدیریت Volumes و اتصال آنها به Pods نقش دارد، مشاهده کنید.

برای مشاهده لاگ‌های مربوط به Ceph یا NFS سرور (در صورت استفاده از این سیستم‌ها)، باید به سرور‌های ذخیره‌سازی خود دسترسی داشته باشید و فایل‌های لاگ آنها را بررسی کنید.

۵. بررسی وضعیت StorageClass و Provisioning

در صورتی که از Dynamic Provisioning و StorageClass استفاده می‌کنید، لازم است مطمئن شوید که StorageClass به درستی پیکربندی شده است. به عنوان مثال، برای بررسی وضعیت StorageClass و ویژگی‌های آن، دستور زیر را اجرا کنید:

kubectl get storageclass

اگر StorageClass به درستی پیکربندی نشده باشد، ممکن است مشکلاتی در زمان Dynamic Provisioning ایجاد شود. در صورت لزوم می‌توانید از دستور describe برای مشاهده جزئیات بیشتر استفاده کنید:

kubectl describe storageclass <storageclass-name>

۶. بررسی مشکلات در زمان حذف و بازنویسی Volume‌ها

گاهی اوقات وقتی که شما PVC را حذف می‌کنید، PV به‌درستی پاک نمی‌شود و مشکلاتی در ایجاد یا حذف Volume‌ها پیش می‌آید. برای رفع این مشکل، گزینه‌های مختلفی مانند ReclaimPolicy برای PV وجود دارد که تعیین می‌کند که پس از حذف PVC چه اتفاقی برای PV خواهد افتاد.

برای بررسی وضعیت ReclaimPolicy، دستور زیر را اجرا کنید:

kubectl describe pv <pv-name>

مقادیر ممکن برای ReclaimPolicy عبارتند از:

• Retain: PV پس از حذف PVC حفظ می‌شود.
• Delete: PV پس از حذف PVC حذف می‌شود.
• Recycle: PV پس از حذف PVC به حالت پیش‌فرض باز می‌گردد (این گزینه کمتر استفاده می‌شود).

۷. بررسی وضعیت Pod و دسترسی به Volume‌ها

در صورتی که Pod قادر به دسترسی به Volume نیست، ممکن است تنظیمات امنیتی یا سیاست‌های دسترسی اشتباه باشد. برای بررسی این موضوع، از دستورات زیر استفاده کنید:

• مشاهده وضعیت Pod:

kubectl get pod <pod-name> -n <namespace>

• بررسی مشکل در دسترسی به Volume در Pod:

kubectl describe pod <pod-name> -n <namespace>

توجه داشته باشید که اگر Pod به PersistentVolume یا Volume‌های دیگر دسترسی نداشته باشد، ممکن است مشکل در نحوه پیکربندی VolumeMounts یا اشتباه در مسیرهای تعریف‌شده برای Mount باشد.

۸. بررسی محدودیت‌ها و ظرفیت Volume‌ها

اگر مشکلاتی مانند عدم تخصیص فضای کافی برای PVC و PV دارید، باید ظرفیت Volume‌ها را بررسی کنید. بررسی ظرفیت‌های درخواست‌شده و تخصیص‌یافته بسیار مهم است. از دستور زیر برای بررسی وضعیت فضای تخصیص‌یافته استفاده کنید:

kubectl get pvc <pvc-name> -n <namespace>

جمع‌بندی

عیب‌یابی مشکلات ذخیره‌سازی در Kubernetes نیازمند بررسی دقیق منابع مختلف مانند PersistentVolume، PersistentVolumeClaim، Volume Mounts، StorageClass و NFS/Ceph است. ابزارهای مختلف kubectl برای مشاهده وضعیت این منابع و بررسی لاگ‌ها می‌توانند در شناسایی و رفع مشکلات کمک کنند. همچنین، استفاده از سیاست‌های مختلف ذخیره‌سازی، مانند ReclaimPolicy، و بررسی تنظیمات مربوط به Dynamic Provisioning و Resource Requests در Kubernetes از جمله مراحل کلیدی در عیب‌یابی مشکلات ذخیره‌سازی به شمار می‌روند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از ابزارهای مانیتورینگ برای حجم‌ها (مانند Prometheus)” subtitle=”توضيحات کامل”]برای نظارت و مانیتورینگ حجم‌های ذخیره‌سازی در Kubernetes، می‌توان از ابزارهایی مانند Prometheus و Grafana استفاده کرد. این ابزارها به شما کمک می‌کنند تا وضعیت و عملکرد PersistentVolumes، PersistentVolumeClaims و دیگر منابع ذخیره‌سازی را مانیتور کرده و مشکلات احتمالی را شناسایی کنید. در این بخش، نحوه استفاده از Prometheus برای مانیتورینگ حجم‌ها و تنظیمات مورد نیاز برای این کار توضیح داده خواهد شد.

۱. معرفی Prometheus و Grafana برای مانیتورینگ

Prometheus یک ابزار متن‌باز برای جمع‌آوری و ذخیره‌سازی متریک‌ها است که به طور گسترده‌ای برای نظارت بر زیرساخت‌ها و برنامه‌های Kubernetes استفاده می‌شود. Grafana نیز ابزاری است که به شما این امکان را می‌دهد تا این متریک‌ها را به صورت گرافیکی نمایش دهید.

Prometheus از Exporter‌ها برای جمع‌آوری اطلاعات از منابع مختلف مانند حجم‌های ذخیره‌سازی استفاده می‌کند. Kube-state-metrics یکی از این Exporter‌ها است که اطلاعات مربوط به وضعیت منابع مختلف Kubernetes از جمله PV و PVC را جمع‌آوری می‌کند.

۲. نصب Prometheus و Grafana در Kubernetes

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

نصب Prometheus با استفاده از Helm:

1. ابتدا باید Helm را نصب کنید (در صورتی که از قبل نصب نیست):

   curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
   

2. سپس، مخزن Prometheus را اضافه کنید:

   helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
   helm repo update
   

3. نصب Prometheus به همراه kube-state-metrics:

   helm install prometheus prometheus-community/kube-prometheus-stack
   

نصب Grafana:

1. نصب Grafana با Helm:

   helm install grafana prometheus-community/grafana
   

2. بعد از نصب، دسترسی به داشبورد Grafana به‌طور پیش‌فرض از طریق Port Forwarding فراهم می‌شود:

   kubectl port-forward service/grafana 3000:80
   

   سپس می‌توانید وارد داشبورد Grafana شوید و به آدرس http://localhost:3000 بروید.

۳. تنظیم Prometheus برای مانیتورینگ حجم‌ها

برای مانیتورینگ حجم‌ها و منابع ذخیره‌سازی در Kubernetes با استفاده از Prometheus، باید kube-state-metrics را تنظیم کنید. این ابزار به Prometheus کمک می‌کند تا متریک‌های مرتبط با وضعیت منابع Kubernetes مانند PersistentVolume، PersistentVolumeClaim و StorageClass را جمع‌آوری کند.

نصب و پیکربندی kube-state-metrics:

1. نصب kube-state-metrics با استفاده از Helm:

   helm install kube-state-metrics prometheus-community/kube-state-metrics
   

2. بعد از نصب kube-state-metrics، Prometheus به طور خودکار شروع به جمع‌آوری متریک‌ها از این ابزار می‌کند. اطلاعاتی که از kube-state-metrics به Prometheus ارسال می‌شود شامل وضعیت PV و PVC، میزان فضای استفاده‌شده، میزان فضای آزاد و دیگر جزئیات مرتبط با ذخیره‌سازی است.

۴. نمایش اطلاعات در Grafana

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

برای مشاهده متریک‌های مربوط به حجم‌ها، ابتدا به داشبورد Prometheus در Grafana وارد شوید. در اینجا می‌توانید از کوئری‌های Prometheus برای نمایش اطلاعات مربوط به PersistentVolume و PersistentVolumeClaim استفاده کنید.

مثال از کوئری‌های Prometheus برای مانیتورینگ فضای ذخیره‌سازی:

1. مشاهده ظرفیت و فضای استفاده‌شده برای PersistentVolumes:

   kube_persistentvolume_capacity_bytes
   

2. مشاهده فضای استفاده‌شده توسط PVC:

   kube_persistentvolumeclaim_resource_requests_storage_bytes
   

3. مشاهده وضعیت اتصال و استفاده از PVC:

   kube_persistentvolumeclaim_info
   

در Grafana، می‌توانید این کوئری‌ها را وارد کرده و نمودارهایی برای نمایش وضعیت ذخیره‌سازی در زمان واقعی ایجاد کنید.

۵. استفاده از Prometheus Alerts برای مدیریت حجم‌ها

یکی دیگر از ویژگی‌های Prometheus، قابلیت ایجاد Alert است. شما می‌توانید قوانینی برای ارسال هشدار در صورت استفاده بیش از حد از حجم‌ها یا مشکلات دیگر مانند ظرفیت کم فضای ذخیره‌سازی ایجاد کنید.

نمونه‌ای از تنظیم هشدار برای فضای ذخیره‌سازی:

groups:
  - name: storage-alerts
    rules:
      - alert: PVCUsageHigh
        expr: kube_persistentvolumeclaim_resource_requests_storage_bytes > 0.8 * kube_persistentvolumeclaim_capacity_bytes
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "PVC usage is above 80% capacity"

در این هشدار، زمانی که میزان استفاده از PVC از ۸۰% ظرفیت آن بیشتر شود، یک هشدار critical ارسال خواهد شد.

۶. بررسی و عیب‌یابی مشکلات ذخیره‌سازی با Prometheus

ابزار Prometheus همچنین به شما این امکان را می‌دهد که مشکلات ذخیره‌سازی را شناسایی و عیب‌یابی کنید. به‌عنوان مثال، اگر یک PVC با مشکل مواجه شود یا یک PersistentVolume به درستی کار نکند، می‌توانید با استفاده از کوئری‌های Prometheus وضعیت این منابع را مشاهده کنید.

برای مثال:

• بررسی PersistentVolumeClaim که به درستی متصل نشده است:

  kube_persistentvolumeclaim_status_phase{phase="Pending"}
  

این کوئری به شما نشان می‌دهد که چه PVCهایی در وضعیت Pending هستند و این امکان را به شما می‌دهد که مشکل را شناسایی کنید.

جمع‌بندی

استفاده از Prometheus و Grafana برای مانیتورینگ حجم‌ها در Kubernetes یک راهکار قدرتمند برای نظارت بر فضای ذخیره‌سازی و شناسایی مشکلات ذخیره‌سازی است. با استفاده از ابزارهایی مانند kube-state-metrics و Prometheus Alerts، می‌توانید وضعیت PersistentVolumes و PersistentVolumeClaims را مانیتور کرده و در صورت بروز مشکل، اقدامات اصلاحی انجام دهید. این ابزارها به شما این امکان را می‌دهند که از ذخیره‌سازی ایمن و پایدار در Kubernetes اطمینان حاصل کنید.[/cdb_course_lesson][/cdb_course_lessons]