خدمات مش و سیاست ترافیک
1) چرا سرویس مش
Service Mesh یک لایه زیرساخت برای ترافیک شرق و غرب (ارتباطات بین سرویس) است که قابلیت های یکنواخت را بدون بازنویسی کد فراهم می کند:- امنیت پیش فرض: mTLS، صدور خودکار/چرخش گواهینامه ها، هویت خدمات.
- خط مشی ترافیک: مسیریابی L7، تست canary/AV، تخریب و ثبات.
- قابلیت مشاهده: معیارها، سیاهههای مربوط، ردیابی، سیگنال های طلا در هر تماس.
- عملیات: سیاست های یکنواخت برای همه زبان ها/چارچوب ها.
تفاوت از دروازه API: دروازه - محیط شمال-جنوب ؛ مش - شرق و غرب در خوشه/سازمان. اغلب با هم کار می کنند.
2) معماری: هواپیماها و الگوها
هواپیما داده: پروکسی جانبی (Envoy/Linkerd-proxy/haproxy)، که ترافیک غلاف/VM را رهگیری می کند.
صفحه کنترل: تنظیمات (مسیرها، سیاست ها، گواهینامه ها) را توزیع می کند، وضعیت فروشگاه ها را منتشر می کند، درایوهای خدمات را منتشر می کند.
هویت: معمولا SPIFFE ID و گواهی خودکار X.509 (SPIRE/ساخته شده در CA).
نقاط ورود/خروج: ورود/خروج دروازه برای نظارت بر جریان های مرزی.
حالت های پیاده سازی: sidecar برای هر زیر ؛ per-node/ambient-modes در پیادهسازیهای جدید.
3) سیاست امنیتی و اعتماد صفر
1. mTLS به طور پیش فرض - رمزگذاری servis↔servis و احراز هویت متقابل.
2. AuthN/AuthZ:- AuthN: اعتماد تنها هویت صادر شده توسط CA mesh 'a (SPIFFE).
- قوانین اعلام شده «چه کسی می تواند به چه کسی و چگونه» (RBAC/ABAC).
- دامنه ها/زیر شبکه های مجاز ؛ خروج اجباری از طریق دروازه خروجی.
- مسدود کردن نتایج مستقیم از قلب.
3. جداسازی و کنترل خروج:
4. چرخش مخفی: گواهینامه های کوتاه مدت، تنظیم مجدد پروکسی خودکار.
yaml apiVersion: security. istio. io/v1beta1 kind: PeerAuthentication metadata: { name: default, namespace: istio-system }
spec:
mtls: { mode: STRICT }
Istio (مثال: فقط اجازه می دهد موجودی gRPC → صدور صورت حساب):
yaml apiVersion: security. istio. io/v1beta1 kind: AuthorizationPolicy metadata: { name: billing-allow, namespace: prod }
spec:
selector: { matchLabels: { app: billing } }
rules:
- from:
- source: { principals: ["spiffe://corp. local/ns/prod/sa/inventory"] }
to:
- operation: { ports: ["8080"], methods: ["POST"], paths: ["/proto. Billing/"] }
4) سیاست ترافیک: پایداری و مسیریابی
4. 1 زمان و عقب نشینی
Timeouts: باید بر روی تماس (اتصال/خواندن/به طور کلی) تنظیم شود.
تکرار: فقط برای عملیات idemotent ؛ عقب نشینی + jitter ؛ limits per-try timeout را انتخاب کنید.
yaml apiVersion: networking. istio. io/v1beta1 kind: VirtualService metadata: { name: orders }
spec:
hosts: ["orders"]
http:
- route:
- destination: { host: orders, subset: v1, port: { number: 8080 } }
timeout: 5s retries:
attempts: 2 perTryTimeout: 2s retryOn: "5xx,connect-failure,reset"
4. 2 قطع کننده مدار и تشخیص بیرونی
CB: درخواست ها/اتصالات همزمان را محدود می کند و از بالادست محافظت می کند.
Outlier: موارد «بد» را با خطا/تأخیر پرتاب می کند.
yaml apiVersion: networking. istio. io/v1beta1 kind: DestinationRule metadata: { name: orders }
spec:
host: orders trafficPolicy:
connectionPool:
http: { http1MaxPendingRequests: 1024, maxRequestsPerConnection: 100 }
outlierDetection:
consecutive5xxErrors: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50
4. 3 قناری و با شرایط
وزن - ترافیک بر اساس وزن v1/v2 تقسیم می شود.
Header-based: flags/cookies/tenant → به نسخه جدید منتقل می شود.
وابستگی جلسه: هش با کلید (مقیاس منظم).
yaml http:
- match: [{ headers: { "x-experiment": { exact: "new" } } }]
route: [{ destination: { host: orders, subset: v2 } }]
- route:
- destination: { host: orders, subset: v1, weight: 90 }
- destination: { host: orders, subset: v2, weight: 10 }
4. 4 تزریق خطا و تخریب
تزریق تاخیر/خطا برای تست استحکام و SLO.
yaml fault:
delay: { fixedDelay: 300ms, percentage: { value: 10 } }
abort: { httpStatus: 503, percentage: { value: 1 } }
5) مرزهای شبکه: ورود/خروج و خدمات خارجی
ورودی دروازه: تنها نقطه ورود برای مشتریان خارجی در مش ؛ ادغام با WAF/OIDC/ratelimits.
خروج دروازه: خروجی مرکزی با یک لیست از میزبان مجاز، بازرسی TLS، رکورد تله متری.
ServiceEntry: SNI/host خارجی را به عنوان بخشی از مش اعلام می کند (سیاست ها و mTLS-origination اعمال می شود).
yaml apiVersion: networking. istio. io/v1beta1 kind: ServiceEntry metadata: { name: payments-external }
spec:
hosts: ["api. payments. com"]
ports: [{ number: 443, name: https, protocol: TLS }]
resolution: DNS location: MESH_EXTERNAL
6) چند خوشه، چند شبکه و ترکیبی
دامنه PKI/اعتماد مشترک: هویتهای SPIFFE منفرد بین خوشهها.
کشف نقطه پایانی: توپ خدمات بین مناطق ؛ اولویت محلی و شکست.
انزوای منطقه ای: سیاست های منطقه ای، محدودیت ها و اولویت ها
VM در مش: اتصال سیستم های میراث/Stateful به پروکسی ها و سیاست های مشابه.
7) قابلیت مشاهده، SLO و عملیات
Метрики: 'requests _ total', 'request _ duration _ ms {p50, p95, p99}', '5xx _ rate', 'retry _ attempes', 'cb _ state', 'mTLS _ authz _ denied'.
سیاهههای مربوط به دسترسی: ساختاری، با 'traceparent'، 'کاربر/مستاجر'، 'پاسخ _ پرچم'.
ردیابی: تزریق خودکار هدر (W3C ردیابی زمینه)، نمونه برداری، دهانه در سطح هاپ.
SLO: اهداف توسط p99/خطاها در مسیر (سرویس → سرویس).
هشدارها: «سنبله 5xx»، «تنظیم مجدد» افزایش، «outlier _ ejections»، تخریب mTLS (خرابی دست).
8) عملکرد و هزینه
Sidecar فاکتورها (CPU/RAM/latency) را اضافه می کند. بهینه سازی:- دانه دانه بودن: شامل سیاست که در آن مورد نیاز; فیلترهای سنگین را در همه جا روشن نکنید.
- استخر: تقسیم مسیر (بحرانی/پس زمینه) به مسیرهای مختلف و محدودیت.
- پروفایل: p99 در مسیرهای «سرد»، حجم تله متری (سیاهههای مربوط به نرخ محدود/مسیرهای پیاده روی).
- در صورت پشتیبانی و مناسب بودن حالت های محیطی/جانبی را در نظر بگیرید.
9) ایمنی و انطباق
حداقل دسترسی مورد نیاز: به صراحت دستورالعمل ها و روش ها را اجازه می دهد.
سیاست در neimspaces/مستاجران: مرزهای شبکه/مجوز.
چرخش کلید/AC: برنامه ریزی شده و اضطراری ؛ گواهینامه های TTL کوتاه.
PII/اسرار: ماسک در سیاهههای مربوط/آهنگ ؛ رمزگذاری بر روی سیم/در حالت استراحت.
حسابرسی: چه کسی، چه زمانی و چه سیاستی تغییر کرده است ؛ شورش های دو مرحله ای
10) ادغام با لایه K8s
سیاست های مش مکمل، نه جایگزین، NetworkPolicy.
در ورود/خروج دروازه، شما می توانید PodSecurity/PSA را در سطح زیر آویزان کنید.
NRA/autoscaling: retrays/CB ها را در نظر بگیرید - آنها بار را تغییر می دهند.
برنامه های انتشار: وزن قناری از طریق VirtualService + ارتقاء SLO خودکار.
11) چک لیست پیاده سازی
- مرزهای اعتماد تعریف شده و STRICT mTLS فعال شده است.
- سیاست های AuthZ را فعال کنید: چه کسی به چه کسی، که در آن پورت/روش.
- زمان بندی/تلاش مجدد و تشخیص outlier پیکربندی شده است، مسیرهای idempointent تعریف شده است.
- مسیرهای قناری و طرح برگشت ثبت شده است. تزریق خطا - فقط در غیر انگیختن.
- وابستگی های خارجی از طریق خروجی دروازه و ServiceEntry مشتق شده است.
- معیارها، سیاههها، ردیابی ها پیکربندی شده اند ؛ داشبورد و هشدار در p99/5xx/CB.
- سهمیه/محدودیت در هر مستاجر/فضای نام در دسترس هستند.
- کتاب های آماده شده: نشت گواهی، شکست CA، تخریب بالادست، 503/RESET جرم.
- برنامه چند خوشه ای (PKI مشترک، اولویت های محلی، سناریوهای DR).
- روز آزمون (روز بازی): رها کردن هواپیما کنترل، sidecar توقف، شکستن شبکه، بالادست سمی است.
12) ضد الگوهای
مش «در همه جا و در یک بار» بدون موجودی مسیر و SLO → پیچیدگی گران قیمت.
Retrays پیش فرض برای تمام روش ها → اثر تکراری و بهمن ترافیک.
mTLS غیر فعال «به طور موقت» به طور دائم باقی می ماند.
خروج بدون دروازه → نشت داده ها/وابستگی های حساب نشده.
یک سیاست جهانی برای همه خدمات ؛ امنیت کاذب و مثبت کاذب.
قابلیت مشاهده صفر: شامل مش است، اما معیارها/مسیرها را جمع آوری نمی کند - معنی را از دست می دهد.
13) دستور العمل های سریع
Linkerd: فعال کردن mTLS و سیاست توسط سرور
yaml apiVersion: policy. linkerd. io/v1beta1 kind: Server metadata: { name: billing, namespace: prod }
spec:
podSelector: { matchLabels: { app: billing } }
port: 8080 apiVersion: policy. linkerd. io/v1beta1 kind: ServerAuthorization metadata: { name: billing-allow-inventory, namespace: prod }
spec:
server: { name: billing }
client:
meshTLS:
identities: ["inventory. prod. serviceaccount. identity. linkerd. cluster. local"]
کنسول (قصد L7 + شکاف)
hcl
Kind = "service-router"
Name = "orders"
Routes = [{
Match { HTTP { PathPrefix = "/v1" } }
Destination { Service = "orders" }
}]
Kind = "service-splitter"
Name = "orders"
Splits = [
{ Weight = 90, ServiceSubset = "v1" },
{ Weight = 10, ServiceSubset = "v2" }
]
14) سوالات متداول
آیا به یک تیم کوچک نیاز دارید ؟
اگر 3-5 خدمات - اغلب نه. با کتابخانه های ورودی و انعطاف پذیری خوب شروع کنید. اتصال مش زمانی که نیاز به پیش فرض mTLS، سیاست های یکنواخت و ردیابی بدون تغییر کد وجود دارد.
چگونه هزینه را کنترل کنیم ؟
اندازه گیری سربار (CPU/RAM/latency) در مسیرهای بحرانی، خاموش کردن فیلترهای غیر ضروری، کاهش حجم سیاهههای مربوط/مسیرهای پیاده روی، استفاده از حالت های بدون sidecar که در آن امن است.
آیا می توان با مش و پروکسی های دستی پیکربندی کرد ؟
بله، اما از ردیابی دوگانه/تکراری اجتناب کنید. یک مکان واحد درست است - هواپیما کنترل.
کدام مهمتر است: امنیت یا عملکرد ؟
پیش فرض امنیت (mTLS، AuthZ) است. عملکرد با تنظیم استخرهای اتصال، تشخیص دور، مسیرهای هدف به دست می آید.
15) مجموع
Service Mesh شبکه بین سرویس ها را به یک لایه قابل برنامه ریزی با سیاست های یکنواخت تبدیل می کند: رمزگذاری و هویت، مسیریابی خوب و انعطاف پذیری، تله متری و سهمیه ها. شروع با مسیرهای بحرانی، روشن کردن STRICT mTLS و صریح AuthZ، تنظیم زمان/retrays/CB، کنترل خروج، اندازه گیری p99 و 5xx، صرف روز بازی. سپس مش به یک تقویت کننده قابلیت اطمینان و سرعت انتشار تبدیل خواهد شد و نه منبع شگفتی.