سرویس مش: ایستگاه، Linkerd

سرویس مش: ایستگاه، Linkerd

1) سرویس مش چیست و چه زمانی مورد نیاز است

Service Mesh یک لایه داده/کنترل شبکه است که mTLS، مسیریابی، تحمل خطا و قابلیت مشاهده بین خدمات بدون بازنویسی کد را فراهم می کند.

• امنیت پیش فرض (اعتماد صفر، هویت خدمات، سیاست دسترسی).
• مدیریت ترافیک (قناری/آبی سبز، A/B، سایه).
• قابلیت اطمینان (retras، timeouts، شکستن مدار).
• قابلیت مشاهده (معیارها، سیاههها، مسیرها).
• استاندارد سازی عملیاتی (سیاست ها به عنوان کد، GitOps).

• بسیاری از خدمات با چند زبانه و mTLS مورد نیاز است.
• نیاز به سناریوهای مسیریابی/آزمایش پیشرفته بدون تغییر برنامه.
• الزامات حسابرسی/سیاست در سطح شبکه وجود دارد.

2) Istio vs Linkerd - یک مقایسه کوتاه

3) مدل های معماری و استقرار

3. 1 مش جانبی (کلاسیک)

هر Pod یک کارت جانبی پروکسی دریافت می کند.
مزایا: بلوغ، کنترل کامل L7.
منفی: سربار CPU/RAM، پیچیدگی تخلیه/اشکال زدایی.

3. 2 ایستگاه محیط مش

ztunnel (L4) در گره + پروکسی نقطه راه (L7) به عنوان مورد نیاز است.
مزایا: هزینه و پیچیدگی کمتر، گنجاندن تدریجی L7.
معایب: جدیدتر، همه موارد L7 بدون نقطه بینراهی در دسترس نیستند.

4) هویت و mTLS (اعتماد صفر)

4. 1 SPIFFE/SPIRE و گواهینامه ها

به هر تمرین یک شناسه SPIFFE اختصاص داده می شود: 'spiffe ://cluster. محلی/NS/NS/SA/SA '.
احراز هویت: TLS متقابل بین خدمات.
چرخش کلید - به طور خودکار (TTL کوتاه).

4. 2 ایستیو (PeerAuthentication + DestinationRule)

yaml apiVersion: security. istio. io/v1 kind: PeerAuthentication metadata: { name: default, namespace: payments }
spec:
mtls: { mode: STRICT }
apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments-dr, namespace: payments }
spec:
host: payments. svc. cluster. local trafficPolicy:
tls: { mode: ISTIO_MUTUAL }

4. 3 Linkerd - به طور پیش فرض mTLS

بعد از «نصب linkerd» + «تزریق linkerd» فعال شده است.
خوشه ها - لنگر اعتماد خود، چرخش اتوماتیک.

5) مدیریت ترافیک

5. 1 Istio: VirtualService (مسیرها، قناری ها)

yaml apiVersion: networking. istio. io/v1 kind: VirtualService metadata: { name: payments }
spec:
hosts: ["payments"]
http:
- route:
- destination: { host: payments, subset: v1 } # stable weight: 90
- destination: { host: payments, subset: v2 } # canary weight: 10 retries: { attempts: 2, perTryTimeout: 300ms }
timeout: 2s

yaml apiVersion: networking. istio. io/v1 kind: DestinationRule metadata: { name: payments }
spec:
host: payments subsets:
- name: v1 labels: { version: v1 }
- name: v2 labels: { version: v2 }
trafficPolicy:
loadBalancer: { simple: LEAST_CONN }
outlierDetection:
consecutive5xx: 5 interval: 5s baseEjectionTime: 30s maxEjectionPercent: 50

5. 2 لینک: ServiceProfile + TrafficSplit

yaml apiVersion: linkerd. io/v1alpha2 kind: ServiceProfile metadata:
name: payments. default. svc. cluster. local spec:
routes:
- name: POST /withdraw condition:
method: POST pathRegex: "/withdraw"
isRetryable: true timeout: 2s apiVersion: split. smi-spec. io/v1alpha2 kind: TrafficSplit metadata: { name: payments }
spec:
service: payments backends:
- service: payments-v1 weight: 90
- service: payments-v2 weight: 10

6) دروازه های ورودی/خروجی و API

