התקנת Cloud Service Mesh לעומסי עבודה ב-Kubernetes Google Cloud

בדף הזה מוסבר איך להתקין את Cloud Service Mesh לא מנוהל בתוך אשכול לעומסי עבודה של Kubernetes ב- Google Cloud:

  • מריצים את הפקודה asmcli כדי לבצע התקנה חדשה של Cloud Service Mesh 1.30.4-asm.14.
  • אפשר גם לפרוס שער כניסה.
  • פורסים או פורסים מחדש את עומסי העבודה כדי להחדיר פרוקסי מסוג sidecar.

הוראות להכנת התקנה אופליין של Cloud Service Mesh זמינות במאמר הכנת התקנה אופליין של Cloud Service Mesh. תצטרכו לציין את האפשרויות --offline ו---output_dir כשמריצים את הפקודה asmcli install.

מגבלות

חשוב לשים לב למגבלות הבאות:

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

  • לכלי asmcli צריכה להיות גישה לנקודת הקצה של Google Kubernetes Engine‏ (GKE). אפשר להגדיר גישה דרך שרת מעבר, כמו מכונה וירטואלית של Compute Engine בענן וירטואלי פרטי (VPC), כדי לתת גישה ספציפית.

לפני שמתחילים

לפני שמתחילים, חשוב לוודא:

תפקידים שנדרשים להתקנה של Cloud Service Mesh בתוך האשכול

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

שם התפקיד מזהה תפקיד אישור גישה למיקום תיאור
אדמין ב-GKE Hub roles/gkehub.admin פרויקט Fleet גישה מלאה ל-GKE Hub ולמשאבים קשורים.
אדמין ב-Kubernetes Engine roles/container.admin פרויקט של אשכול. שימו לב: צריך להקצות את התפקיד הזה גם בפרויקט של ה-Fleet וגם בפרויקט של האשכול כדי ליצור קישורים בין פרויקטים. התפקיד הזה מספק גישה לניהול מלא של אשכולות קונטיינרים ואובייקטים של Kubernetes API שלהם.
Mesh Config Admin roles/meshconfig.admin פרויקט Fleet ופרויקט אשכול ההרשאה הזו מספקת את ההרשאות שנדרשות לאתחול רכיבים מנוהלים של Cloud Service Mesh, כמו רמת בקרה מנוהלת והרשאת קצה עורפי שמאפשרת לעומסי עבודה לתקשר עם Stackdriver בלי שכל אחד מהם יקבל הרשאה בנפרד (גם לרמות בקרה מנוהלות וגם לרמות בקרה בתוך האשכול).
אדמין IAM בפרויקט roles/resourcemanager.projectIamAdmin פרויקט של אשכול הרשאות לניהול מדיניות IAM בפרויקטים.
אדמין בחשבון שירות roles/iam.serviceAccountAdmin פרויקט Fleet אימות כחשבון שירות.
אדמין של ניהול שירותים roles/servicemanagement.admin פרויקט Fleet שליטה מלאה במשאבים של ניהול שירותי Google.
Service Usage Admin roles/serviceusage.serviceUsageAdmin פרויקט Fleet אפשרות להפעיל, להשבית ולבדוק את מצבי השירות, לבדוק פעולות ולצרוך מכסה וחיוב בפרויקט צרכן.(הערה 1)
אדמין של שירות CA בטא roles/privateca.admin פרויקט Fleet גישה מלאה לכל המשאבים של שירות CA. (הערה 2)

הערות:

  1. אדמין של Service Usage – התפקיד הזה נדרש כתנאי מוקדם להפעלת mesh.googleapis.com API כשמבצעים הקצאת משאבים ראשונית של Cloud Service Mesh מנוהל.
  2. אדמין של שירות CA – התפקיד הזה נדרש רק אם אתם משלבים עם שירות CA.

התקנה של Cloud Service Mesh

בקטעים הבאים מוסבר איך להתקין את Cloud Service Mesh:

  1. מריצים את הפקודה asmcli install כדי להתקין את מישור הבקרה בתוך האשכול באשכול יחיד. בקטעים הבאים מפורטות דוגמאות לשורת הפקודה. הדוגמאות כוללות ארגומנטים נדרשים וארגומנטים אופציונליים שיכולים להיות שימושיים. מומלץ תמיד לציין את הארגומנט output_dir כדי לאתר שערים וכלים לדוגמה, כמו istioctl. רשימת הדוגמאות מופיעה בסרגל הניווט שמשמאל.

  2. אופציונלי: התקנת שער כניסה. כברירת מחדל,‏ asmcli לא מתקין את istio-ingressgateway. מומלץ לפרוס ולנהל את רמת הבקרה ואת השערים בנפרד. אם אתם צריכים להתקין את istio-ingressgateway שמוגדר כברירת מחדל עם מישור הבקרה בתוך האשכול, צריך לכלול את הארגומנט --option legacy-default-ingressgateway.

  3. כדי להשלים את ההגדרה של Cloud Service Mesh, צריך להפעיל הזרקת sidecar אוטומטית ולפרוס או לפרוס מחדש עומסי עבודה.

  4. אם אתם מתקינים את Cloud Service Mesh ביותר מאשכול אחד, מריצים את הפקודה asmcli install בכל אשכול. כשמריצים את הפקודה asmcli install, חשוב להשתמש באותו FLEET_PROJECT_ID לכל אשכול. אחרי שמתקינים את Cloud Service Mesh, אפשר לעיין בהוראות להגדרת רשת מרובת אשכולות ב Google Cloud.

  5. אם האשכולות שלכם נמצאים ברשתות שונות (כמו במצב island), אתם צריכים להעביר שם רשת ייחודי ל-asmcli באמצעות הדגל --network_id.

