برنامه نویسی

Kubernetes Service Mesh

ارسال شده توسط author-avatar
0
Kubernetes Service Mesh

15 دقیقه زمان برای خواندن این مطلب نیاز است.

فهرست مطالب

Kubernetes Service Mesh

در دنیای مدرن میکروسرویس‌ها و Kubernetes، مدیریت ارتباطات شبکه بین سرویس‌ها به یکی از پیچیده‌ترین چالش‌ها تبدیل شده است. وقتی تعداد سرویس‌های شما از چند عدد به چند ده یا چند صد عدد می‌رسد، مسائلی مانند مشاهده‌پذیری (Observability)، امنیت (Security)، کنترل ترافیک (Traffic Control)، و قابلیت اطمینان (Reliability) به طور تصاعدی دشوارتر می‌شوند. اینجاست که Kubernetes Service Mesh وارد می‌شود. Kubernetes Service Mesh یک لایه زیرساختی است که ارتباطات بین سرویس‌ها را در یک کلاستر Kubernetes مدیریت می‌کند. این لایه قابلیت‌های پیشرفته‌ای مانند لودبالانسینگ هوشمند، Circuit Breaking، Retry و Timeout، مشاهده‌پذیری کامل (مشاهده Metrics، Tracing، Logs)، امنیت mTLS بین سرویس‌ها، و کنترل دقیق ترافیک (مثل Canary Deployment و Blue-Green Deployment) را بدون نیاز به تغییر کد برنامه فراهم می‌کند. در این مقاله جامع و تخصصی از داناپدیا، به بررسی عمیق Kubernetes Service Mesh می‌پردازیم. از مفاهیم پایه و معماری (Data Plane و Control Plane) گرفته تا معرفی محبوب‌ترین Service Meshها (Istio، Linkerd، Consul)، مقایسه آن‌ها، نصب و پیکربندی، قابلیت‌های کلیدی (mTLS، مشاهده‌پذیری، ترافیک شکستن)، سناریوهای عملی (Canary Release، A/B Testing)، و یک پروژه عملی کامل. اگر به دنبال درک عمیق و تخصصی Kubernetes Service Mesh هستید، تا انتهای این مقاله از داناپدیا با ما همراه باشید.

CSS Custom Properties در React

Service Mesh چیست و چرا به آن نیاز داریم؟

در معماری میکروسرویس‌ها، هر سرویس برای انجام وظیفه خود نیاز به برقراری ارتباط با سرویس‌های دیگر دارد (مثلاً سرویس سفارش با سرویس انبار و سرویس پرداخت). در ابتدا، توسعه‌دهندگان این منطق شبکه (مانند Retry، Timeout، Circuit Breaker، Load Balancing) را درون کد خود پیاده‌سازی می‌کردند. این روش منجر به تکرار کد (Code Duplication)، وابستگی زبان برنامه‌نویسی، و پیچیدگی بالا می‌شد. Kubernetes Service Mesh این منطق را از کد برنامه خارج کرده و به یک لایه زیرساختی مجزا (شبکه) منتقل می‌کند.

معماری Service Mesh

یک Kubernetes Service Mesh از دو بخش اصلی تشکیل شده است:

  1. Data Plane (صفحه داده): متشکل از Proxyهای سبک (مثل Envoy، Linkerd-proxy) که به عنوان sidecar در کنار هر پاد (Pod) سرویس شما قرار می‌گیرند. تمام ترافیک ورودی و خروجی پاد از این proxy عبور می‌کند. Proxyها مسئول مسیریابی، مشاهده‌پذیری، امنیت و کنترل ترافیک هستند.
  2. Control Plane (صفحه کنترل): مسئول مدیریت و پیکربندی proxyها است. کنترل پلن خط مشی‌ها (Policies)، قوانین مسیریابی، و گواهی‌های امنیتی را برای proxyها ارسال می‌کند.

