بانک و مؤسسات مالی
mTLS اجباری برای انطباق با الزامات بانک مرکزی، AuthorizationPolicy دقیق و Audit Trail کامل برای ممیزی PCI-DSS.
Service Mesh مدیریتشده مبتنی بر IstioService Mesh و ارتباط امن میکروسرویسپایدار
ارتباط امن، رمزنگاریشده و قابل مشاهده بین تمام میکروسرویسهای شما — بدون تغییر یک خط کد
GITA Mesh یک Istio مدیریتشده با پشتیبانی کامل از Ambient Mesh، mTLS خودکار، Gateway API و قابلیت مشاهده عمیق با Kiali و Jaeger است — مناسب کلاسترهای Production با هزاران Pod.
Certified Istio DistributionSLA ۹۹.۹۵٪ Data Planeپشتیبانی فارسی ۲۴/۷
SERVICE MESH و ارتباط امن میکروسرویس
Mesh
Authentication
Authorization
Lifecycle
Integration
اعتماد ۸۰+ تیم پلتفرم در ایران
۴ اپراتور تلکام۶ بانک و فینتک۱۲ پلتفرم تجارت الکترونیک۹ پلتفرم AI/ML
+۱۲٬۰۰۰Workload فعال زیر مدیریت GITA Mesh
مسیر ارزشآفرینی
ما نه فقط دردهای شما را میفهمیم — برای رسیدن به آنچه که سازمان شما باید باشد، نقشه میسازیم.
GITA Mesh یک توزیع سازمانی از Istio است که تیم ما آن را روی کلاستر شما مستقر، patch و SRE میکند. از حالت کلاسیک sidecar تا Ambient Mesh مدرن، از یک کلاستر تا Multi-Cluster Federation، همه را در یک Control Plane واحد مدیریت میکنید. تیم معماران ما در فاز Discovery نقشه راهی متناسب با ابعاد، SLA و رگولاتوری شما طراحی میکنند.
Before
وضعیت رایج امروز
- 01
ترافیک بین سرویسها رمزنگاری نشده در شبکه داخلی جریان دارد
هزینه پنهان: نقض الزامات Zero-Trust و ریسک Lateral Movement
- 02
وقتی یک سرویس کند میشود، تشخیص علت ساعتها طول میکشد
هزینه پنهان: MTTR بالا و از دست رفتن SLA مشتری
- 03
Release جدید کل کاربران را همزمان تحت تأثیر قرار میدهد
هزینه پنهان: ریسک Outage در هر deploy و rollback پرهزینه
- 04
هر تیم authZ را در کد سرویس خودش implement میکند
هزینه پنهان: حفرههای امنیتی پراکنده و کد تکراری در دهها سرویس
After
با Mesh
- 01
mTLS خودکار روی ۱۰۰٪ ترافیک east-west
قبلاً: ترافیک داخلی plaintext
- 02
Distributed trace کامل در Jaeger
قبلاً: Debug با لاگ پراکنده در ۲۰ سرویس
- 03
Canary ۵٪، ۲۵٪، ۱۰۰٪ با یک YAML
قبلاً: Deploy = Big Bang برای همه کاربران
- 04
AuthorizationPolicy متمرکز در Mesh
قبلاً: authZ در کد هر سرویس
معماری راهکار
معماری GITA Mesh چگونه کار میکند — جریان داده زنده
Control Plane (istiod) بهصورت جداگانه از Data Plane (Envoy sidecar یا ztunnel + waypoint در Ambient) مستقر میشود. تمام proxyها از یک مرجع SPIFFE/SPIRE هویت workload میگیرند، توکنهای mTLS خود را هر ۲۴ ساعت بهصورت خودکار rotation میکنند و policyها از Control Plane بهصورت xDS push میشوند. در سناریوی Multi-Cluster، چندین Control Plane با Trust Domain مشترک federate میشوند.
جریان داده
ورودیها
Clients & Identities
هسته احراز
Gateway · Auth · Policy · Token
لایه داده
Identity Store · HSM · Directory
ممیزی و تلهمتری
Audit Pipeline · Kafka
اپلیکیشنها
Apps & Cloud
درخواست احراز هویت
ارزیابی سیاست
صدور توکن
گزارش ممیزی
همگامسازی داده
روی برچسبهای بالا کلیک کنید تا فقط یک نوع جریان داده فعال شود — یا روی هر نود حرکت کنید برای نمایش پررنگتر.
قابلیتهای محصول
قابلیتهایی که Service Mesh را عملیاتی میکنند
10 ماژول تخصصی یکپارچه و قابل توسعه — برای انتخاب هر قابلیت، روی آن کلیک کنید.
هسته امنیت
mTLS خودکار سراسری
رمزنگاری و احراز هویت دوطرفه بین تمام Podها، بدون تغییر یک خط در کد سرویس.
GITA Mesh بهصورت پیشفرض STRICT mTLS را روی تمام namespaceها فعال میکند. هویت هر workload از طریق SPIFFE SVID صادر و هر ۲۴ ساعت rotate میشود. Citadel/istiod بهعنوان CA داخلی عمل میکند یا میتواند به HashiCorp Vault یا CA سازمانی شما chain شود.
نکات کلیدی
- STRICT mTLS روی ۱۰۰٪ ترافیک east-west
- Rotation خودکار گواهی هر ۲۴ ساعت
- Integration با Vault و CA سازمانی
- PeerAuthentication per-namespace
برای شماحذف کامل ترافیک plaintext در کلاستر
موارد استفاده صنعتی
راهکار متناسب با صنعت شما
فینتک و پرداخت
Rate limiting سراسری برای حفاظت در برابر abuse، canary deployment برای release بیریسک سرویس پرداخت و observability عمیق برای SLA.
تجارت الکترونیک
Traffic splitting برای A/B testing، failover بین مناطق در Black Friday و Auto-scaling مبتنی بر متریکهای Envoy.
تلکام و 5G CNF
پشتیبانی از CNFهای استاندارد 3GPP، latency پایین با eBPF و Multi-Cluster Mesh برای پوشش geographic.
AI/ML Serving
Canary بین نسخههای مدل، Traffic Mirroring برای shadow inference، rate limit per-customer روی endpointهای inference.
سازمانهای دولتی
استقرار On-Premise و Air-Gapped، CA داخلی، انطباق با ابلاغیههای افتا و گزارشگیری Forensic.
Retail و omni-channel
اتصال سامانههای POS، انبار و فروشگاه آنلاین در یک Mesh، با policyهای جداگانه و مشاهده end-to-end.
Enterprise SaaS
Multi-tenancy ایزوله با namespace per-tenant، AuthorizationPolicy per-customer و metering دقیق بر اساس Envoy stats.
یکپارچهسازی
با اکوسیستم Cloud-Native شما کار میکند
+۴۰ ادغام تأییدشده در محیط Production
زیرساخت شما متفاوت است؟ ادغام سفارشی درخواست دهیدفرآیند پیادهسازی
از تماس اول تا Production در ۴ فاز
نقشه راه شفاف از اولین تماس تا عملیات دائمی — هر مرحله با خروجی قابل اندازهگیری.
PHASE 01
ارزیابی فنی و طراحی
۱ هفته
بررسی کلاستر، CNI، توپولوژی سرویسها، الزامات mTLS و انتخاب مدل (Sidecar یا Ambient).
سند Mesh Architecture Blueprint
PHASE 02
Pilot روی Namespace محدود
۲–۳ هفته
نصب Control Plane، فعالسازی mTLS PERMISSIVE روی ۳ تا ۵ سرویس، تست canary و آموزش تیم.
Mesh عملیاتی روی namespace پایلوت
PHASE 03
گسترش کلاستر و سختگیری
۴–۶ هفته
Onboarding تمام namespaceها، تبدیل به STRICT mTLS، تدوین AuthorizationPolicy و فعالسازی Multi-Cluster در صورت نیاز.
Mesh کامل کلاستر با policyهای فعال
PHASE 04
عملیات و بهبود مستمر
دائمی
پشتیبانی ۲۴/۷، patch منظم Istio، گزارش ماهانه performance و بهینهسازی sampling و resource.
SLA تضمینشده Data Plane
PHASE 01۱ هفته
ارزیابی فنی و طراحی
بررسی کلاستر، CNI، توپولوژی سرویسها، الزامات mTLS و انتخاب مدل (Sidecar یا Ambient).
سند Mesh Architecture Blueprint
PHASE 02۲–۳ هفته
Pilot روی Namespace محدود
نصب Control Plane، فعالسازی mTLS PERMISSIVE روی ۳ تا ۵ سرویس، تست canary و آموزش تیم.
Mesh عملیاتی روی namespace پایلوت
PHASE 03۴–۶ هفته
گسترش کلاستر و سختگیری
Onboarding تمام namespaceها، تبدیل به STRICT mTLS، تدوین AuthorizationPolicy و فعالسازی Multi-Cluster در صورت نیاز.
Mesh کامل کلاستر با policyهای فعال
PHASE 04دائمی
عملیات و بهبود مستمر
پشتیبانی ۲۴/۷، patch منظم Istio، گزارش ماهانه performance و بهینهسازی sampling و resource.
SLA تضمینشده Data Plane
سوالات متداول فنی
سوالاتی که تیم فنی شما احتمالاً میپرسد
تفاوت Sidecar و Ambient Mesh چیست و کدام برای ما مناسب است؟+
حالت Sidecar یک Envoy کنار هر Pod اجرا میکند که قابلیتهای L4 و L7 کامل دارد ولی overhead memory و CPU بالایی روی هر Pod اعمال میکند. حالت Ambient یک ztunnel بهازای هر node و waypoint اختیاری برای L7 دارد، که تا ۹۰٪ مصرف منابع را کاهش میدهد. برای کلاسترهای بزرگ یا workloadهایی که L7 policy ندارند، Ambient انتخاب بهتری است. تیم ما در فاز Discovery توصیه دقیق بر اساس workload شما ارائه میدهد.
Rotation گواهی mTLS چگونه انجام میشود و آیا قطعی ایجاد میکند؟+
گواهیهای SPIFFE SVID بهصورت پیشفرض هر ۲۴ ساعت rotate میشوند و این فرایند بهصورت hot، یعنی بدون قطعی اتصالهای جاری انجام میشود. Envoy گواهی جدید را در حافظه load میکند و اتصالهای جدید از آن استفاده میکنند. در پیکربندی، میتوان TTL را تا ۱ ساعت کاهش داد برای انطباق با الزامات سختگیرانه.
Multi-Cluster Mesh چگونه پیاده میشود و چه شرایطی نیاز دارد؟+
سه مدل اصلی پشتیبانی میشود: Multi-Primary (هر کلاستر Control Plane مستقل، Trust Domain مشترک)، Primary-Remote (یک Control Plane، چند Remote) و External Control Plane. شرط اصلی، اتصال L3/L4 بین کلاسترها و یک Root CA مشترک است. East-West Gateway در هر کلاستر مستقر میشود و ترافیک inter-cluster از طریق آن mTLS میشود.
Overhead Observability چقدر است و چگونه آن را کنترل میکنیم؟+
متریکهای Envoy بهصورت پیشفرض حدود ۲۰ تا ۴۰ مگابایت per-pod memory مصرف میکنند. tracing با sampling ۱۰۰٪ روی workload heavy میتواند ۵٪ CPU اضافه کند. ما بهصورت پیشفرض sampling را روی ۱٪ تنظیم میکنیم و بهصورت دینامیک per-route قابل افزایش است. در حالت Ambient، overhead به نود منتقل میشود نه Pod.
Debug کردن مشکلات Mesh چگونه انجام میشود؟+
ابزار `istioctl` دستورات قدرتمندی مثل `proxy-config`، `analyze` و `pc` برای بررسی config Envoy دارد. Kiali validation خودکار CRDها را نمایش میدهد. تیم پشتیبانی ما دسترسی به runbook اختصاصی برای مشکلات رایج (502 از Envoy، mTLS handshake fail، DNS، …) دارد و در SLA تعهد رفع issue کمتر از ۴ ساعت برای severity-1.
ارتقاء نسخه Istio چگونه و با چه فرکانس انجام میشود؟+
ما از مدل Canary Upgrade استفاده میکنیم: نسخه جدید Control Plane بهصورت موازی نصب میشود، namespaceها یکییکی به آن مهاجرت میکنند و در صورت بروز مشکل rollback آنی انجام میشود. نسخه LTS هر ۶ ماه و patch امنیتی در کمتر از ۷۲ ساعت بعد از انتشار upstream اعمال میشود.
ادغام با API Gateway موجود (Kong, F5, …) چطور است؟+
Service Mesh و API Gateway مکمل هم هستند. API Gateway در مرز شمالی (north-south) کار میکند، Mesh در داخل (east-west). معمولاً API Gateway ترافیک را به Ingress Gateway Istio تحویل میدهد و از آنجا mTLS داخلی برقرار میشود. ما الگوهای آماده برای Kong، Apigee، Envoy Gateway و F5 BIG-IP داریم.
Multi-Tenancy چگونه در Mesh پیاده میشود؟+
هر tenant بهصورت یک یا چند namespace جداگانه با AuthorizationPolicy و NetworkPolicy ایزوله میشود. در سناریوهای سختگیرانه، میتوان Soft Multi-Tenancy با istiod مشترک یا Hard Multi-Tenancy با istiod جداگانه per-tenant داشت. Resource Quota و rate limit per-tenant نیز قابل تنظیم است.
Certificate Authority داخلی یا CA سازمانی — کدام پشتیبانی میشود؟+
هر دو. بهصورت پیشفرض، istiod بهعنوان CA داخلی Root و Intermediate صادر میکند. در سازمانهایی که PKI داخلی دارند، میتوان istiod را chain کرد به HashiCorp Vault یا CA سازمانی شما، بهطوری که Root شما باشد و istiod فقط Intermediate صادر کند. cert-manager نیز کاملاً پشتیبانی میشود.
Performance overhead واقعی Envoy sidecar چقدر است؟+
در بنچمارک ما روی workload معمول HTTP، latency p۵۰ حدود ۰.۵ میلیثانیه و p۹۹ حدود ۲.۵ میلیثانیه افزایش پیدا میکند. throughput نزدیک به ۹۵٪ حالت بدون sidecar حفظ میشود. در حالت Ambient، این عدد به ۰.۲ میلیثانیه p۵۰ کاهش مییابد. با Cilium eBPF در حالتهای خاص، میتوان به latency کمتر از خط پایه (بدون Mesh) رسید.
تماس مستقیم با تیم فنی
جلسه فنی با معمار Service Mesh رزرو کنید
۳۰ دقیقه با معمار ارشد Service Mesh ما صحبت کنید. وضعیت کلاستر، توپولوژی سرویس و الزامات mTLS شما را بررسی میکنیم و نقشه راه ارائه میدهیم. رایگان، بدون پرزنتیشن فروش، بدون تعهد.
فرم درخواست جلسه
مرحله ۱ از ۲