שירות רשת: איסטיו, לינקרד

שירות רשת: איסטיו, לינקרד

1) מהו שירות רשת ומתי הוא נחוץ

Service Mesh היא שכבת מישור מידע/בקרה המספקת MTLS, ניתוב, סובלנות לקויה, ותצפית בין שירותים ללא כתיבה מחדש של קוד.

• ביטחון ברירת מחדל (אפס אמון, זהויות שירות, מדיניות גישה).
• ניהול תנועה (קנרית/כחול-ירוק, A/B, צל).
• אמינות (retras, פסקי זמן, שבירת מעגל).
• יכולת תצפית (מדדים, רישומים, שבילים).
• סטנדרטיזציה מבצעית (מדיניות כקוד, GitOps).

• הרבה מיקרו-רווחים עם רב-לשוניות ודרישות mTLS.
• יש צורך בתרחישי ניתוב/ניסוי מתקדמים מבלי לשנות את היישום.
• ישנן דרישות ביקורת/מדיניות ברמת הרשת.

2) איסטיו נגד לינקרד - השוואה קצרה

3) מודלים של ארכיטקטורה ופריסה

3. 1 sidecar mesh (קלאסי)

כל תא מקבל סירת פרוקסי.
מקצוענים: בגרות, שליטה מלאה באל-7.
חסרונות: תקורה CPU/RAM, מורכבות של דלדול/דיבוג.

3. 2 Estio Ambient Mesh

Zunnel (L4) על צומת + waypoint proxies (L7) כנדרש.
יתרונות: עלות נמוכה ומורכבות, הכללה הדרגתית של L7.
חסרונות: חדש יותר, לא כל מקרי אל-7 זמינים ללא נקודת דרך.

4) זהות ו ־ mTLS (אפס אמון)

4. 1 SPIFE/SPIRE ותעודות

לכל אימון מוקצה זיהוי SPIFE: "Spiffe ://cluster. מקומי/ns/NS/sa/SA '.
אימות: TLS הדדי בין שירותים.
סיבוב מפתחות - אוטומטית (TTL קצר).

4. 2 איסטיו (אימות פיראטי + כלל )

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 איסטיו: Virtual Service (מסלולים, קנריות)

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 לינקרד: פרופיל Service + ספליט

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

איסטיו שער (כניסה/יציאה) - שולט בתנועה נכנסת/יוצאת, סיום TLS, מעבר mTLS.
לינקרד עובדת עם בקרי כניסה קיימים (NGINX/Contour/Traefik); יציאה - באמצעות מדיניות נעילה/יציאה-תבניות שער.
מדיניות היציאה: דומיין וויטליסטים, מדיניות 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 מדיניות לינקרד (שרת + serverauthorization)

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 * Proometheus: ”isstio _ positions _ total”, ”istio _ request _ dure _ milliseconds _ bucket”, ”istio _ tcp _ absed _ bytes _ total”.
Linkerd viz: ”בקשה _ total”, latency p50/p95/p999, ”הצלחה _ rate”.

8. 2 שבילים ויומנים

דחוף את הקשר W3C.
Estio/Envoy # OTLP OpenTelemetry Collector; לינקרד - באמצעות לוגרי סיד/אפליקציית SDK.

8. 3 מקרים

הוסף עקבות _ id להיסטוגרמות משך זמן עבור קפיצה אל עקבות.

9 מגבלות קצב, WAF, מסננים מותאמים אישית

Istio: Envanized Filter/WASM למגבלות קצב מקומיות, eksternal-rate-limit (Redis), וכן לוגיקת WAF (Lua/WASM).
לינקרד: תמיכה מקומית מוגבלת; מגבלת קצב ביציאה/רמת שער.

10) ריבוי אשכולות

איסטיו: שער מזרח-מערב, שיתוף PKI או אמון-צרור, תגלית שירות באמצעות Servally Innection, Federation.
לינקרד: linkerd multicloster קישור, שער לכל אשכול, service-rior secure second.

שימוש-מקרים: נכסי אזורים, לוקליזציה תנועה, פדרלי אפס אמון.

11) ביצועים ועלות

