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

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

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

אם אתם צריכים להתקין Cloud Service Mesh לא מנוהל בתוך אשכול עם istiodמישור בקרה ב-GKE Google Cloud, תוכלו לעיין במאמר התקנה של Cloud Service Mesh בתוך אשכול ב- Google Cloud. הערה: לעומסי עבודה (workload) של Kubernetes ב-Google Cloud, מומלץ להקצות רמת בקרה מנוהלת

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

מגבלות

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

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

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

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

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

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

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

שם התפקיד מזהה תפקיד Grant location תיאור
אדמין GKE Hub roles/gkehub.admin פרויקט Fleet גישה מלאה ל-GKE Hubs ולמשאבים קשורים.
Kubernetes Engine Admin 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 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. אופציונלי: התקנת שער לתעבורת נתונים נכנסת (ingress). כברירת מחדל, 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. אם האשכולות שלכם נמצאים ברשתות שונות (כמו במצב איים), צריך להעביר שם רשת ייחודי ל-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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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. מזינים את הערכים במשתני המיקום שמופיעים.

  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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 GKE Fleet.
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 וזיכרון.

התקנה של תכונות ברירת המחדל ושירות רשות האישורים (CA)

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

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

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

  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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $PWD לא פועל כאן.
    • --platform multicloud מציין שהפלטפורמה היא משהו שונה מ Google Cloud, כמו פלטפורמה מקומית או פלטפורמה מרובת עננים.
    • --enable_all מאפשר לסקריפט:
      • מעניקים את הרשאות ה-IAM הנדרשות.
      • מפעילים את ממשקי Google API הנדרשים.
      • מגדירים תווית באשכול שמזהה את הרשת.
      • רושמים את האשכול ב-Fleet אם הוא עדיין לא רשום.
    • --ca gcp_cas שימוש ב-Certificate Authority Service כרשות האישורים. שינוי רשויות אישורים במהלך שדרוג גורם לזמן השבתה. asmcliמגדיר את Certificate Authority Service לשימוש בזהות של עומס עבודה ב-
    • ‫--ca_pool המזהה המלא של מאגר ה-CA ב-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 משתמשת במפתח חתימה ובאישור של רשות אישורים (CA) ביניים, שנחתמו על ידי רשות האישורים הבסיסית. אם יש כמה רשויות אישורים ברשת, נוצרת היררכיית אמון בין רשויות האישורים. אפשר לחזור על השלבים האלה כדי להקצות אישורים ומפתחות לכל מספר של רשויות אישורים.

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

  1. עוברים לספרייה istio-1.28.2-asm.4.

  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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
      • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
      • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
      • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
      • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
      • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
      • ‫--output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 GKE Fleet.
      • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של ה-Fleet.
      • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
      • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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. מזינים את הערכים במשתני המיקום שמופיעים. אתם יכולים לבחור להפעיל את 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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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. מזינים את הערכים במצייני המקום שמופיעים.

  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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 GKE Fleet.
    • ‫--fleet_id מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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. מזינים את הערכים במשתני המיקום שמופיעים.

  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 מזהה הפרויקט של פרויקט המארח של ה-Fleet.
    • ‫--kubeconfig הנתיב המלא לקובץ kubeconfig. משתנה הסביבה $PWD לא פועל כאן. בנוסף, מיקומי קבצים יחסיים kubeconfig שמשתמשים ב-`~` לא יפעלו.
    • --output_dir כוללים את האפשרות הזו כדי לציין ספרייה שבה asmcli מוריד את חבילת anthos-service-mesh ומחלץ את קובץ ההתקנה, שמכיל את istioctl, דוגמאות ומניפסטים. אחרת, הקבצים יורדים לספרייה tmp.asmcli אפשר לציין נתיב יחסי או נתיב מלא. משתנה הסביבה $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 נכנסים או יוצאים. שערי מעבר הם שרתי 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-1282-4

    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 כדי לשייך sidecars מוזרקים לתיקון 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-1282-4-5788d57586-bljj4   1/1     Running   0          23h   app=istiod,istio.io/rev=asm-1282-4,istio=istiod,pod-template-hash=5788d57586
istiod-asm-1282-4-5788d57586-vsklm   1/1     Running   1          23h   app=istiod,istio.io/rev=asm-1282-4,istio=istiod,pod-template-hash=5788d57586

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

    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

מה השלב הבא?