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

Istio محبوب‌ترین و غنی‌ترین پاسخ در این فضا است:

Service Mesh. Simplified. — Easily build cloud native workloads securely and reliably with Istio, with or without sidecars.

شعار جدید مهم است: دیگر فقط sidecar نیست. با ambient mode (GA از v1.24) می‌توانید L4 را سبک و L7 را انتخابی بگیرید.

نسخه اعلام‌شده روی سایت: Istio 1.31. بنیان‌گذاران: Google، IBM، Lyft (۲۰۱۶). CNCF Graduated (ژوئیه ۲۰۲۳؛ پیش‌تر Incubating از سپتامبر ۲۰۲۲). کاربران: Airbnb، eBay، Salesforce، Splunk، Atlassian، T-Mobile و ده‌ها سازمان دیگر.

Service mesh چیست؟ (و Istio کجا می‌نشیند)

Service mesh لایه زیرساختی است که به اپ‌ها می‌دهد:

• zero-trust (mTLS، identity، authorization)
• observability (متریک، trace، log ترافیک)
• traffic management (canary، retry، timeout، fault injection)

بدون تغییر business logic.

Istio این قابلیت‌ها را با application-aware network روی Kubernetes (و VMها) پیاده می‌کند — قابل برنامه‌ریزی با CRDها و Gateway API.

دو حالت Data Plane

طبق مستندات Istio:

۱. Sidecar mode (کلاسیک)

هر Pod → Envoy sidecar
  ترافیک in/out از Envoy می‌گذرد

• حداکثر انعطاف L7 per-pod
• هزینه: CPU/RAM × تعداد Pod (sidecar tax)
• بالغ‌ترین مسیر feature برای سال‌ها

۲. Ambient mode (GA از v1.24)

هر Node → ztunnel (L4 / mTLS / telemetry ساده)
Namespace یا سرویس‌های نیازمند L7 → waypoint (Envoy)

مزیت اعلام‌شده: در سناریوهای L4-only صرفه‌جویی حافظه می‌تواند بیش از ۹۰٪ نسبت به sidecar باشد؛ با waypoint هنوز صرفه‌جویی قابل‌توجه در برابر «یک Envoy per Pod».

کارloadهای ambient و sidecar می‌توانند در یک mesh همزیستی و تدریجی migrate شوند.

معماری Control Plane

istiod (unified control plane)
  ├── xDS → Envoy sidecars / waypoints
  ├── CA / identity → mTLS certificates
  └── config from K8s CRDs + Gateway API

Data plane:
  sidecars  OR  ztunnel (+ optional waypoints)
  + Ingress/Egress Gateways

تاریخچه: اجزای قدیمی‌تر (Pilot، Citadel، Galley) در istiod ادغام شدند — یک باینری/Deployment ساده‌تر برای ops.

Envoy قلب L7 است؛ برای جزئیات proxy به مقاله Envoy مراجعه کنید. ztunnel برای L4 با طراحی سبک‌تر (Rust در معماری ambient) از sidecar کامل Envoy جدا است.

قابلیت‌های اصلی

Security

• mTLS خودکار بین workloadها
• workload identity (SPIFFE-style)
• AuthorizationPolicy (L4 و L7)
• PeerAuthentication، RequestAuthentication (JWT و …)
• مدل BeyondProd / zero-trust بدون قفل به یک vendor

Traffic management

• VirtualService / DestinationRule (مدل کلاسیک Istio)
• canary، A/B، traffic split درصدی
• retry، timeout، circuit breaking، outlier detection
• fault injection برای تست chaos
• Gateway و ادغام Kubernetes Gateway API
• multi-cluster / hybrid / VM در یک mesh

Observability

• متریک استاندارد (Prometheus)
• distributed tracing (Zipkin، Jaeger، OpenTelemetry)
• access logs
• یکپارچگی با Grafana و APMها

Extensibility

• Wasm روی Envoy
• ادغام policy خارجی
• اکوسیستم vendor: Google Cloud، IBM، Red Hat، Azure، Solo.io، Tetrate، Huawei، VMware، …

منابع پیکربندی رایج

نمونه canary مفهومی:

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts: [reviews]
  http:
  - route:
    - destination:
        host: reviews
        subset: v1
      weight: 90
    - destination:
        host: reviews
        subset: v2
      weight: 10

نصب سریع

پیش‌نیاز

• Kubernetes cluster
• istioctl هم‌نسخه با control plane هدف

# دریافت istioctl — از istio.io/latest/docs راهنمای نسخه روز
istioctl x precheck

Sidecar profile نمونه

istioctl install --set profile=default -y
kubectl label namespace default istio-injection=enabled
# deploy apps — sidecar inject می‌شود
istioctl analyze

Ambient

istioctl install --set profile=ambient -y
# اضافه کردن namespace به ambient (طبق docs نسخه شما)
# سپس در صورت نیاز waypoint برای L7
istioctl waypoint apply -n my-ns

Helm نیز پشتیبانی می‌شود. برای production: HA istiod، resource limits، و مسیر upgrade رسمی نسخه به نسخه.

Ingress: Istio Ingress Gateway یا Gateway API — می‌تواند به workloadهای ambient وصل شود.

مقایسه جامع: Istio در برابر meshهای دیگر

جدول یک‌نگاه

Istio در برابر Linkerd (جزئی)

