‫Anthos Service Mesh ו-Traffic Director נקראים עכשיו Cloud Service Mesh. מידע נוסף זמין בסקירה הכללית על Cloud Service Mesh.

‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

התקנה ושדרוג של שערים באמצעות ממשקי Istio API

‫Cloud Service Mesh מאפשר לכם לפרוס ולנהל שערי גישה כחלק מ-Service mesh. שער מתאר מאזן עומסים שפועל בקצה של הרשת ומקבל חיבורים נכנסים או יוצאים של HTTP/TCP. שערים משמשים בעיקר לניהול תעבורת נתונים נכנסת (ingress), אבל אפשר גם להגדיר שערים לניהול סוגים אחרים של תעבורת נתונים.

שערי יציאה (egress): שער יציאה מאפשר להגדיר צומת יציאה ייעודי לתעבורת נתונים שיוצאת מהרשת, וכך להגביל את השירותים שיכולים או צריכים לגשת לרשתות חיצוניות, או לאפשר בקרה מאובטחת של תעבורת נתונים יוצאת כדי להוסיף אבטחה לרשת, למשל.
שערים לדואר נכנס: שער לדואר נכנס מאפשר להגדיר צומת כניסה ייעודי לקבלת חיבורי HTTP/TCP נכנסים.
שערי מזרח-מערב: שרת proxy לתעבורת נתונים מזרח-מערב, שמאפשר לעומסי עבודה של שירותים לתקשר מעבר לגבולות האשכול ברשת מרובת-פרימריות ברשתות שונות. כברירת מחדל, השער הזה יהיה ציבורי באינטרנט.

בדף הזה מתוארות שיטות מומלצות לפריסה ולשדרוג של שרתי proxy של שערים, וגם דוגמאות להגדרת שרתי proxy של שערים משלכם ב-istio-ingressgateway וב-istio-egressgateway.

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

שיטות מומלצות לפריסת שערים

השיטות המומלצות לפריסת שערים תלויות בסוג מישור הנתונים שבו אתם משתמשים: מישור נתונים מנוהל או מישור נתונים לא מנוהל.

שיטות מומלצות למישור נתונים מנוהל

מפעילים את מישור הנתונים המנוהל.
מוסיפים תווית של גרסה בניהול למרחב שמות.
פריסה וניהול של רמת הבקרה והשערים בנפרד.
השיטה המומלצת לאבטחה היא לפרוס שערים במרחב שמות שונה ממישור הבקרה.
משתמשים בהחדרת sidecar אוטומטית (הזרקה אוטומטית) כדי להזריק את הגדרות ה-proxy לשערי הכניסה, בדומה להזרקה של sidecar proxies לשירותים.

השיטות המומלצות האלה:

חשוב לוודא שהשערים המנוהלים מתעדכנים אוטומטית כדי ליהנות מהשיפורים ועדכוני האבטחה האחרונים.
העברת הניהול והתחזוקה של מופעי שער למישור הנתונים המנוהל של Cloud Service Mesh.

שיטות מומלצות למישור נתונים לא מנוהל

פריסה וניהול של רמת הבקרה והשערים בנפרד.
השיטה המומלצת לשמירה על האבטחה היא לפרוס שערים במרחב שמות שונה ממישור הבקרה.
משתמשים בהחדרת sidecar אוטומטית (הזרקה אוטומטית) כדי להזריק את הגדרות ה-proxy לשערי הכניסה, בדומה להזרקה של sidecar proxies לשירותים.

השיטות המומלצות האלה:

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

פריסת שער לדוגמה

כדי לתמוך במשתמשים עם כלי פריסה קיימים, Cloud Service Mesh תומך באותן דרכים לפריסת שער כמו Istio: IstioOperator,‏ Helm ו-Kubernetes YAML. כל שיטה מניבה את אותה תוצאה. אפשר לבחור את השיטה שאתם הכי מכירים, אבל אנחנו ממליצים להשתמש בשיטת ה-YAML של Kubernetes כי קל יותר לשנות אותה ואפשר לאחסן מניפסטים עם נתונים בניהול גרסאות.

בשלבים הבאים מוסבר איך פורסים שער לדוגמה.

יוצרים מרחב שמות לשער אם עדיין אין כזה. מחליפים את GATEWAY_NAMESPACE בשם של מרחב השמות.
```
kubectl create namespace GATEWAY_NAMESPACE
```
מפעילים את מרחב השמות להחדרה. השלבים תלויים בהטמעה של מישור הבקרה.
מנוהל (TD)
1. מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
מנוהל (Istiod)
חשוב לדעת: השימוש ב-Managed Cloud Service Mesh באמצעות הטמעת מישור הבקרה ISTIOD יצא משימוש. צריך לעדכן את כל צי המכשירים המנוהלים של ISTIOD להטמעה של רמת הבקרה TRAFFIC_DIRECTOR.

מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
אם אתם משתמשים קיימים במישור הבקרה המנוהל של Istiod: מומלץ להשתמש בהזרקה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהזרקה מבוססת-עדכון. פועלים לפי ההוראות הבאות:
1. מריצים את הפקודה הבאה כדי לאתר את ערוצי ההפצה הזמינים:
  
  kubectl -n istio-system get controlplanerevision
  
  הפלט אמור להיראות כך:
  
  NAME AGE asm-managed-rapid 6d7h
  
  הערה: אם ברשימה שלמעלה מופיעות שתי גרסאות של מישור הבקרה, צריך להסיר אחת מהן. אין תמיכה בכמה ערוצי מישור בקרה באשכול.
  
  בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.
2. מחילים את תווית הגרסה על מרחב השמות:
  
  kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
בתוך האשכול
חשוב לדעת: השימוש ב-Cloud Service Mesh בתוך האשכול באמצעות מישור הבקרה ISTIOD ב-GKE ב- Google Cloud יצא משימוש. אנחנו ממשיכים לתמוך ב-Cloud Service Mesh עם מישור בקרה בתוך האשכול ב-Google Distributed Cloud (תוכנה בלבד), כפי שמתואר במאמר פלטפורמות נתמכות.

מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
kubectl label namespace GATEWAY_NAMESPACE \ istio.io/rev- istio-injection=enabled --overwrite
מומלץ להשתמש בהחדרה שמוגדרת כברירת מחדל, אבל יש תמיכה גם בהחדרה שמבוססת על תיקון: פועלים לפי ההוראות הבאות:
1. משתמשים בפקודה הבאה כדי לאתר את תווית הגרסה ב-istiod:
  
  kubectl get deploy -n istio-system -l app=istiod -o \ jsonpath={.items[*].metadata.labels.'istio\.io\/rev'}'{"\n"}'
2. מחילים את תווית הגרסה על מרחב השמות. בפקודה הבאה, REVISION_LABEL הוא הערך של התווית istiod revision שרשמתם בשלב הקודם.
  
  kubectl label namespace GATEWAY_NAMESPACE \ istio-injection- istio.io/rev=REVISION_LABEL --overwrite
מעתיקים את קובצי ההגדרות של שערים לדוגמה ממאגר anthos-service-mesh.
עוברים לספרייה samples. כדי לוודא שאתם בספרייה הנכונה, מריצים את הפקודה ls כדי להציג את תוכן הספרייה, ואז מוודאים שיש ספרייה בשם gateways (שתהיה לכם גישה אליה בשלב הבא) וספרייה בשם online-boutique.
פריסת שער כניסה או יציאה. הם נמצאים בספרייה samples/gateways/ כמו שהם, או שאתם יכולים לשנות אותם לפי הצורך.
תעבורת נתונים נכנסת (Ingress)
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
תעבורת נתונים יוצאת (egress)
kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway

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

kubectl get pod,service -n GATEWAY_NAMESPACE

מוודאים שהפלט דומה לזה:

NAME                                      READY   STATUS    RESTARTS   AGE
pod/istio-ingressgateway-856b7c77-bdb77   1/1     Running   0          3s

NAME                           TYPE           CLUSTER-IP     EXTERNAL-IP      PORT(S)        AGE
service/istio-ingressgateway   LoadBalancer   10.24.5.129    34.82.157.6      80:31904/TCP   3s

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

בוררי שערים

אתם יכולים להחיל הגדרת Gateway על שרתי ה-proxy‏ istio-ingressgateway ו-istio-egressgateway כדי לנהל את תעבורת הנתונים הנכנסת והיוצאת ברשת ה-Mesh שלכם, וכך לציין איזו תעבורת נתונים אתם רוצים שתכנס לרשת או תצא ממנה. משאבי ההגדרה של Gateway משתמשים בתוויות של ה-Pods בפריסת Gateway, ולכן חשוב שהבורר של Gateway יתאים לתוויות האלה.

לדוגמה, בפריסות הקודמות, התווית istio=ingressgateway מוגדרת ב-Pods של השער. כדי להחיל הגדרת שער על הפריסות האלה, צריך לבחור את אותה תווית:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
...

דוגמה להגדרת Gateway ושירות וירטואלי מופיעה בקובץ frontend.yaml באפליקציית הדוגמה Online Boutique.

שדרוג שערים

שדרוגים במקום

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

אם רוצים לשנות את הגרסה של מישור הבקרה שבה נעשה שימוש בשער, אפשר להגדיר את התווית istio.io/rev בפריסת השער. פעולה זו תפעיל גם הפעלה מחדש מתגלגלת.

מישור בקרה מנוהל

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

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

מישור בקרה בתוך האשכול