התקנה של תכונות ברירת מחדל ו-Mesh CA

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

מקומי

מריצים את הפקודות הבאות ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware או ב-Google Distributed Cloud (תוכנה בלבד) ל-bare metal כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ורשות האישורים של Cloud Service Mesh. מזינים את הערכים במחזיקי המקום שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. asmcliהפקודה מגדירה את רשות האישורים של Cloud Service Mesh כך שתשתמש בזהות עומס העבודה של fleet

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

AWS

מריצים את הפקודות הבאות ב-GKE ב-AWS כדי להתקין את מישור הבקרה עם תכונות ברירת מחדל ורשות אישורים של Cloud Service Mesh. מזינים את הערכים במחזיקי המקום שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcliהקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. asmcliהגדרת רשות האישורים של Cloud Service Mesh לשימוש בזהויות עומסי עבודה של fleet.

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

Azure

מריצים את הפקודות הבאות ב-GKE ב-Azure כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ורשות אישורים של Cloud Service Mesh. מזינים את הערכים ב-placeholders שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca mesh_ca
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת ,asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. asmcliהגדרת רשות האישורים של Cloud Service Mesh לשימוש בזהויות עומסי עבודה של fleet.

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

‫Amazon EKS

מריצים את הפקודות הבאות ב-Amazon EKS כדי להתקין את מישור הבקרה עם תכונות ברירת מחדל ורשות אישורים של Cloud Service Mesh. מזינים את הערכים במחזיקי המקום שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --option attached-cluster \
  --network_id default \
  --ca mesh_ca
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --option attached-cluster משנה את כלי החתימה שמוגדר כברירת מחדל ל-istiod.
    • --network_id אם מגדירים רשת Mesh מרובת רשתות, צריך להגדיר את --network_id לערך ייחודי לכל אשכול ברשת ה-Mesh.
    • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. asmcliהגדרת רשות האישורים של Cloud Service Mesh לשימוש בזהויות עומסי עבודה של fleet.

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

Microsoft AKS

מריצים את הפקודות הבאות ב-Microsoft AKS כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ורשות האישורים של Cloud Service Mesh. מזינים את הערכים במחזיקי המקום שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --option attached-cluster \
  --network_id default \
  --ca mesh_ca
    • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer מאפשר רישום ב-GKE Fleet.
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --option attached-cluster משנה את כלי החתימה שמוגדר כברירת מחדל ל-istiod.
    • --network_id אם מגדירים רשת Mesh מרובת רשתות, צריך להגדיר את --network_id לערך ייחודי לכל אשכול ברשת ה-Mesh.
    • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. asmcliהגדרת רשות האישורים של Cloud Service Mesh לשימוש בזהויות עומסי עבודה של fleet.

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

התקנה של תכונות ברירת המחדל ושל Certificate Authority (CA) Service

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

בנוסף לרשות האישורים של Cloud Service Mesh, אפשר להגדיר את Cloud Service Mesh כך שישתמש בCertificate Authority Service. המדריך הזה מאפשר לכם לשלב עם CA Service, מומלץ לתרחישי השימוש הבאים:

  • אם אתם צריכים רשויות אישורים שונות כדי לחתום על אישורים של עומסי עבודה באשכולות שונים.
  • אם אתם צריכים לגבות את מפתחות החתימה ב-Cloud HSM.
  • אם אתם פועלים בתחום עם רגולציה מחמירה וכפופים לדרישות תאימות.
  • אם רוצים לשרשר את רשות האישורים של Cloud Service Mesh לאישור בסיס מותאם אישית של הארגון כדי לחתום על אישורים של עומסי עבודה.

העלות של רשות האישורים של Cloud Service Mesh כלולה בתמחור של Cloud Service Mesh. שירות ה-CA לא נכלל במחיר הבסיסי של Cloud Service Mesh, והוא מחויב בנפרד. בנוסף, שירות CA מגיע עם SLA מפורש, אבל רשות האישורים של Cloud Service Mesh לא מגיעה עם SLA.

