Pods چند کانتینری Kubernetes: الگوهای Sidecar، Adapter و Ambassador

Summarize this content to 400 words in Persian Lang
پادهای Kubernetes کوچکترین واحدهای قابل استقرار هستند، و در حالی که اکثر برنامه ها از غلاف های تک کانتینری استفاده می کنند، Kubernetes نیز پشتیبانی می کند غلاف های چند کانتینری. این غلاف ها حاوی چندین کانتینر هستند که منابع را به اشتراک می گذارند و برای رسیدن به یک هدف مشترک تعامل نزدیک دارند.

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

چرا از غلاف های چند کانتینری استفاده کنیم؟

غلاف های چند کانتینر زمانی مفید هستند که ظروف:

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

مفاهیم کلیدی غلاف های چند کانتینری

فضای ذخیره سازی مشترک: ظروف در یک غلاف می توانند حجم یکسانی داشته باشند.

شبکه اشتراکی: کانتینرهای داخل یک پاد آدرس IP یکسانی دارند و می توانند از طریق آن ارتباط برقرار کنند localhost.

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

الگوهای طراحی متداول برای غلاف های چند کانتینری

1. الگوی ماشین کناری

این الگوی ماشین کناری زمانی استفاده می شود که یک ظرف ثانویه عملکرد برنامه اولیه را افزایش داده یا گسترش دهد. موارد استفاده رایج عبارتند از:

مجموعه گزارش (به عنوان مثال، Fluentd).
همگام سازی داده ها
کشف سرویس یا به‌روزرسانی‌های پیکربندی.

مثال: Nginx با یک Sidecar برای حمل و نقل گزارش

مرحله 1: فایل Pod YAML را تعریف کنید.

apiVersion: v1
kind: Pod
metadata:
name: sidecar-pod
spec:
containers:
– name: nginx
image: nginx
volumeMounts:
– mountPath: /var/log/nginx
name: shared-logs
– name: log-collector
image: busybox
command: [“/bin/sh”, “-c”] args: [“tail -f /var/log/nginx/access.log”] volumeMounts:
– mountPath: /var/log/nginx
name: shared-logs
volumes:
– name: shared-logs
emptyDir: {}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مرحله 2: Pod را مستقر کنید.

kubectl apply -f sidecar-pod.yaml

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مرحله 3: بررسی گزارش ها.

kubectl logs sidecar-pod -c log-collector

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

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

2. الگوی آداپتور

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

جمع آوری و تبدیل معیارها
پل زدن پروتکل های ارتباطی

مثال: آداپتور برای تبدیل معیارها

مرحله 1: فایل Pod YAML را تعریف کنید.

apiVersion: v1
kind: Pod
metadata:
name: adapter-pod
spec:
containers:
– name: app
image: busybox
command: [“/bin/sh”, “-c”] args: [“while true; do echo ‘{\”metric\”: 100}’ > /data/metrics.json; sleep 5; done”] volumeMounts:
– mountPath: /data
name: shared-data
– name: adapter
image: busybox
command: [“/bin/sh”, “-c”] args: [“while true; do cat /data/metrics.json | jq ‘.metric’; sleep 5; done”] volumeMounts:
– mountPath: /data
name: shared-data
volumes:
– name: shared-data
emptyDir: {}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مرحله 2: Pod را مستقر کنید.

kubectl apply -f adapter-pod.yaml

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مرحله 3: بررسی تبدیل متریک.

kubectl logs adapter-pod -c adapter

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این آداپتور کانتینر داده های متریک تولید شده توسط را می خواند و پردازش می کند برنامه ظرف

3. الگوی سفیر

این الگوی سفیر به عنوان یک پروکسی بین کانتینر اولیه و سیستم ها یا سرویس های خارجی عمل می کند. این الگو معمولاً برای موارد زیر استفاده می شود:

ارتباط API
پروکسی های سرویس
مسیریابی سفارشی

مثال: Ambassador for External API Calls

مرحله 1: فایل Pod YAML را تعریف کنید.

apiVersion: v1
kind: Pod
metadata:
name: ambassador-pod
spec:
containers:
– name: app
image: busybox
command: [“/bin/sh”, “-c”] args: [“while true; do wget -qO- http://localhost:8080/api; sleep 5; done”] – name: ambassador
image: nginx
ports:
– containerPort: 8080
volumeMounts:
– mountPath: /etc/nginx/conf.d
name: nginx-config
volumes:
– name: nginx-config
configMap:
name: ambassador-config
—
apiVersion: v1
kind: ConfigMap
metadata:
name: ambassador-config
data:
default.conf: |
server {
listen 8080;
location /api {
proxy_pass http://api.example.com;
}
}

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مرحله 2: ConfigMap و Pod را مستقر کنید.

kubectl apply -f ambassador-pod.yaml

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

مرحله 3: بررسی رفتار پروکسی.

kubectl logs ambassador-pod -c app

وارد حالت تمام صفحه شوید

از حالت تمام صفحه خارج شوید

این برنامه کانتینر با سفیر ظرفی که درخواست را پروکسی می کند http://api.example.com.

خلاصه عملی

مراحل پیاده سازی Multi-Container Pods:

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

بهترین روش ها برای غلاف های چند کانتینری

مسئولیت های روشن را تعریف کنید: از همپوشانی نقش ها بین ظروف خودداری کنید.

از منابع مشترک به طور موثر استفاده کنید: از حجم های مشترک و شبکه برای تعامل کانتینر استفاده کنید.

نظارت بر عملکرد: غلاف های چند کانتینری می توانند منابع فشرده باشند. نظارت بر استفاده از منابع برای جلوگیری از تنگناها

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

نتیجه گیری

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

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
    - mountPath: /var/log/nginx
      name: shared-logs
  - name: log-collector
    image: busybox
    command: ["/bin/sh", "-c"]
    args: ["tail -f /var/log/nginx/access.log"]
    volumeMounts:
    - mountPath: /var/log/nginx
      name: shared-logs
  volumes:
  - name: shared-logs
    emptyDir: {}

kubectl apply -f sidecar-pod.yaml

kubectl logs sidecar-pod -c log-collector

apiVersion: v1
kind: Pod
metadata:
  name: adapter-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["/bin/sh", "-c"]
    args: ["while true; do echo '{\"metric\": 100}' > /data/metrics.json; sleep 5; done"]
    volumeMounts:
    - mountPath: /data
      name: shared-data
  - name: adapter
    image: busybox
    command: ["/bin/sh", "-c"]
    args: ["while true; do cat /data/metrics.json | jq '.metric'; sleep 5; done"]
    volumeMounts:
    - mountPath: /data
      name: shared-data
  volumes:
  - name: shared-data
    emptyDir: {}

kubectl apply -f adapter-pod.yaml

kubectl logs adapter-pod -c adapter

apiVersion: v1
kind: Pod
metadata:
  name: ambassador-pod
spec:
  containers:
  - name: app
    image: busybox
    command: ["/bin/sh", "-c"]
    args: ["while true; do wget -qO- http://localhost:8080/api; sleep 5; done"]
  - name: ambassador
    image: nginx
    ports:
    - containerPort: 8080
    volumeMounts:
    - mountPath: /etc/nginx/conf.d
      name: nginx-config
  volumes:
  - name: nginx-config
    configMap:
      name: ambassador-config
---
apiVersion: v1
kind: ConfigMap
metadata:
  name: ambassador-config
data:
  default.conf: |
    server {
      listen 8080;
      location /api {
        proxy_pass http://api.example.com;
      }
    }

kubectl apply -f ambassador-pod.yaml

kubectl logs ambassador-pod -c app