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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יוצרים מרחב שמות לשער אם עדיין אין כזה. מחליפים את GATEWAY_NAMESPACE בשם מרחב השמות.
```
kubectl create namespace GATEWAY_NAMESPACE
```
מפעילים את מרחב השמות להחדרה. השלבים תלויים בהטמעה של מישור הבקרה.
מנוהל (TD)
1. מחילים את תווית ההזרקה שמוגדרת כברירת מחדל על מרחב השמות:
```
kubectl label namespace GATEWAY_NAMESPACE \
    istio.io/rev- istio-injection=enabled --overwrite
```
מנוהל (Istiod)
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
```
  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
בתוך האשכול
מומלץ: מריצים את הפקודה הבאה כדי להחיל את תווית ברירת המחדל של הזרקה על מרחב השמות:
```
  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.
פריסת שער לתעבורת נתונים נכנסת (ingress) או יוצאת (egress). הקבצים האלה נמצאים בספרייה 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 נועדו לספק הדרכה ולעזור לכם להתחיל במהירות. אתם יכולים להתאים אותם לצרכים שלכם.

בוררי שער

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

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

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

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

שדרוג שערים

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

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

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

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

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

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

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

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

אם סימנתם את מרחב השמות להוספה, צריך להגדיר את התווית 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

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

אם אתם משתמשים במישור הבקרה בתוך האשכול ורוצים לשלוט בהשקה של גרסה חדשה של מישור הבקרה בצורה הדרגתית יותר, אתם יכולים לפעול לפי דפוס השדרוג של גרסה ראשונית (canary). אתם יכולים להפעיל כמה גרסאות של פריסת שער ולוודא שהכול פועל כצפוי עם קבוצת משנה של התנועה. לדוגמה, אם רוצים להשיק גרסה חדשה, גרסה ראשונית (canary), יוצרים עותק של פריסת שער עם התווית 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

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

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

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

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

אם נתקלתם בבעיה כשבדקתם את האפליקציה עם הגרסה החדשה של שער הכניסה, הריצו את הפקודה הזו כדי לחזור לגרסה הישנה על ידי מחיקת ה-Deployment עם הגדרת התווית החדשה 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 הזה בתמונה בפועל של פרוקסי Cloud Service Mesh. אם הקריאה ל-webhook לשינוי נכשלת, ה-placeholder‏ auto נשאר, והמאגר לא נמצא. בדרך כלל הבעיה נובעת מתווית שגויה של מרחב שמות. מוודאים שהגדרתם את מרחב השמות הנכון ואז פורסים או משדרגים שוב את השער.