שלטו בארכיטקטורת רשת השירות עם Istio

1. הקדמה

גלו את הקסם של ארכיטקטורת רשת השירות וראו איך היא משדרגת את המערכות המבוזרות שלכם.

צללו עמוק לתוך Istio, הכוכב של רשת השירות, ולמדו איך הוא מתזמר את אשכול Kubernetes שלכם לשלמות.

2. מהי רשת שירות?

יישומים מונוליטיים התפתחו ליחידות קטנות יותר ובלתי תלויות. המגמה הזו צברה פופולריות רבה עם מחשוב ענן וארכיטקטורת מיקרו-שירותים. כלים כמו Docker ו-Kubernetes האיצו את המגמה הזו.

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

אתגרים נוספים כוללים אבטחה ונראות.

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

4. Istio נחשף

Istio, תוצר פתוח של IBM, Google ו-Lyft, משדרג באופן בלתי נראה את היישומים המבוזרים עם ניהול תנועה, אבטחה ותובנות ביצועים.

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

בבסיסו, Istio מציב פרוקסי Envoy כ'סיידקארים' לצד כל מיקרו-שירות:

רשת פרוקסי זו יוצרת את מישור הנתונים של Istio, המתוזמר על ידי מישור הבקרה:

הגמישות של Istio באה לידי ביטוי באינטגרציה חלקה עם מערכות רישום חיצוניות, טלמטריה ומדיניות.

5. לפענח את אבני הבניין של Istio

ארכיטקטורת Istio היא זוג דינמי: מישור הנתונים ומישור הבקרה. יחד הם מתזמרים את הקסם מאחורי יכולות Istio. בואו נצלול לרכיבים המרכזיים שמניעים את הפלטפורמה יוצאת הדופן הזו.

הכינו את עצמכם לחקור את הפרטים המורכבים של רכיבי הליבה של Istio.

5.1. מישור הנתונים: המרכז של Envoy

מישור הנתונים של Istio הוא גרסה משופרת של פרוקסי Envoy. הפלא הפתוח הזה מתמודד עם תחכומי הרשת, ומשחרר את היישומים להתמקד בליבת העסק שלהם. יישומים מתקשרים בקלות, ללא מודעות לתשתית הרשת המורכבת.

בבסיסו, Envoy הוא אשף רשת שפועל בשכבות 3 ו-4 של מודל OSI. הוא מנהל חיבורים בחכמה באמצעות שרשרת של פילטרים רשתיים מתאימים. מעבר לכך, פילטר השכבה ה-7 של Envoy מאפשר לו להתמודד בחן עם תעבורת HTTP. וזה לא הכל - הוא טבעי עם פרוטוקולי HTTP/2 ו-gRPC.

רבות מהתכונות הבולטות של Istio הן למעשה כוחות-על שנובעים מיכולות מובנות של Envoy:

• שליטה בתנועה: Envoy מחזיק בשליטה גרנולרית על תעבורת HTTP, gRPC, WebSocket ו-TCP, מנתב אותה במדויק.
• עמידות הרשת: ניסיונות חוזרים אוטומטיים, מפסקי מעגל והזרקת תקלות מובנים מבטיחים אמינות רשת בלתי מתפשרת.
• אבטחה: הגנו על התקשורת שלכם עם מדיניות אבטחה חזקה, שליטה בגישה והגבלת קצב.

הכוח האמיתי של Envoy מתגלה כשמצרפים אותו ל-Istio. היכולת שלו להרחבה, המונעת על ידי WebAssembly, מהווה משחק משנה בכל הנוגע לאכיפת מדיניות מותאמת וטלמטריה. בנוסף, API Proxy-Wasm של Istio פותח דלתות לעוד התאמות מותאמות אישית של Envoy.

5.2. מישור הבקרה: המאסטרו של Istiod

הכירו את istiod, המנצח של תזמורת מישור הבקרה של Istio. המאסטרו הזה הופך חוקים ניהול תעבורה והנחיות ניתוב ברמה גבוהה לתצורות ידידותיות ל-Envoy, ומפיץ אותן לצדדים באופן חלק.

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

