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

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

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

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

בדף הזה מתוארות שיטות מומלצות לפריסה ולשדרוג של שרתי 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 proxies לשירותים.

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

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

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

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

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

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

פריסת שערים

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

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

   kubectl create namespace GATEWAY_NAMESPACE
   

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

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

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

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

kubectl delete deploy/istio-ingressgateway -n GATEWAY_NAMESPACE

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