חשוב לדעת: השימוש ב-Cloud Service Mesh בתוך האשכול באמצעות מישור הבקרה ISTIOD ב-GKE ב- Google Cloud יצא משימוש. אנחנו ממשיכים לתמוך ב-Cloud Service Mesh עם מישור בקרה בתוך האשכול ב-Google Distributed Cloud (תוכנה בלבד), כפי שמתואר במאמר פלטפורמות נתמכות.

כדי להחיל את אותו דפוס על השערים כשיש לכם מישור בקרה בתוך האשכול, תצטרכו לשנות את הגרסה של מישור הבקרה שנמצא בשימוש על ידי השער. מגדירים את התווית istio.io/rev בפריסת השער שתפעיל הפעלה מחדש הדרגתית. השלבים הנדרשים תלויים בשאלה אם צריך לעדכן את תווית הגרסה במרחב השמות ו/או ב-gateway pod.

אם סימנתם את מרחב השמות להוספה, צריך להגדיר את התווית istio.io/rev במרחב השמות לערך הגרסה החדש:
```
  kubectl label namespace GATEWAY_NAMESPACE \
    istio-injection- istio.io/rev=REVISION \
    --overwrite
```

אם הפעלתם הזרקה רק עבור ה-pod של השער, צריך להגדיר את התווית istio.io/rev בהטמעה לערך התיקון החדש, כמו בקובץ ה-YAML הבא של Kubernetes:

cat <<EOF > gateway-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        # This is required to tell Cloud Service Mesh to inject the gateway with the
        # required configuration.
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION
    spec:
      containers:
      - name: istio-proxy
        image: auto # The image will automatically update each time the pod starts.
EOF

kubectl apply -f gateway-deployment.yaml

שדרוגים של גרסת קנרית (מתקדם)

אם אתם משתמשים ברמת הבקרה בתוך האשכול ורוצים לשלוט בהשקה של גרסה חדשה של רמת הבקרה בצורה הדרגתית יותר, אתם יכולים לפעול לפי דפוס השדרוג הקנרי. אתם יכולים להפעיל כמה גרסאות של פריסת שער ולוודא שהכול פועל כמצופה עם קבוצת משנה של התנועה. לדוגמה, אם רוצים להשיק גרסה חדשה, קנרית, יוצרים עותק של פריסת שער עם התווית istio.io/rev=REVISION שמוגדרת לגרסה החדשה ושם חדש, למשל istio-ingressgateway-canary:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: istio-ingressgateway-canary
  namespace: GATEWAY_NAMESPACE
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  template:
    metadata:
      annotations:
        inject.istio.io/templates: gateway
      labels:
        istio: ingressgateway
        istio.io/rev: REVISION # Set to the control plane revision you want to deploy
    spec:
      containers:
      - name: istio-proxy
        image: auto

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

kubectl get endpoints -o "custom-columns=NAME:.metadata.name,PODS:.subsets[*].addresses[*].targetRef.name"

NAME                   PODS
istio-ingressgateway   istio-ingressgateway-788854c955-8gv96,istio-ingressgateway-canary-b78944cbd-mq2qf

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

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

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

kubectl delete deploy/istio-ingressgateway-canary -n GATEWAY_NAMESPACE

הגדרה מתקדמת

פריסת שערים שמסיימים תעבורת TLS

פרטים נוספים מופיעים במאמר בנושא הגדרת סיום TLS בשער כניסה.

הגדרת גרסת TLS מינימלית לשער

ב-Cloud Service Mesh, גרסת ה-TLS המינימלית שמוגדרת כברירת מחדל לשרתי שער היא 1.2. אפשר להגדיר את גרסת ה-TLS המינימלית באמצעות השדה minProtocolVersion. מידע נוסף זמין במאמר בנושא ServerTLSSettings.

תכונות שלא נתמכות

אם יש לכם TRAFFIC_DIRECTOR הטמעה של מישור הבקרה, השדות או הערכים הבאים ב-Gateway לא נתמכים:

‫ServerTLSSettings.TLSmode עם ערך AUTO_PASSTHROUGH
ServerTLSSettings.verifyCertificateSpki
ServerTLSSettings.verifyCertificateHash

פתרון בעיות בשערי תשלום

העדכון של תמונת השער מ-`auto` נכשל

כשפורסים או משדרגים שער, Cloud Service Mesh מוסיף את הערך auto כמחזיק מקום בשדה image. אחרי הקריאה ל-webhook משנה, Cloud Service Mesh מחליף אוטומטית את ה-placeholder הזה בתמונת ה-proxy בפועל של Cloud Service Mesh. אם הקריאה ל-webhook לשינוי נכשלת, ה-placeholder‏ auto נשאר, והמאגר לא נמצא. בדרך כלל הבעיה נובעת מתווית שגויה של מרחב שמות. מוודאים שהגדרתם את מרחב השמות הנכון ואז פורסים או משדרגים שוב את השער.