בבסיסו, istiod עושה שימוש באותו קוד ו-APIs כמו קודמיו. Pilot, למשל, ממשיך להיות המאסטרו של גילוי השירותים, מתרגם פרטי פלטפורמה ספציפיים לשפה אוניברסלית שה'סיידקארים' מבינים. הגמישות הזו מאפשרת ל-Istio לעבוד בהרמוניה עם סביבות שונות כמו Kubernetes ומכונות וירטואליות.

istiod גם לוקח אחריות על אבטחה, מבסס אימות בין שירותים ואימות משתמשי קצה עם מערכת ניהול זהויות ותעודות מובנית. אכיפת מדיניות אבטחה גרנולרית על בסיס זהות השירותים היא קלה לביצוע. בנוסף, istiod מתפקד כרשות תעודות (CA) אמינה, ומנפיקה תעודות לאבטחת התקשורת בין שירותים באמצעות TLS הדדי (MTLS).

6. איך Istio פועל

חקרנו את התכונות הטיפוסיות של רשת שירות וניתחנו את הארכיטקטורה והרכיבים המרכזיים של Istio. עכשיו, בואו נגלה איך Istio מספק את התכונות הללו באמצעות הרכיבים המרכזיים שלו.

נחזור לאותן קטגוריות תכונות שחקרנו קודם.

6.1. ניהול תעבורה

API ניהול התעבורה של Istio מציע שליטה גרנולרית על תעבורת רשת השירות. התאמנו תצורות תעבורה באמצעות APIs אלו והגדירו משאבי API עם Kubernetes CRDs. משאבי API עיקריים לניתוב תעבורה הם שירותים וירטואליים וחוקי יעד:

שירות וירטואלי מגדיר איך בקשות מנותבות לשירות בתוך רשת Istio. הוא מכיל חוקי ניתוב אחד או יותר המוערכים לפי הסדר. לאחר ניתוב השירות הווירטואלי, חוקי היעד חלים לשלוט בתעבורה ליעד, כגון קיבוץ מופעי שירות לפי גרסה.

6.2. אבטחה

הבסיס האבטחתי של Istio הוא זהויות חזקות לכל שירות. סוכני Istio לצד כל פרוקסי Envoy משתפים פעולה עם istiod כדי לאוטומטית להחליף מפתחות ותעודות:

Istio תומך בשני סוגי אימות: אימות שותפים ואימות בקשות. אימות שותפים מאבטח את התקשורת בין שירותים עם TLS הדדי של Istio. אימות בקשות מתמודד עם אימות משתמשי קצה באמצעות בדיקת JWT עם ספק אימות מותאם אישית או OIDC.

Istio אוכף שליטה בגישה לשירותים על ידי החלת מדיניות הרשאה. מדיניות אלו מווסתות תעבורה נכנסת בפרוקסי Envoy, ומאפשרות שליטה בגישה ברמת הרשת, המרחב, והשירות.

6.3. נראות

Istio מייצר טלמטריה מקיפה, כולל מדדים, עקיבות מבוזרות ולוגים עבור כל תקשורת השירותים בתוך הרשת. הטלמטריה הזו כוללת מדדים ברמת הפרוקסי, השירות ומישור הבקרה.

בעבר, Mixer היה הרכיב המרכזי בארכיטקטורת הטלמטריה של Istio. עם זאת, Telemetry v2 מחליף את תכונות Mixer עם תוספים של פרוקסי Envoy:

Istio יוצר עקיבות מבוזרות באמצעות פרוקסי Envoy ותומך במערכות מעקב שונות כמו Zipkin, Jaeger, Lightstep, ו-Datadog. שיעור הדגימה ליצירת עקיבות ניתן להגדרה. בנוסף, Istio מייצר לוגי גישה עבור תעבורת שירות בפורמטים מותאמים אישית.

7. צללו לתוך Istio

מספיק רקע, בואו נבדוק את Istio בפעולה! נתקין את Istio על אשכול Kubernetes ונשתמש באפליקציה פשוטה של מיקרו-שירותים כדי להציג את עוצמתו.

7.1 התקנה