هر دو Graduated و production-provenاند — تفاوت در عمق در برابر سادگی است، نه «کدام امن‌تر مطلق».

Istio در برابر Cilium Service Mesh

خیلی تیم‌ها Cilium برای CNI و Istio/Linkerd برای mesh را ترکیب کرده‌اند؛ با Cilium mesh ممکن است یکی شوند — معماری را آگاهانه انتخاب کنید.

Istio در برابر Consul

• Consul: قوی در discovery و mesh چندمحیطی (VM + K8s)، اکوسیستم HashiCorp
• Istio: عمیق‌ترین یکپارچگی Kubernetes و Envoy، ambient برای مقیاس K8s-native
• اگر estate عمدتاً Kubernetes است → Istio/Linkerd/Cilium؛ اگر hybrid کلاسیک HashiStack دارید → Consul را جدی بگیرید

Istio در برابر «بدون mesh»

گاهی NetworkPolicy (Cilium) + mTLS در لایه اپ + Falco کافی است. Mesh وقتی ارزش دارد که:

• تعداد سرویس‌ها و تیم‌ها بالا است
• canary/traffic policy یکسان لازم است
• zero-trust east-west اجباری است
• مشاهده‌پذیری ترافیک بدون instrument تک‌تک سرویس‌ها می‌خواهید

Ambient در برابر Sidecar — کی کدام؟

امنیت و عملیات

• mTLS را با PeerAuthentication در حالت STRICT تدریجی کنید
• AuthorizationPolicy را least-privilege بنویسید
• istiod و gateway را HA کنید
• istioctl analyze قبل از apply
• نسخه control plane و data plane را هم‌تراز نگه دارید
• متریک proxy و ztunnel را در Prometheus/Grafana ببینید
• برای لاگ ترافیک از Fluentd / Bit استفاده کنید
• تصاویر از Harbor؛ GitOps با Argo

Certificate لبه: cert-manager. DNS: CoreDNS.

Troubleshooting

istioctl proxy-status
istioctl analyze -n my-ns
istioctl ztunnel-config all   # ambient
kubectl -n istio-system get pods

ارتباط با stack شما

Internet
  → Istio Ingress / Gateway API
  → Services
       ├── Sidecar Envoy   یا
       └── ztunnel (± waypoint)
  → Pods ([containerd](/blog/containerd-container-runtime-guide/))

CNI: [Cilium](/blog/cilium-ebpf-kubernetes-networking/) (اغلب)
Alt mesh: [Linkerd](/blog/linkerd-ultralight-service-mesh-guide/)
Edge alt: [Contour](/blog/contour-kubernetes-ingress-envoy-guide/)
App runtime: [Dapr](/blog/dapr-distributed-application-runtime-guide/)
Security: [Falco](/blog/falco-runtime-security-ebpf-guide/)

Best practices

1. اول مشخص کنید به کدام سطح L7 واقعاً نیاز دارید
2. برای cluster جدید پرPod: ambient را جدی ارزیابی کنید
3. Canary را با VirtualService/Gateway API + متریک اتوماتیک ببندید
4. Policy امنیتی را جدا از routing نگه دارید (خوانایی)
5. Multi-cluster را فقط با نیاز واقعی و تیم آماده شروع کنید
6. istioctl را در CI برای analyze بگذارید
7. از profile آماده (default/ambient/minimal) شروع کنید نه custom عظیم
8. Document کنید کدام namespace sidecar است و کدام ambient
9. Vendor distribution (GKE ASM، OpenShift Service Mesh، …) را با OSS خالص مقایسه کنید
10. قبل از انتخاب نهایی، POC سه‌روزه Istio ambient در برابر Linkerd روی همان اپ

چه زمانی Istio؟

✅ استفاده کنید

• نیاز به traffic management پیچیده و policy غنی
• multi-cluster / hybrid / VM در یک مدل
• تیم platform که ظرفیت ops Istio را دارد
• می‌خواهید از sidecar به ambient migrate کنید بدون عوض کردن کل محصول
• اکوسیستم و پشتیبانی vendor مهم است

⚠️ شاید نه / جای دیگر بهتر

جمع‌بندی

Istio دیگر فقط «mesh سنگین با sidecar» نیست — با ambient مسیر مقیاس‌پذیرتری برای zero-trust و telemetry باز شده، در حالی که همچنان قوی‌ترین جعبه‌ابزار L7 را روی Envoy نگه می‌دارد. انتخاب بین Istio، Linkerd و Cilium انتخاب معماری و تیم است، نه فقط چک‌لیست feature.

قدم بعدی

1. Get started — چهار قدم ارزیابی رسمی
2. یک namespace با sidecar injection و یک canary ساده
3. همان workload را روی ambient تکرار کنید و RAM/CPU را مقایسه کنید
4. یک AuthorizationPolicy STRICT بعد از mTLS پایدار
5. POC موازی با Linkerd روی همان سرویس‌ها — جدول تصمیم داخلی بنویسید

منابع

• Istio — istio.io
• What is Istio / Service mesh
• Ambient mode GA (v1.24)
• CNCF: Ambient reaches GA
• Linkerd (مقاله P30Light)
• Envoy (مقاله P30Light)
• Cilium (مقاله P30Light)
• GitHub — istio/istio

منتشر شده در P30Light — بخش زیرساخت و سرور.