Istio Gateway (ورود/خروج) - ترافیک ورودی/خروجی، TLS termination، mTLS passthrough را کنترل می کند.
Linkerd با کنترل کننده های ورودی موجود (NGINX/Contour/Traefik) کار می کند. خروج - از طریق NetworkPolicy/خروج از دروازه الگوهای.
سیاست های خروج: لیست های سفید دامنه، سیاست SNI، ممنوعیت مستقیم اینترنت.

7) مجوز و سیاست

7. 1 ایستگاه مجوز سیاست (RBAC/ABAC)

yaml apiVersion: security. istio. io/v1 kind: AuthorizationPolicy metadata: { name: allow-withdraw, namespace: payments }
spec:
selector: { matchLabels: { app: payments } }
action: ALLOW rules:
- from:
- source:
principals: ["spiffe://cluster. local/ns/api/sa/gateway"]
to:
- operation:
methods: ["POST"]
paths: ["/withdraw"]
when:
- key: request. auth. claims[role]
values: ["cashout"]

7. 2 سیاست Linkerd (سرور + مجوز سرور)

yaml apiVersion: policy. linkerd. io/v1beta3 kind: Server metadata: { name: payments-server, namespace: payments }
spec:
podSelector: { matchLabels: { app: payments } }
port: 8080 apiVersion: policy. linkerd. io/v1beta3 kind: ServerAuthorization metadata: { name: allow-gateway, namespace: payments }
spec:
server: { name: payments-server }
client:
meshTLS:
identities: [".ns. api. serviceaccount. identity. linkerd. cluster. local"]

8) قابلیت مشاهده و تله متری

8. 1 معیارها

Istio Telemetry API → Prometheus: 'istio _ requests _ total', 'istio _ request _ duration _ milliseconds _ bucket', 'istio _ tcp _ received _ bytes _ total'.
Linkerd viz: 'request _ total', latency p50/p95/p99, 'success _ rate'.

8. 2 مسیرهای پیاده روی و سیاهههای مربوط

زمینه ردیابی W3C را فشار دهید.
Istio/Envoy → OTLP в OpenTelemetry Collector ؛ Linkerd - از طریق loggers sidecar/SDK برنامه.

8. 3 نمونه

trace _ id را به هیستوگرام های مدت زمان برای پرش به ردیابی اضافه کنید.

9) محدودیت نرخ، WAF، فیلترهای سفارشی

Istio: EnvoyFilter/WASM برای محدودیت های نرخ محلی، سرویس محدود کننده نرخ eksternal (Redis) و همچنین منطق WAF (Lua/WASM).
Linkerd: پشتیبانی بومی محدود ؛ محدودیت نرخ - در سطح ورود/دروازه.

10) چند خوشه ای

Istio: دروازه شرق به غرب، PKI مشترک یا trust-bundle، کشف خدمات از طریق ServiceEntry، Federation.
Linkerd: 'link multicluster link'، دروازه در هر خوشه، контроллер سرویس آینه.

موارد استفاده: مناطق دارایی، محلی سازی ترافیک، اعتماد صفر فدرال.

11) عملکرد و هزینه

مش جانبی: سربار CPU/RAM در هر Pod، افزایش تأخیر (معمولاً 1-3 میلی ثانیه در هر هاپ در حالت پایدار).
محیط (Istio): مصرف کمتر برای L4، L7 نقطه روشن است.
Linkerd: پروکسی سبک وزن به طور کلی سربار کمتر است، اما کمتر شدید قابلیت های L7.
تمرین: اندازه گیری p95/CPU قبل/بعد، نگه داشتن دروازه SLO برای تخریب.

12) ایمنی

mTLS در همه جا، TTL کوتاه، چرخش اتوماتیک.
Policy as Code (OPA/Gatekeeper, Kyverno) for 'authorizationPolicy: ALLOW all' prohibtions.
اسرار - از طریق CSI/Vault، نه در مانیفست.
کنترل خروج: انکار به طور پیش فرض، صریح اجازه لیست.
دامنههای اعتماد را برای محیطها جدا کنید (prod/stage).

13) ادغام با نسخه ها و دروازه SLO

Canary/Blue-Green توسط مسیرهای مش اجرا می شود (مثال ها را ببینید).
تجزیه و تحلیل متریک (Prometheus/SpanMetrics) در Argo Rollouts AnalysisTemplate - Hitchhiking/Rollback در burn-rate/p95/5xx.
حاشیه نویسی نسخه ها در Grafana: مقایسه 'version = stable' canary '.

14) ضد الگوهای

