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

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

התקנה ושדרוג של שערים באמצעות ממשקי 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 proxies לשירותים.

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

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

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

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

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

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

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

שדרוג שערים

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

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

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

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

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

kubectl rollout restart deployment istio-ingressgateway \
  -n GATEWAY_NAMESPACE

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

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

כשפריסת ה-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

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