مزایای کلیدی استفاده از Service Mesh در Kubernetes

  • جداسازی دغدغه‌ها (Separation of Concerns): تیم توسعه فقط روی منطق کسب‌وکار تمرکز می‌کند، تیم زیرساخت روی شبکه.
  • مشاهده‌پذیری پیشرفته (Advanced Observability): متریک‌های غنی (میزان موفقیت، تأخیر، حجم ترافیک)، توزیع‌شده tracing، و لاگ‌های ترافیک به صورت خودکار جمع‌آوری می‌شوند.
  • امنیت صفر اعتماد (Zero-Trust Security): احراز هویت و رمزگذاری mTLS بین همه سرویس‌ها به صورت پیش‌فرض.
  • کنترل ترافیک هوشمند: Canary Release، A/B Testing، Blue-Green Deployment، و Mirroring ترافیک بدون تغییر کد.
  • قابلیت اطمینان (Resilience): Retry، Timeout، Circuit Breaker، و Bulkheading به صورت خودکار اعمال می‌شوند.
  • سازگاری با چندین زبان: از آنجا که proxy مستقل از کد است، سرویس‌های نوشته شده با هر زبان (Go، Java، Python، Node.js، و غیره) از قابلیت‌های Service Mesh بهره‌مند می‌شوند.

SQL COALESCE Function

مقایسه محبوب‌ترین Kubernetes Service Meshها

سه Service Mesh محبوب در اکوسیستم Kubernetes وجود دارند. در ادامه به مقایسه Kubernetes Service Meshهای اصلی می‌پردازیم.

جدول مقایسه Istio، Linkerd و Consul

ویژگیIstioLinkerdConsul (HashiCorp)
Proxy پیش‌فرضEnvoy (C++)Linkerd2-proxy (Rust)Envoy یا Consul Proxy
عملکردنسبتاً سنگین (به دلیل Envoy)بسیار سبک و سریعمتوسط
مصرف منابعبالاپایین (تا ۵ برابر کمتر از Istio)متوسط
پیچیدگی نصببالا (نیاز به آشنایی با CRDها)ساده (یک دستور CLI)متوسط
قابلیت mTLSدارد (پیشرفته)دارد (ساده)دارد (یکپارچه با Consul)
مشاهده‌پذیریبسیار قوی (Kiali, Jaeger, Grafana)خوب (Grafana, Viz extension)متوسط (یکپارچه با ابزارهای HashiCorp)
کنترل ترافیکبسیار قدرتمند (VirtualService, DestinationRule)محدودتر (پشتیبانی از قابلیت‌های پایه)خوب
محبوبیتبسیار بالابالامتوسط
مستنداتعالیعالیخوب
موارد استفادهسازمان‌های بزرگ با نیازهای پیشرفتهتیم‌هایی که سادگی و عملکرد اولویت دارندسازمان‌هایی که از قبل Consul استفاده می‌کنند

توصیه داناپدیا

  • اگر تازه‌کار هستید یا منابع محدودی دارید → از Linkerd شروع کنید.
  • اگر به کنترل ترافیک پیشرفته (مثل مسیریابی بر اساس header، وزن‌دهی پیچیده) نیاز دارید → Istio انتخاب مناسبی است.
  • اگر از قبل از Consul برای سرویس‌دیسکاوری استفاده می‌کنید → Consul Service Mesh بهترین یکپارچگی را دارد.

Bun Test Runner

Kubernetes Service Mesh

نصب و راه‌اندازی Linkerd (ساده‌ترین Service Mesh)

بیایید با ساده‌ترین Kubernetes Service Mesh یعنی Linkerd شروع کنیم.

مرحله 1: نصب CLI Linkerd

# لینوکس / macOS
curl --proto '=https' --tlsv1.2 -sSfL https://run.linkerd.io/install | sh
export PATH=$PATH:$HOME/.linkerd2/bin

# ویندوز (با chocolatey)
choco install linkerd2

# تأیید نصب
linkerd version

مرحله 2: نصب Linkerd روی کلاستر Kubernetes

# بررسی پیش‌نیازها
linkerd check --pre

# نصب کنترل پلن
linkerd install | kubectl apply -f -

# بررسی وضعیت
linkerd check

# مشاهده داشبورد Linkerd
linkerd viz install | kubectl apply -f -
linkerd viz dashboard

مرحله 3: افزودن Service Mesh به یک اپلیکیشن

# فرض کنید یک اپلیکیشن به نام emojivoto دارید
kubectl create ns emojivoto