הגדרת שירות CA

  1. כדי להימנע מבעיות של השהיה מוגזמת או מהפסקות חשמל פוטנציאליות בין אזורים, צריך ליצור את מאגר אישורים ברמה DevOps ובאותו אזור כמו האשכול שהוא משרת. מידע נוסף זמין במאמר בנושא רמות שמותאמות לעומסי עבודה.
  2. יוצרים את ה-CA כדי שיהיה לפחות רשות אישורים פעילה אחת במאגר ה-CA באותו פרויקט כמו אשכול GKE. שימוש ב-CA משני כדי לחתום על אישורי עומסי עבודה של Cloud Service Mesh. רושמים את מאגר רשויות האישורים שמתאים לרשות האישורים המשנית.

  3. אם המאגר מיועד רק לשרת אישורים לעומסי עבודה של Cloud Service Mesh, צריך להגדיר את מדיניות הנפקת האישורים הבאה למאגר ה-CA:

    policy.yaml

    baselineValues:
  keyUsage:
    baseKeyUsage:
      digitalSignature: true
      keyEncipherment: true
    extendedKeyUsage:
      serverAuth: true
      clientAuth: true
  caOptions:
    isCa: false
identityConstraints:
  allowSubjectPassthrough: false
  allowSubjectAltNamesPassthrough: true
  celExpression:
    expression: subject_alt_names.all(san, san.type == URI && san.value.startsWith("spiffe://PROJECT_ID.svc.id.goog/ns/") )

  4. כדי לעדכן את מדיניות הנפקת האישורים של מאגר רשויות האישורים, משתמשים בפקודה הבאה:

    gcloud privateca pools update CA_POOL --location ca_region --issuance-policy policy.yaml

    מידע על הגדרת מדיניות במאגר זמין במאמר שימוש במדיניות הנפקת אישורים.

  5. אם אתם משתמשים בתבנית אישור, עכשיו צריך להגדיר אותה. מידע נוסף זמין במדריך לשירות CA בנושא אישורים של זהויות לעומסי עבודה. מוודאים שתבנית האישור נוצרה באותו אזור שבו נוצר מאגר רשויות האישורים. אם יש כמה אזורים למאגרי CA, צריך ליצור תבנית אישור לכל אזור.

הגדרת Cloud Service Mesh לשימוש בשירות CA

מריצים את הפקודות הבאות ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware או ב-Google Distributed Cloud (תוכנה בלבד) ל-Bare Metal כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ואת Certificate Authority Service. מזינים את הערכים ב-placeholders שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
  --kubeconfig KUBECONFIG_FILE \
  --fleet_id FLEET_PROJECT_ID \
  --output_dir DIR_PATH \
  --enable_all \
  --ca gcp_cas \
  --platform multicloud \
  --ca_pool  projects/CA_POOL_PROJECT_ID/locations/ca_region/caPools/CA_POOL
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca gcp_cas שימוש ב-Certificate Authority Service כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם להשבתה. asmcliמגדיר את Certificate Authority Service לשימוש בזהות עומס עבודה של Fleet
    • --ca_pool המזהה המלא של מאגר רשויות האישורים של Certificate Authority Service. אם אתם משתמשים בתבנית אישור, צריך להוסיף את מזהה התבנית אחרי :. לדוגמה: 
        --ca_pool projects/CA_POOL_PROJECT_ID/locations/ca_region/caPools/CA_POOL:projects/CA_POOL_PROJECT_ID/locations/ca_region/certificateTemplates/CERT_TEMPLATE_ID

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

התקנת תכונות ברירת מחדל באמצעות Istio CA

בקטע הזה נסביר איך:

  • יצירת אישורים ומפתחות עבור רשות האישורים (CA) של Istio, ש-Cloud Service Mesh משתמש בהם כדי לחתום על עומסי העבודה.
  • מריצים את הפקודה asmcli כדי להתקין את Cloud Service Mesh עם תכונות ברירת המחדל ולהפעיל את Istio CA.

כברירת מחדל, סביבות שבהן מותקן Cloud Service Mesh עם רשות האישורים של Istio מדווחות על מדדים ל-Prometheus. כדי להשתמש בלוחות הבקרה של Cloud Service Mesh, צריך להפעיל את Stackdriver. מידע נוסף זמין במאמר בנושא התקנה עם תכונות אופציונליות.

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

קובץ ה-Makefile ליצירת האישורים נמצא בספריית המשנה istio-1.30.4-asm.14 בספרייה --output_dir שציינתם בפקודה asmcli validate. אם לא הפעלתם את asmcli validate, או אם אין לכם את הספרייה שהורדתם באופן מקומי, תוכלו לקבל את קובץ ה-Makefile על ידי הורדת קובץ ההתקנה של Cloud Service Mesh וחילוץ התוכן.

  1. עוברים לספרייה istio-1.30.4-asm.14.

  2. יוצרים ספרייה בשביל האישורים והמפתחות:

    mkdir -p certs && \
