הגדרת הגדרות מתקדמות

במאמר הזה יש הערות שיכולות לעזור לכם להגדיר את Cloud Service Mesh.

הגדרת מכונה וירטואלית אחת ב-Compute Engine ל-Cloud Service Mesh

ההליך הזה הוא דוגמה לאופן שבו אפשר להטמיע פריסה של קובץ עזר חיצוני וחסימת תנועה כדי לספק ל-VM גישה לשירותי Cloud Service Mesh.

כדי להשתמש בהליך הזה, צריך להתקין את Docker. פועלים לפי ההוראות של Docker להתקנת Docker Engine.

אם אתם מבצעים את התהליך הזה כדי להגדיר את Cloud Service Mesh במכונה וירטואלית אחת, חלק ממשימות ההגדרה דורשות גישה למארח Linux. המארח יכול להיות מכונה מקומית או מכונה וירטואלית (VM) שפועלת ברשת הענן הווירטואלי הפרטי (VPC).

קודם מורידים ומכינים את קובצי התצורה ואת הסקריפטים לדוגמה.

  1. מתחברים למארח Linux שבו משתמשים במהלך תהליך ההגדרה.

  2. מורידים את הארכיון של הקבצים הנדרשים למארח Linux ומחלצים את הארכיון:

    wget https://storage.googleapis.com/traffic-director/traffic-director-xdsv3.tar.gz
tar -xzvf traffic-director-xdsv3.tar.gz; cd traffic-director-xdsv3

    הארכיון מכיל את הקבצים הבאים:

    • ‫sidecar.env – קובץ תצורה עם משתני סביבה.
    • ‫iptables.sh – סקריפט להגדרת כללי netfilter.
    • ‫bootstrap_template.yaml – קובץ תבנית Bootstrap ל-Envoy.
    • ‫run.sh – סקריפט ברמה העליונה שמשתמש בקובץ ההגדרות sidecar.env כדי להגדיר את iptables ליירוט ולהריץ את שרת ה-proxy של Envoy sidecar.

  3. בכל מארח שמריץ פרוקסי מסוג קובץ עזר חיצוני, יוצרים משתמש מערכת כדי להריץ את תהליך הפרוקסי של Envoy. זהו המשתמש של שרת ה-proxy של Envoy. הכניסה מושבתת עבור המשתמש של Envoy proxy.

    sudo adduser --system --disabled-login envoy

  4. עורכים את קובץ sidecar.env כדי לשנות את ההגדרה. כדי לקבל תיאור מפורט של כל משתנה, קוראים את ההערות בשורות בקובץ התצורה.

    1. בקובץ sidecar.env, מגדירים את המשתנה ENVOY_USER לשם המשתמש שבוחרים להיות משתמש ה-proxy של Envoy.

לאחר מכן, לכל מארח של מכונה וירטואלית שמריץ אפליקציות באמצעות Cloud Service Mesh, מבצעים את השלבים הבאים:

  1. מעתיקים את כל ספריית traffic-director-xdsv3 עם הקובץ sidecar.env ששונה לכל מארח של מכונה וירטואלית שבו פועלות אפליקציות שצפויות להשתמש ב-Cloud Service Mesh.
  2. מוסיפים את הסקריפט run.sh לסקריפט לטעינה בזמן ההפעלה של המערכת, כדי להבטיח שהסקריפט יפעל אחרי כל הפעלה מחדש של ה-VM.

  3. בכל מארח של מכונה וירטואלית, מריצים את הסקריפט run.sh:

    cd traffic-director-xdsv3
sudo ./run.sh start

  4. מוודאים ש-Envoy proxy הופעל בצורה תקינה.

    sudo ./run.sh status

    הפלט הבא אמור להתקבל:

    OK: Envoy seems to be running.
OK: Traffic interception seems to be enabled.

    כדי לאמת את כיוון חסימת התנועה, אפשר להשתמש באפשרויות הבאות:

    sudo iptables -S -t nat | grep ISTIO_REDIRECT

    הפלט הצפוי: 

    -N ISTIO_REDIRECT
