התקנה ושדרוג של שערים

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

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

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

בדף הזה מתוארות שיטות מומלצות לפריסה ולשדרוג של שרתי proxy של שערים, וגם דוגמאות להגדרת שרתי proxy של שערים משלכם מסוג istio-ingressgateway ו-istio-egressgateway. אפשר לבצע פעולות כמו פיצול תנועה, הפניות אוטומטיות ולוגיקה של ניסיון חוזר על ידי החלת הגדרת שער על שרתי ה-proxy של השער. במקום להוסיף ניתוב תנועה בשכבת האפליקציה (L7) לאותו משאב API, מקשרים שירות וירטואלי ל-Gateway. כך אפשר לנהל את התעבורה בשער כמו כל תעבורה אחרת במישור הנתונים ב-Service mesh.

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

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

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

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

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

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

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

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

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

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

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

פריסת שערים

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

1. יוצרים מרחב שמות לשער אם עדיין אין כזה. מחליפים את GATEWAY_NAMESPACE בשם מרחב השמות.

   kubectl create namespace GATEWAY_NAMESPACE
   

2. כדי להפעיל הוספה אוטומטית, צריך להוסיף את תוויות ברירת המחדל להוספה למרחבי השמות אם תג ברירת המחדל מוגדר, או את תווית הגרסה למרחב השמות. התווית שמוסיפים תלויה גם בשאלה אם פרסתם Cloud Service Mesh מנוהלת או התקנתם את מישור הבקרה באשכול. תווית משמשת את ה-webhook של sidecar injector כדי לשייך sidecars מוזרקים לגרסה מסוימת של מישור הבקרה.

   בוחרים את הכרטיסייה שלמטה בהתאם לסוג ההתקנה (מנוהלת או בתוך האשכול).

   מנוהל

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

   kubectl -n istio-system get controlplanerevision
   

   הפלט אמור להיראות כך:

   NAME                AGE
   asm-managed         6d7h
   asm-managed-rapid   6d7h
   

   בפלט, הערך בעמודה NAME הוא תווית הגרסה שתואמת לערוץ ההפצה שזמין לגרסה של Cloud Service Mesh.

   בתוך האשכול

   במישורי בקרה בתוך האשכול, בדרך כלל ל-istiod Service ול-Deployment יש תווית של גרסת תיקון שדומה ל-istio.io/rev=asm-11910-9, כאשר asm-11910-9 מציין את הגרסה של Cloud Service Mesh. המספר של ה-revision הופך לחלק מistiod שם השירות, לדוגמה: istiod-asm-11910-9.istio-system

   משתמשים בפקודה הבאה כדי לאתר את תווית הגרסה ב-istiod עבור מישור הבקרה בתוך האשכול:

   kubectl get deploy -n istio-system -l app=istiod \
     -o=jsonpath='{.items[*].metadata.labels.istio\.io\/rev}''{"\n"}'
   

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

   הערה: אפשר להחליף את istio.io/rev בתווית istio-injection=enabled אם תג ברירת המחדל מוגדר. כדי לוודא שתג ברירת המחדל קיים, מריצים את הפקודה istioctl tag list עם istioctl מ-OUTPUT_DIR.

   kubectl label namespace GATEWAY_NAMESPACE istio-injection- istio.io/rev=REVISION --overwrite
   

4. אם התקנתם את Cloud Service Mesh באמצעות asmcli, עוברים לספרייה שציינתם ב---output_dir, ואז מריצים את הפקודה cd כדי לעבור לספרייה samples.

   חשוב: כדי לוודא שאתם בספרייה הנכונה samples, מריצים את הפקודה ls כדי להציג את תוכן הספרייה ומוודאים שיש ספרייה gateways (שתהיה לכם גישה אליה בשלב הבא) וספרייה online-boutique.

   אם לא התקנתם באמצעות asmcli, צריך להעתיק את קובצי ההגדרות של השערים ממאגר anthos-service-mesh.

5. אפשר לפרוס את הגדרת שער לדוגמה שנמצאת בספרייה samples/gateways/ כמו שהיא, או לשנות אותה לפי הצורך.

   תעבורת נתונים נכנסת (Ingress)

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-ingressgateway
   

   תעבורת נתונים יוצאת (egress)

   kubectl apply -n GATEWAY_NAMESPACE -f samples/gateways/istio-egressgateway
   

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

   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 Anthos 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
  

  הערה: אם image לא מתעדכן באופן אוטומטי עם תמונת ה-proxy של Cloud Service Mesh בפועל, המאגר לא יימצא ותתרחש שגיאה. כאן מוסבר איך לפתור בעיות בשערי תשלום.

שדרוגים של גרסה ראשונית (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

הערה: אם image לא מתעדכן באופן אוטומטי עם תמונת ה-proxy בפועל של Cloud Service Mesh, המאגר לא יימצא ותתרחש שגיאה. לשלבים הבאים, אפשר לעיין במאמר בנושא פתרון בעיות בשערי תשלום.

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

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

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

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

לא הצלחנו לעדכן את תמונת השער מ-auto

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