# تزریق proxy به عنوان sidecar به پادها
linkerd inject https://run.linkerd.io/emojivoto.yml | kubectl apply -n emojivoto -f -

# بررسی اینکه proxyها با موفقیت تزریق شده‌اند
kubectl -n emojivoto get pods
# خروجی باید شامل ۲ کانتینر در هر پاد باشد (main + linkerd-proxy)

مرحله 4: مشاهده متریک‌ها

linkerd viz dashboard &

داشبورد Linkerd در مرورگر باز می‌شود و می‌توانید نرخ موفقیت (Success Rate)، درخواست در ثانیه (RPS)، و تأخیر (Latency) بین سرویس‌ها را مشاهده کنید.

PostgreSQL JSONB توابع

قابلیت‌های کلیدی Kubernetes Service Mesh

حالا که یک Service Mesh نصب کردید، بیایید قابلیت‌های کلیدی آن را بررسی کنیم.

1. احراز هویت و رمزگذاری mTLS (امنیت صفر اعتماد)

در یک Kubernetes Service Mesh، ارتباط بین سرویس‌ها به صورت پیش‌فرض با mTLS (Mutual TLS) رمزگذاری و احراز هویت می‌شود. هر سرویس یک هویت (SPIFFE ID) دارد و فقط سرویس‌های مجاز می‌توانند با یکدیگر ارتباط برقرار کنند.

در Istio (پیکربندی mTLS همگانی):

apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: default
spec:
  mtls:
    mode: STRICT  # همه ارتباطات باید mTLS داشته باشند

در Linkerd (به صورت پیش‌فرض فعال است):

# بررسی وضعیت mTLS
linkerd viz edges -n emojivoto deployment

2. مشاهده‌پذیری (Observability) پیشرفته

Service Mesh به طور خودکار سه رکن مشاهده‌پذیری را بدون نیاز به instrumentation در کد فراهم می‌کند:

  • متریک (Metrics): نرخ موفقیت، تأخیر (p50, p95, p99)، حجم ترافیک بین هر جفت سرویس.
  • توزیع‌شده Tracing (Distributed Tracing): ردگیری یک درخواست در طول زنجیره سرویس‌ها.
  • لاگ (Logs): لاگ ترافیک (که کجا رفت، چه status code برگشت).

مثال مشاهده Tracing در Istio با Jaeger:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/release-1.20/samples/addons/jaeger.yaml
kubectl port-forward -n istio-system service/jaeger-query 16686:16686
# سپس در مرورگر http://localhost:16686

3. کنترل ترافیک (Traffic Management)

Service Mesh به شما اجازه می‌دهد ترافیک بین سرویس‌ها را به صورت دقیق کنترل کنید.

مثال: Canary Deployment با Istio (۱۰٪ ترافیک به نسخه جدید)

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: reviews
spec:
  host: reviews
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

مثال: Circuit Breaker با Linkerd

Linkerd به صورت خودکار Circuit Breaker را بر اساس نرخ شکست (error rate) اعمال می‌کند. می‌توانید آن را با ServiceProfile پیکربندی کنید:

apiVersion: linkerd.io/v1alpha2
kind: ServiceProfile
metadata:
  name: my-service.default.svc.cluster.local
spec:
  routes:
  - name: GET /api
    condition:
      method: GET
      pathRegex: /api
    isRetryable: true
    timeout: 10s

4. قابلیت اطمینان (Resilience)

Service Mesh به طور خودکار قابلیت‌های زیر را به برنامه شما اضافه می‌کند:

  • Retry: تلاش مجدد در صورت خطای موقتی (مثل 503).
  • Timeout: قطع درخواست‌هایی که بیش از حد طول می‌کشند.
  • Circuit Breaker: قطع ارتباط با سرویسی که بیش از حد خطا دارد.
  • Rate Limiting: محدود کردن نرخ درخواست‌ها.

WebSocket در Django Channels

پروژه عملی کامل: استقرار یک میکروسرویس با Istio Service Mesh

حالا که با مفاهیم Kubernetes Service Mesh آشنا شدید، بیایید یک پروژه عملی کامل در داناپدیا انجام دهیم: استقرار یک اپلیکیشن ساده متشکل از سه سرویس (Frontend، Backend، Database) با قابلیت‌های Canary Release، mTLS، و مشاهده‌پذیری کامل.