Sidecar mesh: CPU/RAM תקורה לכל פוד, latency מוגברת (בדרך כלל 1-3 ms לכל הופ במצב יציב).
אמביינט (איסטיו): פחות צריכה עבור L4, L7 מופעל נקודה.
לינקרד: פרוקסי קל משקל הוא בדרך כלל פחות תקורה, אבל פחות קיצוני יכולות L7.
תרגול: למדוד p95/CPU לפני/אחרי, לשמור על שערי SLO להשפלה.

12) בטיחות

MTLS בכל מקום, TTL קצר, סיבוב אוטומטי.
מדיניות כקוד (OPA/Gatekeeper, Kyverno) עבור מדיניות Authore : הרשה לכל העכבות.
סודות - באמצעות CSI/כספת, לא מניפוסים.
בקרת יציאה: מכחיש כברירת מחדל, רשימות הרשאה מפורשות.
תחום אמון נפרד לסביבות (prod/stage).

13) אינטגרציה עם שחרורים וגייטינג SLO

קנרית/כחול-ירוק מיושמים על ידי נתיבי רשת (ראו דוגמאות).
Metrics Analysis (Prometheus/SpanMetrics) ב-Argo Rollouts Template - טרמפים/Rollback בקצב צריבה/p95/5xx.
אנוטציות של שחרור בגרפנה: השוואה 'גרסה = יציבה' קנרית.

14) אנטי דפוסים

כלל רשת ”בכל מקום ובת אחת” הלם תשתית.
התעלם מהקרדינליות של המדדים/יומנים של פרוקסי _ העמסת יתר של אחסון TSDB/לוג.
השאר MTLS במצב PERISSIVE/אטום לנצח.
נסה ליצור לוגיקה מסובכת של WAF/business בתוך מסנן Envialter במקום שער/יישום.
אין מדיניות יציאה - דליפות אינטרנט/מעקף ציות.
פרוקסי עם: 15000 דיבאג פתוח מבחוץ.

15) רשימת יישומים (0-60 יום)

0-15 ימים

בחירת מודל: Sidecar vs. Ambient (איסטיו )/Linkerd על ידי פרופיל טעינה.
אפשר mTLS STRICT, מדיניות הרשאה בסיסית לשירותים קריטיים 1-2.
מסלולים בסיסיים (timeout/reteries), לוחות מחוונים RED/SLO.

16-30 ימים

Canary/Lought Split, החוצה זיהוי/מעגל שבירה על פסים חמים.
שילוב OTEL: שבילים + Exemplars; כוננות לשרוף קצב.
שערי יציאה ודומיין לבנים; מכחיש על ידי ברירת מחדל.

31-60 ימים

קישור מרובה אשכולות (אם יש צורך), אמון פדרציה.
מדיניות כקוד לאמיתות מדיניות/אישור סרוורציה.
יום משחק: סימולציה של תקרית ו מסלול/מדיניות rollback.

16) מדדי בגרות

כיסוי MTLS (STRICT/auto-rotate) מהווה 95% מהשירותים.
נתח התנועה בכנרת/פרוגרסיב משחרר 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"]

Kyverno (תוויות נדרשות עבור 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, reteries, 429/503).
תקציב קרדינליות: תוויות 'מסלול', 'קוד', 'יעד' - רק תבנית.
מגבלות רשת/מכסות שם (NetworkPolicy/LookServance Range).
תיעוד פקודה: runbook "כיצד לגלגל בחזרה מסלולים mTLS/policy/keys'.

19) מסקנה

איסטיו ולינקרד עושים את אותו הדבר - תקן את הבטיחות, האמינות והראות של התקשורת הצולבת - אבל עשה זאת בעומקים שונים ובעלות הבעלות.

אתה צריך יכולות L7 עשירות ומדיניות גמישה - לקחת איסטיו (לשקול אמביינט להפחית תקורה).
צריך פשטות ותקורה קטנה. קח את לינקרד.

כל רשת שתבחר: אפשר mTLS כברירת מחדל, מנהל ניתוב כקוד, מקשר מדדים עם מסלולים, סוגר את היציאה ומוסיף גינג SLO לשחרורים. ואז שכבת הרשת תחדל להיות ”קופסה שחורה” ותהפוך לכלי צפוי ליציבות ומהירות שינוי.