pushd certs

  3. יוצרים מפתח ואישור בסיס:

    make -f ../tools/certs/Makefile.selfsigned.mk root-ca

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

    • ‫root-cert.pem: אישור הבסיס
    • ‫root-key.pem: מפתח הבסיס
    • ‫root-ca.conf: ההגדרה של openssl ליצירת אישור הבסיס
    • ‫root-cert.csr: בקשת החתימה (CSR) של אישור הבסיס

  4. יוצרים מפתח ואישור ביניים:

    make -f ../tools/certs/Makefile.selfsigned.mk cluster1-cacerts

    הפעולה הזו יוצרת את הקבצים האלה בספרייה בשם cluster1:

    • ‫ca-cert.pem: אישורי הביניים
    • ‫ca-key.pem: המפתח הביניים
    • ‫cert-chain.pem: שרשרת האישורים שבה נעשה שימוש ב-istiod
    • ‫root-cert.pem: אישור הבסיס

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

  5. חזרה לספרייה הקודמת:

    popd

  6. מריצים את הפקודה asmcli כדי להתקין רשת באמצעות Istio CA:

    מקומי

    מריצים את הפקודות הבאות ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware או ב-Google Distributed Cloud (תוכנה בלבד) ל-bare metal כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים.

    1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

      kubectl config use-context CLUSTER_NAME

    2. מריצים את asmcli install:

      ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
      • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
      • --enable_all מאפשר לסקריפט:
        • נותנים את הרשאות ה-IAM הנדרשות.
        • מפעילים את ממשקי Google API הנדרשים.
        • מגדירים תווית באשכול שמזהה את הרשת.
        • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • --ca_cert אישור הביניים
      • --ca_key המפתח של אישור הביניים
      • ‫--root_cert אישור הבסיס
      • --cert_chain שרשרת האישורים

    AWS

    מריצים את הפקודות הבאות ב-GKE ב-AWS כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים. אתם יכולים לבחור להפעיל את Ingress עבור רשת המשנה הציבורית או רשת המשנה הפרטית.

    גלוי לכולם

    1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

      kubectl config use-context CLUSTER_NAME

    2. מריצים את asmcli install:

      ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
      • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
      • --enable_all מאפשר לסקריפט:
        • נותנים את הרשאות ה-IAM הנדרשות.
        • מפעילים את ממשקי Google API הנדרשים.
        • מגדירים תווית באשכול שמזהה את הרשת.
        • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • ‫--ca_cert אישור הביניים.
      • --ca_key המפתח של אישור הביניים.
      • ‫--root_cert אישור הבסיס.
      • --cert_chain שרשרת האישורים.

    פרטי

    1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

      kubectl config use-context CLUSTER_NAME

    2. שומרים את קובץ ה-YAML הבא בקובץ בשם istio-operator-internal-lb.yaml:

      apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - enabled: true
      k8s:
        serviceAnnotations:
          service.beta.kubernetes.io/aws-load-balancer-internal: "true"
      name: istio-ingressgateway

    3. מריצים את asmcli install:

      ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH \
  --custom_overlay istio-operator-internal-lb.yaml
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
      • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
      • --enable_all מאפשר לסקריפט:
        • נותנים את הרשאות ה-IAM הנדרשות.
        • מפעילים את ממשקי Google API הנדרשים.
        • מגדירים תווית באשכול שמזהה את הרשת.
        • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • ‫--ca_cert אישור הביניים.
      • --ca_key המפתח של אישור הביניים.
      • ‫--root_cert אישור הבסיס.
      • --cert_chain שרשרת האישורים.
      • ‫--custom_overlay השם של קובץ השכבות שהתקבל. מידע נוסף על קובצי שכבת-על זמין במאמר בנושא הפעלת תכונות אופציונליות במישור הבקרה בתוך האשכול

    Azure

    מריצים את הפקודות הבאות ב-GKE ב-Azure כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים. אתם יכולים להפעיל את Ingress עבור רשת המשנה הציבורית או רשת המשנה הפרטית.

    גלוי לכולם

    1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

      kubectl config use-context CLUSTER_NAME

    2. מריצים את asmcli install:

      ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
      • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
      • --enable_all מאפשר לסקריפט:
        • נותנים את הרשאות ה-IAM הנדרשות.
        • מפעילים את ממשקי Google API הנדרשים.
        • מגדירים תווית באשכול שמזהה את הרשת.
        • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • ‫--ca_cert אישור הביניים.
      • --ca_key המפתח של אישור הביניים.
      • ‫--root_cert אישור הבסיס.
      • --cert_chain שרשרת האישורים.

    פרטי

    1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

      kubectl config use-context CLUSTER_NAME

    2. שומרים את קובץ ה-YAML הבא בקובץ בשם istio-operator-internal-lb.yaml:

      apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - enabled: true
      k8s:
        serviceAnnotations:
          service.beta.kubernetes.io/aws-load-balancer-internal: "true"
      name: istio-ingressgateway

    3. מריצים את asmcli install:

      ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH \
  --custom_overlay istio-operator-internal-lb.yaml
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
      • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
      • --enable_all מאפשר לסקריפט:
        • נותנים את הרשאות ה-IAM הנדרשות.
        • מפעילים את ממשקי Google API הנדרשים.
        • מגדירים תווית באשכול שמזהה את הרשת.
        • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • ‫--ca_cert אישור הביניים.
      • --ca_key המפתח של אישור הביניים.
      • ‫--root_cert אישור הבסיס.
      • --cert_chain שרשרת האישורים.
      • ‫--custom_overlay השם של קובץ השכבות שהתקבל. מידע נוסף על קובצי שכבת-על זמין במאמר בנושא הפעלת תכונות אופציונליות במישור הבקרה בתוך האשכול

    ‫Amazon EKS

    מריצים את הפקודות הבאות ב-Amazon EKS כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים.

    1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

      kubectl config use-context CLUSTER_NAME

    2. מריצים את asmcli install:

      ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --option attached-cluster \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH \
  --network_id default
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
      • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
      • --enable_all מאפשר לסקריפט:
        • נותנים את הרשאות ה-IAM הנדרשות.
        • מפעילים את ממשקי Google API הנדרשים.
        • מגדירים תווית באשכול שמזהה את הרשת.
        • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
      • --option attached-cluster משנה את כלי החתימה שמוגדר כברירת מחדל ל-istiod.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • --ca_cert אישור הביניים
      • --ca_key המפתח של אישור הביניים
      • ‫--root_cert אישור הבסיס
      • --cert_chain שרשרת האישורים
      • --network_id אם מגדירים רשת Mesh מרובת רשתות, צריך להגדיר את --network_id לערך ייחודי לכל אשכול ברשת ה-Mesh.

    Microsoft AKS

    מריצים את הפקודות הבאות ב-Microsoft AKS כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים.

    1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

      kubectl config use-context CLUSTER_NAME

    2. מריצים את asmcli install:

      HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --option attached-cluster \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH \
  --network_id default
      • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer מאפשר רישום ב-GKE Fleet.
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
      • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
      • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
      • --enable_all מאפשר לסקריפט:
        • נותנים את הרשאות ה-IAM הנדרשות.
        • מפעילים את ממשקי Google API הנדרשים.
        • מגדירים תווית באשכול שמזהה את הרשת.
        • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
      • --option attached-cluster משנה את כלי החתימה שמוגדר כברירת מחדל ל-istiod.
      • -ca citadel שימוש ב-Istio CA כרשות האישורים.
      • --ca_cert אישור הביניים
      • --ca_key המפתח של אישור הביניים
      • ‫--root_cert אישור הבסיס
      • --cert_chain שרשרת האישורים
      • --network_id אם מגדירים רשת Mesh מרובת רשתות, צריך להגדיר את --network_id לערך ייחודי לכל אשכול ברשת ה-Mesh.