شامل مش «در همه جا و در یک بار» → شوک زیرساخت.
نادیده گرفتن کاردینالیتی معیارها/سیاهههای مربوط از پروکسی → بارگذاری بیش از حد ذخیره سازی TSDB/log.
mTLS را در حالت مجاز/مات برای همیشه بگذارید.
سعی کنید به WAF پیچیده/منطق کسب و کار در داخل EnvoyFilter به جای دروازه/نرم افزار.
بدون سیاست خروج - اینترنت نشت/بای پس انطباق.
پروکسی با «: 15000» اشکال زدایی به خارج باز است.

15) چک لیست پیاده سازی (0-60 روز)

0-15 روز

انتخاب مدل: Sidecar در مقابل محیط (Istio )/Linkerd توسط مشخصات بار.
mTLS STRICT، سیاست های مجوز اساسی برای خدمات بحرانی 1-2 را فعال کنید.
مسیرهای اصلی (timeout/retries)، داشبورد RED/SLO.

16-30 روز

Canary/TrafficSplit، تشخیص بیرونی/مدار شکستن در آهنگ های داغ.
ادغام OTEL: مسیرهای پیاده روی + نمونه ؛ هشدار سوختگی.
دروازه های خروجی و لیست های سفید دامنه ؛ انکار به طور پیش فرض.

31-60 روز

پیوند چند خوشه (در صورت لزوم)، اعتماد فدراسیون.
سیاست به عنوان کد на AuthorizationPolicy/ServerAuthorization.
Game-day: شبیه سازی حادثه و بازگشت مسیر/سیاست.

16) معیارهای بلوغ

mTLS (STRICT/چرخش خودکار) پوشش ≥ 95٪ از خدمات.
سهم ترافیک از طریق انتشار canary/progressive 80٪ ≥.
میانگین سربار p95 <+ 5٪ از پایه (پس از بهینه سازی).
0 خروج باز بدون اجازه، 100٪ خدمات با پایه AuthZ.
RCA «از برنامه به پیگیری» ≤ 2 دقیقه (p50).

17) نمونه هایی از «سیاست به عنوان کد»

دروازه بان (ممنوعیت مجاز در تولید)

yaml apiVersion: constraints. gatekeeper. sh/v1beta1 kind: K8sIstiomTLSStrict metadata: { name: deny-permissive-prod }
spec:
match:
kinds: [{ apiGroups: ["security. istio. io"], kinds: ["PeerAuthentication"] }]
namespaces: ["prod-"]
parameters:
allowedModes: ["STRICT"]

کیورنو (برچسب های مورد نیاز برای VS/DR)

yaml apiVersion: kyverno. io/v1 kind: ClusterPolicy metadata: { name: require-mesh-labels }
spec:
rules:
- name: vs-dr-labels match:
any:
- resources:
kinds: ["VirtualService","DestinationRule"]
validate:
message: "owner and service labels required"
pattern:
metadata:
labels:
owner: "?"
service: "?"

18) راهنمایی های عملیاتی

سیاست ها و مسیرهای نسخه (semver)، ارتقاء از طریق GitOps.
مشاهدات پروکسی: داشبورد اشباع پروکسی فردی (CPU/heap، retries، 429/503).
بودجه کاردینالیتی: برچسب «مسیر»، «کد»، «مقصد» - فقط قالب.
محدودیتهای شبکه/سهمیههای فضای نام (NetworkPolicy/LimitRange).
مستندات فرمان: runbook «چگونگی بازگرداندن مسیرهای mTLS/policy/keys».

19) نتیجه گیری

Istio و Linkerd همان کار را انجام می دهند - استاندارد سازی ایمنی، قابلیت اطمینان و دید ارتباطات متقابل خدمات - اما این کار را در عمق و هزینه های مختلف مالکیت انجام دهید.

شما نیاز به قابلیت های غنی L7 و سیاست های انعطاف پذیر دارید - Istio را در نظر بگیرید (Ambient را برای کاهش سربار در نظر بگیرید).
به سادگی و سربار کوچک نیاز دارید - Linkerd را بگیرید.

هر شبکه ای که انتخاب می کنید: mTLS را به طور پیش فرض فعال کنید، مسیریابی را به عنوان کد مدیریت کنید، معیارها را با آهنگ ها مرتبط کنید، خروجی را ببندید و SLO را به نسخه ها اضافه کنید. سپس لایه شبکه متوقف خواهد شد «جعبه سیاه» و تبدیل به یک ابزار قابل پیش بینی برای ثبات و سرعت تغییر است.