مرحله 1: نصب Istio

# دانلود نسخه پایدار Istio
curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.0 sh -
cd istio-1.20.0
export PATH=$PWD/bin:$PATH

# نصب Istio با پروفایل demo (برای توسعه)
istioctl install --set profile=demo -y

# نصب افزونه‌های مشاهده‌پذیری (Kiali, Prometheus, Grafana, Jaeger)
kubectl apply -f samples/addons
kubectl rollout status deployment/kiali -n istio-system

مرحله 2: فعال کردن Sidecar Injection خودکار

# ایجاد namespace با برچسب برای تزریق خودکار
kubectl create namespace danapedia-apps
kubectl label namespace danapedia-apps istio-injection=enabled

مرحله 3: استقرار سرویس Backend (با دو نسخه)

فایل backend-v1.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-v1
  namespace: danapedia-apps
spec:
  replicas: 2
  selector:
    matchLabels:
      app: backend
      version: v1
  template:
    metadata:
      labels:
        app: backend
        version: v1
    spec:
      containers:
      - name: backend
        image: danapedia/backend:1.0
        ports:
        - containerPort: 8080
        env:
        - name: VERSION
          value: "v1"
---
apiVersion: v1
kind: Service
metadata:
  name: backend
  namespace: danapedia-apps
spec:
  selector:
    app: backend
  ports:
  - port: 8080
    targetPort: 8080

فایل backend-v2.yaml (نسخه جدید با تغییر پاسخ):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-v2
  namespace: danapedia-apps
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backend
      version: v2
  template:
    metadata:
      labels:
        app: backend
        version: v2
    spec:
      containers:
      - name: backend
        image: danapedia/backend:2.0
        ports:
        - containerPort: 8080
        env:
        - name: VERSION
          value: "v2"

استقرار:

kubectl apply -f backend-v1.yaml
kubectl apply -f backend-v2.yaml

مرحله 4: پیکربندی VirtualService برای Canary Release

فایل backend-virtualservice.yaml:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: backend
  namespace: danapedia-apps
spec:
  hosts:
  - backend
  http:
  - match:
    - headers:
        x-canary:
          exact: "true"
    route:
    - destination:
        host: backend
        subset: v2
      weight: 100
  - route:
    - destination:
        host: backend
        subset: v1
      weight: 90
    - destination:
        host: backend
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata:
  name: backend
  namespace: danapedia-apps
spec:
  host: backend
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 100
    outlierDetection:
      consecutive5xxErrors: 5
      interval: 30s
      baseEjectionTime: 60s

اعمال:

kubectl apply -f backend-virtualservice.yaml

مرحله 5: استقرار سرویس Frontend

فایل frontend.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: frontend
  namespace: danapedia-apps
spec:
  replicas: 2
  selector:
    matchLabels:
      app: frontend
  template:
    metadata:
      labels:
        app: frontend
    spec:
      containers:
      - name: frontend
        image: danapedia/frontend:1.0
        ports:
        - containerPort: 80
        env:
        - name: BACKEND_URL
          value: "http://backend:8080"
---
apiVersion: v1
kind: Service
metadata:
  name: frontend
  namespace: danapedia-apps
spec:
  selector:
    app: frontend
  ports:
  - port: 80
    targetPort: 80
---
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: danapedia-gateway
  namespace: danapedia-apps
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: frontend
  namespace: danapedia-apps
spec:
  hosts:
  - "*"
  gateways:
  - danapedia-gateway
  http:
  - match:
    - uri:
        prefix: /
    route:
    - destination:
        host: frontend
        port:
          number: 80

استقرار:

kubectl apply -f frontend.yaml

مرحله 6: تست Canary Release

# دریافت آدرس IP اینگریس
kubectl get svc istio-ingressgateway -n istio-system

# ارسال درخواست عادی (۹۰٪ v1، ۱۰٪ v2)
for i in {1..100}; do curl http://<INGRESS_IP>/; done

# ارسال درخواست با هدر x-canary (۱۰۰٪ به v2)
curl -H "x-canary: true" http://<INGRESS_IP>/