התקנה באמצעות Istio CA עם Google Cloud Observability מופעל

כדי להשתמש בלוחות הבקרה של Cloud Service Mesh, צריך להפעיל את Stackdriver.

מקומי

מריצים את הפקודות הבאות ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware או ב-Google Distributed Cloud (תוכנה בלבד) ל-bare metal כדי להתקין את מישור הבקרה עם Stackdriver ותכונות אופציונליות אחרות ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
   --fleet_id FLEET_PROJECT_ID \
   --kubeconfig KUBECONFIG_FILE \
   --output_dir DIR_PATH \
   --platform multicloud \
   --enable_all \
   --ca citadel \
   --ca_cert CA_CERT_FILE_PATH \
   --ca_key CA_KEY_FILE_PATH \
   --root_cert ROOT_CERT_FILE_PATH \
   --cert_chain CERT_CHAIN_FILE_PATH
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת asmcli, הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • -ca citadel שימוש ב-Istio CA כרשות האישורים.
    • --ca_cert אישור הביניים
    • --ca_key המפתח של אישור הביניים
    • ‫--root_cert אישור הבסיס
    • --cert_chain שרשרת האישורים
    • --option stackdriver הפעלת האפשרות Stackdriver. הערה: אפשר להפעיל גם את Stackdriver וגם את Prometheus באמצעות --option prometheus-and-stackdriver.

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

AWS

מריצים את הפקודות הבאות ב-GKE ב-AWS כדי להתקין את מישור הבקרה עם Stackdriver ותכונות אופציונליות אחרות ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים. אתם יכולים להפעיל את Ingress עבור רשת המשנה הציבורית או רשת המשנה הפרטית.

גלוי לכולם

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH \
  --option stackdriver
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • -ca citadel שימוש ב-Istio CA כרשות האישורים.
    • ‫--ca_cert אישור הביניים.
    • --ca_key המפתח של אישור הביניים.
    • ‫--root_cert אישור הבסיס.
    • --cert_chain שרשרת האישורים.
    • --option stackdriver הפעלת האפשרות Stackdriver. הערה: אפשר להפעיל גם את Stackdriver וגם את Prometheus באמצעות --option prometheus-and-stackdriver.