Istio ניתן להתקנה במגוון דרכים, אך הדרך הקלה ביותר היא להוריד ולחלץ את הגרסה העדכנית ביותר למערכת ההפעלה שלכם (כמו Windows). החבילה המופקת כוללת את לקוח istioctl בתיקיית bin. השתמשו ב-istioctl להתקנת Istio באשכול Kubernetes שלכם:

istioctl install --set profile=demo -y

kubectl label namespace default istio-injection=enabled

אנחנו משתמשים ב-kubectl כאן, בהנחה שיש לכם אשכול Kubernetes (כמו Minikube) ו-Kubectl מוגדרים.

7.2 אפליקציה לדוגמה

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

לא ניכנס לפרטי המיקרו-שירותים, אבל הם קלים ליצירה באמצעות Spring Boot ו-APIs מותאמים אישית. חשוב מכך, צרו תמונות Docker עבור מיקרו-שירותים אלו כדי לפרוס על Kubernetes.

7.3 פריסה

פריסת עומסי עבודה ממוכנים על אשכולות Kubernetes כמו Minikube היא פשוטה. השתמשו במשאבי Deployment ו-Service כדי להצהיר ולגשת לעומס העבודה. בדרך כלל, הגדירו אותם בקובץ YAML:

apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: order-service
  namespace: default
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: order-service
        version: v1
    spec:
      containers:
      - name: order-service
        image: kchandrakant/order-service:v1
        resources:
          requests:
            cpu: 0.1
            memory: 200
---
apiVersion: v1
kind: Service
metadata:
  name: order-service
spec:
  ports:
  - port: 80
    targetPort: 80
    protocol: TCP
    name: http
  selector:
    app: order-service

kubectl apply -f booking-service.yaml -f inventory-service.yaml -f shipping-service.yaml

מכיוון שאפשרנו הזרקה אוטומטית של פרוקסי סיידקאר Envoy עבור מרחב השמות ברירת המחדל, הכל מטופל. או, הזריקו ידנית את פרוקסי סיידקאר Envoy באמצעות פקודת kube-inject של istioctl.

7.4 גישה לאפליקציה

Istio מטפל בעיקר בתעבורת רשת השירות. כברירת מחדל, תעבורה לתוך או מחוץ לרשת חסומה. Istio משתמש בשערים כדי לנהל את תעבורת הרשת הנכנסת והיוצאת, ומעניק לכם שליטה מדויקת על מה שנכנס או יוצא. Istio מציע פריסות שער proxy מוגדרות מראש: istio-ingressgateway ו-istio-egressgateway.

צרו שער ושירות וירטואלי עבור האפליקציה שלכם:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: booking-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: booking
spec:
  hosts:
  - "*"
  gateways:
  - booking-gateway
  http:
  - match:
    - uri:
        prefix: /api/v1/booking
    route:
    - destination:
        host: booking-service
        port:
          number: 8080

8 מקרי שימוש נפוצים ב-Istio

פרסנו אפליקציה פשוטה על Kubernetes עם Istio. בואו נחקור את התכונות החזקות של Istio ונראה איך הן יכולות לשדרג את האפליקציה שלנו.

8.1 ניתוב בקשות

דמיינו שאתם פורסים מספר גרסאות של מיקרו-שירות כמו שירות המשלוח. אתם רוצים להכניס בהדרגה תכונות חדשות מבלי להשפיע על כל המשתמשים. ניתוב בקשות מאפשר לכם לעשות זאת על ידי ניתוב חלק מהתעבורה לגרסה העדכנית ביותר.

השתמשו בחוקי ניתוב של שירותים וירטואליים כדי להשיג זאת.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: shipping-service
spec:
  hosts:
    - shipping-service
  http:
  - route:
    - destination:
        host: shipping-service
        subset: v1
      weight: 90
    - destination:
        host: shipping-service
        subset: v2
      weight: 10
---
apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: shipping-service
spec:
  host: shipping-service
  subsets:
  - name: v1
    labels:
      version: v1
  - name: v2
    labels:
      version: v2

חוקי ניתוב יכולים גם לסנן תעבורה על בסיס כותרות או מאפיינים אחרים. שדה היעד מציין את שירות המטרה עבור בקשות תואמות.

8.2 מפסקי מעגל

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