-A ISTIO_OUTPUT -j ISTIO_REDIRECT
-A ISTIO_REDIRECT -p tcp -j REDIRECT --to-ports 15001`

מיפוי של כללי ניתוב

יש שתי דרכים להגדיר ניתוב במפת כללי ניתוב.

אפשר להפעיל ניתוב על סמך כתובת ה-VIP והיציאה של היעד בפועל של השירות. אם מגדירים כתובת IP וירטואלית של השירות כפרמטר IPAddress של כלל ההעברה, רק תנועה שמיועדת לכתובת הזו ולפורט המשויך לה תתאים ותנותב על סמך פרמטרים של מארח ונתיב שצוינו במפת URL.

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

בהתאם לשתי הגישות האלה, שמות המארחים שמוגדרים בכללי המארחים, שמשויכים לזוג של יציאת יעד ו-VIP, או ליציאת יעד (כשה-VIP הוא 0.0.0.0), צריכים להיות ייחודיים בהגדרות של Service mesh. כלומר, אי אפשר להשתמש באותו שם מארח לשני שירותים שונים עם מערכות עורפיות שונות.

לא משנה באיזו שיטה בוחרים, התנועה אל כתובת ה-VIP שאליה שם המארח או ה-FQDN של השירות מפנים, ואל היציאה שהשירות מאזין לה, חייבת להיעצר ולהיות מופנית אל פרוקסי ה-sidecar. פרטים מלאים על הגדרת המארח זמינים במאמר הגדרת מכונה וירטואלית אחת של Compute Engine ל-Cloud Service Mesh.

לכל כלל העברה ברשת VPC צריכה להיות שילוב ייחודי של כתובת IP ויציאה לכל רשת VPC, כולל כתובת 0.0.0.0. אם יוצרים יותר מכלל העברה אחד עם אותה כתובת IP ואותו פורט ברשת VPC מסוימת, רק כלל ההעברה הראשון תקף. המערכת מתעלמת מהשאר.

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

הגדרה מתקדמת של יירוט תעבורה

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

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

כדי לעשות את זה, משנים את הגדרת המארח של מכונת ה-VM ב-Compute Engine לפי ההוראות הבאות מתוך הליך ההגדרה של Cloud Service Mesh עם מכונות וירטואליות ופריסה ידנית של Envoy:

  1. קובעים את טווח כתובות ה-IP שהשירותים שמנוהלים על ידי Cloud Service Mesh צריכים להפנות אליהן. התנועה שמיועדת לכתובות ה-IP האלה נחסמת ומופנית מחדש לפרוקסי של ה-sidecar. הטווח ספציפי לפריסה שלכם.

  2. בקובץ sidecar.env, מגדירים את הערך של SERVICE_CIDR לטווח הזה. תעבורת הנתונים לכתובות ה-IP האלה מנותבת מחדש על ידי netfilter לשרת proxy מסוג קובץ עזר חיצוני, ומתבצע איזון עומסים בהתאם להגדרה שסופקה על ידי Cloud Service Mesh.

  3. לא נדרש ששרת ה-proxy של sidecar יפעל כמשתמש ייעודי שמוחרג מיירוט תנועה. עם זאת, מומלץ לעשות זאת.

  4. אחרי שמריצים את הסקריפט run.sh, כמו שמתואר בהליך הראשי, iptables מוגדר ליירוט ולהפניה מחדש של הטווח הספציפי הזה בלבד.

  5. מריצים את הפקודה הבאה כדי לוודא שה-netfilter מוגדר בצורה נכונה. במקום ${SERVICE_CIDR}, מחליפים את הערך שהגדרתם כטווח כתובות ה-IP שנקלטו.

    sudo iptables -L -t nat | grep -E "(ISTIO_REDIRECT).+${SERVICE_CIDR})"