פרטי

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. שומרים את קובץ ה-YAML הבא בקובץ בשם istio-operator-internal-lb.yaml:

    apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - enabled: true
      k8s:
        serviceAnnotations:
          service.beta.kubernetes.io/aws-load-balancer-internal: "true"
      name: istio-ingressgateway

  3. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
  --custom_overlay istio-operator-internal-lb.yaml \
  --option stackdriver
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • -ca citadel שימוש ב-Istio CA כרשות האישורים.
    • ‫--ca_cert אישור הביניים.
    • --ca_key המפתח של אישור הביניים.
    • ‫--root_cert אישור הבסיס.
    • --cert_chain שרשרת האישורים.
    • ‫--custom_overlay השם של קובץ השכבות שהתקבל. מידע נוסף על קובצי שכבת-על זמין במאמר הפעלת תכונות אופציונליות במישור הבקרה בתוך האשכול
    • --option stackdriver הפעלת האפשרות Stackdriver. הערה: אפשר להפעיל גם את Stackdriver וגם את Prometheus באמצעות --option prometheus-and-stackdriver. אפשר גם להפעיל את Stackdriver באמצעות --custom_overlay stackdriver.yaml. צריך להוריד את anthos-service-mesh-package או ליצור את stackdriver.yaml מהמניפסט שסופק.

Azure

מריצים את הפקודות הבאות ב-GKE ב-Azure כדי להתקין את מישור הבקרה עם Stackdriver ותכונות אופציונליות אחרות ועם Istio CA. מזינים את הערכים ב-placeholders שמופיעים. אתם יכולים לבחור להפעיל את Ingress עבור רשת המשנה הציבורית או רשת המשנה הפרטית.

גלוי לכולם

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH \
  --option stackdriver
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • -ca citadel שימוש ב-Istio CA כרשות האישורים.
    • ‫--ca_cert אישור הביניים.
    • --ca_key המפתח של אישור הביניים.
    • ‫--root_cert אישור הבסיס.
    • --cert_chain שרשרת האישורים.
    • --option stackdriver הפעלת האפשרות Stackdriver. הערה: אפשר להפעיל גם את Stackdriver וגם את Prometheus באמצעות --option prometheus-and-stackdriver.

פרטי

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. שומרים את קובץ ה-YAML הבא בקובץ בשם istio-operator-internal-lb.yaml:

    apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    ingressGateways:
    - enabled: true
      k8s:
        serviceAnnotations:
          service.beta.kubernetes.io/aws-load-balancer-internal: "true"
      name: istio-ingressgateway

  3. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert FILE_PATH \
  --ca_key FILE_PATH \
  --root_cert FILE_PATH \
  --cert_chain FILE_PATH
  --custom_overlay istio-operator-internal-lb.yaml \
  --option stackdriver
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת ,asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • -ca citadel שימוש ב-Istio CA כרשות האישורים.
    • ‫--ca_cert אישור הביניים.
    • --ca_key המפתח של אישור הביניים.
    • ‫--root_cert אישור הבסיס.
    • --cert_chain שרשרת האישורים.
    • ‫--custom_overlay השם של קובץ השכבות שהתקבל. מידע נוסף על קובצי שכבת-על זמין במאמר הפעלת תכונות אופציונליות במישור הבקרה בתוך האשכול
    • --option stackdriver הפעלת האפשרות Stackdriver. הערה: אפשר להפעיל גם את Stackdriver וגם את Prometheus באמצעות --option prometheus-and-stackdriver. אפשר גם להפעיל את Stackdriver באמצעות --custom_overlay stackdriver.yaml. צריך להוריד את anthos-service-mesh-package או ליצור את stackdriver.yaml מהמניפסט שסופק.

‫Amazon EKS

מריצים את הפקודות הבאות ב-Amazon EKS כדי להתקין את מישור הבקרה עם Stackdriver ותכונות אופציונליות אחרות ו-Istio CA. מזינים את הערכים ב-placeholders שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH \
  --option stackdriver \
  --option attached-cluster
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcliהקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • -ca citadel שימוש ב-Istio CA כרשות האישורים.
    • --ca_cert אישור הביניים
    • --ca_key המפתח של אישור הביניים
    • ‫--root_cert אישור הבסיס
    • --cert_chain שרשרת האישורים
    • --option stackdriver הפעלת האפשרות Stackdriver. הערה: אפשר להפעיל גם את Stackdriver וגם את Prometheus באמצעות --option prometheus-and-stackdriver.
    • --option stackdriver שינוי כלי החתימה שמוגדר כברירת מחדל ל-istiod.

Microsoft AKS

