שירות רשת ומדיניות תנועה

1) מדוע שירות Mesh

• אבטחת ברירת מחדל: mTLS, הנפקה אוטומטית/סיבוב של תעודות, זהויות שירות.
• מדיניות התנועה: ניתוב L7, בדיקות כנרת/AV, השפלה ויציבות.
• תצפית: מדדים, בולי עץ, עקבות, אותות זהב בכל קריאה.
• פעולות: מדיניות אחידה לכל השפות/מסגרות.

הבדל משער API: שער - היקפי צפון-דרום; מזרח-מערב בתוך אשכול/ארגון. לעתים קרובות לעבוד יחד.

2) ארכיטקטורה: מטוסים ותבניות

Data Plane: Sidecar proxy (שליח/Linkerd-proxy/hafroxy), אשר מיירט תנועת פוד/VM.
מטוס בקרה: מפיץ תצורות (מסלולים, מדיניות, תעודות), מאגר סטטוס, מפרסם כונני שירות.
זהות: בדרך כלל SPIF ID ותעודות X.509 אוטומטיות (SPIRE/מובנה CA).
נקודות כניסה/יציאה: כניסה/יציאה-שער כדי לעקוב אחר זרימות גבולות.
מצבי יישום: סירה לכל אחד תחת; Per-node/abbient-modes ביישומים חדשים.

3) מדיניות ביטחון ואפס אמון

1. MTLS כברירת מחדל - הצפנה servis↔servis ואימות הדדי.

• AUTHN: אמון רק זהויות שהונפקו על ידי CA mesh 'a (SPIFFE).
• AuthZ: כללי ”מי יכול למי ואיך” (RBAC/ABAC).

3. בקרת בידוד ויציאה:

• תחומים/תת רשת מותרים; יציאה בכפייה דרך שער היציאה.
• חסימת תוצאות ישירות מהאחים.

4. סיבוב סודי: תעודות קצרות ימים, הגדרה מחדש של פרוקסי אוטומטית.

yaml apiVersion: security. istio. io/v1beta1 kind: PeerAuthentication metadata: { name: default, namespace: istio-system }
spec:
mtls: { mode: STRICT }

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 פסקי זמן ונסיגות

פסקי זמן: יש להגדיר את הקריאה (חיבור/קריאה/סה "כ).
חוזר: עבור פעולות אידמפוטנטיות בלבד; Backoff + jitter; מגבלות לכל ניסיון פסק זמן.

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: מגביל בקשות/חיבורים סימולטניים, הגנה על הזרם העליון.
זורק מקרים ”רעים” על ידי שגיאה/איחור.

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.
מבוסס כותרת: דגלים/עוגיות/דייר = יועבר לגרסה החדשה.
זיקה: חשיש על ידי מפתח (מגודל בצורה מסודרת).

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 הזרקת פגמים והשפלה

הזרקת השהייה/שגיאה עבור בדיקת robusness ו ־ SLO.

yaml fault:
delay: { fixedDelay: 300ms, percentage: { value: 10 } }
abort: { httpStatus: 503, percentage: { value: 1 } }

5) גבולות רשת: חדירה/יציאה ושירותים חיצוניים

כניסה-שער: נקודת הכניסה היחידה ללקוחות חיצוניים ברשת; אינטגרציה עם WAF/OIDC/ratelimits.
יציאה-שער: פלט מרכזי עם רשימה של מארחים מורשים, בדיקת TLS, תקליט טלמטריה.
Service Intelligence: מכריז על SNI/פונדקאי חיצוני כחלק מ-mesh (מדיניות ו-mTLS-מקוריות).

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/trust משותף: זהויות בודדות של SPIFE בין אשכולות.
תגלית אנדיפוינט: כדורי שירות בין אזורים; עדיפות מקומית וכשלונות.
בידוד אזורי: מדיניות אזורית, גבולות וסדרי עדיפויות.
VM ברשת: חיבור מערכות מורשת/סטטיליזציה לאותן מדיניות.

7) יכולת תצפית, SLO ותפעול

בקשות: 'בקשה _ סך', 'בקשה _ משך _ ms _ 50, p95, p99', '5xx _ rate', 'retry _ princess',' cb _ state ',' mTLS _ authz _ נדחה '.
יומני גישה: מבנית, עם "tracepart'," משתמש/דייר "," תגובה _ דגלים ".
התחקות: הזרקה אוטומטית של כותרות (W3C Trace Context), דגימה, משתרעת ברמת ההופ.
SLO: מטרות על ידי p99/שגיאות על המסלול (service ac service).
התראות: "5xx" spike, "reset" rise, "outlier _ ejections', mTLS delegradation (כישלונות לחיצת יד).

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