مرحله 7: مشاهده متریک‌ها با Kiali

# اجرای Kiali
istioctl dashboard kiali

در Kiali می‌توانید:

  • توپولوژی سرویس‌ها (گراف ارتباطی) را ببینید.
  • نرخ خطا و تأخیر بین هر جفت سرویس را مشاهده کنید.
  • جزییات درخواست‌ها (که آیا به v1 رفت یا v2) را بررسی کنید.

مرحله 8: فعال کردن mTLS همگانی

kubectl apply -f - <<EOF
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default
  namespace: danapedia-apps
spec:
  mtls:
    mode: STRICT
EOF

از این لحظه به بعد، تمام ارتباطات بین سرویس‌ها رمزگذاری و احراز هویت می‌شوند.

CQRS با MediatR

چالش‌ها و محدودیت‌های Service Mesh

با وجود تمام مزایا، Kubernetes Service Mesh بدون چالش نیست:

  1. پیچیدگی (Complexity): Istio به خصوص دارای منحنی یادگیری تندی است.
  2. مصرف منابع (Resource Overhead): هر پاد یک proxy sidecar مصرف می‌کند (معمولاً ۵۰-۱۰۰ مگابایت رم و ۰.۱-۰.۵ CPU core). برای هزاران پاد، این مقدار قابل توجه است.
  3. تأخیر اضافی (Latency Overhead): عبور ترافیک از یک proxy اضافی، چند میلی‌ثانیه تأخیر اضافه می‌کند.
  4. اشکال‌زدایی (Debugging) دشوارتر: وقتی خطایی رخ می‌دهد، تشخیص اینکه مشکل از برنامه است، proxy است، یا کنترل پلن، سخت‌تر می‌شود.
  5. مناسب برای همه برنامه‌ها نیست: برای برنامه‌های ساده با تعداد سرویس کم (مثلاً ۳-۵ سرویس)، سربار Service Mesh ارزشش را ندارد.

CSS Anchor Positioning

بهترین شیوه‌ها در Kubernetes Service Mesh

داناپدیا این بهترین شیوه‌ها را برای استفاده موفق از Service Mesh توصیه می‌کند:

  1. از کوچک شروع کنید: ابتدا Service Mesh را روی یک namespace غیرتولیدی (مثل staging) پیاده‌سازی کنید.
  2. به تدریج فعال کنید: همه سرویس‌ها را یکجا به mesh اضافه نکنید. یکی یکی پیش بروید.
  3. منابع را مانیتور کنید: مصرف CPU و رم proxyها را زیر نظر داشته باشید.
  4. از ابزارهای مشاهده‌پذیری استفاده کنید: Kiali، Jaeger، و Grafana را برای درک رفتار سیستم نصب کنید.
  5. مستندسازی کنید: قوانین مسیریابی، سیاست‌های امنیتی، و پیکربندی‌های Service Mesh را در Git ذخیره کنید.
  6. آموزش تیم: Service Mesh یک ابزار تخصصی است. تیم خود را آموزش دهید.
  7. برای محیط‌های مختلف، پروفایل جداگانه: در توسعه، پروفایل demo، در تولید پروفایل production (با replicas بیشتر برای کنترل پلن).

React Native Expo Router

جمع‌بندی نهایی از داناپدیا

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

در این مقاله از داناپدیا، ما سفری کامل داشتیم: از مفاهیم پایه Service Mesh و معماری Data Plane/Control Plane گرفته تا مقایسه ابزارهای محبوب (Istio، Linkerd، Consul)، نصب Linkerd، قابلیت‌های کلیدی (mTLS، مشاهده‌پذیری، کنترل ترافیک، قابلیت اطمینان)، یک پروژه عملی کامل با Istio (شامل Canary Release، Gateway، VirtualService، Kiali)، و چالش‌ها و بهترین شیوه‌ها. اکنون شما دانش کافی را دارید تا تصمیم بگیرید که آیا به Service Mesh نیاز دارید و اگر آری، چگونه آن را پیاده‌سازی کنید.

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

MySQL Performance Schema

Kubernetes Service Mesh

سوالات متداول (FAQ) درباره Kubernetes Service Mesh

