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

[cdb_course_lessons title=”بخش 5. مبانی امنیت در Kubernetes”][cdb_course_lesson title=”فصل 1. مدیریت Service Accounts و RBAC (Role-Based Access Control)”][/cdb_course_lesson][cdb_course_lesson title=”Service Accounts:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف Service Account” subtitle=”توضیحات کامل”]در کوبرنتیز، Service Account یک نوع هویت است که به Pods یا سرویس‌ها اجازه می‌دهد با API سرور Kubernetes ارتباط برقرار کنند. این هویت معمولاً به‌صورت خودکار در زمان ایجاد Pod به آن اختصاص داده می‌شود و به پادها اجازه می‌دهد تا با استفاده از این هویت، عملیات‌هایی مانند دسترسی به منابع Kubernetes را انجام دهند.

هر Service Account به همراه یک یا چند Token و Secret ایجاد می‌شود که برای احراز هویت درخواست‌ها به API سرور Kubernetes استفاده می‌شود. این Service Account‌ها می‌توانند به‌طور خاص برای دسترسی به منابع مختلف، مانند ConfigMaps، Secrets، یا حتی اجزای Kubernetes نظیر Pods یا Services محدود شوند.

چرا از Service Account برای Pods استفاده می‌شود؟

• به هر Pod اجازه می‌دهد تا با استفاده از یک هویت خاص به Kubernetes API دسترسی داشته باشد.
• می‌توان دسترسی به منابع مختلف را با استفاده از Role و RoleBinding کنترل کرد.
• برای احراز هویت و دسترسی به منابع داخلی Kubernetes، نیازی به ایجاد و مدیریت credentials دستی نیست.

در نهایت، Service Account‌ها به Kubernetes کمک می‌کنند که دسترسی‌ها به‌صورت ایمن و مدیریت‌شده برای هر پاد تعریف شوند.

استفاده پیش‌فرض از Service Account در Kubernetes

پادها به‌طور پیش‌فرض از Service Account به نام default در namespace خود استفاده می‌کنند. این Service Account دسترسی‌های محدودی به منابع Kubernetes دارد و معمولاً برای بیشتر کاربردهای عمومی مناسب است. اما در موارد خاص که نیاز به دسترسی‌های خاص‌تر یا جداگانه باشد، باید یک Service Account جدید ایجاد و برای پاد تنظیم شود.

ایجاد Service Account جدید

برای ایجاد یک Service Account جدید به نام my-service-account در namespace جاری، از دستور زیر استفاده می‌کنیم:

kubectl create serviceaccount my-service-account

برای مشاهده لیست Service Account‌ها در namespace جاری:

kubectl get serviceaccounts

پیکربندی Pod‌ها برای استفاده از Service Account خاص

پس از ایجاد یک Service Account جدید، باید فایل YAML پاد را طوری پیکربندی کنیم که از آن Service Account خاص استفاده کند. این کار با اضافه کردن بخش serviceAccountName به فایل YAML پاد انجام می‌شود.

نمونه فایل YAML پاد که از Service Account خاص استفاده می‌کند:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  serviceAccountName: my-service-account
  containers:
  - name: mycontainer
    image: nginx

در اینجا:

• serviceAccountName: my-service-account مشخص می‌کند که پاد mypod باید از Service Account به نام my-service-account استفاده کند.

برای اعمال این پیکربندی و ایجاد پاد:

kubectl apply -f pod-definition.yaml

مشاهده Service Account‌ها

برای مشاهده لیست Service Account‌ها در namespace جاری:

kubectl get serviceaccounts

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

kubectl describe serviceaccount my-service-account

این دستور اطلاعاتی مانند Secrets و Tokens مرتبط با Service Account را نمایش می‌دهد.

جمع بندی

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

در این بخش، به صورت دقیق به چگونگی ایجاد و مدیریت Service Account‌ها پرداخته می‌شود.

ایجاد یک Service Account جدید

برای ایجاد یک Service Account جدید در Kubernetes، می‌توانید از دستور kubectl create serviceaccount استفاده کنید.

1. ایجاد Service Account جدید

برای ایجاد یک Service Account جدید به نام my-service-account در namespace جاری، از دستور زیر استفاده کنید:

kubectl create serviceaccount my-service-account

این دستور یک Service Account جدید با نام my-service-account در namespace جاری ایجاد می‌کند.

2. ایجاد Service Account در یک Namespace خاص

اگر بخواهید Service Account را در یک namespace خاص ایجاد کنید، می‌توانید از دستور زیر استفاده کنید:

kubectl create serviceaccount my-service-account -n my-namespace

در اینجا -n my-namespace مشخص می‌کند که Service Account جدید در namespace my-namespace ایجاد شود.

3. مشاهده Service Account‌ها

برای مشاهده لیست تمامی Service Account‌ها در namespace جاری:

kubectl get serviceaccounts

اگر بخواهید Service Account‌ها را در یک namespace خاص مشاهده کنید، از دستور زیر استفاده کنید:

kubectl get serviceaccounts -n my-namespace

4. مشاهده جزئیات Service Account

برای مشاهده اطلاعات دقیق‌تر در مورد یک Service Account خاص، از دستور describe استفاده کنید:

kubectl describe serviceaccount my-service-account

این دستور اطلاعاتی مانند Tokens و Secrets مربوط به Service Account را نمایش می‌دهد.

ایجاد Service Account از طریق فایل YAML

شما می‌توانید Service Account را از طریق یک فایل YAML نیز تعریف کنید. این روش برای ایجاد و مدیریت Service Account‌ها در پروژه‌های بزرگ یا برای استفاده در pipeline‌های CI/CD مناسب است.

نمونه فایل YAML برای ایجاد یک Service Account به نام my-service-account در namespace my-namespace:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: my-service-account
  namespace: my-namespace

برای ایجاد این Service Account از فایل YAML:

kubectl apply -f serviceaccount.yaml

تغییرات در Service Account‌ها

پس از ایجاد Service Account، ممکن است بخواهید تنظیمات یا جزئیات آن را تغییر دهید. به طور مستقیم نمی‌توان Service Account‌ها را ویرایش کرد، اما می‌توانید آن‌ها را حذف کرده و با تنظیمات جدید ایجاد کنید.

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

kubectl delete serviceaccount my-service-account

اگر بخواهید یک Service Account را در namespace خاصی حذف کنید:

kubectl delete serviceaccount my-service-account -n my-namespace

دسترسی به Secrets و Tokens مرتبط با Service Account

هر Service Account به طور خودکار Token و Secret برای احراز هویت به API سرور Kubernetes تولید می‌کند. برای مشاهده Secrets مربوط به یک Service Account، از دستور زیر استفاده کنید:

kubectl get secrets

برای مشاهده جزئیات یک Secret خاص که به Service Account متصل است:

kubectl describe secret <secret-name>

این اطلاعات برای احراز هویت و ارتباط با Kubernetes API مفید است.

استفاده از Service Account در Pods

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

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

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  serviceAccountName: my-service-account
  containers:
  - name: mycontainer
    image: nginx

در اینجا، serviceAccountName: my-service-account مشخص می‌کند که پاد باید از Service Account به نام my-service-account استفاده کند.

برای اعمال این پیکربندی و ایجاد پاد:

kubectl apply -f pod-definition.yaml

جمع بندی

در این بخش، یاد گرفتیم که چگونه یک Service Account جدید ایجاد کرده و آن را در Kubernetes مدیریت کنیم. استفاده از دستور kubectl create serviceaccount یا فایل‌های YAML به ما این امکان را می‌دهد که به راحتی Service Account‌ها را در namespace‌های مختلف ایجاد کنیم. همچنین، مشاهده جزئیات و دسترسی به Secrets و Tokens مرتبط با Service Account به ما کمک می‌کند که بتوانیم دسترسی‌ها را به صورت دقیق‌تری مدیریت کنیم. در نهایت، با استفاده از تنظیمات صحیح در فایل‌های YAML، می‌توانیم Service Account را برای استفاده در Pods تنظیم کرده و از آن برای دسترسی به منابع Kubernetes استفاده کنیم.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیکربندی Pod‌ها برای استفاده از Service Accounts خاص” subtitle=”توضیحات کامل”]یکی از اصلی‌ترین اهداف استفاده از Service Accounts در Kubernetes، تخصیص دسترسی‌های خاص به Pods است. به عبارت دیگر، هر Pod می‌تواند به یک Service Account اختصاص یابد تا بتواند از دسترسی‌های مشخص‌شده برای آن Service Account استفاده کند. در این بخش، به نحوه پیکربندی Pod‌ها برای استفاده از Service Accounts خاص پرداخته می‌شود.

۱. مفهوم Service Account در Pods

در Kubernetes، هر Pod می‌تواند به یک Service Account خاص اختصاص یابد. این تخصیص به Pod این امکان را می‌دهد که از Token و Secret موجود در Service Account برای احراز هویت و دسترسی به API سرور Kubernetes استفاده کند.

در صورتی که برای یک Pod، Service Account مشخص نشود، Kubernetes به صورت خودکار یک Service Account به نام default به آن Pod اختصاص می‌دهد.

۲. پیکربندی Pod برای استفاده از Service Account خاص

برای اینکه یک Pod از Service Account خاص استفاده کند، باید در فایل پیکربندی آن Pod (که معمولاً در قالب فایل YAML است) گزینه serviceAccountName را تنظیم کنید.

۲.۱. مثال پیکربندی Pod برای استفاده از یک Service Account خاص

در این مثال، قصد داریم یک Pod به نام myapp-pod ایجاد کنیم که از Service Account به نام my-service-account استفاده می‌کند. فایل YAML این Pod به صورت زیر خواهد بود:

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
spec:
  serviceAccountName: my-service-account  # استفاده از Service Account خاص
  containers:
  - name: myapp-container
    image: nginx

در این فایل YAML:

• serviceAccountName: my-service-account به Kubernetes می‌گوید که این Pod باید از Service Account به نام my-service-account استفاده کند.
• اگر این Service Account وجود نداشته باشد، Kubernetes خطا می‌دهد.

۲.۲. اعمال پیکربندی و ایجاد Pod

برای ایجاد Pod از این پیکربندی، دستور زیر را اجرا کنید:

kubectl apply -f pod-definition.yaml

این دستور Pod را با نام myapp-pod ایجاد می‌کند که از Service Account مشخص‌شده (my-service-account) استفاده خواهد کرد.

۳. بررسی وضعیت Pod و Service Account

برای بررسی وضعیت Pod و مطمئن شدن از اینکه Pod به درستی از Service Account خاص استفاده می‌کند، می‌توانید از دستور describe استفاده کنید:

kubectl describe pod myapp-pod

در قسمت Service Account که در اطلاعات Pod نمایش داده می‌شود، باید نام my-service-account را مشاهده کنید.

۴. بررسی دسترسی‌ها و استفاده از Token

برای اینکه مطمئن شوید Pod به درستی از Service Account استفاده می‌کند، می‌توانید Token‌های مربوط به آن Service Account را بررسی کنید. هر Pod که از Service Account خاص استفاده می‌کند، به طور خودکار Token مربوط به آن Service Account را در اختیار خواهد داشت.

برای بررسی Secret‌ها و Token‌ها، دستور زیر را اجرا کنید:

kubectl get secrets

سپس، Secret مربوط به Service Account را پیدا کرده و جزئیات آن را مشاهده کنید:

kubectl describe secret <secret-name>

۵. استفاده از Service Account در دسترسی به API Kubernetes

هر Pod که به Service Account خاصی اختصاص یابد، از Token‌های آن Service Account برای دسترسی به API Kubernetes استفاده می‌کند. این دسترسی‌ها شامل خواندن منابع مانند پادها، خدمات، و سایر منابع Kubernetes می‌شود.

برای مثال، اگر شما یک Pod دارید که نیاز دارد به صورت برنامه‌نویسی به API سرور Kubernetes دسترسی پیدا کند، می‌توانید از kubectl client یا از کتابخانه‌های خاص برای دسترسی به API استفاده کنید. در این حالت، توکن مربوط به Service Account به طور خودکار برای احراز هویت استفاده می‌شود.

۶. تنظیمات پیشرفته: استفاده از Service Account در Deployment‌ها و سایر منابع

شما می‌توانید از Service Account‌ها نه تنها در Pods، بلکه در منابع دیگری مانند Deployments، StatefulSets، DaemonSets و غیره نیز استفاده کنید. در اینجا نمونه‌ای از پیکربندی یک Deployment که از یک Service Account خاص استفاده می‌کند آورده شده است:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      serviceAccountName: my-service-account  # استفاده از Service Account خاص
      containers:
      - name: myapp-container
        image: nginx

در اینجا، serviceAccountName: my-service-account باعث می‌شود که Pods‌های ایجاد شده توسط این Deployment از Service Account خاص استفاده کنند.

جمع بندی

در این بخش، نحوه پیکربندی Pods برای استفاده از Service Account خاص بررسی شد. با تخصیص یک Service Account خاص به یک Pod، می‌توان دسترسی‌های مشخص و امن را برای Pods فراهم کرد. این تخصیص به طور معمول از طریق گزینه serviceAccountName در فایل YAML انجام می‌شود و می‌تواند به راحتی در انواع منابع Kubernetes از جمله Pods و Deployments به کار رود. استفاده صحیح از Service Account‌ها به شما کمک می‌کند که دسترسی‌ها را کنترل کنید و امنیت برنامه‌های خود را افزایش دهید.[/cdb_course_lesson][cdb_course_lesson title=”Role-Based Access Control (RBAC):”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف مفاهیم Role و ClusterRole” subtitle=”توضیحات کامل”]در Kubernetes، کنترل دسترسی به منابع مختلف از طریق مفاهیم Role و ClusterRole انجام می‌شود. این مفاهیم به شما این امکان را می‌دهند که با دقت بالایی دسترسی‌های مختلف را به منابع داخل یک Namespace خاص یا در سطح کل کلاستر مدیریت کنید.

۱. مفهوم Role

Role در Kubernetes مجموعه‌ای از مجوزها (permissions) است که به منابع خاصی در یک Namespace معین اجازه دسترسی می‌دهد. این مجوزها می‌توانند شامل عملیات‌هایی مانند مشاهده، ایجاد، بروزرسانی یا حذف منابع مختلفی مانند Pods، Services، ConfigMaps و دیگر منابع باشند.

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

۱.۱. مثال پیکربندی یک Role

در این مثال، یک Role به نام pod-reader تعریف می‌شود که فقط مجوز خواندن (get, list, watch) از منابع Pods را در یک Namespace خاص می‌دهد.

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

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

• apiGroups: [“”] نشان‌دهنده گروه API برای منابع پایه است.
• resources: [“pods”] منابعی هستند که دسترسی به آن‌ها مجاز است.
• verbs: [“get”, “list”, “watch”] مشخص می‌کنند که کاربر می‌تواند این عملیات‌ها را روی منابع انجام دهد.

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

kubectl apply -f role-definition.yaml

۲. مفهوم ClusterRole

ClusterRole مشابه Role است، اما با این تفاوت که ClusterRole می‌تواند دسترسی‌هایی را در سطح کل کلاستر (تمامی Namespaceها) اعمال کند. به عبارت دیگر، ClusterRole به منابع موجود در تمامی Namespaceها دسترسی می‌دهد، نه فقط یک Namespace خاص.

این امکان برای تنظیم دسترسی‌های سطح کل کلاستر مانند مشاهده منابع در تمامی Namespaceها یا مدیریت منابع خاص در کلاستر مفید است.

۲.۱. مثال پیکربندی یک ClusterRole

در این مثال، یک ClusterRole به نام cluster-admin تعریف می‌شود که تمامی عملیات‌ها را بر روی تمامی منابع در تمام Namespace‌ها مجاز می‌کند.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-admin
rules:
- apiGroups: [""]
  resources: ["pods", "services", "nodes"]
  verbs: ["*"]

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

• apiGroups: [“”] گروه API برای منابع پایه است.
• resources: [“pods”, “services”, “nodes”] منابعی هستند که دسترسی به آن‌ها مجاز است.
• verbs: [“*”] به این معنی است که تمامی عملیات‌ها مانند ایجاد، خواندن، بروزرسانی و حذف برای این منابع مجاز هستند.

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

kubectl apply -f clusterrole-definition.yaml

۳. تفاوت اصلی بین Role و ClusterRole

ویژگی	Role	ClusterRole
محدوده دسترسی	محدود به یک Namespace خاص	اعمال دسترسی‌ها در سطح کل کلاستر، شامل تمامی Namespace‌ها
زمان استفاده	برای مدیریت دسترسی‌ها در سطح Namespace	برای مدیریت دسترسی‌ها در سطح کلاستر، مستقل از Namespace
استفاده‌های معمول	دسترسی به منابع مانند Pods، Services در یک Namespace خاص	دسترسی‌های جهانی مانند مشاهده تمامی Pods و خدمات در کل کلاستر

۴. استفاده از Role و ClusterRole در ترکیب با RoleBinding و ClusterRoleBinding

برای اینکه یک کاربر، گروه یا Service Account بتواند از Role یا ClusterRole استفاده کند، باید یک RoleBinding یا ClusterRoleBinding ایجاد کنید. این تنظیمات مجوزها را برای کاربران یا سرویس‌ها در سطح خاص (Namespace یا کلاستر) اعمال می‌کنند.

۴.۱. RoleBinding برای Role

اگر بخواهید یک Role خاص را به یک کاربر در یک Namespace مشخص تخصیص دهید، باید از RoleBinding استفاده کنید.

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: default
subjects:
- kind: User
  name: "example-user"  # کاربر یا سرویس‌اکانت مورد نظر
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader  # نام Role که تخصیص داده می‌شود
  apiGroup: rbac.authorization.k8s.io

۴.۲. ClusterRoleBinding برای ClusterRole

اگر بخواهید یک ClusterRole را به یک کاربر یا سرویس‌اکانت در سطح کلاستر تخصیص دهید، باید از ClusterRoleBinding استفاده کنید.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: User
  name: "example-user"  # کاربر یا سرویس‌اکانت مورد نظر
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: cluster-admin  # نام ClusterRole که تخصیص داده می‌شود
  apiGroup: rbac.authorization.k8s.io

جمع بندی

در این بخش، مفاهیم Role و ClusterRole در Kubernetes معرفی و توضیح داده شد. Role به شما این امکان را می‌دهد که دسترسی‌ها را در سطح یک Namespace خاص کنترل کنید، در حالی که ClusterRole دسترسی‌ها را در سطح کل کلاستر فراهم می‌آورد. برای تخصیص این دسترسی‌ها به کاربران، گروه‌ها یا سرویس‌اکانت‌ها، از RoleBinding و ClusterRoleBinding استفاده می‌شود. این ابزارها نقش بسیار مهمی در مدیریت دسترسی‌ها و امنیت در Kubernetes ایفا می‌کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد و مدیریت RoleBinding و ClusterRoleBinding” subtitle=”توضیحات کامل”]در Kubernetes، برای ارتباط دادن Role و ClusterRole با کاربران یا سرویس‌اکانت‌ها از مفاهیم RoleBinding و ClusterRoleBinding استفاده می‌شود. این ابزارها به شما این امکان را می‌دهند که دسترسی‌های تعریف‌شده در یک Role یا ClusterRole را به کاربران یا سرویس‌اکانت‌ها در سطح یک Namespace یا سطح کلاستر اعمال کنید.

RoleBinding

RoleBinding یک اتصال بین یک Role و یک یا چند subject (مثل کاربران، سرویس‌اکانت‌ها یا گروه‌ها) در یک Namespace خاص است. با استفاده از RoleBinding، دسترسی‌های موجود در یک Role را می‌توان به کاربران خاص یا سرویس‌اکانت‌ها در همان Namespace تخصیص داد.

ساختار پیکربندی RoleBinding

در اینجا یک مثال از RoleBinding برای تخصیص یک Role به یک ServiceAccount آورده شده است:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: default  # Namespace مورد نظر
subjects:
- kind: ServiceAccount
  name: example-service-account  # نام سرویس‌اکانت
  namespace: default  # Namespace که سرویس‌اکانت در آن قرار دارد
roleRef:
  kind: Role
  name: pod-reader  # نام Role که باید به آن دسترسی داده شود
  apiGroup: rbac.authorization.k8s.io

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

• subjects: کاربر یا سرویس‌اکانت مورد نظر که می‌خواهید دسترسی‌ها را به آن بدهید.
• roleRef: اشاره به Role یا ClusterRole که می‌خواهید دسترسی‌ها از آن گرفته شود.
• namespace: مشخص می‌کند که این RoleBinding در کدام Namespace اعمال شود (در اینجا default).

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

kubectl apply -f rolebinding-definition.yaml

ClusterRoleBinding

ClusterRoleBinding مشابه RoleBinding است، با این تفاوت که ClusterRoleBinding برای تخصیص دسترسی‌ها در سطح کلاستر (یعنی برای تمام Namespaceها) به کار می‌رود. به این معنی که اگر بخواهید یک ClusterRole را به یک کاربر یا سرویس‌اکانت در سطح کلاستر تخصیص دهید، باید از ClusterRoleBinding استفاده کنید.

ساختار پیکربندی ClusterRoleBinding

در اینجا یک مثال از ClusterRoleBinding برای تخصیص یک ClusterRole به یک ServiceAccount آورده شده است:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-admin-binding
subjects:
- kind: ServiceAccount
  name: example-service-account  # نام سرویس‌اکانت
  namespace: default  # Namespace که سرویس‌اکانت در آن قرار دارد
roleRef:
  kind: ClusterRole
  name: cluster-admin  # نام ClusterRole که باید به آن دسترسی داده شود
  apiGroup: rbac.authorization.k8s.io

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

• subjects: کاربر یا سرویس‌اکانت که می‌خواهید دسترسی‌ها را به آن بدهید.
• roleRef: اشاره به ClusterRole یا Role که می‌خواهید دسترسی‌ها از آن گرفته شود.
• namespace: در اینجا Namespace سرویس‌اکانت مشخص شده است. این بخش در ClusterRoleBinding تأثیری ندارد زیرا دسترسی‌ها در سطح کلاستر اعمال می‌شود.

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

kubectl apply -f clusterrolebinding-definition.yaml

ویرایش و حذف RoleBinding و ClusterRoleBinding

برای ویرایش یا حذف RoleBinding یا ClusterRoleBinding می‌توانید از دستورات زیر استفاده کنید.

ویرایش RoleBinding و ClusterRoleBinding

برای ویرایش RoleBinding یا ClusterRoleBinding می‌توانید از دستور kubectl edit استفاده کنید:

kubectl edit rolebinding pod-reader-binding -n default
kubectl edit clusterrolebinding cluster-admin-binding

این دستورها ویرایشگر پیش‌فرض سیستم را باز کرده و به شما اجازه می‌دهند پیکربندی را تغییر دهید.

حذف RoleBinding و ClusterRoleBinding

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

kubectl delete rolebinding pod-reader-binding -n default
kubectl delete clusterrolebinding cluster-admin-binding

جمع بندی

در این بخش، نحوه ایجاد و مدیریت RoleBinding و ClusterRoleBinding در Kubernetes بررسی شد. RoleBinding برای تخصیص دسترسی‌های یک Role به کاربران یا سرویس‌اکانت‌ها در یک Namespace خاص استفاده می‌شود، در حالی که ClusterRoleBinding برای تخصیص دسترسی‌های یک ClusterRole در سطح کلاستر استفاده می‌شود. این مفاهیم به شما امکان می‌دهند تا دسترسی‌های پیچیده را به راحتی مدیریت کرده و امنیت کلاستر خود را بهینه کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”محدودسازی دسترسی کاربران و منابع Kubernetes” subtitle=”توضیحات کامل”]در Kubernetes، مدیریت دسترسی کاربران و منابع یک بخش مهم از امنیت است. محدودسازی دسترسی به منابع مختلف و تخصیص دسترسی‌های دقیق به کاربران و سرویس‌اکانت‌ها، می‌تواند به شما کمک کند تا امنیت کلاستر خود را حفظ کنید و از دسترسی غیرمجاز جلوگیری کنید. این کار به وسیله‌ی کنترل‌های مختلفی مانند Role-Based Access Control (RBAC)، Network Policies، و Resource Quotas انجام می‌شود.

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

---

1. استفاده از Role-Based Access Control (RBAC)

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

محدودسازی دسترسی با استفاده از Roles

برای محدودسازی دسترسی به منابع مختلف در یک Namespace خاص، می‌توانید از Role استفاده کنید. یک Role به شما اجازه می‌دهد تا دسترسی‌های خاصی (مثل خواندن، نوشتن، حذف و غیره) را به منابع خاص (مثل Pods، Services، و Deployments) در یک Namespace معین بدهید.

مثال:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

در این مثال، یک Role با نام pod-reader ایجاد شده که به کاربر یا سرویس‌اکانت دسترسی خواندن (get و list) به منابع Pods در Namespace default می‌دهد.

---

2. استفاده از Network Policies

Network Policies یکی از ابزارهای بسیار مهم برای محدودسازی دسترسی بین پادها (Pods) در Kubernetes است. با استفاده از Network Policies، می‌توانید مشخص کنید که کدام پادها مجاز به ارتباط با پادهای دیگر هستند. این امر به ویژه برای جداسازی و کنترل ترافیک شبکه در کلاسترهای بزرگ و پیچیده بسیار مفید است.

ساختار Network Policy

در یک Network Policy، می‌توانید تعیین کنید که کدام پادها از چه IP‌ها یا پورت‌هایی اجازه برقراری ارتباط دارند.

مثال:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-db-access
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: db
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: web
    ports:
    - protocol: TCP
      port: 3306

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

• podSelector: مشخص می‌کند که کدام پادها تحت تاثیر این سیاست قرار می‌گیرند.
• ingress: مشخص می‌کند که از کجا و از چه پورت‌هایی ترافیک به این پادها مجاز است. در اینجا فقط پادهایی با برچسب app: web می‌توانند به پادهایی با برچسب app: db روی پورت 3306 دسترسی داشته باشند.

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

kubectl apply -f networkpolicy-definition.yaml

---

3. استفاده از Resource Quotas

برای محدودسازی استفاده از منابع مانند CPU، حافظه و تعداد پادها در یک Namespace، می‌توانید از Resource Quotas استفاده کنید. Resource Quotas به شما اجازه می‌دهد تا سقفی برای منابع استفاده‌شده توسط پادها و دیگر منابع در یک Namespace تعیین کنید.

ساختار Resource Quota

مثال:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-resources
  namespace: default
spec:
  hard:
    requests.cpu: "2"
    requests.memory: 4Gi
    limits.cpu: "4"
    limits.memory: 8Gi
    pods: "10"

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

• requests.cpu و requests.memory: مقدار حداقل منابعی که هر پاد باید درخواست کند.
• limits.cpu و limits.memory: حداکثر منابعی که یک پاد می‌تواند مصرف کند.
• pods: تعداد پادهایی که می‌توانند در این Namespace ایجاد شوند.

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

kubectl apply -f resourcequota-definition.yaml

---

4. استفاده از PodSecurityPolicies

PodSecurityPolicies (اگر فعال باشد) می‌توانند برای محدود کردن رفتار پادها در Kubernetes استفاده شوند. این سیاست‌ها به شما این امکان را می‌دهند که رفتارهای خطرناک پادها مانند اجرای کانتینرها با دسترسی ریشه (root)، استفاده از حجم‌های مشترک و یا دسترسی به شبکه‌های خارجی را محدود کنید.

ساختار PodSecurityPolicy

مثال:

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted-psp
spec:
  privileged: false
  volumes:
  - 'emptyDir'
  - 'configMap'
  - 'secret'
  allowedCapabilities: []
  requiredDropCapabilities:
  - NET_ADMIN
  - SYS_TIME
  runAsUser:
    rule: 'MustRunAsNonRoot'

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

• privileged: تعیین می‌کند که پاد نمی‌تواند به صورت privileged اجرا شود.
• allowedCapabilities: قابلیت‌های مجاز برای پادها را محدود می‌کند.
• runAsUser: نیاز به اجرای کانتینرها با کاربر غیر ریشه دارد.

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

kubectl apply -f podsecuritypolicy-definition.yaml

---

جمع بندی

در این بخش، روش‌های مختلف محدودسازی دسترسی کاربران و منابع در Kubernetes را بررسی کردیم. با استفاده از RBAC می‌توانید دسترسی‌های دقیق‌تری به منابع مختلف در کلاستر خود اعمال کنید. از Network Policies می‌توانید برای کنترل ترافیک شبکه و ارتباط بین پادها استفاده کنید. Resource Quotas به شما این امکان را می‌دهند که منابع را در یک Namespace محدود کنید. همچنین PodSecurityPolicies می‌توانند برای محدود کردن رفتار پادها و افزایش امنیت استفاده شوند. این ابزارها به شما کمک می‌کنند که از دسترسی‌های غیرمجاز جلوگیری کرده و امنیت کلاستر خود را بهبود بخشید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی دسترسی کاربران با استفاده از دستورات kubectl auth can-i” subtitle=”توضیحات کامل”]یکی از نیازهای مهم در مدیریت امنیت و دسترسی در Kubernetes، بررسی سطح دسترسی کاربران و سرویس‌اکانت‌ها به منابع مختلف است. Kubernetes به‌طور پیش‌فرض امکان بررسی دقیق دسترسی‌ها و اطمینان از اینکه کاربر یا سرویس‌اکانت خاصی مجاز به انجام عمل خاصی است یا نه، را فراهم می‌کند.

برای این منظور، ابزار kubectl auth can-i در Kubernetes طراحی شده است که به شما این امکان را می‌دهد تا بررسی کنید که آیا یک کاربر یا سرویس‌اکانت خاص اجازه انجام عملی خاص را دارد یا خیر. این ابزار به‌ویژه زمانی مفید است که بخواهید دسترسی‌ها را عیب‌یابی کرده و از صحیح بودن تنظیمات Role و ClusterRole خود اطمینان حاصل کنید.

---

1. ساختار دستور kubectl auth can-i

دستور kubectl auth can-i به شما این امکان را می‌دهد که بررسی کنید آیا یک کاربر یا سرویس‌اکانت خاص اجازه انجام عملی خاص را بر روی منابع Kubernetes دارد یا خیر. این دستور برای شبیه‌سازی دسترسی‌ها استفاده می‌شود و از دستورات زیر می‌توان به آن دسترسی پیدا کرد:

kubectl auth can-i <action> <resource> [--namespace=<namespace>] [--as=<user>]

در اینجا:

• <action>: عملی است که می‌خواهید دسترسی آن را بررسی کنید. این عمل می‌تواند یکی از مواردی مانند get، create، delete، update و غیره باشد.
• <resource>: نام منبعی است که می‌خواهید دسترسی به آن را بررسی کنید. به عنوان مثال، pods، services، deployments و غیره.
• --namespace=<namespace>: در صورتی که بخواهید دسترسی را در یک Namespace خاص بررسی کنید، می‌توانید این پارامتر را مشخص کنید.
• --as=<user>: برای بررسی دسترسی کاربری خاص به جای کاربر فعلی، می‌توانید این پارامتر را به کار ببرید.

---

2. مثال‌های عملی برای استفاده از kubectl auth can-i

بررسی دسترسی برای مشاهده (Read) منابع Pods

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

kubectl auth can-i get pods --namespace=default

این دستور بررسی می‌کند که آیا کاربر فعلی مجاز به انجام عمل get روی Pods در Namespace default است یا خیر.

بررسی دسترسی برای ایجاد (Create) منابع Deployment

اگر بخواهید بررسی کنید که آیا کاربر یا سرویس‌اکانت خاصی مجاز به ایجاد یک Deployment در Namespace خاصی است، دستور زیر را وارد کنید:

kubectl auth can-i create deployments --namespace=default

این دستور بررسی می‌کند که آیا کاربر فعلی اجازه ایجاد Deployment در Namespace default را دارد یا خیر.

بررسی دسترسی برای حذف (Delete) منابع Service

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

kubectl auth can-i delete services --namespace=default

این دستور بررسی می‌کند که آیا کاربر فعلی می‌تواند Services را در Namespace default حذف کند یا خیر.

بررسی دسترسی برای دسترسی به منابع در یک Cluster به‌صورت کلی

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

kubectl auth can-i get pods --as=admin

در این دستور، بررسی می‌کنیم که آیا کاربر admin مجاز به انجام عملیات get روی منابع Pods است یا خیر.

بررسی دسترسی برای ایجاد (Create) منابع Secret برای کاربر خاص

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

kubectl auth can-i create secrets --namespace=default --as=john

این دستور بررسی می‌کند که آیا کاربر john مجاز به ایجاد Secrets در Namespace default است یا خیر.

---

3. نتایج دستور kubectl auth can-i

دستور kubectl auth can-i دو نتیجه ممکن دارد:

• yes: نشان‌دهنده این است که کاربر یا سرویس‌اکانت مجاز به انجام عمل موردنظر است.
• no: نشان‌دهنده این است که کاربر یا سرویس‌اکانت مجاز به انجام عمل موردنظر نیست.

---

4. استفاده از kubectl auth can-i برای تست RoleBindings و ClusterRoleBindings

با استفاده از این ابزار، می‌توانید بررسی کنید که آیا یک RoleBinding یا ClusterRoleBinding به درستی دسترسی‌ها را تخصیص داده است یا خیر. به عنوان مثال، برای بررسی دسترسی یک سرویس‌اکانت به منابع مختلف در کلاستر، می‌توانید دستورات زیر را به کار ببرید:

kubectl auth can-i get pods --as=serviceaccount:default:my-service-account --namespace=default

این دستور بررسی می‌کند که آیا سرویس‌اکانت my-service-account که در Namespace default قرار دارد، می‌تواند Pods را مشاهده کند یا خیر.

---

5. بررسی دسترسی برای کاربران در سطح کلاستر

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

kubectl auth can-i get nodes --as=admin

این دستور بررسی می‌کند که آیا کاربر admin مجاز به مشاهده Nodes در کلاستر است یا خیر.

---

جمع بندی

دستور kubectl auth can-i ابزاری قدرتمند برای بررسی و عیب‌یابی دسترسی‌ها در Kubernetes است. این دستور به شما این امکان را می‌دهد که بررسی کنید آیا یک کاربر یا سرویس‌اکانت خاص مجاز به انجام عمل خاصی بر روی منابع مختلف است یا خیر. استفاده از این دستور می‌تواند به شما در شبیه‌سازی دسترسی‌ها و اطمینان از صحت تنظیمات Role و ClusterRole کمک کند و امنیت کلاستر شما را تقویت کند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. استفاده از Security Context برای Pods و کانتینرها”][/cdb_course_lesson][cdb_course_lesson title=”SecurityContext:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف و تنظیم Security Context در سطح Pod” subtitle=”توضیحات کامل”]در کوبرنتیز، Security Context مجموعه‌ای از تنظیمات امنیتی است که می‌توانند برای Pod یا Container تنظیم شوند. این تنظیمات به شما این امکان را می‌دهند که رفتار امنیتی و محدودیت‌های اجرایی را برای Pod‌ها یا Containers تعریف کنید. Security Context‌ها می‌توانند تنظیمات مختلفی شامل دسترسی‌ها، مجوزها، و ویژگی‌های خاص امنیتی را مشخص کنند که برای حفظ امنیت و مدیریت منابع سیستم بسیار مهم هستند.

Security Context در سطح Pod به شما این امکان را می‌دهد که امنیت کلی Pod و تمام Containers داخل آن را تعریف کنید. به‌طور کلی، این تنظیمات شامل مواردی مثل User ID (UID)، Group ID (GID)، و دسترسی‌های سطح پایین به منابع سیستم می‌باشد.

---

1. ساختار کلی یک Security Context در سطح Pod

Security Context در سطح Pod می‌تواند به‌صورت زیر در فایل YAML تعریف شود:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
    seLinuxOptions:
      level: "s0:c123,c456"
  containers:
    - name: example-container
      image: example-image
      securityContext:
        allowPrivilegeEscalation: false
        privileged: false

در اینجا:

• runAsUser: تعیین می‌کند که تمامی Containers در داخل Pod تحت چه User ID (UID) اجرا شوند.
• runAsGroup: مشخص می‌کند که تمامی Containers در داخل Pod تحت چه Group ID (GID) اجرا شوند.
• fsGroup: به شما این امکان را می‌دهد که مشخص کنید چه Group ID (GID) برای دسترسی به سیستم‌فایل‌ها در اختیار Containers قرار گیرد.
• seLinuxOptions: برای تعیین تنظیمات خاص SELinux استفاده می‌شود.
• allowPrivilegeEscalation: این تنظیم مشخص می‌کند که آیا می‌توان از سطح دسترسی‌های پایین‌تر به سطح بالاتر دسترسی پیدا کرد یا خیر.
• privileged: اگر true باشد، به Container سطح دسترسی‌های بیشتری داده می‌شود که معمولا برای Container‌های خاص نیاز است (مثل دسترسی به دستگاه‌های خاص).

---

2. تنظیمات کلیدی در Security Context

برای پیکربندی دقیق‌تر Security Context در سطح Pod، می‌توانید از تنظیمات مختلف زیر استفاده کنید:

1. runAsUser و runAsGroup

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

• runAsUser: این گزینه برای تعیین User ID (UID) است که Container‌ها اجرا می‌شوند. این کار می‌تواند امنیت سیستم را از طریق جلوگیری از دسترسی‌های غیرمجاز به منابع حساس بهبود بخشد.
• runAsGroup: این گزینه برای تعیین Group ID (GID) است که به همراه runAsUser برای Containers استفاده می‌شود.

securityContext:
  runAsUser: 1000
  runAsGroup: 3000

2. fsGroup

این گزینه Group ID (GID) را تعیین می‌کند که برای تمام فایل‌ها و دایرکتوری‌های موجود در Pod به‌عنوان گروه مالک تعیین می‌شود. این تنظیم می‌تواند برای کنترل دسترسی به سیستم‌فایل‌ها استفاده شود.

securityContext:
  fsGroup: 2000

3. allowPrivilegeEscalation

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

securityContext:
  allowPrivilegeEscalation: false

4. privileged

اگر این گزینه فعال باشد (true)، Container به سطح دسترسی بیشتری دست خواهد یافت، که می‌تواند برای کارهایی مانند کار با دستگاه‌های خاص یا استفاده از امکانات سیستمی خاص مورد نیاز باشد. به‌طور معمول، این گزینه باید غیرفعال باشد مگر اینکه کاملاً ضروری باشد.

securityContext:
  privileged: false

5. readOnlyRootFilesystem

با فعال کردن این گزینه، سیستم‌فایل ریشه (root filesystem) Container به‌صورت فقط‌خواندنی (read-only) می‌شود، که این امر می‌تواند امنیت را در برابر دسترسی‌های غیرمجاز افزایش دهد.

securityContext:
  readOnlyRootFilesystem: true

6. seLinuxOptions

این گزینه برای پیکربندی ویژگی‌های SELinux (Security-Enhanced Linux) برای Pod استفاده می‌شود. این تنظیمات می‌توانند بر اساس سطح امنیتی خاصی که برای Pod مورد نیاز است، پیکربندی شوند.

securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

---

3. استفاده از Security Context در سطح Container

در داخل یک Pod، می‌توانید علاوه بر تنظیمات سطح Pod، Security Context را به‌صورت جداگانه برای هر Container تنظیم کنید. برای این کار، باید تنظیمات securityContext را در بخش مربوط به هر Container در فایل YAML قرار دهید:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
    - name: example-container
      image: example-image
      securityContext:
        runAsUser: 1001
        allowPrivilegeEscalation: false

در این مثال، تنظیمات Security Context برای Container خاصی اعمال شده است که ممکن است با تنظیمات کل Pod متفاوت باشد.

---

4. تعیین Security Context به‌صورت دینامیک

برای تنظیم Security Context به‌صورت دینامیک در هنگام اجرای Pod، می‌توانید از دستورات kubectl به‌صورت مستقیم استفاده کنید:

kubectl run example-pod --image=nginx --restart=Never \
  --overrides='
    {
      "apiVersion": "v1",
      "spec": {
        "securityContext": {
          "runAsUser": 1000,
          "runAsGroup": 3000
        },
        "containers": [
          {
            "name": "nginx",
            "image": "nginx",
            "securityContext": {
              "allowPrivilegeEscalation": false
            }
          }
        ]
      }
    }'

در این دستور، Pod با تنظیمات Security Context خاص ایجاد می‌شود.

---

جمع بندی

Security Context در Kubernetes ابزاری قدرتمند برای مدیریت و تنظیم امنیت Pod‌ها و Containers است. با استفاده از این تنظیمات، می‌توانید کنترل دقیقی بر روی دسترسی‌ها، سطح مجوزها، و ویژگی‌های اجرایی در سطح سیستم‌عامل داشته باشید. این ویژگی‌ها به شما کمک می‌کنند تا امنیت Pods و Containers را بهبود بخشید و از هرگونه تهدید احتمالی جلوگیری کنید. تنظیمات مختلف مانند runAsUser، allowPrivilegeEscalation و privileged می‌توانند مطابق با نیازهای امنیتی شما سفارشی‌سازی شوند و رفتار Pods را به گونه‌ای تغییر دهند که به بهترین شکل از سیستم و داده‌ها محافظت شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”محدود سازی دسترسی‌های سیستم فایل (ReadOnlyRootFilesystem)” subtitle=”توضیحات کامل”]در Kubernetes، یکی از مهم‌ترین جنبه‌های امنیتی، محدودسازی دسترسی به سیستم فایل‌های Container است. تنظیم ReadOnlyRootFilesystem به شما این امکان را می‌دهد که سطح دسترسی به سیستم‌فایل‌های ریشه (Root filesystem) را به‌صورت “فقط خواندنی” تنظیم کنید. این به طور موثری از تغییرات ناخواسته و دسترسی‌های غیرمجاز به سیستم‌فایل جلوگیری می‌کند و در نتیجه یک لایه امنیتی اضافی برای Container‌ها فراهم می‌آورد.

---

1. مفهوم ReadOnlyRootFilesystem

ReadOnlyRootFilesystem یک تنظیم در SecurityContext است که به شما این امکان را می‌دهد که سیستم‌فایل ریشه در داخل Container فقط به‌صورت خواندنی (read-only) در دسترس باشد. زمانی که این تنظیم فعال باشد، هیچ‌گونه تغییراتی نمی‌تواند در سیستم‌فایل ریشه انجام شود. این ویژگی در مواقعی که به دنبال کاهش ریسک آسیب‌پذیری‌های امنیتی و جلوگیری از تغییرات غیرمجاز در سیستم‌فایل هستید، بسیار مفید است.

---

2. فعال‌سازی ReadOnlyRootFilesystem

برای فعال‌سازی ReadOnlyRootFilesystem در سطح Pod یا Container، می‌توانید از بخش securityContext در فایل YAML استفاده کنید. اگر بخواهید این تنظیمات را برای کل Pod یا فقط برای یک Container خاص اعمال کنید، می‌توانید آن را به‌طور جداگانه تنظیم کنید.

1. تنظیم برای کل Pod

در صورتی که بخواهید این تنظیم برای تمام Containers داخل Pod اعمال شود، باید آن را در بخش spec.securityContext در فایل YAML تعریف کنید.

apiVersion: v1
kind: Pod
metadata:
  name: readonly-pod
spec:
  securityContext:
    readOnlyRootFilesystem: true
  containers:
    - name: example-container
      image: example-image

در اینجا:

• readOnlyRootFilesystem: true در بخش securityContext Pod قرار داده شده است. این بدان معنی است که تمامی Containers داخل این Pod نمی‌توانند تغییراتی در سیستم‌فایل ریشه ایجاد کنند.

2. تنظیم برای یک Container خاص

اگر بخواهید این تنظیمات فقط برای یک Container خاص اعمال شود، می‌توانید آن را در بخش securityContext هر Container در فایل YAML قرار دهید.

apiVersion: v1
kind: Pod
metadata:
  name: readonly-container-pod
spec:
  containers:
    - name: example-container
      image: example-image
      securityContext:
        readOnlyRootFilesystem: true

در اینجا:

• readOnlyRootFilesystem: true فقط برای Container خاص example-container اعمال می‌شود. به این ترتیب، فقط این Container در داخل Pod سیستم‌فایل ریشه خود را به‌صورت خواندنی می‌کند.

---

3. مزایای استفاده از ReadOnlyRootFilesystem

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

• کاهش خطر تغییرات ناخواسته: وقتی که سیستم‌فایل ریشه به‌صورت فقط‌خواندنی تنظیم می‌شود، هیچ‌گونه تغییراتی نمی‌تواند در آن اعمال شود. این به جلوگیری از تغییرات غیرمجاز یا بدافزارهای احتمالی کمک می‌کند.
• افزایش امنیت: این تنظیم می‌تواند به کاهش آسیب‌پذیری‌ها و محافظت از فایل‌های حیاتی سیستم کمک کند. حتی اگر یک مهاجم به Container نفوذ کند، به دلیل محدودیت‌های سیستم‌فایلی نمی‌تواند به راحتی سیستم‌فایل ریشه را تغییر دهد.
• مؤثر در جلوگیری از حملات Rootkit: یکی از انواع حملات، Rootkit‌ها هستند که به مهاجم اجازه می‌دهند سیستم را کنترل کنند. با استفاده از این ویژگی، امکان تغییر سیستم‌فایل‌ها برای نصب Rootkit‌ها غیرممکن می‌شود.

---

4. محدودیت‌ها و چالش‌ها

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

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

• حجم‌های (Volumes): اگر یک Container به فایل‌هایی نیاز دارد که باید در سیستم‌فایل ریشه ذخیره شود، باید مطمئن شوید که این فایل‌ها در Volume‌هایی ذخیره شوند که به‌صورت جداگانه و با تنظیمات نوشتنی (read-write) پیکربندی شده‌اند.
• ایجاد داده‌های موقتی: برخی برنامه‌ها برای ذخیره داده‌های موقتی نیاز به نوشتن در سیستم‌فایل دارند، بنابراین باید از Volumes یا مسیرهایی استفاده کرد که در خارج از سیستم‌فایل ریشه قرار دارند.

---

5. استفاده از Volume‌های جداگانه برای ذخیره داده‌ها

در صورت استفاده از ReadOnlyRootFilesystem، معمولاً از Volumes برای ذخیره داده‌های قابل نوشتن استفاده می‌شود. برای این کار، می‌توانید از نوع Volume‌هایی مثل emptyDir، hostPath، یا persistentVolumeClaim استفاده کنید.

مثال زیر نشان می‌دهد که چگونه می‌توان یک Volume قابل نوشتن را برای ذخیره داده‌ها در کنار ReadOnlyRootFilesystem تنظیم کرد:

apiVersion: v1
kind: Pod
metadata:
  name: readonly-container-with-volume
spec:
  securityContext:
    readOnlyRootFilesystem: true
  volumes:
    - name: data-volume
      emptyDir: {}
  containers:
    - name: example-container
      image: example-image
      volumeMounts:
        - name: data-volume
          mountPath: /data

در این مثال:

• readOnlyRootFilesystem: true تنظیم شده است تا سیستم‌فایل ریشه فقط خواندنی باشد.
• emptyDir برای Volume استفاده می‌شود که داده‌ها در آن ذخیره می‌شود و امکان نوشتن در آن وجود دارد.
• mountPath: /data به Container اعلام می‌کند که این Volume باید در مسیر /data سیستم‌فایل داخل Container قرار گیرد.

---

6. بررسی وضعیت تنظیمات

برای بررسی وضعیت ReadOnlyRootFilesystem یک Pod یا Container، می‌توانید از دستور kubectl استفاده کنید. این دستور به شما کمک می‌کند که مشخص کنید آیا تنظیمات امنیتی به درستی اعمال شده‌اند یا خیر.

برای مشاهده تنظیمات Pod‌ها و Containers:

kubectl get pod readonly-pod -o yaml

این دستور اطلاعات مربوط به Pod مورد نظر را به‌صورت YAML نمایش می‌دهد و می‌توانید بررسی کنید که تنظیمات readOnlyRootFilesystem به درستی اعمال شده است یا خیر.

---

جمع بندی

استفاده از ReadOnlyRootFilesystem در Kubernetes یک روش مؤثر برای افزایش امنیت Containers است. با این تنظیم، سیستم‌فایل ریشه به‌صورت خواندنی می‌شود و از تغییرات غیرمجاز جلوگیری می‌شود. با این حال، باید توجه داشته باشید که برخی از Containers ممکن است به دسترسی نوشتن به سیستم‌فایل نیاز داشته باشند. در این موارد، می‌توان از Volumes جداگانه برای ذخیره داده‌های قابل نوشتن استفاده کرد. این تنظیم نه تنها از حملات و تغییرات ناخواسته جلوگیری می‌کند بلکه به بهبود امنیت سیستم و داده‌ها نیز کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اجرای کانتینرها با کاربرهای غیر ریشه (Non-Root Users)” subtitle=”توضیحات کامل”]در Kubernetes، اجرای کانتینرها با کاربرهای غیر ریشه (Non-Root Users) یکی از روش‌های حیاتی برای افزایش امنیت است. به‌طور پیش‌فرض، بسیاری از کانتینرها به‌عنوان کاربر ریشه (Root) اجرا می‌شوند که می‌تواند منجر به آسیب‌پذیری‌های امنیتی شود. مهاجمان می‌توانند به‌راحتی با استفاده از دسترسی‌های ریشه، کنترل کامل سیستم را به‌دست آورند. بنابراین، اجرای کانتینرها با کاربرهای غیر ریشه می‌تواند به‌طور قابل‌توجهی خطرات ناشی از دسترسی‌های غیرمجاز را کاهش دهد.

---

1. مفهوم اجرای کانتینرها با کاربرهای غیر ریشه

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

---

2. تنظیمات برای اجرای کانتینرها با کاربر غیر ریشه

برای اطمینان از اجرای کانتینرها با کاربرهای غیر ریشه، باید تنظیمات securityContext را در فایل YAML کانتینر یا Pod خود پیکربندی کنید. در این تنظیمات، شما می‌توانید کاربر و گروه خاصی را برای کانتینر تعریف کنید.

1. استفاده از تنظیمات runAsUser و runAsGroup

با استفاده از runAsUser می‌توانیم کاربر خاصی را برای اجرای کانتینر مشخص کنیم. همچنین، از runAsGroup برای تنظیم گروه خاص برای کانتینر استفاده می‌شود.

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

apiVersion: v1
kind: Pod
metadata:
  name: non-root-pod
spec:
  containers:
    - name: non-root-container
      image: example-image
      securityContext:
        runAsUser: 1001
        runAsGroup: 1001
        allowPrivilegeEscalation: false

در اینجا:

• runAsUser: 1001 مشخص می‌کند که کانتینر باید با کاربر ID (UID) 1001 اجرا شود.
• runAsGroup: 1001 به کانتینر اعلام می‌کند که گروه ID (GID) 1001 باید برای این کانتینر استفاده شود.
• allowPrivilegeEscalation: false مشخص می‌کند که کانتینر اجازه ارتقاء امتیازات (privilege escalation) را ندارد.

2. استفاده از تنظیمات runAsNonRoot

برای اطمینان از اینکه کانتینر حتماً با کاربر غیر ریشه اجرا می‌شود، می‌توانیم از تنظیم runAsNonRoot استفاده کنیم. این تنظیم اطمینان می‌دهد که کانتینر نمی‌تواند به‌عنوان کاربر ریشه اجرا شود.

apiVersion: v1
kind: Pod
metadata:
  name: non-root-pod
spec:
  containers:
    - name: non-root-container
      image: example-image
      securityContext:
        runAsNonRoot: true
        runAsUser: 1001
        runAsGroup: 1001

در اینجا:

• runAsNonRoot: true این اطمینان را می‌دهد که کانتینر تنها با یک کاربر غیر ریشه اجرا می‌شود. اگر runAsUser به‌طور پیش‌فرض به کاربر ریشه (UID 0) تنظیم شده باشد، Kubernetes کانتینر را نمی‌سازد.

---

3. مزایای اجرای کانتینرها با کاربرهای غیر ریشه

اجرای کانتینرها با کاربرهای غیر ریشه مزایای قابل توجهی دارد:

• کاهش آسیب‌پذیری‌ها: اگر یک مهاجم موفق به نفوذ به یک کانتینر شود، دسترسی‌های او محدود به کاربر غیر ریشه خواهد بود. این بدان معناست که او نمی‌تواند تغییرات عمده‌ای در سیستم ایجاد کند یا به منابع حساس دسترسی داشته باشد.
• محافظت در برابر حملات Rootkit: اجرای کانتینرها به‌عنوان کاربر غیر ریشه به کاهش احتمال نصب بدافزارهای سطح ریشه (Rootkit) کمک می‌کند. حتی اگر مهاجم به کانتینر دسترسی پیدا کند، نمی‌تواند به سطح ریشه دست یابد.
• مطابقت با بهترین شیوه‌های امنیتی: اجرای کانتینرها با کاربرهای غیر ریشه بخشی از بهترین شیوه‌های امنیتی است که توسط استانداردهای مختلف مانند CIS Benchmarks توصیه شده است.

---

4. چالش‌ها و محدودیت‌ها

اگرچه اجرای کانتینرها با کاربرهای غیر ریشه می‌تواند امنیت را افزایش دهد، اما در برخی مواقع ممکن است باعث بروز مشکلاتی در اجرای برنامه‌ها و سرویس‌ها شود:

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

---

5. بررسی وضعیت اجرای کانتینر با کاربر غیر ریشه

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

kubectl get pod non-root-pod -o yaml

این دستور اطلاعات مربوط به Pod را نمایش می‌دهد. در بخش securityContext باید اطمینان حاصل کنید که تنظیمات runAsUser و runAsNonRoot به‌درستی اعمال شده است.

---

جمع بندی

اجرای کانتینرها با کاربرهای غیر ریشه یکی از اقدامات امنیتی حیاتی در Kubernetes است. این کار به شما این اطمینان را می‌دهد که حتی در صورت نفوذ یک مهاجم به کانتینر، او نمی‌تواند دسترسی‌های ریشه را به‌دست آورد و تغییرات غیرمجاز در سیستم اعمال کند. با استفاده از تنظیمات securityContext مانند runAsUser، runAsGroup و runAsNonRoot می‌توانید کانتینرهای خود را با کاربران غیر ریشه اجرا کرده و امنیت سیستم‌های خود را به‌طور قابل‌توجهی افزایش دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تنظیم قابلیت‌های Linux (Linux Capabilities) برای محدود سازی دسترسی” subtitle=”توضیحات کامل”]در Kubernetes، استفاده از Linux Capabilities به‌عنوان یک ابزار مهم برای محدودسازی دسترسی‌های سیستمی و ارتقاء امنیت کانتینرها مطرح می‌شود. Linux Capabilities به سیستم‌عامل Linux این امکان را می‌دهند که دسترسی‌های خاصی را به برنامه‌ها و کانتینرها اختصاص دهد بدون اینکه نیاز به دسترسی ریشه (root) داشته باشند. به عبارت دیگر، با استفاده از این قابلیت‌ها می‌توانیم برای هر کانتینر مجموعه‌ای از عملیات خاص سیستم‌عامل را تعیین کنیم و از اجرای آنها با دسترسی‌های غیرضروری جلوگیری کنیم.

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

---

1. مفهوم Linux Capabilities

در لینوکس، به‌طور پیش‌فرض، فرایندها برای انجام اکثر عملیات‌ها نیاز به دسترسی ریشه دارند. اما Linux Capabilities این امکان را فراهم می‌کنند که این دسترسی‌ها به قسمت‌های خاص سیستم‌عامل برای فرایندهای مختلف تقسیم شوند. به این ترتیب، به جای اعطای دسترسی ریشه (UID 0)، می‌توانیم به فرایندها فقط قابلیت‌هایی را بدهیم که برای عملکرد آنها ضروری است.

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

---

2. تنظیم Linux Capabilities در Kubernetes

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

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

• add: برای افزودن قابلیت‌های جدید به کانتینر.
• drop: برای حذف قابلیت‌های غیرضروری از کانتینر.

مثال 1: اضافه کردن قابلیت‌های خاص به یک کانتینر

در مثال زیر، قابلیت NET_ADMIN که به فرایندها اجازه تغییر تنظیمات شبکه را می‌دهد، به کانتینر اضافه می‌شود.

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-capabilities
spec:
  containers:
    - name: container-with-capabilities
      image: example-image
      securityContext:
        capabilities:
          add:
            - NET_ADMIN

در اینجا:

• add به کانتینر این امکان را می‌دهد که قابلیت NET_ADMIN را به دست آورد و به‌طور خاص تنظیمات شبکه را تغییر دهد.

مثال 2: حذف قابلیت‌های خاص از یک کانتینر

در این مثال، قابلیت CHOWN که به فرایندها اجازه تغییر مالکیت فایل‌ها را می‌دهد، از کانتینر حذف می‌شود.

apiVersion: v1
kind: Pod
metadata:
  name: pod-without-capabilities
spec:
  containers:
    - name: container-without-capabilities
      image: example-image
      securityContext:
        capabilities:
          drop:
            - CHOWN

در اینجا:

• drop برای حذف قابلیت CHOWN استفاده می‌شود، که به این معنی است که کانتینر قادر به تغییر مالکیت فایل‌ها نخواهد بود.

---

3. استفاده از Linux Capabilities برای محدودسازی دسترسی

با استفاده از Linux Capabilities، می‌توانیم به‌طور دقیق‌تر و جزئی‌تر دسترسی‌های مختلف به منابع سیستم را محدود کنیم. به‌طور مثال، به‌جای این که اجازه بدهیم کانتینر به‌طور کامل به تنظیمات شبکه، دسترسی ریشه، یا فرایندهای حساس دسترسی داشته باشد، می‌توانیم فقط قابلیت‌های ضروری را اضافه کنیم.

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

• NET_ADMIN: به کانتینر این اجازه را می‌دهد که تنظیمات شبکه را تغییر دهد.
• SYS_TIME: به کانتینر این امکان را می‌دهد که زمان سیستم را تغییر دهد.
• CHOWN: به کانتینر این اجازه را می‌دهد که مالکیت فایل‌ها را تغییر دهد.
• DAC_OVERRIDE: به کانتینر این امکان را می‌دهد که از دسترسی‌های کنترل شده سیستم‌فایل عبور کند.
• SETUID: به کانتینر این اجازه را می‌دهد که شناسه کاربری (UID) خود را تغییر دهد.

با افزودن یا حذف این قابلیت‌ها، می‌توانیم دسترسی‌های کانتینر را دقیقا طبق نیاز برنامه تنظیم کنیم.

---

4. بررسی وضعیت قابلیت‌ها

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

kubectl describe pod <pod-name>

این دستور اطلاعاتی در مورد Pod و کانتینرها شامل securityContext و قابلیت‌های تنظیم‌شده نمایش می‌دهد.

---

5. مزایای استفاده از Linux Capabilities

استفاده از Linux Capabilities برای محدودسازی دسترسی‌ها مزایای زیادی دارد:

• کاهش سطح حمله: با حذف قابلیت‌های غیرضروری از کانتینرها، حملات به‌طور قابل‌توجهی کاهش می‌یابند.
• کاهش نیاز به دسترسی ریشه: به‌جای اعطای دسترسی ریشه به کانتینرها، می‌توان فقط قابلیت‌های خاص و ضروری را تنظیم کرد که این باعث امنیت بیشتر می‌شود.
• استفاده بهینه از منابع: با استفاده از Linux Capabilities می‌توانیم دقیقاً مشخص کنیم که هر کانتینر چه قابلیت‌هایی نیاز دارد و از تخصیص منابع به‌طور غیرضروری جلوگیری کنیم.

---

جمع بندی

تنظیم قابلیت‌های لینوکس (Linux Capabilities) در Kubernetes ابزار مهمی برای افزایش امنیت کانتینرها و محدودسازی دسترسی‌ها است. با استفاده از تنظیمات securityContext در Kubernetes، می‌توانیم به‌طور دقیق مشخص کنیم که کدام قابلیت‌های سیستمی برای هر کانتینر ضروری هستند و از اعطای دسترسی‌های اضافی جلوگیری کنیم. این رویکرد به کاهش خطرات امنیتی و محافظت از سیستم در برابر تهدیدات مختلف کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson title=”Pod Security Standards (PSS):”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”معرفی استانداردهای امنیتی Pod” subtitle=”توضیحات کامل”]در دنیای Kubernetes، امنیت یکی از مسائل بسیار مهم است که باید در تمام سطوح، از جمله Pods، در نظر گرفته شود. Pods در Kubernetes واحد اجرایی است که یک یا چند کانتینر را در خود جای می‌دهد و منابع مشترک را با هم به اشتراک می‌گذارند. هرچه امنیت Pods بیشتر تأمین شود، خطرات ناشی از حملات و نفوذها کاهش می‌یابد.

در این بخش، به معرفی استانداردهای امنیتی مهم برای Pods خواهیم پرداخت که باید برای ایمن‌سازی محیط Kubernetes رعایت شوند. رعایت این استانداردها می‌تواند به بهبود امنیت محیط و کاهش ریسک‌های موجود در سیستم کمک کند.

---

1. اجرای کانتینرها با کاربران غیر ریشه

یکی از مهم‌ترین استانداردهای امنیتی، اجرای کانتینرها با کاربر غیر ریشه است. همانطور که قبلاً ذکر شد، استفاده از کاربر ریشه (root) در کانتینرها می‌تواند خطرات امنیتی به همراه داشته باشد. به‌طور کلی، استفاده از کاربران غیر ریشه (Non-Root) در کانتینرها برای به حداقل رساندن ریسک‌های امنیتی ضروری است.

برای اطمینان از اجرای کانتینرها با کاربر غیر ریشه، می‌توان از تنظیمات runAsUser و runAsNonRoot در securityContext استفاده کرد.

apiVersion: v1
kind: Pod
metadata:
  name: non-root-pod
spec:
  containers:
    - name: non-root-container
      image: example-image
      securityContext:
        runAsUser: 1000
        runAsNonRoot: true

این پیکربندی تضمین می‌کند که کانتینر تحت کاربر غیر ریشه اجرا شود و در صورتی که شناسه کاربری ریشه (UID 0) باشد، کانتینر اجرا نخواهد شد.

---

2. محدود کردن دسترسی به سیستم‌فایل‌ها (Read-Only Root FileSystem)

یکی دیگر از استانداردهای امنیتی مهم، استفاده از سیستم‌فایل فقط خواندنی (Read-Only Root FileSystem) برای کانتینرها است. با این کار، حتی اگر یک حمله موفق به کانتینر وارد شود، مهاجم نمی‌تواند به سیستم‌فایل‌های کانتینر تغییرات وارد کند.

برای تنظیم این ویژگی، می‌توان از گزینه readOnlyRootFilesystem در securityContext استفاده کرد.

apiVersion: v1
kind: Pod
metadata:
  name: readonly-pod
spec:
  containers:
    - name: readonly-container
      image: example-image
      securityContext:
        readOnlyRootFilesystem: true

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

---

3. استفاده از Network Policies

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

برای ایجاد یک Network Policy، می‌توان از ساختار YAML مشابه زیر استفاده کرد:

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

در این مثال:

• ترافیک ورودی (ingress) فقط از Pods با برچسب app: frontend به Pods با برچسب app: backend اجازه داده می‌شود.
• سایر ترافیک‌های ورودی به Pods با برچسب app: backend مسدود می‌شوند.

---

4. استفاده از Pod Security Policies (PSP)

Pod Security Policies (PSP) یکی دیگر از ابزارهای امنیتی Kubernetes است که به شما این امکان را می‌دهد که قوانین امنیتی برای Pods تعریف کنید. PSP امکان کنترل تنظیمات امنیتی مانند استفاده از کاربران غیر ریشه، قابلیت‌های لینوکس، محدودیت‌های سیستم‌فایل و موارد دیگر را فراهم می‌آورد.

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

apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted-psp
spec:
  runAsUser:
    rule: 'MustRunAsNonRoot'
  seLinux:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  volumes:
    - 'emptyDir'
    - 'configMap'

در این مثال:

• تنظیم runAsUser: MustRunAsNonRoot به‌وضوح می‌گوید که فقط کاربران غیر ریشه می‌توانند کانتینرها را اجرا کنند.
• محدودیت‌هایی برای انواع مختلف Volume‌ها مانند emptyDir و configMap نیز تعیین شده است.

---

5. محدودسازی قابلیت‌های لینوکس (Linux Capabilities)

یکی از استانداردهای امنیتی مهم، محدودسازی قابلیت‌های لینوکس برای هر کانتینر است. لینوکس برای هر فرایند مجموعه‌ای از قابلیت‌ها (Capabilities) را تعریف کرده است که به آن اجازه می‌دهد تا دسترسی خاصی به سیستم‌عامل پیدا کند. برای مثال، یک فرایند می‌تواند دسترسی به تغییر زمان سیستم یا تغییرات در تنظیمات شبکه داشته باشد.

در Kubernetes، می‌توانیم با استفاده از securityContext، قابلیت‌های لینوکس را برای هر کانتینر محدود کنیم.

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-limited-capabilities
spec:
  containers:
    - name: container-with-limited-caps
      image: example-image
      securityContext:
        capabilities:
          drop:
            - ALL

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

---

6. محدود کردن منابع و استفاده از Resource Requests & Limits

یکی از شیوه‌های امنیتی در Kubernetes، محدود کردن منابع مورد استفاده کانتینرها است. تنظیمات requests و limits به Kubernetes این امکان را می‌دهند که منابع مورد نیاز برای کانتینرها را مشخص کرده و محدود کند.

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-resource-limits
spec:
  containers:
    - name: container-with-limits
      image: example-image
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

در اینجا:

• requests: میزان حداقل منابع مورد نیاز کانتینر را مشخص می‌کند.
• limits: بیشترین میزان منابعی که کانتینر می‌تواند استفاده کند را محدود می‌کند.

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

---

جمع بندی

رعایت استانداردهای امنیتی برای Pods در Kubernetes یکی از گام‌های حیاتی در ایمن‌سازی زیرساخت‌های کانتینری است. اجرای کانتینرها با کاربران غیر ریشه، محدودسازی دسترسی به سیستم‌فایل‌ها، استفاده از Network Policies، اعمال Pod Security Policies، محدودسازی قابلیت‌های لینوکس و تنظیمات منابع، همگی از استانداردهای کلیدی امنیتی هستند که می‌توانند به‌طور قابل‌توجهی امنیت محیط Kubernetes را افزایش دهند. این استانداردها باعث کاهش ریسک‌های امنیتی، ارتقاء ایمنی سیستم‌ها و جلوگیری از حملات و نفوذهای احتمالی خواهند شد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از PodSecurityPolicy (Deprecated) و جایگزین‌های آن” subtitle=”توضیحات کامل”]PodSecurityPolicy (PSP) ابزاری در Kubernetes است که به مدیران سیستم این امکان را می‌دهد تا محدودیت‌های امنیتی خاصی را برای Pods تنظیم کنند. این ابزار اجازه می‌دهد که سیاست‌های مختلفی مانند استفاده از کاربر ریشه، امکان mount کردن سیستم فایل‌ها، و تنظیمات خاص دیگر را بر اساس نیاز تنظیم کرد. با این حال، PodSecurityPolicy از نسخه 1.21 Kubernetes به‌طور رسمی به حالت “Deprecated” درآمده و در نسخه‌های بعدی این ویژگی حذف خواهد شد. به همین دلیل، لازم است که آشنایی کامل با جایگزین‌های جدید این ابزار داشته باشیم.

ویژگی‌های PodSecurityPolicy (PSP)

PodSecurityPolicy مجموعه‌ای از سیاست‌های امنیتی را برای کنترل رفتار Pods در Kubernetes تعیین می‌کند. این سیاست‌ها به طور خاص برای افزایش امنیت در سطح Pod و جلوگیری از دسترسی‌های غیرمجاز به منابع سیستم طراحی شده‌اند. برخی از قابلیت‌های PSP عبارت‌اند از:

1. اجازه استفاده از کاربر ریشه (Root User): شما می‌توانید مشخص کنید که Pods می‌توانند به‌طور غیرمستقیم یا مستقیم از کاربر ریشه استفاده کنند یا خیر.
2. محدودیت‌های Mount کردن فایل سیستم: با استفاده از PSP می‌توانید دسترسی به برخی از پوشه‌های سیستمی مثل /proc یا /dev را محدود کنید.
3. محدود کردن Capabilities: PodSecurityPolicy به شما این امکان را می‌دهد که قابلیت‌های خاص سیستم عامل را برای Pods محدود کنید.
4. اجازه دادن به privilege escalation: شما می‌توانید مانع از privilege escalation در Pods شوید و یا تنظیم کنید که این قابلیت به‌طور محدود فعال باشد.

مشکلات و محدودیت‌های PodSecurityPolicy

با وجود اینکه PodSecurityPolicy ابزار مفیدی برای مدیریت امنیت در Kubernetes بود، مشکلاتی نیز داشت که باعث شده استفاده از آن به طور گسترده‌تری در نظر گرفته نشود:

1. پیچیدگی و انعطاف‌پذیری محدود: تنظیمات PSP نسبتاً پیچیده بودند و در برخی موارد نمی‌توانستند نیازهای پیچیده امنیتی را به‌طور کامل پوشش دهند.
2. مدیریت Policy‌ها: تنظیم و مدیریت Policy‌های پیچیده برای Pods در بسیاری از موارد دشوار و زمان‌بر بود.
3. عدم توانایی در مدیریت سطوح مختلف امنیتی: برخی از سیاست‌های امنیتی که کاربران درخواست می‌کردند، به‌طور پیش‌فرض در PSP وجود نداشتند و باید آنها را به صورت دستی و پیچیده پیاده‌سازی می‌کردند.

جایگزین‌های PodSecurityPolicy

با توجه به اینکه PodSecurityPolicy به‌طور رسمی در نسخه 1.21 Kubernetes deprecated شده و از نسخه‌های بعدی حذف خواهد شد، Kubernetes تیم‌هایی را برای توسعه جایگزین‌های جدید معرفی کرده است که به‌طور بهتری می‌توانند امنیت Pods را مدیریت کنند.

1. PodSecurity Admission (PSA)

یک جایگزین اصلی برای PodSecurityPolicy، PodSecurity Admission است که از نسخه 1.22 Kubernetes به عنوان یک feature آزمایشی ارائه شد. PodSecurity Admission به‌طور خاص برای جایگزینی PSP طراحی شده است و به شما امکان می‌دهد تا سیاست‌های امنیتی را برای Pods به‌راحتی پیاده‌سازی کنید.

ویژگی‌های PodSecurity Admission:

• پیکربندی بر اساس سطح امنیتی: شما می‌توانید Pods را بر اساس سطح امنیتی به سه سطح مختلف تقسیم کنید:
  • privileged: دسترسی به تمام قابلیت‌ها و منابع.
  • baseline: حداقل نیازمندی‌های امنیتی.
  • restricted: محدودیت‌های شدید امنیتی.
• پیکربندی به‌صورت Namespace: PodSecurity Admission به شما این امکان را می‌دهد که سیاست‌های امنیتی را به‌طور خاص برای هر Namespace تنظیم کنید.

یک مثال از پیکربندی PodSecurity Admission برای یک Namespace به شکل زیر است:

apiVersion: policy/v1
kind: PodSecurity
metadata:
  name: pod-security-policy
  namespace: default
spec:
  enforce: baseline
  enforceVersion: v1.22.0
  audit: restricted
  auditVersion: v1.22.0
  warn: privileged
  warnVersion: v1.22.0

این پیکربندی نشان می‌دهد که در این Namespace از سیاست baseline برای اعمال محدودیت‌ها استفاده می‌شود، در حالی که برای گزارش وضعیت Pods از سطح restricted استفاده می‌کند.

2. OPA Gatekeeper

یکی دیگر از جایگزین‌های محبوب برای PodSecurityPolicy، استفاده از OPA Gatekeeper است. OPA (Open Policy Agent) Gatekeeper یک پروژه متن‌باز است که به شما این امکان را می‌دهد که سیاست‌های Kubernetes را با استفاده از زبان Rego تعریف کنید.

ویژگی‌های OPA Gatekeeper:

• پشتیبانی از سیاست‌های پیچیده‌تر: OPA Gatekeeper به شما امکان می‌دهد تا سیاست‌های امنیتی پیچیده‌تری را ایجاد و مدیریت کنید که دقیقاً متناسب با نیازهای خاص شما باشند.
• چک کردن وضعیت: این ابزار می‌تواند به طور مداوم وضعیت Pods و منابع دیگر را بررسی کرده و مطمئن شود که آنها با سیاست‌های تعیین‌شده مطابقت دارند.
• قابلیت استفاده از Auditing: OPA Gatekeeper قابلیت auditing را فراهم می‌کند تا بتوانید بررسی کنید که آیا سیاست‌ها به‌طور صحیح اعمال می‌شوند یا خیر.

یک مثال از پیکربندی OPA Gatekeeper برای محدود کردن Pods از کاربر ریشه (Root User) به شکل زیر است:

apiVersion: admission.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: opa-gatekeeper
webhooks:
  - name: policy.example.com
    rules:
      - operations: ["CREATE"]
        apiGroups: [""]
        apiVersions: ["v1"]
        resources: ["pods"]
    clientConfig:
      service:
        name: opa-gatekeeper
        namespace: default
        path: "/v1/admit"
      caBundle: <CA_BUNDLE>

3. Kubernetes PodSecurity Policies (PSP) through Third-Party Solutions

در برخی موارد، ممکن است شما بخواهید از راه‌حل‌های شخص ثالث برای مدیریت PodSecurity استفاده کنید. ابزارهایی مانند Calico یا Cilium می‌توانند به شما کمک کنند تا سیاست‌های امنیتی مورد نیاز خود را پیاده‌سازی کنید.

جمع بندی

PodSecurityPolicy به عنوان یک ابزار امنیتی مهم در Kubernetes برای مدیریت امنیت Pods، به‌طور رسمی به حالت deprecated درآمده و در آینده حذف خواهد شد. از آنجا که Kubernetes به سمت استانداردهای جدیدتری حرکت کرده است، PodSecurity Admission و OPA Gatekeeper به‌عنوان جایگزین‌های اصلی PSP مطرح شده‌اند. استفاده از این ابزارها امکان مدیریت دقیق‌تر و بهینه‌تر سیاست‌های امنیتی برای Pods را فراهم می‌کند. از آنجا که این ابزارها انعطاف‌پذیری بیشتری دارند، به‌راحتی می‌توانید سیاست‌های امنیتی خود را به طور دقیق‌تری پیاده‌سازی و مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. پیکربندی و استفاده از Network Policies”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف Network Policies برای محدود کردن ترافیک ورودی و خروجی” subtitle=”توضیحات کامل”]Network Policies در Kubernetes ابزاری هستند که به شما این امکان را می‌دهند تا نحوه ترافیک ورودی و خروجی بین Pods را کنترل و محدود کنید. به عبارت دیگر، می‌توانند مانند فایروال عمل کنند و مشخص کنند که کدام Pods اجازه دارند به یک Pod خاص دسترسی پیدا کنند یا از آن درخواست کنند. با استفاده از Network Policies، شما قادر خواهید بود تا امنیت شبکه را در Kubernetes به صورت دقیق‌تری تنظیم کنید و از حملات احتمالی مانند حملات DDoS یا دسترسی غیرمجاز جلوگیری کنید.

اصول اولیه Network Policies در Kubernetes

Network Policies به‌طور پیش‌فرض در Kubernetes غیرفعال هستند و برای استفاده از آنها باید CNI Plugin (مانند Calico یا Cilium) نصب و پیکربندی شود که از Network Policies پشتیبانی می‌کند.

یک Network Policy معمولاً شامل سه بخش اصلی است:

1. تعریف قوانین ترافیک ورودی (Ingress)
2. تعریف قوانین ترافیک خروجی (Egress)
3. پیکربندی Selector‌ها برای تعیین Pods هدف

بخش‌های مختلف یک Network Policy

یک Network Policy معمولاً شامل بخش‌های زیر است:

1. metadata:
   • name: نامی که برای سیاست تعریف می‌شود.
   • namespace: namespace‌ای که سیاست برای آن اعمال می‌شود.
2. spec:
   • podSelector: Pods که این سیاست روی آنها اعمال می‌شود. می‌توانید از label selectors برای انتخاب Pods استفاده کنید.
   • ingress: تنظیمات ترافیک ورودی برای Pods.
   • egress: تنظیمات ترافیک خروجی برای Pods.

نحوه تعریف Network Policy

در اینجا یک نمونه ساده از Network Policy برای محدود کردن ترافیک ورودی و خروجی آورده شده است.

1. محدود کردن ترافیک ورودی (Ingress) به یک Pod خاص

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-nginx-ingress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: frontend

در این مثال:

• این Network Policy ترافیک ورودی به Pods با لیبل app: nginx را محدود می‌کند.
• فقط Pods با لیبل app: frontend قادر خواهند بود به Pods با لیبل app: nginx دسترسی پیدا کنند.

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

حال فرض کنید می‌خواهید ترافیک خروجی از یک Pod خاص را محدود کنید.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-nginx-egress
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginx
  egress:
  - to:
    - podSelector:
        matchLabels:
          app: backend

در این مثال:

• این Network Policy ترافیک خروجی از Pods با لیبل app: nginx را محدود می‌کند.
• تنها Pods با لیبل app: backend می‌توانند مقصد ترافیک خروجی Pods nginx باشند.

3. استفاده از کدهای IP برای محدود کردن ترافیک

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-specific-ip
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: nginx
  ingress:
  - from:
    - ipBlock:
        cidr: 192.168.1.0/24

در این مثال:

• ترافیک ورودی به Pods با لیبل app: nginx فقط از IP‌های موجود در شبکه 192.168.1.0/24 مجاز است.

4. مسدود کردن تمامی ترافیک‌ها به جز موارد خاص

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all
  namespace: default
spec:
  podSelector: {}
  ingress: []
  egress: []

در این مثال:

• هیچ ترافیک ورودی یا خروجی برای Pods در این سیاست مجاز نیست مگر اینکه سیاست‌های دیگری برای ترافیک مشخص شده باشند.

---

ایجاد و اعمال Network Policies

برای ایجاد یک Network Policy، شما ابتدا باید فایل YAML مربوط به سیاست را بنویسید و سپس با استفاده از دستور kubectl apply آن را به Kubernetes اعمال کنید. برای مثال:

kubectl apply -f network-policy.yaml

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

kubectl get networkpolicy

---

نکات مهم در استفاده از Network Policies

1. پشتیبانی CNI Plugin: برای استفاده از Network Policies، باید از یک CNI plugin پشتیبانی‌کننده مثل Calico یا Cilium استفاده کنید.
2. پیش‌فرض‌ها: به طور پیش‌فرض، هیچ Network Policy در Kubernetes اعمال نمی‌شود و همه Pods به‌طور آزادانه می‌توانند با یکدیگر ارتباط برقرار کنند. باید خودتان سیاست‌های امنیتی مورد نظر را تنظیم کنید.
3. محدود کردن ترافیک با PodSelector: با استفاده از podSelector می‌توانید سیاست را برای Pods خاصی تنظیم کنید و فقط ترافیک به آن Pods را محدود کنید.
4. یادآوری قانون “Stateful”: Network Policies در Kubernetes به صورت “Stateless” عمل می‌کنند. یعنی پس از اعمال سیاست‌ها، تمام ترافیک‌های ورودی و خروجی کنترل خواهند شد و شما هیچ‌گونه امکان ذخیره‌سازی وضعیت ترافیک ندارید.

---

جمع بندی

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

مفهوم Network Policies

Network Policies در Kubernetes برای تعریف قوانین دسترسی به شبکه در سطح Pods استفاده می‌شوند. این قوانین می‌توانند ترافیک ورودی (Ingress) یا خروجی (Egress) را کنترل کرده و به شما این امکان را می‌دهند که از امنیت بیشتری برخوردار شوید. قوانین Network Policy به‌طور پیش‌فرض در Kubernetes غیر فعال هستند و برای فعال‌سازی آن‌ها نیاز به یک CNI (Container Network Interface) مانند Calico یا Cilium دارید که از Network Policies پشتیبانی کند.

اجزای یک Network Policy

یک Network Policy از چند بخش اصلی تشکیل می‌شود که به شما امکان می‌دهد قوانین مختلف را برای کنترل ترافیک بین Pods تعریف کنید:

1. Pod Selector:
   • به کمک این بخش، مشخص می‌کنید که کدام Pods باید تحت تاثیر این سیاست قرار بگیرند. می‌توانید از selectorهای مختلف استفاده کنید تا Pods خاصی را هدف قرار دهید.
2. Ingress:
   • این بخش ترافیک ورودی به Pod را مدیریت می‌کند. شما می‌توانید منابع خاصی را تعیین کنید که مجاز به ارسال درخواست به Pod هستند.
3. Egress:
   • این بخش برای کنترل ترافیک خروجی از Pod به کار می‌رود. می‌توانید مشخص کنید که Pods به کدام منابع اجازه ارسال ترافیک را دارند.
4. Ports:
   • این بخش برای تعیین پورت‌های مجاز استفاده می‌شود. به کمک آن می‌توانید مشخص کنید که چه پورت‌هایی برای دریافت یا ارسال ترافیک در دسترس هستند.
5. Policy Types:
   • این بخش مشخص می‌کند که آیا سیاست به‌طور خاص برای Ingress یا Egress اعمال خواهد شد یا برای هر دو.

نمونه‌ای از پیکربندی Network Policy

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

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-from-specific-label
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: trusted-app
    ports:
    - protocol: TCP
      port: 80
  policyTypes:
  - Ingress

توضیحات:

• این Network Policy برای Pods با برچسب app: my-app اعمال می‌شود.
• Ingress فقط از Pods با برچسب app: trusted-app و از پورت 80 مجاز است.
• نوع سیاست Ingress است، بنابراین فقط ترافیک ورودی کنترل می‌شود.

مدیریت ترافیک خروجی (Egress)

اگر بخواهید ترافیک خروجی از Pods را نیز محدود کنید، می‌توانید بخش egress را به Network Policy اضافه کنید. در اینجا یک مثال از محدود کردن ترافیک خروجی به یک آدرس IP خاص آورده شده است.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-egress-to-external
spec:
  podSelector:
    matchLabels:
      app: my-app
  egress:
  - to:
    - ipBlock:
        cidr: 203.0.113.0/24
    ports:
    - protocol: TCP
      port: 443
  policyTypes:
  - Egress

توضیحات:

• این سیاست به Pods با برچسب app: my-app اعمال می‌شود.
• Egress فقط به آدرس IPهای درون رنج 203.0.113.0/24 و پورت 443 اجازه ارسال ترافیک می‌دهد.
• نوع سیاست Egress است و فقط ترافیک خروجی از Pod را محدود می‌کند.

استفاده از Network Policy برای محدود کردن ترافیک بین Namespaces

در بسیاری از مواقع، ممکن است بخواهید ترافیک بین Namespaces مختلف را محدود کنید. به‌عنوان مثال، ممکن است بخواهید اجازه دهید که Pods در Namespace A فقط به Pods در Namespace B دسترسی داشته باشند. در اینجا یک مثال از پیکربندی Network Policy برای محدود کردن ترافیک بین Namespaces آورده شده است.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-namespace-b-traffic
  namespace: namespace-a
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          name: namespace-b
    ports:
    - protocol: TCP
      port: 8080
  policyTypes:
  - Ingress

توضیحات:

• این Network Policy برای Pods در Namespace namespace-a اعمال می‌شود.
• Ingress فقط از Pods در Namespace namespace-b مجاز است.
• پورت 8080 مجاز است.

Policy Types

Network Policy می‌تواند به یکی از دو نوع زیر باشد:

1. Ingress: این نوع سیاست‌ها برای کنترل ترافیک ورودی استفاده می‌شود.
2. Egress: این نوع سیاست‌ها برای کنترل ترافیک خروجی استفاده می‌شود.

در نهایت، Policy Types می‌توانند ترکیبی از هر دو باشند (یعنی هم Ingress و هم Egress).

جمع بندی

با استفاده از Network Policies در Kubernetes، می‌توانید کنترل دقیق‌تری بر ترافیک بین Pods و منابع دیگر داشته باشید. این ابزار به شما اجازه می‌دهد که قوانین پیچیده‌ای برای مدیریت ترافیک ورودی و خروجی ایجاد کنید و به این ترتیب، سطح امنیت و کنترل در شبکه Kubernetes خود را افزایش دهید. برای استفاده مؤثر از Network Policies باید یک CNI (Container Network Interface) که از آن‌ها پشتیبانی کند مانند Calico یا Cilium را پیاده‌سازی کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از Labels برای مدیریت ترافیک شبکه” subtitle=”توضیحات کامل”]در Kubernetes، یکی از ابزارهای پرکاربرد برای مدیریت و کنترل ترافیک شبکه بین Pods، استفاده از Labels است. Labels در Kubernetes ویژگی‌هایی هستند که به منابع (مثل Pods یا Services) اضافه می‌شوند و می‌توانند برای شناسایی، دسته‌بندی و مدیریت منابع استفاده شوند. این Labels به‌ویژه در پیاده‌سازی Network Policies برای محدودسازی ترافیک ورودی و خروجی از Pods اهمیت دارند.

تعریف Labels

Labels کلید-مقدار (key-value) هستند که به هر شیء Kubernetes (مثل Podها، Serviceها، ReplicaSetها، و غیره) نسبت داده می‌شوند. این Labels در اصل به‌عنوان ابزاری برای دسته‌بندی و جستجو در منابع مختلف Kubernetes استفاده می‌شوند.

برای مثال، می‌توان به هر Pod یک Label با نام app و مقدار frontend داد تا Pods مربوط به بخش‌های مختلف برنامه به‌راحتی از هم تمایز پیدا کنند.

استفاده از Labels در پیکربندی Network Policies

در Kubernetes، شما می‌توانید از Labels برای ایجاد Network Policies استفاده کنید تا ترافیک ورودی و خروجی بین Pods بر اساس ویژگی‌های مشترک آن‌ها محدود شود. به‌عنوان مثال، اگر بخواهید ترافیک شبکه را فقط برای Pods با Label خاصی (مثل role=backend) محدود کنید، می‌توانید از این ویژگی استفاده کنید.

مثال عملی از استفاده از Labels در Network Policies

در اینجا یک نمونه Network Policy برای محدود کردن ترافیک ورودی به Pods با Label role=frontend آورده شده است که فقط اجازه می‌دهد ترافیک از Pods با Label role=backend به آن‌ها برسد:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-frontend
spec:
  podSelector:
    matchLabels:
      role: frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend
  policyTypes:
  - Ingress

در این مثال:

• podSelector در بخش matchLabels Pods با Label role=frontend را انتخاب می‌کند.
• بخش ingress مشخص می‌کند که فقط Pods با Label role=backend می‌توانند ترافیک ورودی به Pods با Label role=frontend ارسال کنند.
• در نهایت، policyTypes: Ingress نشان می‌دهد که این سیاست فقط برای ترافیک ورودی اعمال می‌شود.

مشاهده و بررسی Labels

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

kubectl get pods --show-labels

این دستور لیستی از Pods را نمایش می‌دهد همراه با Labels مربوط به هرکدام.

افزودن یا تغییر Labels به Pods

برای افزودن یا تغییر Labels به یک Pod خاص، می‌توانید از دستور زیر استفاده کنید:

kubectl label pods <pod-name> role=frontend

این دستور Label جدید role=frontend را به Pod مورد نظر اضافه می‌کند.

جمع بندی

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

شرایط مثال

فرض کنید در یک محیط Kubernetes، دو نوع Pod داریم:

1. Pods که Label role=frontend دارند.
2. Pods که Label role=backend دارند.

ما می‌خواهیم ترافیک ورودی به Pods با Label role=frontend را فقط از Pods با Label role=backend مجاز کنیم. سایر ترافیک‌ها باید مسدود شوند.

مثال عملی از ایجاد Network Policy

برای ایجاد این سیاست، یک Network Policy تعریف می‌کنیم که ترافیک ورودی به Pods با Label role=frontend را محدود به Pods با Label role=backend می‌کند و ترافیک غیرمجاز از منابع دیگر را مسدود می‌کند.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-backend-to-frontend
spec:
  podSelector:
    matchLabels:
      role: frontend  # انتخاب Pods با Label role=frontend
  ingress:
  - from:
    - podSelector:
        matchLabels:
          role: backend  # فقط Pods با Label role=backend می‌توانند ترافیک ورودی ارسال کنند
  policyTypes:
  - Ingress  # فقط ترافیک ورودی را محدود می‌کنیم

در این مثال:

• podSelector در بخش matchLabels Pods با Label role=frontend را انتخاب می‌کند. این بدین معنی است که این Network Policy فقط برای Pods با Label role=frontend اعمال خواهد شد.
• بخش ingress مشخص می‌کند که فقط ترافیک ورودی از Pods با Label role=backend به Pods با Label role=frontend مجاز است.
• policyTypes: Ingress نشان می‌دهد که این سیاست فقط برای ترافیک ورودی اعمال می‌شود و ترافیک خروجی تحت تأثیر قرار نخواهد گرفت.

نحوه اعمال Network Policy

برای اعمال این Network Policy در کلاستر Kubernetes، می‌توانید فایل YAML فوق را در کلاستر خود ایجاد کرده و آن را با استفاده از دستور kubectl اعمال کنید:

1. ابتدا فایل YAML را ذخیره کنید. به‌عنوان مثال، فایل را به نام allow-backend-to-frontend-policy.yaml ذخیره کنید.
2. سپس، از دستور زیر برای ایجاد Network Policy استفاده کنید:

kubectl apply -f allow-backend-to-frontend-policy.yaml

بررسی و مشاهده وضعیت Network Policy

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

kubectl get networkpolicies

این دستور تمام Network Policies موجود در کلاستر شما را نمایش می‌دهد. همچنین می‌توانید جزئیات بیشتری از یک Network Policy خاص را با دستور زیر مشاهده کنید:

kubectl describe networkpolicy allow-backend-to-frontend

جمع بندی

استفاده از Network Policy برای مسدود کردن ترافیک غیرمجاز یکی از بهترین روش‌ها برای مدیریت امنیت در Kubernetes است. با استفاده از این ابزار می‌توانید به‌طور دقیق‌تری کنترل کنید که کدام منابع مجاز به ارسال یا دریافت ترافیک از Pods خاصی باشند و ترافیک غیرمجاز را به‌راحتی مسدود کنید. این کار به شما این امکان را می‌دهد که سیاست‌های امنیتی خود را به‌طور مؤثر پیاده‌سازی کنید و امنیت کلاستر Kubernetes خود را بهبود بخشید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. ذخیره‌سازی امن اطلاعات حساس با Secrets”][/cdb_course_lesson][cdb_course_lesson title=”Secrets در Kubernetes:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف و انواع Secrets: Generic و Docker Registry” subtitle=”توضیحات کامل”]Secretsها در Kubernetes ابزارهایی هستند که برای ذخیره و مدیریت داده‌های حساس مانند رمز عبور، توکن‌ها، کلیدهای API و گواهینامه‌ها به‌کار می‌روند. این اطلاعات معمولاً نمی‌خواهند در قالب plain text در فایل‌های کانفیگ یا کد منبع ذخیره شوند، بنابراین Kubernetes از Secrets برای نگهداری امن این داده‌ها استفاده می‌کند. به‌طور کلی، Secrets به شما این امکان را می‌دهند که اطلاعات حساس را به صورت ایمن ذخیره و به Pods یا سایر منابع در کلاستر Kubernetes تحویل دهید.

Kubernetes از دو نوع Secrets پشتیبانی می‌کند که در این بخش به معرفی و بررسی آن‌ها خواهیم پرداخت:

1. Generic Secret
2. Docker Registry Secret

1. Generic Secret

Generic Secrets رایج‌ترین نوع Secrets در Kubernetes هستند. این نوع Secrets برای ذخیره‌سازی انواع مختلف داده‌ها استفاده می‌شود، از جمله رمزهای عبور، کلیدهای API، گواهینامه‌ها و سایر داده‌های حساس. این اطلاعات می‌توانند به‌طور مستقیم در Kubernetes به‌صورت Base64-encoded ذخیره شوند.

نحوه ایجاد Generic Secret

برای ایجاد یک Generic Secret در Kubernetes، می‌توانید از دستور kubectl استفاده کنید یا یک فایل YAML ایجاد کنید. در اینجا، به‌صورت کماندی و YAML روش ایجاد یک Generic Secret را توضیح می‌دهیم.

1. ایجاد Generic Secret با استفاده از دستور kubectl:

kubectl create secret generic my-secret \
  --from-literal=username=myuser \
  --from-literal=password=mypassword

در این دستور:

• my-secret نام Secret است.
• --from-literal برای اضافه کردن مقادیر به Secret استفاده می‌شود.

2. ایجاد Generic Secret با استفاده از فایل YAML:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: bXl1c2Vy  # این مقدار Base64-encoded است
  password: bXlwYXNzd29yZA==  # این مقدار نیز Base64-encoded است

در اینجا:

• data شامل کلیدهای مخفی (مثلاً username و password) به‌صورت Base64-encoded است.
• type: Opaque نشان می‌دهد که Secret از نوع عمومی است و هیچ نوع خاصی ندارد.

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

kubectl apply -f my-secret.yaml

2. Docker Registry Secret

Docker Registry Secrets به‌طور خاص برای ذخیره‌سازی اطلاعات ورود به Docker Registry (مانند Docker Hub یا سایر ریجستری‌های خصوصی) استفاده می‌شود. این نوع Secret معمولاً برای تأمین امنیت هنگام کشیدن تصاویر از Docker Registry به‌کار می‌رود.

برای ایجاد یک Docker Registry Secret، باید از دستور kubectl create secret docker-registry استفاده کنید و اطلاعات ورود خود به Docker Registry را وارد کنید.

نحوه ایجاد Docker Registry Secret

1. ایجاد Docker Registry Secret با استفاده از دستور kubectl:

kubectl create secret docker-registry my-docker-secret \
  --docker-server=https://index.docker.io/v1/ \
  --docker-username=myuser \
  --docker-password=mypassword \
  --docker-email=myemail@example.com

در این دستور:

• my-docker-secret نام Secret است.
• --docker-server آدرس Docker Registry است.
• --docker-username نام کاربری شما در Docker Registry.
• --docker-password رمز عبور شما برای Docker Registry.
• --docker-email ایمیل شما در Docker Registry.

2. ایجاد Docker Registry Secret با استفاده از فایل YAML:

apiVersion: v1
kind: Secret
metadata:
  name: my-docker-secret
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: <Base64-encoded Docker config file>

در اینجا:

• type: kubernetes.io/dockerconfigjson نوع Secret را مشخص می‌کند که برای Docker Registry است.
• .dockerconfigjson شامل اطلاعات رمزنگاری‌شده از فایل تنظیمات Docker Registry است که باید Base64-encoded شود.

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

kubectl apply -f my-docker-secret.yaml

جمع بندی

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

• Generic Secret: برای ذخیره انواع مختلف داده‌های حساس مانند رمز عبور و کلیدهای API.
• Docker Registry Secret: برای ذخیره اطلاعات ورود به Docker Registry به‌منظور استفاده از آن در هنگام کشیدن تصاویر Docker.

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

کوبرنتیز[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ذخیره‌سازی اطلاعات حساس مانند رمز عبور، توکن و گواهینامه‌ها” subtitle=”توضیحات کامل”]در هر سیستم توزیع‌شده‌ای که از Kubernetes برای مدیریت منابع خود استفاده می‌کند، یکی از چالش‌های اصلی حفظ امنیت و حفاظت از اطلاعات حساس مانند رمزهای عبور، توکن‌ها و گواهینامه‌ها است. در Kubernetes، اطلاعات حساس باید به‌طور امن ذخیره و مدیریت شوند تا از دسترسی‌های غیرمجاز جلوگیری شود. در این زمینه، Secrets ابزاری کلیدی هستند که به‌طور ویژه برای ذخیره‌سازی اطلاعات حساس طراحی شده‌اند.

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

1. ذخیره‌سازی رمز عبور (Password)

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

ذخیره‌سازی رمز عبور با استفاده از Generic Secret

1. ایجاد یک Secret برای رمز عبور با استفاده از kubectl:

kubectl create secret generic db-password --from-literal=password='yourpassword'

در این دستور:

• db-password نام Secret است.
• --from-literal برای اضافه کردن مقادیر به Secret استفاده می‌شود. در اینجا، رمز عبور yourpassword به‌صورت مستقیم وارد می‌شود.

2. ایجاد Secret با فایل YAML:

apiVersion: v1
kind: Secret
metadata:
  name: db-password
type: Opaque
data:
  password: eW91cnBhc3N3b3Jk  # رمز عبور Base64-encoded است

در اینجا، password باید به‌صورت Base64-encoded وارد شود. برای دریافت مقدار Base64 از رمز عبور، می‌توانید از ابزارهایی مانند echo یا base64 در سیستم خود استفاده کنید.

echo -n 'yourpassword' | base64

2. ذخیره‌سازی توکن‌ها (Tokens)

توکن‌ها معمولاً برای احراز هویت یا مجوز در سیستم‌های مختلف مانند API‌ها، سرویس‌های ثالث و حتی Kubernetes به کار می‌روند. برای ذخیره‌سازی این توکن‌ها، از Secrets مشابه رمز عبور استفاده می‌شود.

ذخیره‌سازی توکن با استفاده از Generic Secret

1. ایجاد Secret برای توکن API با استفاده از kubectl:

kubectl create secret generic api-token --from-literal=token='yourtoken'

در اینجا، api-token نام Secret است و yourtoken توکن شماست.

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

apiVersion: v1
kind: Secret
metadata:
  name: api-token
type: Opaque
data:
  token: eW91cnRva2Vu  # توکن Base64-encoded است

مجدداً برای استفاده از توکن به‌صورت Base64-encoded، می‌توانید از دستور base64 استفاده کنید.

3. ذخیره‌سازی گواهینامه‌ها (Certificates)

گواهینامه‌ها (Certificates) برای رمزنگاری اطلاعات و احراز هویت در بسیاری از پروتکل‌ها و سرویس‌ها مانند HTTPS یا TLS مورد استفاده قرار می‌گیرند. این اطلاعات نیز باید به‌صورت امن ذخیره و در دسترس قرار گیرند.

ذخیره‌سازی گواهینامه‌ها با استفاده از Generic Secret

1. ایجاد Secret برای گواهینامه‌ها با استفاده از kubectl:

kubectl create secret generic tls-certificate --from-file=tls.crt=/path/to/tls.crt --from-file=tls.key=/path/to/tls.key

در اینجا:

• tls.crt گواهینامه عمومی (public certificate) است.
• tls.key کلید خصوصی (private key) است.

2. ایجاد Secret برای گواهینامه‌ها با استفاده از فایل YAML:

apiVersion: v1
kind: Secret
metadata:
  name: tls-certificate
type: kubernetes.io/tls
data:
  tls.crt: <Base64-encoded certificate>
  tls.key: <Base64-encoded private key>

برای تبدیل گواهینامه‌ها و کلیدهای خصوصی به Base64، از ابزار base64 در سیستم خود استفاده کنید.

4. مدیریت و استفاده از Secrets در Pods

پس از ایجاد Secrets برای اطلاعات حساس مانند رمز عبور، توکن‌ها و گواهینامه‌ها، می‌توانید آن‌ها را به‌راحتی در Pods خود استفاده کنید. برای این کار، از envFrom یا volume می‌توان برای استخراج مقادیر از Secrets و قرار دادن آن‌ها در محیط کانتینرها یا فایل‌ها استفاده کرد.

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

apiVersion: v1
kind: Pod
metadata:
  name: secret-example
spec:
  containers:
    - name: app-container
      image: yourimage
      envFrom:
        - secretRef:
            name: db-password

در اینجا، Secret db-password به‌عنوان متغیر محیطی به کانتینر وارد می‌شود و شما می‌توانید از آن در برنامه خود استفاده کنید.

استفاده از Secret به‌عنوان volume در Pod:

apiVersion: v1
kind: Pod
metadata:
  name: secret-volume-example
spec:
  containers:
    - name: app-container
      image: yourimage
      volumeMounts:
        - name: secret-volume
          mountPath: "/etc/secret-volume"
  volumes:
    - name: secret-volume
      secret:
        secretName: db-password

در اینجا، Secret db-password به‌عنوان یک volume در /etc/secret-volume در دسترس قرار می‌گیرد.

جمع بندی

در Kubernetes، برای ذخیره‌سازی اطلاعات حساس مانند رمز عبور، توکن‌ها و گواهینامه‌ها از Secrets استفاده می‌شود. این ابزار به شما این امکان را می‌دهد که اطلاعات حساس را به‌صورت امن ذخیره و به Pods یا سایر منابع Kubernetes تحویل دهید. همچنین، Kubernetes از انواع مختلفی از Secrets پشتیبانی می‌کند که از جمله آن‌ها می‌توان به Generic Secret و TLS Secret اشاره کرد. برای استفاده از این اطلاعات در Pods، می‌توانید آن‌ها را به‌عنوان متغیر محیطی یا volume به کانتینرها تزریق کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از Secrets در Pods و کانتینرها” subtitle=”توضیحات کامل”]در کوبرنتیز، Secrets به‌منظور ذخیره‌سازی اطلاعات حساس مانند رمز عبور، توکن‌ها، کلیدهای API و گواهینامه‌ها استفاده می‌شود. به‌طور معمول، این اطلاعات برای احراز هویت و دسترسی به منابع خارجی یا سرویس‌های مختلف به کار می‌روند. با استفاده از Secrets در Kubernetes، می‌توانید این داده‌ها را به‌صورت امن ذخیره کرده و آن‌ها را به Pods و کانتینرها منتقل کنید.

Secrets به شما این امکان را می‌دهند که این داده‌های حساس را در محیط Kubernetes مدیریت کنید بدون آنکه آن‌ها در فایل‌های پیکربندی یا کدهای برنامه‌تان ظاهر شوند.

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

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

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

1. ایجاد یک Secret جدید:

kubectl create secret generic my-secret --from-literal=username='admin' --from-literal=password='secretpassword'

در این مثال، یک Secret با نام my-secret ایجاد می‌شود که شامل دو داده است: username و password.

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

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-example
spec:
  containers:
    - name: app-container
      image: nginx
      envFrom:
        - secretRef:
            name: my-secret

در این پیکربندی، از envFrom برای بارگذاری تمام مقادیر موجود در Secret به‌عنوان متغیرهای محیطی در کانتینر استفاده می‌شود. کانتینر می‌تواند به این متغیرها دسترسی پیدا کند. در اینجا، متغیرهای محیطی username و password در داخل کانتینر به‌طور خودکار ایجاد می‌شوند.

2. استفاده از Secrets به‌عنوان Volume در Pods

روش دیگر برای استفاده از Secrets در Pods، نصب آن‌ها به‌عنوان یک volume است. در این روش، مقادیر Secrets به‌عنوان فایل‌هایی در دسترس کانتینرها قرار می‌گیرند و شما می‌توانید به این فایل‌ها دسترسی پیدا کنید.

ایجاد Secret و استفاده از آن به‌عنوان Volume

1. ایجاد یک Secret برای گواهینامه‌ها:

kubectl create secret generic my-tls-secret --from-file=tls.crt=/path/to/tls.crt --from-file=tls.key=/path/to/tls.key

در این مثال، یک Secret با نام my-tls-secret ایجاد می‌شود که شامل دو فایل tls.crt و tls.key است.

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

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

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

• Secret my-tls-secret به‌عنوان یک volume در Pod تعریف شده است.
• محتویات این Secret در داخل کانتینر و در مسیر /etc/tls به‌صورت فایل‌های قابل دسترسی قرار می‌گیرد.
• فایل‌های گواهینامه و کلید خصوصی در داخل این مسیر به‌عنوان فایل‌هایی با نام tls.crt و tls.key در دسترس خواهند بود.

3. استفاده از Secrets به‌عنوان متغیرهای محیطی با رمزگذاری Base64

گاهی اوقات ممکن است بخواهید مقادیر حساس خود را به‌طور مستقیم به‌صورت Base64 رمزگذاری کنید و آن‌ها را به‌عنوان Secret ذخیره کنید.

مثال رمزگذاری Base64:

1. رمزگذاری Base64 داده‌ها:

echo -n 'secretpassword' | base64

نتیجه رمزگذاری شده به‌صورت Base64 برای استفاده در Secret خواهد بود.

2. ایجاد Secret با داده‌های رمزگذاری شده:

apiVersion: v1
kind: Secret
metadata:
  name: encoded-secret
type: Opaque
data:
  username: YWRtaW4=  # 'admin' به‌صورت Base64 رمزگذاری شده است
  password: c2VjcmV0cGFzc3dvcmQ=  # 'secretpassword' به‌صورت Base64 رمزگذاری شده است

در اینجا، داده‌ها به‌صورت Base64 رمزگذاری شده‌اند و در داخل Secret ذخیره شده‌اند.

3. استفاده از Secret رمزگذاری شده در Pod:

apiVersion: v1
kind: Pod
metadata:
  name: secret-encoded-example
spec:
  containers:
    - name: app-container
      image: nginx
      envFrom:
        - secretRef:
            name: encoded-secret

در این پیکربندی، داده‌های رمزگذاری شده از Secret به‌عنوان متغیرهای محیطی به کانتینر تزریق می‌شوند.

جمع بندی

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

• به‌عنوان متغیرهای محیطی با استفاده از envFrom.
• به‌عنوان فایل‌های سیستم با استفاده از Volumes.

این روش‌ها باعث می‌شوند که داده‌های حساس در داخل کانتینرها در دسترس باشند، در حالی که در داخل فایل‌های پیکربندی یا کدهای برنامه‌تان افشا نشوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”دسترسی به Secrets از طریق Volume و محیط متغیر (Environment Variables)” subtitle=”توضیحات کامل”]در کوبرنتیز، Secrets می‌توانند به دو صورت در اختیار Pods و کانتینرها قرار گیرند: از طریق Volumes یا از طریق Environment Variables. هرکدام از این روش‌ها مزایای خاص خود را دارند و انتخاب روش مناسب به نیازهای خاص شما بستگی دارد.

1. دسترسی به Secrets از طریق Volume

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

نحوه استفاده از Secrets به‌عنوان Volume

1. ایجاد Secret:

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

kubectl create secret generic my-app-secret --from-literal=db-password='supersecret'

در این مثال، Secret‌ای به نام my-app-secret ایجاد می‌شود که شامل یک داده db-password است.

2. تعریف Volume برای Secret در Pod:

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

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

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

• یک volume به نام secret-volume به Pod اضافه شده است.
• این volume به Secret با نام my-app-secret متصل شده است.
• Secret در مسیر /etc/secrets در کانتینر نصب می‌شود و داده‌های موجود در Secret به‌صورت فایل‌هایی در این مسیر قابل دسترسی خواهند بود.

برای مثال، اگر Secret شما حاوی یک کلید db-password باشد، این کلید به‌صورت یک فایل متنی در مسیر /etc/secrets/db-password در کانتینر ذخیره خواهد شد.

2. دسترسی به Secrets از طریق Environment Variables

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

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

1. ایجاد Secret:

اولین قدم ایجاد Secret است. به‌عنوان مثال:

kubectl create secret generic my-app-secret --from-literal=db-password='supersecret'

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

برای تزریق داده‌های Secret به‌عنوان متغیر محیطی، از تنظیمات زیر استفاده می‌کنیم:

apiVersion: v1
kind: Pod
metadata:
  name: secret-env-example
spec:
  containers:
    - name: app-container
      image: nginx
      envFrom:
        - secretRef:
            name: my-app-secret

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

• از envFrom برای بارگذاری تمام داده‌های موجود در Secret به‌عنوان متغیرهای محیطی استفاده شده است.
• در کانتینر، متغیرهای محیطی به نام‌های db-password و غیره به‌طور خودکار بارگذاری می‌شوند و شما می‌توانید از آن‌ها در برنامه‌تان استفاده کنید.

به‌عنوان مثال، اگر در Secret شما یک داده با نام db-password وجود داشته باشد، این داده به‌عنوان متغیر محیطی db-password در داخل کانتینر در دسترس خواهد بود.

مقایسه بین استفاده از Secrets به‌عنوان Volume و Environment Variables

ویژگی	استفاده از Volume	استفاده از Environment Variables
نحوه دسترسی	به‌عنوان فایل در سیستم فایل کانتینر	به‌عنوان متغیر محیطی در کانتینر
امنیت	اطلاعات حساس به‌صورت فایل ذخیره می‌شود	اطلاعات حساس به‌صورت متغیر محیطی ذخیره می‌شود
کاربرد مناسب	برای ذخیره‌سازی فایل‌ها و گواهینامه‌ها	برای ذخیره‌سازی اطلاعات غیر ساختاری مانند توکن‌ها و رمزها
امنیت فایل	فایل‌ها می‌توانند با دسترسی خاص به‌طور جداگانه محافظت شوند	متغیرهای محیطی ممکن است در فایل‌های log نمایش داده شوند
استفاده در برنامه	می‌توان به‌صورت مستقیم به فایل‌ها دسترسی داشت	می‌توان به‌صورت مستقیم به متغیرهای محیطی دسترسی داشت

جمع بندی

در Kubernetes، شما می‌توانید Secrets را به‌طور مؤثر و امن به‌صورت Volumes یا Environment Variables در Pods و کانتینرها استفاده کنید. استفاده از Volumes به‌ویژه زمانی مفید است که نیاز به ذخیره‌سازی داده‌های حساس به‌صورت فایل دارید، مانند گواهینامه‌ها یا کلیدهای خصوصی. از طرف دیگر، استفاده از Environment Variables بیشتر برای داده‌های حساس مانند رمزهای عبور یا توکن‌ها مناسب است.

هرکدام از این روش‌ها مزایای خاص خود را دارند، اما انتخاب بین آن‌ها بستگی به نوع اطلاعات حساس و نیاز شما دارد.[/cdb_course_lesson][cdb_course_lesson title=”امنیت Secrets:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از رمزنگاری در سطح ذخیره‌سازی (Encryption at Rest)” subtitle=”توضیحات کامل”]رمزنگاری در سطح ذخیره‌سازی (Encryption at Rest) به فرآیند رمزنگاری داده‌هایی اطلاق می‌شود که در زمان ذخیره‌شدن بر روی دیسک یا سایر رسانه‌های ذخیره‌سازی، در حالت خام و بدون پردازش قرار دارند. این نوع رمزنگاری به‌منظور حفاظت از داده‌ها در برابر دسترسی غیرمجاز در محیط‌هایی که داده‌ها به‌صورت دائم ذخیره می‌شوند، کاربرد دارد. در Kubernetes، به‌ویژه هنگام ذخیره‌سازی داده‌های حساس مانند Secrets یا Persistent Volumes، رمزنگاری در سطح ذخیره‌سازی یک راهکار حیاتی برای حفظ امنیت داده‌هاست.

1. اهمیت رمزنگاری در سطح ذخیره‌سازی

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

در Kubernetes، اطلاعاتی مانند Secrets، Persistent Volumes (PV)، و سایر داده‌های حساس باید در هنگام ذخیره‌سازی رمزنگاری شوند تا اطمینان حاصل شود که فقط افراد یا سرویس‌های معتبر قادر به خواندن و استفاده از آن‌ها هستند.

2. پیکربندی رمزنگاری در سطح ذخیره‌سازی در Kubernetes

Kubernetes امکاناتی برای پیکربندی Encryption at Rest فراهم کرده است. این امکانات از طریق تنظیمات مختلف در سطح API Server و etcd امکان‌پذیر است. Kubernetes از etcd برای ذخیره‌سازی داده‌های پیکربندی و وضعیت استفاده می‌کند که حاوی داده‌های بسیار حساسی مانند Secrets است. بنابراین، رمزنگاری این داده‌ها برای جلوگیری از دسترسی غیرمجاز ضروری است.

3. تنظیم رمزنگاری در Kubernetes

برای استفاده از رمزنگاری در سطح ذخیره‌سازی در Kubernetes، باید تنظیمات خاصی را در API Server و etcd انجام دهید. مراحل اصلی عبارت‌اند از:

3.1. تنظیمات رمزنگاری در etcd

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

1. فایل پیکربندی kube-apiserver را باز کنید. این فایل معمولاً در مسیر /etc/kubernetes/manifests/kube-apiserver.yaml قرار دارد.
2. بخش مربوط به رمزنگاری را به این صورت اضافه یا اصلاح کنید:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  template:
    spec:
      containers:
        - name: kube-apiserver
          command:
            - kube-apiserver
            - --encryption-provider-config=/etc/kubernetes/encryption/encryption-config.yaml

3. در این پیکربندی، مسیر --encryption-provider-config به فایل پیکربندی رمزنگاری اشاره دارد که باید تنظیمات رمزنگاری در آن قرار داده شود.

3.2. تنظیمات فایل پیکربندی رمزنگاری

برای پیکربندی رمزنگاری، یک فایل پیکربندی با نام encryption-config.yaml ایجاد کنید. این فایل می‌تواند به شکل زیر باشد:

apiVersion: v1
kind: Secret
metadata:
  name: encryption-config
  namespace: kube-system
data:
  encryption-config.yaml: |
    kind: EncryptionConfig
    apiVersion: encryption.k8s.io/v1
    resources:
      - resources:
          - secrets
        providers:
          - identity: {}
          - aesgcm:
              keys:
                - name: key1
                  secret: <base64-encoded-secret-key>

در این فایل:

• برای رمزنگاری Secrets از AES-GCM استفاده شده است.
• مقدار <base64-encoded-secret-key> باید به‌صورت base64 رمزنگاری شده و یک کلید تصادفی باشد.

پس از ایجاد این فایل، باید آن را در مسیر /etc/kubernetes/encryption/ قرار دهید و Kubernetes را مجدداً راه‌اندازی کنید تا تغییرات اعمال شود.

3.3. بررسی وضعیت رمزنگاری

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

kubectl get secrets --namespace=kube-system

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

4. مزایای رمزنگاری در سطح ذخیره‌سازی

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

جمع بندی

رمزنگاری در سطح ذخیره‌سازی (Encryption at Rest) در Kubernetes ابزاری بسیار مهم برای حفاظت از داده‌های حساس مانند Secrets و اطلاعات پیکربندی است. با پیکربندی مناسب رمزنگاری در etcd، می‌توان اطمینان حاصل کرد که حتی در صورت دسترسی غیرمجاز به فضای ذخیره‌سازی، داده‌ها در معرض سرقت قرار نخواهند گرفت. استفاده از این روش یکی از بهترین شیوه‌ها برای افزایش امنیت و محافظت از داده‌های حساس در کلاستر Kubernetes است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”محدودسازی دسترسی به Secrets با RBAC” subtitle=”توضیحات کامل”]Role-Based Access Control (RBAC) یکی از مهم‌ترین ابزارها برای مدیریت و محدود کردن دسترسی در Kubernetes است. این قابلیت به شما این امکان را می‌دهد که دسترسی‌ها به منابع مختلف Kubernetes مانند Secrets را بر اساس نقش‌های مختلف کاربران، سرویس‌ها یا گروه‌ها مدیریت کنید. با استفاده از RBAC می‌توانید دسترسی به منابع حساس مانند Secrets را برای کاربران و سرویس‌ها محدود کرده و فقط به کسانی که نیاز به دسترسی دارند این اجازه را بدهید.

در این بخش به نحوه محدودسازی دسترسی به Secrets با استفاده از RBAC خواهیم پرداخت.

1. مفاهیم کلیدی در RBAC برای محدودسازی دسترسی به Secrets

قبل از بررسی چگونگی پیکربندی RBAC برای محدود کردن دسترسی به Secrets، نیاز است که با مفاهیم اصلی RBAC در Kubernetes آشنا شویم:

• Role: یک Role مجموعه‌ای از مجوزهای دسترسی به منابع مختلف (مانند Pods، Secrets، یا ConfigMaps) در یک Namespace خاص است. این منابع می‌توانند دسترسی به منابع مختلف در کلاستر Kubernetes را تنظیم کنند.
• ClusterRole: مشابه Role است، با این تفاوت که دسترسی‌ها را در سطح کل کلاستر (نه فقط در یک Namespace خاص) تنظیم می‌کند.
• RoleBinding: این شیء ارتباط بین یک Role و یک کاربر یا گروه مشخص را برقرار می‌کند. یعنی تعیین می‌کند که یک کاربر یا سرویس خاص چه مجوزهایی بر روی منابع یک Namespace خاص دارد.
• ClusterRoleBinding: مشابه RoleBinding است، اما دسترسی‌های آن در سطح کلاستر اعمال می‌شود.

2. محدودسازی دسترسی به Secrets با استفاده از Role و RoleBinding

برای محدود کردن دسترسی به Secrets، می‌توانیم یک Role ایجاد کرده و به آن دسترسی به منابع Secrets بدهیم. سپس این Role را از طریق RoleBinding به کاربران، سرویس‌ها یا گروه‌های خاص اختصاص می‌دهیم.

2.1. ایجاد Role برای محدود کردن دسترسی به Secrets

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

مثال: ایجاد یک Role که فقط به Secrets در Namespace default دسترسی دارد:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  # تعیین نام و Namespace برای Role
  namespace: default
  name: secret-access-role
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list"]  # تنها دسترسی به خواندن داده‌های Secrets

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

• apiGroups: به منابع استاندارد اشاره دارد که در اینجا Secrets جزء آن است.
• resources: مشخص می‌کند که منابع چه چیزی هستند، در اینجا فقط Secrets است.
• verbs: عملیات مجاز بر روی منابع را مشخص می‌کند، مانند get (برای خواندن) و list (برای لیست کردن).

2.2. ایجاد RoleBinding برای اختصاص دسترسی به Role

پس از ایجاد Role، باید آن را از طریق یک RoleBinding به کاربر، سرویس، یا گروه خاص اختصاص دهید. به عنوان مثال، اگر بخواهید به سرویس my-app در Namespace default دسترسی به Secrets بدهید، می‌توانید از دستور زیر استفاده کنید:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: secret-access-binding
  namespace: default
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: default
roleRef:
  kind: Role
  name: secret-access-role
  apiGroup: rbac.authorization.k8s.io

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

• subjects: مشخص می‌کند که چه کاربران یا سرویس‌ها می‌توانند به این Role دسترسی داشته باشند.
• roleRef: مشخص می‌کند که این RoleBinding به کدام Role اشاره دارد و آن را به کاربر یا سرویس مشخص شده اعمال می‌کند.

2.3. بررسی دسترسی به Secrets

برای بررسی اینکه آیا یک سرویس خاص (مانند my-app) به Secrets دسترسی دارد یا خیر، می‌توانید از دستور زیر استفاده کنید:

kubectl auth can-i get secrets --as=system:serviceaccount:default:my-app

این دستور بررسی می‌کند که آیا سرویس my-app قادر به خواندن Secrets در Namespace default است یا خیر. اگر پاسخ “yes” بود، به این معناست که دسترسی برقرار شده است.

3. محدودسازی دسترسی به Secrets با ClusterRole و ClusterRoleBinding

اگر بخواهید دسترسی به Secrets را به کاربران یا سرویس‌ها در سطح کلاستر محدود کنید، باید از ClusterRole و ClusterRoleBinding استفاده کنید.

3.1. ایجاد ClusterRole برای محدود کردن دسترسی به Secrets در سطح کلاستر

در اینجا یک ClusterRole تعریف می‌کنیم که به کاربران دسترسی به Secrets در تمامی Namespaceها بدهد:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: cluster-secret-access-role
rules:
  - apiGroups: [""]
    resources: ["secrets"]
    verbs: ["get", "list"]

3.2. ایجاد ClusterRoleBinding برای اختصاص دسترسی به ClusterRole

حال، باید ClusterRole را به کاربران یا سرویس‌ها در سطح کلاستر اختصاص دهیم. این کار را با استفاده از ClusterRoleBinding انجام می‌دهیم. مثلاً اگر بخواهید به سرویس my-app در Namespace default دسترسی بدهید، از دستور زیر استفاده می‌کنیم:

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-secret-access-binding
subjects:
  - kind: ServiceAccount
    name: my-app
    namespace: default
roleRef:
  kind: ClusterRole
  name: cluster-secret-access-role
  apiGroup: rbac.authorization.k8s.io

جمع بندی

محدودسازی دسترسی به Secrets با استفاده از RBAC یکی از روش‌های مؤثر برای محافظت از داده‌های حساس در Kubernetes است. با استفاده از Role و RoleBinding، می‌توانید دسترسی به Secrets را در سطح Namespace محدود کنید و با استفاده از ClusterRole و ClusterRoleBinding این محدودیت‌ها را در سطح کلاستر اعمال کنید. همچنین، با استفاده از دستور kubectl auth can-i می‌توانید از صحت دسترسی‌های تعریف‌شده اطمینان حاصل کنید. این روش‌ها به شما کمک می‌کنند تا امنیت داده‌های حساس را در کلاستر Kubernetes خود افزایش دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”چرخش (Rotation) و مدیریت دوره‌ای Secrets” subtitle=”توضیحات کامل”]چرخش Secrets و مدیریت آن‌ها به‌طور دوره‌ای یکی از بخش‌های حیاتی در حفظ امنیت سیستم‌ها و داده‌های حساس است. در یک محیط Kubernetes، Secrets ممکن است شامل اطلاعات حساسی مانند رمز عبور، توکن‌های دسترسی، و گواهینامه‌ها باشند. این اطلاعات باید به‌طور منظم به‌روزرسانی و چرخش داده شوند تا از خطرات احتمالی مانند افشای اطلاعات حساس جلوگیری شود.

در این بخش به روش‌ها و بهترین شیوه‌ها برای چرخش و مدیریت دوره‌ای Secrets در Kubernetes می‌پردازیم.

1. اهمیت چرخش دوره‌ای Secrets

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

2. روش‌های چرخش Secrets در Kubernetes

چرخش Secrets در Kubernetes می‌تواند به دو روش اصلی انجام شود:

• چرخش دستی (Manual Rotation): در این روش، مدیر سیستم یا تیم امنیتی باید به‌طور دستی Secrets را به‌روزرسانی کند و سپس کانتینرها یا Pods را که از این Secrets استفاده می‌کنند، مجدداً راه‌اندازی کند.
• چرخش خودکار (Automated Rotation): در این روش، ابزارها و سرویس‌های خاص می‌توانند به‌طور خودکار Secrets را به‌روزرسانی کنند. به‌عنوان مثال، استفاده از سیستم‌های مدیریت Secrets مانند HashiCorp Vault، AWS Secrets Manager یا Google Cloud Secret Manager می‌تواند به‌طور خودکار Secrets را مدیریت و به‌روزرسانی کند.

3. چرخش دستی Secrets

در این روش، برای چرخش دستی Secrets، شما باید مراحل زیر را دنبال کنید:

3.1. به‌روزرسانی Secret

ابتدا باید Secret جدید را ایجاد کنید. برای این کار می‌توانید از دستور kubectl create secret استفاده کنید.

مثال: ایجاد یک Secret جدید برای یک پایگاه داده با رمز عبور جدید:

kubectl create secret generic db-password --from-literal=password=newpassword123 --dry-run=client -o yaml | kubectl apply -f -

در این دستور:

• --from-literal: برای وارد کردن داده‌ها به صورت مستقیم به داخل Secret استفاده می‌شود.
• --dry-run=client: این گزینه اجازه می‌دهد که فقط خروجی YAML برای Secret جدید نمایش داده شود بدون اینکه مستقیماً در کلاستر ذخیره شود.
• -o yaml: خروجی به فرمت YAML خواهد بود.
• | kubectl apply -f -: برای اعمال تغییرات به کلاستر استفاده می‌شود.

3.2. به‌روزرسانی منابع وابسته به Secret

پس از به‌روزرسانی Secret، باید منابعی که از آن استفاده می‌کنند (مانند Pods یا Deployments) را به‌روزرسانی کنید تا از Secret جدید استفاده کنند.

برای این کار، می‌توانید Pods را دوباره راه‌اندازی کنید:

kubectl rollout restart deployment <deployment-name>

این دستور باعث می‌شود که Deployment شما مجدداً راه‌اندازی شود و از Secret جدید استفاده کند.

4. چرخش خودکار Secrets با استفاده از ابزارهای مدیریت Secrets

چرخش خودکار Secrets یکی از بهترین شیوه‌ها برای مدیریت امنیت در Kubernetes است. ابزارهایی مانند HashiCorp Vault، AWS Secrets Manager و Google Cloud Secret Manager به‌طور خودکار امکان چرخش Secrets را فراهم می‌کنند.

4.1. استفاده از HashiCorp Vault

HashiCorp Vault یکی از ابزارهای قدرتمند برای مدیریت Secrets است که امکان چرخش خودکار آنها را نیز دارد. برای استفاده از Vault، می‌توانید مراحل زیر را دنبال کنید:

1. نصب و پیکربندی Vault در Kubernetes.
2. پیکربندی Vault برای تولید و چرخش Secrets.
3. استفاده از Vault Agent در Pods برای دسترسی به Secrets به‌صورت خودکار.

4.2. استفاده از AWS Secrets Manager

AWS Secrets Manager یک سرویس امن برای ذخیره و مدیریت Secrets است که از چرخش خودکار پشتیبانی می‌کند. برای استفاده از این سرویس در Kubernetes، می‌توانید از ابزار Kubernetes External Secrets استفاده کنید تا به‌طور خودکار Secrets را از AWS Secrets Manager به Kubernetes وارد کنید.

5. نظارت بر چرخش و مدیریت Secrets

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

برای مثال، می‌توانید از ابزارهایی مانند Prometheus و Grafana برای نظارت بر تغییرات و چرخش Secrets استفاده کنید.

جمع بندی

چرخش و مدیریت دوره‌ای Secrets بخش حیاتی امنیت در Kubernetes است. با استفاده از روش‌های چرخش دستی یا خودکار، می‌توان از افشای اطلاعات حساس جلوگیری کرد و از تهدیدات امنیتی کاست. با به‌کارگیری ابزارهای مدیریت Secrets مانند HashiCorp Vault، AWS Secrets Manager و Google Cloud Secret Manager، این فرآیند را خودکار و امن‌تر می‌سازید. به‌روزرسانی منظم Secrets و نظارت دقیق بر آن‌ها برای حفظ امنیت سیستم‌های شما ضروری است.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. حفاظت از Cluster و منابع”][/cdb_course_lesson][cdb_course_lesson title=”Admission Controllers:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”آشنایی با Admission Controllers مانند PodSecurityAdmission و ImagePolicyWebhook” subtitle=”توضیحات کامل”]Admission Controllers در Kubernetes بخش‌های حیاتی از فرآیند اعتبارسنجی و تصویب درخواست‌ها هستند که قبل از اینکه منابع در کلاستر به‌طور کامل ایجاد شوند، اعمال می‌شوند. این کنترلرها به مدیران Kubernetes این امکان را می‌دهند که دسترسی‌ها و سیاست‌های امنیتی را به‌صورت دقیق‌تری برای منابع مختلف در سطح کلاستر پیاده‌سازی کنند. در این بخش به معرفی و استفاده از دو Admission Controller مهم، یعنی PodSecurityAdmission و ImagePolicyWebhook خواهیم پرداخت.

1. معرفی Admission Controllers

Admission Controllers درخواست‌های API را پس از مرحله اعتبارسنجی ولی قبل از ذخیره‌شدن داده‌ها در etcd بررسی و پردازش می‌کنند. این‌ها می‌توانند به‌طور خودکار درخواست‌ها را قبول یا رد کنند یا تغییراتی روی آنها اعمال کنند.

مهم‌ترین عملکردهای Admission Controllers عبارت‌اند از:

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

در این بخش، به دو Admission Controller مهم که برای امنیت و مدیریت منابع در Kubernetes استفاده می‌شوند خواهیم پرداخت: PodSecurityAdmission و ImagePolicyWebhook.

2. PodSecurityAdmission

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

2.1. نحوه عملکرد PodSecurityAdmission

PodSecurityAdmission به‌طور خاص برای پیاده‌سازی سیاست‌های امنیتی Pod‌ها مانند محدودیت‌های سطح دسترسی، استفاده از کاربرهای غیر ریشه و همچنین محدودیت‌های دیگر طراحی شده است. این Admission Controller می‌تواند بر اساس یک سری از Policies امنیتی اعمال شود و اجازه ندهد Pods غیرمجاز به کلاستر اضافه شوند.

2.2. پیکربندی PodSecurityAdmission

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

برای پیکربندی PodSecurityAdmission، می‌توانید به صورت زیر عمل کنید:

1. ابتدا باید PodSecurityPolicy را فعال کرده و تنظیمات مورد نیاز را در فایل کانفیگ قرار دهید.
2. تنظیمات اعمال‌شده در کانفیگ را به‌صورت زیر در Pod مشخص کنید.

نمونه‌ای از استفاده از PodSecurityAdmission:

apiVersion: admission.k8s.io/v1
kind: AdmissionControlConfiguration
admissionControl:
  enabled:
    - PodSecurityAdmission

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

2.3. سیاست‌های PodSecurityAdmission

PodSecurityAdmission از سه سطح امنیتی پشتیبانی می‌کند:

• Privileged: اجازه به تمام Pods با سطح دسترسی بالا.
• Baseline: محدودیت‌های پایه مانند جلوگیری از اجرای Pods با دسترسی‌های ریشه.
• Restricted: محدودیت‌های دقیق‌تر مانند مسدود کردن اجرای هرگونه Pod با سطوح امنیتی پایین.

3. ImagePolicyWebhook

ImagePolicyWebhook یک Admission Controller است که برای بررسی و اعتبارسنجی Images قبل از اجرا در Kubernetes استفاده می‌شود. این کنترلر به شما این امکان را می‌دهد که از اجرای تصاویر Docker یا container image که به‌طور خاص به تصویب نرسیده‌اند یا از منابع غیرمجاز هستند، جلوگیری کنید.

3.1. نحوه عملکرد ImagePolicyWebhook

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

با استفاده از ImagePolicyWebhook می‌توانید:

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

3.2. پیکربندی ImagePolicyWebhook

برای استفاده از ImagePolicyWebhook، ابتدا نیاز به یک وب‌هوک برای بررسی سیاست‌های image دارید. این وب‌هوک می‌تواند از API‌های خارجی استفاده کند تا درخواست‌های مربوط به images را تایید یا رد کند.

برای تنظیم یک وب‌هوک ImagePolicy، شما باید:

1. یک سرویس وب ایجاد کنید که بتواند درخواست‌های Webhook را پردازش کند.
2. Webhook خود را در Kubernetes برای پردازش اعتبارسنجی‌های image ثبت کنید.

نمونه‌ای از پیکربندی Webhook برای اعتبارسنجی image:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: example-image-policy
webhooks:
  - name: image-policy.example.com
    clientConfig:
      url: "https://your-webhook-server.com"
    rules:
      - operations: ["CREATE"]
        apiGroups: ["apps"]
        apiVersions: ["v1"]
        resources: ["pods"]

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

جمع بندی

Admission Controllers مانند PodSecurityAdmission و ImagePolicyWebhook ابزارهای قدرتمندی برای افزایش امنیت و مدیریت منابع در Kubernetes هستند. PodSecurityAdmission به شما این امکان را می‌دهد که سیاست‌های امنیتی را برای Pods اعمال کنید و از اجرای پیکربندی‌های خطرناک جلوگیری کنید. از طرف دیگر، ImagePolicyWebhook اجازه می‌دهد که Images قبل از اجرا بررسی شوند و تنها تصاویر تاییدشده و امن در کلاستر اجرا شوند. استفاده از این کنترلرها برای حفظ امنیت و مدیریت دسترسی‌ها در Kubernetes ضروری است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیکربندی Admission Controllers برای افزایش امنیت” subtitle=”توضیحات کامل”]Admission Controllers در Kubernetes یکی از اجزای حیاتی برای مدیریت امنیت و دسترسی به منابع مختلف هستند. این کنترلرها به‌طور پیش‌فرض در فرآیند پذیرش درخواست‌های API بین مراحل اعتبارسنجی و ذخیره‌سازی داده‌ها قرار دارند و می‌توانند درخواست‌ها را تأیید، تغییر یا رد کنند. استفاده از Admission Controllers می‌تواند به‌طور چشمگیری امنیت یک کلاستر را افزایش دهد، چرا که به شما امکان می‌دهد سیاست‌های امنیتی دقیقی را برای منابع و درخواست‌های مختلف اعمال کنید.

در این بخش، به نحوه پیکربندی Admission Controllers برای افزایش امنیت در Kubernetes پرداخته و تنظیمات مختلفی که برای تقویت امنیت منابع و کاربران ضروری هستند، بررسی خواهیم کرد.

1. معرفی Admission Controllers و نقش آن‌ها در امنیت

Admission Controllers به‌طور خاص برای اجرا شدن پس از مرحله اعتبارسنجی و قبل از ذخیره داده‌ها در etcd طراحی شده‌اند. این کنترلرها در سطوح مختلفی می‌توانند به درخواست‌ها اعمال شوند:

• Mutating Admission Controllers: این کنترلرها می‌توانند تغییراتی را در درخواست‌های ورودی اعمال کنند (مثلاً اضافه کردن برچسب‌ها یا تنظیمات پیش‌فرض).
• Validating Admission Controllers: این کنترلرها به‌طور عمده برای بررسی صحت و اعتبار درخواست‌ها و منابع جدید استفاده می‌شوند (مثلاً بررسی اعتبار «PodSecurityPolicy» یا سیاست‌های امنیتی).

برای تأمین امنیت در Kubernetes، می‌توانید از Admission Controllers برای پیاده‌سازی سیاست‌های مختلف استفاده کنید. در اینجا به بررسی نحوه پیکربندی و استفاده از مهم‌ترین Admission Controllers امنیتی خواهیم پرداخت.

2. پیکربندی PodSecurityAdmission

PodSecurityAdmission یک Admission Controller است که برای اجرای سیاست‌های امنیتی بر روی Pods طراحی شده است. با استفاده از این کنترلر می‌توان از اجرای Pods با پیکربندی‌های خطرناک جلوگیری کرد و رفتارهایی مانند اجرای دسترسی‌های ریشه یا استفاده از کاربرهای ناامن را محدود کرد.

2.1. نحوه پیکربندی PodSecurityAdmission

برای پیکربندی PodSecurityAdmission در Kubernetes، باید ابتدا آن را در کلاستر فعال کنید. سپس سیاست‌های امنیتی را برای Pods تعریف کرده و آن‌ها را به‌طور خودکار بر روی درخواست‌های جدید اعمال کنید.

برای فعال‌سازی PodSecurityAdmission باید تنظیمات زیر را در فایل پیکربندی kube-apiserver وارد کنید:

--enable-admission-plugins=PodSecurityAdmission

سپس می‌توانید سیاست‌های امنیتی زیر را برای Pods تنظیم کنید:

• Privileged: اجازه به تمام Pods برای اجرا با سطوح دسترسی بالا.
• Baseline: اجازه به Pods با دسترسی‌های ایمن‌تر مانند جلوگیری از استفاده از دسترسی‌های ریشه.
• Restricted: محدودترین سیاست که فقط Pods با بالاترین سطح امنیتی اجازه اجرا خواهند داشت.

نمونه‌ای از پیکربندی PodSecurityAdmission:

apiVersion: admission.k8s.io/v1
kind: AdmissionControlConfiguration
admissionControl:
  enabled:
    - PodSecurityAdmission
  policy: "Baseline"

با این تنظیم، Kubernetes به‌طور پیش‌فرض از سیاست‌های امنیتی Baseline برای Pods استفاده می‌کند.

3. پیکربندی ImagePolicyWebhook

ImagePolicyWebhook یک Admission Controller است که برای کنترل تصاویر Docker یا container imageها پیش از اجرای آن‌ها در کلاستر طراحی شده است. این کنترلر به شما امکان می‌دهد که از اجرای Images خطرناک یا ناامن جلوگیری کنید.

3.1. نحوه پیکربندی ImagePolicyWebhook

برای پیکربندی ImagePolicyWebhook، باید یک وب‌هوک (Webhook) تنظیم کنید که درخواست‌های مربوط به کشیدن یا استفاده از images را بررسی کند. این وب‌هوک می‌تواند درخواست‌هایی که به image ارسال می‌شود را اعتبارسنجی کرده و بررسی کند که آیا آن‌ها به سیاست‌های تعریف‌شده مطابقت دارند یا خیر.

برای پیکربندی این Webhook باید سرویس Webhook خود را ایجاد کنید و سپس در Kubernetes آن را به‌عنوان Mutating Admission Controller ثبت کنید:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: example-image-policy
webhooks:
  - name: image-policy.example.com
    clientConfig:
      url: "https://your-webhook-server.com"
    rules:
      - operations: ["CREATE"]
        apiGroups: ["apps"]
        apiVersions: ["v1"]
        resources: ["pods"]

در این پیکربندی، هر بار که یک Pod با Image جدید ایجاد می‌شود، درخواست به وب‌هوک شما ارسال می‌شود تا اعتبارسنجی انجام شود.

4. پیکربندی NodeRestriction

NodeRestriction یک Admission Controller است که به‌طور خاص برای محدود کردن دسترسی به اطلاعات حساس در سطح نودها (Nodes) طراحی شده است. این کنترلر می‌تواند دسترسی کاربران و سرویس‌ها به اطلاعات نودها را محدود کند، مانند اینکه چه کسی قادر است به ConfigMapها و Secretsهای نودها دسترسی پیدا کند.

4.1. نحوه پیکربندی NodeRestriction

برای فعال‌سازی این Admission Controller در Kubernetes، کافیست گزینه زیر را در پیکربندی kube-apiserver اضافه کنید:

--enable-admission-plugins=NodeRestriction

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

5. پیکربندی AlwaysPullImages

یکی دیگر از Admission Controllers که می‌تواند به امنیت کمک کند، AlwaysPullImages است. این کنترلر باعث می‌شود که Kubernetes همیشه تصویر (image) موردنظر را از مخزن بارگیری کند و از استفاده از caches یا local images جلوگیری کند. این کار به‌ویژه در سناریوهایی مفید است که می‌خواهید از اجرای images ناامن یا قدیمی جلوگیری کنید.

5.1. نحوه پیکربندی AlwaysPullImages

برای پیکربندی AlwaysPullImages در Kubernetes، باید گزینه زیر را در kube-apiserver فعال کنید:

--enable-admission-plugins=AlwaysPullImages

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

جمع بندی

Admission Controllers ابزارهای قدرتمندی برای افزایش امنیت در Kubernetes هستند. با استفاده از این کنترلرها می‌توان دسترسی‌ها، اعتبارسنجی‌ها و سیاست‌های امنیتی دقیق‌تری را در سطح کلاستر و منابع مختلف پیاده‌سازی کرد. پیکربندی صحیح و استفاده از کنترلرهای امنیتی مانند PodSecurityAdmission، ImagePolicyWebhook و NodeRestriction می‌تواند از بسیاری از تهدیدات امنیتی جلوگیری کرده و مدیریت منابع را بهبود بخشد.

 [/cdb_course_lesson][cdb_course_lesson title=”Image Security:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از تصاویر معتبر و امن” subtitle=”توضیحات کامل”]در کلاسترهای Kubernetes، یکی از چالش‌های امنیتی اصلی، مدیریت و استفاده از تصاویر Docker یا container images معتبر و امن است. تصاویر غیرمعتبر یا آسیب‌پذیر ممکن است حاوی کدهای مخرب یا آسیب‌پذیری‌هایی باشند که می‌توانند به مهاجمین اجازه دهند به منابع کلاستر دسترسی پیدا کنند. بنابراین، استفاده از تصاویر امن و معتبر باید جزء سیاست‌های امنیتی اصلی هر سازمانی باشد.

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

1. اهمیت استفاده از تصاویر معتبر و امن

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

• آسیب‌پذیری‌ها: تصاویر قدیمی یا آسیب‌دیده ممکن است دارای vulnerabilities شناخته‌شده‌ای باشند که مهاجمین از آن‌ها سوءاستفاده کنند.
• تصاویر غیرمعتبر: استفاده از تصاویر منتشرشده از منابع ناشناخته می‌تواند شامل کدهای مخرب باشد.
• پشتیبانی و نگهداری: تصاویر رسمی یا معتبر معمولا پشتیبانی و بروزرسانی‌های منظم دریافت می‌کنند تا از مشکلات امنیتی جلوگیری شود.

2. راهکارهای استفاده از تصاویر معتبر و امن

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

2.1. استفاده از مخازن معتبر و شناخته‌شده

اولین و مهم‌ترین قدم برای اطمینان از امنیت تصاویر، استفاده از maven repositories و image registries معتبر است. برای مثال:

• Docker Hub: بزرگترین و معروف‌ترین مخزن تصاویر Docker است که تصاویر رسمی را از سازمان‌های معتبر منتشر می‌کند.
• Google Container Registry (GCR): برای تصاویر مرتبط با Google Cloud.
• Amazon Elastic Container Registry (ECR): برای تصاویر مرتبط با AWS.

همچنین می‌توانید از private registries برای ذخیره‌سازی و استفاده از تصاویر خاص خودتان استفاده کنید که به‌طور اختصاصی برای سازمان شما ساخته شده‌اند.

2.2. بررسی و اسکن تصاویر برای آسیب‌پذیری‌ها

برای اطمینان از عدم وجود آسیب‌پذیری‌های امنیتی در تصاویر، از ابزارهای vulnerability scanning استفاده کنید. این ابزارها به‌طور خودکار تصاویر را بررسی کرده و آسیب‌پذیری‌ها را شناسایی می‌کنند. نمونه‌هایی از این ابزارها عبارتند از:

• Clair: یک ابزار برای اسکن آسیب‌پذیری‌ها در تصاویر Docker.
• Trivy: یک ابزار ساده و سریع برای اسکن تصاویر Docker به منظور شناسایی آسیب‌پذیری‌ها.
• Anchore: یک ابزار برای بررسی امنیت تصاویر و تطبیق با استانداردهای امنیتی.
• Aqua Security: یک پلتفرم جامع برای امنیت تصاویر و کانتینرها.

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

2.3. استفاده از Signed Images

تصاویر امضا شده (Signed Images) راه دیگری برای اطمینان از اعتبار تصویر است. امضا کردن تصاویر به شما این امکان را می‌دهد که تضمین کنید تصویر مورد استفاده از یک منبع معتبر است و تغییرات غیرمجاز در آن اعمال نشده است.

برای امضای تصاویر Docker از ابزار Notary استفاده می‌شود. Notary یک ابزار متن‌باز است که به شما امکان می‌دهد تصاویر را به‌صورت دیجیتالی امضا کرده و از صحت آن‌ها اطمینان حاصل کنید.

در صورتی که از Docker Hub استفاده می‌کنید، این سرویس به‌طور پیش‌فرض از امضای تصاویر پشتیبانی می‌کند. برای بررسی امضای یک تصویر در Docker Hub می‌توانید از دستور زیر استفاده کنید:

docker trust inspect <image_name>

این دستور بررسی می‌کند که تصویر مورد نظر امضا شده است یا خیر و به شما این امکان را می‌دهد که به‌راحتی آن را اعتبارسنجی کنید.

2.4. محدود کردن استفاده از تصاویر با سیاست‌های امنیتی

برای محدود کردن استفاده از تصاویر غیرمعتبر و خطرناک، می‌توانید از Admission Controllers استفاده کنید که درخواست‌های ساخت Pods را برای استفاده از تصاویر خاص بررسی کنند. به عنوان مثال، استفاده از ImagePolicyWebhook به شما این امکان را می‌دهد که تصاویری که از منابع غیرمعتبر یا غیرمجاز کشیده می‌شوند را مسدود کنید.

نمونه‌ای از پیکربندی ImagePolicyWebhook برای محدود کردن تصاویر:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: example-image-policy
webhooks:
  - name: image-policy.example.com
    clientConfig:
      url: "https://your-webhook-server.com"
    rules:
      - operations: ["CREATE"]
        apiGroups: ["apps"]
        apiVersions: ["v1"]
        resources: ["pods"]

با این تنظیمات، هر زمان که یک Pod جدید با Image مشخصی ایجاد شود، این درخواست از طریق Webhook بررسی خواهد شد.

2.5. تنظیمات پیکربندی در Kubernetes برای استفاده از تصاویر امن

برای افزایش امنیت در Kubernetes و جلوگیری از استفاده از تصاویر ناامن، می‌توان تنظیماتی را برای kubelet و kube-apiserver اعمال کرد. برای مثال، می‌توانید به Kubernetes دستور دهید که تنها از تصاویر امضا شده یا از مخازن خاص استفاده کند.

برای اعمال این تنظیمات در kube-apiserver می‌توان گزینه‌های زیر را استفاده کرد:

--feature-gates=ImagePolicyWebhook=true
--enable-admission-plugins=ImagePolicyWebhook

این تنظیمات به Kubernetes اجازه می‌دهد که از ImagePolicyWebhook برای اعتبارسنجی تصاویر استفاده کند.

جمع بندی

استفاده از تصاویر معتبر و امن یکی از اصول اصلی در تضمین امنیت در Kubernetes است. با استفاده از مخازن معتبر، اسکن تصاویر برای آسیب‌پذیری‌ها، امضای دیجیتالی تصاویر، و پیکربندی دقیق سیاست‌ها و Admission Controllers می‌توانید از تهدیدات امنیتی جلوگیری کرده و یک محیط امن برای اجرای کانتینرها ایجاد کنید. این اقدامات به شما کمک می‌کند تا از خطرات ناشی از استفاده از تصاویر آسیب‌پذیر یا غیرمعتبر دوری کنید و از درز داده‌ها و حملات به منابع کلاستر جلوگیری کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”امضای تصاویر کانتینرها (Container Image Signing)” subtitle=”توضیحات کامل”]امضای تصاویر کانتینر یکی از روش‌های اساسی برای تأمین امنیت و اعتبار تصاویر کانتینر در محیط‌های مانند Kubernetes است. این فرآیند به شما این امکان را می‌دهد که تصویری که از آن استفاده می‌کنید، از یک منبع معتبر است و هیچ‌گونه تغییر غیرمجاز در آن ایجاد نشده است. امضای تصاویر نه تنها کمک می‌کند تا از خطرات ناشی از استفاده از تصاویر دستکاری‌شده جلوگیری شود، بلکه اطمینان می‌دهد که کانتینرهای شما به‌طور صحیح و امن اجرا می‌شوند.

در این بخش، به معرفی فرآیند امضای تصاویر کانتینر، ابزارهای مورد استفاده، نحوه تنظیم و مدیریت امضای تصاویر کانتینر پرداخته می‌شود.

1. چرا امضای تصاویر کانتینر اهمیت دارد؟

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

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

2. روش‌های امضای تصاویر کانتینر

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

2.1. Docker Content Trust (DCT)

Docker Content Trust (DCT) یک ویژگی در Docker است که اجازه می‌دهد تصاویر Docker امضا شده و اعتبارسنجی شوند. با فعال کردن این ویژگی، Docker تنها به تصاویر امضا شده اجازه بارگذاری و اجرا می‌دهد. این ویژگی از Notary برای انجام امضای دیجیتال استفاده می‌کند.

برای فعال‌سازی Docker Content Trust در Docker:

export DOCKER_CONTENT_TRUST=1

پس از فعال‌سازی این تنظیم، زمانی که می‌خواهید یک تصویر را کش کنید یا به مخزن Docker push کنید، Docker تنها تصاویر امضا شده را قبول می‌کند. برای امضای یک تصویر، می‌توانید از دستور docker trust استفاده کنید.

برای امضای یک تصویر با استفاده از Docker:

docker trust sign <image_name>

این دستور تصویر را امضا کرده و آن را به مخزن ارسال می‌کند.

2.2. Notary

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

برای امضای یک تصویر با استفاده از Notary، مراحل زیر را انجام دهید:

1. نصب ابزار Notary:

curl -sSL https://github.com/theupdateframework/notary/releases/download/v0.6.0/notary-0.6.0-linux-amd64.tar.gz | tar xz -C /usr/local/bin

2. تنظیم Notary برای کار با Docker Hub:

برای امضای تصاویر در Docker Hub، باید ابتدا وارد حساب کاربری خود شوید:

docker login

3. امضای تصویر:

notary sign <image_name>

2.3. Cosign

Cosign یک ابزار دیگر است که توسط Sigstore برای امضای تصاویر کانتینر و دیگر فایل‌ها ایجاد شده است. Cosign به شما این امکان را می‌دهد که به‌راحتی تصاویر Docker را امضا کنید و سپس از این امضا برای تأیید اعتبار تصویر استفاده نمایید.

برای استفاده از Cosign، ابتدا باید آن را نصب کنید:

brew install cosign

سپس می‌توانید تصویر مورد نظر را امضا کنید:

cosign sign <image_name>

Cosign از KMS (Key Management Services) برای مدیریت کلیدهای امضا استفاده می‌کند که موجب می‌شود فرآیند امضا و تأیید اعتبار امن‌تر شود.

3. نحوه بررسی و اعتبارسنجی تصاویر امضا شده

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

3.1. بررسی امضای تصویر با Docker

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

docker trust inspect <image_name>

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

3.2. بررسی امضای تصویر با Cosign

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

cosign verify <image_name>

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

4. استفاده از تصاویر امضا شده در Kubernetes

در Kubernetes می‌توان از Admission Controllers برای بررسی و استفاده از تصاویر امضا شده استفاده کرد. یکی از Admission Controllers مفید برای این کار ImagePolicyWebhook است که می‌تواند درخواست‌های ساخت Pod را بررسی کرده و تنها تصاویری که امضا شده‌اند را بپذیرد.

برای پیکربندی ImagePolicyWebhook، تنظیمات زیر را در فایل mutatingwebhookconfiguration خود قرار دهید:

apiVersion: admissionregistration.k8s.io/v1
kind: MutatingWebhookConfiguration
metadata:
  name: image-policy-webhook
webhooks:
  - name: image-policy.example.com
    clientConfig:
      url: "https://your-webhook-server.com"
    rules:
      - operations: ["CREATE"]
        apiGroups: ["apps"]
        apiVersions: ["v1"]
        resources: ["pods"]

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

جمع بندی

امضای تصاویر کانتینر یکی از راه‌های اصلی برای تأمین امنیت در استفاده از کانتینرها و Kubernetes است. این روش به شما امکان می‌دهد تا از تصاویر دستکاری شده و آسیب‌پذیر جلوگیری کنید. ابزارهای مختلفی مانند Docker Content Trust، Notary، و Cosign می‌توانند در فرآیند امضای تصاویر کمک کنند و از امنیت تصاویر اطمینان حاصل کنند. علاوه بر این، استفاده از Admission Controllers در Kubernetes می‌تواند اطمینان حاصل کند که تنها تصاویر امضا شده در کلاستر استفاده شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”محدودسازی دسترسی به Registry‌های خارجی” subtitle=”توضیحات کامل”]در Kubernetes، دسترسی به تصاویر کانتینر معمولاً از طریق Docker Registry یا سایر Registry‌های کانتینر خارجی انجام می‌شود. برای امنیت بیشتر، مهم است که دسترسی به این Registry‌ها محدود شود تا از بارگذاری تصاویر مخرب یا نامعتبر جلوگیری شود. محدودسازی دسترسی به این Registry‌ها می‌تواند از طرق مختلفی انجام شود، از جمله استفاده از ابزارهای مجازسازی و کنترل دسترسی.

استفاده از ImagePullSecrets

یکی از رایج‌ترین روش‌های محدود کردن دسترسی به Registry‌های خارجی، استفاده از ImagePullSecrets است. این ویژگی به Kubernetes اجازه می‌دهد تا از اطلاعات احراز هویت برای دسترسی به Registry‌های خصوصی استفاده کند. برای استفاده از این ویژگی، می‌توان یک Secret برای نگهداری اطلاعات ورود (مانند توکن‌ها یا کلمه عبور) به Registry‌های خصوصی ایجاد کرد.

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

1. ایجاد یک Secret برای دسترسی به Registry خارجی

ابتدا یک Secret برای نگهداری اطلاعات دسترسی به Registry خارجی ایجاد می‌کنیم. به عنوان مثال، اگر بخواهید از Docker Hub استفاده کنید:

kubectl create secret docker-registry my-registry-secret \
  --docker-server=https://index.docker.io/v1/ \
  --docker-username=myuser \
  --docker-password=mypassword \
  --docker-email=myemail@example.com

در این مثال:

• my-registry-secret: نام Secret که برای دسترسی به Docker Hub استفاده می‌شود.
• docker-server: آدرس Registry خارجی (مثلاً Docker Hub).
• docker-username: نام کاربری شما در Docker Hub.
• docker-password: کلمه عبور شما در Docker Hub.
• docker-email: ایمیل حساب Docker Hub شما.

2. استفاده از Secret در Pod

پس از ایجاد Secret، می‌توان از آن در پیکربندی Pod برای دسترسی به Registry خصوصی استفاده کرد. برای این کار، باید Secret را به صورت یک ImagePullSecret در Pod قرار دهیم. نمونه‌ای از پیکربندی Pod که از Secret برای دسترسی به Registry خارجی استفاده می‌کند به شکل زیر است:

apiVersion: v1
kind: Pod
metadata:
  name: my-private-pod
spec:
  containers:
  - name: my-container
    image: my-registry.com/my-image:latest
  imagePullSecrets:
  - name: my-registry-secret

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

• imagePullSecrets: به Kubernetes اعلام می‌کند که از Secret مشخص‌شده برای احراز هویت هنگام کشیدن تصویر از Registry خارجی استفاده کند.

3. محدود کردن دسترسی به Registry خارجی

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

مثال برای ایجاد یک Network Policy که دسترسی به Registry خاصی را محدود می‌کند:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-registry-access
spec:
  podSelector: {}
  ingress:
    - from:
      - podSelector:
          matchLabels:
            app: trusted-app
  egress:
    - to:
      - ipBlock:
          cidr: "192.168.0.0/16"  # فرض بر این است که آدرس IP Registry معتبر در این رنج قرار دارد

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

• podSelector: به Kubernetes می‌گوید که چه Podهایی مشمول این سیاست می‌شوند.
• ingress و egress: دسترسی‌ها به منابع را کنترل می‌کند.
• ipBlock: آدرس‌های IP معتبر برای Registry محدود می‌شوند.

جمع‌بندی

برای امنیت بیشتر در Kubernetes و جلوگیری از بارگذاری تصاویر کانتینرهای غیرمجاز از Registry‌های خارجی، می‌توان از روش‌هایی همچون ImagePullSecrets برای احراز هویت به Registry‌ها و Network Policies برای محدود کردن دسترسی به Registry‌های خاص استفاده کرد. این اقدامات به شما کمک می‌کنند تا از امنیت بالاتری در محیط Kubernetes برخوردار باشید.[/cdb_course_lesson][cdb_course_lesson title=”Resource Quotas:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”تعریف Resource Quotas برای جلوگیری از مصرف بیش از حد منابع” subtitle=”توضیحات کامل”]Resource Quotas در Kubernetes ابزارهایی هستند که به مدیران سیستم این امکان را می‌دهند تا مصرف منابع مانند CPU، حافظه و تعداد شیءهای مختلف (مانند Pod‌ها، Services، PVC‌ها و غیره) را در سطح Namespace محدود کنند. این ابزار برای جلوگیری از مصرف بیش از حد منابع توسط کاربران یا برنامه‌ها در یک Namespace خاص بسیار مفید است.

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

ویژگی‌های Resource Quotas

1. محدود کردن منابع مصرفی: شما می‌توانید میزان مصرف منابع همچون CPU، حافظه، تعداد Pod‌ها، تعداد PVC‌ها و سایر منابع را در سطح Namespace مشخص کنید.
2. مانیتورینگ مصرف منابع: Resource Quotas به شما کمک می‌کنند تا میزان مصرف منابع را در Namespace‌ها نظارت کرده و مانع از تجاوز از مقدار مشخص‌شده شوید.
3. بیشتر استفاده برای محیط‌های چندکاربره: در محیط‌هایی که چند تیم یا کاربر از یک کلاستر Kubernetes استفاده می‌کنند، Resource Quotas ابزار مناسبی برای مدیریت منابع است.

نحوه ایجاد و پیکربندی Resource Quotas

برای استفاده از Resource Quotas، ابتدا باید یک شیء ResourceQuota ایجاد کنید که منابع مختلفی که می‌خواهید محدود کنید، در آن تعریف شود.

1. ایجاد ResourceQuota برای محدود کردن منابع

در این مثال، ResourceQuota‌ای تعریف می‌کنیم که مقدار مصرف حافظه و CPU را محدود می‌کند و تعداد Pod‌ها را نیز مشخص می‌کند:

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

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

• requests.cpu و requests.memory: مقدار منابعی که در هر درخواست می‌توان مصرف کرد.
• limits.cpu و limits.memory: حد حداکثر منابعی که یک Pod می‌تواند مصرف کند.
• pods: حداکثر تعداد Pod‌هایی که می‌توانند در Namespace ایجاد شوند.

2. اعمال ResourceQuota به Namespace

این ResourceQuota به طور خاص برای Namespace my-namespace تعریف شده است. به این ترتیب، هر Pod یا شیء دیگری که در این Namespace ایجاد می‌شود، باید از این محدودیت‌ها تبعیت کند.

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

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

kubectl get resourcequota -n my-namespace

این دستور اطلاعاتی در مورد میزان استفاده از منابع موجود و میزان مصرف فعلی در Namespace مورد نظر نمایش می‌دهد.

4. استفاده از Resource Quotas برای دیگر منابع

علاوه بر محدود کردن CPU و حافظه، ResourceQuota می‌تواند برای محدود کردن انواع دیگری از منابع مانند تعداد Services، PVC‌ها، ConfigMap‌ها و Secrets نیز مورد استفاده قرار گیرد. در زیر یک مثال برای محدود کردن تعداد Services و PVC‌ها آورده شده است:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: my-resource-quota
  namespace: my-namespace
spec:
  hard:
    services: "5"
    persistentvolumeclaims: "5"

جمع‌بندی

Resource Quotas در Kubernetes ابزاری قدرتمند برای جلوگیری از مصرف بیش از حد منابع در یک کلاستر است. این ابزار امکان تخصیص منابع به طور دقیق‌تر را در محیط‌های چندکاربره فراهم می‌آورد و از ایجاد ترافیک اضافی یا بارگذاری بیش از حد منابع جلوگیری می‌کند. با استفاده از Resource Quotas، مدیران سیستم می‌توانند سطح منابعی که هر Namespace یا کاربر می‌تواند استفاده کند را به دقت کنترل کنند، که این امر به بهبود عملکرد و مدیریت منابع در کلاستر کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”مدیریت دسترسی تیم‌ها به منابع مشخص” subtitle=”توضیحات کامل”]مدیریت دسترسی تیم‌ها به منابع مشخص در Kubernetes یکی از جنبه‌های کلیدی مدیریت امنیت و منابع است. در Kubernetes، این کار با استفاده از ابزارهایی مانند Role-Based Access Control (RBAC)، Service Accounts و Namespaces انجام می‌شود که به شما اجازه می‌دهند دسترسی دقیق و کنترل‌شده‌ای را به منابع مختلف در کلاستر فراهم کنید.

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

نحوه مدیریت دسترسی تیم‌ها به منابع

1. استفاده از Namespaces برای جداسازی منابع

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

برای مثال، اگر دو تیم A و B دارید، می‌توانید دو Namespace مجزا برای هر کدام ایجاد کنید:

kubectl create namespace team-a
kubectl create namespace team-b

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

2. استفاده از RBAC برای مدیریت دسترسی به منابع

برای مدیریت دسترسی دقیق‌تر، از RBAC (Role-Based Access Control) استفاده می‌کنیم که اجازه می‌دهد دسترسی به منابع مشخص بر اساس نقش‌های تعریف‌شده تعیین شود. در این سیستم، می‌توانید برای هر تیم یا کاربر، نقش‌هایی ایجاد کرده و دسترسی به منابع را به آن نقش‌ها اختصاص دهید.

مراحل ایجاد Role و RoleBinding

• Role: یک Role مجموعه‌ای از مجوزها را برای منابع در داخل یک Namespace خاص تعریف می‌کند.
• RoleBinding: از طریق RoleBinding می‌توانید یک Role را به کاربران یا Service Account‌ها در یک Namespace خاص اختصاص دهید.

مثال از ایجاد Role برای دسترسی به Pods در Namespace خاص:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: team-a
  name: pod-reader
rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list"]

در این مثال، Role به نام pod-reader تعریف شده است که فقط اجازه دسترسی به Pods در Namespace team-a را با دسترسی‌های get و list می‌دهد.

سپس با استفاده از RoleBinding می‌توان این Role را به یک کاربر یا Service Account اختصاص داد:

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: team-a
subjects:
- kind: User
  name: "team-a-user"  # نام کاربری که می‌خواهیم به این Role اختصاص دهیم
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

در این مثال، RoleBinding به کاربر team-a-user در Namespace team-a اجازه می‌دهد تا از Role pod-reader استفاده کند.

3. استفاده از Service Accounts برای تخصیص دسترسی

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

برای ایجاد یک Service Account برای تیم A:

kubectl create serviceaccount team-a-sa -n team-a

سپس می‌توانید این Service Account را در پیکربندی Pod‌ها یا Deployments برای هر تیم مشخص کنید تا دسترسی‌های آن تیم را مدیریت کنید.

نمونه‌ای از تنظیمات ServiceAccount در Pod

apiVersion: v1
kind: Pod
metadata:
  name: mypod
  namespace: team-a
spec:
  serviceAccountName: team-a-sa
  containers:
  - name: mycontainer
    image: nginx

در این مثال، Pod به Service Account team-a-sa در Namespace team-a متصل است و دسترسی‌ها بر اساس این Service Account مدیریت می‌شوند.

4. استفاده از Network Policies برای محدودسازی ترافیک بین تیم‌ها

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

به طور مثال، می‌توانید دسترسی به Pods تیم A را از تیم B مسدود کنید:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-team-b
  namespace: team-a
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - podSelector:
        matchLabels:
          team: "b"

این NetworkPolicy مانع از این می‌شود که Pods در Namespace team-b به Pods در Namespace team-a دسترسی داشته باشند.

جمع‌بندی

مدیریت دسترسی تیم‌ها به منابع در Kubernetes از اهمیت زیادی برخوردار است. با استفاده از ابزارهایی مانند Namespaces، RBAC، Service Accounts و Network Policies می‌توان دسترسی دقیق به منابع را در سطح کلاستر کنترل کرد. این روش‌ها کمک می‌کنند تا هر تیم یا کاربر تنها به منابع مربوط به خود دسترسی داشته باشد و از ایجاد تداخل یا سوءاستفاده از منابع جلوگیری شود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. مدیریت گواهینامه‌ها و TLS”][/cdb_course_lesson][cdb_course_lesson title=”TLS/SSL در Kubernetes:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”پیکربندی TLS برای ارتباطات بین سرویس‌ها” subtitle=”توضیحات کامل”]یکی از جنبه‌های کلیدی امنیت در Kubernetes، پیکربندی ارتباطات امن بین سرویس‌ها با استفاده از TLS (Transport Layer Security) است. این پروتکل امنیتی برای رمزنگاری ارتباطات شبکه‌ای بین سرویس‌ها به کار می‌رود و از حملات مختلف مانند Man-in-the-Middle (MITM) جلوگیری می‌کند. استفاده از TLS در ارتباطات بین سرویس‌ها باعث می‌شود که داده‌های ارسالی و دریافتی در شبکه به صورت امن منتقل شوند و فقط سرویس‌های معتبر بتوانند با یکدیگر ارتباط برقرار کنند.

در این قسمت، به نحوه پیکربندی TLS برای ارتباطات بین سرویس‌ها در Kubernetes پرداخته خواهد شد.

مراحل پیکربندی TLS برای ارتباطات بین سرویس‌ها

1. ایجاد گواهینامه‌های TLS و کلیدها

برای استفاده از TLS، اولین قدم ایجاد گواهینامه‌ها و کلیدهای SSL است. این گواهینامه‌ها باید توسط یک Certificate Authority (CA) امضا شوند تا اعتبار داشته باشند.

برای تولید یک Certificate و Private Key برای استفاده در Kubernetes می‌توان از دستور openssl استفاده کرد:

# ایجاد کلید خصوصی
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# ایجاد گواهینامه CSR (Certificate Signing Request)
openssl req -new -key server.key -out server.csr -subj "/CN=example.com/O=myorg"

# امضای گواهینامه با استفاده از CA
openssl x509 -req -in server.csr -signkey server.key -out server.crt

در این مرحله، شما دو فایل server.crt (گواهینامه) و server.key (کلید خصوصی) خواهید داشت که برای پیکربندی TLS نیاز دارید.

2. استفاده از Secrets برای ذخیره گواهینامه‌ها و کلیدها

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

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

kubectl create secret tls my-tls-secret --cert=server.crt --key=server.key -n mynamespace

در این دستور:

• my-tls-secret: نام Secret
• server.crt: گواهینامه
• server.key: کلید خصوصی
• mynamespace: Namespace که Secret در آن ذخیره می‌شود

3. پیکربندی سرویس برای استفاده از TLS

برای استفاده از TLS در ارتباطات بین سرویس‌ها، باید سرویس‌ها را به گونه‌ای پیکربندی کنید که از گواهینامه‌های TLS استفاده کنند. این کار معمولاً با استفاده از Ingress Controller یا Mutual TLS (mTLS) انجام می‌شود.

به عنوان مثال، اگر از Ingress Controller برای مدیریت ترافیک ورودی استفاده می‌کنید، باید TLS را در Ingress پیکربندی کنید:

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

در این مثال، گواهینامه TLS از Secret my-tls-secret استفاده می‌کند تا ترافیک ورودی به example.com را به صورت امن رمزنگاری کند.

4. پیکربندی Mutual TLS (mTLS) برای ارتباطات داخلی

برای ارتباطات امن بین سرویس‌ها در داخل کلاستر، می‌توان از Mutual TLS (mTLS) استفاده کرد که در آن هر دو طرف ارتباط (سرویس‌ها) برای اعتبارسنجی و رمزنگاری ترافیک، گواهینامه‌های TLS خود را ارسال می‌کنند. برای پیاده‌سازی mTLS، می‌توان از Istio یا Linkerd به عنوان سرویس‌ مش (Service Mesh) استفاده کرد.

به طور مثال، با Istio می‌توانید Peer Authentication و DestinationRule را برای تنظیم mTLS بین سرویس‌ها پیکربندی کنید:

• ایجاد Peer Authentication برای اجبار mTLS:

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: mynamespace
spec:
  mtls:
    mode: STRICT

• ایجاد DestinationRule برای تنظیم mTLS:

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: my-destination-rule
  namespace: mynamespace
spec:
  host: my-service
  trafficPolicy:
    tls:
      mode: ISTIO_MUTUAL

در این مثال، Istio به طور خودکار mTLS را بین سرویس‌ها فعال می‌کند.

5. پیکربندی سرویس‌ها برای استفاده از TLS

هر سرویس که قرار است از TLS استفاده کند، باید به گونه‌ای پیکربندی شود که از گواهینامه و کلیدهای TLS استفاده کند. این پیکربندی معمولاً در بخش containers در فایل‌های YAML برای هر سرویس انجام می‌شود. به عنوان مثال، در یک سرویس که نیاز به TLS دارد، می‌توانید از Secret‌های ذخیره‌شده برای تنظیم گواهینامه و کلید استفاده کنید:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-service
  namespace: mynamespace
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: my-container
        image: myimage
        volumeMounts:
        - name: tls-secret
          mountPath: /etc/tls
          readOnly: true
      volumes:
      - name: tls-secret
        secret:
          secretName: my-tls-secret

در این پیکربندی، گواهینامه و کلید TLS از Secret my-tls-secret به داخل کانتینر مونت می‌شود و سرویس می‌تواند از آن برای رمزنگاری و ارتباطات امن استفاده کند.

جمع‌بندی

پیکربندی TLS برای ارتباطات بین سرویس‌ها در Kubernetes یکی از مهم‌ترین اقدامات برای حفظ امنیت داده‌ها در حال انتقال است. با استفاده از gRPC و Mutual TLS (mTLS) می‌توان ارتباطات امنی بین سرویس‌ها فراهم کرد. مراحل این کار شامل ایجاد گواهینامه‌های TLS، ذخیره‌سازی آن‌ها به صورت Secret، پیکربندی سرویس‌ها برای استفاده از TLS، و استفاده از Istio یا Linkerd برای پشتیبانی از mTLS می‌باشد. این روش‌ها باعث می‌شوند که ارتباطات بین سرویس‌ها در کلاستر Kubernetes به صورت رمزنگاری‌شده و امن انجام شود.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”ایجاد و مدیریت گواهینامه‌های TLS” subtitle=”توضیحات کامل”]گواهینامه‌های TLS (Transport Layer Security) برای رمزنگاری و تأمین ارتباطات امن در شبکه استفاده می‌شوند. در Kubernetes، این گواهینامه‌ها برای ارتباطات بین سرویس‌ها، Ingress، و همچنین برای ایجاد ارتباطات امن با منابع خارجی ضروری هستند. در این بخش، به نحوه ایجاد و مدیریت گواهینامه‌های TLS در Kubernetes پرداخته خواهد شد.

مراحل ایجاد و مدیریت گواهینامه‌های TLS

1. ایجاد گواهینامه‌های خودامضا (Self-Signed Certificates)

برای تست یا استفاده در محیط‌هایی که نیاز به گواهینامه‌های معتبر از یک Certificate Authority (CA) ندارند، می‌توان از گواهینامه‌های خودامضا استفاده کرد. برای ایجاد یک گواهینامه خودامضا از ابزار openssl استفاده می‌کنیم.

ایجاد گواهینامه و کلید خصوصی با استفاده از دستور openssl:

# ایجاد یک کلید خصوصی
openssl genpkey -algorithm RSA -out server.key -pkeyopt rsa_keygen_bits:2048

# ایجاد درخواست گواهینامه (CSR)
openssl req -new -key server.key -out server.csr -subj "/CN=example.com/O=myorg"

# امضای گواهینامه با استفاده از کلید خصوصی
openssl x509 -req -in server.csr -signkey server.key -out server.crt

در اینجا:

• server.key: کلید خصوصی
• server.crt: گواهینامه

2. استفاده از Kubernetes Secrets برای ذخیره گواهینامه‌ها و کلیدها

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

kubectl create secret tls my-tls-secret --cert=server.crt --key=server.key -n mynamespace

در این دستور:

• my-tls-secret: نام Secret
• server.crt: فایل گواهینامه
• server.key: فایل کلید خصوصی
• mynamespace: نام namespace که Secret در آن ذخیره می‌شود.

3. ایجاد گواهینامه‌های معتبر از یک CA

اگر شما نیاز به گواهینامه‌ای دارید که توسط یک Certificate Authority (CA) معتبر امضا شده باشد، می‌توانید از CA‌های معتبر مانند Let’s Encrypt استفاده کنید. برای استفاده از گواهینامه‌های صادر شده توسط یک CA، معمولاً لازم است که درخواست CSR به CA ارسال شود.

با استفاده از ابزارهایی مانند cert-manager در Kubernetes، می‌توانید فرآیند درخواست، تمدید و مدیریت گواهینامه‌های TLS را خودکار کنید. cert-manager از پروتکل‌هایی مانند ACME (که توسط Let’s Encrypt پشتیبانی می‌شود) برای درخواست گواهینامه‌های TLS از یک CA استفاده می‌کند.

برای نصب cert-manager و پیکربندی آن برای استفاده از Let’s Encrypt، مراحل زیر را دنبال کنید:

• نصب cert-manager:

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml

• ایجاد یک Issuer برای درخواست گواهینامه از Let’s Encrypt:

apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: letsencrypt-prod
  namespace: mynamespace
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: nginx

• درخواست گواهینامه با استفاده از cert-manager:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-tls-certificate
  namespace: mynamespace
spec:
  secretName: my-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: Issuer
  commonName: example.com
  dnsNames:
  - example.com

با این پیکربندی، cert-manager به صورت خودکار گواهینامه‌ای از Let’s Encrypt برای دامنه example.com درخواست می‌کند و آن را به صورت یک Secret در Kubernetes ذخیره می‌کند.

4. مدیریت دوره‌ای گواهینامه‌ها (Certificate Rotation)

گواهینامه‌ها معمولاً یک تاریخ انقضا دارند، بنابراین نیاز به چرخش گواهینامه‌ها (certificate rotation) وجود دارد. در Kubernetes، می‌توانید از ابزارهایی مانند cert-manager برای چرخش خودکار گواهینامه‌ها استفاده کنید.

cert-manager به طور خودکار گواهینامه‌ها را تمدید می‌کند و اگر تاریخ انقضا نزدیک باشد، گواهینامه جدیدی ایجاد کرده و آن را در Secret ذخیره می‌کند.

اگر از گواهینامه‌های دستی استفاده می‌کنید، باید به صورت دستی تاریخ انقضای گواهینامه‌ها را بررسی کرده و آنها را تمدید کنید.

5. پیکربندی TLS در سرویس‌ها

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

یک سرویس نمونه که از گواهینامه TLS استفاده می‌کند:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-tls-app
  namespace: mynamespace
spec:
  replicas: 1
  template:
    spec:
      containers:
      - name: my-app-container
        image: myimage
        ports:
        - containerPort: 443
        volumeMounts:
        - name: tls-volume
          mountPath: /etc/tls
          readOnly: true
      volumes:
      - name: tls-volume
        secret:
          secretName: my-tls-secret

در این پیکربندی، گواهینامه و کلید TLS از Secret my-tls-secret به داخل کانتینر مونت می‌شود و برنامه می‌تواند از آن برای ارتباطات امن استفاده کند.

جمع‌بندی

ایجاد و مدیریت گواهینامه‌های TLS یکی از مهم‌ترین اقدامات برای تأمین ارتباطات امن در Kubernetes است. شما می‌توانید گواهینامه‌های خودامضا برای استفاده داخلی یا گواهینامه‌های معتبر از CAها مانند Let’s Encrypt ایجاد کنید. پس از ایجاد گواهینامه‌ها، باید آنها را در Kubernetes ذخیره کنید و از Secrets برای پیکربندی سرویس‌ها استفاده کنید. همچنین، برای مدیریت گواهینامه‌ها، ابزارهایی مانند cert-manager می‌توانند به شما کمک کنند تا گواهینامه‌ها را به طور خودکار تمدید و مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson title=”Cert Manager:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از Cert Manager برای مدیریت خودکار گواهینامه‌ها” subtitle=”توضیحات کامل”]Cert Manager یک ابزار قدرتمند و اتوماسیون برای مدیریت گواهینامه‌ها در Kubernetes است. این ابزار امکان درخواست، تمدید و مدیریت گواهینامه‌های TLS را به صورت خودکار فراهم می‌کند. Cert Manager از منابع مختلف گواهینامه‌ها مانند Let’s Encrypt، Vault، یا Self-Signed Certificates پشتیبانی می‌کند و برای هر کاربرد خاص گواهینامه‌ها را ایجاد و تمدید می‌کند.

در این بخش، نحوه استفاده از Cert Manager برای مدیریت خودکار گواهینامه‌ها را بررسی خواهیم کرد.

مراحل استفاده از Cert Manager

1. نصب Cert Manager

ابتدا باید Cert Manager را در کلاستر Kubernetes خود نصب کنید. نصب Cert Manager از طریق دستور زیر انجام می‌شود:

kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml

این دستور، تمامی منابع لازم برای اجرای Cert Manager را در کلاستر Kubernetes شما نصب می‌کند.

2. ایجاد Issuer یا ClusterIssuer

برای درخواست گواهینامه‌ها، باید یک Issuer یا ClusterIssuer ایجاد کنید. Issuer برای یک namespace خاص و ClusterIssuer برای تمام کلاستر به کار می‌رود.

برای استفاده از Let’s Encrypt، از یک Issuer یا ClusterIssuer استفاده می‌کنیم که از پروتکل ACME پشتیبانی کند. برای استفاده از Let’s Encrypt در حالت Production، می‌توان از دستور زیر برای ایجاد یک ClusterIssuer استفاده کرد:

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: letsencrypt-prod
spec:
  acme:
    server: https://acme-v02.api.letsencrypt.org/directory
    email: your-email@example.com
    privateKeySecretRef:
      name: letsencrypt-prod-key
    solvers:
    - http01:
        ingress:
          class: nginx

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

• server: آدرس سرور Let’s Encrypt
• email: ایمیل شما که برای ثبت درخواست‌ها در Let’s Encrypt استفاده می‌شود
• privateKeySecretRef: نام Secret که کلید خصوصی مربوط به این Issuer را ذخیره می‌کند.
• solvers: تنظیماتی که نشان می‌دهند Cert Manager چگونه می‌تواند چالش‌های DNS یا HTTP را حل کند (در این مثال از روش HTTP استفاده شده است).

برای ایجاد این ClusterIssuer در Kubernetes از دستور زیر استفاده کنید:

kubectl apply -f letsencrypt-prod-clusterissuer.yaml

3. ایجاد درخواست گواهینامه (Certificate)

پس از ایجاد Issuer یا ClusterIssuer، می‌توانید از آن برای درخواست گواهینامه استفاده کنید. برای این کار، یک Certificate ایجاد می‌کنیم.

به عنوان مثال، برای درخواست گواهینامه برای دامنه example.com، فایل YAML زیر را ایجاد می‌کنیم:

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: my-tls-certificate
  namespace: mynamespace
spec:
  secretName: my-tls-secret
  issuerRef:
    name: letsencrypt-prod
    kind: ClusterIssuer
  commonName: example.com
  dnsNames:
  - example.com

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

• secretName: نام Secret که گواهینامه و کلید خصوصی در آن ذخیره خواهند شد.
• issuerRef: ارجاع به Issuer یا ClusterIssuer که گواهینامه را صادر می‌کند.
• commonName: نام دامنه‌ای که گواهینامه برای آن صادر می‌شود.
• dnsNames: لیستی از نام‌های دامنه برای گواهینامه.

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

kubectl apply -f my-tls-certificate.yaml

پس از اعمال این پیکربندی، Cert Manager به صورت خودکار گواهینامه را از Let’s Encrypt درخواست کرده و آن را به Secret my-tls-secret ذخیره می‌کند.

4. استفاده از گواهینامه در سرویس‌ها

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

یک پیکربندی نمونه برای استفاده از گواهینامه TLS در Ingress به صورت زیر است:

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

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

• بخش tls مشخص می‌کند که این Ingress از گواهینامه TLS برای دامنه example.com استفاده کند.
• secretName: نام Secret که گواهینامه TLS در آن ذخیره شده است.

5. مدیریت تمدید گواهینامه‌ها

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

با استفاده از cert-manager دیگر نیازی به نگرانی در مورد تمدید دستی گواهینامه‌ها نخواهید داشت و این فرآیند به طور کامل خودکار خواهد بود.

جمع‌بندی

Cert Manager یک ابزار قوی برای مدیریت گواهینامه‌های TLS در Kubernetes است که می‌تواند درخواست، تمدید و مدیریت گواهینامه‌ها را به صورت خودکار انجام دهد. با استفاده از Cert Manager می‌توانید گواهینامه‌ها را از Let’s Encrypt یا منابع دیگر دریافت کنید و آنها را در Kubernetes به طور ایمن ذخیره کرده و از آنها در سرویس‌ها و Ingress‌ها استفاده کنید. همچنین، Cert Manager به صورت خودکار گواهینامه‌ها را تمدید کرده و این فرآیند را برای شما ساده می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”صدور و تمدید خودکار گواهینامه‌های SSL” subtitle=”توضیحات کامل”]گواهینامه‌های SSL/TLS برای ایمن‌سازی ارتباطات بین کاربران و سرورها از طریق رمزنگاری استفاده می‌شوند. صدور و تمدید خودکار گواهینامه‌ها یکی از نیازهای مهم در محیط‌های تولیدی است، به‌ویژه در Kubernetes که معمولا از سرویس‌ها، Ingress‌ها و دیگر منابع برای ارتباطات استفاده می‌شود. یکی از ابزارهای معروف برای انجام این فرآیند در Kubernetes Cert Manager است. این ابزار امکان درخواست، صدور و تمدید خودکار گواهینامه‌های SSL را فراهم می‌آورد.

در این بخش، به بررسی نحوه صدور و تمدید خودکار گواهینامه‌های SSL با استفاده از Cert Manager خواهیم پرداخت.

مراحل صدور و تمدید خودکار گواهینامه‌های SSL

1. نصب Cert Managerبرای استفاده از Cert Manager در Kubernetes، ابتدا باید این ابزار را نصب کنید. دستور نصب Cert Manager از طریق Kubernetes به شرح زیر است:

   kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.7.1/cert-manager.yaml
   

   این دستور تمام منابع لازم برای راه‌اندازی Cert Manager را در کلاستر Kubernetes شما نصب می‌کند.

2. ایجاد Issuer یا ClusterIssuerبرای درخواست گواهینامه‌های SSL، نیاز است تا یک Issuer یا ClusterIssuer ایجاد کنید. Issuer مخصوص یک namespace است و ClusterIssuer به‌طور سراسری در تمام کلاستر در دسترس است.برای استفاده از Let’s Encrypt در Cert Manager، می‌توان از یک ClusterIssuer استفاده کرد که از پروتکل ACME پشتیبانی کند. نمونه‌ای از پیکربندی ClusterIssuer برای Let’s Encrypt به شرح زیر است:

   apiVersion: cert-manager.io/v1
   kind: ClusterIssuer
   metadata:
     name: letsencrypt-prod
   spec:
     acme:
       server: https://acme-v02.api.letsencrypt.org/directory
       email: your-email@example.com
       privateKeySecretRef:
         name: letsencrypt-prod-key
       solvers:
         - http01:
             ingress:
               class: nginx
   

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

   • server: سرور ACME که به Let’s Encrypt اشاره دارد.
   • email: ایمیلی که برای مدیریت درخواست‌ها استفاده می‌شود.
   • privateKeySecretRef: Secret برای ذخیره کلید خصوصی مربوط به درخواست‌های ACME.
   • solvers: روش‌هایی که Cert Manager برای حل چالش‌های دامنه استفاده می‌کند. در این مثال، از چالش HTTP استفاده شده است.

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

   kubectl apply -f letsencrypt-prod-clusterissuer.yaml
   

3. درخواست گواهینامه SSLپس از ایجاد Issuer یا ClusterIssuer، می‌توانید درخواست گواهینامه SSL برای دامنه‌های خود ارسال کنید. در اینجا، یک Certificate ایجاد می‌کنیم که به Issuer یا ClusterIssuer ارجاع می‌دهد و برای دامنه‌ی خاص گواهینامه درخواست می‌کند.نمونه‌ای از درخواست گواهینامه برای دامنه example.com به شکل زیر است:

   apiVersion: cert-manager.io/v1
   kind: Certificate
   metadata:
     name: example-com-tls
     namespace: default
   spec:
     secretName: example-com-tls-secret
     issuerRef:
       name: letsencrypt-prod
       kind: ClusterIssuer
     commonName: example.com
     dnsNames:
       - example.com
   

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

   • secretName: نام Secret که گواهینامه و کلید خصوصی آن ذخیره خواهند شد.
   • issuerRef: ارجاع به Issuer یا ClusterIssuer که مسئول صدور گواهینامه است.
   • commonName: نام دامنه‌ای که گواهینامه برای آن درخواست می‌شود.
   • dnsNames: لیستی از نام‌های دامنه که گواهینامه برای آنها معتبر خواهد بود.

   برای درخواست گواهینامه از دستور زیر استفاده کنید:

   kubectl apply -f example-com-tls-certificate.yaml
   

4. استفاده از گواهینامه در سرویس‌ها و Ingressبعد از دریافت گواهینامه، می‌توانید از آن در سرویس‌ها یا Ingressها استفاده کنید. در اینجا، از گواهینامه SSL صادر شده برای یک Ingress استفاده خواهیم کرد.نمونه‌ای از پیکربندی Ingress برای استفاده از گواهینامه SSL به شکل زیر است:

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

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

   • بخش tls مشخص می‌کند که این Ingress از گواهینامه SSL برای دامنه example.com استفاده کند.
   • secretName: نام Secret که گواهینامه و کلید خصوصی در آن ذخیره شده است.
5. مدیریت تمدید گواهینامه‌هاCert Manager به صورت خودکار گواهینامه‌ها را تمدید می‌کند. زمانی که یک گواهینامه به پایان اعتبار خود نزدیک می‌شود، Cert Manager به طور خودکار درخواست تمدید ارسال کرده و پس از دریافت گواهینامه جدید، آن را به Secret مربوطه بروزرسانی می‌کند.تمدید خودکار گواهینامه‌ها به صورت کاملاً اتوماتیک انجام می‌شود و شما نیازی به نگرانی برای تمدید دستی گواهینامه‌ها نخواهید داشت.

جمع‌بندی

با استفاده از Cert Manager، می‌توان فرآیند صدور و تمدید خودکار گواهینامه‌های SSL/TLS را به‌طور ساده و امن مدیریت کرد. این ابزار با استفاده از منابع مانند Let’s Encrypt و دیگر سرویس‌ها، گواهینامه‌ها را به طور خودکار درخواست، صادر و تمدید می‌کند. همچنین، این گواهینامه‌ها به‌راحتی در Ingress‌ها و سرویس‌های Kubernetes استفاده می‌شوند و این روند به‌صورت خودکار مدیریت می‌شود، که به بهبود امنیت ارتباطات در Kubernetes کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. شناسایی و رفع آسیب‌پذیری‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”بررسی حملات رایج مانند Privilege Escalation و Data Exfiltration” subtitle=”توضیحات کامل”]Kubernetes یک سیستم قدرتمند برای مدیریت و ارکستراسیون کانتینرهاست، اما مانند هر سیستم پیچیده دیگری، ممکن است در معرض حملات و آسیب‌پذیری‌های مختلف قرار گیرد. در این بخش به بررسی دو حمله رایج، Privilege Escalation و Data Exfiltration، که می‌تواند در محیط Kubernetes رخ دهد، خواهیم پرداخت.

بررسی حملات رایج در Kubernetes

1. Privilege Escalation

Privilege Escalation به معنای ارتقاء دسترسی یک کاربر یا فرآیند از سطح دسترسی پایین‌تر به سطح بالاتر (مثلاً از کاربر معمولی به کاربر ریشه) است. این حمله یکی از بزرگترین تهدیدات در هر سیستم‌عامل و به‌ویژه در Kubernetes است که می‌تواند به نفوذگران اجازه دهد تا دسترسی کامل به کلاستر داشته باشند.

در Kubernetes، چندین سناریو وجود دارد که می‌توانند موجب Privilege Escalation شوند، از جمله:

• اجرای کانتینر با دسترسی ریشه (root): یکی از شایع‌ترین دلایل این نوع حمله، اجرای کانتینرها با دسترسی ریشه است. اگر کانتینری که به‌طور اشتباه با دسترسی ریشه اجرا شود، مهاجم می‌تواند به راحتی دسترسی به سیستم عامل میزبان پیدا کند.
• استفاده از Podهای Privileged: Podهایی که در حالت privileged اجرا می‌شوند، به‌طور کامل به منابع سیستم عامل میزبان دسترسی دارند. این باعث می‌شود که اگر مهاجم بتواند به یک Pod privileged دسترسی پیدا کند، به‌طور بالقوه قادر به اجرای دستورات مدیریتی بر روی سیستم میزبان باشد.
• استفاده از Capabilities لینوکس: اگر یک کانتینر دارای دسترسی به قابلیت‌های خاص لینوکس باشد، می‌تواند به راحتی از این قابلیت‌ها برای ارتقاء دسترسی خود استفاده کند.

برای جلوگیری از Privilege Escalation، توصیه‌هایی وجود دارد:

• اطمینان حاصل کنید که Security Context کانتینرها و Podها به‌درستی پیکربندی شده‌اند.
• از Pod Security Policies (اگرچه به‌طور رسمی Deprecated شده است) یا جایگزین‌های آن برای محدودسازی دسترسی‌های غیرضروری استفاده کنید.
• کانتینرها را با کاربرهای غیر ریشه اجرا کنید و از اجرای کانتینرها در حالت privileged خودداری کنید.
• به‌جای اعطای دسترسی کامل به قابلیت‌های سیستم، تنها آن دسته از قابلیت‌های لینوکس را که برای عملکرد کانتینر لازم است، اعطا کنید.

2. Data Exfiltration

Data Exfiltration به معنای انتقال غیرمجاز داده‌ها از یک سیستم به مقصد دیگر است. این نوع حمله در Kubernetes می‌تواند از طریق کانتینرها، Podها و یا حتی سرویس‌های خارجی انجام شود. در محیط Kubernetes، موارد زیر می‌توانند منجر به Data Exfiltration شوند:

• دسترسی به Secrets و ConfigMaps: اگر یک مهاجم بتواند به Secrets و ConfigMaps که معمولاً شامل اطلاعات حساس مانند توکن‌های دسترسی، رمزهای عبور و کلیدهای API هستند، دسترسی پیدا کند، ممکن است بتواند داده‌های حساسی را استخراج کند.
• عدم مدیریت دسترسی به منابع: اگر دسترسی به منابع مختلف Kubernetes به‌درستی مدیریت نشود، ممکن است مهاجم بتواند به منابعی که به او تعلق ندارد، دسترسی پیدا کند و داده‌های مهم را از سیستم خارج کند.
• عدم استفاده از Encryption: اگر داده‌ها در حال انتقال و یا ذخیره‌سازی رمزنگاری نشوند، ممکن است در حین انتقال داده‌ها به بیرون از شبکه یا در زمان ذخیره‌سازی به‌راحتی قابل استخراج باشند.

برای جلوگیری از Data Exfiltration، اقدامات زیر می‌توانند مفید باشند:

• استفاده از RBAC برای محدودسازی دسترسی به منابع حساس.
• تنظیم Network Policies برای مسدود کردن ترافیک خروجی غیرمجاز از Podها.
• ذخیره‌سازی و انتقال داده‌ها با استفاده از Encryption به‌ویژه در حالت Encryption at Rest و Encryption in Transit.
• محدودسازی دسترسی به Secrets و ConfigMaps و استفاده از روش‌هایی مانند HashiCorp Vault یا Kubernetes Secrets Management برای مدیریت داده‌های حساس.
• بررسی و نظارت دقیق بر Audit Logs برای شناسایی هرگونه فعالیت مشکوک در سیستم.

جمع‌بندی

حملات Privilege Escalation و Data Exfiltration از جمله حملات رایج و خطرناک در محیط‌های Kubernetes هستند که می‌توانند آسیب‌های جدی به امنیت سیستم وارد کنند. برای مقابله با این تهدیدات، پیاده‌سازی کنترل‌های امنیتی مناسب نظیر RBAC، استفاده از Network Policies برای محدودسازی ترافیک شبکه، و تنظیم Security Context کانتینرها به‌درستی ضروری است. علاوه بر این، استفاده از گواهینامه‌های امنیتی مانند Encryption در تمام مراحل ذخیره‌سازی و انتقال داده‌ها می‌تواند از Data Exfiltration جلوگیری کند.[/cdb_course_lesson][cdb_course_lesson title=”ابزارهای شناسایی آسیب‌پذیری:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”استفاده از ابزارهای امنیتی مانند Trivy و Kube-bench” subtitle=”توضیحات کامل”]برای حفظ امنیت کلاسترهای Kubernetes، شناسایی آسیب‌پذیری‌ها در اجزای مختلف سیستم بسیار مهم است. در این راستا، ابزارهای مختلفی وجود دارند که می‌توانند به شناسایی مشکلات امنیتی و آسیب‌پذیری‌ها در کانتینرها، Podها، تصاویر Docker، تنظیمات Kubernetes و زیرساخت کمک کنند. در این بخش به معرفی و استفاده از دو ابزار قدرتمند، Trivy و Kube-bench برای شناسایی آسیب‌پذیری‌ها پرداخته می‌شود.

1. استفاده از Trivy

Trivy یک ابزار شناخته شده و متن‌باز برای شناسایی آسیب‌پذیری‌ها در تصاویر Docker است. این ابزار به طور ویژه برای یافتن آسیب‌پذیری‌ها در کانتینرها و بسته‌های نرم‌افزاری که در آن‌ها وجود دارد، طراحی شده است. Trivy می‌تواند آسیب‌پذیری‌های موجود در images، file systems و Git repositories را شناسایی کند.

ویژگی‌های Trivy:

• اسکن تصاویر Docker: Trivy می‌تواند به‌طور خودکار تصاویر Docker را اسکن کرده و آسیب‌پذیری‌های موجود را شناسایی کند.
• پشتیبانی از انواع آسیب‌پذیری‌ها: آسیب‌پذیری‌های مربوط به کتابخانه‌ها و پکیج‌ها، سیستم‌عامل‌ها و کانتینرها را شناسایی می‌کند.
• پشتیبانی از اسکن در زمان واقعی: می‌توان آن را به‌طور خودکار در سیستم CI/CD برای اسکن تصاویر در زمان ساخت اضافه کرد.

نصب Trivy:

برای نصب Trivy در سیستم خود، می‌توانید از دستور زیر استفاده کنید:

# برای سیستم‌های مبتنی بر Debian/Ubuntu:
sudo apt-get install -y wget
wget https://github.com/aquasecurity/trivy/releases/download/v0.39.0/trivy_0.39.0_Linux-64bit.deb
sudo dpkg -i trivy_0.39.0_Linux-64bit.deb

# برای سیستم‌های macOS:
brew install aquasecurity/trivy/trivy

اسکن تصاویر با Trivy:

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

trivy image <image_name>

مثال:

trivy image ubuntu:latest

این دستور تمامی آسیب‌پذیری‌های موجود در تصویر ubuntu:latest را شناسایی کرده و نمایش می‌دهد.

2. استفاده از Kube-bench

Kube-bench یک ابزار متن‌باز است که به‌طور خاص برای ارزیابی امنیتی کلاسترهای Kubernetes طراحی شده است. این ابزار با استفاده از معیارهای CIS Kubernetes Benchmark (CIS Kubernetes Security Benchmark) به بررسی پیکربندی‌های امنیتی در کلاسترهای Kubernetes می‌پردازد و گزارش‌هایی از آسیب‌پذیری‌ها و تنظیمات نادرست ارائه می‌دهد.

ویژگی‌های Kube-bench:

• مطابقت با CIS Kubernetes Benchmark: این ابزار به‌طور دقیق تنظیمات امنیتی را با استانداردهای CIS مقایسه می‌کند.
• ارزیابی خودکار کلاستر: Kube-bench به‌طور خودکار پیکربندی‌های مختلف کلاستر را بررسی کرده و گزارشی از آسیب‌پذیری‌ها و مشکلات امنیتی آن‌ها ارائه می‌دهد.
• گزارش‌دهی جامع: گزارش‌هایی دقیق و جزئی از وضعیت امنیتی کلاستر و هشدارهای مربوط به مسائل امنیتی دریافت می‌کنید.

نصب Kube-bench:

برای نصب Kube-bench، می‌توانید از دستور زیر استفاده کنید:

# دانلود و نصب Kube-bench به‌صورت مستقیم از GitHub:
curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.0/kube-bench-0.6.0-linux-amd64.tar.gz -o kube-bench.tar.gz
tar -xvzf kube-bench.tar.gz
cd kube-bench-0.6.0-linux-amd64
sudo mv kube-bench /usr/local/bin/

اجرای Kube-bench:

برای اجرای Kube-bench و بررسی وضعیت امنیتی کلاستر Kubernetes، دستور زیر را وارد کنید:

kube-bench run --targets Node

این دستور تنظیمات امنیتی مربوط به Node در کلاستر را بررسی می‌کند. شما می‌توانید با تغییر گزینه --targets به بررسی دیگر بخش‌ها (مانند ControlPlane یا Etcd) بپردازید.

پیکربندی و گزارش‌دهی:

پس از اجرای Kube-bench، گزارشی شامل مشکلات امنیتی و تنظیمات نادرست کلاستر نمایش داده می‌شود. شما می‌توانید این گزارش‌ها را برای اصلاح و بهبود امنیت کلاستر خود استفاده کنید.

جمع‌بندی

برای شناسایی و مدیریت آسیب‌پذیری‌ها در محیط Kubernetes، استفاده از ابزارهای امنیتی مانند Trivy و Kube-bench بسیار مؤثر است. Trivy ابزاری عالی برای شناسایی آسیب‌پذیری‌های موجود در تصاویر Docker است، در حالی که Kube-bench به شما کمک می‌کند تا وضعیت امنیتی کلاستر Kubernetes خود را با معیارهای معتبر جهانی ارزیابی کنید. استفاده از این ابزارها به شما این امکان را می‌دهد که مشکلات امنیتی را شناسایی کرده و تدابیر لازم را برای رفع آن‌ها اتخاذ کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”اسکن Cluster برای شناسایی تنظیمات ناامن” subtitle=”توضیحات کامل”]اسکن کلاستر Kubernetes برای شناسایی تنظیمات ناامن یک بخش حیاتی از فرآیند تضمین امنیت در کلاسترهای Kubernetes است. تنظیمات نادرست و ناامن می‌توانند به مهاجمین اجازه دهند تا به منابع حساس دسترسی پیدا کنند یا به سایر مشکلات امنیتی منجر شوند. ابزارهای مختلفی برای شناسایی این تنظیمات ناامن وجود دارند که به شما کمک می‌کنند تا سطح امنیتی کلاستر خود را بررسی کنید و اقدامات اصلاحی لازم را انجام دهید.

در این بخش، به دو ابزار محبوب و کارآمد برای اسکن کلاستر Kubernetes و شناسایی تنظیمات ناامن، یعنی Kube-bench و kube-score خواهیم پرداخت.

1. استفاده از Kube-bench برای اسکن تنظیمات ناامن کلاستر

Kube-bench یکی از ابزارهای قدرتمند و متن‌باز است که برای اسکن و ارزیابی تنظیمات امنیتی کلاسترهای Kubernetes طراحی شده است. این ابزار از معیارهای CIS Kubernetes Benchmark استفاده می‌کند و می‌تواند تنظیمات ناامن موجود در کلاستر را شناسایی کند.

مراحل نصب و استفاده از Kube-bench:

1. نصب Kube-bench: برای نصب این ابزار، می‌توانید از دستور زیر استفاده کنید:

   # دانلود و نصب Kube-bench به‌صورت مستقیم از GitHub:
   curl -L https://github.com/aquasecurity/kube-bench/releases/download/v0.6.0/kube-bench-0.6.0-linux-amd64.tar.gz -o kube-bench.tar.gz
   tar -xvzf kube-bench.tar.gz
   cd kube-bench-0.6.0-linux-amd64
   sudo mv kube-bench /usr/local/bin/
   

2. اجرای Kube-bench: بعد از نصب، برای اسکن کلاستر Kubernetes خود، می‌توانید از دستور زیر استفاده کنید. این دستور به‌طور پیش‌فرض تمامی تنظیمات مربوط به Node، Control Plane و Etcd را بررسی می‌کند:

   kube-bench run
   

   شما می‌توانید اسکن را بر اساس بخش‌های مختلف کلاستر مانند ControlPlane، Node یا Etcd انجام دهید:

   kube-bench run --targets Node
   

3. تحلیل گزارش‌ها: پس از اجرای Kube-bench، گزارشی شامل نتایج بررسی تنظیمات امنیتی کلاستر و شناسایی آسیب‌پذیری‌ها و تنظیمات نادرست در کلاستر به شما نمایش داده می‌شود. این گزارش‌ها شامل هشدارها و توصیه‌هایی برای اصلاح تنظیمات ناامن خواهند بود.

2. استفاده از kube-score برای ارزیابی تنظیمات Pod

kube-score ابزاری است که برای ارزیابی پیکربندی‌های YAML مربوط به منابع Kubernetes مانند Pods، Deployments و دیگر منابع Kubernetes طراحی شده است. این ابزار به شما کمک می‌کند تا مشکلات امنیتی و پیکربندی‌های نادرست در منابع مختلف را شناسایی کنید.

مراحل نصب و استفاده از kube-score:

1. نصب kube-score: برای نصب این ابزار، از دستور زیر استفاده کنید:

   # نصب با استفاده از Homebrew (برای macOS):
   brew install kube-score
   
   # نصب با استفاده از curl (برای سیستم‌های لینوکس):
   curl -s https://api.github.com/repos/zegl/kube-score/releases/latest | \
   jq -r ".assets[] | select(.name | test(\"Linux-x86_64\")) | .browser_download_url" | \
   xargs curl -LO
   tar -xvzf kube-score-* && sudo mv kube-score /usr/local/bin/
   

2. اجرای kube-score برای بررسی منابع Kubernetes: برای بررسی منابع Kubernetes، کافی است فایل YAML مورد نظر خود را به دستور زیر وارد کنید:

   kube-score score <your-kubernetes-manifest>.yaml
   

   این ابزار موارد مختلفی مانند Security Contexts، ImagePullPolicy، Resource Requests/Limits، Labels و دیگر تنظیمات امنیتی را بررسی کرده و به شما گزارش می‌دهد.

3. تحلیل گزارش‌ها: بعد از اجرای دستور، kube-score گزارشی را به شما نشان خواهد داد که شامل پیشنهادات و مشکلات مربوط به منابع Kubernetes است. اگر تنظیمات امنیتی یا پیکربندی‌های نادرستی وجود داشته باشد، آن‌ها را شناسایی و برای اصلاح آن‌ها توصیه‌هایی ارائه می‌دهد.

3. استفاده از Kubectl و کدهای تست

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

kubectl auth can-i create pod --as=system:serviceaccount:<namespace>:<serviceaccount-name>

این دستور بررسی می‌کند که آیا یک ServiceAccount خاص دسترسی لازم برای ایجاد Pod را دارد یا خیر. این نوع اسکن‌ها می‌توانند به شناسایی مسائل امنیتی در کلاستر کمک کنند.

جمع‌بندی

برای شناسایی تنظیمات ناامن در کلاستر Kubernetes، استفاده از ابزارهایی مانند Kube-bench و kube-score بسیار مفید است. Kube-bench به شما کمک می‌کند تا مطابق با معیارهای CIS Kubernetes Benchmark تنظیمات امنیتی کلاستر خود را ارزیابی کنید، در حالی که kube-score برای ارزیابی تنظیمات YAML منابع Kubernetes و شناسایی مشکلات امنیتی در آن‌ها طراحی شده است. همچنین ابزارهای خط فرمان مانند kubectl می‌توانند به شما در تحلیل دسترسی‌ها و شناسایی تنظیمات اشتباه کمک کنند. این ابزارها به شما این امکان را می‌دهند که مشکلات امنیتی کلاستر را شناسایی کرده و اقدامات اصلاحی را انجام دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” title=”Patch Management: به‌روزرسانی مداوم Cluster و اجزای آن برای جلوگیری از سوءاستفاده” subtitle=”توضیحات کامل”]یکی از مهمترین جنبه‌های حفظ امنیت در یک کلاستر کوبرنتیز، Patch Management است. این فرآیند شامل به‌روزرسانی مداوم نرم‌افزارها و اجزای مختلف کلاستر برای رفع آسیب‌پذیری‌ها و جلوگیری از سوءاستفاده‌های احتمالی است. با توجه به اینکه حملات به سیستم‌های ناامن در هر لحظه ممکن است انجام شود، به‌روزرسانی اجزای مختلف سیستم به صورت مداوم از نظر امنیتی از اهمیت ویژه‌ای برخوردار است.

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

1. اهمیت به‌روزرسانی اجزای کلاستر

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

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

2. نحوه انجام Patch Management در Kubernetes

برای انجام به‌روزرسانی در Kubernetes و اجزای مختلف آن، فرآیندهای مختلفی باید طی شود. در اینجا، نحوه انجام به‌روزرسانی برای اجزای مختلف Kubernetes توضیح داده می‌شود:

2.1 به‌روزرسانی Kubernetes Cluster

به‌روزرسانی Kubernetes کلاستر شامل به‌روزرسانی نسخه‌های مختلف مانند کنترل پلن (Control Plane)، نودها (Nodes) و سرویس‌های مختلف کلاستر است.

• برای به‌روزرسانی نسخه کنترل پلن می‌توانید از ابزار kubeadm استفاده کنید. ابتدا نسخه جدید را در سیستم خود نصب کنید و سپس کنترل پلن را به‌روزرسانی کنید:
  1. به‌روزرسانی kubeadm:

     sudo apt-get update && sudo apt-get install -y kubeadm=<new-version>
     

  2. به‌روزرسانی Control Plane: پس از به‌روزرسانی kubeadm، از دستور زیر برای به‌روزرسانی کنترل پلن استفاده کنید:

     sudo kubeadm upgrade apply v<new-version>
     

  3. به‌روزرسانی نودها: برای به‌روزرسانی نودهای Kubernetes، از دستور زیر استفاده کنید:

     sudo apt-get update && sudo apt-get install -y kubelet=<new-version>
     sudo systemctl restart kubelet
     

  4. تأیید به‌روزرسانی: پس از به‌روزرسانی، می‌توانید از دستور زیر برای بررسی وضعیت کلاستر و نودها استفاده کنید:

     kubectl get nodes
     

2.2 به‌روزرسانی Containers و Images

یکی از مهمترین اجزای Kubernetes کانتینرها و ایمیج‌های مورد استفاده در Podها هستند. این اجزا باید به‌طور مداوم به‌روزرسانی شوند تا از آسیب‌پذیری‌های شناخته شده جلوگیری شود.

• به‌روزرسانی تصاویر کانتینرها به‌طور معمول با استفاده از دستورات زیر انجام می‌شود:
  1. Pull کردن تصویر جدید:

     docker pull <image-name>:<new-version>
     

  2. به‌روزرسانی Deployment: پس از به‌روزرسانی تصویر، برای به‌روزرسانی Podها و اطمینان از استفاده از تصویر جدید، از دستور زیر برای آپدیت کردن Deployment استفاده کنید:

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

  3. تأیید به‌روزرسانی: برای بررسی اینکه Pods جدید با تصویر به‌روز در حال اجرا هستند، می‌توانید از دستور زیر استفاده کنید:

     kubectl get pods
     

2.3 به‌روزرسانی Plugins و Extensions

در Kubernetes، پلاگین‌ها و افزونه‌ها (مانند Helm charts، Network Policies و Ingress controllers) نیز نیاز به به‌روزرسانی دارند.

• به‌روزرسانی Helm Charts: برای به‌روزرسانی Helm charts به نسخه جدید، می‌توانید از دستور زیر استفاده کنید:

  helm repo update
  helm upgrade <release-name> <chart-name> --version <new-version>
  

• به‌روزرسانی Ingress Controllers: به‌روزرسانی Ingress controller نیز از طریق دستوراتی مشابه با دستور زیر انجام می‌شود:

  kubectl apply -f ingress-controller.yaml
  

3. استفاده از ابزارهای خودکار برای Patch Management

برای ساده‌سازی فرآیند به‌روزرسانی و Patch Management در کلاسترهای Kubernetes، می‌توانید از ابزارهای خودکاری مانند Kured استفاده کنید که برای به‌روزرسانی خودکار نودها طراحی شده است.

• نصب Kured:

  kubectl apply -f https://raw.githubusercontent.com/weaveworks/kured/master/deploy/kured.yaml
  

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

جمع‌بندی

Patch Management یک بخش حیاتی از امنیت کلاستر Kubernetes است که به به‌روزرسانی منظم اجزای مختلف کلاستر برای جلوگیری از آسیب‌پذیری‌ها و سوءاستفاده‌ها کمک می‌کند. فرآیند به‌روزرسانی کلاستر شامل به‌روزرسانی اجزای مختلف مانند کنترل پلن، نودها، کانتینرها و تصاویر، پلاگین‌ها و افزونه‌ها است. استفاده از ابزارهای خودکار مانند Kured می‌تواند این فرآیند را تسهیل کند. با به‌روزرسانی منظم و مراقبت از اجزای مختلف کلاستر، می‌توان از تهدیدات امنیتی جلوگیری کرده و پایداری و کارایی کلاستر را حفظ کرد.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 6. نظارت و Debugging در Kubernetes”][cdb_course_lesson title=”فصل 1. مشاهده و بررسی لاگ‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دستور kubectl logs: مشاهده لاگ‌های یک Pod” subtitle=”توضیحات کامل”]یکی از ابزارهای کلیدی برای اشکال‌زدایی (Debugging) و نظارت بر عملکرد برنامه‌های در حال اجرا در Kubernetes، دستور kubectl logs است. این دستور امکان مشاهده لاگ‌های یک Pod یا Container را فراهم می‌کند. در این بخش، نحوه استفاده از kubectl logs برای مشاهده لاگ‌های یک Pod و گزینه‌های مختلف آن بررسی می‌شود.

---

مشاهده لاگ‌های یک Pod

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

kubectl logs <pod-name>

مثال:

kubectl logs my-pod

این دستور لاگ‌های اصلی مربوط به اولین کانتینر موجود در Pod را نمایش می‌دهد.

---

مشاهده لاگ‌های یک Container در یک Pod چندکانتینری

اگر یک Pod شامل چندین Container باشد، باید نام کانتینر موردنظر را مشخص کنید:

kubectl logs <pod-name> -c <container-name>

مثال:

kubectl logs my-pod -c my-container

---

مشاهده لاگ‌های جدید به‌صورت زنده (Live Streaming)

برای مشاهده لاگ‌های زنده و در حال جریان یک Pod می‌توان از فلگ -f (معادل --follow) استفاده کرد:

kubectl logs -f <pod-name>

مثال:

kubectl logs -f my-pod

این دستور به‌صورت Real-time لاگ‌ها را نمایش داده و تا زمانی که اجرا شود، هر خط جدیدی که در لاگ‌ها نوشته شود نمایش داده خواهد شد.

---

مشاهده لاگ‌های Pod بر اساس بازه زمانی مشخص

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

kubectl logs <pod-name> --since=1h

مثال:

kubectl logs my-pod --since=30m

این دستور فقط لاگ‌های تولید شده در ۳۰ دقیقه اخیر را نمایش می‌دهد.

---

مشاهده تعداد مشخصی از خطوط آخر لاگ

گاهی اوقات ممکن است بخواهید فقط N خط آخر لاگ‌ها را مشاهده کنید. برای این کار از گزینه --tail استفاده کنید:

kubectl logs <pod-name> --tail=<number>

مثال:

kubectl logs my-pod --tail=100

این دستور فقط ۱۰۰ خط آخر لاگ را نمایش می‌دهد.

---

مشاهده لاگ‌های یک Pod که دیگر اجرا نمی‌شود (CrashLoopBackOff)

اگر Pod شما به هر دلیلی Crash کرده باشد، می‌توان لاگ‌های آخرین اجرای آن را مشاهده کرد:

kubectl logs <pod-name> --previous

مثال:

kubectl logs my-crashed-pod --previous

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

---

مشاهده لاگ‌های چندین Pod به‌صورت هم‌زمان

اگر بخواهید لاگ‌های مربوط به همه Podها در یک Namespace مشخص را مشاهده کنید، می‌توانید از گزینه -l برای فیلتر کردن بر اساس Labels استفاده کنید:

kubectl logs -l app=my-app --all-containers=true

مثال:

kubectl logs -l app=nginx --all-containers=true

این دستور لاگ‌های تمام Podهایی که دارای Label app=nginx هستند را نمایش می‌دهد.

---

جمع‌بندی

دستور kubectl logs ابزاری قدرتمند برای مشاهده و تحلیل لاگ‌های Podها در Kubernetes است. این دستور می‌تواند برای اشکال‌زدایی، بررسی وضعیت اجرای کانتینرها و تحلیل عملکرد برنامه‌ها استفاده شود. برخی از مهم‌ترین قابلیت‌های آن عبارت‌اند از:

• نمایش لاگ‌های یک Pod (kubectl logs <pod-name>)
• نمایش لاگ‌های یک کانتینر خاص در Podهای چندکانتینری (kubectl logs <pod-name> -c <container-name>)
• مشاهده لاگ‌های جدید به‌صورت زنده (kubectl logs -f <pod-name>)
• فیلتر کردن لاگ‌ها بر اساس زمان (kubectl logs <pod-name> --since=1h)
• مشاهده تعداد مشخصی از خطوط آخر لاگ (kubectl logs <pod-name> --tail=100)
• مشاهده لاگ‌های مربوط به اجرای قبلی یک Pod (kubectl logs <pod-name> --previous)
• مشاهده لاگ‌های چندین Pod به‌صورت هم‌زمان بر اساس Labels (kubectl logs -l app=my-app --all-containers=true)

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

---

مشاهده لاگ‌های یک کانتینر خاص در یک Pod

برای مشاهده لاگ‌های یک Container در یک Pod چندکانتینری، از گزینه -c یا --container استفاده می‌شود:

kubectl logs <pod-name> -c <container-name>

مثال:

kubectl logs my-multi-container-pod -c app-container

در این مثال، لاگ‌های مربوط به کانتینری که نام آن app-container است نمایش داده می‌شود.

---

مشاهده لاگ‌های زنده (Live Streaming) یک کانتینر خاص

اگر بخواهید لاگ‌های یک کانتینر خاص را به‌صورت زنده و در حال جریان مشاهده کنید، می‌توانید از فلگ -f (معادل --follow) استفاده کنید:

kubectl logs -f <pod-name> -c <container-name>

مثال:

kubectl logs -f my-multi-container-pod -c app-container

این دستور به‌صورت Real-time لاگ‌های جدید کانتینر موردنظر را نمایش می‌دهد.

---

مشاهده لاگ‌های یک کانتینر خاص از یک بازه زمانی مشخص

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

kubectl logs <pod-name> -c <container-name> --since=1h

مثال:

kubectl logs my-multi-container-pod -c app-container --since=30m

این دستور فقط لاگ‌های ۳۰ دقیقه اخیر را نمایش می‌دهد.

---

مشاهده تعداد مشخصی از خطوط آخر لاگ

گاهی اوقات ممکن است بخواهید فقط N خط آخر لاگ‌های یک کانتینر را مشاهده کنید. برای این کار از گزینه --tail استفاده کنید:

kubectl logs <pod-name> -c <container-name> --tail=<number>

مثال:

kubectl logs my-multi-container-pod -c app-container --tail=50

این دستور فقط ۵۰ خط آخر لاگ را نمایش می‌دهد.

---

مشاهده لاگ‌های یک کانتینر که دیگر اجرا نمی‌شود

اگر Pod شما کرش کرده باشد و بخواهید لاگ‌های اجرای قبلی یک Container را ببینید، می‌توانید از فلگ --previous استفاده کنید:

kubectl logs <pod-name> -c <container-name> --previous

مثال:

kubectl logs my-multi-container-pod -c app-container --previous

این دستور لاگ‌های مربوط به اجرای قبلی app-container را نمایش می‌دهد.

---

مشاهده لاگ‌های تمام کانتینرهای یک Pod چندکانتینری

اگر بخواهید لاگ‌های همه کانتینرهای یک Pod چندکانتینری را به‌صورت هم‌زمان ببینید، می‌توانید از گزینه --all-containers=true استفاده کنید:

kubectl logs <pod-name> --all-containers=true

مثال:

kubectl logs my-multi-container-pod --all-containers=true

این دستور لاگ‌های تمام کانتینرهای موجود در my-multi-container-pod را نمایش می‌دهد.

---

جمع‌بندی

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

• مشاهده لاگ‌های یک کانتینر خاص:

  kubectl logs <pod-name> -c <container-name>
  

• مشاهده لاگ‌های زنده (Live Streaming):

  kubectl logs -f <pod-name> -c <container-name>
  

• مشاهده لاگ‌های یک بازه زمانی خاص:

  kubectl logs <pod-name> -c <container-name> --since=1h
  

• مشاهده تعداد مشخصی از خطوط آخر لاگ:

  kubectl logs <pod-name> -c <container-name> --tail=100
  

• مشاهده لاگ‌های اجرای قبلی (CrashLoopBackOff):

  kubectl logs <pod-name> -c <container-name> --previous
  

• مشاهده لاگ‌های تمام کانتینرهای یک Pod:

  kubectl logs <pod-name> --all-containers=true
  

با استفاده از این روش‌ها می‌توان تحلیل عمیق‌تری از رفتار Podهای چندکانتینری انجام داد و خطاها و مشکلات احتمالی را سریع‌تر شناسایی و برطرف کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از پارامتر -f برای مشاهده Real-Time لاگ‌ها (Follow Mode)” subtitle=”توضیحات کامل”]در Kubernetes، زمانی که نیاز به مشاهده لحظه‌ای و زنده لاگ‌های یک Pod یا Container دارید، می‌توانید از گزینه -f یا --follow در دستور kubectl logs استفاده کنید. این قابلیت به شما امکان می‌دهد تا جریان لاگ‌ها را به‌صورت Real-Time مشاهده کنید و تغییرات جدید را بدون نیاز به اجرای مجدد دستور ببینید.

---

مشاهده لحظه‌ای لاگ‌های یک Pod

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

kubectl logs -f <pod-name>

مثال:

kubectl logs -f my-app-pod

این دستور تمامی لاگ‌های کانتینر اصلی در Pod موردنظر را نمایش داده و به‌صورت زنده به‌روزرسانی می‌کند.

---

مشاهده لاگ‌های لحظه‌ای یک کانتینر خاص در Pod‌های چندکانتینری

اگر Pod شما شامل چندین کانتینر باشد و بخواهید فقط لاگ‌های زنده یک کانتینر خاص را ببینید، باید از فلگ -c برای مشخص کردن نام کانتینر استفاده کنید:

kubectl logs -f <pod-name> -c <container-name>

مثال:

kubectl logs -f my-multi-container-pod -c app-container

در این دستور، لاگ‌های کانتینری که نام آن app-container است، نمایش داده می‌شود و به‌صورت زنده به‌روزرسانی خواهد شد.

---

مشاهده هم‌زمان لاگ‌های تمام کانتینرهای یک Pod

برای مشاهده هم‌زمان لاگ‌های تمامی کانتینرهای یک Pod چندکانتینری به‌صورت Real-Time، از گزینه --all-containers=true استفاده کنید:

kubectl logs -f <pod-name> --all-containers=true

مثال:

kubectl logs -f my-multi-container-pod --all-containers=true

این دستور تمامی لاگ‌های زنده مربوط به همه کانتینرهای داخل Pod را نمایش می‌دهد.

---

مشاهده لاگ‌های زنده یک Pod کرش‌کرده (CrashLoopBackOff)

اگر یک Pod از کار افتاده باشد اما همچنان لاگ‌های قبلی آن موجود باشد، می‌توانید از گزینه --previous برای مشاهده آخرین اجرای ناموفق استفاده کنید:

kubectl logs -f <pod-name> --previous

مثال:

kubectl logs -f my-crashed-pod --previous

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

---

مشاهده لاگ‌های زنده همراه با فیلتر کردن خروجی

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

kubectl logs -f <pod-name> | grep "ERROR"

مثال:

kubectl logs -f my-app-pod | grep "Exception"

این دستور تنها لاگ‌هایی که شامل کلمه “Exception” هستند را نمایش خواهد داد.

---

خروج از حالت مشاهده لحظه‌ای لاگ‌ها

برای متوقف کردن مشاهده لاگ‌های زنده در حالت Follow Mode، می‌توانید از کلید ترکیبی Ctrl + C استفاده کنید.

---

جمع‌بندی

پارامتر -f در kubectl logs برای مشاهده لاگ‌های زنده و لحظه‌ای بسیار مفید است. برخی از مهم‌ترین روش‌های استفاده از آن شامل:

• مشاهده لاگ‌های زنده یک Pod:

  kubectl logs -f <pod-name>
  

• مشاهده لاگ‌های زنده یک کانتینر خاص در یک Pod چندکانتینری:

  kubectl logs -f <pod-name> -c <container-name>
  

• مشاهده لاگ‌های زنده تمامی کانتینرهای یک Pod چندکانتینری:

  kubectl logs -f <pod-name> --all-containers=true
  

• مشاهده لاگ‌های اجرای قبلی یک Pod کرش‌کرده:

  kubectl logs -f <pod-name> --previous
  

• فیلتر کردن لاگ‌های زنده با grep:

  kubectl logs -f <pod-name> | grep "ERROR"
  

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

---

استفاده از grep برای فیلتر کردن لاگ‌های Kubernetes

دستور grep به شما این امکان را می‌دهد که متن مشخصی را از لاگ‌ها جستجو کرده و تنها موارد مرتبط را نمایش دهید.

۱. فیلتر کردن لاگ‌های یک Pod برای نمایش ارورها

kubectl logs my-app-pod | grep "ERROR"

مثال خروجی:

2024-02-09 10:15:32 ERROR Database connection failed!
2024-02-09 10:16:05 ERROR Unable to authenticate user.

✅ این دستور فقط لاگ‌های شامل کلمه “ERROR” را نمایش می‌دهد.

---

۲. فیلتر کردن لاگ‌های زنده (Real-Time)

اگر بخواهید لاگ‌های جدید را هم‌زمان با تولید آن‌ها فیلتر کنید، از -f همراه با grep استفاده کنید:

kubectl logs -f my-app-pod | grep "WARN"

✅ این دستور فقط لاگ‌های جدیدی را که شامل کلمه “WARN” هستند، نمایش می‌دهد.

---

۳. نمایش چندین نوع خطا به‌صورت هم‌زمان (Regular Expressions – egrep)

برای فیلتر کردن چندین کلمه به‌صورت هم‌زمان، می‌توان از egrep یا grep -E استفاده کرد:

kubectl logs my-app-pod | egrep "ERROR|WARN|FATAL"

✅ این دستور تمامی لاگ‌هایی که شامل ERROR، WARN یا FATAL هستند را نمایش می‌دهد.

---

۴. نمایش خطوط قبل و بعد از یک خط خاص

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

• نمایش ۳ خط قبل از هر خطی که شامل “ERROR” است:

  kubectl logs my-app-pod | grep -B 3 "ERROR"
  

• نمایش ۲ خط بعد از هر خطی که شامل “WARN” است:

  kubectl logs my-app-pod | grep -A 2 "WARN"
  

• نمایش ۲ خط قبل و ۲ خط بعد از هر خطی که شامل “FATAL” است:

  kubectl logs my-app-pod | grep -C 2 "FATAL"
  

✅ این تکنیک برای بررسی خطاها همراه با جزئیات بیشتر بسیار مفید است.

---

۵. جستجوی حساس یا غیرحساس به حروف بزرگ و کوچک (-i)

برای فیلتر کردن لاگ‌ها بدون در نظر گرفتن حروف کوچک و بزرگ:

kubectl logs my-app-pod | grep -i "error"

✅ این دستور کلماتی مانند error، ERROR، Error و eRrOr را نیز پیدا می‌کند.

---

۶. محدود کردن تعداد خطوط خروجی (head و tail)

برای نمایش فقط ۱۰ خط آخر لاگ‌ها:

kubectl logs my-app-pod | tail -n 10

یا نمایش ۲۰ خط اول لاگ‌ها:

kubectl logs my-app-pod | head -n 20

✅ این روش برای بررسی لاگ‌های جدید یا لاگ‌های ابتدایی یک فرایند مفید است.

---

۷. ذخیره‌سازی لاگ‌های فیلترشده در فایل

برای ذخیره کردن خروجی فیلترشده در یک فایل جهت تحلیل‌های بعدی:

kubectl logs my-app-pod | grep "ERROR" > error_logs.txt

✅ این دستور فقط لاگ‌های شامل “ERROR” را در فایلی به نام error_logs.txt ذخیره می‌کند.

---

جمع‌بندی

🔹 ابزار grep یکی از ساده‌ترین و مؤثرترین راه‌ها برای مدیریت حجم بالای لاگ‌ها در Kubernetes است.
🔹 می‌توان با استفاده از -f لاگ‌ها را به‌صورت لحظه‌ای مشاهده و فیلتر کرد.
🔹 امکان جستجوی چندین الگو با Regular Expressions (egrep) وجود دارد.
🔹 می‌توان خطوط قبل و بعد از خطای موردنظر را نمایش داد (-B, -A, -C).
🔹 امکان ذخیره‌سازی لاگ‌های مهم و فیلترشده در فایل برای تحلیل‌های بعدی وجود دارد.

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

---

۱. ذخیره‌سازی لاگ‌های Pod در فایل محلی

برای ذخیره لاگ‌های یک Pod در یک فایل، می‌توان خروجی دستور kubectl logs را به یک فایل هدایت کرد:

kubectl logs my-app-pod > my-app-logs.txt

✅ این دستور لاگ‌های my-app-pod را در فایلی به نام my-app-logs.txt ذخیره می‌کند.

---

۲. ذخیره لاگ‌های زنده (Live Logs) در فایل

اگر بخواهید لاگ‌ها را به‌صورت لحظه‌ای و در حال اجرا ذخیره کنید، از -f همراه با tee استفاده کنید:

kubectl logs -f my-app-pod | tee live-logs.txt

✅ این دستور هم‌زمان لاگ‌ها را نمایش داده و در فایل live-logs.txt ذخیره می‌کند.

---

۳. فشرده‌سازی لاگ‌ها برای کاهش حجم

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

kubectl logs my-app-pod | gzip > my-app-logs.gz

✅ این دستور لاگ‌ها را در قالب فشرده .gz ذخیره می‌کند که حجم کمتری اشغال می‌کند.

---

۴. ذخیره لاگ‌های تمام کانتینرهای یک Pod

اگر یک Pod دارای چندین کانتینر باشد، برای ذخیره لاگ‌های تمامی کانتینرهای آن می‌توان از --all-containers استفاده کرد:

kubectl logs my-app-pod --all-containers > all-containers-logs.txt

✅ این دستور لاگ‌های تمام کانتینرهای داخل Pod را در یک فایل ذخیره می‌کند.

---

۵. ذخیره لاگ‌ها در یک دایرکتوری با نام‌های مشخص‌شده

برای ذخیره لاگ‌های چندین Pod مختلف در فایل‌های جداگانه، می‌توان از یک حلقه for استفاده کرد:

for pod in $(kubectl get pods -o custom-columns=:metadata.name); do
  kubectl logs $pod > logs/$pod.log
done

✅ این اسکریپت لاگ‌های تمام Podها را در دایرکتوری logs/ ذخیره می‌کند.

---

۶. ذخیره لاگ‌ها در سیستم‌های ذخیره‌سازی ابری

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

✅ ذخیره در AWS S3

kubectl logs my-app-pod > my-app-logs.txt
aws s3 cp my-app-logs.txt s3://my-log-bucket/

✅ ذخیره در Google Cloud Storage (GCS)

kubectl logs my-app-pod > my-app-logs.txt
gsutil cp my-app-logs.txt gs://my-log-bucket/

✅ ذخیره در Azure Blob Storage

kubectl logs my-app-pod > my-app-logs.txt
az storage blob upload --container-name logs --file my-app-logs.txt --name my-app-logs.txt

🔹 این روش برای تحلیل‌های طولانی‌مدت و بررسی داده‌های حجیم بسیار مفید است.

---

۷. ذخیره‌سازی لاگ‌ها در پایگاه داده برای تحلیل پیشرفته

اگر نیاز دارید که لاگ‌ها را پردازش و تحلیل کنید، می‌توانید آن‌ها را در پایگاه داده ذخیره کنید.

✅ ارسال لاگ‌ها به پایگاه داده MySQL

kubectl logs my-app-pod | while read line; do
  echo "INSERT INTO logs (log_entry) VALUES ('$line');" | mysql -u user -p database_name
done

✅ ذخیره در پایگاه داده NoSQL مانند MongoDB

kubectl logs my-app-pod | while read line; do
  echo "{ \"log\": \"$line\" }" | mongoimport --db logsDB --collection podLogs
done

🔹 این روش برای تحلیل‌های Big Data و Machine Learning روی لاگ‌ها بسیار مفید است.

---

۸. ارسال لاگ‌ها به سیستم‌های مدیریت لاگ مانند ELK و Loki

برای پردازش و نمایش بصری لاگ‌ها، ابزارهایی مانند Elasticsearch، Logstash، Kibana (ELK) و Loki (Grafana) بسیار مفید هستند.

✅ ارسال لاگ‌ها به Elasticsearch

kubectl logs my-app-pod | while read line; do
  curl -X POST "http://elasticsearch:9200/logs/_doc/" -H "Content-Type: application/json" -d "{ \"log\": \"$line\" }"
done

✅ ارسال لاگ‌ها به Loki (Grafana Logging)

kubectl logs my-app-pod | curl -X POST -H "Content-Type: application/json" --data-binary @- http://loki:3100/loki/api/v1/push

🔹 این روش برای مانیتورینگ و تحلیل بصری لاگ‌ها در داشبوردهای گرافیکی بسیار کارآمد است.

---

جمع‌بندی

🔹 برای ذخیره‌سازی لاگ‌ها، می‌توان از فایل‌های متنی، فشرده‌سازی، دایرکتوری‌های مشخص، و یا فضای ابری استفاده کرد.
🔹 ابزارهای مدیریتی مانند ELK، Loki، Prometheus به تحلیل داده‌های لاگ کمک می‌کنند.
🔹 برای پردازش و جستجوی سریع، ذخیره‌سازی در پایگاه داده‌های SQL و NoSQL گزینه مناسبی است.
🔹 ارسال لاگ‌ها به سرویس‌های ابری مانند AWS S3، GCS و Azure Blob Storage برای ذخیره‌سازی طولانی‌مدت پیشنهاد می‌شود.

✅ با این روش‌ها می‌توان لاگ‌های Kubernetes را بهینه ذخیره و پردازش کرد و به راحتی در آینده تحلیل‌های عمیق‌تری روی آن‌ها انجام داد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. بررسی وضعیت منابع با دستورات اصلی”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دستور kubectl describe: دریافت اطلاعات جزئی در مورد Pod‌ها، Deployment‌ها، و سایر منابع” subtitle=”توضیحات کامل”]دستور kubectl describe در Kubernetes برای دریافت اطلاعات دقیق و جزئی از منابع مختلف مانند Pods، Deployments، Services، Nodes، Secrets، ConfigMaps و سایر Objectهای Kubernetes استفاده می‌شود. این دستور جزئیات پیکربندی، وضعیت فعلی، رویدادها (Events) و سایر اطلاعات حیاتی مرتبط با منابع را نمایش می‌دهد.

---

۱. ساختار کلی دستور

kubectl describe <RESOURCE_TYPE> <RESOURCE_NAME> -n <NAMESPACE>

🔹 RESOURCE_TYPE : نوع منبعی که قصد مشاهده اطلاعات آن را داریم.
🔹 RESOURCE_NAME : نام منبعی که اطلاعات آن را می‌خواهیم.
🔹 -n <NAMESPACE> : (اختیاری) مشخص کردن Namespace خاص برای دریافت اطلاعات.

✅ اگر RESOURCE_NAME مشخص نشود، اطلاعات تمام منابع از آن نوع در Namespace فعلی نمایش داده می‌شود.

---

۲. مشاهده جزئیات یک Pod

برای دریافت اطلاعات کامل یک Pod خاص:

kubectl describe pod my-pod

✅ خروجی شامل اطلاعاتی مانند:

• Node که Pod روی آن اجرا شده است.
• IPهای داخلی و خارجی مربوط به Pod.
• تصاویر (Images) استفاده شده برای کانتینرهای داخل Pod.
• متغیرهای محیطی (Environment Variables).
• Volumeها و مسیرهای Mount شده.
• Eventهای اخیر مرتبط با Pod.

📌 مثال خروجی:

Name:         my-pod
Namespace:    default
Node:         node-1/192.168.1.10
Start Time:   Mon, 09 Feb 2025 10:00:00 GMT
Labels:       app=web
Annotations:  kubectl.kubernetes.io/restartedAt: 2025-02-09T10:00:00Z
Status:       Running
IP:           10.244.1.12
Containers:
  nginx:
    Image:         nginx:latest
    Ports:         80/TCP
    Environment:   ENV=production
Events:
  Type     Reason     Age    From                  Message
  ----     ------     ----   ----                  -------
  Normal   Scheduled  5m     default-scheduler    Successfully assigned my-pod to node-1
  Normal   Pulled     4m     kubelet, node-1      Container image "nginx:latest" already present
  Normal   Started    4m     kubelet, node-1      Started container nginx

---

۳. مشاهده جزئیات یک Deployment

kubectl describe deployment my-deployment

✅ اطلاعاتی که نمایش داده می‌شود:

• تعداد Replicaها.
• تصویر (Image) استفاده شده.
• متغیرهای محیطی.
• Selectorهای مرتبط با Podها.
• رویدادهای اخیر (مانند Restart شدن یک Pod).

📌 مثال خروجی:

Name:                   my-deployment
Namespace:              default
Replicas:               3 desired | 3 updated | 3 total | 3 available | 0 unavailable
Selector:               app=web
Image:                  nginx:latest
StrategyType:           RollingUpdate
Events:
  Type     Reason     Age    From                   Message
  ----     ------     ----   ----                   -------
  Normal   ScalingUp  2m     deployment-controller  Scaled up replica set my-deployment-5d7f9b86b8 to 3

---

۴. مشاهده اطلاعات مربوط به یک Node

kubectl describe node node-1

✅ اطلاعات نمایش داده‌شده:

• نام و آدرس Node.
• وضعیت کلی (Ready، NotReady).
• ظرفیت منابع (CPU، Memory، Storage).
• Pods در حال اجرا روی آن Node.
• رویدادهای مرتبط با Node.

📌 مثال خروجی:

Name:               node-1
Roles:              worker
Labels:             kubernetes.io/hostname=node-1
Capacity:
  cpu:             8
  memory:          32Gi
  ephemeral-storage: 100Gi
Allocatable:
  cpu:             7
  memory:          30Gi
  ephemeral-storage: 90Gi
Conditions:
  Type             Status  LastHeartbeatTime
  ----             ------  -----------------
  Ready            True    2025-02-09T10:15:00Z

---

۵. مشاهده اطلاعات مربوط به یک Service

kubectl describe service my-service

✅ اطلاعاتی که نمایش داده می‌شود:

• نوع Service (ClusterIP، NodePort، LoadBalancer).
• آدرس‌های IP و Portهای در دسترس.
• Podهایی که تحت این Service قرار دارند.

📌 مثال خروجی:

Name:              my-service
Namespace:         default
Labels:            app=web
Selector:          app=web
Type:              ClusterIP
IP:                10.100.200.1
Port:              80/TCP
Endpoints:         10.244.1.12:80, 10.244.1.13:80

---

۶. مشاهده اطلاعات ConfigMap و Secrets

✅ مشاهده جزئیات یک ConfigMap

kubectl describe configmap my-config

✅ مشاهده جزئیات یک Secret

kubectl describe secret my-secret

📌 نکته: مقدار داده‌های ذخیره‌شده در Secretها معمولاً رمزنگاری شده (Base64 Encoded) نمایش داده می‌شوند.

---

۷. مشاهده رویدادهای مرتبط با یک Namespace

kubectl describe namespace my-namespace

✅ این دستور اطلاعاتی درباره:

• وضعیت (Active یا Terminating).
• ResourceQuotaها و LimitRangeهای مربوط به آن.
• رویدادهای اخیر در سطح Namespace.

📌 مثال خروجی:

Name:         my-namespace
Status:       Active
Resource Quotas:
  Name:       compute-quota
  CPU:        4
  Memory:     16Gi
Events:
  Type     Reason     Age    From                  Message
  ----     ------     ----   ----                  -------
  Normal   Created    10m    kubernetes            Namespace my-namespace created

---

۸. مشاهده اطلاعات مربوط به Role و RoleBinding

✅ دریافت اطلاعات مربوط به یک Role

kubectl describe role my-role -n my-namespace

✅ دریافت اطلاعات مربوط به یک RoleBinding

kubectl describe rolebinding my-rolebinding -n my-namespace

📌 مثال خروجی:

Name:         my-role
Namespace:    my-namespace
Rules:
  Resources  Verbs
  ---------  -----
  pods       ["get", "list", "watch"]

---

۹. مشاهده اطلاعات یک Persistent Volume (PV)

kubectl describe pv my-pv

✅ اطلاعات نمایش داده‌شده:

• نوع Storage.
• فضای اختصاص داده‌شده و استفاده‌شده.
• Policy و وضعیت Mount شدن.

📌 مثال خروجی:

Name:         my-pv
Capacity:     100Gi
Access Modes: ReadWriteOnce
Reclaim Policy: Retain
Status:       Bound

---

جمع‌بندی

🔹 دستور kubectl describe اطلاعات کامل و دقیق در مورد منابع مختلف Kubernetes را نمایش می‌دهد.
🔹 این دستور پیکربندی، وضعیت اجرا، متریک‌های منابع، رویدادهای اخیر و اطلاعات امنیتی را ارائه می‌دهد.
🔹 kubectl describe pod <POD_NAME> یکی از پرکاربردترین دستورات برای عیب‌یابی (Debugging) Podها است.
🔹 این دستور برای Nodeها، Deployments، Services، ConfigMaps، Secrets و سایر منابع Kubernetes قابل استفاده است.

✅ با استفاده از این دستور، می‌توان دقیق‌تر مشکلات و پیکربندی‌ها را بررسی و مدیریت کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مشاهده وقایع مرتبط (Events) برای هر منبع در Kubernetes” subtitle=”توضیحات کامل”]در Kubernetes، رویدادها (Events) اطلاعات مهمی در مورد تغییرات و وضعیت منابع مختلف ارائه می‌دهند. این رویدادها شامل مواردی مانند زمان‌بندی (Scheduling)، راه‌اندازی (Starting)، توقف (Stopping)، مشکلات مربوط به منابع (Resource Issues)، خطاها (Errors)، و سایر رخدادهای مهم است. مشاهده و بررسی این رویدادها برای رفع مشکلات، دیباگ و مانیتورینگ بسیار ضروری است.

---

۱. مشاهده رویدادهای کلی در Kubernetes

برای مشاهده تمامی رویدادهای مربوط به یک Namespace خاص:

kubectl get events -n <NAMESPACE>

✅ مثال:

kubectl get events -n default

🔹 این دستور تمامی رویدادهای رخ‌داده در Namespace default را نمایش می‌دهد.

📌 نمونه خروجی:

LAST SEEN   TYPE      REASON              OBJECT                MESSAGE
30s         Normal    Scheduled           pod/my-app            Successfully assigned default/my-app to node-1
28s         Normal    Pulled              pod/my-app            Successfully pulled image "nginx:latest"
25s         Normal    Created             pod/my-app            Created container nginx
25s         Normal    Started             pod/my-app            Started container nginx

🔹 ستون‌های خروجی شامل:

• LAST SEEN: آخرین باری که این رویداد ثبت شده است.
• TYPE: نوع رویداد (Normal یا Warning).
• REASON: دلیل رویداد (مثلاً Scheduled، Started، Failed).
• OBJECT: منبع مرتبط با رویداد.
• MESSAGE: توضیحی درباره رویداد.

---

۲. مشاهده رویدادهای مربوط به یک Pod خاص

kubectl describe pod <POD_NAME> -n <NAMESPACE>

✅ مثال:

kubectl describe pod my-app -n default

📌 بخش Events در خروجی:

Events:
  Type     Reason     Age   From               Message
  ----     ------     ----  ----               -------
  Normal   Scheduled  1m    default-scheduler Successfully assigned my-app to node-1
  Normal   Pulled     50s   kubelet, node-1   Container image "nginx:latest" already present
  Normal   Started    48s   kubelet, node-1   Started container nginx

🔹 این اطلاعات به ما کمک می‌کند بفهمیم Pod در چه مرحله‌ای قرار دارد و آیا مشکلی رخ داده است یا خیر.

---

۳. مشاهده رویدادهای مربوط به یک Node خاص

برای بررسی وقایع مرتبط با یک Node:

kubectl describe node <NODE_NAME>

✅ مثال:

kubectl describe node node-1

📌 نمونه خروجی بخش Events:

Events:
  Type     Reason               Age    From                Message
  ----     ------               ----   ----                -------
  Warning  MemoryPressure       10m    kubelet, node-1     System memory is low
  Normal   NodeHasSufficientMemory  2m  kubelet, node-1     Memory pressure resolved

🔹 این اطلاعات مشخص می‌کند که Node آیا دچار مشکلاتی مانند کمبود حافظه (MemoryPressure)، کمبود فضای دیسک (DiskPressure) یا موارد دیگر شده است.

---

۴. مشاهده رویدادهای مرتبط با یک Deployment

kubectl describe deployment <DEPLOYMENT_NAME> -n <NAMESPACE>

✅ مثال:

kubectl describe deployment my-deployment -n default

📌 نمونه خروجی بخش Events:

Events:
  Type     Reason     Age   From                   Message
  ----     ------     ----  ----                   -------
  Normal   ScalingUp  2m    deployment-controller  Scaled up replica set my-deployment-7d6fbb to 3

🔹 این خروجی نشان می‌دهد که این Deployment در حال افزایش تعداد Replicaها بوده است.

---

۵. مشاهده رویدادهای مربوط به یک Service

kubectl describe service <SERVICE_NAME> -n <NAMESPACE>

✅ مثال:

kubectl describe service my-service -n default

📌 نمونه خروجی بخش Events:

Events:
  Type     Reason         Age   From                Message
  ----     ------         ----  ----                -------
  Normal   LoadBalancerIP 2m    service-controller  Assigned IP 192.168.1.100 to LoadBalancer

🔹 این خروجی نشان می‌دهد که یک آدرس IP برای LoadBalancer اختصاص داده شده است.

---

۶. مشاهده رویدادهای مرتبط با یک Persistent Volume (PV)

kubectl describe pv <PV_NAME>

✅ مثال:

kubectl describe pv my-pv

📌 نمونه خروجی بخش Events:

Events:
  Type     Reason       Age   From                  Message
  ----     ------       ----  ----                  -------
  Normal   Provisioned  10m   persistent-volume-controller Successfully provisioned volume my-pv

🔹 این خروجی نشان می‌دهد که این PV با موفقیت ایجاد و تخصیص داده شده است.

---

۷. مشاهده رویدادهای مرتبط با یک Namespace

kubectl get events --field-selector involvedObject.kind=Namespace,involvedObject.name=<NAMESPACE>

✅ مثال:

kubectl get events --field-selector involvedObject.kind=Namespace,involvedObject.name=default

📌 نمونه خروجی:

LAST SEEN   TYPE      REASON     OBJECT           MESSAGE
5m          Normal    Created    namespace/default   Namespace default created

🔹 این خروجی نشان می‌دهد که Namespace ایجاد شده است.

---

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

✅ فیلتر کردن رویدادهای هشدار (Warning)

kubectl get events --field-selector type=Warning

✅ فیلتر کردن رویدادها برای منابع خاص (مثلاً فقط Podها)

kubectl get events --field-selector involvedObject.kind=Pod

✅ مشاهده آخرین ۱۰ رویداد ثبت‌شده

kubectl get events --sort-by=.metadata.creationTimestamp | tail -10

---

۹. مشاهده رویدادها با جزئیات کامل (JSON یا YAML)

✅ دریافت خروجی به‌صورت YAML

kubectl get events -o yaml

✅ دریافت خروجی به‌صورت JSON

kubectl get events -o json

---

جمع‌بندی

🔹 Kubernetes رویدادهای مختلفی را برای Podها، Deployments، Nodes، Services، PV و سایر منابع ثبت می‌کند.
🔹 این رویدادها به دیباگ کردن مشکلات، عیب‌یابی خطاها و نظارت بر وضعیت منابع کمک می‌کنند.
🔹 دستور kubectl get events لیستی از تمامی رویدادهای رخ‌داده را نمایش می‌دهد.
🔹 با استفاده از kubectl describe <RESOURCE> می‌توان رویدادهای مرتبط با یک منبع خاص را مشاهده کرد.
🔹 فیلتر کردن و مشاهده رویدادهای مهم (مانند Warningها) باعث کاهش حجم اطلاعات و بهبود تحلیل‌ها می‌شود.

✅ مشاهده و بررسی Events یکی از مهم‌ترین بخش‌های مدیریت و نگهداری Kubernetes است و کمک زیادی به رفع مشکلات و بهینه‌سازی عملکرد می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دستور kubectl get: مشاهده وضعیت کلی منابع Kubernetes” subtitle=”توضیحات کامل”]دستور kubectl get یکی از دستورات پرکاربرد در Kubernetes است که برای مشاهده وضعیت کلی منابع مختلف موجود در کلاستر Kubernetes استفاده می‌شود. با این دستور می‌توان اطلاعاتی مانند وضعیت Pod‌ها، Deployment‌ها، ReplicaSet‌ها، Service‌ها و دیگر منابع Kubernetes را دریافت کرد.

ساختار کلی دستور kubectl get:

kubectl get [resource] [name] [options]

• [resource]: نوع منبعی که می‌خواهید اطلاعات آن را مشاهده کنید (برای مثال pods, deployments, services).
• [name]: نام خاص منبع مورد نظر برای مشاهده (اختیاری، اگر بخواهید فقط یک منبع خاص را مشاهده کنید).
• [options]: پارامترهایی برای فیلتر کردن و اصلاح نتایج، مانند -o برای خروجی به فرمت خاص، --namespace برای تعیین namespace خاص و …

برخی از کاربردهای متداول kubectl get:

1. مشاهده وضعیت تمام Pods در namespace جاری:

   kubectl get pods
   

   این دستور فهرستی از تمام Pod‌ها را به همراه وضعیت آن‌ها، تعداد محتوای در حال اجرا، وضعیت (Running, Pending, etc.) و دیگر جزئیات می‌دهد.

2. مشاهده وضعیت تمام منابع در یک namespace خاص:

   kubectl get all --namespace <namespace-name>
   

   این دستور فهرستی از تمام منابع موجود در namespace مشخص شده را نمایش می‌دهد.

3. مشاهده اطلاعات کامل‌تر در مورد یک Pod خاص:

   kubectl get pod <pod-name> -o wide
   

   استفاده از گزینه -o wide به شما اطلاعات اضافی از جمله IP‌های داخلی و وضعیت‌های دقیق‌تری از منابع را نمایش می‌دهد.

4. مشاهده وضعیت تمام Deployment‌ها:

   kubectl get deployments
   

   با این دستور می‌توانید فهرستی از تمام Deployment‌ها در Kubernetes را مشاهده کنید.

5. مشاهده وضعیت Node‌ها:

   kubectl get nodes
   

   این دستور فهرستی از تمام Node‌ها در کلاستر را نمایش می‌دهد که شامل وضعیت، ظرفیت منابع، و دیگر جزئیات است.

6. مشاهده وضعیت یک سرویس خاص:

   kubectl get service <service-name>
   

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

فیلتر کردن خروجی با استفاده از -o:

• مشاهده خروجی به صورت YAML:

  kubectl get pod <pod-name> -o yaml
  

  این دستور خروجی را به صورت YAML برای Pod مورد نظر نمایش می‌دهد.

• مشاهده خروجی به صورت JSON:

  kubectl get service <service-name> -o json
  

  این دستور خروجی سرویس را به صورت JSON نمایش می‌دهد.

جمع‌بندی:

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

استفاده از o yaml-:

فرمت yaml به شما امکان می‌دهد که داده‌ها را به صورت خوانا و ساختار یافته مشاهده کنید. خروجی YAML معمولاً برای مدیریت منابع و ذخیره‌سازی پیکربندی‌ها به کار می‌رود.

1. مشاهده اطلاعات یک Pod به صورت YAML:

   kubectl get pod <pod-name> -o yaml
   

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

2. مشاهده وضعیت یک Deployment به صورت YAML:

   kubectl get deployment <deployment-name> -o yaml
   

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

استفاده از o json-:

فرمت json برای تعاملات خودکار و پردازش داده‌ها مناسب‌تر است. این فرمت به ویژه برای اسکریپت‌ها و ابزارهای تحلیل داده‌ها مفید است. استفاده از json معمولاً در زمانی که به داده‌های دقیق‌تر برای اتوماسیون یا تجزیه و تحلیل نیاز داریم توصیه می‌شود.

1. مشاهده اطلاعات یک Pod به صورت JSON:

   kubectl get pod <pod-name> -o json
   

   با استفاده از این دستور، شما می‌توانید اطلاعات Pod مورد نظر را به صورت JSON مشاهده کنید. این فرمت برای پردازش داده‌ها در اسکریپت‌ها یا سیستم‌های اتوماسیون بسیار مناسب است.

2. مشاهده وضعیت یک Service به صورت JSON:

   kubectl get service <service-name> -o json
   

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

استفاده از o custom-columns-:

در صورتی که تنها به بخشی خاص از داده‌ها نیاز دارید، می‌توانید از گزینه -o custom-columns استفاده کنید. این گزینه به شما اجازه می‌دهد که فقط ستون‌های مشخصی را از داده‌ها انتخاب کنید.

1. مشاهده اسم و وضعیت Pod‌ها:

   kubectl get pods -o custom-columns="NAME:.metadata.name,STATUS:.status.phase"
   

   با این دستور، تنها نام و وضعیت (status) Pod‌ها در خروجی نمایش داده می‌شود.

جمع‌بندی:

استفاده از فرمت‌های خروجی مانند yaml و json در Kubernetes، به شما کمک می‌کند تا بتوانید داده‌ها را به صورت ساختار یافته و قابل پردازش مشاهده کنید. این فرمت‌ها به ویژه در محیط‌های پیچیده و برای تحلیل‌های دقیق‌تر و خودکارسازی فرآیندها بسیار مفید هستند. انتخاب فرمت مناسب بستگی به نیاز شما برای تجزیه و تحلیل داده‌ها و یا استفاده از آن‌ها در اسکریپت‌ها و برنامه‌ها دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دستور kubectl top: مشاهده مصرف CPU و حافظه Pod‌ها و Node‌ها” subtitle=”توضیحات کامل”]دستور kubectl top یکی از دستورات مفید در Kubernetes است که به شما امکان می‌دهد مصرف منابع سیستم، مانند CPU و حافظه، را برای Pod‌ها و Node‌ها بررسی کنید. این دستور به طور خاص برای نظارت بر وضعیت و بهینه‌سازی مصرف منابع استفاده می‌شود و می‌تواند به شناسایی گلوگاه‌ها و مشکلات عملکردی کمک کند.

مشاهده مصرف CPU و حافظه Pod‌ها و Node‌ها:

برای مشاهده مصرف منابع در سطح Pod‌ها و Node‌ها از دستور kubectl top استفاده می‌شود.

1. مشاهده مصرف منابع برای تمام Pod‌ها: برای مشاهده مصرف CPU و حافظه برای تمامی Pod‌ها در فضای نام (Namespace) جاری، می‌توانید از دستور زیر استفاده کنید:

   kubectl top pod
   

   این دستور به شما گزارشی از مصرف CPU و حافظه هر Pod در Kubernetes می‌دهد. خروجی به‌صورت زیر خواهد بود:

   NAME            CPU(cores)   MEMORY(bytes)
   pod-name-1      10m          50Mi
   pod-name-2      25m          100Mi
   pod-name-3      30m          150Mi
   

   در اینجا، CPU(cores) مصرف CPU را به‌صورت میلی‌هسته (milli-cores) و MEMORY(bytes) مصرف حافظه را به‌صورت مگابایت (Mi) نشان می‌دهد.

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

   kubectl top pod <pod-name>
   

   این دستور مصرف منابع را فقط برای Pod مشخص‌شده نمایش می‌دهد.

3. مشاهده مصرف منابع کانتینرها: اگر Pod شما دارای چندین کانتینر باشد، می‌توانید مصرف منابع را به تفکیک برای هر کانتینر مشاهده کنید:

   kubectl top pod <pod-name> --containers
   

   این دستور مصرف CPU و حافظه را برای هر کانتینر در Pod نمایش می‌دهد.

4. مشاهده مصرف منابع برای تمام Node‌ها: برای مشاهده مصرف منابع (CPU و حافظه) برای تمامی Node‌ها در Cluster، می‌توانید از دستور زیر استفاده کنید:

   kubectl top node
   

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

   NAME           CPU(cores)   MEMORY(bytes)
   node-1         2 CPUs        8Gi
   node-2         3 CPUs        12Gi
   node-3         1 CPU         4Gi
   

   در اینجا، CPU(cores) مصرف CPU در هسته‌ها و MEMORY(bytes) مصرف حافظه در گیگابایت (Gi) را نمایش می‌دهد.

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

   kubectl top node <node-name>
   

شناسایی منابعی که بیشترین بار را دارند:

برای شناسایی منابعی که بیشترین بار را دارند (به‌ویژه زمانی که نیاز به مدیریت منابع و بهینه‌سازی عملکرد دارید)، دستور kubectl top بسیار مفید است. با مشاهده مصرف منابع در سطح Pod‌ها و Node‌ها، می‌توانید منابعی را که بیشترین مصرف را دارند شناسایی کنید.

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

   kubectl top pod --sort-by=cpu
   

   یا برای مشاهده Pod‌های با مصرف بالاتر حافظه:

   kubectl top pod --sort-by=memory
   

2. شناسایی Node‌های پرمصرف: برای شناسایی Node‌هایی که بیشترین مصرف منابع (CPU و حافظه) را دارند، می‌توانید از دستور زیر استفاده کنید:

   kubectl top node --sort-by=cpu
   

   یا برای شناسایی Node‌هایی با بیشترین مصرف حافظه:

   kubectl top node --sort-by=memory
   

جمع‌بندی:

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

دسترسی به ترمینال کانتینرها برای اجرای دستورات مستقیم:

یکی از کاربردهای رایج دستور kubectl exec ورود به ترمینال کانتینر برای اجرای دستورات است. این قابلیت به‌ویژه زمانی مفید است که بخواهید به صورت موقت در داخل یک کانتینر وارد شده و دستوری را اجرا کنید، مثلاً برای اشکال‌زدایی یا بررسی وضعیت سیستم.

1. دسترسی به ترمینال کانتینر: برای دسترسی به ترمینال یک کانتینر خاص داخل Pod، دستور kubectl exec به‌همراه گزینه -it به کار می‌رود. گزینه -i برای تعامل (Interactive) و -t برای تخصیص یک ترمینال (Terminal) است. دستور زیر به شما این امکان را می‌دهد که وارد کانتینر شوید:

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

   در اینجا، <pod-name> نام Pod مورد نظر است و /bin/bash مسیر برنامه‌ای است که برای ورود به ترمینال از آن استفاده می‌شود. برای مثال، اگر از کانتینرهای مبتنی بر Alpine استفاده می‌کنید، می‌توانید از /bin/sh به جای /bin/bash استفاده کنید:

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

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

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

   kubectl exec <pod-name> -- ls /path/to/directory
   

   یا برای اجرای دستور curl داخل کانتینر:

   kubectl exec <pod-name> -- curl http://example.com
   

بررسی وضعیت درون کانتینر (مثل فایل‌ها، پیکربندی‌ها، و سرویس‌ها):

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

1. بررسی فایل‌ها و دایرکتوری‌ها: برای بررسی فایل‌ها و دایرکتوری‌های داخل کانتینر، می‌توانید از دستور ls یا سایر دستورات مشابه استفاده کنید. به‌طور مثال، اگر بخواهید محتویات دایرکتوری /etc را مشاهده کنید:

   kubectl exec -it <pod-name> -- ls /etc
   

2. بررسی پیکربندی‌های کانتینر: در بسیاری از موارد، ممکن است نیاز باشد تا پیکربندی‌ها یا متغیرهای محیطی کانتینر را بررسی کنید. برای مشاهده متغیرهای محیطی که در کانتینر تنظیم شده‌اند، می‌توانید دستور printenv را اجرا کنید:

   kubectl exec -it <pod-name> -- printenv
   

   این دستور لیستی از متغیرهای محیطی داخل کانتینر را نمایش می‌دهد که می‌تواند شامل تنظیمات مهمی مانند تنظیمات پایگاه داده، متغیرهای API و غیره باشد.

3. بررسی سرویس‌های در حال اجرا: برای بررسی سرویس‌ها و پروسس‌های در حال اجرای داخل کانتینر، می‌توانید از دستور ps استفاده کنید. برای مثال، برای مشاهده پروسس‌های در حال اجرا داخل کانتینر:

   kubectl exec -it <pod-name> -- ps aux
   

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

4. مشاهده فایل‌های لاگ درون کانتینر: گاهی اوقات برای عیب‌یابی، نیاز به مشاهده فایل‌های لاگ در داخل کانتینر دارید. برای این کار، می‌توانید از دستور cat یا tail استفاده کنید تا محتوای فایل‌های لاگ را بررسی کنید. به عنوان مثال، برای مشاهده لاگ‌های موجود در /var/log:

   kubectl exec -it <pod-name> -- cat /var/log/container-log.log
   

   یا برای مشاهده لاگ‌های در حال تغییر:

   kubectl exec -it <pod-name> -- tail -f /var/log/container-log.log
   

جمع‌بندی:

دستور kubectl exec یک ابزار قدرتمند برای تعامل با کانتینرها در Kubernetes است. با استفاده از این دستور، می‌توانید به ترمینال کانتینرها دسترسی پیدا کنید و دستورات مختلفی را اجرا کنید. همچنین این دستور به شما این امکان را می‌دهد که به بررسی وضعیت فایل‌ها، پیکربندی‌ها، و سرویس‌های درون کانتینر بپردازید و به‌راحتی مشکلات یا نیازهای تنظیماتی را شناسایی و برطرف کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دستور kubectl port-forward” subtitle=”توضیحات کامل”]دستور kubectl port-forward یکی از ابزارهای پرکاربرد در Kubernetes است که برای ایجاد تونل‌های محلی و دسترسی به برنامه‌های در حال اجرا داخل یک Pod استفاده می‌شود. این دستور به شما امکان می‌دهد تا ترافیک شبکه را از یک پورت محلی به پورت‌های داخلی کانتینرها هدایت کنید و از طریق این تونل، با برنامه‌ها یا سرویس‌های در حال اجرا در داخل Pods ارتباط برقرار کنید.

ایجاد تونل برای دسترسی به برنامه‌های داخل یک Pod:

در حالت کلی، Kubernetes Pods و سرویس‌های درون آن‌ها معمولاً در شبکه داخلی (Cluster) قرار دارند و به‌طور مستقیم از خارج از Cluster قابل دسترسی نیستند. دستور kubectl port-forward به شما این امکان را می‌دهد که یک تونل محلی بین ماشین خود و Pod ایجاد کنید و به‌این ترتیب، به پورت‌های درون Pod دسترسی پیدا کنید.

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

kubectl port-forward pod/<pod-name> 8080:8080

در این دستور:

• <pod-name> باید با نام Pod مورد نظر شما جایگزین شود.
• 8080:8080 مشخص می‌کند که ترافیک دریافتی از پورت 8080 ماشین محلی شما به پورت 8080 کانتینر در داخل Pod هدایت خواهد شد.

پس از اجرای این دستور، شما می‌توانید به اپلیکیشن خود از طریق http://localhost:8080 دسترسی پیدا کنید.

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

kubectl port-forward pod/<pod-name> 8080:8080 9090:9090

این دستور به شما اجازه می‌دهد که پورت 8080 و 9090 را از Pod به پورت‌های معادل روی ماشین محلی شما منتقل کنید.

Debug کردن سرویس‌ها در محیط توسعه:

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

1. Debug کردن سرویس‌های داخلی: فرض کنید سرویس شما فقط در داخل Cluster در دسترس است و شما نمی‌خواهید برای بررسی آن تنظیمات خاصی را برای دسترسی به آن از خارج انجام دهید. با استفاده از دستور kubectl port-forward می‌توانید دسترسی به پورت‌های سرویس را در محیط توسعه به راحتی انجام دهید و از مشکلات موجود با استفاده از ابزارهای مورد نظر خود مانند curl، Postman یا حتی مرورگر تست کنید.
2. اتصال به پایگاه‌داده‌ها: در صورتی که سرویس شما شامل یک پایگاه‌داده باشد که به‌طور معمول فقط از طریق شبکه داخلی قابل دسترسی است، دستور kubectl port-forward این امکان را به شما می‌دهد که به‌صورت موقت و فقط برای تست یا دیباگ، به پایگاه‌داده دسترسی پیدا کنید. به‌طور مثال، اگر MySQL در داخل Pod روی پورت 3306 در حال اجراست، می‌توانید از دستور زیر برای انتقال پورت استفاده کنید:

   kubectl port-forward pod/<pod-name> 3306:3306
   

   سپس می‌توانید از طریق mysql -h 127.0.0.1 -P 3306 به پایگاه‌داده متصل شوید.

3. پیکربندی‌های مختلف با استفاده از پورت‌های متعدد: در بعضی مواقع نیاز دارید که چندین پورت را به طور همزمان از کانتینرهای مختلف یا سرویس‌های مختلف داخل Podها منتقل کنید. برای مثال، اگر در حال تست اپلیکیشن Node.js هستید که روی پورت 3000 در حال اجرا است و پایگاه‌داده‌ای دارید که روی پورت 5432 (PostgreSQL) فعال است، می‌توانید به‌صورت همزمان از چندین پورت به صورت زیر استفاده کنید:

   kubectl port-forward pod/<pod-name> 3000:3000 5432:5432
   

جمع‌بندی:

دستور kubectl port-forward ابزار بسیار مفیدی برای ایجاد تونل‌های شبکه‌ای در داخل Kubernetes است که به شما امکان می‌دهد به‌طور موقت به سرویس‌ها و برنامه‌ها در داخل Pods دسترسی پیدا کنید. این دستور به‌ویژه در شرایطی که نیاز به دیباگ یا آزمایش سرویس‌ها در محیط‌های توسعه دارید، بسیار کاربردی است. همچنین با استفاده از این دستور می‌توانید به پایگاه‌داده‌ها، وب‌سرویس‌ها و دیگر سرویس‌های در حال اجرا در داخل Pods دسترسی پیدا کرده و آن‌ها را بررسی یا اشکال‌زدایی کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی وضعیت Pod: شناسایی دلایل خرابی (CrashLoopBackOff، ImagePullBackOff، و غیره)” subtitle=”توضیحات کامل”]در Kubernetes، وضعیت Pods یکی از جنبه‌های کلیدی برای شناسایی مشکلات و نگهداری از کلاستر است. Pods به‌عنوان واحدهای اصلی اجرای برنامه‌ها در Kubernetes، ممکن است با مشکلات مختلفی روبه‌رو شوند که این مشکلات می‌تواند عملکرد کل سیستم را تحت تأثیر قرار دهد. یکی از ابزارهای اصلی برای بررسی وضعیت Pods، استفاده از دستور kubectl describe pod و kubectl get pod است که اطلاعات مفیدی را در مورد وضعیت فعلی Pod و دلایل احتمالی خرابی آن‌ها ارائه می‌دهد.

در اینجا به بررسی برخی از وضعیت‌های رایج و دلایل خرابی Pods می‌پردازیم که در فرآیند اشکال‌زدایی (debugging) و عیب‌یابی کاربرد فراوان دارند:

شناسایی دلایل خرابی:

1. CrashLoopBackOff: یکی از وضعیت‌های رایج که ممکن است در Pods رخ دهد، CrashLoopBackOff است. این وضعیت زمانی اتفاق می‌افتد که کانتینر داخل Pod به طور مداوم کرش می‌کند و Kubernetes سعی دارد آن را دوباره راه‌اندازی کند، اما به دلیل وجود مشکل، کانتینر همیشه در حال کرش است. معمولاً این وضعیت نشان‌دهنده یک مشکل در کد یا پیکربندی اپلیکیشن است.برای مشاهده دلیل دقیق بروز CrashLoopBackOff، می‌توان از دستور زیر استفاده کرد:

   kubectl describe pod <pod-name>
   

   در خروجی این دستور، بخش‌هایی مانند State و Last State برای کانتینرها را بررسی کنید. اگر دلیل خرابی در خروجی به‌طور واضح ذکر نشده باشد، بررسی لاگ‌ها می‌تواند مفید باشد:

   kubectl logs <pod-name> --previous
   

   همچنین بررسی میزان منابع (مانند حافظه و CPU) که کانتینر نیاز دارد و مقایسه آن با منابع موجود در Cluster نیز می‌تواند مفید باشد.

   راه‌حل‌ها:

   • بررسی کد اپلیکیشن برای یافتن اشتباهات رایج.
   • بررسی پیکربندی‌های فایل‌های Dockerfile و YAML.
   • اطمینان از اینکه منابع کافی به کانتینر اختصاص داده شده است.
2. ImagePullBackOff: وضعیت ImagePullBackOff زمانی رخ می‌دهد که Kubernetes قادر به دانلود (pull) تصویر کانتینر از رجیستری (Registry) نباشد. این وضعیت به دلیل مشکلات مختلفی مانند نامعتبر بودن تصویر، خطا در احراز هویت (authentication) به رجیستری، یا عدم دسترسی به اینترنت در محیط کلاستر ممکن است رخ دهد.برای بررسی علت دقیق‌تر و شناسایی مشکل، می‌توانید از دستور زیر استفاده کنید:

   kubectl describe pod <pod-name>
   

   در خروجی، اطلاعاتی از جمله خطاهای مربوط به کشیدن تصویر (pull) در قسمت Events قابل مشاهده خواهد بود. معمولاً خطاهایی مانند “ErrImagePull” یا “ImagePullBackOff” می‌تواند نشان‌دهنده مشکل در دریافت تصویر از رجیستری باشد.

   راه‌حل‌ها:

   • اطمینان از اینکه تصویر کانتینر در رجیستری مورد نظر موجود است.
   • بررسی نام تصویر و تگ آن برای اشتباهات.
   • اگر رجیستری نیاز به احراز هویت دارد، اطمینان حاصل کنید که اطلاعات احراز هویت به درستی تنظیم شده است (مانند استفاده از imagePullSecrets).
   • در صورت استفاده از Docker Hub، ممکن است محدودیت‌هایی برای تعداد درخواست‌ها وجود داشته باشد، بنابراین بررسی وضعیت آن ضروری است.
3. ImagePullBackOff و No Matching Manifest: یکی دیگر از مشکلات رایج در وضعیت ImagePullBackOff زمانی است که Kubernetes قادر به پیدا کردن نسخه مناسب تصویر در رجیستری نیست. این معمولاً زمانی رخ می‌دهد که نام یا تگ تصویر اشتباه باشد.برای بررسی این مشکل، می‌توان به خروجی دستور kubectl describe نگاهی انداخت و به دنبال خطاهایی مانند no matching manifest for یا ImagePullBackOff بود. در این صورت، باید اطمینان حاصل کنید که تگ تصویر یا نسخه‌ای که در تنظیمات Pod تعریف کرده‌اید، در رجیستری موجود است.
4. CrashLoopBackOff due to Insufficient Resources (Memory/CPU): در برخی مواقع، مشکلات مرتبط با منابع (مانند حافظه یا CPU) می‌تواند منجر به وضعیت CrashLoopBackOff شود. اگر یک کانتینر منابع بیشتری از آنچه که در YAML فایل یا تنظیمات Pod تعریف شده است، مصرف کند، ممکن است کرش کند و Kubernetes آن را دوباره راه‌اندازی کند.برای بررسی این وضعیت، می‌توانید از دستور زیر استفاده کنید تا میزان مصرف منابع را بررسی کنید:

   kubectl top pod <pod-name>
   

   راه‌حل‌ها:

   • در صورت نیاز، منابع بیشتری برای Pod در نظر بگیرید (استفاده از resources.requests و resources.limits).
   • بررسی کنید که آیا کانتینر شما در حال مصرف منابع بیش از حد است و آن را بهینه‌سازی کنید.

جمع‌بندی:

بررسی وضعیت Pods در Kubernetes به‌ویژه در زمان بروز مشکلات، یکی از ابزارهای اصلی برای شناسایی و رفع مشکلات است. وضعیت‌های رایج مانند CrashLoopBackOff و ImagePullBackOff می‌تواند نشان‌دهنده مشکلاتی در پیکربندی، منابع، یا نحوه اجرای برنامه‌ها باشد. استفاده از دستورات مانند kubectl describe pod و kubectl logs می‌تواند اطلاعات دقیقی در مورد دلایل خرابی ارائه دهد. همچنین استفاده از دستور kubectl top pod برای بررسی منابع مصرفی، ابزار مفیدی برای شناسایی مشکلات ناشی از منابع ناکافی است. با توجه به اطلاعات به‌دست‌آمده، می‌توان اقدامات لازم را برای رفع مشکلات انجام داد و اطمینان حاصل کرد که Pods به‌طور پایدار در حال اجرا هستند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی وضعیت Liveness و Readiness Probes” subtitle=”توضیحات کامل”]در کوبرنتیز، Liveness Probe و Readiness Probe ابزارهایی هستند که به کلاستر کمک می‌کنند تا از صحت و درستی عملکرد Pods و کانتینرها مطمئن شود. این ابزارها به Kubernetes این امکان را می‌دهند که بتواند تصمیمات خودکار در خصوص راه‌اندازی مجدد Pods یا ارسال ترافیک به آنها بگیرد. این دو پروب نقش کلیدی در حفظ پایداری و دسترسی بالای سرویس‌ها در محیط‌های مقیاس‌پذیر و خودکار Kubernetes دارند.

Liveness Probe:

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

زمانی که Liveness Probe باید فعال شود:

• هنگامی که یک کانتینر متوقف می‌شود یا وارد یک وضعیت غیرقابل دسترسی می‌شود، Liveness Probe فعال شده و اقدام به راه‌اندازی مجدد کانتینر می‌کند.
• اگر یک کانتینر برای مدت زیادی در حال پردازش باشد اما بدون هیچگونه خروجی‌ای (یا بسته شدن) باقی بماند، Liveness Probe به Kubernetes می‌گوید که این کانتینر در حالت “Deadlock” قرار دارد و باید دوباره راه‌اندازی شود.

نحوه پیکربندی Liveness Probe: برای تنظیم Liveness Probe در یک کانتینر در Pod، باید به‌طور خاص از livenessProbe در فایل YAML خود استفاده کنید. به‌عنوان مثال:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: example-image
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8080
      initialDelaySeconds: 3
      periodSeconds: 5

در اینجا:

• httpGet درخواست HTTP را به مسیر /healthz ارسال می‌کند تا بررسی کند که آیا سرویس به درستی کار می‌کند.
• initialDelaySeconds مقدار تأخیری است که Kubernetes قبل از انجام اولین بررسی باید منتظر بماند.
• periodSeconds تعیین می‌کند که چند ثانیه بین هر بررسی بعدی باید فاصله باشد.

Readiness Probe:

Readiness Probe به Kubernetes می‌گوید که آیا یک کانتینر آماده دریافت ترافیک از سرویس‌ها است یا خیر. این پروب برای تعیین اینکه آیا یک کانتینر به‌طور کامل راه‌اندازی شده و آماده پذیرش درخواست‌ها است، کاربرد دارد. اگر این پروب نشان دهد که کانتینر آماده نیست، Kubernetes ترافیک را به آن کانتینر ارسال نمی‌کند.

زمانی که Readiness Probe باید فعال شود:

• وقتی یک کانتینر هنوز آماده پذیرش درخواست‌ها نیست (مثلاً در حال بارگذاری یا آماده‌سازی محیط داخلی) Readiness Probe آن را شناسایی کرده و به Kubernetes اطلاع می‌دهد که ترافیک به آن کانتینر ارسال نشود.
• این می‌تواند در هنگام شروع به‌کار سرویس‌ها یا زمان‌های خاصی که در حال آماده‌سازی داده‌ها یا پیکربندی‌ها هستند، مفید باشد.

نحوه پیکربندی Readiness Probe: برای پیکربندی Readiness Probe، از readinessProbe در فایل YAML مشابه Liveness Probe استفاده می‌شود. مثالی از این پیکربندی به‌صورت زیر است:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: example-image
    readinessProbe:
      httpGet:
        path: /readiness
        port: 8080
      initialDelaySeconds: 5
      periodSeconds: 10

در اینجا:

• httpGet برای بررسی وضعیت /readiness از کانتینر استفاده می‌کند.
• initialDelaySeconds مدت تأخیر قبل از اولین درخواست بررسی را تعیین می‌کند.
• periodSeconds فاصله زمانی بین هر درخواست وضعیت بعدی را مشخص می‌کند.

تفاوت‌های بین Liveness و Readiness Probes:

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

جمع‌بندی:

Liveness و Readiness Probes ابزارهایی اساسی برای مدیریت سلامت و در دسترس بودن سرویس‌ها در Kubernetes هستند. Liveness Probe برای شناسایی و راه‌اندازی مجدد کانتینرهای ناکارآمد استفاده می‌شود، در حالی که Readiness Probe تضمین می‌کند که کانتینر تنها زمانی ترافیک دریافت کند که آماده باشد. با پیکربندی صحیح این پروب‌ها، می‌توان اطمینان حاصل کرد که سرویس‌ها به طور صحیح و بدون مشکل در محیط‌های Kubernetes اجرا می‌شوند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. مدیریت Events و رویدادها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دستور kubectl get events: مشاهده رویدادهای اخیر مرتبط با منابع” subtitle=”توضیحات کامل”]دستور kubectl get events یکی از دستورات کاربردی در Kubernetes است که به شما این امکان را می‌دهد تا رویدادهای اخیر و مهم مرتبط با منابع مختلف در کلاستر خود را مشاهده کنید. این رویدادها می‌توانند شامل اطلاع‌رسانی‌ها در خصوص تغییرات وضعیت منابع، هشدارها، خطاها، یا موفقیت‌ها باشند. این اطلاعات به شما کمک می‌کنند تا مشکلات کلاستر یا Pod‌های خاص را شناسایی کنید و با تحلیل آن‌ها به رفع مشکلات بپردازید.

کاربردهای دستور kubectl get events:

• مشاهده وضعیت و تغییرات منابع: می‌توانید اطلاعاتی از جمله وضعیت ایجاد و حذف Pods، تنظیمات یا تغییرات ConfigMap‌ها، و رویدادهای دیگر را دریافت کنید.
• تشخیص مشکلات: به‌ویژه برای تشخیص مشکلات موقتی یا خطاهایی که در کلاستر رخ داده‌اند (مثل مشکلات زمان راه‌اندازی Pods، مشکلات مربوط به منابع و یا اجزای شبکه) مفید است.
• تحلیل دقیق وضعیت و خطاها: هنگام بروز خطا یا مشکل در سیستم، می‌توان با بررسی رویدادها از جزئیات دقیق‌تری نسبت به دلیل مشکل و زمان بروز آن مطلع شد.

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

kubectl get events

این دستور به‌طور پیش‌فرض تمامی رویدادهای اخیر را برای تمامی منابع در فضای نام (namespace) جاری نمایش می‌دهد. خروجی معمولاً شامل اطلاعاتی مانند زمان وقوع رویداد، نوع رویداد، منبع (Pod، Node، یا سایر منابع)، و پیام مرتبط با رویداد است.

مثال خروجی:

LAST SEEN   TYPE      REASON                   OBJECT                             MESSAGE
3m          Normal    Scheduled                pod/nginx-7d95b4cbbd-8vn2b         Successfully assigned default/nginx-7d95b4cbbd-8vn2b to node-1
2m          Normal    Pulled                   pod/nginx-7d95b4cbbd-8vn2b         Container image "nginx:latest" already present on machine
1m          Normal    Created                  pod/nginx-7d95b4cbbd-8vn2b         Created container nginx
1m          Normal    Started                  pod/nginx-7d95b4cbbd-8vn2b         Started container nginx

در اینجا:

• LAST SEEN: زمان وقوع رویداد.
• TYPE: نوع رویداد، که می‌تواند Normal یا Warning باشد.
• REASON: دلیل رویداد (مثل “Scheduled”، “Pulled”، “Created”، “Started”).
• OBJECT: منبع مربوط به رویداد (مثل Pod، Deployment).
• MESSAGE: پیام توصیفی که اطلاعات بیشتری در مورد رویداد می‌دهد.

فیلتر کردن رویدادها:

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

• مشاهده رویدادهای مربوط به یک Pod خاص:

kubectl get events --field-selector involvedObject.name=nginx-7d95b4cbbd-8vn2b

• مشاهده رویدادها برای فضای نام خاص:

kubectl get events --namespace=default

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

برای مشاهده جزئیات بیشتر در مورد رویدادها، می‌توانید از پارامتر -o wide برای دریافت اطلاعات تکمیلی استفاده کنید.

kubectl get events -o wide

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

جمع‌بندی:

دستور kubectl get events یک ابزار قوی برای مشاهده و تجزیه و تحلیل رویدادهای مختلف در کلاستر Kubernetes است. این دستور به شما کمک می‌کند تا وضعیت فعلی منابع را بررسی کنید، مشکلات و خطاها را شناسایی نمایید و از تغییرات اخیر در کلاستر آگاه شوید. با استفاده از فیلترهای مناسب، می‌توان رویدادهای مربوط به منابع خاص را مشاهده کرده و برای حل مشکلات سریع‌تر اقدام کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تشخیص مشکلات شبکه، محدودیت منابع، یا خطاهای مرتبط با زمان‌بندی (Scheduling)” subtitle=”توضیحات کامل”]دستور kubectl get events در Kubernetes یکی از ابزارهای اساسی برای مشاهده و تجزیه‌ و تحلیل رویدادهای سیستم است. این دستور به‌ویژه برای شناسایی مشکلات و خطاهایی که ممکن است در کلاستر Kubernetes رخ دهد، مانند مشکلات شبکه، محدودیت منابع، یا خطاهای مربوط به زمان‌بندی (Scheduling)، بسیار مفید است. رویدادهایی که توسط این دستور نمایش داده می‌شوند، شامل پیام‌های خطا یا هشدارهایی از منابع مختلف در کلاستر مانند Pods، Nodes، Deployments و دیگر منابع هستند.

کاربردهای دستور kubectl get events برای تشخیص مشکلات:

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

   LAST SEEN   TYPE      REASON          OBJECT             MESSAGE
   5s          Warning   NetworkPolicy   pod/myapp-123      NetworkPolicy dropped pod communication
   

2. مشکلات مربوط به محدودیت منابع: وقتی که Pods نمی‌توانند به منابع کافی (مثل CPU یا حافظه) دسترسی پیدا کنند یا با محدودیت‌های منابع مواجه می‌شوند، رویدادهایی با نوع Warning ثبت خواهند شد که ممکن است بیانگر این باشند که Pod‌ها به‌دلیل مشکلات منابع (مثل OOMKilled) نتواسته‌اند اجرا شوند.مثال رویداد محدودیت منابع:

   LAST SEEN   TYPE      REASON         OBJECT                MESSAGE
   3m          Warning   OutOfMemory    pod/myapp-456         Container terminated due to memory limit
   2m          Warning   CPUThrottling  pod/myapp-789         Container CPU throttled due to resource limit
   

3. مشکلات زمان‌بندی (Scheduling): یکی از مشکلات رایج در Kubernetes، زمانی است که Pod‌ها به‌دلیل مشکلات در زمان‌بندی نمی‌توانند بر روی Node‌ها راه‌اندازی شوند. این مشکل معمولاً به‌دلیل کمبود منابع در نودها یا محدودیت‌های scheduler رخ می‌دهد. دستور kubectl get events به شما این امکان را می‌دهد که چنین مشکلاتی را شناسایی کنید.مثال رویداد زمان‌بندی:

   LAST SEEN   TYPE      REASON          OBJECT                MESSAGE
   2m          Warning   FailedScheduling pod/myapp-101         0/3 nodes are available: 3 Insufficient cpu.
   1m          Normal    Scheduled        pod/myapp-102         Successfully assigned default/myapp-102 to node-1
   

فیلتر کردن رویدادهای خاص:

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

مثال فیلتر برای مشکلات زمان‌بندی:

kubectl get events --field-selector reason=FailedScheduling

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

تحلیل و حل مشکلات با توجه به رویدادها:

1. مشکلات شبکه:
   • بررسی تنظیمات Network Policies برای اطمینان از این‌که ترافیک به درستی بین Pods مسیریابی می‌شود.
   • بررسی وضعیت شبکه کلاستر و بررسی Log‌های مرتبط با سرویس‌های شبکه.
2. مشکلات منابع:
   • تنظیم منابع (CPU، حافظه) در Pod‌ها و Node‌ها و یا استفاده از ResourceRequests و ResourceLimits برای جلوگیری از شرایط Overcommitment.
   • بررسی وضعیت Node‌ها و اطمینان از این‌که منابع کافی برای میزبانی Pod‌ها وجود دارد.
3. مشکلات زمان‌بندی:
   • اطمینان از این‌که Node‌های کافی برای اجرای Pods موجود هستند.
   • بررسی محدودیت‌های taints و tolerations برای اطمینان از این‌که Pod‌ها می‌توانند بر روی Node‌های مناسب اجرا شوند.

جمع‌بندی:

دستور kubectl get events به‌طور مؤثری به شما کمک می‌کند تا مشکلات مختلف کلاستر خود را شناسایی کنید. این دستور به شما امکان می‌دهد تا به‌ویژه مشکلات شبکه، محدودیت منابع، یا مشکلات زمان‌بندی را به‌سرعت شناسایی کرده و بر اساس رویدادهای ثبت‌شده، اقدامات اصلاحی را انجام دهید. استفاده از فیلترهای مناسب و تجزیه‌ و تحلیل دقیق‌تر رویدادها می‌تواند به‌طور قابل‌توجهی زمان تشخیص و رفع مشکلات را کاهش دهد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تحلیل وقایع: مرتب‌سازی وقایع بر اساس زمان یا نوع رویداد” subtitle=”توضیحات کامل”]یکی از جنبه‌های کلیدی در مدیریت Kubernetes، تحلیل وقایع (Events) است. این وقایع به‌طور مستقیم اطلاعات حیاتی در مورد وضعیت منابع و اتفاقاتی که در کلاستر رخ می‌دهند، ارائه می‌دهند. در واقع، رویدادها به‌عنوان یک سیستم اطلاع‌رسانی از وضعیت تغییرات، هشدارها، و خطاها در Kubernetes عمل می‌کنند.

برای تحلیل و حل مشکلات در Kubernetes، ابتدا باید این رویدادها را به‌طور دقیق بررسی کنید. یکی از روش‌های اصلی برای تحلیل وقایع، مرتب‌سازی آن‌ها بر اساس زمان یا نوع رویداد است. این کار کمک می‌کند تا شما بتوانید رویدادها را به‌طور مؤثر دسته‌بندی کرده و مشکلات را سریع‌تر شناسایی کنید.

مرتب‌سازی وقایع بر اساس زمان:

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

برای مرتب‌سازی رویدادها بر اساس زمان، می‌توانید از دستور kubectl get events استفاده کنید. به‌طور پیش‌فرض، این دستور رویدادها را از جدیدترین تا قدیمی‌ترین نمایش می‌دهد. اما می‌توانید با استفاده از گزینه‌های مختلف دستور آن را تغییر دهید.

مثال دستور برای مرتب‌سازی رویدادها بر اساس زمان:

kubectl get events --sort-by='.lastTimestamp'

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

مرتب‌سازی وقایع بر اساس نوع رویداد:

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

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

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

kubectl get events --field-selector type=Warning --sort-by='.lastTimestamp'

در این مثال، رویدادهایی که نوع آن‌ها Warning است (هشدارها) به‌صورت مرتب‌شده بر اساس زمان (آخرین به اولین) نمایش داده می‌شوند.

تجزیه‌ و تحلیل وقایع برای شناسایی مشکلات:

1. مشکلات مربوط به Pods:
   • با مرتب‌سازی بر اساس زمان، می‌توانید ببینید که چه زمانی یک Pod شروع به خرابی کرده یا مشکلاتی مانند CrashLoopBackOff رخ داده است.
   • با مرتب‌سازی بر اساس نوع، می‌توانید هشدارهای مرتبط با مشکلات منابع، زمان‌بندی یا اجرای Pods را مشاهده کنید.
2. مشکلات منابع:
   • مرتب‌سازی بر اساس نوع رویدادها می‌تواند شما را در تشخیص مشکلات مربوط به محدودیت‌های منابع یاری کند. به‌عنوان مثال، رویدادهایی با دلیل OutOfMemory یا CPUThrottling می‌توانند نشان‌دهنده مشکلات در تخصیص منابع به Pods باشند.
3. مشکلات شبکه:
   • با استفاده از دستور مرتب‌سازی می‌توانید رویدادهای شبکه‌ای را که مرتبط با دسترسی به سرویس‌ها، مشکلات DNS، یا NetworkPolicy هستند، شناسایی کرده و اقدام به رفع آن‌ها کنید.

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

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

مثال فیلتر با استفاده از grep:

kubectl get events --sort-by='.lastTimestamp' | grep 'OutOfMemory'

این دستور تمامی رویدادهایی که مرتبط با مشکلات OutOfMemory هستند را فیلتر کرده و به شما نشان می‌دهد.

جمع‌بندی:

مرتب‌سازی و تجزیه‌ و تحلیل وقایع یکی از ابزارهای حیاتی در مدیریت و نگهداری کلاستر Kubernetes است. با استفاده از دستور kubectl get events و مرتب‌سازی رویدادها بر اساس زمان یا نوع، می‌توانید مشکلات سیستم را به‌سرعت شناسایی کرده و اقدامات اصلاحی انجام دهید. فیلتر کردن دقیق‌تر با ابزارهای کمکی می‌تواند به شما در تجزیه‌ و تحلیل عمیق‌تر و مدیریت بهتر کلاستر کمک کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از ابزارهای خارجی برای ثبت و تحلیل وقایع” subtitle=”توضیحات کامل”]در Kubernetes، ابزارهای داخلی برای مشاهده و تجزیه‌ و تحلیل وقایع (Events) بسیار مفید هستند، اما در محیط‌های پیچیده و بزرگ‌مقیاس، نیاز به ابزارهای خارجی برای ثبت و تحلیل دقیق‌تر وقایع، نظارت بر منابع، و ارائه گزارش‌های قابل‌فهم‌تر است. این ابزارها می‌توانند به شما کمک کنند تا وضعیت سلامت کلاستر خود را به‌طور مداوم پایش کنید، مشکلات را سریع‌تر شناسایی نمایید و از توانایی‌های پیشرفته برای آنالیز و تجزیه‌ و تحلیل استفاده کنید.

در این بخش، به برخی از ابزارهای محبوب و رایج برای ثبت و تحلیل وقایع Kubernetes اشاره می‌کنیم.

1. Prometheus + Grafana

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

برای ثبت وقایع در Prometheus، معمولاً از kube-state-metrics یا node-exporter استفاده می‌شود که اطلاعات سیستم مانند میزان CPU، حافظه، وضعیت Pods و سایر منابع را جمع‌آوری می‌کنند. علاوه بر این، Prometheus می‌تواند از طریق Alertmanager هشدارهایی برای رخدادهای خاص در کلاستر ارسال کند.

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

مراحل نصب Prometheus و Grafana در Kubernetes:

1. نصب Prometheus:

   kubectl create -f https://github.com/prometheus-operator/kube-prometheus/blob/main/manifests/setup/prometheus-operator-crds.yaml
   kubectl create -f https://github.com/prometheus-operator/kube-prometheus/blob/main/manifests/prometheus-operator-deployment.yaml
   

2. نصب Grafana:

   kubectl create -f https://raw.githubusercontent.com/grafana/grafana-operator/master/deploy/crds/grafana.com_grafanas_crd.yaml
   kubectl apply -f https://raw.githubusercontent.com/grafana/grafana-operator/master/deploy/operator.yaml
   

3. استفاده از داشبورد Grafana برای مشاهده وضعیت وقایع:
   • بعد از نصب، می‌توانید به داشبورد Grafana وارد شوید و داده‌های مربوط به وقایع Kubernetes را بررسی کنید.

2. Elasticsearch, Fluentd, and Kibana (EFK Stack)

EFK (Elasticsearch, Fluentd, Kibana) یکی دیگر از مجموعه ابزارهای قدرتمند برای ثبت، ذخیره‌سازی، و تحلیل لاگ‌ها و وقایع در Kubernetes است. این مجموعه ابزار به‌طور ویژه برای جمع‌آوری، تجزیه‌ و تحلیل، و جستجوی لاگ‌ها و وقایع در سیستم‌های توزیع‌شده طراحی شده است.

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

مراحل نصب EFK Stack در Kubernetes:

1. نصب Fluentd برای ارسال لاگ‌ها به Elasticsearch:

   kubectl create -f https://raw.githubusercontent.com/fluent/fluentd-kubernetes-daemonset/master/kubernetes/fluentd-elasticsearch.yaml
   

2. نصب Elasticsearch:

   kubectl apply -f https://raw.githubusercontent.com/elastic/cloud-on-k8s/v1.9.0/deploy/crds/elasticsearch.k8s.elastic.co_elasticsearches_crd.yaml
   kubectl apply -f https://raw.githubusercontent.com/elastic/cloud-on-k8s/v1.9.0/deploy/crds/elasticsearch.k8s.elastic.co_elasticsearches_cr.yaml
   

3. نصب Kibana:

   kubectl apply -f https://raw.githubusercontent.com/elastic/cloud-on-k8s/v1.9.0/deploy/crds/kibana.k8s.elastic.co_kibanas_crd.yaml
   kubectl apply -f https://raw.githubusercontent.com/elastic/cloud-on-k8s/v1.9.0/deploy/crds/kibana.k8s.elastic.co_kibanas_cr.yaml
   

4. مشاهده لاگ‌ها از طریق Kibana:
   • بعد از نصب، می‌توانید با ورود به Kibana، تمامی وقایع و لاگ‌های مربوط به کلاستر Kubernetes را جستجو و تجزیه‌ و تحلیل کنید.

3. Loki + Promtail (از Grafana Labs)

Loki مشابه با Elasticsearch است اما به‌طور خاص برای لاگ‌ها طراحی شده است و می‌تواند به‌راحتی با Promtail که یک agent جمع‌آوری لاگ‌ها است، ترکیب شود. Loki به‌عنوان سیستم ذخیره‌سازی برای لاگ‌ها عمل می‌کند، در حالی که Promtail برای ارسال لاگ‌ها از Kubernetes به Loki به کار می‌رود.

یکی از ویژگی‌های برجسته Loki این است که مشابه Prometheus برای ذخیره‌سازی و تجزیه‌ و تحلیل داده‌های متنی (لاگ‌ها) طراحی شده است و این کار را با حجم کمی از منابع انجام می‌دهد.

مراحل نصب Loki و Promtail در Kubernetes:

1. نصب Loki:

   kubectl create -f https://raw.githubusercontent.com/grafana/loki/main/production/kubernetes/helm/loki.yaml
   

2. نصب Promtail:

   kubectl create -f https://raw.githubusercontent.com/grafana/loki/main/production/kubernetes/helm/promtail.yaml
   

3. مشاهده لاگ‌ها در Grafana:
   • بعد از نصب، می‌توانید به داشبورد Grafana وارد شوید و لاگ‌های Kubernetes را از Loki مشاهده کنید.

4. Datadog

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

مراحل نصب Datadog در Kubernetes:

1. نصب Agent Datadog:

   kubectl create -f https://github.com/DataDog/datadog-agent/blob/main/deployments/kubernetes/datadog-agent.yaml
   

2. مشاهده داده‌ها و وقایع در داشبورد Datadog:
   • بعد از نصب، می‌توانید به داشبورد Datadog وارد شوید و تمامی اطلاعات مربوط به Kubernetes را مشاهده کنید.

جمع‌بندی:

استفاده از ابزارهای خارجی برای ثبت و تحلیل وقایع در Kubernetes می‌تواند به‌طور قابل‌توجهی در بهبود عملکرد کلاستر و شناسایی سریع‌تر مشکلات کمک کند. ابزارهایی مانند Prometheus + Grafana، EFK Stack (Elasticsearch, Fluentd, Kibana)، Loki + Promtail و Datadog می‌توانند به‌طور مؤثر وقایع و لاگ‌های سیستم را جمع‌آوری و تحلیل کنند و از طریق داشبوردهای گرافیکی و هشدارهای خودکار، امکان پیگیری و رفع مشکلات را برای شما فراهم کنند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. رفع مشکلات ارتباطات شبکه”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”شناسایی محدودیت‌های شبکه با بررسی تنظیمات Network Policy” subtitle=”توضیحات کامل”]Network Policies در Kubernetes ابزارهای قدرتمندی هستند که به شما اجازه می‌دهند تا ترافیک شبکه‌ای بین Podها را کنترل و محدود کنید. این قابلیت به‌ویژه برای ایجاد امنیت در برابر دسترسی‌های ناخواسته و محدود کردن ارتباطات شبکه‌ای بین سرویس‌ها و منابع مختلف در کلاستر استفاده می‌شود. با استفاده از Network Policies، شما می‌توانید مشخص کنید که کدام Podها می‌توانند به کدام دیگر دسترسی داشته باشند، یا حتی ممکن است ترافیک ورودی و خروجی را از منابع خاصی مسدود کنید.

در این بخش، به بررسی روش‌ها و نکات کلیدی برای شناسایی محدودیت‌های شبکه و تحلیل تنظیمات Network Policy در Kubernetes خواهیم پرداخت.

1. ساختار و نحوه کار Network Policies

یک Network Policy شامل دو بخش اصلی است:

1. Ingress: این بخش کنترل می‌کند که چه ترافیکی می‌تواند به Pod وارد شود.
2. Egress: این بخش کنترل می‌کند که چه ترافیکی می‌تواند از Pod خارج شود.

این تنظیمات می‌توانند مبتنی بر IP Address، Namespace، یا Label Selector باشند، که به‌طور دقیق‌تر ترافیک را مشخص و محدود می‌کنند. به‌طور پیش‌فرض، Kubernetes هیچ Network Policy فعال ندارد و ترافیک آزادانه جریان دارد. برای اعمال محدودیت‌ها، باید یک Network Policy تعریف کنید.

2. اجزای یک Network Policy

یک Network Policy معمولاً شامل بخش‌های زیر است:

• Pod Selector: مشخص می‌کند که کدام Podها تحت پوشش این Policy قرار می‌گیرند.
• Policy Types: مشخص می‌کند که این Policy برای Ingress، Egress یا هر دو اعمال می‌شود.
• Ingress/Egress Rules: شامل تنظیماتی است که تعیین می‌کند چه منابعی می‌توانند به Pod ترافیک ارسال کنند و چه منابعی می‌توانند از Pod ترافیک دریافت کنند.

3. بررسی محدودیت‌های شبکه با Network Policy

برای شناسایی محدودیت‌های شبکه و نحوه تاثیرگذاری Network Policyها بر ارتباطات در کلاستر، باید موارد زیر را بررسی کنید:

الف) بررسی Network Policyهای موجود در کلاستر

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

kubectl get networkpolicies --all-namespaces

این دستور لیستی از تمام Network Policyها در تمام Namespaces را به شما نشان می‌دهد.

ب) تجزیه‌ و تحلیل تنظیمات Ingress و Egress

پس از شناسایی Network Policyهای موجود، می‌توانید تنظیمات Ingress و Egress هر Policy را بررسی کنید. این کار به شما کمک می‌کند تا مشخص کنید چه منابعی مجاز به ارتباط با Pod مورد نظر هستند.

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

kubectl describe networkpolicy <policy-name> -n <namespace-name>

این دستور اطلاعات دقیق‌تری را درباره‌ی محدودیت‌های شبکه برای Podها در قالب Ingress و Egress نمایش می‌دهد.

ج) بررسی Policyهای فعال

یکی از مهم‌ترین جنبه‌ها در بررسی محدودیت‌های شبکه، ارزیابی وضعیت Network Policies فعال است. اگر Network Policy برای Pod یا سرویس خاصی اعمال شده باشد، ترافیک شبکه آن Pod یا سرویس تحت تاثیر قرار خواهد گرفت. به همین دلیل باید اطمینان حاصل کنید که برای Podهایی که نیاز به دسترسی‌های خاص دارند، سیاست‌های صحیحی تنظیم شده باشد.

برای بررسی وضعیت Network Policyهای فعال در یک namespace خاص، از دستور زیر استفاده کنید:

kubectl get networkpolicy -n <namespace-name>

این دستور به شما نشان می‌دهد که آیا Network Policy خاصی در آن namespace اعمال شده است یا خیر.

د) شبیه‌سازی ترافیک و آزمایش ارتباطات

یکی از روش‌های موثر برای شناسایی محدودیت‌های شبکه، شبیه‌سازی ترافیک و بررسی ارتباطات است. برای این کار، می‌توانید از ابزارهایی مانند kubectl exec برای برقراری ارتباط با یک Pod و تست ارتباطات بین Pods مختلف استفاده کنید.

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

kubectl exec -it <pod-name> -n <namespace-name> -- curl <target-pod-ip>:<port>

اگر Network Policy محدودیتی برای ترافیک بین این دو Pod در نظر گرفته باشد، این دستور ممکن است با خطا مواجه شود و قادر به برقراری ارتباط نباشید.

4. نمونه‌ای از تعریف Network Policy برای محدود کردن دسترسی

در اینجا یک نمونه ساده از تعریف یک Network Policy را ارائه می‌دهیم که فقط به Podهایی که از همان namespace و با استفاده از آدرس IP خاص به Pod مقصد دسترسی دارند اجازه می‌دهد:

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

در این Network Policy، ترافیک ورودی از دیگر Podهایی که در همان namespace و با همان label قرار دارند، مجاز است و فقط بر روی پورت 80 می‌تواند ترافیک ارسال کند.

جمع‌بندی:

بررسی و شناسایی محدودیت‌های شبکه در Kubernetes با استفاده از Network Policies به شما کمک می‌کند تا ترافیک بین منابع مختلف کلاستر را به‌طور دقیق کنترل کنید. با تنظیمات صحیح Ingress و Egress، می‌توانید امنیت شبکه را در کلاستر خود افزایش دهید و از دسترسی‌های غیرمجاز به منابع جلوگیری کنید. برای این منظور، ابزارهایی مانند دستور kubectl describe و آزمایش ارتباطات با استفاده از kubectl exec می‌توانند به شما در شناسایی مشکلات و محدودیت‌های شبکه کمک کنند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی سرویس‌ها و DNS: تست ارتباطات بین Pod‌ها و سرویس‌ها” subtitle=”توضیحات کامل”]در Kubernetes، سرویس‌ها و DNS بخش‌های مهمی از زیرساخت شبکه‌ای هستند که به شما امکان می‌دهند تا بین Pod‌ها ارتباط برقرار کنید و منابع مختلف در کلاستر را از طریق نام‌های دامنه قابل دسترسی کنید. DNS در Kubernetes به طور خودکار برای سرویس‌ها و Pod‌ها تنظیم می‌شود تا دسترسی به منابع از طریق نام دامنه راحت‌تر و بدون نیاز به حفظ آدرس IPها باشد. در این بخش، به بررسی نحوه تست ارتباطات بین Pod‌ها و سرویس‌ها خواهیم پرداخت.

1. آشنایی با سرویس‌ها در Kubernetes

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

• ClusterIP: پیش‌فرض ترین نوع سرویس است که به سرویس اجازه می‌دهد تنها از داخل کلاستر دسترسی داشته باشد.
• NodePort: این سرویس اجازه می‌دهد که از خارج کلاستر به سرویس‌ها دسترسی داشته باشید.
• LoadBalancer: این سرویس برای محیط‌های ابری استفاده می‌شود و یک آدرس IP عمومی برای دسترسی به سرویس‌ها فراهم می‌کند.
• ExternalName: این سرویس به شما این امکان را می‌دهد که به سرویس‌های خارج از کلاستر دسترسی داشته باشید.

2. DNS در Kubernetes

Kubernetes به‌طور خودکار برای هر سرویس یک رکورد DNS ایجاد می‌کند که نام سرویس را به آدرس IP آن سرویس می‌نگارد. این ویژگی باعث می‌شود که دسترسی به سرویس‌ها و Pod‌ها از طریق DNS بسیار ساده شود.

برای مثال، در صورتی که یک سرویس به نام my-service در namespace default تعریف شده باشد، DNS آن به صورت زیر خواهد بود:

my-service.default.svc.cluster.local

این نام DNS به شما این امکان را می‌دهد که به جای استفاده از آدرس IP، تنها با استفاده از نام سرویس، به آن دسترسی پیدا کنید.

3. تست ارتباطات بین Pod‌ها و سرویس‌ها

برای تست ارتباطات بین Pod‌ها و سرویس‌ها، می‌توانید از ابزارهایی مانند curl، wget یا nc (netcat) برای ارسال درخواست‌ها از داخل Pod به سرویس‌های مختلف استفاده کنید. در اینجا چند روش برای انجام این کار آورده شده است.

الف) دسترسی به سرویس‌ها از داخل Pod

برای تست اینکه یک Pod می‌تواند به سرویس خاصی در کلاستر دسترسی داشته باشد، ابتدا به Pod مورد نظر متصل شوید:

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

پس از ورود به داخل Pod، می‌توانید از دستور curl برای ارسال درخواست HTTP به سرویس مورد نظر استفاده کنید. به عنوان مثال، برای ارسال درخواست به سرویس my-service در namespace default می‌توانید از دستور زیر استفاده کنید:

curl my-service.default.svc.cluster.local

اگر سرویس در دسترس باشد، پاسخ از سرویس دریافت خواهید کرد.

ب) استفاده از nslookup برای بررسی DNS

یکی از ابزارهای مفید برای بررسی صحت تنظیمات DNS در داخل کلاستر Kubernetes، استفاده از دستور nslookup است. این دستور به شما امکان می‌دهد تا بررسی کنید که آیا سرویس DNS به درستی کار می‌کند یا نه.

برای استفاده از nslookup داخل Pod:

kubectl exec -it <pod-name> -- nslookup my-service.default.svc.cluster.local

این دستور باید آدرس IP مربوط به سرویس my-service را بازگرداند. اگر این آدرس IP دریافت نشد یا خطا دریافت کردید، ممکن است مشکلی در تنظیمات DNS وجود داشته باشد.

ج) تست اتصال از داخل Pod به سرویس‌ها با استفاده از پورت

گاهی اوقات ممکن است بخواهید اتصال به سرویس‌های خاص را با استفاده از پورت‌های خاصی تست کنید. برای این منظور، می‌توانید از دستور nc (netcat) استفاده کنید که به شما اجازه می‌دهد اتصال به پورت خاصی از سرویس‌ها را بررسی کنید.

برای مثال، برای بررسی اتصال به پورت 80 سرویس my-service از داخل Pod، از دستور زیر استفاده کنید:

kubectl exec -it <pod-name> -- nc -zv my-service.default.svc.cluster.local 80

اگر سرویس در دسترس باشد، پاسخ مشابه به این خواهید دید:

Connection to my-service.default.svc.cluster.local 80 port [tcp/http] succeeded!

4. بررسی دسترسی به سرویس‌های خارجی

اگر شما از سرویس ExternalName استفاده می‌کنید که به منابع خارج از کلاستر اشاره دارد، می‌توانید از همان روش‌ها برای تست دسترسی استفاده کنید. به عنوان مثال، برای دسترسی به یک سرویس خارجی مانند my-external-service.com از داخل یک Pod، می‌توانید از دستور زیر استفاده کنید:

kubectl exec -it <pod-name> -- curl my-external-service.com

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

جمع‌بندی:

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

1. آشنایی با ابزار nslookup

nslookup یک ابزار خط فرمان برای پرس‌و‌جو در DNS است که به شما این امکان را می‌دهد تا رکوردهای DNS را بررسی کنید. این ابزار می‌تواند برای تشخیص مشکلات مختلف DNS در کلاستر Kubernetes مانند بررسی صحیح بودن نام‌های سرویس و درستی تنظیمات DNS استفاده شود.

برای استفاده از nslookup داخل یک Pod، ابتدا باید وارد Pod شوید:

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

پس از ورود به Pod، می‌توانید از دستور nslookup برای بررسی نام دامنه سرویس‌ها استفاده کنید. به عنوان مثال، برای بررسی رکورد DNS سرویس my-service در namespace default:

nslookup my-service.default.svc.cluster.local

اگر DNS به درستی کار کند، باید آدرس IP مربوط به سرویس را دریافت کنید. اگر پاسخ منفی یا خطا دریافت کردید، ممکن است مشکلی در پیکربندی DNS یا سرویس‌ها وجود داشته باشد.

2. آشنایی با ابزار dig

ابزار dig (Domain Information Groper) نیز ابزاری مشابه nslookup است که برای بررسی و تست رکوردهای DNS به کار می‌رود، اما خروجی دقیق‌تری نسبت به nslookup ارائه می‌دهد. از این ابزار می‌توان برای بررسی دقیق‌تر اطلاعات DNS استفاده کرد.

برای استفاده از dig در داخل یک Pod، ابتدا وارد Pod شوید:

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

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

dig my-service.default.svc.cluster.local

خروجی مشابه به این خواهید دید:

; <<>> DiG 9.10.6 <<>> my-service.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12345
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
;my-service.default.svc.cluster.local. IN A
;; ANSWER SECTION:
my-service.default.svc.cluster.local. 60 IN A 10.96.0.1
;; AUTHORITY SECTION:
default.svc.cluster.local. 60 IN NS ns.dns.cluster.local.
;; ADDITIONAL SECTION:
ns.dns.cluster.local. 60 IN A 10.96.0.10

در این خروجی، می‌توانید اطلاعات دقیق در مورد رکورد A (آدرس IP) سرویس مورد نظر، سرورهای نام (Nameservers) و سایر جزئیات مرتبط را مشاهده کنید.

3. استفاده از nslookup و dig برای شناسایی مشکلات DNS

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

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

4. استفاده از dig برای شناسایی جزئیات بیشتر

یکی از مزایای بزرگ dig نسبت به nslookup این است که dig` می‌تواند اطلاعات بیشتری مانند زمان پاسخ‌دهی (query time) و مسیر سرورهای نام (nameservers) را نشان دهد. این ویژگی به شما کمک می‌کند تا مشکلات پیچیده‌تری مانند مشکل در سرورهای نام را شناسایی کنید.

برای مثال، استفاده از دستور زیر برای شبیه‌سازی یک پرس‌وجو برای رکورد MX (Mail Exchange) یا CNAME نیز ممکن است به شما کمک کند تا بررسی‌های دقیق‌تری داشته باشید:

dig +short CNAME my-service.default.svc.cluster.local

این دستور به شما یک پاسخ کوتاه از رکورد CNAME می‌دهد، که در برخی مواقع می‌تواند مفید باشد.

جمع‌بندی:

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

1. چگونگی کارکرد kubectl proxy:

دستور kubectl proxy به‌طور موقت یک پروکسی HTTP در سیستم محلی شما راه‌اندازی می‌کند که به درخواست‌ها اجازه می‌دهد تا به سرویس‌ها و منابع مختلف در داخل کلاستر Kubernetes دسترسی پیدا کنند. این پروکسی معمولاً بر روی پورت 8001 راه‌اندازی می‌شود، اما می‌توانید این پورت را تغییر دهید.

2. اجرای دستور kubectl proxy:

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

kubectl proxy

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

برای مثال، برای دسترسی به Dashboard Kubernetes (که یک سرویس داخلی است) به‌طور مستقیم از طریق مرورگر، از URL زیر استفاده کنید:

http://localhost:8001/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

3. انتخاب پورت دلخواه:

اگر بخواهید پورت پروکسی را به پورت دلخواه تغییر دهید، می‌توانید از گزینه --port استفاده کنید. برای مثال:

kubectl proxy --port=8080

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

http://localhost:8080/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/

4. دسترسی به منابع مختلف:

از پروکسی ایجادشده می‌توانید برای دسترسی به منابع مختلف مانند سرویس‌ها، Pod‌ها، و یا حتی API‌های Kubernetes استفاده کنید. به‌طور مثال:

• دسترسی به لیست Pod‌ها:

curl http://localhost:8001/api/v1/pods

• دسترسی به سرویس خاص:

curl http://localhost:8001/api/v1/namespaces/default/services/my-service:8080/proxy/

5. محدودیت‌ها و امنیت:

استفاده از kubectl proxy بیشتر برای تست و دسترسی موقت به سرویس‌های داخلی در محیط توسعه و تست مناسب است. در محیط‌های تولید، برای دسترسی به سرویس‌ها به‌طور معمول از Ingress Controllers، Load Balancers، یا سرویس‌های دیگر استفاده می‌شود که امنیت بیشتری را فراهم می‌کنند.

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

جمع‌بندی:

دستور kubectl proxy یک ابزار ساده و مؤثر برای دسترسی به سرویس‌ها و منابع داخلی Kubernetes از طریق پروکسی HTTP است. این ابزار برای بررسی سرویس‌ها، API‌ها و دیگر منابع در داخل کلاستر مفید است، به‌ویژه در محیط‌های توسعه و تست. به‌وسیله این پروکسی می‌توان دسترسی به سرویس‌های مختلف را به‌صورت موقت فراهم کرد و از آن برای تحلیل مشکلات شبکه و سرویس‌ها استفاده نمود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. استفاده از ابزارهای داخلی و خارجی”][/cdb_course_lesson][cdb_course_lesson title=”ابزارهای داخلی Kubernetes:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Dashboard برای نظارت گرافیکی” subtitle=”توضیحات کامل”]در Kubernetes ابزارهای مختلفی برای مدیریت و نظارت بر کلاستر وجود دارند که می‌توانند به سادگی عملیات روزمره را تسهیل کنند. یکی از این ابزارها، Kubernetes Dashboard است که یک رابط گرافیکی وب‌بیس است و به شما امکان می‌دهد تا وضعیت کلاستر خود را به‌طور گرافیکی مشاهده کنید، منابع مختلف مانند Pod‌ها، Service‌ها، Deployment‌ها و سایر منابع را مدیریت کنید.

1. آشنایی با Kubernetes Dashboard:

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

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

• نمایش لیستی از منابع مختلف مانند Pod‌ها، Deployment‌ها، ReplicaSets، Services، و ConfigMaps.
• امکان ایجاد و ویرایش منابع جدید مانند Pod‌ها و Deployment‌ها.
• نظارت بر وضعیت کلاستر و مشاهده لاگ‌ها و جزئیات خطاها.
• امکان بررسی وضعیت منابع و مشاهده نمودارهای مصرف منابع.

2. نصب و راه‌اندازی Kubernetes Dashboard:

برای نصب و راه‌اندازی Kubernetes Dashboard، می‌توانید از دستوراتی که در زیر آمده است استفاده کنید. این روش‌ها به‌صورت پیش‌فرض در اکثر کلاسترهای Kubernetes قابل استفاده هستند.

• نصب Dashboard: برای نصب Dashboard از YAML آماده استفاده می‌شود:

kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.5.0/aio/deploy/recommended.yaml

این دستور، تمامی منابع مورد نیاز برای اجرای Kubernetes Dashboard را در کلاستر شما ایجاد می‌کند.

• ایجاد سرویس حساب برای دسترسی به Dashboard (اختیاری): اگر می‌خواهید دسترسی به Dashboard را با یک سرویس حساب خاص تنظیم کنید، باید یک ServiceAccount ایجاد کنید و آن را به یک ClusterRoleBinding متصل کنید. برای این کار می‌توانید فایل YAML زیر را استفاده کنید:

apiVersion: v1
kind: ServiceAccount
metadata:
  name: dashboard-admin
  namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dashboard-admin
subjects:
- kind: ServiceAccount
  name: dashboard-admin
  namespace: kubernetes-dashboard
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io

پس از ایجاد این منابع، می‌توانید یک توکن دسترسی برای dashboard-admin ایجاد کرده و از آن برای ورود به Dashboard استفاده کنید.

• دریافت توکن دسترسی (برای ورود به Dashboard):

kubectl -n kubernetes-dashboard create token dashboard-admin

این دستور توکنی را تولید می‌کند که می‌توانید از آن برای ورود به Dashboard استفاده کنید.

3. دسترسی به Kubernetes Dashboard:

برای دسترسی به Kubernetes Dashboard از طریق پروکسی محلی، دستور زیر را وارد کنید:

kubectl proxy

این دستور پروکسی HTTP را بر روی سیستم شما راه‌اندازی می‌کند. سپس می‌توانید از مرورگر خود به داشبورد دسترسی پیدا کنید:

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

در این URL، پس از ورود با استفاده از توکن دسترسی که قبلاً دریافت کرده‌اید، می‌توانید داشبورد را مشاهده کرده و منابع مختلف را مدیریت کنید.

4. ویژگی‌های Kubernetes Dashboard:

• مدیریت منابع:
  • شما می‌توانید منابع مختلفی مانند Pod‌ها، Deployment‌ها، ReplicaSet‌ها، و Services را ایجاد، ویرایش، و حذف کنید.
• نظارت و مانیتورینگ:
  • وضعیت کلی کلاستر، مصرف منابع (CPU، حافظه) و وضعیت منابع را مشاهده کنید. همچنین می‌توانید نمودارهای مصرف منابع را برای هر Pod یا Deployment ببینید.
• مشاهده لاگ‌ها:
  • امکان مشاهده لاگ‌های هر Pod و کانتینر موجود در کلاستر به‌صورت گرافیکی وجود دارد.
• ورود و مدیریت خطاها:
  • مشاهده جزئیات خطاها و وضعیت Pod‌ها مانند CrashLoopBackOff یا ImagePullBackOff.
• ایجاد منابع جدید:
  • از طریق رابط گرافیکی Dashboard می‌توانید منابع جدیدی نظیر Pod‌ها، Deployment‌ها و Service‌ها را ایجاد کنید.

5. محدودیت‌ها و امنیت Kubernetes Dashboard:

• دسترسی محدود به Dashboard:
  • برای استفاده از Kubernetes Dashboard در محیط‌های تولید، لازم است که دسترسی‌های آن محدود شود. توصیه می‌شود که از Role-Based Access Control (RBAC) برای تعیین دسترسی‌ها استفاده کنید و از توکن‌های کوتاه‌مدت یا سیستم‌های احراز هویت مطمئن استفاده کنید.
• امنیت در برابر حملات:
  • به دلیل اینکه Dashboard به منابع کل کلاستر دسترسی دارد، باید آن را تنها در موارد ضروری و با دسترسی‌های کنترل‌شده به‌کار برد.

جمع‌بندی:

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

 [/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ابزارهای داخلی مانند kubectl debug (در نسخه‌های جدید)” subtitle=”توضیحات کامل”]در Kubernetes، یکی از ابزارهای مفید برای دیباگ کردن منابع مختلف، دستور kubectl debug است. این ابزار به شما این امکان را می‌دهد که به راحتی وضعیت Pod‌ها، کانتینر‌ها و سایر منابع را بررسی کنید و مشکلات احتمالی را شناسایی کنید. این ابزار به‌ویژه در نسخه‌های جدید Kubernetes به عنوان یکی از ویژگی‌های قدرتمند معرفی شده است.

1. آشنایی با kubectl debug:

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

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

2. نصب و استفاده از kubectl debug:

برای استفاده از دستور kubectl debug، نسخه Kubernetes شما باید حداقل 1.18 یا بالاتر باشد. همچنین باید ابزار kubectl-debug بر روی کلاستر شما فعال باشد. در بسیاری از نسخه‌های Kubernetes، این ابزار به‌صورت پیش‌فرض فعال است، اما در برخی موارد ممکن است نیاز به فعال‌سازی آن باشد.

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

kubectl debug POD_NAME -it --image=busybox --target=TARGET_CONTAINER

در این دستور:

• POD_NAME: نام Pod هدفی که می‌خواهید دیباگ کنید.
• -it: به شما امکان وارد شدن به یک محیط تعاملی در کانتینر می‌دهد.
• --image=busybox: تصویری که می‌خواهید برای دیباگ استفاده کنید (در اینجا از تصویر busybox برای نمونه استفاده شده است).
• --target=TARGET_CONTAINER: مشخص می‌کند که هدف شما کدام کانتینر درون Pod است که می‌خواهید آن را دیباگ کنید (اختیاری است و فقط برای Pod‌های چند کانتینری استفاده می‌شود).

3. اضافه کردن کانتینر دیباگ به Pod:

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

kubectl debug POD_NAME -it --image=busybox --target=TARGET_CONTAINER --container=debug-container

در این دستور:

• --container=debug-container: این گزینه نام کانتینر جدیدی را که به Pod برای دیباگ اضافه می‌شود، مشخص می‌کند.

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

4. استفاده از kubectl debug برای متصل شدن به کانتینر:

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

kubectl debug POD_NAME -it --image=busybox --container=debug-container --command

در این دستور:

• --command: به Kubernetes دستور می‌دهد که این کانتینر برای دیباگ اجرا شود بدون اینکه به‌طور پیش‌فرض برنامه اصلی کانتینر اجرا شود. در این حالت شما می‌توانید از محیط آن برای تست و دیباگ استفاده کنید.

5. مزایای kubectl debug:

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

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

6. استفاده از kubectl debug در ترکیب با دیگر ابزارهای دیباگ:

در کنار دستور kubectl debug، می‌توانید از ابزارهای دیگر دیباگ مانند kubectl logs, kubectl describe, و kubectl top برای دریافت اطلاعات دقیق‌تر در مورد وضعیت کلاستر و منابع مختلف استفاده کنید. ترکیب این ابزارها به شما این امکان را می‌دهد که یک فرآیند دیباگ موثرتر داشته باشید و مشکلات کلاستر خود را سریع‌تر پیدا کنید.

7. نمونه‌های عملی از استفاده kubectl debug:

• مشاهده مشکلات یک کانتینر خاص در یک Pod: فرض کنید یک Pod با چندین کانتینر دارید و یکی از آن‌ها با مشکلاتی مواجه شده است. برای دیباگ، می‌توانید از دستور زیر استفاده کنید:

  kubectl debug mypod -it --image=busybox --target=container1
  

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

  kubectl debug mypod -it --image=busybox --container=debug-container --command
  

جمع‌بندی:

دستور kubectl debug یک ابزار مفید برای دیباگ کردن منابع Kubernetes است که به شما این امکان را می‌دهد که به‌راحتی به Pod‌ها و کانتینرهای موجود دسترسی پیدا کنید و مشکلات آن‌ها را شناسایی کنید. این ابزار از نسخه‌های جدید Kubernetes به‌طور پیش‌فرض موجود است و با استفاده از آن می‌توانید کانتینرهای جدید برای دیباگ کردن مشکلات اضافه کنید، به محیط‌های تعاملی وارد شوید و مشکلات را به‌طور سریع و ساده حل کنید.[/cdb_course_lesson][cdb_course_lesson title=”ابزارهای خارجی برای مانیتورینگ:”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Prometheus و Grafana برای نظارت دقیق منابع” subtitle=”توضیحات کامل”]در محیط‌های Kubernetes، نظارت بر عملکرد و سلامت منابع از اهمیت ویژه‌ای برخوردار است. برای این کار، ابزارهای مختلفی وجود دارند که به شما کمک می‌کنند تا به‌طور مؤثر مصرف منابع، وضعیت و عملکرد سرویس‌ها را مانیتور کنید. یکی از بهترین و پرکاربردترین ترکیب‌ها برای نظارت، استفاده از Prometheus برای جمع‌آوری متریک‌ها و Grafana برای تجزیه و تحلیل و نمایش این متریک‌ها است. در این بخش، نحوه استفاده از این ابزارها را برای نظارت دقیق‌تر بر منابع Kubernetes شرح خواهیم داد.

1. آشنایی با Prometheus:

Prometheus یک سیستم جمع‌آوری و ذخیره‌سازی متریک‌های زمان‌واقعی است که بر اساس مدل داده‌ای از نوع pull طراحی شده است. این ابزار معمولاً برای نظارت بر عملکرد و مصرف منابع در Kubernetes استفاده می‌شود و به‌طور گسترده در اکوسیستم Kubernetes برای جمع‌آوری متریک‌ها از اجزا و سرویس‌های مختلف استفاده می‌شود. Prometheus به‌طور خودکار از API‌های Kubernetes داده‌های مربوط به منابع مانند Pod‌ها، Node‌ها و سرویس‌ها را جمع‌آوری می‌کند.

ویژگی‌های Prometheus:

• جمع‌آوری متریک‌ها به صورت pull از منابع.
• ذخیره‌سازی داده‌ها در یک پایگاه داده time-series.
• قابلیت query کردن داده‌ها با زبان PromQL.
• ادغام با ابزارهای گرافیکی مانند Grafana.

2. نصب Prometheus در Kubernetes:

برای استفاده از Prometheus در Kubernetes، می‌توانید از ابزارهایی مانند Helm برای نصب و پیکربندی آن استفاده کنید. در ادامه مراحل نصب Prometheus را شرح می‌دهیم:

1. نصب Helm (در صورت عدم نصب):ابتدا Helm را نصب کنید. برای نصب Helm، از دستور زیر استفاده کنید:

   curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
   

2. اضافه کردن مخزن Prometheus به Helm:

   helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
   helm repo update
   

3. نصب Prometheus با Helm:برای نصب Prometheus از دستور زیر استفاده کنید:

   helm install prometheus prometheus-community/kube-prometheus-stack
   

   این دستور بسته کامل Prometheus و سایر ابزارهای وابسته را به Kubernetes نصب می‌کند.

3. آشنایی با Grafana:

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

ویژگی‌های Grafana:

• قابلیت اتصال به منابع مختلف داده مانند Prometheus.
• ایجاد داشبوردهای سفارشی با انواع گراف‌ها و ویجت‌ها.
• ارائه قابلیت‌های alerting برای ارسال هشدارها بر اساس متریک‌ها.

4. نصب Grafana در Kubernetes:

اگر هنوز Grafana را در کلاستر خود نصب نکرده‌اید، می‌توانید آن را با استفاده از Helm نصب کنید. برای این کار، مراحل زیر را دنبال کنید:

1. نصب Grafana با استفاده از Helm:برای نصب Grafana از دستور زیر استفاده کنید:

   helm install grafana prometheus-community/grafana
   

2. پیکربندی اتصال Grafana به Prometheus:برای اینکه Grafana داده‌ها را از Prometheus دریافت کند، باید منابع Prometheus را به Grafana متصل کنید. اگر از بسته Helm استفاده کرده‌اید، به‌طور خودکار این اتصال برقرار خواهد شد. در غیر این صورت، شما باید منبع داده Prometheus را به‌صورت دستی در تنظیمات Grafana اضافه کنید.وارد داشبورد Grafana شوید و در قسمت Data Sources منبع داده Prometheus را اضافه کنید:
   • URL: http://prometheus-server.default.svc.cluster.local
   • سپس دکمه Save & Test را بزنید تا اتصال برقرار شود.

5. ایجاد داشبوردهای Grafana برای نظارت بر منابع Kubernetes:

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

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

1. داشبورد Kubernetes پیش‌ساخته: Grafana یک مجموعه داشبوردهای آماده برای Kubernetes ارائه می‌دهد که شما می‌توانید آن‌ها را از طریق لینک‌های زیر وارد کنید:
   • وارد داشبورد Grafana شوید.
   • به بخش + Create بروید و Import را انتخاب کنید.
   • در قسمت Grafana.com Dashboard، شناسه داشبورد 315 را وارد کنید که یک داشبورد پیش‌ساخته برای نظارت بر Kubernetes است.
2. ایجاد داشبورد سفارشی: شما می‌توانید داشبورد خود را برای نمایش متریک‌های خاص از Kubernetes ایجاد کنید. برای این کار، از PromQL (زبان پرس‌وجو Prometheus) برای جمع‌آوری داده‌ها استفاده خواهید کرد.

6. نظارت بر منابع با استفاده از Prometheus و Grafana:

حالا که Prometheus و Grafana نصب و پیکربندی شده‌اند، می‌توانید شروع به نظارت بر منابع Kubernetes کنید. این می‌تواند شامل نظارت بر موارد زیر باشد:

• مصرف CPU و حافظه Node‌ها و Pod‌ها.
• درصد استفاده از فضای ذخیره‌سازی.
• تعداد درخواست‌ها و خطاهای HTTP.
• زمان‌های پاسخ‌دهی سرویس‌ها.

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

7. ایجاد هشدار در Grafana:

برای نظارت پیشرفته‌تر، می‌توانید هشدارهایی را در Grafana برای اطلاع از بروز مشکلات تنظیم کنید. به‌عنوان مثال، اگر مصرف CPU یا حافظه از حد معینی بیشتر شد، Grafana می‌تواند به شما هشدار دهد.

برای ایجاد هشدار:

• وارد داشبورد Grafana شوید.
• در گراف‌های مورد نظر، روی Panel Title کلیک کرده و Edit را انتخاب کنید.
• به تب Alert بروید و قوانین هشدار را تنظیم کنید.

جمع‌بندی:

استفاده از Prometheus و Grafana به‌عنوان ابزارهای مکمل در Kubernetes برای نظارت دقیق بر منابع، یکی از بهترین روش‌ها برای حفظ سلامت و عملکرد کلاستر است. Prometheus به‌طور خودکار متریک‌های مربوط به منابع مختلف Kubernetes را جمع‌آوری می‌کند و Grafana این داده‌ها را به‌صورت گرافیکی نمایش می‌دهد و ابزارهای تحلیلی و هشداردهی پیشرفته‌ای فراهم می‌آورد. با استفاده از این دو ابزار، شما می‌توانید مصرف منابع، وضعیت سرویس‌ها و سلامت کلی کلاستر خود را به‌طور مؤثر نظارت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ELK Stack برای مدیریت و تحلیل لاگ‌ها” subtitle=”توضیحات کامل”]در محیط‌های Kubernetes و سیستم‌های توزیع‌شده، یکی از مهم‌ترین جنبه‌ها در نظارت بر سیستم، مدیریت و تحلیل لاگ‌ها است. برای مدیریت این لاگ‌ها و تجزیه و تحلیل آن‌ها به‌طور مؤثر، از ELK Stack (ElasticSearch، Logstash و Kibana) استفاده می‌شود. این ابزارها به شما کمک می‌کنند تا لاگ‌ها را جمع‌آوری، ذخیره، جستجو، و به‌صورت گرافیکی تحلیل کنید. در این بخش، به نحوه استفاده از ELK Stack برای مدیریت و تحلیل لاگ‌ها در Kubernetes خواهیم پرداخت.

1. آشنایی با ELK Stack:

ELK Stack شامل سه ابزار اصلی است که هرکدام نقش خاصی در مدیریت و تحلیل لاگ‌ها دارند:

• ElasticSearch: موتور جستجوی توزیع‌شده برای ذخیره‌سازی و جستجو در داده‌ها (لاگ‌ها).
• Logstash: ابزار پردازش لاگ‌ها که مسئول جمع‌آوری، تجزیه و انتقال لاگ‌ها از منابع مختلف به ElasticSearch است.
• Kibana: رابط گرافیکی برای تجزیه و تحلیل و نمایش داده‌ها در ElasticSearch است.

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

2. نصب ELK Stack در Kubernetes:

برای نصب و راه‌اندازی ELK Stack در Kubernetes، معمولاً از Helm به‌عنوان یک ابزار مدیریت پکیج برای نصب و پیکربندی استفاده می‌شود. در اینجا، مراحل نصب ELK Stack در Kubernetes با استفاده از Helm آورده شده است.

2.1. نصب Elasticsearch:

1. ابتدا مخزن Helm مربوط به ElasticSearch را اضافه کنید:

   helm repo add elastic https://helm.elastic.co
   helm repo update
   

2. سپس، Elasticsearch را نصب کنید:

   helm install elasticsearch elastic/elasticsearch
   

   این دستور پیکربندی پیش‌فرض را برای نصب Elasticsearch در Kubernetes استفاده می‌کند.

2.2. نصب Logstash:

برای نصب Logstash، از دستور زیر استفاده کنید:

helm install logstash elastic/logstash

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

2.3. نصب Kibana:

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

helm install kibana elastic/kibana

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

3. پیکربندی و جمع‌آوری لاگ‌ها با Logstash:

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

مثال ساده از پیکربندی Logstash برای جمع‌آوری لاگ‌ها از فایل‌های کانتینر در Kubernetes:

input {
  file {
    path => "/var/log/containers/*.log"
    start_position => "beginning"
  }
}

filter {
  # پردازش لاگ‌ها (می‌توانید الگوهای خاصی برای استخراج اطلاعات داشته باشید)
  grok {
    match => { "message" => "%{COMBINEDAPACHELOG}" }
  }
}

output {
  elasticsearch {
    hosts => ["http://elasticsearch:9200"]
    index => "kubernetes-logs-%{+YYYY.MM.dd}"
  }
}

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

• input: از فایل‌های لاگ کانتینرها در Kubernetes لاگ‌ها را جمع‌آوری می‌کند.
• filter: پردازش لاگ‌ها برای استخراج اطلاعات ساختاریافته.
• output: ارسال لاگ‌ها به Elasticsearch برای ذخیره‌سازی و جستجو.

4. تحلیل لاگ‌ها با Kibana:

پس از نصب و پیکربندی ELK Stack، شما می‌توانید از Kibana برای تجزیه و تحلیل و نمایش لاگ‌ها استفاده کنید. Kibana به شما این امکان را می‌دهد که لاگ‌ها را بر اساس معیارهای مختلف جستجو کرده و آن‌ها را در داشبوردهای گرافیکی نمایش دهید.

برای استفاده از Kibana:

1. به رابط گرافیکی Kibana وارد شوید (در صورتی که از Kubernetes استفاده می‌کنید، باید از port-forwarding برای دسترسی به Kibana استفاده کنید):

   kubectl port-forward svc/kibana 5601:5601
   

2. به مرورگر خود بروید و به آدرس http://localhost:5601 وارد شوید.
3. در Kibana، شما می‌توانید الگوهای داده‌ای (index patterns) را برای Elasticsearch تعریف کنید تا بتوانید به راحتی به داده‌های جمع‌آوری‌شده دسترسی پیدا کنید و تجزیه و تحلیل انجام دهید.
4. پس از تعریف index pattern، می‌توانید از امکانات مختلف Kibana مانند Discover، Visualize و Dashboard برای تجزیه و تحلیل و نمایش لاگ‌ها استفاده کنید.

5. مزایای استفاده از ELK Stack برای مدیریت لاگ‌ها:

• مقیاس‌پذیری بالا: ELK Stack قادر است لاگ‌ها را در مقیاس بزرگ ذخیره و پردازش کند.
• جستجو و تحلیل سریع: Elasticsearch به شما این امکان را می‌دهد که به‌سرعت در میان حجم بالای لاگ‌ها جستجو کنید.
• نمایش گرافیکی و داشبوردها: Kibana ابزارهایی برای تجزیه و تحلیل و نمایش گرافیکی لاگ‌ها ارائه می‌دهد.
• پردازش و پردازش پیچیده: Logstash به شما این امکان را می‌دهد که لاگ‌ها را پردازش کرده و داده‌های خاصی را از آن‌ها استخراج کنید.

جمع‌بندی:

استفاده از ELK Stack (Elasticsearch، Logstash و Kibana) برای جمع‌آوری، پردازش، ذخیره‌سازی و تجزیه و تحلیل لاگ‌ها یکی از بهترین روش‌ها برای نظارت و مدیریت لاگ‌ها در محیط‌های Kubernetes است. این ابزارها به شما این امکان را می‌دهند که به‌طور مؤثر لاگ‌ها را مدیریت کرده و به سرعت مشکلات سیستم را شناسایی کنید. با پیکربندی مناسب و استفاده از امکانات Kibana، می‌توانید به‌راحتی اطلاعات مفیدی از لاگ‌ها استخراج کرده و آن‌ها را برای تحلیل‌های بیشتر استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ابزارهای دیگر مانند Fluentd، Datadog، یا New Relic” subtitle=”توضیحات کامل”]در کنار ELK Stack، ابزارهای دیگری مانند Fluentd، Datadog و New Relic برای جمع‌آوری، مدیریت، و تحلیل لاگ‌ها و مانیتورینگ در Kubernetes وجود دارند. این ابزارها هرکدام ویژگی‌ها و قابلیت‌های خاص خود را دارند که به شما در نظارت دقیق‌تر و بهتر کمک می‌کنند. در این بخش، به معرفی این ابزارها و نحوه استفاده از آن‌ها خواهیم پرداخت.

1. Fluentd:

Fluentd یکی از ابزارهای محبوب و قدرتمند برای جمع‌آوری، پردازش، و ارسال لاگ‌ها به منابع مختلف است. Fluentd به‌عنوان یک جمع‌کننده لاگ (log collector) و پردازشگر (log processor) استفاده می‌شود که می‌تواند لاگ‌ها را از منابع مختلف (مانند کانتینرها، سیستم‌های فایل، API‌ها) جمع‌آوری کرده و آن‌ها را به مقصدهای مختلف (مانند Elasticsearch، InfluxDB، یا Cloud Storage) ارسال کند.

1.1. نصب Fluentd در Kubernetes:

برای نصب Fluentd در Kubernetes، معمولاً از Helm استفاده می‌شود که نصب را سریع‌تر و راحت‌تر می‌کند. ابتدا باید مخزن Fluentd را به Helm اضافه کرده و سپس آن را نصب کنید.

1. افزودن مخزن Fluentd به Helm:

   helm repo add fluent https://fluent.github.io/helm-charts
   helm repo update
   

2. نصب Fluentd با استفاده از Helm:

   helm install fluentd fluent/fluentd
   

   بعد از نصب Fluentd، پیکربندی Fluentd برای جمع‌آوری لاگ‌ها و ارسال آن‌ها به مقصد مورد نظر (مانند Elasticsearch یا Datadog) می‌تواند از طریق ویرایش فایل پیکربندی fluent.conf انجام شود.

1.2. پیکربندی Fluentd برای ارسال لاگ‌ها به Elasticsearch:

برای پیکربندی Fluentd جهت ارسال لاگ‌ها به Elasticsearch، یک پیکربندی ساده به شکل زیر می‌تواند باشد:

<match kubernetes.**>
  @type elasticsearch
  host "elasticsearch-service"
  port 9200
  logstash_format true
  logstash_prefix "k8s-logs"
</match>

این پیکربندی باعث می‌شود که لاگ‌ها به‌صورت خودکار به Elasticsearch ارسال شوند و در قالب Logstash ذخیره شوند.

1.3. مزایای Fluentd:

• مقیاس‌پذیری: Fluentd می‌تواند در مقیاس بزرگ داده‌ها را پردازش و ارسال کند.
• انعطاف‌پذیری: Fluentd قابلیت ادغام با منابع مختلف برای جمع‌آوری و پردازش لاگ‌ها را دارد.
• پشتیبانی از فرمت‌های مختلف: Fluentd از فرمت‌های مختلف لاگ مانند JSON، syslog، و others پشتیبانی می‌کند.

---

2. Datadog:

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

2.1. نصب Datadog Agent در Kubernetes:

برای نصب Datadog Agent در Kubernetes، می‌توانید از دستور زیر استفاده کنید:

kubectl create secret generic datadog-api-key --from-literal api-key=<YOUR_DATADOG_API_KEY>
helm install datadog datadog/datadog \
  --set apiKeyExistingSecret=datadog-api-key \
  --set targetSystem=kubernetes

این دستور Datadog Agent را در تمام نودهای کلاستر نصب می‌کند و به آن اجازه می‌دهد تا داده‌ها را از Pod‌ها، کانتینرها و نودها جمع‌آوری کند.

2.2. ویژگی‌های Datadog:

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

---

3. New Relic:

New Relic یک پلتفرم تجزیه و تحلیل عملکرد نرم‌افزار است که به شما کمک می‌کند تا منابع Kubernetes و لاگ‌های برنامه‌ها را نظارت کرده و مشکلات عملکردی را شناسایی کنید. New Relic به‌ویژه برای مانیتورینگ عملکرد نرم‌افزار (APM) کاربرد دارد و می‌تواند اطلاعات عمیق‌تری از عملکرد اپلیکیشن‌ها در Kubernetes فراهم کند.

3.1. نصب New Relic Agent در Kubernetes:

برای نصب New Relic Agent در Kubernetes، ابتدا باید یک License Key از New Relic دریافت کنید و سپس آن را از طریق Helm نصب کنید:

kubectl create secret generic newrelic-license-key --from-literal=licenseKey=<YOUR_NEW_RELIC_LICENSE_KEY>
helm install newrelic newrelic/newrelic-infrastructure \
  --set licenseKey=<YOUR_NEW_RELIC_LICENSE_KEY> \
  --set clusterName=k8s-cluster

3.2. ویژگی‌های New Relic:

• نظارت کامل بر عملکرد: New Relic می‌تواند تمامی جوانب اپلیکیشن‌ها و سرویس‌ها را تجزیه و تحلیل کند.
• جمع‌آوری اطلاعات از سرویس‌های مختلف: این ابزار قادر است از منابع مختلف مانند Kubernetes، Nginx، Apache، و غیره اطلاعات جمع‌آوری کند.
• نمایش نمودارهای گرافیکی و داشبوردهای کاربردی: New Relic این امکان را فراهم می‌کند که داده‌ها را در قالب گراف‌ها و نمودارهای تعاملی مشاهده کنید.

---

جمع‌بندی:

هرکدام از این ابزارها (Fluentd، Datadog، و New Relic) ویژگی‌ها و قابلیت‌های خاص خود را دارند که آن‌ها را برای استفاده در محیط‌های Kubernetes به گزینه‌های قدرتمندی تبدیل کرده است. Fluentd برای جمع‌آوری و پردازش لاگ‌ها به‌طور قابل تنظیم، Datadog برای نظارت یکپارچه بر منابع و لاگ‌ها، و New Relic برای تجزیه و تحلیل دقیق عملکرد نرم‌افزار مناسب هستند.

انتخاب ابزار مناسب بستگی به نیازهای خاص شما دارد. در صورتی که به دنبال ابزار نظارتی کامل با توانایی تجزیه و تحلیل عمیق هستید، Datadog یا New Relic گزینه‌های مناسبی خواهند بود. اگر بیشتر تمرکز شما بر روی پردازش و جمع‌آوری لاگ‌ها است، Fluentd یک انتخاب عالی خواهد بود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 7. بررسی وضعیت سلامت (Health)”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی کانفیگ Probe‌ها برای تشخیص مشکلات” subtitle=”توضیحات کامل”]در کوبرنتیز، Liveness Probe و Readiness Probe ابزارهایی هستند که به ما کمک می‌کنند تا وضعیت سلامتی و آمادگی یک Pod را بررسی کنیم. این دو نوع Probe به‌ویژه در محیط‌های مقیاس‌پذیر و پویا برای اطمینان از عملکرد صحیح و دسترس‌پذیری سرویس‌ها ضروری هستند. در این بخش، به بررسی این دو نوع Probe، نحوه پیکربندی آن‌ها و چگونگی تشخیص مشکلات از طریق این ابزارها خواهیم پرداخت.

---

1. Liveness Probe:

Liveness Probe به Kubernetes کمک می‌کند تا تشخیص دهد که آیا یک کانتینر در داخل Pod همچنان به درستی کار می‌کند یا خیر. اگر Liveness Probe نشان دهد که کانتینر در وضعیت سالم نیست، Kubernetes آن را به‌طور خودکار Restart می‌کند.

1.1. چرا Liveness Probe مهم است؟

• بازنشانی خودکار کانتینرها: وقتی که یک کانتینر به دلیل مشکلاتی مانند deadlock یا منابع غیرقابل دسترس متوقف می‌شود، Liveness Probe آن را شناسایی کرده و آن را ری‌استارت می‌کند تا از خرابی سرویس جلوگیری شود.
• نظارت بر وضعیت سلامت: این Probe به ما کمک می‌کند تا اطمینان حاصل کنیم که کانتینر بعد از مدت زمان مشخصی همچنان به درستی کار می‌کند.

1.2. پیکربندی Liveness Probe:

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

• HTTP Request: یک درخواست HTTP به مسیر مشخصی ارسال می‌شود و بررسی می‌شود که پاسخ 2xx (موفق) دریافت شود.
• TCP Socket: یک ارتباط TCP به یک پورت مشخص بررسی می‌شود.
• Exec Command: یک دستور در داخل کانتینر اجرا می‌شود و بررسی می‌شود که دستور موفقیت‌آمیز اجرا شود.

نمونه پیکربندی برای Liveness Probe به‌صورت زیر است:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: myimage
      livenessProbe:
        httpGet:
          path: /healthz
          port: 8080
        initialDelaySeconds: 3
        periodSeconds: 5
        failureThreshold: 3

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

• httpGet: درخواست HTTP به مسیر /healthz و پورت 8080 ارسال می‌شود.
• initialDelaySeconds: مدت زمان تا شروع بررسی سلامت پس از راه‌اندازی کانتینر.
• periodSeconds: فواصل زمانی برای انجام چک‌های سلامت.
• failureThreshold: تعداد تلاش‌های ناموفق قبل از این که Kubernetes تصمیم به Restart کانتینر بگیرد.

1.3. تشخیص مشکلات با Liveness Probe:

Liveness Probe می‌تواند مشکلات مختلفی را شناسایی کند:

• Deadlock‌ها: اگر یک کانتینر به دلیل deadlock متوقف شده باشد و نتواند به درستی پاسخ دهد، Liveness Probe آن را شناسایی کرده و کانتینر را ری‌استارت می‌کند.
• مصرف بیش از حد منابع: در صورتی که یک کانتینر به دلایلی مانند مصرف بیش از حد CPU یا حافظه از کار بیفتد، Liveness Probe می‌تواند آن را تشخیص دهد.

---

2. Readiness Probe:

Readiness Probe بررسی می‌کند که آیا یک کانتینر آماده است تا درخواست‌ها را دریافت کند یا خیر. زمانی که یک کانتینر در حال راه‌اندازی است یا در حال انجام برخی عملیات‌های ضروری است، ممکن است درخواست‌ها را پاسخ ندهد. اینجا است که Readiness Probe وارد عمل می‌شود و کمک می‌کند تا Kubernetes درخواست‌ها را به این کانتینر ارسال نکند تا زمانی که آماده باشد.

2.1. چرا Readiness Probe مهم است؟

• مدیریت بار: Readiness Probe به Kubernetes کمک می‌کند تا از ارسال درخواست‌ها به کانتینرهایی که هنوز آماده پاسخ‌دهی نیستند، جلوگیری کند. این ویژگی به توزیع مناسب بار در میان نودها و سرویس‌ها کمک می‌کند.
• بهبود دسترس‌پذیری: به محض آماده شدن کانتینر، Kubernetes به‌طور خودکار آن را به سرویس‌دهی فعال اضافه می‌کند.

2.2. پیکربندی Readiness Probe:

Readiness Probe دقیقاً مانند Liveness Probe می‌تواند از سه روش مختلف استفاده کند. در اینجا نمونه‌ای از پیکربندی Readiness Probe آورده شده است:

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: mycontainer
      image: myimage
      readinessProbe:
        httpGet:
          path: /readiness
          port: 8080
        initialDelaySeconds: 5
        periodSeconds: 10
        failureThreshold: 3

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

• httpGet: درخواست HTTP به مسیر /readiness و پورت 8080 ارسال می‌شود.
• initialDelaySeconds: مدت زمان تا شروع بررسی آمادگی پس از راه‌اندازی کانتینر.
• periodSeconds: فواصل زمانی برای انجام چک‌های آمادگی.
• failureThreshold: تعداد تلاش‌های ناموفق قبل از اینکه Kubernetes تصمیم بگیرد که کانتینر آماده نیست و از دسترس خارج شود.

2.3. تشخیص مشکلات با Readiness Probe:

Readiness Probe می‌تواند مشکلات مختلفی را شناسایی کند:

• آمادگی نداشتن برای پاسخ‌دهی: اگر سرویس‌ها یا پیکربندی‌ها هنوز در حال راه‌اندازی یا بارگذاری باشند، Readiness Probe از ارسال درخواست‌ها جلوگیری می‌کند.
• مشکلات در اتصال به دیتابیس یا سایر سرویس‌ها: در صورتی که کانتینر نتواند به منابع مورد نیاز (مانند دیتابیس) متصل شود، Readiness Probe آن را شناسایی کرده و از ارسال درخواست‌ها به آن جلوگیری می‌کند.

---

3. تشخیص مشکلات با ترکیب Liveness و Readiness Probes:

ترکیب Liveness و Readiness Probe می‌تواند به تشخیص مشکلات پیچیده‌تر کمک کند. برای مثال، یک کانتینر ممکن است به‌طور موقت از کار بیفتد (و Liveness Probe آن را ری‌استارت کند)، اما همچنان آماده نباشد (Readiness Probe بررسی می‌کند که هنوز آماده دریافت درخواست‌ها نیست).

• Liveness Probe در مواقعی که کانتینر نیاز به ری‌استارت دارد (به‌طور مثال در صورت deadlock یا خرابی) وارد عمل می‌شود.
• Readiness Probe مانع از دریافت درخواست‌های غیرضروری و بار اضافی بر کانتینری می‌شود که هنوز در حال راه‌اندازی یا آماده‌سازی است.

---

جمع‌بندی:

Liveness و Readiness Probes ابزارهای ضروری برای نظارت بر وضعیت کانتینرها در Kubernetes هستند. Liveness Probe به Kubernetes کمک می‌کند تا کانتینرهای خراب را شناسایی و ری‌استارت کند، در حالی که Readiness Probe اطمینان می‌دهد که تنها کانتینرهای آماده به دریافت درخواست‌ها، این درخواست‌ها را دریافت می‌کنند. استفاده صحیح از این Probes به شما کمک می‌کند تا سرویس‌های Kubernetes خود را پایدار و قابل اعتماد نگه دارید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بهینه‌سازی زمان‌بندی و حساسیت پروب‌ها” subtitle=”توضیحات کامل”]در کوبرنتیز، Liveness Probes و Readiness Probes نقش مهمی در اطمینان از وضعیت صحیح کانتینرها ایفا می‌کنند. اما تنظیمات این پروب‌ها، به‌ویژه در مقیاس‌های بزرگ و پیچیده، می‌تواند تأثیر زیادی بر عملکرد و زمان‌بندی سیستم داشته باشد. در این بخش به نحوه بهینه‌سازی زمان‌بندی و حساسیت این پروب‌ها پرداخته خواهد شد تا از عملکرد بهینه و کاهش مشکلات غیرضروری اطمینان حاصل کنیم.

---

1. مفهوم زمان‌بندی و حساسیت در Probes:

• زمان‌بندی (Timing): این مربوط به فواصل زمانی است که بین هر بار بررسی وضعیت کانتینر یا Pod انجام می‌شود. زمان‌بندی به‌طور مستقیم بر نحوه تعامل Kubernetes با منابع و چگونگی پاسخ به خرابی‌ها تأثیر دارد.
• حساسیت (Sensitivity): حساسیت پروب‌ها نشان‌دهنده میزان تحمل یا تحمل‌پذیری سیستم نسبت به خطاها است. حساسیت کم ممکن است باعث شود که Kubernetes پیش از آنکه مشکل جدی ایجاد شود، تصمیم به ری‌استارت کانتینر بگیرد، در حالی که حساسیت زیاد ممکن است به این منجر شود که سیستم نسبت به مشکلات جزئی مقاوم باشد.

2. تنظیم زمان‌بندی Liveness و Readiness Probes:

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

2.1. initialDelaySeconds:

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

• اگر کانتینر شما نیاز به راه‌اندازی و پیکربندی اولیه طولانی دارد (برای مثال اتصال به دیتابیس یا منابع خارجی)، باید initialDelaySeconds را بیشتر تنظیم کنید تا از شکست اولیه پروب‌ها جلوگیری شود.

نمونه:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 15  # تنظیم زمان تا اولین بررسی وضعیت
  periodSeconds: 5

2.2. periodSeconds:

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

• برای پروب‌های حساس‌تر که زمان پاسخ‌دهی کمی دارند، می‌توان مقدار کمتری انتخاب کرد، در حالی که برای سرویس‌هایی که دارای پردازش‌های طولانی هستند، باید periodSeconds بالاتر تنظیم شود.

نمونه:

readinessProbe:
  httpGet:
    path: /readiness
    port: 8080
  periodSeconds: 10  # مدت زمان بین هر بررسی

2.3. failureThreshold و successThreshold:

این دو پارامتر به تنظیمات حساسیت پروب‌ها کمک می‌کنند:

• failureThreshold: تعداد تلاش‌های ناموفق قبل از آنکه Kubernetes تصمیم به ری‌استارت کانتینر بگیرد.
• successThreshold: تعداد تلاش‌های موفق مورد نیاز برای تشخیص آمادگی کانتینر.
• تنظیم failureThreshold بالاتر ممکن است به سیستم اجازه دهد که مشکلات کوتاه‌مدت را نادیده بگیرد، اما در عوض ممکن است مشکلات دائمی را دیرتر شناسایی کند.
• تنظیم successThreshold می‌تواند از شناسایی زودهنگام وضعیت آماده جلوگیری کند، که ممکن است باعث شود درخواست‌ها به کانتینری که هنوز کاملاً آماده نیست، ارسال شود.

نمونه:

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  failureThreshold: 3  # تعداد تلاش‌های ناموفق
  successThreshold: 1  # تعداد تلاش‌های موفق

2.4. timeoutSeconds:

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

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

نمونه:

readinessProbe:
  httpGet:
    path: /readiness
    port: 8080
  timeoutSeconds: 3  # مدت زمان انتظار برای پاسخ

---

3. بهینه‌سازی حساسیت Probes برای سرویس‌های متفاوت:

برای بهینه‌سازی حساسیت، لازم است که متناسب با نوع سرویس‌ها و کاربرد آن‌ها، پروب‌ها تنظیم شوند:

• سرویس‌های حساس: اگر سرویس شما به‌طور مداوم باید در دسترس باشد (مثل API‌های real-time یا سرویس‌های پردازش تراکنش)، باید حساسیت پروب‌ها را بیشتر کنید و فواصل زمانی کوتاه‌تری برای periodSeconds و timeoutSeconds انتخاب کنید.
• سرویس‌های با تأخیر بالا: سرویس‌هایی که بارگذاری اولیه بالایی دارند یا زمان پاسخ‌دهی طولانی‌تری دارند (مثل پردازش‌های دسته‌ای یا درخواست‌های به منابع خارجی) نیاز به زمان تأخیر بیشتر در initialDelaySeconds و فواصل بیشتر در periodSeconds دارند.

---

4. موارد مهم برای بهینه‌سازی:

• بار زیاد روی Kubernetes: اگر تعداد زیادی Pod با پروب‌های حساس و زمان‌بندی کوتاه داشته باشید، Kubernetes باید درخواست‌های زیادی را مدیریت کند. در این حالت، توجه به تنظیمات initialDelaySeconds و periodSeconds به کاهش فشار بر روی کنترلرها و API server کمک می‌کند.
• همگام‌سازی با سایر متغیرها: پروب‌ها باید به‌طور هماهنگ با سایر پیکربندی‌های Pod مثل منابع (CPU و حافظه) تنظیم شوند. پروب‌هایی که در محیط‌های با منابع محدود تنظیم می‌شوند، باید با دقت بیشتری پیکربندی شوند تا از خرابی‌های غیرضروری جلوگیری شود.

---

جمع‌بندی:

بهینه‌سازی زمان‌بندی و حساسیت Liveness و Readiness Probes بخش مهمی از پیکربندی Kubernetes است که به افزایش پایداری، عملکرد و کارایی سیستم کمک می‌کند. با تنظیم مقادیر مناسب برای پارامترهای مختلف مانند initialDelaySeconds, periodSeconds, failureThreshold, timeoutSeconds, می‌توان به‌طور موثری زمان‌بندی و حساسیت پروب‌ها را کنترل کرد. این تنظیمات به شما کمک می‌کند تا مطمئن شوید که کانتینرها به‌طور بهینه نظارت می‌شوند و مشکلات به‌طور سریع شناسایی و رفع می‌شوند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مدیریت Restart Policy: تنظیم و تحلیل Restart Policy‌ها برای Pods” subtitle=”توضیحات کامل”]در کوبرنتیز، Restart Policy به شما اجازه می‌دهد که نحوه واکنش سیستم به خرابی‌ها و وقفه‌ها را کنترل کنید. این سیاست مشخص می‌کند که چگونه سیستم باید با Podهایی که به‌دلیل مشکلاتی مثل کرش کردن یا قطع ارتباط از کار افتاده‌اند، برخورد کند. Restart Policy برای هر Pod تعریف می‌شود و تأثیر زیادی بر پایداری و عملکرد سیستم دارد.

---

1. انواع Restart Policy‌ها:

در Kubernetes سه نوع Restart Policy وجود دارد که می‌توانید برای Pods تنظیم کنید:

1.1. Always (پیش‌فرض):

این سیاست به‌طور پیش‌فرض برای Pods تنظیم می‌شود و باعث می‌شود که Kubernetes هر بار که یک کانتینر در Pod به هر دلیلی متوقف می‌شود (خواه دلیل آن خرابی باشد یا قطع برق)، آن را مجدداً راه‌اندازی کند. این سیاست برای سرویس‌هایی که همیشه باید در دسترس باشند بسیار مناسب است.

• استفاده معمول: سرویس‌های دائمی که باید به‌طور پیوسته در حال اجرا باشند.

نمونه:

apiVersion: v1
kind: Pod
metadata:
  name: always-restart-pod
spec:
  restartPolicy: Always
  containers:
  - name: my-container
    image: my-image

1.2. OnFailure:

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

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

نمونه:

apiVersion: v1
kind: Pod
metadata:
  name: onfailure-restart-pod
spec:
  restartPolicy: OnFailure
  containers:
  - name: my-container
    image: my-image

1.3. Never:

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

• استفاده معمول: برای کارهای یک‌بار مصرف که به‌طور مداوم نیاز به راه‌اندازی ندارند، مانند jobهای کوتاه‌مدت یا پردازش‌های دوره‌ای.

نمونه:

apiVersion: v1
kind: Pod
metadata:
  name: never-restart-pod
spec:
  restartPolicy: Never
  containers:
  - name: my-container
    image: my-image

---

2. تأثیر Restart Policy بر روی نوع Pod:

توجه به این نکته مهم است که Restart Policy بسته به نوع Pod ممکن است متفاوت باشد. برای نمونه:

• Pods که به‌صورت مستقل از سایر Pods اجرا می‌شوند، ممکن است به Always تنظیم شوند تا همیشه در دسترس باشند.
• Pods که به‌عنوان Job یا CronJob استفاده می‌شوند، بیشتر به Never یا OnFailure تنظیم می‌شوند تا پس از اتمام عملیات خاص خود، دیگر مجدداً راه‌اندازی نشوند.

3. مدیریت Restart Policy در حالت‌های خاص:

3.1. زمانی که Pod بخشی از یک Deployment است:

در مواردی که Pod بخشی از یک Deployment است، تنظیمات restartPolicy به‌طور خودکار به Always تنظیم می‌شود. در این وضعیت، Kubernetes خود به‌طور مداوم تلاش می‌کند تا تعداد Pods در حال اجرا را با توجه به تعریف در Deployment نگه دارد. بنابراین، اگر Podهای شما بخشی از یک Deployment باشند، نگرانی زیادی در مورد تغییر سیاست راه‌اندازی مجدد (Restart Policy) ندارید.

3.2. زمانی که Pod بخشی از یک StatefulSet است:

در StatefulSet، Pods به‌طور خاص برای هرکدام از نمونه‌ها شناخته می‌شوند، و زمان‌بندی راه‌اندازی مجدد می‌تواند تأثیرات متفاوتی در حافظه و ذخیره‌سازی داشته باشد. معمولاً، اگر Pod در یک StatefulSet از کار بیفتد، با سیاست Always راه‌اندازی مجدد می‌شود تا وضعیت ذخیره‌شده آن حفظ شود.

3.3. زمانی که Pod بخشی از یک DaemonSet است:

در DaemonSet، که برای اجرای Pods در هر نود (Node) استفاده می‌شود، معمولاً سیاست Always تنظیم می‌شود تا اطمینان حاصل شود که هر زمان نود جدیدی به Cluster افزوده شد، Pod مربوط به آن نیز راه‌اندازی می‌شود.

---

4. استفاده از Restart Policy در شرایط واقعی:

برای مثال، در یک کلاستر که دارای سرویس‌های مهم و دائمی مانند API Gateways یا Web Servers است، می‌توانیم از Always برای تضمین بالا بودن دسترسی استفاده کنیم. از طرفی، در پردازش‌هایی که پس از اتمام نیاز به تکمیل دارند و پس از آن دیگر نیازی به تکرار نیستند (مثل batch jobs یا پردازش‌های دوره‌ای)، می‌توان از Never یا OnFailure برای جلوگیری از راه‌اندازی مجدد غیرضروری استفاده کرد.

---

5. بررسی خرابی‌های ناشی از Restart Policy:

اگر به‌طور مداوم با خرابی‌های Pod مواجه هستید و فکر می‌کنید که Restart Policy به‌درستی تنظیم نشده است، می‌توانید از ابزارهایی مانند kubectl describe یا kubectl logs برای بررسی دلایل دقیق خرابی استفاده کنید.

• استفاده از kubectl describe برای تحلیل وضعیت Pod:

kubectl describe pod <pod-name>

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

---

جمع‌بندی:

Restart Policy در Kubernetes نقش مهمی در مدیریت و پایش وضعیت Pods ایفا می‌کند. بسته به نیاز شما، باید سیاست مناسب را انتخاب کنید تا از پایداری سیستم و منابع اطمینان حاصل کنید. برای سرویس‌هایی که نیاز به دسترسی دائم دارند، از Always استفاده کنید، برای مواردی که خرابی‌های موقتی را انتظار دارید از OnFailure بهره ببرید و در نهایت، برای پردازش‌های کوتاه‌مدت که پس از اتمام باید متوقف شوند، از Never استفاده کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 8. مدیریت فضای دیسک و ذخیره‌سازی”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”شناسایی مشکلات Mount یا دسترسی به Persistent Volume‌ها” subtitle=”توضیحات کامل”]در کوبرنتیز، Volumes برای ذخیره‌سازی داده‌ها و اشتراک آن‌ها بین کانتینرها در Podها استفاده می‌شوند. مشکلات مربوط به Mount کردن یا دسترسی به Persistent Volume‌ها (PV) می‌تواند منجر به از کار افتادن سرویس‌ها یا داده‌های از دست رفته شود. برای شناسایی و رفع این مشکلات، ضروری است که با فرآیند و ابزارهای مختلف Kubernetes آشنا باشیم.

---

1. مشکلات متداول با Volumes:

1.1. مشکلات Mount کردن (Mount Issues):

یکی از شایع‌ترین مشکلات در Kubernetes زمانی است که Volume مورد نظر به‌درستی به کانتینرها Mount نمی‌شود. این موضوع می‌تواند به دلایل مختلفی اتفاق بیفتد، از جمله مشکلات در پیکربندی یا وضعیت Volume.

• دلایل رایج:
  • مشکلات مربوط به تنظیمات StorageClass یا Persistent Volume.
  • مشکلات در ارتباط با پروتکل‌های شبکه‌ای در صورتی که از NFS یا iSCSI استفاده می‌کنید.
  • عدم وجود فضای کافی در نود یا دسترسی نداشتن به فایل‌سیستم.
  • عدم تطابق نوع Volume با پیکربندی Pod.

1.2. مشکلات دسترسی به Persistent Volumes (PV):

دسترسی به PV به دلیل مشکلات تنظیمات یا سطح دسترسی می‌تواند با چالش‌های مختلفی روبه‌رو شود.

• دلایل رایج:
  • Pod نمی‌تواند به PV متصل شود.
  • PV یا Persistent Volume Claim (PVC) به‌درستی ایجاد نشده باشد.
  • مشکلات مربوط به سیاست‌های RBAC که اجازه دسترسی به منابع PV را نمی‌دهند.
  • محدودیت‌های منابع یا فضای ذخیره‌سازی در کلاستر.

---

2. شناسایی مشکلات Mount و دسترسی به PV:

برای شناسایی مشکلات مربوط به Mount و دسترسی به Persistent Volumes، ابزارهای مختلفی در اختیار داریم. به کمک این ابزارها می‌توانیم به‌سرعت مشکلات را شناسایی و رفع کنیم.

2.1. استفاده از kubectl describe برای بررسی وضعیت Volume:

با استفاده از دستور kubectl describe می‌توانیم وضعیت دقیق PVC یا PV را بررسی کنیم و دلایل احتمالی مشکلات Mount یا دسترسی را شناسایی کنیم.

• بررسی PVC:

kubectl describe pvc <pvc-name>

این دستور وضعیت مربوط به Persistent Volume Claim را نمایش می‌دهد، از جمله اینکه آیا PVC به‌درستی به یک Persistent Volume متصل شده است یا خیر.

• بررسی PV:

kubectl describe pv <pv-name>

با این دستور می‌توانید اطلاعات مربوط به Persistent Volume را بررسی کنید. از جمله وضعیت آن، حجم ذخیره‌سازی تخصیص داده‌شده، و اگر مشکلاتی در اتصال وجود داشته باشد، در این خروجی نمایش داده می‌شود.

2.2. بررسی Logs و Events:

اگر مشکلی در دسترسی به Volume به‌وجود آمده باشد، می‌توانید از دستورات kubectl logs و kubectl get events برای بررسی لاگ‌ها و رویدادها استفاده کنید.

• مشاهده لاگ‌های مربوط به Pod:

kubectl logs <pod-name> -c <container-name>

این دستور لاگ‌های مربوط به کانتینر خاص در Pod را نمایش می‌دهد و ممکن است مشکلات مربوط به Mount یا دسترسی به Volume را نمایان کند.

• بررسی رویدادها (Events):

kubectl get events --sort-by='.metadata.creationTimestamp'

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

---

3. بررسی تنظیمات PVC و PV:

در صورتی که مشکلی در دسترسی به Volume وجود داشته باشد، باید مطمئن شوید که تنظیمات Persistent Volume Claim (PVC) و Persistent Volume (PV) به‌درستی پیکربندی شده‌اند.

3.1. تطابق PVC و PV:

وقتی یک PVC ایجاد می‌شود، باید مشخصات آن با PV موجود تطابق داشته باشد، از جمله اندازه حجم، نوع ذخیره‌سازی، و سیاست دسترسی. اگر این مشخصات با هم تطابق نداشته باشند، Pod قادر به Mount کردن Volume نخواهد بود.

• بررسی تطابق حجم PVC و PV در فایل YAML:

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

3.2. بررسی سیاست‌های دسترسی:

Access Modes در PVC و PV نقش مهمی در توانایی Kubernetes برای دسترسی به Volume دارند. بررسی کنید که Access Modes در PVC و PV هم‌خوانی داشته باشند:

• ReadWriteOnce: اجازه می‌دهد که تنها یک Pod به طور هم‌زمان به Volume دسترسی پیدا کند.
• ReadOnlyMany: اجازه می‌دهد که چندین Pod فقط به صورت خواندنی به Volume دسترسی داشته باشند.
• ReadWriteMany: اجازه می‌دهد که چندین Pod همزمان به Volume دسترسی داشته باشند.

---

4. بررسی مشکلات شبکه در ذخیره‌سازی شبکه‌ای:

اگر از NFS، iSCSI یا دیگر سیستم‌های ذخیره‌سازی شبکه‌ای استفاده می‌کنید، مشکلات شبکه می‌تواند موجب عدم دسترسی به Volume شود. بررسی وضعیت شبکه و ارتباطات می‌تواند به رفع این مشکل کمک کند.

• بررسی وضعیت NFS:

kubectl describe pod <pod-name> | grep NFS

این دستور کمک می‌کند تا اگر مشکلی در اتصال NFS وجود داشته باشد، شناسایی شود.

---

5. راه‌حل‌های رفع مشکلات Mount و دسترسی به PV:

5.1. بازسازی PVC و PV:

در صورتی که مشکل Mount همچنان ادامه داشته باشد، ممکن است نیاز به بازسازی PVC یا PV داشته باشید. ابتدا PVC یا PV مشکل‌دار را حذف کرده و سپس دوباره آن‌ها را ایجاد کنید.

5.2. تأسیس مجدد فضای ذخیره‌سازی:

در صورتی که مشکل مربوط به فضای ذخیره‌سازی است، می‌توانید فضای مورد نیاز را از طریق تنظیمات StorageClass یا افزایش ظرفیت Persistent Volume اختصاص دهید.

5.3. مراجعه به مستندات و بررسی خطاها:

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

---

جمع‌بندی:

مشکلات مربوط به Mount یا دسترسی به Persistent Volume در Kubernetes می‌توانند به دلایل مختلفی از جمله تنظیمات نادرست PVC یا PV، مشکلات شبکه‌ای، یا مشکلات در فضای ذخیره‌سازی رخ دهند. برای شناسایی و رفع این مشکلات، از ابزارهایی مانند kubectl describe، kubectl logs، و kubectl get events می‌توان بهره برد. همچنین، بررسی تطابق مشخصات PVC و PV و وضعیت شبکه به شناسایی و رفع مشکلات کمک خواهد کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”دستور kubectl df-pv: مشاهده مصرف فضای PV‌ها” subtitle=”توضیحات کامل”]در کوبرنتیز، Persistent Volumes (PV) برای ذخیره‌سازی داده‌ها در محیط‌های پویا و مقیاس‌پذیر استفاده می‌شوند. از آنجایی که PV‌ها می‌توانند منابع زیادی را اشغال کنند، مدیریت فضای ذخیره‌سازی اهمیت زیادی دارد. یکی از ابزارهایی که می‌تواند به شما در نظارت بر فضای مصرفی در Persistent Volumes کمک کند، دستور kubectl df-pv است.

این دستور به شما این امکان را می‌دهد تا میزان فضای استفاده‌شده و فضای باقی‌مانده در PV‌های موجود در کلاستر را مشاهده کنید. به‌ویژه در سیستم‌هایی که از Dynamic Provisioning استفاده می‌کنند، نظارت بر فضای مصرفی در PV‌ها می‌تواند به جلوگیری از مشکلات در آینده کمک کند.

---

1. کاربرد دستور kubectl df-pv:

دستور kubectl df-pv مشابه با دستور df در لینوکس عمل می‌کند و اطلاعات مربوط به فضای ذخیره‌سازی را به‌صورت خلاصه و مفهومی نمایش می‌دهد.

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

• مشاهده وضعیت کلی فضای ذخیره‌سازی در Persistent Volumes.
• بررسی میزان فضای استفاده‌شده و باقی‌مانده در هر Volume.
• شناسایی حجم‌های PV که به‌طور غیرضروری فضای زیادی را اشغال کرده‌اند.
• پیدا کردن PV‌هایی که فضای کافی برای ذخیره داده‌ها در آینده نخواهند داشت.

---

2. نحوه استفاده از دستور kubectl df-pv:

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

kubectl df-pv

این دستور گزارشی از فضای مصرفی و فضای باقی‌مانده در تمامی PV‌های موجود در کلاستر نمایش می‌دهد.

3. مثال خروجی دستور kubectl df-pv:

خروجی دستور به‌طور معمول به‌صورت جدول نشان داده می‌شود. برای مثال:

NAME           CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
pvc-1234abcd   10Gi       RWO            Retain           Bound    default/my-pvc    standard                 5d
pvc-5678efgh   20Gi       RWO            Retain           Bound    default/my-pvc2   fast                    10d

در این جدول:

• NAME: نام Persistent Volume.
• CAPACITY: حجم کل فضای در دسترس برای Volume.
• ACCESS MODES: حالت دسترسی به Volume (مثلاً ReadWriteOnce).
• RECLAIM POLICY: سیاست بازیابی (مانند Retain).
• STATUS: وضعیت Volume (مانند Bound یا Available).
• CLAIM: PVC (Persistent Volume Claim) که این PV را استفاده می‌کند.
• STORAGECLASS: Storage Class استفاده‌شده برای این PV.
• REASON: دلیل وضعیت جاری (در صورت وجود).
• AGE: مدت زمان از زمان ایجاد PV.

---

4. مقایسه با دستور df در لینوکس:

دستور df در لینوکس به شما اجازه می‌دهد که فضای ذخیره‌سازی استفاده‌شده و باقی‌مانده در فایل‌سیستم‌های مختلف را مشاهده کنید. به‌طور مشابه، دستور kubectl df-pv فضای ذخیره‌سازی را برای Persistent Volumes در Kubernetes نشان می‌دهد.

اگر بخواهید از دستور df برای مشاهده فضای ذخیره‌سازی در یک سیستم لینوکس استفاده کنید، خروجی به شکل زیر خواهد بود:

df -h

این دستور فضای مصرف‌شده و باقی‌مانده برای تمامی پارتیشن‌ها را نمایش می‌دهد.

---

5. چرا نظارت بر مصرف فضای PV مهم است؟

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

---

6. نکات اضافی برای استفاده از دستور kubectl df-pv:

• اگر می‌خواهید اطلاعات بیشتری در مورد وضعیت PVC‌ها و PV‌ها کسب کنید، می‌توانید از دستورات تکمیلی مانند kubectl describe pvc و kubectl describe pv استفاده کنید.
• دستور kubectl df-pv بیشتر برای مشاهده وضعیت کلی PV‌ها کاربرد دارد و برای بررسی دقیق‌تر، باید به منابع و تنظیمات بیشتر توجه کنید.

---

جمع‌بندی:

دستور kubectl df-pv ابزاری مفید برای نظارت بر مصرف فضای ذخیره‌سازی در Persistent Volumes در کلاستر Kubernetes است. این دستور به شما کمک می‌کند تا از وضعیت فضای مصرفی و باقی‌مانده در PV‌ها آگاه شوید و از بروز مشکلات مربوط به فضای ذخیره‌سازی جلوگیری کنید. با استفاده از این دستور و ابزارهای مکمل، می‌توانید مدیریت بهتری بر منابع ذخیره‌سازی خود در Kubernetes داشته باشید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 9. عیب‌یابی Image و کانتینرها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی مشکلات Pull Image (مانند خطاهای ImagePullBackOff)” subtitle=”توضیحات کامل”]یکی از مشکلات رایج که ممکن است در هنگام استقرار Pod‌ها در Kubernetes به آن برخورد کنید، مشکلات مربوط به Pull کردن تصاویر (Images) است. این مشکلات ممکن است باعث شود که Pod نتواند به درستی اجرا شود و وضعیت آن به حالت‌های مختلفی مانند ImagePullBackOff تغییر کند. در اینجا به بررسی علل و روش‌های رفع این مشکلات می‌پردازیم.

---

1. خطای ImagePullBackOff چیست؟

وقتی Kubernetes تلاش می‌کند تا یک تصویر کانتینر را از یک رجیستری (Registry) بارگیری کند و موفق به این کار نشود، وضعیت Pod به ImagePullBackOff تغییر می‌کند. این وضعیت به این معنی است که Kubernetes تلاش‌های قبلی برای بارگیری تصویر به نتیجه نرسیده‌اند و حالا سیستم به مدت کوتاهی تلاش برای بارگیری را متوقف کرده است.

این خطا می‌تواند به دلیل دلایل مختلفی مانند مشکلات اتصال به رجیستری، خطاهای مربوط به اعتبارسنجی (Authentication)، نامعتبر بودن نام تصویر یا اشتباهات در نوشتار تصویر و یا محدودیت‌های شبکه ایجاد شود.

---

2. علل رایج بروز خطای ImagePullBackOff:

برخی از دلایل رایج بروز خطای ImagePullBackOff عبارتند از:

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

   مثال:

   image: myregistry/myimage:latest
   

2. عدم دسترسی به رجیستری (Registry):
   • اگر Kubernetes نتواند به رجیستری تصویر دسترسی پیدا کند (به دلیل مشکلات شبکه یا تنظیمات امنیتی)، تصویر نمی‌تواند کشیده شود.
3. مشکلات احراز هویت (Authentication):
   • اگر رجیستری خصوصی باشد، ممکن است نیاز به ارائه توکن یا رمز عبور برای دسترسی به تصویر باشد. در صورتی که اطلاعات احراز هویت نادرست باشد یا تنظیمات مربوط به Secret به درستی پیکربندی نشده باشد، Kubernetes قادر به بارگیری تصویر نخواهد بود.
4. مشکلات مربوط به نسخه تصویر (Tag):
   • اگر نسخه‌ای از تصویر که شما اشاره کرده‌اید وجود نداشته باشد، Kubernetes نمی‌تواند آن را بارگیری کند. اطمینان حاصل کنید که نسخه‌ی تصویر به‌طور صحیح مشخص شده است.
5. مشکلات شبکه یا DNS:
   • در صورتی که Kubernetes نتواند به سرور رجیستری دسترسی پیدا کند (به دلیل مشکلات DNS یا شبکه)، بارگیری تصویر به مشکل می‌خورد.

---

3. تشخیص علت خطای ImagePullBackOff:

برای تشخیص علت خطای ImagePullBackOff می‌توانید از دستور kubectl describe pod استفاده کنید تا اطلاعات دقیق‌تری در مورد خطای بارگیری تصویر دریافت کنید.

kubectl describe pod <pod-name>

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

مثال خروجی:

Events:
  Type     Reason     Age   From                                        Message
  ----     ------     ----  ----                                        -------
  Normal   Scheduled  3m    default-scheduler                           Successfully assigned default/my-pod to node1
  Normal   Pulling    3m    kubelet, node1                              Pulling image "myregistry/myimage:latest"
  Warning  Failed     2m    kubelet, node1                              Failed to pull image "myregistry/myimage:latest": rpc error: code = Unknown desc = Error response from daemon: pull access denied for myregistry/myimage, repository does not exist or may require 'docker login'
  Warning  Failed     2m    kubelet, node1                              Error: ErrImagePull
  Normal   BackOff    2m    kubelet, node1                              Back-off pulling image "myregistry/myimage:latest"

در این مثال، خطای مربوط به عدم دسترسی به تصویر (pull access denied) مشاهده می‌شود که به دلیل مشکلات احراز هویت یا نادرست بودن نام تصویر ایجاد شده است.

---

4. روش‌های رفع خطای ImagePullBackOff:

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

1. بررسی نام تصویر:
   • ابتدا اطمینان حاصل کنید که نام و نسخه تصویر به‌درستی وارد شده است. اگر نام تصویر به‌درستی نوشته نشده باشد یا نسخه‌ای که اشاره کرده‌اید وجود نداشته باشد، باید آن را اصلاح کنید.
2. بررسی دسترسی به رجیستری:
   • اگر از یک رجیستری خصوصی استفاده می‌کنید، مطمئن شوید که اطلاعات احراز هویت (مثل Secret‌ها) به‌درستی پیکربندی شده است. می‌توانید از Secret‌های Kubernetes برای احراز هویت با رجیستری استفاده کنید.

   مثال:

   imagePullSecrets:
     - name: my-registry-secret
   

3. بررسی وضعیت شبکه و DNS:
   • اگر خطا مربوط به اتصال شبکه باشد، باید اطمینان حاصل کنید که کلاستر شما به اینترنت یا به شبکه‌ای که رجیستری در آن قرار دارد، دسترسی دارد. در صورت نیاز، می‌توانید از ابزارهایی مانند nslookup برای تست DNS استفاده کنید.
4. تست با استفاده از دستورات kubectl logs و exec:
   • اگر Pod همچنان در حال تلاش برای بارگیری تصویر است، می‌توانید از دستور kubectl logs برای بررسی لاگ‌های بیشتر و دریافت اطلاعات دقیق‌تر استفاده کنید.

---

5. پیشگیری از بروز خطای ImagePullBackOff:

برای جلوگیری از بروز این نوع خطاها در آینده، توصیه می‌شود که:

• از تصاویر معتبر و به‌روز استفاده کنید.
• نام و نسخه تصاویر را به دقت وارد کنید.
• هنگام استفاده از رجیستری‌های خصوصی، تنظیمات احراز هویت و Secret‌ها را به‌درستی پیکربندی کنید.
• در صورت استفاده از ابزارهایی مانند Helm، بررسی کنید که charts شما به درستی پیکربندی شده‌اند و نسخه‌ها به درستی مشخص شده‌اند.
• سیستم‌های نظارت و هشدار برای نظارت بر وضعیت Pod‌ها و خطاهای احتمالی در فرآیند بارگیری تنظیم کنید.

---

جمع‌بندی:

خطای ImagePullBackOff معمولاً زمانی اتفاق می‌افتد که Kubernetes نتواند یک تصویر کانتینر را از رجیستری بارگیری کند. این خطا ممکن است به دلایل مختلفی مانند اشتباه در نوشتار نام تصویر، مشکلات شبکه، احراز هویت نادرست، یا نسخه‌های نامعتبر تصویر ایجاد شود. برای رفع این خطا، لازم است که نام تصویر را بررسی کرده و از پیکربندی صحیح احراز هویت و دسترسی به رجیستری اطمینان حاصل کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از Registry‌های خصوصی با Secret‌ها” subtitle=”توضیحات کامل”]در Kubernetes، زمانی که نیاز به استفاده از تصاویر (ایمیج) کانتینر از یک Registry خصوصی دارید، باید اطلاعات احراز هویت (مثل توکن‌ها یا نام کاربری و رمز عبور) را به Kubernetes ارائه دهید. برای انجام این کار، از Secret‌ها برای ذخیره اطلاعات حساس استفاده می‌شود. در اینجا نحوه استفاده از Registry‌های خصوصی با Secret‌ها را بررسی می‌کنیم.

---

1. چرا از Registry‌های خصوصی استفاده کنیم؟

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

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

---

2. ایجاد Secret برای دسترسی به Registry خصوصی

برای ایجاد یک Secret که Kubernetes بتواند از آن برای دسترسی به یک Registry خصوصی استفاده کند، از دستور kubectl create secret docker-registry استفاده می‌کنیم. این Secret حاوی اطلاعات احراز هویت شما برای اتصال به Registry خواهد بود.

فرمت کلی دستور:

kubectl create secret docker-registry <secret-name> \
  --docker-server=<registry-server> \
  --docker-username=<username> \
  --docker-password=<password> \
  --docker-email=<email>

مثال:

kubectl create secret docker-registry my-registry-secret \
  --docker-server=myregistry.example.com \
  --docker-username=myuser \
  --docker-password=mypassword \
  --docker-email=myuser@example.com

در این مثال:

• my-registry-secret: نام Secret است.
• myregistry.example.com: آدرس سرور رجیستری خصوصی است.
• myuser: نام کاربری برای احراز هویت است.
• mypassword: رمز عبور برای احراز هویت است.
• myuser@example.com: ایمیل حساب کاربری است.

---

3. استفاده از Secret در Pods

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

مثال پیکربندی Pod برای استفاده از Secret:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: myregistry.example.com/myimage:latest
  imagePullSecrets:
  - name: my-registry-secret

در این مثال:

• imagePullSecrets به Kubernetes می‌گوید که از Secret به نام my-registry-secret برای دسترسی به تصاویر موجود در رجیستری خصوصی myregistry.example.com استفاده کند.

---

4. استفاده از Secret در Deployment‌ها و سایر منابع

علاوه بر Pod‌ها، می‌توانید Secret را در Deployment‌ها و دیگر منابع Kubernetes نیز استفاده کنید. به‌عنوان مثال، در یک Deployment می‌توانید Secret را به‌طور مشابه به‌عنوان imagePullSecrets اضافه کنید.

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

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: myregistry.example.com/myimage:latest
      imagePullSecrets:
      - name: my-registry-secret

این پیکربندی مشابه با Pod است و به Kubernetes دستور می‌دهد که برای کشیدن تصاویر از Registry خصوصی از Secret استفاده کند.

---

5. بررسی وضعیت و اطمینان از دسترسی به Registry

پس از پیکربندی Pod یا Deployment با Secret، می‌توانید از دستور kubectl describe pod <pod-name> برای بررسی وضعیت Pod و اطلاعات مربوط به کشیدن تصویر استفاده کنید. در صورتی که مشکل در کشیدن تصویر وجود داشته باشد، می‌توانید خطاهای مربوط به آن را در بخش Events مشاهده کنید.

مثال:

kubectl describe pod my-pod

خروجی این دستور ممکن است حاوی اطلاعاتی در مورد وضعیت کشیدن تصویر باشد. اگر مشکلی در دسترسی به رجیستری وجود داشته باشد، مانند اشتباه در Secret یا دسترسی به شبکه، خطاهایی در این بخش مشاهده خواهید کرد.

---

6. توجهات و نکات امنیتی:

1. حفاظت از Secret‌ها:
   • Secret‌ها می‌توانند شامل اطلاعات حساس مانند نام کاربری و رمز عبور باشند، پس باید اطمینان حاصل کنید که فقط افراد مجاز به آن‌ها دسترسی دارند. برای این کار می‌توانید از RBAC برای مدیریت دسترسی به Secret‌ها استفاده کنید.
2. دسترسی محدود به Secret‌ها:
   • توصیه می‌شود که دسترسی به Secret‌ها را محدود کنید. از طریق RBAC می‌توانید مجوزهای دسترسی را به کاربران و سرویس‌ها به‌طور دقیق تنظیم کنید.
3. استفاده از Kubernetes Secrets با Vault:
   • برای مدیریت امن‌تر Secrets در Kubernetes می‌توانید از Vault استفاده کنید. این ابزار از رمزنگاری پیشرفته برای ذخیره‌سازی Secrets پشتیبانی می‌کند و امکان چرخش دوره‌ای رمزها و توکن‌ها را فراهم می‌آورد.

---

جمع‌بندی:

استفاده از Registry‌های خصوصی در Kubernetes نیازمند پیکربندی صحیح Secret‌ها برای دسترسی به تصاویر کانتینر است. با استفاده از دستور kubectl create secret docker-registry می‌توانید Secret‌هایی برای احراز هویت به رجیستری‌های خصوصی ایجاد کرده و آن‌ها را در Pod‌ها یا منابع دیگر Kubernetes استفاده کنید. از طریق این روش، می‌توانید امنیت تصاویر کانتینر خود را حفظ کرده و به صورت خودکار از آن‌ها در Pod‌ها و Deployment‌ها استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”Debugging کانتینرها: استفاده از ابزارهای داخل کانتینر مانند curl یا ping برای تست ارتباطات” subtitle=”توضیحات کامل”]Debugging یا اشکال‌زدایی یکی از مهم‌ترین مراحل در توسعه و اجرای کانتینرها است. در Kubernetes، پس از راه‌اندازی یک Pod یا کانتینر، ممکن است به مشکلات مختلفی برخورد کنید که باید آن‌ها را شناسایی و رفع کنید. یکی از روش‌های معمول برای دیباگ کردن کانتینرها، استفاده از ابزارهای داخلی مانند curl و ping است که به شما کمک می‌کنند تا ارتباطات شبکه‌ای، وضعیت سرویس‌ها، و عملکرد کانتینر را بررسی کنید.

---

1. چرا از ابزارهای داخلی استفاده کنیم؟

ابزارهایی مانند curl و ping می‌توانند در تشخیص مشکلات زیر مفید باشند:

• بررسی ارتباطات شبکه‌ای بین کانتینرها.
• تست اتصال به سرویس‌های داخلی یا خارجی.
• شبیه‌سازی درخواست‌های HTTP برای بررسی عملکرد سرویس‌ها.
• تشخیص مشکلات مربوط به DNS و سرویس‌های Kubernetes.

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

---

2. استفاده از دستور kubectl exec برای وارد شدن به کانتینر

برای استفاده از ابزارهای داخلی کانتینر مانند curl یا ping، ابتدا باید به محیط کانتینر دسترسی پیدا کنید. برای این کار از دستور kubectl exec استفاده می‌کنیم.

فرمت کلی دستور:

kubectl exec -it <pod-name> -- <command>

• -it: این گزینه‌ها برای دسترسی تعاملی به کانتینر استفاده می‌شوند.
• <pod-name>: نام Pod یا نام کانتینری است که می‌خواهید به آن وارد شوید.
• <command>: دستور یا ابزار مورد نظر برای اجرا است (مثلاً curl یا ping).

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

kubectl exec -it my-pod -- curl http://my-service

اگر بخواهید از دستور ping برای بررسی ارتباط شبکه‌ای استفاده کنید:

kubectl exec -it my-pod -- ping 8.8.8.8

در این مثال‌ها:

• my-pod نام Pod است که کانتینر شما در آن در حال اجرا است.
• دستور curl برای ارسال درخواست HTTP به آدرس http://my-service استفاده می‌شود.
• دستور ping برای تست ارتباط شبکه‌ای با سرور 8.8.8.8 استفاده می‌شود.

---

3. بررسی ارتباط شبکه‌ای با ping

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

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

مثال: برای تست دسترسی به یک سرور DNS یا سرویس دیگر در شبکه، می‌توانید از دستور ping استفاده کنید:

kubectl exec -it my-pod -- ping my-service

اگر سرویس my-service در همان Pod یا شبکه قرار داشته باشد، این دستور باید پاسخ‌های موفقیت‌آمیز را نمایش دهد.

---

4. استفاده از curl برای تست درخواست‌های HTTP

دستور curl برای ارسال درخواست‌های HTTP بسیار مفید است. با استفاده از curl می‌توانید از داخل کانتینر خود تست‌های مختلفی انجام دهید، از جمله:

• بررسی پاسخ سرویس‌ها.
• مشاهده هدرهای HTTP.
• بررسی وضعیت کدهای HTTP (مثل 200، 404، 500).

مثال: برای بررسی وضعیت سرویس وب در داخل یک Pod، از دستور curl استفاده کنید:

kubectl exec -it my-pod -- curl -I http://my-web-service

در این مثال:

• -I فقط هدرهای HTTP را نمایش می‌دهد.
• http://my-web-service URL سرویس شما است.

این دستور پاسخ‌هایی مانند کد وضعیت HTTP، هدرها و اطلاعات دیگر را از سرویس وب برمی‌گرداند.

---

5. استفاده از netcat (nc) برای تست اتصال شبکه

یکی دیگر از ابزارهای مفید در اشکال‌زدایی شبکه، netcat یا به اختصار nc است. با استفاده از این ابزار می‌توانید اتصال به پورت‌های خاص در یک سرویس یا سرور را تست کنید.

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

kubectl exec -it my-pod -- nc -zv my-service 80

در این مثال:

• -z برای اسکن پورت‌ها استفاده می‌شود.
• -v برای نمایش جزئیات بیشتر از جمله نتیجه اتصال استفاده می‌شود.

این دستور بررسی می‌کند که آیا پورت 80 در سرویس my-service باز و قابل دسترسی است یا خیر.

---

6. نکات مهم در هنگام استفاده از ابزارهای داخل کانتینر:

• وجود ابزارهای لازم: قبل از استفاده از ابزارهایی مانند curl، ping یا netcat، اطمینان حاصل کنید که این ابزارها در تصویر کانتینر شما موجود هستند. اگر این ابزارها در تصویر نیستند، می‌توانید آن‌ها را از طریق Dockerfile به تصویر اضافه کنید.
• دسترس‌پذیری شبکه: برخی از مشکلات ممکن است به دلیل تنظیمات شبکه یا محدودیت‌های امنیتی در Kubernetes ایجاد شوند. برای رفع این مشکلات، تنظیمات Network Policies و Service Account را بررسی کنید.
• فعال کردن دسترسی از داخل کانتینر: اگر دسترسی به برخی سرویس‌ها یا منابع نیاز به احراز هویت دارد، اطمینان حاصل کنید که Secret‌ها و Service Account به درستی پیکربندی شده باشند.

---

جمع‌بندی:

استفاده از ابزارهایی مانند curl، ping و netcat در کانتینرها می‌تواند به شما کمک کند تا مشکلات شبکه و ارتباطی را شناسایی کرده و در زمان اشکال‌زدایی به شما کمک کند. با دسترسی به ترمینال کانتینر و اجرای این ابزارها، می‌توانید وضعیت شبکه، اتصال به سرویس‌ها و پاسخ‌های HTTP را بررسی کرده و مشکلات را شناسایی کنید. این روش‌ها به ویژه در محیط‌هایی که نیاز به تشخیص سریع مشکلات دارند، بسیار مؤثر هستند.[/cdb_course_lesson][/cdb_course_lessons]

[cdb_course_lessons title=”بخش 7. ابزارها و دستورات Kubernetes”][cdb_course_lesson title=”فصل 1. مدیریت منابع با kubectl”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نحوه نصب و پیکربندی ابزار kubectl” subtitle=”توضیحات کامل”]kubectl ابزار خط فرمان رسمی برای تعامل با Kubernetes است و به شما این امکان را می‌دهد که منابع Kubernetes را مدیریت کنید، وضعیت Cluster را مشاهده کنید، و پیکربندی‌ها را تغییر دهید. در این بخش، مراحل نصب و پیکربندی ابزار kubectl را به طور کامل شرح خواهیم داد.

---

1. نصب ابزار kubectl

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

---

نصب kubectl در سیستم‌عامل Linux

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

1. ابتدا باید آخرین نسخه kubectl را دانلود کنید:

   curl -LO https://storage.googleapis.com/kubernetes-release/release/$(curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt)/bin/linux/amd64/kubectl
   

2. فایل دانلود شده را اجرایی کنید:

   chmod +x ./kubectl
   

3. فایل اجرایی را به یک پوشه در مسیر سیستم (مثل /usr/local/bin) منتقل کنید:

   sudo mv ./kubectl /usr/local/bin/kubectl
   

4. پس از نصب، برای بررسی نصب صحیح kubectl دستور زیر را اجرا کنید:

   kubectl version --client
   

---

نصب kubectl در سیستم‌عامل macOS

برای نصب kubectl در macOS، شما می‌توانید از Homebrew استفاده کنید. دستورات زیر را اجرا کنید:

1. ابتدا kubectl را با Homebrew نصب کنید:

   brew install kubectl
   

2. پس از نصب، برای بررسی نسخه kubectl از دستور زیر استفاده کنید:

   kubectl version --client
   

---

نصب kubectl در سیستم‌عامل Windows

در سیستم‌عامل Windows، می‌توانید از choco (Chocolatey) برای نصب kubectl استفاده کنید:

1. ابتدا Chocolatey را نصب کنید (در صورتی که قبلاً نصب نکردید):

   Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.ServicePointManager]::SecurityProtocol -bor 3072; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))
   

2. سپس kubectl را با استفاده از دستور زیر نصب کنید:

   choco install kubernetes-cli
   

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

   kubectl version --client
   

---

2. پیکربندی kubectl

پس از نصب موفقیت‌آمیز kubectl، برای دسترسی به Cluster و انجام عملیات مدیریت، نیاز است که kubectl به یک Cluster Kubernetes متصل شود. این اتصال از طریق پیکربندی فایل kubeconfig انجام می‌شود.

---

پیکربندی kubectl برای اتصال به Cluster

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

1. دریافت فایل kubeconfig از Admin Cluster اگر شما به عنوان یک کاربر جدید در حال تنظیم kubectl هستید، معمولاً مسئول Cluster (مثلاً Admin) باید فایل kubeconfig را برای شما ارسال کند. این فایل شامل اطلاعاتی مانند URL سرویس API و گواهی‌های امنیتی است.
2. تنظیم فایل kubeconfig به‌صورت دستی اگر به‌صورت دستی فایل kubeconfig را تنظیم می‌کنید، می‌توانید فایل را در مسیر ~/.kube/config ذخیره کنید و تنظیمات آن را به‌صورت زیر انجام دهید:
   • apiVersion: نسخه سرویس API که به آن متصل خواهید شد.
   • clusters: اطلاعات مربوط به Cluster.
   • contexts: پیکربندی‌های مختلف برای اتصال به Cluster.
   • users: اطلاعات کاربری برای احراز هویت.

   مثال فایل kubeconfig:

   apiVersion: v1
   kind: Config
   clusters:
   - name: my-cluster
     cluster:
       server: https://my-cluster-api-server
       certificate-authority-data: <CA_CERTIFICATE>
   contexts:
   - name: my-cluster-context
     context:
       cluster: my-cluster
       user: my-user
   users:
   - name: my-user
     user:
       token: <ACCESS_TOKEN>
   current-context: my-cluster-context
   

3. تنظیم متغیر محیطی KUBECONFIG اگر فایل kubeconfig شما در مسیر پیش‌فرض نیست، می‌توانید متغیر محیطی KUBECONFIG را برای اشاره به مسیر فایل خود تنظیم کنید:

   export KUBECONFIG=/path/to/your/kubeconfig
   

---

انتخاب و تغییر Context در kubectl

اگر در حال کار با چندین Cluster مختلف باشید، kubectl به شما این امکان را می‌دهد که به راحتی بین Context‌های مختلف جابجا شوید.

1. مشاهده context‌های موجود:

   kubectl config get-contexts
   

2. انتخاب یک context برای استفاده:

   kubectl config use-context my-cluster-context
   

---

3. تست اتصال به Cluster

پس از پیکربندی فایل kubeconfig، می‌توانید با استفاده از دستور زیر اطمینان حاصل کنید که kubectl به درستی به Cluster متصل است و اطلاعات Cluster را بازیابی می‌کند:

kubectl cluster-info

این دستور اطلاعاتی از جمله آدرس سرویس API و سایر جزئیات مربوط به Cluster را نمایش می‌دهد.

---

جمع‌بندی

نصب و پیکربندی صحیح ابزار kubectl برای مدیریت منابع Kubernetes بسیار ضروری است. با نصب ابزار به‌صورت صحیح و پیکربندی فایل kubeconfig، شما می‌توانید به راحتی به Cluster‌ها متصل شده و از آن‌ها استفاده کنید. این ابزار امکان اجرای دستورات مختلف برای مدیریت منابع، بررسی وضعیت سیستم، و انجام تنظیمات مختلف در Kubernetes را فراهم می‌کند.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl create برای ایجاد منابع (مثل Pods، Services، Deployments)” subtitle=”توضیحات کامل”]یکی از مهمترین وظایف ابزار kubectl در Kubernetes ایجاد منابع مختلف در Cluster است. با استفاده از دستور kubectl create می‌توان منابعی نظیر Pods، Services و Deployments را به راحتی ایجاد کرد. این دستور به شما این امکان را می‌دهد که منابع Kubernetes را به‌طور سریع و دقیق بر اساس پیکربندی‌های دلخواه ایجاد کنید.

---

1. ایجاد Pod با استفاده از kubectl create

Podها کوچکترین واحد اجرایی در Kubernetes هستند. برای ایجاد یک Pod، می‌توانید از دستور kubectl create همراه با مشخصات لازم استفاده کنید.

ایجاد یک Pod ساده:

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

kubectl create pod my-pod --image=nginx

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

ایجاد یک Pod با تعداد خاصی از Replicas:

برای ایجاد یک Pod با تعداد خاصی از Replica‌ها، باید از یک Deployment استفاده کنید (که در ادامه به آن می‌پردازیم).

---

2. ایجاد Deployment با استفاده از kubectl create

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

ایجاد یک Deployment ساده:

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

kubectl create deployment my-deployment --image=nginx

این دستور یک Deployment به نام my-deployment با استفاده از تصویر nginx ایجاد می‌کند.

ایجاد Deployment با تعداد Replicas خاص:

برای ایجاد یک Deployment با تعداد مشخصی از Replica‌ها (مثلاً 3 تا)، می‌توانید از گزینه --replicas استفاده کنید:

kubectl create deployment my-deployment --image=nginx --replicas=3

---

3. ایجاد Service با استفاده از kubectl create

Services در Kubernetes برای اتصال به Pod‌ها از طریق شبکه و مدیریت دسترسی به آن‌ها استفاده می‌شوند. kubectl create به شما این امکان را می‌دهد که یک Service را برای یک Pod یا Deployment ایجاد کنید.

ایجاد یک Service ساده برای Pod:

برای ایجاد یک Service برای یک Pod خاص از دستور زیر استفاده می‌شود:

kubectl expose pod my-pod --port=8080 --target-port=80

این دستور یک Service برای my-pod ایجاد می‌کند که ترافیک ورودی روی پورت 8080 را به پورت 80 در Pod هدایت می‌کند.

ایجاد یک Service برای Deployment:

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

kubectl expose deployment my-deployment --port=8080 --target-port=80

این دستور یک Service برای Deployment my-deployment ایجاد می‌کند که ترافیک ورودی روی پورت 8080 را به پورت 80 در Pod‌ها هدایت می‌کند.

ایجاد یک Service از نوع ClusterIP، NodePort یا LoadBalancer:

در زمان ایجاد Service، می‌توانید نوع دسترسی به Service را تعیین کنید. به‌طور پیش‌فرض، نوع Service ClusterIP است، اما می‌توانید آن را به نوع‌های دیگری مانند NodePort یا LoadBalancer تغییر دهید:

kubectl expose deployment my-deployment --type=NodePort --port=8080 --target-port=80

در این مثال، --type=NodePort Service را از نوع NodePort ایجاد می‌کند.

---

4. ایجاد Resource‌های دیگر با استفاده از kubectl create

به‌طور مشابه می‌توانید منابع دیگری مانند ConfigMap‌ها، Secrets، Volumes و … را نیز با استفاده از kubectl create ایجاد کنید.

ایجاد ConfigMap از فایل:

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

kubectl create configmap my-config --from-file=path/to/config/file

ایجاد Secret از فایل:

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

kubectl create secret generic my-secret --from-file=path/to/secret/file

ایجاد Namespace:

برای ایجاد یک Namespace در Kubernetes، دستور زیر را اجرا کنید:

kubectl create namespace my-namespace

---

5. ایجاد منابع از YAML یا JSON

اگر ترجیح می‌دهید که منابع خود را به‌صورت فایل‌های YAML یا JSON بنویسید، می‌توانید از دستور kubectl create -f برای ایجاد منابع استفاده کنید.

ایجاد منابع از فایل YAML:

kubectl create -f my-deployment.yaml

ایجاد منابع از فایل JSON:

kubectl create -f my-service.json

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

---

جمع‌بندی

ابزار kubectl create یکی از دستورات پایه‌ای و مهم برای ایجاد منابع مختلف در Kubernetes است. با استفاده از این دستور می‌توانید منابعی مانند Pods، Deployments، Services و بسیاری از منابع دیگر را به راحتی در Kubernetes ایجاد کنید. این ابزار علاوه بر پشتیبانی از گزینه‌های مختلف برای تعیین تعداد Replicas و نوع سرویس، همچنین از فایل‌های YAML و JSON برای ایجاد منابع نیز پشتیبانی می‌کند.

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

---

1. ساخت یک Pod از فایل YAML

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

محتوای فایل pod.yaml:

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

این فایل YAML یک Pod به نام my-pod با یک کانتینر از تصویر nginx می‌سازد. پس از ایجاد این فایل، می‌توانید از دستور زیر برای ساخت Pod استفاده کنید:

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

kubectl apply -f pod.yaml

این دستور فایل pod.yaml را می‌خواند و Pod مربوطه را در Kubernetes ایجاد می‌کند.

---

2. ساخت یک Deployment از فایل YAML

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

محتوای فایل deployment.yaml:

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

این فایل YAML یک Deployment به نام nginx-deployment با ۳ Replica از Pod‌هایی که تصویر nginx را اجرا می‌کنند، ایجاد می‌کند.

ایجاد Deployment از فایل YAML:

kubectl apply -f deployment.yaml

---

3. ساخت یک Service از فایل YAML

Services برای ارائه دسترسی شبکه به Pod‌ها استفاده می‌شوند. برای مثال، اگر بخواهید یک Service برای دسترسی به Pod‌های nginx-deployment ایجاد کنید، می‌توانید از فایل YAML زیر استفاده کنید:

محتوای فایل service.yaml:

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

این فایل YAML یک Service به نام nginx-service برای Pod‌هایی که دارای برچسب app: nginx هستند، ایجاد می‌کند. این Service از نوع ClusterIP است که به این معنی است که فقط از داخل Cluster قابل دسترسی است.

ایجاد Service از فایل YAML:

kubectl apply -f service.yaml

---

4. ساخت یک ConfigMap از فایل YAML

ConfigMap‌ها برای نگهداری پیکربندی‌های غیر حساس مانند تنظیمات یا فایل‌های پیکربندی برای کانتینر‌ها استفاده می‌شوند. در اینجا مثالی از یک فایل YAML برای ایجاد یک ConfigMap آورده شده است:

محتوای فایل configmap.yaml:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config1: "value1"
  config2: "value2"

این فایل یک ConfigMap به نام my-config می‌سازد که شامل دو پیکربندی config1 و config2 است.

ایجاد ConfigMap از فایل YAML:

kubectl apply -f configmap.yaml

---

5. ساخت یک PersistentVolume و PersistentVolumeClaim از فایل YAML

اگر نیاز دارید تا فضای ذخیره‌سازی دائمی برای Pod‌های خود فراهم کنید، می‌توانید از PersistentVolume (PV) و PersistentVolumeClaim (PVC) استفاده کنید. در اینجا مثالی از فایل YAML برای ایجاد یک PV و PVC آورده شده است:

محتوای فایل pv-pvc.yaml:

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: /mnt/data
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  resources:
    requests:
      storage: 1Gi
  accessModes:
    - ReadWriteOnce

این فایل YAML یک PV با ظرفیت ۱ گیگابایت و یک PVC برای درخواست فضای ذخیره‌سازی مشابه ایجاد می‌کند.

ایجاد PV و PVC از فایل YAML:

kubectl apply -f pv-pvc.yaml

---

6. ساخت منابع از فایل‌های YAML دیگر

علاوه بر موارد ذکر شده، می‌توانید انواع مختلف منابع مانند Namespaces، Secrets، Ingress‌ها، Network Policies و غیره را نیز از فایل‌های YAML ایجاد کنید. این روش برای مدیریت و نگهداری منابع در یک پروژه یا محیط Kubernetes بسیار مفید است.

ایجاد Namespace از فایل YAML:

apiVersion: v1
kind: Namespace
metadata:
  name: my-namespace

ایجاد Secret از فایل YAML:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: dXNlcm5hbWU=   # Base64 encoded value of username
  password: cGFzc3dvcmQ=   # Base64 encoded value of password

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

kubectl apply -f <file-name>.yaml

---

جمع‌بندی

استفاده از فایل‌های YAML در Kubernetes برای ایجاد منابع یکی از روش‌های اصلی و کارآمد است. این فایل‌ها به شما این امکان را می‌دهند که منابع پیچیده را به‌طور ساختار یافته تعریف کرده و آن‌ها را به‌طور مداوم مدیریت کنید. با استفاده از دستور kubectl apply -f <file-name>.yaml می‌توانید به راحتی منابع مختلف مانند Pods، Deployments، Services، ConfigMap‌ها و دیگر منابع را ایجاد و مدیریت کنید. این روش همچنین برای نسخه‌بندی و اشتراک‌گذاری پیکربندی‌ها در تیم‌های توسعه مفید است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl apply برای به‌روزرسانی منابع” subtitle=”توضیحات کامل”]در Kubernetes، برای به‌روزرسانی منابع از دستور kubectl apply استفاده می‌شود. این دستور به‌طور خاص برای مدیریت منابع و اعمال تغییرات بر روی آن‌ها طراحی شده است. یکی از ویژگی‌های مهم kubectl apply این است که تغییرات به‌صورت افزایشی و بدون حذف منابع موجود، انجام می‌شود. این ویژگی به شما این امکان را می‌دهد که به‌روزرسانی‌ها را به‌راحتی اعمال کرده و به تنظیمات جدید منابع دسترسی پیدا کنید.

---

1. عملکرد kubectl apply

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

---

2. استفاده از kubectl apply برای به‌روزرسانی منابع

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

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

فرض کنید یک Deployment به نام nginx-deployment دارید که در آن نسخه‌ای از تصویر nginx در حال استفاده است. حالا می‌خواهید این Deployment را به نسخه جدیدتری از nginx به‌روزرسانی کنید.

فایل YAML قبلی (deployment.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.18 # نسخه قبلی
        ports:
        - containerPort: 80

به‌روزرسانی تصویر به نسخه جدید (nginx:1.19)

در فایل YAML جدید، فقط تصویر کانتینر را تغییر می‌دهید:

فایل YAML به‌روزرسانی‌شده (deployment-updated.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19 # نسخه جدید
        ports:
        - containerPort: 80

به‌روزرسانی Deployment با kubectl apply:

kubectl apply -f deployment-updated.yaml

در اینجا، دستور kubectl apply فقط تغییرات مربوط به تصویر کانتینر را اعمال می‌کند. Kubernetes به‌طور خودکار Pod‌های جدید را با نسخه جدید تصویر nginx:1.19 ایجاد کرده و Pod‌های قدیمی را حذف می‌کند.

---

3. پیگیری تغییرات و به‌روزرسانی وضعیت منابع

پس از به‌روزرسانی منابع، می‌توانید وضعیت آن‌ها را بررسی کرده و اطمینان حاصل کنید که همه‌چیز به‌درستی به‌روزرسانی شده است.

بررسی وضعیت Deployment پس از به‌روزرسانی:

kubectl get deployment nginx-deployment

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

بررسی Pod‌ها بعد از به‌روزرسانی:

kubectl get pods -l app=nginx

این دستور لیستی از Pod‌هایی که برچسب app=nginx دارند را نمایش می‌دهد. با این کار می‌توانید ببینید که آیا Pod‌ها به‌درستی به‌روزرسانی شده‌اند یا نه.

---

4. مدیریت به‌روزرسانی با استراتژی Rolling Update

Kubernetes به‌طور پیش‌فرض از استراتژی Rolling Update برای به‌روزرسانی منابع استفاده می‌کند. این استراتژی به این معناست که Pod‌های جدید یکی‌یکی جایگزین Pod‌های قدیمی می‌شوند و هیچ‌گاه همه‌ی Pod‌ها به‌طور همزمان از دست نمی‌روند. این کار باعث می‌شود که سرویس‌ها همیشه در دسترس باقی بمانند.

اگر می‌خواهید این استراتژی را مدیریت کنید، می‌توانید موارد زیر را تنظیم کنید:

مثال تنظیم استراتژی Rolling Update:

spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 1

• maxSurge: تعداد Pod‌های اضافی که در زمان به‌روزرسانی می‌توانند ایجاد شوند.
• maxUnavailable: حداکثر تعداد Pod‌هایی که می‌توانند همزمان غیرقابل دسترس باشند.

---

5. به‌روزرسانی منابع دیگر با kubectl apply

دستور kubectl apply می‌تواند برای به‌روزرسانی انواع مختلف منابع مانند ConfigMap‌ها، Secrets، Services و غیره استفاده شود. در همه‌ی این موارد، روند به‌روزرسانی مشابه است: ابتدا فایل YAML جدید با تغییرات موردنظر را ایجاد می‌کنید و سپس با دستور kubectl apply آن را اعمال می‌کنید.

به‌روزرسانی یک ConfigMap:

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-config
data:
  config1: "new-value1"  # به‌روزرسانی مقادیر
  config2: "new-value2"

به‌روزرسانی ConfigMap با kubectl apply:

kubectl apply -f configmap-updated.yaml

---

جمع‌بندی

دستور kubectl apply یکی از ابزارهای بسیار مفید برای به‌روزرسانی منابع در Kubernetes است. این دستور تنها تغییرات لازم را اعمال می‌کند و منابع موجود را بدون حذف یا ایجاد دوباره مدیریت می‌کند. به‌روزرسانی منابع مختلف مانند Deployments، ConfigMap‌ها، Services و غیره با استفاده از فایل‌های YAML، امکان پیگیری تغییرات و اطمینان از عملکرد صحیح منابع را فراهم می‌کند. علاوه بر این، استراتژی Rolling Update به‌طور خودکار به‌روزرسانی Pod‌ها را بدون از دست دادن دسترسی به سرویس‌ها انجام می‌دهد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مقایسه تغییرات با kubectl diff” subtitle=”توضیحات کامل”]دستور kubectl diff در Kubernetes به شما این امکان را می‌دهد که تغییرات بین وضعیت کنونی منابع در کلاستر و فایل YAML یا تنظیمات جدیدی که می‌خواهید اعمال کنید را مقایسه کنید. این دستور برای بررسی دقیق قبل از اعمال تغییرات و اطمینان از اینکه تغییرات به درستی اعمال می‌شوند، بسیار مفید است. با استفاده از kubectl diff، می‌توانید مشاهده کنید که چه تفاوت‌هایی بین وضعیت فعلی و فایل پیکربندی شما وجود دارد.

---

1. عملکرد kubectl diff

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

این دستور می‌تواند برای تمام منابع Kubernetes مانند Pods، Deployments، ConfigMaps، Secrets و سایر منابع استفاده شود.

---

2. مقایسه منابع با kubectl diff

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

فرمان ساده برای استفاده از kubectl diff:

kubectl diff -f deployment.yaml

در اینجا، Kubernetes فایل deployment.yaml را با وضعیت فعلی Deployment‌ها در کلاستر مقایسه می‌کند و هرگونه تغییرات را نشان می‌دهد. این دستور هیچ تغییری در منابع ایجاد نمی‌کند، فقط تغییرات احتمالی را نمایش می‌دهد.

---

3. مقایسه منابع از کلاستر و فایل YAML جدید

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

مثال: مقایسه Deployment فعلی با فایل YAML جدید

فرض کنید Deployment فعلی شما از نسخه nginx:1.18 استفاده می‌کند و شما می‌خواهید آن را به نسخه nginx:1.19 به‌روزرسانی کنید. ابتدا باید فایل YAML جدید خود را برای این به‌روزرسانی ایجاد کنید.

فایل YAML جدید (deployment-updated.yaml):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.19  # نسخه به‌روزرسانی شده
        ports:
        - containerPort: 80

برای مقایسه این فایل با وضعیت کنونی Deployment در کلاستر، می‌توانید از دستور kubectl diff استفاده کنید:

دستور برای مقایسه:

kubectl diff -f deployment-updated.yaml

این دستور تغییرات بین فایل deployment-updated.yaml و وضعیت فعلی Deployment در کلاستر را نشان می‌دهد. خروجی این دستور شامل تغییراتی مانند نسخه جدید تصویر کانتینر خواهد بود.

---

4. تفاوت‌های خروجی

خروجی دستور kubectl diff مشابه یک مقایسه‌ی git diff است که تفاوت‌ها را به‌صورت برجسته نمایش می‌دهد. خطوطی که حذف می‌شوند با علامت - و خطوطی که به فایل جدید اضافه می‌شوند با علامت + نمایش داده می‌شوند.

نمونه خروجی از kubectl diff:

diff -u deployment-old.yaml deployment-updated.yaml
--- deployment-old.yaml
+++ deployment-updated.yaml
@@ -9,7 +9,7 @@
       containers:
       - name: nginx
-        image: nginx:1.18
+        image: nginx:1.19

در این خروجی، خط image: nginx:1.18 حذف شده و با image: nginx:1.19 جایگزین شده است.

---

5. مزایای استفاده از kubectl diff

• اطمینان از اعمال تغییرات صحیح: قبل از اعمال تغییرات بر روی منابع، می‌توانید دقیقاً ببینید که چه تغییراتی انجام می‌شود.
• جلوگیری از اشتباهات: با استفاده از kubectl diff می‌توانید از اعمال تغییرات ناخواسته جلوگیری کنید و مطمئن شوید که تنظیمات صحیحی را به منابع اعمال خواهید کرد.
• سهولت استفاده: این ابزار به شما کمک می‌کند تا تغییرات میان فایل‌های پیکربندی و منابع موجود را به‌سادگی مشاهده کنید.

---

6. کاربردهای kubectl diff در سناریوهای مختلف

• به‌روزرسانی نسخه‌های کانتینر: هنگام به‌روزرسانی تصویر کانتینر در یک Deployment، با استفاده از kubectl diff می‌توانید مقایسه کنید که تغییرات فقط به‌روزرسانی نسخه تصویر را شامل می‌شود.
• پیکربندی‌های امنیتی: اگر تنظیمات امنیتی مانند NetworkPolicy یا RBAC را به‌روزرسانی می‌کنید، kubectl diff می‌تواند کمک کند تا دقیقا متوجه شوید چه تغییراتی در سیاست‌های امنیتی ایجاد شده است.
• پیکربندی منابع: هنگام تغییر تنظیمات منابع مانند replicas، resource requests و limits، kubectl diff می‌تواند تفاوت‌ها را شبیه‌سازی کند تا از تغییرات ناخواسته جلوگیری شود.

---

جمع‌بندی

دستور kubectl diff یک ابزار عالی برای مقایسه منابع موجود در کلاستر Kubernetes و فایل‌های YAML جدید است. این دستور به شما اجازه می‌دهد تغییرات قبل از اعمال آن‌ها را مشاهده کنید و از اعمال تغییرات ناخواسته جلوگیری کنید. استفاده از kubectl diff به شما این امکان را می‌دهد که با دقت بیشتری منابع Kubernetes خود را مدیریت کنید و از اشتباهات احتمالی جلوگیری نمایید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl delete برای حذف منابع با نام یا نوع مشخص” subtitle=”توضیحات کامل”]در Kubernetes، دستور kubectl delete برای حذف منابع مختلف مانند Pods، Services، Deployments، ConfigMaps و سایر منابع استفاده می‌شود. این دستور به شما این امکان را می‌دهد که منابع خاص را با استفاده از نام یا نوع آن‌ها حذف کنید. دستور kubectl delete در مدیریت منابع Kubernetes به‌ویژه برای حذف منابع غیر ضروری یا منابعی که دیگر مورد استفاده قرار نمی‌گیرند، بسیار مفید است.

---

1. حذف منابع با استفاده از نام یا نوع

برای حذف یک منبع خاص، باید نام منبع و نوع آن را مشخص کنید. به‌عنوان مثال، اگر می‌خواهید یک Pod خاص را حذف کنید، می‌توانید دستور kubectl delete را به همراه نام Pod اجرا کنید.

فرمت کلی دستور:

kubectl delete <نوع منبع> <نام منبع>

در این دستور:

• <نوع منبع> مانند pod, service, deployment و غیره است.
• <نام منبع> نام منبع مورد نظر است که می‌خواهید حذف کنید.

---

2. حذف یک Pod خاص

برای حذف یک Pod خاص از کلاستر Kubernetes، کافی است نام آن را به‌عنوان ورودی وارد کنید. به‌عنوان مثال، برای حذف یک Pod به نام nginx-pod، دستور به‌صورت زیر خواهد بود:

kubectl delete pod nginx-pod

این دستور Pod مورد نظر را از کلاستر حذف می‌کند.

---

3. حذف منابع با استفاده از نوع منبع

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

حذف تمام Pods در یک Namespace:

kubectl delete pods --all --namespace=my-namespace

در اینجا، --all به معنای حذف تمام Pods در نام‌فضای my-namespace است.

---

4. حذف منابع به‌صورت انتخابی با استفاده از لیبل‌ها (Labels)

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

حذف منابع با استفاده از لیبل:

kubectl delete pods -l app=nginx

در اینجا، تمام Pods‌هایی که لیبل app=nginx دارند حذف خواهند شد.

---

5. حذف منابع از طریق فایل YAML

شما می‌توانید منابعی را که قبلاً در یک فایل YAML تعریف کرده‌اید با استفاده از دستور kubectl delete حذف کنید. برای این کار، تنها کافی است فایل YAML مورد نظر را مشخص کنید.

حذف منابع از طریق فایل YAML:

kubectl delete -f deployment.yaml

در اینجا، تمام منابع تعریف‌شده در فایل deployment.yaml حذف می‌شوند.

---

6. حذف منابع از طریق فیلتر کردن بر اساس Namespace

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

حذف منابع در یک Namespace خاص:

kubectl delete pods --namespace=my-namespace

این دستور تمام Pods‌ها را در نام‌فضای my-namespace حذف خواهد کرد.

---

7. حذف منابع از طریق پترن‌های خاص (مثل استفاده از wildcard)

اگر بخواهید منابع خاصی را با الگوهای خاص (wildcards) حذف کنید، می‌توانید از آن‌ها در نام منابع استفاده کنید. به‌عنوان مثال، برای حذف تمام Pods که نام آن‌ها با nginx- شروع می‌شود، می‌توانید از دستور زیر استفاده کنید:

حذف منابع با نام خاص:

kubectl delete pod nginx-*

این دستور تمام Pods‌هایی که نام آن‌ها با nginx- شروع می‌شود را حذف می‌کند.

---

8. حذف منابع با تأیید

به‌طور پیش‌فرض، دستور kubectl delete منابع را بدون هیچ‌گونه تأیید قبلی حذف می‌کند. اما اگر بخواهید پیش از حذف، تأیید کنید، می‌توانید از گزینه --dry-run استفاده کنید که به شما اجازه می‌دهد پیش از اعمال تغییرات، آن‌ها را بررسی کنید.

حذف با تأیید (با استفاده از dry-run):

kubectl delete pod nginx-pod --dry-run

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

---

9. حذف منابع با گزینه –force و –grace-period

در بعضی موارد، ممکن است بخواهید منابع را فوراً و بدون مدت زمان انتظار حذف کنید. برای این کار می‌توانید از گزینه‌های --force و --grace-period=0 استفاده کنید.

حذف فوری منابع:

kubectl delete pod nginx-pod --force --grace-period=0

این دستور Pod را فوراً حذف می‌کند بدون اینکه مدت زمان مهلت (grace period) برای حذف تعیین شده باشد.

---

جمع‌بندی

دستور kubectl delete یک ابزار بسیار مفید و قدرتمند در Kubernetes است که به شما این امکان را می‌دهد که منابع مختلف کلاستر را با استفاده از نام، نوع، لیبل، فایل‌های YAML یا فیلترهای مختلف حذف کنید. همچنین با استفاده از گزینه‌های مختلف این دستور، شما می‌توانید حذف منابع را به‌صورت انتخابی، سریع، یا با تأیید انجام دهید. این ابزار به‌ویژه در زمان مدیریت منابع Kubernetes برای حذف منابع اضافی یا مشکلات منابع بسیار کاربردی است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”حذف منابع از فایل‌های YAML” subtitle=”توضیحات کامل”]در Kubernetes، منابع معمولاً از طریق فایل‌های YAML یا JSON تعریف می‌شوند. این فایل‌ها شامل پیکربندی‌ها و تنظیمات منابع مختلف مانند Pods، Deployments، Services و غیره هستند. پس از ایجاد این منابع با استفاده از دستور kubectl apply -f، شما می‌توانید آن‌ها را با استفاده از دستور kubectl delete -f حذف کنید.

این روش به‌ویژه زمانی مفید است که شما منابعی را در یک یا چند فایل YAML تعریف کرده باشید و بخواهید به‌طور همزمان تمامی منابع تعریف‌شده در این فایل‌ها را حذف کنید. دستور kubectl delete -f به شما این امکان را می‌دهد که منابع را از فایل YAML حذف کرده و آن‌ها را از کلاستر Kubernetes خود پاک کنید.

---

1. حذف منابع از یک فایل YAML خاص

برای حذف منابع از یک فایل YAML، کافی است نام فایل YAML را به دستور kubectl delete -f بدهید. این دستور تمامی منابعی که در آن فایل YAML تعریف شده‌اند را حذف می‌کند.

فرمت کلی دستور:

kubectl delete -f <نام فایل YAML>

در اینجا:

• <نام فایل YAML> به نام فایل YAML اشاره دارد که منابع آن داخل آن تعریف شده است.

---

2. حذف منابع از چند فایل YAML

شما می‌توانید منابع را از چندین فایل YAML مختلف همزمان حذف کنید. برای این کار، کافی است نام چند فایل YAML را به‌طور جداگانه به دستور kubectl delete -f وارد کنید.

حذف منابع از چند فایل YAML:

kubectl delete -f file1.yaml -f file2.yaml

این دستور تمامی منابع تعریف‌شده در هر دو فایل file1.yaml و file2.yaml را حذف می‌کند.

---

3. حذف منابع از یک دایرکتوری (همه فایل‌های YAML در دایرکتوری)

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

حذف منابع از دایرکتوری:

kubectl delete -f /path/to/directory/

این دستور تمام منابع تعریف‌شده در فایل‌های YAML موجود در دایرکتوری مشخص‌شده را حذف می‌کند.

---

4. حذف منابع از فایل‌های YAML با استفاده از فیلترها

اگر می‌خواهید فقط منابع خاصی را از فایل YAML حذف کنید، می‌توانید از فیلترهای خاصی مانند --selector یا -l برای حذف منابع بر اساس لیبل‌ها استفاده کنید. این کار به شما این امکان را می‌دهد که منابع خاصی را که دارای ویژگی‌های مشخص هستند از فایل YAML حذف کنید.

حذف منابع با استفاده از لیبل از فایل YAML:

kubectl delete -f file.yaml -l app=nginx

در اینجا، فقط منابعی که در فایل file.yaml دارای لیبل app=nginx هستند حذف خواهند شد.

---

5. حذف منابع از فایل YAML با تأیید

همچنین می‌توانید از گزینه --dry-run استفاده کنید تا قبل از اعمال تغییرات، عملیات حذف را شبیه‌سازی کرده و بررسی کنید که چه منابعی حذف خواهند شد.

حذف منابع با dry-run:

kubectl delete -f file.yaml --dry-run

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

---

6. حذف منابع از فایل YAML با استفاده از گزینه force و grace-period

در صورتی که بخواهید منابع را فوراً حذف کنید بدون اینکه مدت زمان مهلت (grace period) برای حذف تعیین شود، می‌توانید از گزینه‌های --force و --grace-period=0 استفاده کنید.

حذف فوری منابع از فایل YAML:

kubectl delete -f file.yaml --force --grace-period=0

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

---

7. حذف منابع با استفاده از namespace در فایل YAML

اگر منابعی که می‌خواهید حذف کنید در یک نام‌فضای خاص هستند، می‌توانید از گزینه --namespace برای مشخص کردن نام‌فضای مورد نظر استفاده کنید.

حذف منابع از فایل YAML در یک Namespace خاص:

kubectl delete -f file.yaml --namespace=my-namespace

در اینجا، فقط منابعی که در فایل file.yaml و در نام‌فضای my-namespace قرار دارند حذف می‌شوند.

---

جمع‌بندی

دستور kubectl delete -f یکی از روش‌های بسیار مفید برای حذف منابع از کلاستر Kubernetes است که از فایل‌های YAML به‌عنوان ورودی استفاده می‌کند. این دستور به شما این امکان را می‌دهد که به‌طور همزمان و به‌صورت گروهی منابع مختلف را که در یک یا چند فایل YAML تعریف شده‌اند حذف کنید. همچنین شما می‌توانید این دستور را به‌طور دقیق‌تر با استفاده از فیلترها، گزینه‌های تأیید، و حذف فوری منابع برای شرایط خاص سفارشی کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 2. مشاهده و مدیریت منابع”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl get برای مشاهده منابع مختلف (Pods، Nodes، Deployments و …)” subtitle=”توضیحات کامل”]در Kubernetes، دستور kubectl get یکی از پرکاربردترین و ابتدایی‌ترین دستورات است که برای مشاهده و بررسی وضعیت منابع مختلف در کلاستر استفاده می‌شود. این دستور اطلاعات کاملی درباره منابع مختلف مانند Pods، Nodes، Deployments، Services، ReplicaSets و غیره را به‌صورت جدول یا سایر فرمت‌ها نمایش می‌دهد.

---

1. مشاهده Pods

برای مشاهده لیست تمام Pods موجود در کلاستر Kubernetes، می‌توانید از دستور kubectl get pods استفاده کنید. این دستور وضعیت Pods را نمایش می‌دهد که شامل نام، وضعیت، زمان ایجاد و اطلاعات بیشتر است.

فرمت کلی دستور:

kubectl get pods

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

مشاهده Pods در یک namespace خاص:

kubectl get pods --namespace=my-namespace

---

2. مشاهده Nodes

برای مشاهده وضعیت و اطلاعات مربوط به Nodes در کلاستر، از دستور kubectl get nodes استفاده می‌شود. این دستور اطلاعاتی نظیر نام Node، وضعیت آن، نسخه Kubernetes، و ظرفیت منابع را نمایش می‌دهد.

فرمت کلی دستور:

kubectl get nodes

با این دستور، تمامی Nodes موجود در کلاستر شما نمایش داده می‌شود.

---

3. مشاهده Deployments

برای مشاهده اطلاعات مربوط به Deployments در Kubernetes، از دستور kubectl get deployments استفاده می‌شود. این دستور اطلاعاتی از قبیل تعداد Replica‌ها، وضعیت فعلی و تعداد Pods در هر Deployment را نمایش می‌دهد.

فرمت کلی دستور:

kubectl get deployments

شما همچنین می‌توانید Deployments یک namespace خاص را با استفاده از گزینه --namespace مشاهده کنید.

مشاهده Deployments در یک namespace خاص:

kubectl get deployments --namespace=my-namespace

---

4. مشاهده Services

برای مشاهده اطلاعات مربوط به Services در کلاستر، از دستور kubectl get services یا kubectl get svc استفاده می‌شود. این دستور اطلاعاتی از قبیل نام Service، نوع آن، IP، و پورت‌های در دسترس را نمایش می‌دهد.

فرمت کلی دستور:

kubectl get services

همچنین، مانند سایر منابع، می‌توانید Services یک namespace خاص را نیز مشاهده کنید.

مشاهده Services در یک namespace خاص:

kubectl get services --namespace=my-namespace

---

5. مشاهده ReplicaSets

برای مشاهده وضعیت و اطلاعات مربوط به ReplicaSets، از دستور kubectl get replicasets استفاده می‌شود. این دستور اطلاعاتی از قبیل تعداد Pod‌های در حال اجرا و تعداد Pod‌های مورد نیاز برای هر ReplicaSet را نمایش می‌دهد.

فرمت کلی دستور:

kubectl get replicasets

---

6. مشاهده PersistentVolumes (PV)

برای مشاهده وضعیت Persistent Volumes در کلاستر، از دستور kubectl get pv استفاده می‌شود. این دستور اطلاعاتی از قبیل وضعیت، ظرفیت و استفاده از هر PersistentVolume را نشان می‌دهد.

فرمت کلی دستور:

kubectl get pv

---

7. مشاهده ConfigMaps

برای مشاهده اطلاعات مربوط به ConfigMaps که برای ذخیره‌سازی پیکربندی‌ها و داده‌های غیر حساس استفاده می‌شوند، از دستور kubectl get configmaps استفاده می‌شود.

فرمت کلی دستور:

kubectl get configmaps

---

8. مشاهده Secrets

برای مشاهده اطلاعات مربوط به Secrets که شامل داده‌های حساس (مثل رمز عبور یا توکن‌ها) است، از دستور kubectl get secrets استفاده می‌شود. البته باید توجه داشته باشید که داده‌های حساس به صورت پیش‌فرض به صورت رمزنگاری‌شده نمایش داده می‌شوند.

فرمت کلی دستور:

kubectl get secrets

---

9. استفاده از فیلترها برای مشاهده منابع خاص

دستور kubectl get این امکان را به شما می‌دهد که منابع خاصی را بر اساس فیلترهای مختلف جستجو کنید. به عنوان مثال، می‌توانید منابع را بر اساس لیبل یا نام خاص فیلتر کنید.

مشاهده منابع با لیبل خاص:

kubectl get pods -l app=nginx

در این مثال، فقط Pods‌هایی که دارای لیبل app=nginx هستند نمایش داده می‌شوند.

---

10. استفاده از فرمت‌های خروجی مختلف

شما می‌توانید از پارامترهای -o برای تنظیم فرمت خروجی دستور kubectl get استفاده کنید. به‌طور پیش‌فرض، خروجی به‌صورت جدول است، اما می‌توانید آن را به فرمت‌های مختلف مانند YAML، JSON، یا Wide تغییر دهید.

خروجی به فرمت YAML:

kubectl get pods -o yaml

خروجی به فرمت JSON:

kubectl get pods -o json

خروجی به فرمت Wide:

kubectl get pods -o wide

فرمت wide اطلاعات بیشتری مانند IP‌های Pod و Node‌ها را نشان می‌دهد.

---

11. مشاهده منابع با جزئیات بیشتر

در صورت نیاز به اطلاعات بیشتر از منابع، می‌توانید از دستور kubectl describe استفاده کنید. این دستور اطلاعات دقیق‌تری درباره وضعیت و پیکربندی منابع خاص مانند Pods، Deployments یا Services ارائه می‌دهد.

---

جمع‌بندی

دستور kubectl get ابزاری بسیار قدرتمند و کاربردی در Kubernetes است که به شما امکان می‌دهد تا وضعیت و اطلاعات مربوط به منابع مختلف کلاستر خود را مشاهده کنید. این دستور برای نظارت و مدیریت منابع در کلاستر Kubernetes استفاده می‌شود و می‌توان آن را برای مشاهده Pods، Nodes، Deployments، Services، ReplicaSets و دیگر منابع استفاده کرد. همچنین با استفاده از پارامترهای مختلف مانند -o می‌توانید خروجی را در فرمت‌های مختلفی مشاهده کنید و با استفاده از فیلترها منابع خاص را جستجو کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”فیلتر کردن خروجی‌ها با o- (مانند o json- یا o wide-)” subtitle=”توضیحات کامل”]در Kubernetes، هنگامی که از دستور kubectl get برای مشاهده منابع استفاده می‌کنید، به‌طور پیش‌فرض خروجی به صورت جدول (Table) نمایش داده می‌شود. با این حال، ممکن است بخواهید اطلاعات بیشتری یا جزئیات خاص‌تری در مورد منابع به‌دست آورید. در چنین مواقعی می‌توانید از گزینه -o (Output) برای تغییر فرمت خروجی استفاده کنید.

این گزینه به شما این امکان را می‌دهد که داده‌ها را در فرمت‌های مختلفی مانند yaml، json، wide و حتی custom-columns دریافت کنید.

---

1. استفاده از o json-

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

فرمت کلی دستور:

kubectl get pods -o json

در این حالت، خروجی به صورت یک شیء JSON که تمام جزئیات مربوط به Pods را شامل می‌شود، نمایش داده می‌شود.

مثال خروجی:

{
  "apiVersion": "v1",
  "items": [
    {
      "metadata": {
        "name": "nginx-pod",
        "namespace": "default",
        ...
      },
      "spec": {
        "containers": [
          {
            "name": "nginx",
            "image": "nginx:latest",
            ...
          }
        ]
      },
      "status": {
        "phase": "Running",
        ...
      }
    }
  ]
}

---

2. استفاده از o wide-

فرمت wide برای مشاهده اطلاعات تکمیلی و اضافه در مورد منابع (مانند Pods) کاربرد دارد. در این فرمت، شما اطلاعات بیشتری مانند IP داخلی هر Pod، Node‌ای که Pod روی آن اجرا می‌شود و سایر ویژگی‌های شبکه‌ای را دریافت خواهید کرد.

فرمت کلی دستور:

kubectl get pods -o wide

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

مثال خروجی:

NAME         READY   STATUS    RESTARTS   AGE   IP            NODE         NOMINATED NODE
nginx-pod    1/1     Running   0          10m   10.244.1.5    node-01      <none>

---

3. استفاده از o yaml-

اگر بخواهید خروجی را به صورت YAML دریافت کنید، می‌توانید از گزینه -o yaml استفاده کنید. YAML به‌طور کلی بیشتر برای پیکربندی‌ها و ذخیره‌سازی منابع در Kubernetes استفاده می‌شود.

فرمت کلی دستور:

kubectl get pods -o yaml

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

مثال خروجی:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  namespace: default
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80
status:
  phase: Running
  podIP: 10.244.1.5
  startTime: "2025-02-09T12:00:00Z"

---

4. استفاده از o custom-columns-

با استفاده از -o custom-columns، می‌توانید خروجی را به صورت دلخواه با انتخاب ستون‌های خاص نمایش دهید. این ویژگی به شما این امکان را می‌دهد که تنها اطلاعات مورد نظر خود را مشاهده کنید.

فرمت کلی دستور:

kubectl get pods -o custom-columns="NAME:.metadata.name,STATUS:.status.phase"

در این دستور، فقط نام و وضعیت (Status) هر Pod نمایش داده می‌شود.

مثال خروجی:

NAME         STATUS
nginx-pod    Running

---

5. استفاده از o=jsonpath-

اگر می‌خواهید یک بخش خاص از داده‌ها را در فرمت JSON استخراج کنید، می‌توانید از -o=jsonpath استفاده کنید. این روش مشابه به استفاده از JQ در JSON است و به شما این امکان را می‌دهد که بخش‌های خاصی از داده‌ها را استخراج کنید.

فرمت کلی دستور:

kubectl get pods -o=jsonpath='{.items[0].metadata.name}'

این دستور تنها نام اولین Pod را برمی‌گرداند.

مثال خروجی:

nginx-pod

---

6. استفاده از o=wide- برای سرویس‌ها

همچنین، برای مشاهده اطلاعات تکمیلی در مورد منابع دیگری مانند Services، از o wide- استفاده می‌شود. در این صورت می‌توانید اطلاعات بیشتری از منابع سرویس‌ها مانند IP‌های Cluster و Node‌های مورد استفاده را مشاهده کنید.

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

kubectl get services -o wide

---

جمع‌بندی

استفاده از گزینه o- در دستور kubectl get این امکان را به شما می‌دهد که داده‌های خروجی را در فرمت‌های مختلف مشاهده کنید. این ویژگی برای تحلیل دقیق‌تر منابع بسیار مفید است. فرمت‌های رایج شامل json، yaml، wide و custom-columns هستند که هرکدام ویژگی‌های خاص خود را دارند و به شما کمک می‌کنند تا اطلاعات مورد نظر را سریع‌تر و کارآمدتر دریافت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl describe برای مشاهده جزئیات منابع” subtitle=”توضیحات کامل”]دستور kubectl describe یکی از پرکاربردترین ابزارهای خط فرمان Kubernetes است که برای دریافت جزئیات دقیق و اطلاعات کامل در مورد منابع مختلف مانند Pods، Deployments، Services و سایر منابع Kubernetes استفاده می‌شود. این دستور، اطلاعاتی به‌طور جامع از وضعیت یک منبع خاص، پیکربندی‌ها، رویدادها (Events)، و حتی پیام‌های خطا را ارائه می‌دهد.

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

برای مشاهده جزئیات یک منبع خاص از دستور kubectl describe استفاده می‌کنیم. این دستور می‌تواند برای انواع مختلف منابع مانند Pods، Deployments، ReplicaSets، Namespaces، و بسیاری دیگر به‌کار رود.

مثال‌ها:

1. مشاهده جزئیات یک Pod خاص:

   kubectl describe pod <pod-name> -n <namespace>
   

2. مشاهده جزئیات یک Deployment:

   kubectl describe deployment <deployment-name> -n <namespace>
   

3. مشاهده جزئیات یک Service:

   kubectl describe service <service-name> -n <namespace>
   

توضیحات و اطلاعات دریافتی

زمانی که دستور kubectl describe اجرا می‌شود، خروجی شامل اطلاعات زیر می‌شود:

• Metadata: شامل نام، namespace، لیبل‌ها، و annotations مربوط به منبع.
• Spec: شامل تنظیمات پیکربندی برای آن منبع مانند تعداد تکرارها، انتخابگرها (selectors)، و منابع تعریف‌شده.
• Status: وضعیت فعلی منبع از جمله تعداد پادها در حال اجرا، در حال آماده بودن، و وضعیت کلی منابع.
• Events: یک لیست از رویدادهای مرتبط با منبع که می‌تواند شامل هشدارها، خطاها، و تغییرات وضعیت باشد.

مثال عملی: مشاهده جزئیات یک Pod

فرض کنید می‌خواهید جزئیات مربوط به یک Pod خاص را بررسی کنید. برای این کار دستور زیر را وارد می‌کنید:

kubectl describe pod my-pod -n default

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

Name:           my-pod
Namespace:      default
Priority:       0
Node:           node-1/192.168.1.2
Start Time:     Mon, 08 Feb 2025 10:00:00 +0000
Labels:         app=my-app
                environment=prod
Annotations:    kubernetes.io/created-by=...
Status:         Running
IP:             10.244.1.2
Containers:
  my-container:
    Container ID:   docker://abcdef123456
    Image:          my-image:v1
    Port:           8080/TCP
    State:          Running
    Ready:          True
    Restart Count:  0
    Environment:    <none>
    Mounts:
      /data from my-data-volume (rw)
      /config from my-config-volume (ro)
Conditions:
  Type              Status
  Initialized       True
  Ready             True
  ContainersReady   True
  PodScheduled      True
Events:
  Type    Reason     Age   From               Message
  ----    ------     ----  ----               -------
  Normal  Scheduled  10m   default-scheduler  Successfully assigned default/my-pod to node-1
  Normal  Pulling    9m    kubelet, node-1    Pulling image "my-image:v1"
  Normal  Pulled     8m    kubelet, node-1    Successfully pulled image "my-image:v1"
  Normal  Created    8m    kubelet, node-1    Created container my-container
  Normal  Started    8m    kubelet, node-1    Started container my-container

کاربردهای دیگر

• بررسی رویدادهای خطایابی
• مشاهده وضعیت منابع در زمان واقعی
• بررسی دلایل خرابی Pod یا دیگر منابع
• بررسی جزئیات تنظیمات و منابع در فایل‌های پیکربندی

جمع‌بندی

دستور kubectl describe ابزار قدرتمندی است که می‌تواند به شما در شناسایی مشکلات و مشاهده جزئیات دقیق هر منبع Kubernetes کمک کند. با استفاده از این دستور می‌توان به سرعت وضعیت منابع را بررسی کرده و از اطلاعات دقیق آن‌ها برای رفع مشکلات یا بهبود عملکرد منابع استفاده کرد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl top برای مشاهده مصرف منابع (CPU و Memory)” subtitle=”توضیحات کامل”]دستور kubectl top یکی از ابزارهای کاربردی در Kubernetes است که برای مشاهده مصرف منابع مختلف (مانند CPU و Memory) در Podها و Nodeها به کار می‌رود. این دستور به شما این امکان را می‌دهد تا وضعیت و مصرف منابع در زمان واقعی را برای بررسی و تحلیل به دست آورید. به ویژه زمانی که با مشکلاتی مانند مصرف بیش از حد منابع یا عملکرد پایین سرویس‌ها مواجه هستید، این ابزار می‌تواند به شما کمک کند تا منابع مصرفی را شناسایی کنید.

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

دستور kubectl top به شما این امکان را می‌دهد که به سرعت از وضعیت منابع مصرفی در Kubernetes مطلع شوید. این دستور می‌تواند برای مشاهده مصرف منابع در Podها، Nodeها و حتی Containerهای داخل Podها استفاده شود.

1. مشاهده مصرف منابع در Nodeها: برای مشاهده مصرف منابع (CPU و حافظه) در تمامی Nodeهای کلاستر، از دستور زیر استفاده می‌شود:

kubectl top nodes

این دستور به شما اطلاعاتی مانند مصرف CPU و حافظه کل در هر Node را می‌دهد. خروجی به شکل زیر خواهد بود:

NAME           CPU(cores)   MEMORY(bytes)
node-1         1.5 (75%)    4Gi (50%)
node-2         2 (100%)    8Gi (80%)

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

kubectl top pods -n <namespace>

خروجی این دستور مصرف منابع هر Pod را به شما نشان خواهد داد:

NAME           CPU(cores)   MEMORY(bytes)
my-pod-1       250m (12%)   500Mi (30%)
my-pod-2       100m (5%)    200Mi (10%)

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

kubectl top pod <pod-name> -n <namespace>

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

4. مشاهده مصرف منابع برای Containers داخل Podها: می‌توانید مصرف منابع را برای هر Container خاص در داخل یک Pod بررسی کنید:

kubectl top pod <pod-name> --containers -n <namespace>

این دستور می‌تواند برای تشخیص مصرف منابع در سطح کانتینرها به شما کمک کند.

اطلاعات خروجی

خروجی دستور kubectl top به شما اطلاعاتی در مورد مصرف منابع (CPU و Memory) در قالب زیر می‌دهد:

• CPU(cores): میزان مصرف CPU در هسته‌ها (Cores). واحد اندازه‌گیری می‌تواند به صورت درصد یا هسته‌های اختصاصی باشد. به عنوان مثال، 100m برابر با 0.1 هسته CPU است.
• MEMORY(bytes): میزان مصرف حافظه به واحد بایت (می‌توان به صورت مگابایت یا گیگابایت هم نمایش داده شود).

کاربردهای دیگر

• شناسایی منابع پرمصرف: از دستور kubectl top برای شناسایی Podهایی که بیشترین مصرف CPU یا حافظه را دارند، استفاده می‌شود.
• تحلیل عملکرد: بررسی مصرف منابع می‌تواند به شما در تحلیل عملکرد کلاستر و اطمینان از سلامت آن کمک کند.
• مشخص کردن مشکلات: اگر مصرف منابع به طور غیرعادی بالا باشد، می‌توان از این ابزار برای شناسایی مشکلات و اعمال محدودیت‌های مناسب استفاده کرد.

جمع‌بندی

دستور kubectl top ابزاری ساده اما قدرتمند است که می‌تواند به شما کمک کند تا در زمان واقعی مصرف منابع (CPU و حافظه) در Podها، Nodeها و Containers را مشاهده کنید. این ابزار به ویژه زمانی که نیاز به تحلیل عملکرد سیستم دارید یا به دنبال شناسایی منابع پرمصرف هستید، می‌تواند مفید واقع شود.[/cdb_course_lesson][cdb_course_lesson title=”فصل 3. مدیریت Namespace‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مشاهده Namespace‌های موجود با kubectl get namespaces” subtitle=”توضیحات کامل”]در کوبرنتیز، Namespace‌ها به شما این امکان را می‌دهند که منابع مختلف مانند Pods، Services، Deployments و سایر منابع را به صورت منطقی و جداگانه از یکدیگر سازماندهی کنید. این قابلیت به‌ویژه در کلاسترهای بزرگ که ممکن است منابع زیادی وجود داشته باشد، بسیار مفید است. دستور kubectl get namespaces به شما این امکان را می‌دهد که لیستی از تمامی Namespace‌های موجود در کلاستر را مشاهده کنید.

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

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

kubectl get namespaces

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

خروجی مثال:

NAME              STATUS   AGE
default           Active   10d
kube-system       Active   10d
kube-public       Active   10d
my-namespace      Active   2d

جزئیات خروجی

• NAME: نام Namespace.
• STATUS: وضعیت Namespace (معمولاً Active).
• AGE: مدت زمانی که از ایجاد Namespace می‌گذرد.

مشاهده Namespace‌های خاص

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

برای مشاهده جزئیات یک Namespace خاص:

kubectl get namespace <namespace-name>

مثلاً برای مشاهده جزئیات my-namespace:

kubectl get namespace my-namespace

خروجی مشابه زیر خواهد بود:

NAME            STATUS   AGE
my-namespace    Active   2d

کاربردهای دستور kubectl get namespaces

1. شناسایی منابع مختلف در Namespace‌های مختلف: زمانی که می‌خواهید منابع را در یک Namespace خاص مشاهده کنید، می‌توانید از این دستور برای پیدا کردن Namespace‌ها استفاده کنید.
2. مدیریت منابع و جداسازی کارها: با استفاده از Namespace‌ها، می‌توانید منابع خود را برای بخش‌های مختلف سازمان یا محیط‌های مختلف (تولید، توسعه، آزمایش) جدا کنید.
3. تحلیل وضعیت منابع: این دستور به شما این امکان را می‌دهد تا وضعیت کلی از Namespace‌ها و منابع داخل آنها را بررسی کنید.

دستور kubectl describe namespace

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

kubectl describe namespace <namespace-name>

این دستور اطلاعات دقیقی مانند انوتیشن‌ها، برچسب‌ها (labels)، و دیگر مشخصات در مورد Namespace خاص را نمایش می‌دهد.

جمع‌بندی

دستور kubectl get namespaces یکی از ابزارهای کلیدی برای مشاهده و مدیریت Namespace‌ها در Kubernetes است. این دستور به شما این امکان را می‌دهد که لیستی از تمامی Namespace‌ها و وضعیت آن‌ها در کلاستر را مشاهده کرده و از آن برای شناسایی، سازماندهی و مدیریت منابع مختلف استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تغییر Namespace پیش‌فرض با kubectl config set-context” subtitle=”توضیحات کامل”]در Kubernetes، هنگام استفاده از دستور kubectl برای کار با منابع، پیش‌فرض این است که دستورها روی Namespace پیش‌فرض (default) اعمال شوند، مگر اینکه به‌طور خاص Namespace دیگری را مشخص کنید. برای راحتی بیشتر و جلوگیری از نیاز به مشخص کردن Namespace در هر دستور، می‌توانید Namespace پیش‌فرض خود را تغییر دهید. این کار با استفاده از دستور kubectl config set-context انجام می‌شود.

نحوه تغییر Namespace پیش‌فرض

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

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

این دستور، Namespace پیش‌فرض را برای کنسول فعلی Kubernetes شما تغییر می‌دهد. به‌طور پیش‌فرض، تنظیمات برای Context جاری اعمال می‌شود.

مثال: برای تغییر Namespace پیش‌فرض به my-namespace:

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

جزئیات دستور

• --current: این گزینه مشخص می‌کند که تغییرات برای context جاری در فایل پیکربندی انجام شود.
• --namespace=<namespace-name>: این گزینه نام Namespace جدید را مشخص می‌کند که می‌خواهید به‌عنوان Namespace پیش‌فرض تنظیم شود.

بررسی تغییر Namespace پیش‌فرض

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

kubectl config view --minify | grep namespace:

این دستور، Namespace پیش‌فرض فعلی را برای context جاری نمایش می‌دهد.

خروجی مثال:

namespace: my-namespace

کاربردها

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

بازنشانی به Namespace پیش‌فرض

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

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

جمع‌بندی

دستور kubectl config set-context یک روش ساده برای تغییر Namespace پیش‌فرض در محیط کاری Kubernetes شما است. با این دستور، می‌توانید به راحتی تنظیمات Namespace را به‌صورت متمرکز تغییر دهید و کار با منابع داخل یک Namespace خاص را تسهیل کنید. این امکان به‌ویژه برای استفاده در محیط‌های بزرگ با چندین Namespace کاربرد دارد.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ایجاد و حذف Namespace‌ها” subtitle=”توضیحات کامل”]Namespace‌ها در Kubernetes یک ابزار مهم برای جداسازی منابع و مدیریت منطقی آن‌ها هستند. با استفاده از Namespace‌ها می‌توان منابع مختلف مانند Pod‌ها، Service‌ها و سایر منابع را در گروه‌های مختلف سازمان‌دهی کرد. این کار برای مدیریت منابع در محیط‌های چندکاربره و یا محیط‌های متعدد Kubernetes ضروری است.

در این بخش، نحوه ایجاد و حذف Namespace‌ها را بررسی خواهیم کرد.

ایجاد Namespace‌ها

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

دستور ایجاد Namespace جدید

kubectl create namespace <namespace-name>

مثال:

برای ایجاد Namespace به نام dev-environment:

kubectl create namespace dev-environment

این دستور Namespace جدیدی به نام dev-environment را در کلاستر Kubernetes شما ایجاد می‌کند.

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

همچنین می‌توان Namespace‌ها را از طریق فایل‌های YAML تعریف و ایجاد کرد. برای این کار، ابتدا باید فایل YAML برای Namespace ایجاد کنید. به عنوان مثال:

apiVersion: v1
kind: Namespace
metadata:
  name: dev-environment

سپس با استفاده از دستور kubectl apply می‌توانید آن را در کلاستر Kubernetes ایجاد کنید:

kubectl apply -f namespace.yaml

این دستور، Namespace جدید را بر اساس فایل namespace.yaml ایجاد می‌کند.

حذف Namespace‌ها

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

دستور حذف Namespace

kubectl delete namespace <namespace-name>

مثال:

برای حذف Namespace به نام dev-environment:

kubectl delete namespace dev-environment

توجه داشته باشید که پس از اجرای این دستور، تمامی منابع داخل آن Namespace (از جمله Pod‌ها، Service‌ها و سایر منابع) حذف خواهند شد.

بررسی وضعیت Namespace‌ها

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

kubectl get namespaces

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

بررسی جزئیات یک Namespace

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

kubectl describe namespace <namespace-name>

مثال:

برای مشاهده جزئیات Namespace dev-environment:

kubectl describe namespace dev-environment

این دستور، اطلاعات بیشتری در مورد Namespace از جمله وضعیت آن، منابع و برچسب‌ها (labels) ارائه می‌دهد.

جمع‌بندی

Namespace‌ها ابزار قدرتمندی در Kubernetes هستند که برای جداسازی و مدیریت منابع مختلف در کلاستر استفاده می‌شوند. از طریق دستورات kubectl create namespace و kubectl delete namespace می‌توان Namespace‌ها را به راحتی ایجاد یا حذف کرد. همچنین، با استفاده از فایل‌های YAML می‌توان Namespace‌ها را به‌طور برنامه‌نویسی ایجاد کرد. تغییرات در Namespace‌ها می‌تواند به‌طور قابل توجهی نحوه مدیریت منابع و امنیت در یک کلاستر Kubernetes را بهبود بخشد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 4. بررسی و Debugging”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی وضعیت Pods با kubectl logs” subtitle=”توضیحات کامل”]برای بررسی وضعیت Pods در Kubernetes، یکی از ابزارهای اصلی استفاده از دستور kubectl logs است. این دستور به شما این امکان را می‌دهد که لاگ‌های یک یا چند کانتینر درون یک Pod را مشاهده کنید. در ادامه به جزئیات استفاده از این دستور پرداخته می‌شود.

مشاهده لاگ‌های یک Pod

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

kubectl logs <pod-name>

در اینجا pod-name نام Pod مورد نظر است. این دستور لاگ‌های مربوط به اولین کانتینر درون Pod را نمایش می‌دهد.

مشاهده لاگ‌های کانتینر خاص در Pod

اگر Pod شما چندین کانتینر داشته باشد و بخواهید لاگ‌های کانتینر خاصی را مشاهده کنید، می‌توانید نام کانتینر را با استفاده از پارامتر -c مشخص کنید:

kubectl logs <pod-name> -c <container-name>

این دستور فقط لاگ‌های کانتینر مورد نظر را نمایش خواهد داد.

مشاهده لاگ‌ها در یک Namespace خاص

اگر Pod شما در یک Namespace خاص قرار دارد، باید با استفاده از پارامتر -n آن Namespace را مشخص کنید:

kubectl logs <pod-name> -n <namespace-name>

مشاهده لاگ‌ها برای چندین Pod

اگر می‌خواهید لاگ‌های چندین Pod را که در حال اجرا هستند مشاهده کنید، می‌توانید از پارامتر --selector برای فیلتر کردن Pods بر اساس Label استفاده کنید:

kubectl logs -l <label-selector> --all-containers=true

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

مشاهده لاگ‌ها به‌صورت real-time (Follow Mode)

برای مشاهده لاگ‌ها به‌صورت زنده و در زمان واقعی (Follow Mode)، می‌توانید از پارامتر -f استفاده کنید:

kubectl logs -f <pod-name>

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

مشاهده لاگ‌های قدیمی‌تر

اگر می‌خواهید لاگ‌های قبلی یک Pod که ممکن است به دلایلی دوباره راه‌اندازی شده باشد را مشاهده کنید، می‌توانید از پارامتر --previous استفاده کنید:

kubectl logs <pod-name> --previous

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

جمع‌بندی

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

استفاده از دستور kubectl logs با –all-containers

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

kubectl logs <pod-name> --all-containers=true

در اینجا:

• <pod-name> نام Pod مورد نظر شماست.
• --all-containers=true به Kubernetes می‌گوید که لاگ‌های تمام کانتینرهای موجود در Pod را نمایش دهد.

این دستور برای Pod‌هایی که دارای چندین کانتینر هستند، می‌تواند بسیار مفید باشد زیرا تمام لاگ‌ها را در یک نگاه به شما نمایش می‌دهد.

مشاهده لاگ‌های تمامی کانتینرها در Namespace خاص

اگر Pod شما در یک Namespace خاص قرار دارد، می‌توانید با استفاده از پارامتر -n همانند دستورهای قبلی، Namespace را مشخص کنید:

kubectl logs <pod-name> --all-containers=true -n <namespace-name>

مشاهده لاگ‌ها برای تمام Pods با یک Label خاص

اگر بخواهید لاگ‌های تمامی کانتینرها در Pods که با یک Label خاص برچسب‌گذاری شده‌اند را مشاهده کنید، می‌توانید از گزینه -l به‌همراه --all-containers استفاده کنید:

kubectl logs -l <label-selector> --all-containers=true

جمع‌بندی

استفاده از پارامتر --all-containers در دستور kubectl logs به شما این امکان را می‌دهد که لاگ‌های تمامی کانتینرها را به‌صورت یکجا مشاهده کنید. این ویژگی در مواقعی که Pod شما دارای چندین کانتینر باشد، بسیار کاربردی است و به شما کمک می‌کند تا به سرعت مشکل را شناسایی و حل کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl exec برای اجرای دستورات در داخل کانتینرها” subtitle=”توضیحات کامل”]دستور kubectl exec به شما این امکان را می‌دهد که به‌طور مستقیم به داخل کانتینر یک Pod وارد شده و دستورات مختلف را در آن اجرا کنید. این قابلیت به‌ویژه برای عیب‌یابی، مشاهده وضعیت کانتینر یا اجرای دستورات مدیریت سیستم در داخل کانتینر مفید است.

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

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

kubectl exec <pod-name> -- <command>

در اینجا:

• <pod-name> نام Podی است که می‌خواهید به آن وارد شوید.
• <command> دستور مورد نظر شماست که می‌خواهید در داخل کانتینر اجرا کنید.

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

kubectl exec <pod-name> -- ls

اجرای دستورات در کانتینر خاص در یک Pod چند کانتینری

اگر Pod شما شامل چند کانتینر باشد، باید مشخص کنید که دستور مورد نظر در کدام کانتینر اجرا شود. برای این کار از گزینه -c استفاده می‌کنید:

kubectl exec <pod-name> -c <container-name> -- <command>

در اینجا:

• <container-name> نام کانتینری است که می‌خواهید دستور را در آن اجرا کنید.

مثال: اگر بخواهید در کانتینری به نام nginx-container در داخل Pod my-pod دستور ls را اجرا کنید، دستور به شکل زیر خواهد بود:

kubectl exec my-pod -c nginx-container -- ls

ورود به یک کانتینر به‌صورت تعاملی

اگر بخواهید وارد یک کانتینر شده و به‌صورت تعاملی کار کنید (مثلاً یک شل داخل کانتینر باز کنید)، می‌توانید از گزینه -it به‌همراه دستور exec استفاده کنید:

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

یا در صورتی که کانتینر شما از شل دیگری استفاده می‌کند (مثل sh):

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

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

بررسی وضعیت درون کانتینر

شما می‌توانید برای بررسی وضعیت درون کانتینر (مثلاً مشاهده فایل‌ها، پیکربندی‌ها، یا سرویس‌ها) از kubectl exec استفاده کنید. به عنوان مثال، برای مشاهده اطلاعات پیکربندی شبکه داخل کانتینر می‌توانید دستور زیر را وارد کنید:

kubectl exec <pod-name> -- ifconfig

جمع‌بندی

دستور kubectl exec ابزاری قدرتمند برای تعامل با کانتینرها از طریق خط فرمان است. این دستور به شما این امکان را می‌دهد که دستورات را به‌طور مستقیم در داخل کانتینر اجرا کنید و به‌ویژه برای عیب‌یابی و مدیریت کانتینرها بسیار مفید است. با استفاده از این دستور، شما می‌توانید وارد هر کانتینری در یک Pod شده و به‌طور تعاملی یا غیر تعاملی دستورات مختلف را اجرا کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مشاهده وقایع (Events) با kubectl get events” subtitle=”توضیحات کامل”]دستور kubectl get events یکی از ابزارهای قدرتمند برای مشاهده وقایع (Events) در یک کلاستر Kubernetes است. این وقایع می‌توانند شامل اطلاعات مفیدی از جمله وضعیت منابع، مشکلاتی که در زمان اجرای منابع به وجود آمده‌اند، خطاهای سیستم، و موارد مشابه باشند. با استفاده از این دستور، می‌توانید سریعاً مشکلات و خطاهای موجود در کلاستر خود را شناسایی کنید.

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

برای مشاهده وقایع در Kubernetes از دستور زیر استفاده می‌شود:

kubectl get events

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

• Timestamp: زمان وقوع رویداد
• Type: نوع واقعه (Normal یا Warning)
• Reason: دلیل وقوع واقعه
• Object: منبع یا شی‌ای که این واقعه به آن مربوط است
• Message: پیام توضیحی در مورد واقعه

فیلتر کردن وقایع با استفاده از پارامترهای مختلف

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

1. مشاهده وقایع در یک Namespace خاص: اگر می‌خواهید فقط وقایع مربوط به یک Namespace خاص را مشاهده کنید، می‌توانید از گزینه -n به‌همراه نام Namespace استفاده کنید:

   kubectl get events -n <namespace-name>
   

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

   kubectl get events -o wide
   

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

   kubectl get events --field-selector involvedObject.name=<pod-name>
   

مرتب‌سازی وقایع بر اساس زمان

با استفاده از پارامتر --sort-by می‌توانید وقایع را بر اساس زمان یا دیگر فیلدهای موجود مرتب کنید. این کار به شما کمک می‌کند تا ابتدا جدیدترین یا قدیمی‌ترین وقایع را مشاهده کنید:

kubectl get events --sort-by='.lastTimestamp'

این دستور وقایع را بر اساس زمان وقوع مرتب می‌کند.

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

وقایع Kubernetes می‌توانند به شما کمک کنند تا مشکلاتی مانند:

• مشکلات مربوط به Pod‌ها (مثل CrashLoopBackOff یا ImagePullBackOff)
• مشکلات شبکه
• مشکلات مربوط به دسترسی به منابع
• مشکلات زمان‌بندی (Scheduling) و محدودیت‌های منابع

را شناسایی کنید.

مثال:

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

kubectl get events --field-selector involvedObject.name=my-pod

این خروجی می‌تواند اطلاعاتی مانند پیغام‌هایی از نوع Warning را نشان دهد که به شما می‌گویند چرا Pod شما از کار افتاده است.

جمع‌بندی

دستور kubectl get events ابزاری مهم برای تجزیه و تحلیل وقایع در Kubernetes است. با استفاده از این دستور، می‌توانید به‌سرعت مشکلات موجود در کلاستر خود را شناسایی کرده و اقدامات لازم برای رفع آن‌ها را انجام دهید. قابلیت‌های فیلتر کردن و مرتب‌سازی به شما این امکان را می‌دهند که به‌صورت دقیق‌تری بر وقایع مختلف نظارت داشته باشید و مشکلات را به سرعت برطرف کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی مشکلات منابع با kubectl describe” subtitle=”توضیحات کامل”]دستور kubectl describe یکی از ابزارهای کاربردی برای بررسی وضعیت منابع در Kubernetes است. این دستور به شما امکان می‌دهد تا اطلاعات دقیق و جزئیاتی در مورد هر منبع خاص، مانند Pod‌ها، Deployment‌ها، Services، Nodes و غیره به‌دست آورید. این اطلاعات می‌توانند شامل وضعیت منابع، رویدادها، شرایط کنونی، پیکربندی‌ها و هرگونه پیام خطا یا هشدار باشند. به‌ویژه برای شناسایی مشکلات و دلایل خرابی منابع، kubectl describe بسیار مفید است.

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

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

kubectl describe <resource-type> <resource-name>

در این دستور:

• <resource-type> نوع منبع است (مانند pod، deployment، service، node و غیره)
• <resource-name> نام منبع است که می‌خواهید جزئیات آن را بررسی کنید.

مثال‌های مختلف استفاده از دستور kubectl describe

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

   kubectl describe pod <pod-name>
   

   این دستور اطلاعاتی نظیر وضعیت کانتینرهای داخل Pod، رویدادهای اخیر، مشکلات مربوط به تأمین منابع، شرایط کنونی و موارد دیگر را نشان می‌دهد.

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

   kubectl describe deployment <deployment-name>
   

   این دستور شامل اطلاعاتی نظیر تعداد Replica‌ها، وضعیت Pod‌های در حال اجرا، شرایط و خطاهای مربوط به Deployment است.

3. مشاهده جزئیات یک Service: برای مشاهده اطلاعات دقیق درباره یک Service، از دستور زیر استفاده کنید:

   kubectl describe service <service-name>
   

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

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

   kubectl describe node <node-name>
   

   این دستور اطلاعاتی مانند وضعیت نود، منابع CPU و حافظه، شرایط سلامت و اطلاعات بیشتر درباره پیکربندی نود را نمایش می‌دهد.

بررسی مشکلات منابع با kubectl describe

1. مشاهده وضعیت Pod‌ها و دلایل خرابی: زمانی که یک Pod در وضعیت غیرعادی مانند CrashLoopBackOff یا ImagePullBackOff قرار دارد، دستور kubectl describe pod می‌تواند به شما کمک کند تا دلیل این وضعیت را شناسایی کنید. به‌طور مثال، پیام‌هایی که نشان می‌دهند چرا یک کانتینر قادر به شروع شدن نیست، یا دلیل عدم موفقیت در بارگذاری تصویر (image) را می‌توانید در این دستور مشاهده کنید.
2. مشاهده وضعیت Event‌ها: در خروجی kubectl describe، رویدادهایی (Events) که به‌تازگی در کلاستر شما اتفاق افتاده‌اند، نمایش داده می‌شوند. این رویدادها می‌توانند شامل خطاها، مشکلات زمان‌بندی یا مشکلات مربوط به منابع باشند. با مشاهده این رویدادها، می‌توانید مشکلات مربوط به منابع خود را شناسایی کنید.
3. مشاهده وضعیت شرایط کانتینرها: اگر مشکلی در کانتینرها مانند مصرف زیاد منابع یا خرابی در راه‌اندازی وجود داشته باشد، با استفاده از kubectl describe pod، می‌توانید اطلاعاتی از قبیل وضعیت وضعیت کانتینر، پیام‌های خطا و علت‌هایی که باعث ایجاد مشکل شده است را مشاهده کنید.
4. مشاهده Resource Requests و Limits: در دستور kubectl describe, درخواست منابع (Resource Requests) و محدودیت‌ها (Resource Limits) برای هر کانتینر نمایش داده می‌شود. این اطلاعات می‌توانند به شما کمک کنند تا شناسایی کنید که آیا Pod شما به منابع کافی دسترسی دارد یا نه، یا اینکه ممکن است تنظیمات منابع باعث ایجاد مشکلات در Pod شما شوند.
5. مشاهده وضعیت شبکه و اتصال: اگر مشکلی در ارتباطات شبکه یا سرویس‌ها وجود دارد، kubectl describe می‌تواند به شما کمک کند تا وضعیت شبکه و اتصال‌های موجود را بررسی کنید. برای مثال، شما می‌توانید بررسی کنید که آیا سرویس‌ها و Pod‌ها به‌درستی به هم متصل شده‌اند یا خیر.

فیلتر کردن اطلاعات در خروجی

برای جستجو و فیلتر کردن اطلاعات در خروجی دستور kubectl describe, می‌توانید از ابزارهای خارجی مانند grep یا awk استفاده کنید. این کار به شما کمک می‌کند که اطلاعات دقیقی از جزئیات یک منبع خاص به‌دست آورید. برای مثال:

kubectl describe pod <pod-name> | grep -i "CrashLoopBackOff"

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

جمع‌بندی

دستور kubectl describe ابزاری بسیار مفید برای بررسی جزئیات منابع مختلف در Kubernetes است. با استفاده از این دستور، می‌توانید به‌راحتی مشکلات مختلفی که در منابع مختلف کلاستر شما به‌وجود آمده‌اند، شناسایی کنید و به رفع آن‌ها بپردازید. این دستور همچنین به شما کمک می‌کند تا اطلاعات دقیقی از وضعیت منابع، مشکلات شبکه، وضعیت کانتینرها، و بسیاری موارد دیگر به‌دست آورید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 5. مدیریت فایل‌های YAML”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ایجاد فایل‌های YAML برای منابع Kubernetes” subtitle=”توضیحات کامل”]در Kubernetes، منابع به‌طور معمول از طریق فایل‌های YAML تعریف می‌شوند. این فایل‌ها شامل پیکربندی و تنظیمات منابع مختلف مانند Pod‌ها، Deployment‌ها، Service‌ها، ConfigMap‌ها و غیره هستند. فایل‌های YAML ساختار ساده‌ای دارند که برای تعریف ویژگی‌ها و مقادیر منابع Kubernetes استفاده می‌شود.

قالب پایه فایل‌های YAML

هر فایل YAML که برای منابع Kubernetes استفاده می‌شود، معمولاً دارای سه بخش اصلی است: نوع منبع (kind)، متادیتا (metadata) و مشخصات منابع (spec).

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

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

در اینجا:

• apiVersion نسخه API که برای ارتباط با Kubernetes استفاده می‌شود.
• kind نوع منبع (مثلاً Pod، Deployment، Service و غیره).
• metadata شامل اطلاعات متادیتا مانند نام منبع، برچسب‌ها (labels)، و نام‌گذاری‌های دیگر است.
• spec شامل مشخصات منابع است که برای تعریف دقیق‌تر پیکربندی منبع استفاده می‌شود.

ایجاد فایل‌های YAML برای منابع مختلف

1. تعریف یک Pod

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

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

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

2. تعریف یک Deployment

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

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

در این مثال:

• replicas: 3 مشخص می‌کند که Kubernetes باید 3 نسخه از Pod را در کلاستر اجرا کند.
• selector برای شناسایی و انتخاب Pod‌های مرتبط با این Deployment است.
• template شامل تعریف Pod‌هایی است که تحت این Deployment ایجاد خواهند شد.

3. تعریف یک Service

برای ایجاد یک Service که برای دسترسی به Pod‌ها از طریق شبکه استفاده می‌شود، از فایل YAML زیر استفاده کنید:

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

در اینجا:

• selector مشخص می‌کند که Service به کدام Pod‌ها متصل خواهد شد. این Selector باید با Label‌های Pod‌ها تطابق داشته باشد.
• ports مشخص می‌کند که Service بر روی کدام پورت‌ها در دسترس است.
• type: ClusterIP نشان می‌دهد که این Service فقط در داخل کلاستر Kubernetes در دسترس خواهد بود.

4. تعریف یک ConfigMap

برای تعریف یک ConfigMap که تنظیمات و پیکربندی‌ها را برای Pod‌ها فراهم می‌کند، از فایل YAML زیر استفاده کنید:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-configmap
data:
  my-key: my-value

در این مثال:

• data شامل کلیدها و مقادیر مربوط به پیکربندی است. Pod‌ها می‌توانند این مقادیر را از ConfigMap بارگذاری کنند.

5. تعریف یک Secret

برای تعریف یک Secret که برای ذخیره اطلاعات حساس مانند رمز عبور یا توکن‌ها استفاده می‌شود، از فایل YAML زیر استفاده کنید:

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: bXl1c2Vy  # base64-encoded value
  password: bXlwYXNzd29yZA==  # base64-encoded value

در اینجا:

• data شامل مقادیر رمزنگاری‌شده به صورت base64 است. این مقادیر می‌توانند شامل اطلاعات حساسی مانند توکن‌ها، رمزهای عبور و غیره باشند.

اعتبارسنجی و اعمال فایل‌های YAML

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

kubectl apply -f <file-name>.yaml

این دستور فایل YAML را خوانده و منابع را به کلاستر Kubernetes اضافه یا به‌روزرسانی می‌کند.

همچنین می‌توانید برای بررسی و اعتبارسنجی فایل‌های YAML قبل از اعمال آن‌ها از دستور kubectl apply --dry-run استفاده کنید:

kubectl apply -f <file-name>.yaml --dry-run

استفاده از دستور kubectl get برای مشاهده منابع

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

kubectl get pods
kubectl get services
kubectl get deployments
kubectl get configmap

جمع‌بندی

ایجاد فایل‌های YAML برای منابع Kubernetes یکی از روش‌های رایج و مؤثر برای مدیریت منابع در کلاستر است. این فایل‌ها به شما کمک می‌کنند تا منابع مختلف مانند Pods، Deployments، Services، ConfigMap‌ها و Secrets را به‌طور مشخص و انعطاف‌پذیر پیکربندی کنید. با استفاده از دستور kubectl apply، می‌توانید این منابع را به‌راحتی به کلاستر Kubernetes خود اعمال کرده و آن‌ها را مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”خواندن و ویرایش منابع از فایل‌های YAML” subtitle=”توضیحات کامل”]در Kubernetes، منابع معمولاً با استفاده از فایل‌های YAML تعریف و مدیریت می‌شوند. برای مشاهده، ویرایش و به‌روزرسانی این منابع، می‌توان از دستور kubectl و فایل‌های YAML استفاده کرد. این فرآیند شامل خواندن منابع موجود از کلاستر، ویرایش آن‌ها، و سپس اعمال تغییرات به کلاستر است.

خواندن منابع از کلاستر با kubectl get

برای خواندن منابع از کلاستر و ذخیره آن‌ها در فایل YAML، از دستور kubectl get با گزینه -o yaml استفاده می‌شود. این دستور می‌تواند به شما امکان دهد که وضعیت و پیکربندی منابع را به‌طور کامل مشاهده کنید.

مثال‌ها:

1. خواندن اطلاعات Pod‌ها و ذخیره آن‌ها در فایل YAML:

kubectl get pod <pod-name> -o yaml > pod.yaml

این دستور اطلاعات مربوط به Pod مشخص شده را در فایل pod.yaml ذخیره می‌کند.

2. خواندن اطلاعات تمامی Pod‌ها:

kubectl get pods -o yaml > pods.yaml

این دستور تمام Pod‌های موجود در کلاستر را به‌صورت YAML دریافت کرده و در فایل pods.yaml ذخیره می‌کند.

3. خواندن اطلاعات Deployment‌ها:

kubectl get deployment <deployment-name> -o yaml > deployment.yaml

در این دستور، اطلاعات Deployment مشخص‌شده به‌صورت YAML در فایل deployment.yaml ذخیره می‌شود.

ویرایش فایل YAML

پس از ذخیره کردن فایل YAML برای هر منبع، می‌توانید آن را با ویرایشگر متن خود (مانند vim, nano, VSCode و غیره) باز کرده و تغییرات مورد نظر را اعمال کنید. به‌طور مثال، فرض کنید فایل pod.yaml به شکل زیر است:

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

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

1. تغییر تصویر کانتینر:

spec:
  containers:
    - name: example-container
      image: my-new-image:latest
      ports:
        - containerPort: 80

2. اضافه کردن متغیرهای محیطی:

spec:
  containers:
    - name: example-container
      image: nginx
      ports:
        - containerPort: 80
      env:
        - name: MY_ENV_VAR
          value: "value"

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

اعمال تغییرات با kubectl apply

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

kubectl apply -f <file-name>.yaml

برای مثال، پس از ویرایش فایل pod.yaml، برای اعمال تغییرات به کلاستر از دستور زیر استفاده می‌کنید:

kubectl apply -f pod.yaml

مقایسه منابع قبل و بعد از ویرایش با kubectl diff

قبل از اعمال تغییرات، می‌توانید با استفاده از دستور kubectl diff تغییرات بین پیکربندی فعلی منابع و پیکربندی فایل YAML ویرایش‌شده را مقایسه کنید:

kubectl diff -f <file-name>.yaml

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

حذف منابع از فایل YAML

اگر بخواهید منابعی را که قبلاً با استفاده از فایل YAML ایجاد کرده‌اید حذف کنید، می‌توانید از دستور kubectl delete استفاده کنید:

kubectl delete -f <file-name>.yaml

این دستور منابع موجود در فایل YAML را حذف می‌کند.

استفاده از kubectl edit برای ویرایش منابع

یکی از روش‌های سریع برای ویرایش منابع موجود در کلاستر استفاده از دستور kubectl edit است. این دستور به شما اجازه می‌دهد که مستقیماً پیکربندی منابع را در کلاستر ویرایش کنید بدون نیاز به ذخیره آن‌ها در فایل YAML و سپس اعمال تغییرات.

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

kubectl edit pod <pod-name>

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

جمع‌بندی

خواندن و ویرایش منابع Kubernetes از فایل‌های YAML یک روش قدرتمند برای مدیریت منابع است. با استفاده از دستورات kubectl get، kubectl apply و kubectl diff، شما می‌توانید منابع را از کلاستر دریافت کرده، تغییرات لازم را اعمال کنید و سپس آن‌ها را به‌روزرسانی کنید. علاوه بر این، با استفاده از دستور kubectl edit می‌توانید منابع را مستقیماً در کلاستر ویرایش کنید. این فرآیند به شما این امکان را می‌دهد که به‌راحتی و به‌صورت خودکار منابع مختلف Kubernetes را مدیریت و تنظیم کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl edit برای ویرایش مستقیم منابع” subtitle=”توضیحات کامل”]دستور kubectl edit یک ابزار مفید در Kubernetes است که به شما این امکان را می‌دهد که منابع موجود در کلاستر را به‌صورت مستقیم و از داخل محیط خط فرمان ویرایش کنید، بدون اینکه نیازی به ذخیره فایل YAML و اعمال تغییرات از طریق kubectl apply باشد. این دستور معمولاً برای ویرایش منابعی مانند Pods، Deployments، Services و سایر منابع Kubernetes استفاده می‌شود.

نحوه استفاده از kubectl edit

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

kubectl edit pod <pod-name>

این دستور باعث می‌شود که ویرایشگر متنی پیش‌فرض شما (مانند vi یا nano) باز شود و شما بتوانید منابع را ویرایش کنید. پس از ذخیره تغییرات، Kubernetes به‌طور خودکار تغییرات جدید را اعمال می‌کند.

ویرایش انواع مختلف منابع

1. ویرایش Pod:

برای ویرایش یک Pod خاص، دستور زیر را اجرا کنید:

kubectl edit pod <pod-name>

این دستور فایل YAML پیکربندی Pod را برای شما باز می‌کند و شما می‌توانید تغییرات مورد نظر را اعمال کنید. پس از ذخیره تغییرات، Pod به‌طور خودکار به‌روزرسانی خواهد شد.

2. ویرایش Deployment:

برای ویرایش یک Deployment، از دستور زیر استفاده کنید:

kubectl edit deployment <deployment-name>

با این دستور، می‌توانید پیکربندی Deployment را ویرایش کنید، مثلاً تعداد Replica‌ها، تنظیمات image کانتینر، محیط‌های متغیر و غیره.

3. ویرایش Service:

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

kubectl edit service <service-name>

این دستور به شما امکان می‌دهد تا تنظیمات Service را تغییر دهید، مانند نوع سرویس (ClusterIP، LoadBalancer، NodePort) یا پورت‌های در دسترس.

4. ویرایش ConfigMap:

برای ویرایش یک ConfigMap، دستور زیر را اجرا کنید:

kubectl edit configmap <configmap-name>

این دستور به شما این امکان را می‌دهد که مقادیر و تنظیمات پیکربندی را در ConfigMap به‌طور مستقیم ویرایش کنید.

ویژگی‌های مهم دستور kubectl edit

• ویرایشگر پیش‌فرض: معمولاً kubectl edit از ویرایشگر vi به‌طور پیش‌فرض استفاده می‌کند. اگر شما به ویرایشگر دیگری ترجیح می‌دهید (مانند nano)، می‌توانید متغیر محیطی EDITOR را تنظیم کنید:

  export EDITOR=nano
  kubectl edit pod <pod-name>
  

• اعمال تغییرات به‌صورت آنی: پس از ذخیره تغییرات در ویرایشگر، Kubernetes به‌طور خودکار منابع را به‌روز رسانی کرده و تغییرات اعمال می‌شود. نیازی به اجرای دستور kubectl apply نیست.
• بررسی تاریخچه تغییرات: اگرچه kubectl edit به شما اجازه می‌دهد که منابع را به‌راحتی ویرایش کنید، برای بررسی تاریخچه تغییرات باید از ابزارهایی مانند kubectl get و kubectl describe برای مشاهده جزئیات و وضعیت فعلی منابع استفاده کنید.
• محدودیت‌ها: kubectl edit بیشتر برای ویرایش منابع کوچک و تنظیمات ساده استفاده می‌شود. برای تغییرات پیچیده‌تر، معمولاً استفاده از فایل‌های YAML و دستورات kubectl apply پیشنهاد می‌شود.

مثال‌های عملی

1. ویرایش یک Pod:

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

kubectl edit pod my-app-pod

سپس پیکربندی Pod در ویرایشگر باز می‌شود و می‌توانید تغییرات لازم را اعمال کنید.

2. ویرایش یک Deployment:

برای تغییر تنظیمات Deployment مانند تعداد Replica‌ها یا تغییر تصویر کانتینر، دستور زیر را اجرا کنید:

kubectl edit deployment my-app-deployment

در ویرایشگر، می‌توانید تنظیمات مختلف Deployment را ویرایش کرده و ذخیره کنید.

3. ویرایش یک ConfigMap:

برای تغییر مقادیر در یک ConfigMap:

kubectl edit configmap my-app-config

بعد از ذخیره تغییرات، ConfigMap به‌روزرسانی می‌شود و Pod‌ها یا سرویس‌هایی که از آن استفاده می‌کنند، تغییرات را دریافت خواهند کرد.

نکات مهم

• اگر منابع دارای خطا باشند یا تغییرات اعمال‌شده باعث بروز مشکلاتی شوند، Kubernetes ممکن است خطاهایی را گزارش کند.
• دستور kubectl edit برای تغییرات موقت و سریع مفید است، اما برای تغییرات بزرگ‌تر و پیچیده‌تر، استفاده از فایل‌های YAML و روش‌های معمولی kubectl apply توصیه می‌شود.
• در برخی مواقع، پس از ویرایش، منابع ممکن است مجدداً راه‌اندازی شوند (مانند Pod‌ها یا Deployment‌ها).

جمع‌بندی

دستور kubectl edit یک روش سریع و کارآمد برای ویرایش منابع Kubernetes به‌طور مستقیم است. این ابزار به شما این امکان را می‌دهد که منابع را از داخل محیط خط فرمان ویرایش کرده و تغییرات را به‌سرعت اعمال کنید. برای استفاده مؤثر از این دستور، بهتر است از آن برای تغییرات کوچک و زمان‌بندی شده استفاده کنید و برای تغییرات پیچیده‌تر از روش‌های دیگر مانند فایل‌های YAML بهره ببرید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”اعمال تغییرات با kubectl apply -f” subtitle=”توضیحات کامل”]دستور kubectl apply -f <file> یکی از ابزارهای اصلی و پرکاربرد در Kubernetes برای اعمال تغییرات به منابع است. این دستور به شما این امکان را می‌دهد که تغییرات پیکربندی را از طریق فایل‌های YAML یا JSON به‌طور مستقیم بر روی منابع موجود در کلاستر اعمال کنید.

این روش معمولاً زمانی مفید است که شما منابع را در قالب فایل‌های پیکربندی (YAML یا JSON) دارید و می‌خواهید آن‌ها را به‌روز کنید یا منابع جدیدی ایجاد کنید.

نحوه استفاده از kubectl apply -f

برای اعمال تغییرات با kubectl apply -f <file>, کافی است دستور زیر را اجرا کنید:

kubectl apply -f <file>

در اینجا <file> به نام فایل YAML یا JSON که حاوی پیکربندی منبع است اشاره دارد.

مراحل انجام کار:

1. ایجاد یا ویرایش فایل YAML/JSON: ابتدا باید فایل YAML یا JSON مورد نظر برای منابع Kubernetes (Pod، Deployment، Service، و غیره) را آماده کنید. این فایل معمولاً شامل اطلاعات پیکربندی و تنظیمات مختلف منبع خواهد بود.
2. اعمال تغییرات: با استفاده از دستور kubectl apply -f <file>, Kubernetes پیکربندی جدید را اعمال کرده و منابع را به‌روز می‌کند. اگر منبع قبلاً وجود داشته باشد، تغییرات جدید به آن اعمال می‌شود. اگر منبع وجود نداشته باشد، یک منبع جدید ساخته می‌شود.

مثال‌هایی از استفاده:

1. ایجاد یک Pod از فایل YAML:

فرض کنید یک فایل به نام my-pod.yaml دارید که پیکربندی یک Pod را شامل می‌شود. برای ایجاد یا به‌روزرسانی Pod، دستور زیر را اجرا می‌کنید:

kubectl apply -f my-pod.yaml

2. ایجاد یا به‌روزرسانی یک Deployment:

اگر شما یک فایل YAML به نام my-deployment.yaml دارید که پیکربندی Deployment را مشخص می‌کند، برای ایجاد یا به‌روزرسانی Deployment، از دستور زیر استفاده می‌کنید:

kubectl apply -f my-deployment.yaml

3. ایجاد یا به‌روزرسانی چندین منبع با یک فایل YAML:

شما می‌توانید چندین منبع را در یک فایل YAML ترکیب کنید. برای مثال، فایل my-resources.yaml ممکن است شامل چندین منبع باشد (Pod، Deployment، Service، و غیره). شما می‌توانید همه آن‌ها را به‌طور هم‌زمان با دستور زیر اعمال کنید:

kubectl apply -f my-resources.yaml

4. اعمال تغییرات به منابع در یک دایرکتوری:

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

kubectl apply -f ./path/to/directory/

این دستور همه فایل‌های YAML داخل دایرکتوری مشخص شده را بررسی و اعمال می‌کند.

ویژگی‌های مهم kubectl apply:

1. ایجاد منابع جدید: اگر منبعی که در فایل YAML یا JSON تعریف شده است، هنوز در کلاستر وجود نداشته باشد، kubectl apply آن را ایجاد می‌کند.
2. به‌روزرسانی منابع موجود: اگر منبعی که در فایل YAML یا JSON تعریف شده است، قبلاً در کلاستر موجود باشد، kubectl apply تغییرات را اعمال کرده و منابع موجود را به‌روز می‌کند. این به‌روزرسانی به‌صورت امن انجام می‌شود، به‌طوری‌که تغییرات در منابع بر اساس فایل تعریف‌شده اعمال می‌شود و منابع موجود در کلاستر با تغییرات جدید همگام‌سازی می‌شوند.
3. حفظ تغییرات محلی: اگر شما تغییراتی را در منابع Kubernetes در کلاستر اعمال کرده باشید (مانند تغییر در پارامترهای یک Deployment یا Pod)، Kubernetes با استفاده از kubectl apply تغییرات جدید را اعمال می‌کند و تغییرات قبلی در منابع حفظ می‌شود.
4. تاریخچه منابع: زمانی که از kubectl apply استفاده می‌کنید، Kubernetes به‌طور خودکار تاریخچه تغییرات منابع را نگهداری می‌کند. بنابراین، می‌توانید تغییرات قبلی را بازیابی کنید.
5. کاربرد برای منابع پیچیده: kubectl apply به‌ویژه برای مدیریت منابع پیچیده و پایدار Kubernetes مانند Deployments و StatefulSets که نیاز به به‌روزرسانی تدریجی و بدون قطعی دارند بسیار مفید است.

نکات و بهینه‌سازی‌ها:

• استفاده از kubectl apply برای به‌روزرسانی تدریجی: این دستور به شما این امکان را می‌دهد که تغییرات را به‌طور تدریجی و بدون ایجاد مشکلات قطعی بر روی سرویس‌ها اعمال کنید. مثلاً اگر یک Deployment را به‌روز رسانی کنید، Kubernetes به‌طور خودکار ReplicaSet‌های جدید را ایجاد کرده و نسخه‌های قدیمی را حذف می‌کند.
• هماهنگی با GitOps: روش‌های GitOps مانند استفاده از ابزارهایی مانند ArgoCD یا Flux می‌توانند از kubectl apply برای به‌روزرسانی منابع در کلاستر استفاده کنند. این روش از فایل‌های YAML برای نگهداری وضعیت منابع استفاده می‌کند و به‌طور خودکار تغییرات را در کلاستر اعمال می‌کند.
• نسخه‌بندی منابع: برای داشتن کنترل دقیق‌تر بر تغییرات منابع، بهتر است که هر بار تغییراتی را که در فایل YAML اعمال می‌کنید، با استفاده از نسخه‌بندی مناسب (مثلاً Git) ذخیره کنید. این کار کمک می‌کند که به راحتی بتوانید تغییرات را پیگیری و مدیریت کنید.

جمع‌بندی

دستور kubectl apply -f <file> یکی از ابزارهای اصلی Kubernetes برای اعمال تغییرات به منابع است. این دستور به‌طور خودکار منابع را ایجاد یا به‌روز می‌کند و امکان مدیریت منابع را به‌صورت ایمن و قابل پیش‌بینی فراهم می‌آورد. به کمک این دستور می‌توانید منابع مختلف Kubernetes را با استفاده از فایل‌های YAML یا JSON به‌طور مستقیم اعمال و به‌روز کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”بررسی وضعیت منابع تعریف‌شده در YAML با kubectl get -f” subtitle=”توضیحات کامل”]دستور kubectl get -f <file> به شما این امکان را می‌دهد که وضعیت منابع تعریف‌شده در فایل‌های YAML یا JSON را مشاهده کنید. این ابزار به‌طور خاص برای بررسی منابعی که قبلاً از طریق فایل‌های پیکربندی ایجاد شده‌اند استفاده می‌شود و به شما کمک می‌کند تا ببینید که منابع در حال حاضر در کلاستر چه وضعیتی دارند.

نحوه استفاده از kubectl get -f <file>

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

kubectl get -f <file>

در این دستور، <file> به مسیر و نام فایل YAML یا JSON اشاره دارد که منابع Kubernetes در آن تعریف شده است.

توضیحات بیشتر:

• این دستور اطلاعاتی مانند نام، وضعیت، تعداد پادها (Pods)، تعداد ReplicaSet‌ها، و وضعیت دیگر منابع را نمایش می‌دهد.
• شما می‌توانید این دستور را برای مشاهده وضعیت یک یا چند منبع استفاده کنید.

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

1. بررسی وضعیت یک Pod از فایل YAML:

اگر شما یک فایل YAML به نام my-pod.yaml دارید که یک Pod را تعریف می‌کند، می‌توانید با استفاده از دستور زیر وضعیت آن را بررسی کنید:

kubectl get -f my-pod.yaml

این دستور اطلاعات مربوط به Pod موجود در فایل my-pod.yaml را در کلاستر نمایش خواهد داد.

2. بررسی وضعیت چندین منبع از یک فایل YAML:

اگر فایل YAML شما شامل چندین منبع مانند Pod، Deployment و Service باشد، می‌توانید از دستور زیر برای بررسی وضعیت همه منابع در آن فایل استفاده کنید:

kubectl get -f my-resources.yaml

این دستور وضعیت تمام منابع تعریف‌شده در فایل my-resources.yaml را به نمایش می‌گذارد.

3. مشاهده وضعیت منابع از یک دایرکتوری:

اگر شما مجموعه‌ای از فایل‌های YAML دارید که منابع مختلف Kubernetes را تعریف می‌کنند و می‌خواهید وضعیت همه آن‌ها را بررسی کنید، می‌توانید از دایرکتوری حاوی این فایل‌ها استفاده کنید:

kubectl get -f ./path/to/directory/

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

ویژگی‌های kubectl get -f:

1. نمایش وضعیت فعلی منابع: این دستور به شما اجازه می‌دهد که وضعیت فعلی منابع در کلاستر را بر اساس فایل‌های YAML یا JSON مشاهده کنید. به‌عنوان مثال، می‌توانید ببینید که Pod‌ها در حال اجرا هستند یا نه، یا اگر Deployment‌ها به‌درستی اعمال شده‌اند یا خیر.
2. مفید برای بررسی منابع ایجاد شده از فایل‌ها: این دستور به‌ویژه زمانی مفید است که شما منابع را از فایل‌های YAML یا JSON تعریف کرده‌اید و می‌خواهید وضعیت آن‌ها را پس از اعمال تغییرات بررسی کنید.
3. فیلتر کردن خروجی: مانند سایر دستورات kubectl get، شما می‌توانید از گزینه‌هایی مانند -o wide یا -o json برای دریافت اطلاعات دقیق‌تر و با جزئیات بیشتر استفاده کنید.
4. تنظیمات نمایش (Output Formatting): می‌توانید برای نمایش نتایج در قالب‌هایی مانند json، yaml، wide، یا حتی فقط فیلد خاصی از منابع استفاده کنید:

   kubectl get -f my-pod.yaml -o wide
   

   این دستور وضعیت Pod را به‌صورت دقیق‌تر (با اطلاعات بیشتر مانند IP و Node) نمایش می‌دهد.

نکات و بهینه‌سازی‌ها:

• زمانی که می‌خواهید وضعیت منابعی را که اخیراً به‌روزرسانی کرده‌اید مشاهده کنید: اگر شما از فایل‌های YAML برای به‌روزرسانی منابع استفاده کرده‌اید، این دستور کمک می‌کند تا مطمئن شوید که تغییرات به درستی اعمال شده‌اند و منابع در وضعیت صحیح قرار دارند.
• برای دیباگ کردن مشکلات: در صورتی که منابعی در کلاستر شما در وضعیت خراب یا مشکلی قرار دارند، با استفاده از این دستور می‌توانید وضعیت آن‌ها را بررسی کرده و از اطلاعات بیشتری برای دیباگ کردن استفاده کنید.
• در استفاده از Kubernetes CI/CD: در فرآیندهای CI/CD که منابع از طریق فایل‌های YAML تعریف و مدیریت می‌شوند، این دستور به شما امکان می‌دهد که به سرعت وضعیت منابع ایجادشده را پس از اعمال تغییرات بررسی کنید.

جمع‌بندی

دستور kubectl get -f <file> یکی از ابزارهای مهم در Kubernetes است که برای بررسی وضعیت منابع تعریف‌شده در فایل‌های YAML یا JSON استفاده می‌شود. این دستور به شما کمک می‌کند که اطلاعات مربوط به منابع مختلفی که قبلاً در کلاستر تعریف کرده‌اید، مانند Pods، Deployments، Services، و سایر منابع را مشاهده کنید. با استفاده از این دستور، می‌توانید وضعیت منابع را پس از اعمال تغییرات یا به‌روزرسانی‌ها بررسی کرده و از صحت عملکرد آن‌ها مطمئن شوید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 6. مدیریت Context‌ها و Cluster‌ها”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مشاهده Context‌های موجود با kubectl config get-contexts” subtitle=”توضیحات کامل”]دستور kubectl config get-contexts به شما این امکان را می‌دهد که لیست تمام context‌های موجود در فایل پیکربندی Kubernetes (kubeconfig) را مشاهده کنید. Context‌ها شامل اطلاعاتی در مورد کلاستر، نام کاربری (user) و namespace‌ای هستند که برای انجام عملیات در کلاستر مشخص شده است. این دستور به ویژه زمانی مفید است که شما با چندین کلاستر کار می‌کنید و می‌خواهید وضعیت و تنظیمات مختلف آن‌ها را بررسی کنید.

نحوه استفاده از دستور kubectl config get-contexts

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

kubectl config get-contexts

این دستور لیستی از context‌ها را همراه با اطلاعات مربوط به هر کدام، مانند نام context، کلاستر مرتبط، کاربر (user) و namespace مربوطه، به نمایش می‌گذارد.

توضیحات بیشتر:

• Context: یک context در فایل پیکربندی Kubernetes نمایانگر یک ترکیب از کلاستر، کاربر و namespace است. به عبارت دیگر، context‌ها تعیین می‌کنند که شما در کدام کلاستر قرار دارید و با چه کاربری و namespace‌ای به منابع دسترسی خواهید داشت.
• این دستور نمایش می‌دهد که در حال حاضر چه context‌هایی برای استفاده در دسترس هستند و به شما کمک می‌کند تا به راحتی به کلاستر و namespace مورد نظر سوئیچ کنید.

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

1. مشاهده لیست تمام context‌ها:

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

kubectl config get-contexts

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

CURRENT   NAME               CLUSTER            AUTHINFO           NAMESPACE
*         context-1          cluster-1          user-1             default
          context-2          cluster-2          user-2             dev
          context-3          cluster-3          user-3             prod

در این مثال:

• CURRENT: علامت ستاره نشان می‌دهد که کدام context فعلاً در حال استفاده است.
• NAME: نام context‌ها.
• CLUSTER: نام کلاستری که هر context به آن مربوط می‌شود.
• AUTHINFO: نام کاربری مرتبط با هر context.
• NAMESPACE: namespace‌ای که برای هر context مشخص شده است.

2. مشاهده جزئیات بیشتر درباره یک context خاص:

اگر شما بخواهید جزئیات بیشتری درباره یک context خاص مشاهده کنید، می‌توانید از دستور kubectl config view استفاده کنید تا پیکربندی کامل آن را مشاهده کنید:

kubectl config view --context=context-1

3. مشاهده تنها context فعال:

برای مشاهده context فعال و در حال استفاده، از گزینه CURRENT می‌توانید استفاده کنید:

kubectl config get-contexts | grep '*'

این دستور تنها context فعلی را نمایش می‌دهد که علامت ستاره (*) در مقابل آن قرار دارد.

ویژگی‌ها و کاربردها:

• چندین کلاستر: اگر شما با چندین کلاستر Kubernetes کار می‌کنید، می‌توانید از context‌ها برای مدیریت و سوئیچ کردن بین آن‌ها استفاده کنید.
• تسهیل مدیریت منابع: context‌ها به شما کمک می‌کنند که به سرعت و بدون نیاز به تغییرات دستی در پیکربندی، منابع مختلف را از طریق kubectl مدیریت کنید.
• مفید برای CI/CD: در محیط‌های Continuous Integration/Continuous Deployment (CI/CD) که با چندین کلاستر و محیط مختلف کار می‌شود، context‌ها به شما کمک می‌کنند تا به راحتی بین کلاسترهای مختلف جابجا شوید و عملیات مختلف را انجام دهید.

نکات مهم:

• تغییر context فعال: برای تغییر context فعلی، از دستور kubectl config use-context <context-name> استفاده کنید.مثال:

  kubectl config use-context context-2
  

• پیکربندی چندین context: شما می‌توانید چندین context مختلف برای کلاسترهای مختلف یا محیط‌های مختلف (مثل تولید، توسعه، و آزمایش) داشته باشید و به راحتی بین آن‌ها سوئیچ کنید.

جمع‌بندی

دستور kubectl config get-contexts به شما این امکان را می‌دهد که لیست تمام context‌های موجود در فایل پیکربندی Kubernetes را مشاهده کنید. این اطلاعات به شما کمک می‌کند تا درک بهتری از محیط‌های مختلف کلاستری که در حال استفاده از آن‌ها هستید، داشته باشید و بتوانید به راحتی بین آن‌ها جابجا شوید. این ابزار برای مدیران سیستم و توسعه‌دهندگانی که با چندین کلاستر کار می‌کنند، بسیار مفید است.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تغییر Context پیش‌فرض با kubectl config use-context” subtitle=”توضیحات کامل”]دستور kubectl config use-context برای تغییر context پیش‌فرض که در حال حاضر در پیکربندی Kubernetes استفاده می‌شود، به کار می‌رود. هر context شامل تنظیمات مرتبط با یک کلاستر خاص، یک کاربر (user)، و namespace است. این دستور به شما این امکان را می‌دهد که به سرعت از یک context به context دیگر سوئیچ کنید و به منابع مختلف در کلاسترهای مختلف دسترسی پیدا کنید.

نحوه استفاده از دستور kubectl config use-context

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

kubectl config use-context <context-name>

در این دستور، <context-name> نام context جدیدی است که می‌خواهید به عنوان context پیش‌فرض انتخاب کنید.

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

1. تغییر به یک context خاص:

فرض کنید می‌خواهید به context با نام context-2 سوئیچ کنید. دستور زیر را اجرا می‌کنید:

kubectl config use-context context-2

پس از اجرای این دستور، context-2 به عنوان context پیش‌فرض تنظیم می‌شود و تمام دستورات kubectl به طور خودکار در کلاستری که با این context مرتبط است اجرا می‌شود.

2. مشاهده context فعلی:

پس از تغییر context، اگر بخواهید ببینید که کدام context فعلاً در حال استفاده است، می‌توانید دستور زیر را اجرا کنید:

kubectl config current-context

این دستور نام context فعلی که در حال حاضر فعال است را نمایش می‌دهد.

3. مشاهده لیست context‌ها:

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

kubectl config get-contexts

این دستور لیستی از context‌ها را نمایش می‌دهد و می‌توانید از این لیست context مورد نظر خود را انتخاب کنید.

4. تغییر سریع بین چندین کلاستر:

اگر شما در حال کار با چندین کلاستر هستید، این دستور به شما کمک می‌کند که بدون نیاز به تغییر دستی پیکربندی‌های دیگر، به راحتی بین کلاسترها و context‌ها سوئیچ کنید. به عنوان مثال، اگر چند context برای محیط‌های مختلف مانند توسعه (dev) و تولید (prod) دارید، می‌توانید به سرعت بین این دو سوئیچ کنید:

kubectl config use-context dev-context

و سپس برای تغییر به کلاستر تولید:

kubectl config use-context prod-context

نکات مهم:

• Context‌ها را با دقت انتخاب کنید: هنگام استفاده از دستور kubectl config use-context، مطمئن شوید که context انتخابی شما حاوی تنظیمات صحیحی از کلاستر، کاربر و namespace مورد نظر است.
• مدیریت چندین کلاستر: این دستور برای مدیریت چندین کلاستر مختلف بسیار مفید است. به خصوص زمانی که می‌خواهید از یک کلاستر به کلاستری دیگر بروید و نیازی به تغییر دستی تنظیمات ندارید.
• اطمینان از انتخاب context درست: همیشه قبل از اجرای دستورات حساس، از تغییر context اطمینان حاصل کنید. برای این کار می‌توانید از دستور kubectl config current-context استفاده کنید تا مطمئن شوید که در حال کار با context صحیح هستید.

جمع‌بندی

دستور kubectl config use-context <name> به شما این امکان را می‌دهد که به راحتی context پیش‌فرض خود را تغییر دهید و به کلاسترها و منابع مختلف در Kubernetes دسترسی پیدا کنید. این ابزار به ویژه در محیط‌های چندکلاستری و زمانی که با چندین محیط کاری (مانند توسعه، آزمایش، تولید) سروکار دارید، بسیار مفید است. با استفاده از این دستور، می‌توانید سوئیچ بین کلاسترها را بدون نیاز به تغییرات دستی در پیکربندی انجام دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”اضافه کردن Cluster جدید به تنظیمات kubectl” subtitle=”توضیحات کامل”]برای اضافه کردن یک کلاستر جدید به تنظیمات kubectl، شما باید اطلاعات مربوط به کلاستر جدید، از جمله آدرس API سرور Kubernetes، گواهینامه‌ها (certificates)، و سایر تنظیمات مورد نیاز را وارد کنید. این تنظیمات به شما این امکان را می‌دهند که بتوانید به کلاستر جدید دسترسی پیدا کنید و منابع آن را مدیریت کنید.

برای انجام این کار، می‌توانید از دستور kubectl config set-cluster استفاده کنید.

نحوه استفاده از دستور kubectl config set-cluster

دستور kubectl config set-cluster به شما این امکان را می‌دهد که یک کلاستر جدید را به پیکربندی kubectl اضافه کنید.

kubectl config set-cluster <cluster-name> --server=<api-server-url> --certificate-authority=<ca-cert-file>

در این دستور:

• <cluster-name>: نامی است که برای کلاستر جدید انتخاب می‌کنید.
• --server=<api-server-url>: آدرس URL سرور API Kubernetes کلاستر جدید است.
• --certificate-authority=<ca-cert-file>: مسیر فایل گواهینامه (CA certificate) برای تایید هویت سرور API.

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

1. اضافه کردن کلاستر جدید:

فرض کنید می‌خواهید کلاستری با نام my-cluster اضافه کنید و URL سرور API آن https://192.168.1.100:6443 است. فایل گواهینامه CA نیز در مسیر /path/to/ca.crt قرار دارد. دستور مورد نظر به شکل زیر خواهد بود:

kubectl config set-cluster my-cluster --server=https://192.168.1.100:6443 --certificate-authority=/path/to/ca.crt

2. اضافه کردن کلاستر با استفاده از gcloud (برای Google Kubernetes Engine):

اگر از GKE استفاده می‌کنید، می‌توانید از gcloud برای افزودن کلاستر جدید به تنظیمات kubectl استفاده کنید. دستور زیر کلاستر را به تنظیمات kubectl اضافه می‌کند:

gcloud container clusters get-credentials <cluster-name> --zone <zone> --project <project-id>

در این دستور:

• <cluster-name>: نام کلاستری که می‌خواهید اضافه کنید.
• <zone>: ناحیه‌ای که کلاستر در آن قرار دارد.
• <project-id>: شناسه پروژه‌ای که کلاستر در آن ساخته شده است.

3. مشاهده کلاسترهای موجود در پیکربندی:

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

kubectl config get-clusters

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

تنظیمات اضافی هنگام اضافه کردن کلاستر:

اگر کلاستر شما به اعتبارسنجی نیاز دارد، می‌توانید اطلاعات کاربری را نیز به پیکربندی اضافه کنید. برای این کار از دستور kubectl config set-credentials استفاده می‌شود.

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

kubectl config set-credentials user1 --username=myuser --password=mypassword

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

ایجاد context جدید:

برای ایجاد یک context جدید که کلاستر، کاربر و namespace مورد نظر را ترکیب کند، می‌توانید از دستور kubectl config set-context استفاده کنید:

kubectl config set-context my-context --cluster=my-cluster --user=user1 --namespace=default

این دستور یک context جدید با نام my-context ایجاد می‌کند که از کلاستر my-cluster، کاربر user1 و namespace default استفاده می‌کند.

جمع‌بندی

دستور kubectl config set-cluster به شما این امکان را می‌دهد که کلاستر جدیدی را به تنظیمات kubectl اضافه کنید. شما می‌توانید اطلاعات مربوط به کلاستر از جمله URL سرور API و گواهینامه CA را به پیکربندی اضافه کرده و سپس از این کلاستر برای مدیریت منابع Kubernetes استفاده کنید. همچنین می‌توانید با استفاده از دستورات دیگر مانند kubectl config set-credentials و kubectl config set-context اطلاعات مربوط به کاربران و context‌های مختلف را برای دسترسی به کلاستر تنظیم کنید.[/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=”افزودن Label به منابع با kubectl label” subtitle=”توضیحات کامل”]در Kubernetes، Labels برای دسته‌بندی و انتخاب منابع مختلف مانند Pods، Services و غیره استفاده می‌شوند. شما می‌توانید به راحتی به منابع مختلف یک یا چند Label اضافه کنید تا آن‌ها را بهتر سازماندهی کنید و یا در هنگام انتخاب منابع از دستورات خاصی استفاده کنید.

با دستور kubectl label می‌توانید به منابع موجود Label اضافه کنید.

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

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

kubectl label <resource-type> <resource-name> <label-key>=<label-value>

در این دستور:

• <resource-type>: نوع منبعی است که می‌خواهید به آن Label اضافه کنید. این می‌تواند pod، deployment، service و غیره باشد.
• <resource-name>: نام منبعی است که می‌خواهید به آن Label اضافه کنید.
• <label-key>: کلید Label است. یک رشته است که باید مشخص شود.
• <label-value>: مقدار Label است که به کلید Label اختصاص می‌یابد.

مثال‌ها:

1. افزودن Label به یک Pod خاص:

فرض کنید شما یک Pod با نام my-pod دارید و می‌خواهید به آن Label با کلید environment و مقدار production اضافه کنید. دستور به شکل زیر خواهد بود:

kubectl label pod my-pod environment=production

2. افزودن چندین Label به یک Pod:

می‌توانید چندین Label را به طور همزمان به یک منبع اضافه کنید. برای مثال، به Pod با نام my-pod می‌توانید دو Label با کلیدهای مختلف اضافه کنید:

kubectl label pod my-pod environment=production app=frontend

3. افزودن Label به یک Deployment:

فرض کنید شما یک Deployment با نام my-deployment دارید و می‌خواهید به آن Label با کلید tier و مقدار backend اضافه کنید. دستور به شکل زیر خواهد بود:

kubectl label deployment my-deployment tier=backend

4. افزودن Label به چندین منبع هم‌زمان:

می‌توانید برای چندین منبع یک Label را اضافه کنید. برای مثال، به تمام Pods در یک namespace خاص می‌توانید یک Label اضافه کنید:

kubectl label pods --all environment=production

ویرایش Label‌های موجود:

اگر بخواهید Label‌های قبلی را ویرایش کنید یا آن‌ها را حذف کنید، می‌توانید از دستور kubectl label با پارامتر -l برای هدف قرار دادن منابع خاص استفاده کنید و مقدار جدید را اعمال کنید.

1. ویرایش یا به‌روزرسانی Label یک منبع:

برای به‌روزرسانی مقدار یک Label، می‌توانید دستور زیر را اجرا کنید. این دستور مقدار Label قبلی را تغییر می‌دهد:

kubectl label pod my-pod environment=staging --overwrite

در این دستور از پارامتر --overwrite استفاده شده است تا مقدار Label قبلی با مقدار جدید جایگزین شود.

2. حذف Label از یک منبع:

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

kubectl label pod my-pod environment-

این دستور Label با کلید environment را از Pod my-pod حذف می‌کند.

مشاهده Labels:

برای مشاهده Labels مربوط به یک منبع خاص، می‌توانید از دستور kubectl get همراه با پارامتر -L استفاده کنید. به عنوان مثال:

kubectl get pods -L environment

این دستور لیستی از تمام Pods موجود در کلاستر را نمایش می‌دهد و مقدار Label environment را برای هر Pod نمایش می‌دهد.

جمع‌بندی

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

برای افزودن Annotations به منابع از دستور kubectl annotate استفاده می‌شود.

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

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

kubectl annotate <resource-type> <resource-name> <annotation-key>=<annotation-value>

در این دستور:

• <resource-type>: نوع منبعی است که می‌خواهید به آن Annotation اضافه کنید (مثلاً pod، deployment، service و غیره).
• <resource-name>: نام منبعی است که می‌خواهید به آن Annotation اضافه کنید.
• <annotation-key>: کلید Annotation است که به صورت رشته مشخص می‌شود.
• <annotation-value>: مقدار Annotation است که به کلید آن اختصاص می‌یابد.

مثال‌ها:

1. افزودن Annotation به یک Pod خاص:

فرض کنید یک Pod با نام my-pod دارید و می‌خواهید به آن Annotation با کلید description و مقدار This is a critical pod اضافه کنید. دستور به شکل زیر خواهد بود:

kubectl annotate pod my-pod description="This is a critical pod"

2. افزودن چندین Annotation به یک Pod:

برای افزودن چندین Annotation به یک Pod خاص، می‌توانید از دستور زیر استفاده کنید:

kubectl annotate pod my-pod description="This is a critical pod" team="devops"

3. افزودن Annotation به یک Deployment:

فرض کنید یک Deployment با نام my-deployment دارید و می‌خواهید به آن Annotation با کلید last-updated و مقدار 2025-02-09 اضافه کنید. دستور به شکل زیر خواهد بود:

kubectl annotate deployment my-deployment last-updated="2025-02-09"

ویرایش یا به‌روزرسانی Annotations:

اگر بخواهید Annotation‌های قبلی را ویرایش کنید یا آن‌ها را حذف کنید، می‌توانید از دستور kubectl annotate با پارامتر --overwrite برای ویرایش یا تغییر مقدار آن‌ها استفاده کنید.

1. ویرایش یا به‌روزرسانی Annotation یک منبع:

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

kubectl annotate pod my-pod description="Updated description" --overwrite

در این دستور، مقدار Annotation قبلی با مقدار جدید جایگزین می‌شود.

2. حذف Annotation از یک منبع:

برای حذف یک Annotation از منبع خاص، از علامت - برای حذف استفاده می‌کنید:

kubectl annotate pod my-pod description-

این دستور Annotation با کلید description را از Pod my-pod حذف می‌کند.

مشاهده Annotations:

برای مشاهده Annotations مربوط به یک منبع خاص، می‌توانید از دستور kubectl get استفاده کنید همراه با پارامتر -o yaml تا اطلاعات مربوط به Annotations نمایش داده شود:

kubectl get pod my-pod -o yaml

این دستور، تمام اطلاعات مربوط به Pod my-pod را به صورت YAML نمایش می‌دهد که شامل Annotations نیز خواهد بود.

جمع‌بندی

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

دستور kubectl patch به خصوص زمانی مفید است که بخواهید تغییری کوچک و مشخص روی یک منبع ایجاد کنید بدون اینکه نیاز باشد کل تنظیمات آن را دوباره تعریف کنید.

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

دستور kubectl patch به صورت کلی به شکل زیر استفاده می‌شود:

kubectl patch <resource-type> <resource-name> -p '<patch-data>'

در این دستور:

• <resource-type>: نوع منبعی است که می‌خواهید تغییرات را روی آن اعمال کنید (مثلاً pod، deployment، service و غیره).
• <resource-name>: نام منبعی است که می‌خواهید تغییرات جزئی را روی آن اعمال کنید.
• -p '<patch-data>': داده‌های پچ به صورت JSON یا YAML که تغییرات مورد نظر را شامل می‌شود.

مثال‌ها:

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

فرض کنید یک Deployment با نام my-deployment دارید و می‌خواهید تعداد Replicas را از 3 به 5 تغییر دهید. می‌توانید از دستور kubectl patch به شکل زیر استفاده کنید:

kubectl patch deployment my-deployment -p '{"spec": {"replicas": 5}}'

در این مثال، تنها مقدار replicas تغییر می‌کند و سایر تنظیمات Deployment بدون تغییر باقی می‌ماند.

2. تغییر منابع CPU و Memory یک Pod:

اگر بخواهید منابع CPU و Memory یک Pod را تغییر دهید، دستور مشابه زیر را استفاده می‌کنید:

kubectl patch pod my-pod -p '{"spec": {"containers": [{"name": "my-container", "resources": {"requests": {"cpu": "500m", "memory": "512Mi"}, "limits": {"cpu": "1", "memory": "1Gi"}}} ]}}'

در این مثال، مقدار resources در کانتینر my-container تغییر می‌کند و دیگر تنظیمات باقی می‌ماند.

3. افزودن Label به یک Deployment:

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

kubectl patch deployment my-deployment -p '{"metadata": {"labels": {"env": "production"}}}'

در این مثال، یک Label جدید با نام env و مقدار production به Deployment my-deployment اضافه می‌شود.

4. تغییر تصویر کانتینر در یک Deployment:

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

kubectl patch deployment my-deployment -p '{"spec": {"template": {"spec": {"containers": [{"name": "my-container", "image": "my-new-image:v2"}]}}}}'

این دستور، تصویر کانتینر my-container را به my-new-image:v2 تغییر می‌دهد.

پچ‌های JSON و YAML

در دستور kubectl patch، می‌توانید پچ را به صورت JSON یا YAML ارائه دهید، اما معمولا JSON بیشتر استفاده می‌شود. همچنین، اگر تغییرات شما پیچیده‌تر باشد و نیاز به ساختارهای بیشتری داشته باشد، می‌توانید آن‌ها را در یک فایل ذخیره کرده و آن فایل را با دستور kubectl patch بارگذاری کنید.

1. پچ به صورت فایل JSON:

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

kubectl patch deployment my-deployment --patch "$(cat patch.json)"

2. پچ به صورت فایل YAML:

اگر پچ شما به صورت YAML است، می‌توانید از دستور مشابه استفاده کنید:

kubectl patch deployment my-deployment --patch "$(cat patch.yaml)"

جمع‌بندی

دستور kubectl patch به شما این امکان را می‌دهد که تغییرات جزئی و هدفمند را روی منابع Kubernetes اعمال کنید بدون اینکه نیازی به بازنویسی کل منبع باشد. این دستور برای اعمال تغییرات سریع و به‌روز کردن بخش‌های خاص از منابع مفید است. استفاده از پچ‌ها به شما کمک می‌کند که منابع خود را بهینه و دقیق‌تر مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”استفاده از kubectl get -o yaml برای استخراج تعریف YAML” subtitle=”توضیحات کامل”]دستور kubectl get <resource> -o yaml یکی از ابزارهای مفید در Kubernetes است که به شما این امکان را می‌دهد تا اطلاعات کامل یک منبع خاص را به صورت YAML استخراج کنید. این دستور به‌ویژه برای مشاهده و ذخیره‌سازی تعریف منابع به شکل فایل YAML مفید است، به‌طوری‌که می‌توانید آن را به عنوان یک الگو برای ایجاد یا به‌روزرسانی منابع جدید استفاده کنید.

ساختار کلی دستور

kubectl get <resource> <resource-name> -o yaml

در این دستور:

• <resource>: نوع منبعی است که می‌خواهید اطلاعات آن را استخراج کنید. این می‌تواند هر منبعی از Kubernetes مانند pod، service، deployment، namespace و غیره باشد.
• <resource-name>: نام خاص منبعی است که می‌خواهید اطلاعات آن را به دست آورید.
• -o yaml: این پارامتر به Kubernetes اعلام می‌کند که خروجی باید به صورت YAML باشد.

مثال‌ها:

1. استخراج تعریف YAML یک Pod خاص:

برای مشاهده تعریف کامل یک Pod به نام my-pod، می‌توانید از دستور زیر استفاده کنید:

kubectl get pod my-pod -o yaml

این دستور اطلاعات مربوط به Pod مانند پیکربندی کانتینرها، Volumes، Labels، Annotations و سایر ویژگی‌ها را به صورت YAML نمایش می‌دهد.

2. استخراج YAML یک Deployment:

اگر بخواهید تعریف YAML یک Deployment به نام my-deployment را مشاهده کنید، دستور زیر را اجرا کنید:

kubectl get deployment my-deployment -o yaml

خروجی این دستور شامل تمام تنظیمات مرتبط با Deployment، مانند تعداد Replicas، استراتژی به‌روزرسانی، Template پادها، و سایر پیکربندی‌ها خواهد بود.

3. استخراج YAML یک Service:

برای استخراج YAML یک Service به نام my-service از دستور زیر استفاده کنید:

kubectl get service my-service -o yaml

در این حالت، اطلاعات مربوط به پیکربندی‌های سرویس مانند نوع Service (ClusterIP، NodePort و غیره)، انتخابگرها (Selectors) و پورت‌ها نمایش داده می‌شود.

4. استخراج YAML برای چندین Resource:

اگر بخواهید YAML مربوط به چندین منبع مشابه را مشاهده کنید، می‌توانید از دستور زیر استفاده کنید:

kubectl get pods -o yaml

این دستور تمامی Pods در namespace فعلی را به صورت YAML استخراج می‌کند.

ذخیره‌سازی خروجی YAML به یک فایل:

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

kubectl get pod my-pod -o yaml > pod-definition.yaml

این دستور خروجی YAML مربوط به Pod my-pod را در فایل pod-definition.yaml ذخیره می‌کند که می‌توانید از آن برای به‌روزرسانی، بازبینی یا ایجاد منابع مشابه استفاده کنید.

استفاده از YAML استخراج‌شده برای به‌روزرسانی منابع:

پس از استخراج YAML یک منبع، می‌توانید آن را ویرایش کرده و دوباره با استفاده از دستور kubectl apply -f <file> منابع را به‌روزرسانی کنید. به عنوان مثال، اگر فایل pod-definition.yaml را تغییر دهید، می‌توانید آن را به Kubernetes اعمال کنید:

kubectl apply -f pod-definition.yaml

کاربردهای دیگر:

• انتقال منابع بین کلاسترها: می‌توانید YAML استخراج‌شده را برای مهاجرت منابع به کلاستر دیگری استفاده کنید.
• مقایسه منابع: با استفاده از YAML استخراج‌شده، می‌توانید منابع را با نسخه‌های قبلی مقایسه کنید.
• ایجاد منابع جدید: اگر تعریف YAML یک منبع را استخراج کرده و آن را تغییر دهید، می‌توانید از آن برای ایجاد منابع جدید در Kubernetes استفاده کنید.

جمع‌بندی

دستور kubectl get <resource> -o yaml ابزاری بسیار مفید برای استخراج و مشاهده تنظیمات کامل یک منبع به صورت YAML است. این ابزار به شما کمک می‌کند تا پیکربندی دقیق منابع را مشاهده و ذخیره کنید و آن را برای به‌روزرسانی یا ساخت منابع جدید استفاده کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تست فایل‌های YAML با kubectl dry-run و kubectl validate” subtitle=”توضیحات کامل”]در Kubernetes، هنگام کار با فایل‌های YAML برای ایجاد یا به‌روزرسانی منابع، ممکن است بخواهید قبل از اعمال تغییرات واقعی، از صحت فایل‌ها اطمینان حاصل کنید. Kubernetes ابزارهایی را برای شبیه‌سازی اجرای فایل‌های YAML بدون اعمال تغییرات واقعی فراهم کرده است. این ابزارها شامل kubectl dry-run و kubectl validate هستند.

1. kubectl dry-run

kubectl dry-run به شما این امکان را می‌دهد تا یک عملیات ایجاد، به‌روزرسانی یا حذف منابع را شبیه‌سازی کنید بدون اینکه واقعاً آن‌ها را اعمال کنید. این ابزار برای بررسی صحت فایل‌های YAML بسیار مفید است و می‌تواند خطاهای احتمالی را قبل از اعمال تغییرات واقعی نشان دهد.

ساختار کلی دستور:

kubectl apply -f <file> --dry-run=client

در این دستور:

• <file>: نام فایل YAML که می‌خواهید آن را بررسی کنید.
• --dry-run=client: این گزینه به Kubernetes اعلام می‌کند که عملیات را فقط شبیه‌سازی کند و تغییرات واقعی اعمال نشوند.

مثال‌ها:

1. شبیه‌سازی ایجاد یک Pod:

اگر بخواهید یک Pod جدید را از طریق فایل YAML شبیه‌سازی کنید، دستور زیر را اجرا کنید:

kubectl apply -f pod-definition.yaml --dry-run=client

این دستور فایل pod-definition.yaml را شبیه‌سازی می‌کند و اگر همه چیز صحیح باشد، پیامی مانند “Dry run was successful” را نمایش می‌دهد.

2. شبیه‌سازی به‌روزرسانی یک Deployment:

اگر قصد دارید یک Deployment موجود را به‌روزرسانی کنید، می‌توانید فایل YAML به‌روزرسانی شده را با dry-run تست کنید:

kubectl apply -f deployment-update.yaml --dry-run=client

در این حالت، تغییرات مورد نظر اعمال نمی‌شوند، ولی اگر خطایی در فایل وجود داشته باشد، پیام خطا را مشاهده خواهید کرد.

2. kubectl validate (در برخی نسخه‌ها)

در نسخه‌های جدیدتر Kubernetes، دستور kubectl validate برای بررسی صحت فایل‌های YAML وجود دارد. این دستور فایل‌های YAML را بررسی کرده و اطمینان حاصل می‌کند که ساختار صحیحی دارند و منطبق بر ساختارهای تعریف‌شده در API Kubernetes هستند.

ساختار کلی دستور:

kubectl validate -f <file>

در این دستور:

• <file>: نام فایل YAML که می‌خواهید آن را اعتبارسنجی کنید.

مثال:

1. اعتبارسنجی فایل YAML:

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

kubectl validate -f my-resource.yaml

این دستور فایل my-resource.yaml را اعتبارسنجی می‌کند و به شما می‌گوید که آیا فایل معتبر است یا خیر. اگر خطای ساختاری یا منطبق نبودن با API داشته باشد، آن را گزارش خواهد کرد.

3. تفاوت بین kubectl dry-run و kubectl validate

• kubectl dry-run: شبیه‌سازی عملیات بدون اعمال تغییرات واقعی. این گزینه برای تست عملیات‌هایی مانند apply, delete, یا create مفید است.
• kubectl validate: بررسی صحت ساختاری فایل YAML و انطباق آن با API Kubernetes. این دستور به‌طور عمده برای بررسی خطاهای ساختاری فایل YAML استفاده می‌شود و نمی‌تواند به شما بگوید که آیا یک فایل به درستی اجرا خواهد شد یا نه (فقط از نظر ساختاری بررسی می‌کند).

4. مزایای استفاده از kubectl dry-run و kubectl validate

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

جمع‌بندی

با استفاده از kubectl dry-run و kubectl validate می‌توانید اطمینان حاصل کنید که فایل‌های YAML شما به‌درستی پیکربندی شده‌اند و بدون اعمال تغییرات واقعی، آن‌ها را بررسی کنید. این ابزارها به شما کمک می‌کنند تا پیش از ایجاد یا به‌روزرسانی منابع، مطمئن شوید که خطاهای ساختاری و اجرایی وجود ندارد.[/cdb_course_lesson][cdb_course_lesson title=”فصل 8. دستورات متداول برای Scaling”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”تغییر تعداد Replicas با kubectl scale” subtitle=”توضیحات کامل”]در Kubernetes، تعداد Replica‌ها برای منابع مختلفی مثل Deployments، ReplicaSets، و StatefulSets اهمیت زیادی دارد. برای مقیاس‌بندی و تغییر تعداد Replica‌ها می‌توانید از دستور kubectl scale استفاده کنید. این دستور به شما این امکان را می‌دهد تا تعداد Pod‌های در حال اجرا برای یک Deployment یا ReplicaSet را به‌صورت داینامیک افزایش یا کاهش دهید.

1. ساختار کلی دستور kubectl scale

دستور kubectl scale برای تغییر تعداد Replica‌ها به این صورت است:

kubectl scale <resource> <name> --replicas=<number>

در اینجا:

• <resource>: نوع منبعی که می‌خواهید تعداد Replica‌ها را تغییر دهید (مثلاً deployment, replicaset, statefulset).
• <name>: نام منبعی که می‌خواهید مقیاس آن را تغییر دهید.
• --replicas=<number>: تعداد جدید Replica‌ها که می‌خواهید تنظیم کنید.

2. مثال‌ها:

1. تغییر تعداد Replica‌ها در یک Deployment:

فرض کنید یک Deployment به نام my-deployment دارید و می‌خواهید تعداد Replica‌ها را از 3 به 5 تغییر دهید. دستور زیر این کار را انجام می‌دهد:

kubectl scale deployment my-deployment --replicas=5

در این حالت، Kubernetes تعداد Pod‌های مربوط به my-deployment را به 5 می‌رساند.

2. تغییر تعداد Replica‌ها در یک ReplicaSet:

اگر از یک ReplicaSet به نام my-replicaset استفاده می‌کنید، دستور مشابهی برای مقیاس‌بندی آن استفاده می‌شود:

kubectl scale replicaset my-replicaset --replicas=10

این دستور تعداد Pod‌های my-replicaset را به 10 افزایش می‌دهد.

3. تغییر تعداد Replica‌ها در یک StatefulSet:

برای یک StatefulSet به نام my-statefulset که ممکن است به تعداد مشخصی از Replica‌ها نیاز داشته باشد، دستور زیر برای مقیاس‌بندی استفاده می‌شود:

kubectl scale statefulset my-statefulset --replicas=3

این دستور تعداد Replica‌ها را به 3 تغییر می‌دهد.

3. استفاده از فایل YAML برای مقیاس‌بندی

اگر می‌خواهید تعداد Replica‌ها را در فایل YAML تنظیم کنید، می‌توانید به سادگی از دستور kubectl apply برای اعمال تغییرات استفاده کنید.

1. ویرایش فایل YAML برای مقیاس‌بندی:

فرض کنید فایل deployment.yaml دارید که تعداد Replica‌های آن به 3 تنظیم شده است. شما می‌توانید تعداد Replica‌ها را به‌صورت دستی در فایل YAML تغییر دهید:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 5
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest

2. اعمال تغییرات:

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

kubectl apply -f deployment.yaml

این دستور تعداد Replica‌ها را به 5 تنظیم خواهد کرد.

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

پس از تغییر تعداد Replica‌ها، می‌توانید با استفاده از دستور kubectl get وضعیت فعلی Replica‌ها را مشاهده کنید:

kubectl get deployment my-deployment

این دستور به شما تعداد Pods در حال اجرا برای my-deployment را نشان می‌دهد.

جمع‌بندی

دستور kubectl scale یک ابزار قدرتمند برای مقیاس‌بندی منابع در Kubernetes است. با استفاده از آن می‌توانید تعداد Replica‌ها را در Deployments، ReplicaSets و StatefulSets به‌راحتی تغییر دهید. این ابزار به شما این امکان را می‌دهد که به‌طور داینامیک مقیاس برنامه‌های خود را بسته به نیاز تغییر دهید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مدیریت Auto-scaling با kubectl autoscale” subtitle=”توضیحات کامل”]Auto-scaling یکی از ویژگی‌های مهم Kubernetes است که به شما این امکان را می‌دهد که به‌صورت خودکار تعداد Pod‌ها را بسته به میزان بار (مصرف CPU یا حافظه) افزایش یا کاهش دهید. Kubernetes برای انجام این کار از Horizontal Pod Autoscaler (HPA) استفاده می‌کند. دستور kubectl autoscale به شما این امکان را می‌دهد که به‌راحتی HPA را برای منابع مختلف (مانند Deployments) تنظیم کنید.

1. ساختار کلی دستور kubectl autoscale

برای ایجاد یک Auto-scaler به‌طور کلی از دستور زیر استفاده می‌شود:

kubectl autoscale <resource> <name> --min=<min_replicas> --max=<max_replicas> --cpu-percent=<cpu_threshold>

در اینجا:

• <resource>: نوع منبعی که می‌خواهید Auto-scaling را برای آن فعال کنید (مانند deployment, replicaset, statefulset).
• <name>: نام منبعی که می‌خواهید برای آن Auto-scaling تنظیم کنید.
• --min=<min_replicas>: حداقل تعداد Pod‌هایی که باید در هر زمان اجرا شوند.
• --max=<max_replicas>: حداکثر تعداد Pod‌هایی که می‌توانند به‌طور خودکار ایجاد شوند.
• --cpu-percent=<cpu_threshold>: حد آستانه CPU برای شروع Auto-scaling (بر حسب درصد).

2. مثال‌ها:

1. ایجاد Horizontal Pod Autoscaler برای یک Deployment:

فرض کنید یک Deployment به نام my-deployment دارید و می‌خواهید این Deployment به‌طور خودکار تعداد Pod‌های خود را بین 2 و 10 افزایش یا کاهش دهد، بسته به مصرف CPU. برای این کار می‌توانید از دستور زیر استفاده کنید:

kubectl autoscale deployment my-deployment --min=2 --max=10 --cpu-percent=50

این دستور یک HPA برای my-deployment ایجاد می‌کند که:

• حداقل 2 Pod باید همیشه در حال اجرا باشد.
• حداکثر تعداد Pod‌ها 10 خواهد بود.
• اگر مصرف CPU از 50% بیشتر شود، Kubernetes تعداد Pod‌ها را افزایش خواهد داد.

2. ایجاد Horizontal Pod Autoscaler برای یک ReplicaSet:

اگر یک ReplicaSet به نام my-replicaset دارید و می‌خواهید Auto-scaling را برای آن فعال کنید، دستور مشابه زیر را استفاده می‌کنید:

kubectl autoscale replicaset my-replicaset --min=3 --max=6 --cpu-percent=60

در این حالت، ReplicaSet بین 3 تا 6 Pod خواهد مقیاس‌بندی شود و اگر مصرف CPU از 60% فراتر رود، تعداد Pod‌ها افزایش می‌یابد.

3. ایجاد Horizontal Pod Autoscaler برای یک StatefulSet:

برای یک StatefulSet به نام my-statefulset، می‌توانید از دستور زیر برای فعال‌سازی Auto-scaling استفاده کنید:

kubectl autoscale statefulset my-statefulset --min=1 --max=5 --cpu-percent=70

این دستور مشابه موارد قبلی عمل می‌کند و تعداد Pod‌های my-statefulset را بر اساس مصرف CPU مقیاس‌بندی می‌کند.

3. مشاهده وضعیت Auto-scaler

پس از ایجاد Auto-scaler برای Deployment یا هر منبع دیگری، می‌توانید وضعیت آن را با دستور زیر مشاهده کنید:

kubectl get hpa

این دستور لیستی از Horizontal Pod Autoscaler‌ها و وضعیت فعلی آن‌ها (مانند تعداد Pod‌ها و مصرف CPU) را نمایش می‌دهد.

4. پاک کردن Auto-scaler

اگر نیاز به حذف Auto-scaler برای یک منبع خاص دارید، می‌توانید از دستور kubectl delete استفاده کنید:

kubectl delete hpa my-deployment

این دستور HPA مربوط به my-deployment را حذف می‌کند.

5. ملاحظات مهم در مورد Auto-scaling:

• Monitor کردن مصرف منابع: برای استفاده مؤثر از Auto-scaling، باید منابع را به دقت مانیتور کنید و از معیارهای مناسب (مانند مصرف CPU یا حافظه) استفاده کنید تا مطمئن شوید که Auto-scaling به‌درستی کار می‌کند.
• محدودیت‌ها: هرچند HPA به‌طور خودکار تعداد Pod‌ها را مقیاس‌بندی می‌کند، ولی در بعضی موارد ممکن است نیاز به تنظیمات اضافی داشته باشید (مثلاً با استفاده از custom metrics برای معیارهای دیگر به جز CPU و حافظه).

جمع‌بندی

با استفاده از دستور kubectl autoscale، شما می‌توانید به‌راحتی Horizontal Pod Autoscaler را برای منابع مختلف در Kubernetes تنظیم کنید. این ویژگی به شما این امکان را می‌دهد که به‌طور خودکار و داینامیک مقیاس منابع خود را براساس مصرف واقعی تغییر دهید، که این به بهبود عملکرد و استفاده بهینه از منابع کمک می‌کند.[/cdb_course_lesson][cdb_course_lesson title=”فصل 9. مدیریت ConfigMaps و Secrets”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”ایجاد ConfigMaps” subtitle=”توضیحات کامل”]در کوبرنتیز، ConfigMap‌ها برای ذخیره تنظیمات و پیکربندی‌ها استفاده می‌شوند. با استفاده از ConfigMap‌ها می‌توان تنظیمات برنامه‌ها را به‌طور جداگانه از کد برنامه مدیریت کرد. این تنظیمات می‌توانند به‌صورت فایل‌های پیکربندی، محیط متغیرها، یا پارامترهای تنظیماتی در قالب کلید-مقدار ذخیره شوند.

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

ایجاد ConfigMap از فایل

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

kubectl create configmap <configmap-name> --from-file=<path-to-file>

مثال:

kubectl create configmap my-config --from-file=config.txt

این دستور یک ConfigMap به نام my-config می‌سازد که محتوای فایل config.txt را در آن ذخیره می‌کند.

ایجاد ConfigMap از دایرکتوری

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

kubectl create configmap <configmap-name> --from-file=<directory-path>

مثال:

kubectl create configmap my-configs --from-file=/path/to/configs/

ایجاد ConfigMap از مقادیر کلید-مقدار

شما می‌توانید مقادیر را به‌صورت مستقیم به‌عنوان کلید-مقدار به ConfigMap اضافه کنید:

kubectl create configmap <configmap-name> --from-literal=<key>=<value>

مثال:

kubectl create configmap my-config --from-literal=env=production

این دستور یک ConfigMap به نام my-config می‌سازد که در آن کلید env با مقدار production ذخیره شده است.

بررسی ConfigMap‌های موجود

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

kubectl get configmap

برای مشاهده جزئیات یک ConfigMap خاص:

kubectl describe configmap <configmap-name>

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

برای استفاده از ConfigMap در Pods، می‌توانید آن را به‌صورت Volume یا Environment Variables به Pod متصل کنید.

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

در فایل YAML برای Pod، می‌توانید ConfigMap را به‌صورت Volume به Pod اضافه کنید:

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

استفاده از ConfigMap به‌عنوان Environment Variable:

در فایل YAML برای Pod، می‌توانید ConfigMap را به‌عنوان متغیر محیطی (Environment Variable) استفاده کنید:

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

این‌طور ConfigMap به‌عنوان Environment Variables در دسترس کانتینر قرار می‌گیرد.

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

اگر بخواهید یک ConfigMap را به‌روزرسانی کنید، می‌توانید از دستور kubectl apply استفاده کنید:

kubectl apply -f <configmap-file>.yaml

اگر تغییرات جزئی در ConfigMap داشتید و خواستید آنها را به‌روزرسانی کنید، در Podهای مرتبط با ConfigMap نیاز به راه‌اندازی مجدد دارید.

حذف ConfigMap

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

kubectl delete configmap <configmap-name>

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

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

ایجاد Secrets از فایل

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

kubectl create secret generic <secret-name> --from-file=<path-to-file>

مثال:

kubectl create secret generic my-secret --from-file=password.txt

این دستور یک Secret به نام my-secret ایجاد می‌کند و محتوای فایل password.txt را در آن ذخیره می‌کند.

ایجاد Secrets از مقدار کلید-مقدار

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

kubectl create secret generic <secret-name> --from-literal=<key>=<value>

مثال:

kubectl create secret generic my-secret --from-literal=password=supersecret

این دستور یک Secret به نام my-secret ایجاد می‌کند که شامل یک کلید به نام password با مقدار supersecret است.

ایجاد Secrets از چندین مقدار

اگر بخواهید چندین مقدار مختلف را در یک Secret ذخیره کنید، می‌توانید از دستور زیر استفاده کنید:

kubectl create secret generic <secret-name> \
  --from-literal=<key1>=<value1> \
  --from-literal=<key2>=<value2>

مثال:

kubectl create secret generic my-secret \
  --from-literal=password=supersecret \
  --from-literal=username=admin

این دستور یک Secret به نام my-secret ایجاد می‌کند که شامل دو کلید password و username با مقادیر مربوطه است.

ایجاد Secrets از دایرکتوری

اگر بخواهید همه فایل‌های موجود در یک دایرکتوری را به‌عنوان Secret ذخیره کنید، می‌توانید از دستور زیر استفاده کنید:

kubectl create secret generic <secret-name> --from-file=<directory-path>

مثال:

kubectl create secret generic my-secret --from-file=/path/to/configs/

این دستور یک Secret به نام my-secret ایجاد می‌کند که تمام فایل‌های موجود در دایرکتوری /path/to/configs/ را شامل می‌شود.

بررسی Secrets موجود

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

kubectl get secrets

برای مشاهده جزئیات یک Secret خاص:

kubectl describe secret <secret-name>

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

Secrets می‌توانند به‌عنوان Environment Variables یا به‌عنوان Volumes در دسترس کانتینرها قرار گیرند.

استفاده از Secret به‌عنوان Environment Variable:

برای استفاده از Secret به‌عنوان متغیر محیطی در Pod، می‌توانید آن را به این صورت تعریف کنید:

apiVersion: v1
kind: Pod
metadata:
  name: example-pod
spec:
  containers:
  - name: example-container
    image: nginx
    env:
    - name: PASSWORD
      valueFrom:
        secretKeyRef:
          name: my-secret
          key: password

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

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

شما همچنین می‌توانید Secret را به‌عنوان یک Volume در دسترس کانتینر قرار دهید:

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

در این مثال، کلیدهای موجود در Secret my-secret در دایرکتوری /etc/secret در کانتینر نصب می‌شوند.

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

اگر بخواهید یک Secret را به‌روزرسانی کنید، می‌توانید از دستور kubectl apply استفاده کنید:

kubectl apply -f <secret-file>.yaml

در صورتی که Secret‌های جدید ایجاد کرده‌اید، برای به‌روزرسانی Pod‌های مرتبط با آن‌ها نیاز به راه‌اندازی مجدد کانتینرها خواهید داشت.

حذف Secrets

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

kubectl delete secret <secret-name>

به‌این‌ترتیب، Secret حذف می‌شود و هر منبعی که به آن وابسته باشد نمی‌تواند به اطلاعات موجود در Secret دسترسی داشته باشد.

این روندها و دستورات پایه‌ای برای مدیریت و استفاده از Secrets در Kubernetes هستند که به شما کمک می‌کنند تا اطلاعات حساس را به‌طور امن ذخیره و مدیریت کنید.[/cdb_course_lesson][cdb_course_lesson title=”فصل 10. استفاده از kubectl برای مانیتورینگ”][/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مشاهده وضعیت Health منابع با kubectl get pods –show-labels” subtitle=”توضیحات کامل”]در Kubernetes، یکی از روش‌های بررسی وضعیت منابع، استفاده از دستور kubectl get pods است که به شما اجازه می‌دهد تا وضعیت Podها را مشاهده کنید. افزودن گزینه --show-labels به این دستور، به شما کمک می‌کند تا لیبل‌های مرتبط با هر Pod را نیز مشاهده کنید. این کار می‌تواند در عیب‌یابی و مدیریت منابع به‌ویژه در مواقعی که از Labels برای گروه‌بندی یا مدیریت منابع استفاده کرده‌اید، بسیار مفید باشد.

ساختار کلی دستور:

kubectl get pods --show-labels

توضیحات:

• kubectl get pods: این دستور برای نمایش فهرست تمام Pod‌ها در یک Namespace خاص (یا همه Namespace‌ها اگر مشخص نشوند) استفاده می‌شود.
• –show-labels: این گزینه به خروجی اضافه می‌کند تا لیبل‌های هر Pod نیز در کنار اطلاعات دیگر نمایش داده شوند.

خروجی دستور:

خروجی این دستور شامل نام Pod‌ها، وضعیت (Status)، و لیبل‌های هر Pod به‌طور جداگانه خواهد بود. برای مثال:

NAME              READY   STATUS    RESTARTS   AGE   LABELS
nginx-pod-1       1/1     Running   0          5m    app=nginx,env=production
nginx-pod-2       1/1     Running   0          5m    app=nginx,env=development

در اینجا:

• nginx-pod-1 و nginx-pod-2 نام‌های Pod‌ها هستند.
• Running وضعیت فعلی Pod‌ها را نشان می‌دهد.
• در ستون LABELS، لیبل‌های هر Pod شامل app=nginx و env=production یا env=development نشان داده شده است.

کاربرد‌های معمول:

• مدیریت گروه‌های مختلف از Pod‌ها: با استفاده از Labels می‌توانید Pod‌ها را بر اساس ویژگی‌های خاص (مثل محیط، نسخه، و غیره) گروه‌بندی کنید و آن‌ها را به راحتی مدیریت کنید.
• عیب‌یابی: در صورتی که بخواهید مشکلات خاصی را در محیط‌های مختلف (مثل محیط تولید یا آزمایشی) بررسی کنید، می‌توانید از لیبل‌ها برای فیلتر کردن Pod‌ها استفاده کنید.

فیلتر کردن بر اساس Labels:

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

kubectl get pods -l app=nginx --show-labels

این دستور تنها Pod‌هایی که دارای Label app=nginx هستند را نشان می‌دهد و لیبل‌های آن‌ها را نیز نمایش می‌دهد.

خلاصه:

استفاده از kubectl get pods --show-labels ابزار بسیار مفیدی برای نظارت دقیق‌تر و مدیریت منابع Kubernetes است. این دستور به شما کمک می‌کند تا نه تنها وضعیت سلامت Pod‌ها را بررسی کنید، بلکه لیبل‌های آن‌ها را نیز مشاهده کنید تا بتوانید منابع را به شکل مؤثرتری مدیریت و عیب‌یابی کنید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”مشاهده Node‌ها و وضعیت‌شان با kubectl get nodes” subtitle=”توضیحات کامل”]در کوبرنتیز، Node‌ها منابع فیزیکی یا مجازی هستند که پادها (Pods) بر روی آن‌ها اجرا می‌شوند. بررسی وضعیت Node‌ها برای نظارت بر منابع و عملکرد کلی سیستم بسیار مهم است. دستور kubectl get nodes به شما این امکان را می‌دهد که وضعیت کلی Node‌ها را مشاهده کنید و اطلاعات مهمی مثل وضعیت هر Node، تعداد پادهای در حال اجرا و منابع موجود را بررسی کنید.

ساختار کلی دستور:

kubectl get nodes

توضیحات:

• kubectl get nodes: این دستور فهرست تمام Node‌ها در کلاستر Kubernetes شما را نمایش می‌دهد.

خروجی دستور:

در اینجا، اطلاعاتی از قبیل نام Node، وضعیت، تعداد پادها، و منابع مصرفی (CPU، حافظه) در خروجی نمایش داده می‌شود. برای مثال:

NAME           STATUS   ROLES    AGE   VERSION
node-1         Ready    master   10d   v1.21.1
node-2         Ready    <none>   10d   v1.21.1
node-3         Ready    <none>   10d   v1.21.1

در اینجا:

• NAME: نام Node‌ها را نشان می‌دهد.
• STATUS: وضعیت هر Node (مانند Ready یا NotReady).
• ROLES: نقش Node در کلاستر (مثلاً master برای کنترلرها، <none> برای Node‌های عادی).
• AGE: مدت زمانی که Node در کلاستر فعال است.
• VERSION: نسخه Kubernetes که بر روی Node در حال اجرا است.

فیلتر کردن خروجی:

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

• مشاهده جزئیات بیشتر:اگر بخواهید اطلاعات دقیق‌تری از یک Node خاص مشاهده کنید، می‌توانید از دستور kubectl describe node <node-name> استفاده کنید. این دستور، جزئیات دقیقی مانند اطلاعات منابع (CPU، حافظه) و پادهای در حال اجرا را نمایش می‌دهد.مثال:

  kubectl describe node node-1
  

• مشاهده وضعیت منابع:برای مشاهده وضعیت مصرف منابع (مثل CPU و حافظه) برای هر Node، می‌توانید از پارامتر -o wide استفاده کنید:

  kubectl get nodes -o wide
  

استفاده از گزینه‌های دیگر:

1. مشاهده وضعیت Node‌های مشخص:اگر بخواهید وضعیت یک Node خاص را مشاهده کنید، کافی است نام آن را مشخص کنید:

   kubectl get node node-1
   

2. نمایش وضعیت Node‌ها با جزئیات بیشتر:شما می‌توانید از دستور kubectl describe node برای مشاهده اطلاعات دقیق‌تر، مانند وضعیت حافظه، CPU و اطلاعات سیستم استفاده کنید.

جمع بندی

استفاده از دستور kubectl get nodes ابزاری بسیار مفید برای نظارت بر وضعیت Node‌های مختلف در کلاستر Kubernetes است. با این دستور می‌توانید به‌سرعت وضعیت هر Node را بررسی کنید و اطلاعات مربوط به منابع، نقش‌ها و وضعیت کلی سیستم را مشاهده نمایید.[/cdb_course_lesson][cdb_course_lesson icon=”fas fa-arrow-alt-circle-down” badge=”lecture” private_lesson=”true” title=”نمایش وضعیت منابع با kubectl describe nodes” subtitle=”توضیحات کامل”]دستور kubectl describe nodes به شما این امکان را می‌دهد که اطلاعات دقیقی در مورد هر Node در کلاستر Kubernetes مشاهده کنید. این اطلاعات شامل منابع (CPU و حافظه) موجود، وضعیت پادها، شرایط شبکه، و جزئیات دیگری از وضعیت سیستم است. این دستور برای تجزیه و تحلیل دقیق وضعیت Node‌ها و عیب‌یابی مشکلات مختلف در کلاستر بسیار مفید است.

ساختار کلی دستور:

kubectl describe nodes <node-name>

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

kubectl describe nodes

توضیحات:

• kubectl describe nodes: این دستور اطلاعات دقیقی از وضعیت منابع (مانند CPU، حافظه) و وضعیت پادها و دیگر اجزای Node نمایش می‌دهد.

خروجی دستور:

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

1. General Information:
   • Name: نام Node
   • Labels: برچسب‌های مرتبط با Node
   • Annotations: توضیحات اضافی
   • Roles: نقش‌های Node (مثل master یا worker)
   • Creation Timestamp: زمان ایجاد Node

   مثال:

   Name:         node-1
   Roles:        <none>
   Labels:       kubernetes.io/hostname=node-1
   Annotations:  flannel.alpha.coreos.com/backend-type=vxlan
   CreationTimestamp: 2025-02-09T12:34:56Z
   

2. Status: وضعیت کلی Node را نشان می‌دهد، مثل Ready یا NotReady، که تعیین‌کننده این است که Node آماده پذیرش پاد جدید است یا نه.مثال:

   Status:       Ready
   

3. Resource Allocations: در این بخش مصرف فعلی منابع، مانند CPU و حافظه نمایش داده می‌شود.
   • Allocatable: منابع قابل اختصاص به پادها.
   • Capacity: مجموع منابع در دسترس در Node.
   • Used: مقدار استفاده‌شده از منابع.

   مثال:

   Allocatable:
     cpu:                4000m
     memory:             8192Mi
   Capacity:
     cpu:                4000m
     memory:             8192Mi
   

4. Conditions: شرایط فعلی Node مانند OutOfDisk, MemoryPressure, DiskPressure, NetworkUnavailable و وضعیت هر کدام.مثال:

   Conditions:
     Type              Status  LastHeartbeatTime     LastTransitionTime    Reason     Message
     ----              ------  ------------------     ------------------    ------     -------
     OutOfDisk         False   Thu, 09 Feb 2025 12:34:56 UTC  Thu, 09 Feb 2025 12:34:56 UTC   KubeletHasSufficientDisk  kubelet has sufficient disk space
     MemoryPressure    False   Thu, 09 Feb 2025 12:34:56 UTC  Thu, 09 Feb 2025 12:34:56 UTC   KubeletHasSufficientMemory  kubelet has sufficient memory
   

5. Pod Information: این بخش اطلاعاتی از پادهای در حال اجرا بر روی Node را نشان می‌دهد، از جمله نام پاد، وضعیت، و مصرف منابع آن‌ها.مثال:

   Non-terminated Pods:         (2 in total)
     Namespace                  Name                                        CPU Requests  CPU Limits  Memory Requests  Memory Limits
     ---------                  ----                                        ------------  ----------  ---------------  -------------
     default                    my-app-pod                                   200m (5%)     500m (12%)   512Mi (6%)      1Gi (12%)
     kube-system                kube-dns-v11-mbhnz                          100m (2%)     100m (2%)    128Mi (1%)      128Mi (1%)
   

6. Network Information: اطلاعات مربوط به شبکه و آدرس‌های IP و ارتباطات بین Node‌ها.مثال:

   Network:
     IPs:         192.168.1.10
     ExternalIP:  <none>
     Hostname:    node-1
   

فیلتر کردن خروجی:

برای مشاهده اطلاعات دقیق‌تر، می‌توانید از پارامترهای اضافی مانند -o wide برای نمایش جزئیات بیشتر استفاده کنید:

kubectl describe nodes -o wide

خلاصه:

دستور kubectl describe nodes اطلاعات دقیقی از وضعیت هر Node در کلاستر Kubernetes به شما می‌دهد. این اطلاعات شامل وضعیت منابع (CPU، حافظه)، شرایط مختلف (مثل فشار حافظه یا دیسک)، و وضعیت پادهای در حال اجرا است. با استفاده از این دستور می‌توانید مشکلات سیستم را شناسایی و برای رفع آن‌ها اقدامات لازم را انجام دهید.[/cdb_course_lesson][/cdb_course_lessons]