מריצים את הפקודות הבאות ב-Microsoft AKS כדי להתקין את מישור הבקרה עם תכונות ברירת המחדל ו-Istio CA. מזינים את הערכים במחזיקי המקום שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את asmcli install:

    HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer ./asmcli install \
  --fleet_id FLEET_PROJECT_ID \
  --kubeconfig KUBECONFIG_FILE \
  --output_dir DIR_PATH \
  --platform multicloud \
  --enable_all \
  --ca citadel \
  --ca_cert CA_CERT_FILE_PATH \
  --ca_key CA_KEY_FILE_PATH \
  --root_cert ROOT_CERT_FILE_PATH \
  --cert_chain CERT_CHAIN_FILE_PATH \
  --option stackdriver \
  --option attached-cluster
    • HUB_REGISTRATION_EXTRA_FLAGS=--has-private-issuer מאפשר רישום ב-GKE Fleet.
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת, asmcliהקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • -ca citadel שימוש ב-Istio CA כרשות האישורים.
    • --ca_cert אישור הביניים
    • --ca_key המפתח של אישור הביניים
    • ‫--root_cert אישור הבסיס
    • --cert_chain שרשרת האישורים
    • --option stackdriver הפעלת האפשרות Stackdriver. הערה: אפשר להפעיל גם את Stackdriver וגם את Prometheus באמצעות --option prometheus-and-stackdriver.
    • --option stackdriver שינוי כלי החתימה שמוגדר כברירת מחדל ל-istiod.

התקנה עם תכונות אופציונליות

קובץ שכבת-על הוא קובץ YAML שמכיל IstioOperator משאב בהתאמה אישית (CR) שמעבירים אל asmcli כדי להגדיר את מישור הבקרה. אפשר לשנות את הגדרות ברירת המחדל של מישור הבקרה ולהפעיל תכונה אופציונלית על ידי העברת קובץ ה-YAML אל asmcli. אפשר להוסיף עוד שכבות של כיסוי, וכל קובץ כיסוי מבטל את ההגדרה בשכבות הקודמות. מומלץ לשמור את קובצי השכבות במערכת לניהול גרסאות.

יש שתי אפשרויות להפעלת תכונות אופציונליות: --option ו- --custom_overlay.

משתמשים ב---option אם לא צריך לשנות את קובץ השכבות. בשיטה הזו, asmcliמאחזר את הקובץ ממאגר GitHub בשבילכם.

משתמשים ב---custom_overlay כשצריך להתאים אישית את קובץ השכבת-העל.

מידע נוסף מופיע במאמר הפעלת תכונות אופציונליות במישור הבקרה בתוך האשכול.

מריצים את הפקודות הבאות ב-Google Distributed Cloud (תוכנה בלבד) ל-VMware, ב-Google Distributed Cloud (תוכנה בלבד) לשרת פיזי, ב-GKE ב-AWS, ב-GKE ב-Azure, ב-Amazon EKS או ב-Microsoft AKS. מזינים את הערכים ב-placeholders שמופיעים.

  1. מגדירים את ההקשר הנוכחי לאשכול המשתמשים:

    kubectl config use-context CLUSTER_NAME

  2. מריצים את הפקודה asmcli install כדי להתקין את מישור הבקרה עם תכונה אופציונלית. כדי להוסיף כמה קבצים, מציינים את --custom_overlay ואת שם הקובץ, למשל: --custom_overlayoverlay_file1.yaml --custom_overlay overlay_file2.yaml --custom_overlay overlay_file3.yaml

    ./asmcli install \
--fleet_id FLEET_PROJECT_ID \
--kubeconfig KUBECONFIG_FILE \
--output_dir DIR_PATH \
--platform multicloud \
--enable_all \
--ca mesh_ca \
--custom_overlay OVERLAY_FILE
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של הצי.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, לא ניתן להשתמש במיקומי קבצים יחסיים kubeconfig שכוללים את התו '~'.
    • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל istioctl, דוגמאות ומניפסטים. אחרת ,asmcli הקבצים יורדים לספרייה tmp. אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • נותנים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca mesh_ca שימוש ברשות האישורים של Cloud Service Mesh כרשות האישורים. שימו לב שהפקודה asmcliמגדירה את רשות האישורים של Cloud Service Mesh כך שתשתמש בWorkload Identity של Fleet
    • --custom_overlay מציינים את השם של קובץ השכבה.