سوال ۱: آیا Service Mesh جای Ingress Controller (مثل NGINX Ingress) را می‌گیرد؟

پاسخ: خیر، مکمل هستند. Ingress Controller ترافیک ورودی به کلاستر (از خارج) را مدیریت می‌کند. Service Mesh ترافیک داخل کلاستر (بین سرویس‌ها) را مدیریت می‌کند. در بسیاری از معماری‌ها، ترافیک ابتدا به Ingress Controller می‌رسد، سپس به سرویس اول می‌رود، و از آنجا به سرویس‌های دیگر (از طریق Service Mesh) منتقل می‌شود. همچنین می‌توانید از Service Mesh به عنوان Ingress نیز استفاده کنید (مثلاً Istio Gateway).

سوال ۲: آیا Service Mesh فقط برای Kubernetes است؟

پاسخ: خیر، اما محبوب‌ترین پیاده‌سازی‌ها (Istio، Linkerd، Consul) بهینه‌ترین یکپارچگی را با Kubernetes دارند. برخی Service Meshها (مانند Consul) روی ماشین‌های مجازی معمولی نیز کار می‌کنند، اما Kubernetes به دلیل قابلیت sidecar injection، محیط ایده‌آل‌تری است.

سوال ۳: آیا Sidecar Proxy باعث افزایش تأخیر (Latency) می‌شود؟

پاسخ: بله، معمولاً ۲ تا ۱۰ میلی‌ثانیه تأخیر اضافه می‌کند (بسته به proxy و پیکربندی). برای اکثر برنامه‌های کسب‌وکاری، این مقدار قابل قبول است. برای برنامه‌های فوق‌العاده حساس به تأخیر (مثل معاملات مالی با فرکانس بالا)، ممکن است مشکل‌ساز باشد.

سوال ۴: آیا می‌توانم فقط برخی از قابلیت‌های Service Mesh را فعال کنم (مثلاً فقط مشاهده‌پذیری بدون mTLS)؟

پاسخ: بله، کاملاً. در Istio می‌توانید mTLS را خاموش کنید (mode: PERMISSIVE یا DISABLE). در Linkerd نیز mTLS پیش‌فرض است اما می‌توان آن را غیرفعال کرد. بسیاری از تیم‌ها ابتدا فقط مشاهده‌پذیری را فعال می‌کنند و بعداً mTLS و کنترل ترافیک را اضافه می‌کنند.

سوال ۵: هزینه اضافه کردن Service Mesh به کلاستر Kubernetes چقدر است؟

پاسخ: هزینه‌ها شامل موارد زیر است:

  • منابع محاسباتی: هر پاد حدود ۵۰-۲۰۰ مگابایت رم اضافه و ۰.۱-۰.۵ هسته CPU (بسته به ترافیک). برای ۱۰۰ پاد، حدود ۱۰-۲۰ گیگابایت رم و ۱۰-۵۰ هسته CPU اضافه.
  • پیچیدگی عملیاتی: نیاز به تیم یا افراد متخصص برای مدیریت.
  • زمان یادگیری: منحنی یادگیری تند (مخصوصاً برای Istio).

برای پروژه‌های کوچک (کمتر از ۲۰ سرویس)، معمولاً Service Mesh ارزش اقتصادی ندارد.

سوال ۶: تفاوت بین Service Mesh و API Gateway چیست؟

پاسخ:

  • API Gateway: در لبه (edge) قرار دارد، ترافیک خارجی را مدیریت می‌کند، احراز هویت، rate limiting، تبدیل پروتکل و aggregation را انجام می‌دهد (مثل Kong، Ambassador، Tyk).
  • Service Mesh: داخل کلاستر قرار دارد، ترافیک بین سرویس‌ها را مدیریت می‌کند، mTLS، مشاهده‌پذیری، retry، timeout، circuit breaker و canary deployment را انجام می‌دهد.

در عمل، برخی محصولات (مثل Ambassador) هم API Gateway هستند هم Service Mesh (با استفاده از Envoy).

تست Regression چیست

جدیدتر
Container Queries در CSS
قدیمی‌تر پایتون Type Hints

دیدگاهتان را بنویسید