חוק היעד של Istio מאפשר לכם להגדיר התנהגות של מפסקי מעגל עבור שירותים כמו שירות המלאי.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: inventory-service
spec:
  host: inventory-service
  trafficPolicy:
    connectionPool:
      tcp:
        maxConnections: 1
      http:
        http1MaxPendingRequests: 1
        maxRequestsPerConnection: 1
    outlierDetection:
      consecutive5xxErrors: 1
      interval: 1s
      baseEjectionTime: 3m
      maxEjectionPercent: 100

על ידי הגבלת החיבורים המקסימליים, בקשות ממתינות ובקשות לכל חיבור, אתם יכולים לנהל תעבורה ביעילות ולמנוע עומס יתר.

8.3 הפעלת TLS הדדי

TLS הדדי מבטיח תקשורת מאובטחת בין שירותים על ידי דרישת אימות משני הצדדים. Istio מפעיל אוטומטית TLS הדדי עבור שירותים המשתמשים בפרוקסי שלו.

בעוד Istio אוכף TLS הדדי בין שירותים עם פרוקסי, תעבורת plain-text יכולה עדיין להגיע לשירותים ללא פרוקסי. השתמשו במדיניות PeerAuthentication כדי לאכוף TLS הדדי על פני כל הרשת.

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

ניתן להחיל TLS הדדי ברמת הרשת, המרחב או השירות. מדיניות שירות-ספציפיות עוקפות את ההגדרות ברמת המרחב.

8.4 שליטה בגישה עם JWT

JSON Web Tokens (JWT) הם תקן להעברת מידע משתמשים בצורה מאובטחת. הם נפוצים לשימוש באימות והרשאה.

מדיניות AuthorizationPolicy של Istio מאפשרת לכם לשלוט בגישה לשירותים כמו שירות ההזמנות בהתבסס על טענות JWT.

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt
  namespace: default
spec:
  selector:
    matchLabels:
      app: booking-service
  action: ALLOW
  rules:
  - from:
    - source:
       requestPrincipals: ["[email protected]/[email protected]"]

דרשו JWT חוקיים עם טענות ספציפיות עבור גישה מורשית. Istio יוצר מאפיין requestPrincipal מתוך טענות ה-issuer וה-subject של ה-JWT.

9. מחשבות סופיות

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

9.1. האם רשת שירות תמיד נחוצה?

למרות היתרונות של רשתות שירות, יש לקחת בחשבון את החסרונות הבאים:

רשתות שירות מציעות יתרונות, אך הערכה זהירה של מורכבות היישום שלכם היא קריטית. שקלו את היתרונות מול המורכבות המוספת.

9.2. אלטרנטיבות ל-Istio

Istio היא רשת שירות פופולרית הנתמכת על ידי ענקי התעשייה, אך היא אינה האפשרות היחידה. הנה סקירה קצרה של Linkerd ו-Consul.

Linkerd היא רשת שירות ילידת Kubernetes, פרויקט פתוח שצובר פופולריות. זהו פרויקט אינקובציה של CNCF ופועל בצורה דומה ל-Istio, תוך שימוש בפרוקסי TCP. המיקרו-פרוקסי של Linkerd מבוסס על Rust ונקרא Linkerd-proxy.

Linkerd פשוטה יותר מ-Istio בזכות ההתמקדות שלה ב-Kubernetes. עם זאת, מערך התכונות שלה דומה לזה של Istio, והארכיטקטורה המרכזית שלה דומה. Linkerd כוללת ממשק משתמש, מישור נתונים ומישור בקרה.

Consul היא רשת שירות פתוחה מחברת HashiCorp המשלבת עם כלי תשתית אחרים של HashiCorp. מישור הנתונים של Consul תומך הן במודל פרוקסי והן במודל אינטגרציה טבעית. הוא מציע פרוקסי מובנה אך יכול גם לעבוד עם Envoy.

Consul פועלת מעבר ל-Kubernetes, תומכת בפלטפורמות כמו Nomad. היא משתמשת בסוכנים על כל צומת לצורך בדיקות בריאות ומתקשרת עם שרתי Consul לאחסון ושכפול נתונים. למרות שהיא מציעה תכונות סטנדרטיות של רשת שירות, Consul מורכבת יותר לפריסה וניהול.

10. סיכום

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