התקנת שערים

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

  1. יוצרים מרחב שמות לשער הכניסה (ingress gateway) אם עדיין אין כזה. שערי מעבר הם עומסי עבודה של משתמשים, ולכן מומלץ שלא לפרוס אותם במרחב השמות של מישור הבקרה. מחליפים את GATEWAY_NAMESPACE בשם של מרחב השמות.

    kubectl create namespace GATEWAY_NAMESPACE

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

    namespace/GATEWAY_NAMESPACE created

  2. מפעילים הזרקה אוטומטית בשער. השלבים הנדרשים תלויים בשאלה אם רוצים להשתמש בתוויות ברירת מחדל להוספה (למשל, istio-injection=enabled) או בתווית של עדכון במרחב השמות של השער. תג ברירת המחדל של הגרסה ותווית הגרסה משמשים את ה-webhook של רכיב להחדרת sidecar אוטומטית כדי לשייך פרוקסי מוזרקים לגרסה מסוימת של מישור הבקרה.

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

      DIR_PATH/istioctl tag list

    2. החלת תוויות ברירת המחדל להוספה על מרחב השמות.

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

    תווית הגרסה

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

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

      הפקודה מחזירה את תווית התיקון שתואמת לגרסה של Cloud Service Mesh, לדוגמה: asm-1297-18

    2. מחילים את תווית הגרסה על מרחב השמות. בפקודה הבאה, REVISION הוא הערך של התווית istiod revision שרשמתם בשלב הקודם.

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

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

      namespace/GATEWAY_NAMESPACE labeled

    אפשר להתעלם מההודעה "istio.io/rev" not found בפלט. כלומר, למרחב השמות לא הייתה בעבר התווית istio.io/rev, שאמורה להיות קיימת בהתקנות חדשות של Cloud Service Mesh או בפריסות חדשות. ההזרקה האוטומטית נכשלת אם במרחב השמות יש גם את התווית istio.io/rev וגם את התווית istio-injection, ולכן כל הפקודות kubectl label במסמכי Cloud Service Mesh מציינות במפורש את שתי התוויות.

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

  3. מורידים את קובץ התצורה לדוגמה של שער הכניסה מסוג Ingress ‏(‎ .yaml) ממאגר anthos-service-mesh-packages.

  4. משתמשים בהגדרת שער הכניסה לדוגמה בפורמט ‎ .yaml כמו שהיא, או משנים אותה לפי הצורך.

    kubectl apply -n GATEWAY_NAMESPACE \
  -f CONFIG_PATH/istio-ingressgateway

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

    deployment.apps/istio-ingressgateway created
poddisruptionbudget.policy/istio-ingressgateway created
horizontalpodautoscaler.autoscaling/istio-ingressgateway created
role.rbac.authorization.k8s.io/istio-ingressgateway created
rolebinding.rbac.authorization.k8s.io/istio-ingressgateway created
service/istio-ingressgateway created
serviceaccount/istio-ingressgateway created

מידע נוסף על שיטות מומלצות לשימוש בשערי תשלום

פריסה ופריסה מחדש של עומסי עבודה

‫Cloud Service Mesh משתמש בפרוקסי מסוג sidecar כדי לשפר את אבטחת הרשת, המהימנות והניראות (observability). ב-Cloud Service Mesh, הפונקציות האלה מופשטות מהקונטיינר הראשי של האפליקציה ומיושמות בשרת proxy נפוץ מחוץ לתהליך, שמועבר כקונטיינר נפרד באותו Pod.

ההתקנה לא תושלם עד שתפעילו הוספה אוטומטית של קובץ עזר חיצוני (הוספה אוטומטית) ותפעילו מחדש את ה-Pods לכל עומסי העבודה שהופעלו באשכול לפני שהתקנתם את Cloud Service Mesh.

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

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

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

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

      DIR_PATH/istioctl tag list

    2. מריצים את הפקודה הבאה. ‫NAMESPACE הוא שם מרחב השמות שבו רוצים להפעיל הוספה אוטומטית.

      kubectl label namespace NAMESPACE istio-injection=enabled istio.io/rev-

    תוויות ההוספה שמוגדרות כברירת מחדל מוסיפות את הגרסה שהתג שמוגדר כברירת מחדל מצביע עליה.

    תווית הגרסה

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

      kubectl -n istio-system get pods -l app=istiod --show-labels

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

      NAME                                READY   STATUS    RESTARTS   AGE   LABELS
istiod-asm-1297-18-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1297-18,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1297-18-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1297-18,istio=istiod,pod-template-hash=5788d57586

      בפלט, בעמודה LABELS, מציינים את הערך של istiodתווית הגרסה, שמופיע אחרי התחילית istio.io/rev=. בדוגמה הזו, הערך הוא asm-1297-18.

    2. מחילים את תווית הגרסה ומסירים את התווית istio-injection אם היא קיימת. בפקודה הבאה, NAMESPACE הוא שם מרחב השמות שבו רוצים להפעיל הוספה אוטומטית, ו-REVISION היא תווית הגרסה שציינתם בשלב הקודם.

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

      אפשר להתעלם מההודעה "istio-injection not found" בפלט. כלומר, למרחב השמות לא הייתה בעבר התווית istio-injection, וזה מה שצריך לקרות בהתקנות חדשות של Cloud Service Mesh או בפריסות חדשות. מכיוון שההתנהגות של הוספה אוטומטית לא מוגדרת כשבמרחב שמות יש גם את התווית istio-injection וגם את התווית של הגרסה, כל הפקודות kubectl label במסמכי Cloud Service Mesh מוודאות באופן מפורש שרק אחת מהן מוגדרת.

  2. אם עומסי עבודה פעלו באשכול לפני שהתקנתם את Cloud Service Mesh, צריך להפעיל מחדש את ה-Pods כדי להפעיל מחדש את ההזרקה.

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

    אפשר להשתמש באפשרות kubectl כדי לבצע הפעלה מחדש מתגלגלת:

    kubectl rollout restart deployment -n NAMESPACE

מה השלב הבא?