• גרעין: כולל פוליטיקה איפה שצריך; אל תדליק מסננים כבדים בכל מקום.
• בריכות: לפצל שבילים (רקע/קריטי) למסלולים ומגבלות שונים.
• פרופיל: p99 במסלולים ”קרים”, נפח טלמטריה (רישומים/שבילים בגבולות קצב).
• תן דעתך למצבים סביבתיים/חסרי צד אם הם נתמכים ומתאימים.

9) בטיחות וציות

גישה דרושה מינימלית: אפשר במפורש הנחיות ושיטות.
מדיניות על חלל נימי/דיירים: גבולות רשת/אישור.
סיבוב מפתח/AC: מתוכנן וחירום; תעודות TL קצרות.
PII/סודות: מיסוך ביומנים/עקבות; הצפנה על החוט/במנוחה.
ביקורת: מי, מתי ואיזו מדיניות השתנתה; שני שלבים של צעקות.

10) אינטגרציה עם שכבה K8s

מדיניות רשת משלימה, לא תחליף, מדיניות Networks.
בכניסה/יציאה-שער, אתה יכול לתלות PodSecurity/PSA ברמה מתחת.
NRA/autoscaling: שקול מגשים/CBs - הם משנים טעינה.
תוכניות שחרור: משקולות קנרית באמצעות שירות Virtual + קידום SLO אוטומטי.

11) רשימת מימושים

גבולות אמון מוגדרים ו-STRICT mTLS מופעלים.

[ ] מדיניות AuthZ אפשרה: למי, למי, על אילו נמלים/שיטות.

[ מוגדרים מסלולי אידמפוטנטים (idempotent paths/reteries), ] מוגדרים.

[ ] הנתיבים הקנריים ותוכנית ההפעלה רשומים; הזרקת אשמה - רק ללא עבודה.

[ ] תלות חיצונית נגזרת דרך שער היציאה וכניסת הסולידריות.

[ ] Metrics, בולי עץ, עקבות מוגדרים; לוחות מחוונים והתראות על p99/5xx/CB.

[ ] מכסות/מגבלות לדייר/שם זמינות.

[ ] ספרי ריצה מוכנים: דליפת תעודות, כשל במצ "ח, הידרדרות במעלה הזרם, 503/RESET המונית.

[ תוכנית רב-אשכול ] (PKI משותף, סדר עדיפויות מקומי, תרחישי DR).

[ ימי מבחן ] (ימי משחק): הפלת מטוס בקרה, עצירת סירה, הפסקת רשת, רעיל במעלה הזרם.

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

רשת ”בכל מקום ובעת ובעונה אחת” ללא מלאי מסלול ו SLO # מורכבות יקרה.
מגשים מחדש ברירת מחדל לכל השיטות * שכפול אפקט ומפולות תנועה.

MTLS נכה ”באופן זמני” = = = = = = = = = = = = = = = = = = = = = =

יציאה ללא שער * דליפת נתונים/תלויות חסרות.
מדיניות גלובלית אחת לכל השירותים.
אפס יכולת תצפית: כולל רשת, אבל לא לאסוף מדדים/שבילים - לאבד משמעות.

13) מתכונים מהירים

לינקרד: אפשר 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) FAQ

רשת צריכה צוות קטן?
אם 3-5 שירותים - לעתים קרובות יותר לא. תתחיל עם ספריות עמידות וחדירה טובות. חיבור רשת כאשר יש צורך ב-mTLS-ברירת מחדל, מדיניות אחידה, והתחקות ללא שינויי קוד.

איך לשלוט בעלויות?
למדוד תקורה (CPU/RAM/latency) במסלולים קריטיים, לכבות מסננים מיותרים, להפחית את נפח היומנים/שבילים, להשתמש במצבים ללא סירה במקום בטוח.

האם זה אפשרי להפריע עם רשת והגדרות ידניות פרוקסי?
כן, אבל להימנע מניתוב כפול/שכפול מגשים מחדש. מקום אחד הוא נכון - מישור השליטה.

מה חשוב יותר: ביטחון או ביצועים?
ברירת המחדל היא אבטחה (mTLS, AuthZ). ביצועים מושגים על ידי כוונון בריכות חיבור, זיהוי יוצא, מסלולי יעד.

15) סיכומים

שירות Mesh הופך את הרשת בין שירותים לשכבה ניתנת לתכנות עם מדיניות אחידה: הצפנה וזהויות, ניתוב עדין ועמידות, טלמטריה ומכסות. התחל במסלולים קריטיים, הפעל את STRICT mTLS ו-AuthZ מפורש, קבע פסקי זמן/מגשים/CB, בקר יציאה, מדד p99 ו-5xx, בזבז ימי משחק. ואז רשת תהפוך למגבר של אמינות ומהירות של שחרור, ולא מקור של הפתעות.