הגדרת שירותים מרובי אשכולות

במסמך הזה מוסבר איך להפעיל שירותים מרובי-אשכולות (MCS) ולהשתמש בהם. באמצעות MCS, אתם יכולים לגלות ולהפעיל שירותי Kubernetes בכמה אשכולות של Google Kubernetes Engine ‏ (GKE). ‫MCS עוזר לכם ליצור אפליקציות עם זמינות גבוהה ופיזור גיאוגרפי, על ידי הפיכת השירותים שלכם לגמישים וניתנים להתאמה. כשמייצאים שירות באמצעות MCS, השירות זמין בכל האשכולות בfleet.

המסמך הזה מיועד למהנדסי רשתות שמנהלים את הרשתות באשכולות ובצוותים שלהם. למידע נוסף על תפקידים נפוצים ומשימות לדוגמה שמוזכרים בתוכן של Google Cloud , קראו את המאמר תפקידים ומשימות נפוצים של משתמשי GKE.

למידע נוסף על אופן הפעולה של MCS והיתרונות שלו, קראו את המאמר שירותים מרובי-אשכולות.

Google Cloud משאבים שמנוהלים על ידי MCS

‫MCS מנהל את הרכיבים הבאים של Google Cloud:

  • ‫Cloud DNS: ‏MCS מגדיר תחומים ורשומות של Cloud DNS לכל שירות שמיוצא באשכולות של ה-fleet. כך אפשר להתחבר לשירותים שפועלים באשכולות אחרים. האזורים והרשומות האלה נוצרים, נקראים, מתעדכנים ונמחקים על סמך השירותים שאתם בוחרים לייצא בין אשכולות.

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

  • מישור הבקרה של Traffic Director: ב-MCS משתמשים במישור הבקרה של Traffic Director כדי לעקוב אחרי נקודות הקצה והתקינות שלהן באשכולות.

דרישות

אלה הדרישות של MCS:

  • כדי ש-MCS יפעל בצורה תקינה, GKE פורס את ה-Pod‏ gke-mcs-importer בצמתים עם הרשאות RBAC מוגברות. ההרשאות האלה מאפשרות למייבא לנהל נקודות קצה, שירותים ו-ServiceImports כדי להפיץ מטא-נתונים של שירותים בין אשכולות ב-fleet. לכלי הייבוא אין הרשאה להציג או לשנות את הפריסות שלכם.

  • ‫MCS תומך רק בייצוא שירותים מאשכולות GKE מקוריים של VPC ב- Google Cloud. מידע נוסף זמין במאמר יצירת אשכול המותאם ל-VPC. אי אפשר להשתמש באשכולות GKE Standard שאינם VPC-native.

  • הקישוריות בין האשכולות תלויה באשכולות שפועלים באותה רשת VPC, ברשתות VPC מקושרות או ברשתות VPC משותפות. אם האשכולות נמצאים ברשתות נפרדות ולא מחוברות, הקריאות לשירותים חיצוניים ייחסמו. מומלץ להפעיל את MCS בפרויקטים שבהם האשכולות נמצאים באותה רשת VPC. עם זאת, צי לא יכול להכיל אשכולות מיותר מרשת VPC משותפת אחת.

    כדי להגדיר MCS בצי של פרויקטים שונים עם VPC משותף, פועלים לפי ההוראות במאמר הגדרת שירותים מרובי-אשכולות עם VPC משותף.

  • למרות שצי יכול לכלול כמה פרויקטים ב- Google Cloud ורשתות VPC, צריך לייצא שירות יחיד עם כמה אשכולות מפרויקט אחד ומרשת VPC אחת.

  • אי אפשר להשתמש ב-MCS עם מדיניות רשת ב-Kubernetes.

  • בכל אשכול צריך להפעיל את התוסף HttpLoadBalancing. מוודאים שהתוסף HttpLoadBalancing מופעל. התוסף HttpLoadBalancing מופעל כברירת מחדל ואין להשבית אותו.

תמחור

התכונה "שירותים בכמה אשכולות" כלולה בעמלת הניהול של אשכולות GKE, והשימוש בה לא כרוך בעלות נוספת. צריך להפעיל את Traffic Director API, אבל MCS לא מחייב אתכם על נקודות קצה של Cloud Service Mesh.

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

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

  1. מתקינים את Google Cloud SDK.

  2. מפעילים את Google Kubernetes Engine API:

    הפעלת Google Kubernetes Engine API

  3. מחברים את רשתות ה-VPC באמצעות קישור בין רשתות VPC שכנות (peering), Cloud Interconnect או Cloud VPN.

  4. מפעילים את ממשקי ה-API של MCS,‏ fleet (hub),‏ Resource Manager,‏ Traffic Director,‏ Cloud DNS ו-connect gateway:

    gcloud services enable \
    multiclusterservicediscovery.googleapis.com \
    gkehub.googleapis.com \
    cloudresourcemanager.googleapis.com \
    trafficdirector.googleapis.com \
    dns.googleapis.com \
    connectgateway.googleapis.com \
    --project=PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט שבו רוצים לרשום את האשכולות ל-fleet.

הפעלת MCS בפרויקט

כדי להשתמש ב-MCS, צריך לרשום את אשכולות GKE המשתתפים באותו צי. אחרי שמפעילים את התכונה MCS ב-fleet, אפשר לייצא שירותים בין אשכולות ב-fleet.

הפעלת MCS באשכול GKE

  1. מפעילים את התכונה MCS בצי של הפרויקט:

    gcloud container fleet multi-cluster-services enable \
    --project PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט שבו רוצים לרשום את האשכולות ל-fleet. זהו הפרויקט המארח של ה-Fleet.

    כשמפעילים את Multi-cluster Services בפרויקט המארח של ה-fleet, חשבון השירות service-PROJECT_NUMBER@gcp-sa-mcsd.iam.gserviceaccount.com נוצר או שמוודאים שהוא קיים.

  2. רושמים את אשכולות GKE ב-fleet. מומלץ מאוד לרשום את האשכול כשאיחוד זהויות של עומסי עבודה ל-GKE מופעל. אם לא תפעילו את איחוד הזהויות של עומסי עבודה ל-GKE, תצטרכו לרשום את האשכול באמצעות Google Cloud חשבון שירות לאימות, ולהשלים את השלבים הנוספים שמפורטים במאמר אימות של חשבונות שירות.

    כדי לרשום את האשכול ב-"איחוד זהויות של עומסי עבודה ל-GKE", מריצים את הפקודה הבאה:

    gcloud container fleet memberships register MEMBERSHIP_NAME \
   --gke-cluster CLUSTER_LOCATION/CLUSTER_NAME \
   --enable-workload-identity \
   --project PROJECT_ID

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫MEMBERSHIP_NAME: שם החברות שבחרתם כדי לייצג באופן ייחודי את האשכול ב-fleet. בדרך כלל, שם החברות ב-fleet של האשכול הוא שם האשכול, אבל יכול להיות שתצטרכו לציין שם חדש אם כבר קיים ב-fleet אשכול אחר עם השם המקורי.
    • ‫CLUSTER_LOCATION: האזור שבו נמצא האשכול.
    • ‫CLUSTER_NAME: שם האשכול.

  3. מקצים את ההרשאות הנדרשות לניהול זהויות והרשאות גישה (IAM) לכלי הייבוא של MCS:

    gcloud projects add-iam-policy-binding PROJECT_ID \
    --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/gke-mcs/sa/gke-mcs-importer" \
    --role "roles/compute.networkViewer"

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫PROJECT_ID: מזהה הפרויקט מהפרויקט המארח של ה-Fleet.
    • ‫PROJECT_NUMBER: מספר הפרויקט מהפרויקט המארח של ה-Fleet.

  4. מוודאים שלכל אשכול ב-fleet יש מרחב שמות לשיתוף שירותים. אם צריך, יוצרים מרחב שמות באמצעות הפקודה הבאה:

    kubectl create ns NAMESPACE

    מחליפים את NAMESPACE בשם של מרחב השמות.

  5. כדי לוודא ש-MCS מופעל, מריצים את הפקודה הבאה:

    gcloud container fleet multi-cluster-services describe \
    --project PROJECT_ID

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

    createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
  projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
    state:
      code: OK
      description: Firewall successfully updated
      updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
  state: ACTIVE
spec: {}

    אם הערך של state הוא לא ACTIVE, עיינו בקטע פתרון בעיות.

אימות של חשבונות שירות

אם רשמתם את אשכולות GKE ל-fleet באמצעות חשבון שירות, תצטרכו לבצע שלבים נוספים כדי לאמת את חשבון השירות. ‫MCS פורס רכיב שנקרא gke-mcs-importer. הרכיב הזה מקבל עדכונים על נקודות קצה ממישור הבקרה של Traffic Director, ולכן כדי להפעיל את MCS צריך לתת לחשבון השירות הרשאה לקרוא מידע מ-Cloud Service Mesh.

כשמשתמשים בחשבון שירות, אפשר להשתמש בחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine או בחשבון שירות משלכם לצומת:

שימוש ב-MCS

בקטעים הבאים מוסבר איך להשתמש ב-MCS. ה-MCS משתמש ב-API של שירותים מרובי אשכולות ב-Kubernetes.

רישום שירות לייצוא

כדי לרשום שירות לייצוא לאשכולות אחרים ב-fleet, מבצעים את השלבים הבאים:

  1. יוצרים אובייקט ServiceExport בשם export.yaml:

    # export.yaml
kind: ServiceExport
apiVersion: net.gke.io/v1
metadata:
 namespace: NAMESPACE
 name: SERVICE_EXPORT_NAME

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫NAMESPACE: מרחב השמות של האובייקט ServiceExport. מרחב השמות הזה חייב להיות זהה למרחב השמות של השירות שאתם מייצאים.
    • ‫SERVICE_EXPORT_NAME: השם של שירות באשכול שרוצים לייצא לאשכולות אחרים ב-fleet.

  2. יוצרים את המשאב ServiceExport באמצעות הפקודה הבאה:

    kubectl apply -f export.yaml

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

אפשר לייצא את אותו שירות מכמה אשכולות כדי ליצור נקודת קצה אחת של שירות בכמה אשכולות עם זמינות גבוהה, עם חלוקת תנועה בין האשכולות. לפני שאתם מייצאים שירותים עם אותו שם ומרחב שמות, ודאו שאתם רוצים שהם יקובצו בצורה הזו. אנחנו ממליצים לא לייצא שירותים במרחבי השמות default ו-kube-system, כי יש סבירות גבוהה להתנגשויות שמות לא מכוונות ולקיבוץ לא מכוון כתוצאה מכך. אם אתם מייצאים יותר מחמישה שירותים עם אותו שם ומרחב שמות, יכול להיות שחלוקת התנועה בשירותים המיובאים תוגבל לחמישה שירותים מיוצאים.

שימוש בשירותים באשכולות שונים

‫MCS תומך רק ב-ClusterSetIP ובשירותים ללא ראש. רק רשומות DNS מסוג A זמינות.

אחרי שיוצרים אובייקט ServiceExport, תרגום השם של שם הדומיין הבא פותר את השירות שיוצא מכל Pod בכל אשכול ב-Fleet:

 SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

הפלט כולל את הערכים הבאים:

  • ‫SERVICE_EXPORT_NAME ו-NAMESPACE: הערכים שאתם מגדירים באובייקט ServiceExport.

בשירותי ClusterSetIP, הדומיין מפנה אל ClusterSetIP. כדי למצוא את הערך הזה, מאתרים את האובייקט ServiceImport באשכול במרחב השמות שבו נוצר האובייקט ServiceExport. האובייקט ServiceImport נוצר באופן אוטומטי.

לדוגמה:

kind: ServiceImport
apiVersion: net.gke.io/v1
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET
status:
 ports:
 - name: https
   port: 443
   protocol: TCP
   targetPort: 443
 ips: CLUSTER_SET_IP

‫MCS יוצר אובייקט EndpointSlice כחלק מייבוא של שירות לאשכול. באמצעות בדיקה של האובייקט הזה, אתם יכולים לעקוב אחרי ההתקדמות של ייבוא השירות.

כדי למצוא את השם של האובייקט EndpointSlice, חפשו את הערך של ההערה net.gke.io/derived-service באובייקט ServiceImport שתואם לשירות המיובא. לדוגמה:

kind: ServiceImport
apiVersion: net.gke.io/v1
annotations: net.gke.io/derived-service: DERIVED_SERVICE_NAME
metadata:
 namespace: EXPORTED-SERVICE-NAMESPACE
 name: SERVICE-EXPORT-TARGET

לאחר מכן, מחפשים את האובייקט EndpointSlice כדי לבדוק אם MCS כבר הפיץ את נקודות הקצה לאשכול המייבא. האובייקט EndpointSlice נוצר באותו מרחב שמות כמו האובייקט ServiceImport, בשם שמאוחסן בהערה net.gke.io/derived-service. לדוגמה:

kubectl get endpointslice -l kubernetes.io/service-name=DERIVED_SERVICE_NAME -n NAMESPACE

מחליפים את מה שכתוב בשדות הבאים:

  • ‫DERIVED_SERVICE_NAME: הערך של ההערה net.gke.io/derived-service באובייקט ServiceImport.
  • ‫NAMESPACE: מרחב השמות של האובייקט ServiceExport.

אפשר לקבל מידע נוסף על סטטוס התקינות של נקודות הקצה באמצעות לוח הבקרה של Cloud Service Mesh במסוף Google Cloud .

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

 HOSTNAME.MEMBERSHIP_NAME.LOCATION.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

הפלט כולל את הערכים הבאים:

  • ‫SERVICE_EXPORT_NAME ו-NAMESPACE: הערכים שאתם מגדירים באובייקט ServiceExport.
  • ‫MEMBERSHIP_NAME: המזהה הייחודי ב-fleet של האשכול שבו נמצא ה-Pod.
  • ‫LOCATION: המיקום של המינוי. המינויים הם global, או שהמיקום שלהם הוא אחד מהאזורים או מהתחומים שבהם נמצא ה-Pod, כמו us-central1.
  • ‫HOSTNAME: שם המארח של ה-Pod.

אפשר גם לפנות ל-Pod בקצה העורפי באמצעות שם מארח שיוצא מאשכול שרשום ב-Membership גלובלי, באמצעות שם דומיין בפורמט הבא:

HOSTNAME.MEMBERSHIP_NAME.SERVICE_EXPORT_NAME.NAMESPACE.svc.clusterset.local

השבתת MCS

כדי להשבית את MCS:

  1. בכל אשכול ב-fleet, מוחקים את כל אובייקטי ה-ServiceExport שיצרתם:

    kubectl delete serviceexport SERVICE_EXPORT_NAME \
    -n NAMESPACE

    מחליפים את מה שכתוב בשדות הבאים:

    • ‫SERVICE_EXPORT_NAME: השם של אובייקט ServiceExport.
    • ‫NAMESPACE: מרחב השמות של האובייקט ServiceExport.

    יכול להיות שיעבור עד שעה עד שכל הנתונים של ServiceExports יימחקו לגמרי.

  2. ביטול הרישום של האשכולות מה-fleet אם לא צריך לרשום אותם למטרה אחרת.

  3. השבתת התכונה multiclusterservicediscovery:

    gcloud container fleet multi-cluster-services disable \
    --project PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט שבו רשמתם את האשכולות.

    אימות ביצוע של מחיקה בהצלחה

    כשמשביתים את התכונה, מופיעה הודעה שהמחיקה בוצעה.

    אם מופיעה ההודעה הבאה, התכונה מושבתת:

    Waiting for Feature Multi-cluster Services to be deleted...done.

    פתרון בעיות שקשורות לשגיאות במחיקה

    אם לא תמחקו את כל המשאבים של ServiceExport לפני שתשביתו את MCS, או אם המחיקה של ServiceExports או של המשאבים המנוהלים לא תסתיים, יכול להיות שתופיע הודעת שגיאה.

    ההודעה הבאה מציינת שעדיין קיימים משאבים משויכים:

    Feature has associated resources that should be cleaned up before
deletion. Check the Feature state details for more information. This check
can be overridden by setting force=true.

    כדי לפתור את השגיאה, בודקים את מצב התכונה ב-Fleet כולו:

    gcloud container fleet multi-cluster-services describe \
    --project PROJECT_ID

    בפלט, בודקים את השדה description. יש שני מקרים אפשריים:

    1. ‫ServiceExports לא יוסרו.

      בהודעה מצוין שיש ServiceExport משאבים ב-fleet:

      There are N ServiceExport in the Fleet.

      חשוב לוודא שמוחקים את כל המשאבים של ServiceExport. כל עוד לא כל ה-ServiceExports נמחקו לגמרי, ההשבתה של MCS תמשיך להיכשל.

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

      gcloud container fleet multi-cluster-services disable \
--project PROJECT_ID

    2. המשאבים המנוהלים לא יוסרו.

      בהודעה מצוין שהמשאבים מוסרים:

      There are no ServiceExports in the Fleet. Managed resources are in the
process of being removed. See
https://docs.cloud.google.com/kubernetes-engine/docs/how-to/multi-cluster-services#troubleshoot
for more information.

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

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

      gcloud container fleet multi-cluster-services disable \
--project PROJECT_ID

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

    אפשר להשבית את התכונה multiclusterservicediscovery.

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

    gcloud container fleet multi-cluster-services disable --force \
    --project PROJECT_ID

  4. משביתים את ה-API של MCS:

    gcloud services disable multiclusterservicediscovery.googleapis.com \
    --project PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט שבו רשמתם את האשכולות.

מגבלות

מספר האשכולות, ה-Pods ויציאות השירות

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

ב-Kubernetes, שירות מזוהה באופן ייחודי לפי השם שלו ומרחב השמות שאליו הוא שייך. השם הזה והצמד של מרחב השמות נקראים שם עם מרחב שמות.

  • ייצוא אשכולות: אפשר לייצא בבטחה שירות יחיד, שמזוהה לפי שם מרחב שמות, מעד 5 אשכולות בו-זמנית. מעבר למגבלה הזו, יכול להיות שרק קבוצת משנה של נקודות קצה (endpoints) תוכל לייבא לאשכולות הצורכים. אפשר לייצא שירותים שונים מקבוצות משנה שונות של אשכולות.

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

  • מספר השירותים מרובי האשכולות שמיוצאים בו-זמנית: מומלץ לא לייצא בו-זמנית יותר מ-250 יציאות שירות ייחודיות.

    יציאת שירות ייחודית מזוהה באמצעות שם ממרחב שמות ומספר יציאה, כלומר קבוצת ערכים (שם, מרחב שמות, מספר יציאה). כלומר:

    • שירותים עם אותו שם ופורט במרחב השמות, שיוצאו מכמה אשכולות, נחשבים כפורט שירות ייחודי אחד.

    • שני שירותים עם אותו שם ואותה יציאה, אבל עם מרחבי שמות שונים, למשל (name, ns1, port-80) ו-(name, ns2, port-80), הם שתי יציאות שירות שונות, והם נספרים כשתיים מתוך המגבלה של 250 יציאות שירות ייחודיות.

    • שירות מיוצא שחושף שתי יציאות, 80 ו-443, נספר כשתיים מתוך המגבלה של 250 יציאות ייחודיות לשירות, בלי קשר למספר האשכולות ב-fleet שמייצאים את השירות הזה בו-זמנית.

    כל שירות בכמה אשכולות נכלל במכסת השירותים לקצה העורפי, ובכל אזור של כל אשכול ייצוא נוצרת קבוצת נקודות קצה (NEG) ברשת. הגדלת המכסות האלה לא משנה את המגבלה שצוינה למספר הכולל של יציאות שירות ייחודיות.

סוגי השירותים

‫MCS תומך רק ב-ClusterSetIP ובשירותים ללא ראש (Headless). אין תמיכה בשירותי NodePort ו-LoadBalancer, והם עלולים לגרום להתנהגות בלתי צפויה.

שימוש בסוכן IPmasq עם MCS

‫MCS פועל כצפוי כשמשתמשים בטווח ברירת המחדל של כתובות IP של Pod או בטווח אחר שלא מוסווה.

אם אתם משתמשים בטווח כתובות IP מותאם אישית של Pod או ב-ConfigMap מותאם אישית של סוכן IPmasq, יכול להיות שתעבורת הנתונים של MCS תוסווה. הפעולה הזו מונעת מ-MCS לפעול כי כללי חומת האש מאפשרים רק תנועה מכתובות IP של Pod.

כדי למנוע את הבעיה, צריך להשתמש בטווח ברירת המחדל של כתובות ה-IP של Pod, או לציין את כל טווחי כתובות ה-IP של Pod בשדה nonMasqueradeCIDRs של ConfigMap של סוכן IPmasq. אם אתם משתמשים ב-Autopilot או שאתם חייבים להשתמש בטווח כתובות IP של Pod שאינו ברירת המחדל, ואי אפשר לציין את כל טווחי כתובות ה-IP של Pod ב-ConfigMap, אתם צריכים להשתמש ב-Egress NAT Policy כדי להגדיר הסתרת IP.

שימוש חוזר במספרי יציאות בשירות MCS

אי אפשר להשתמש באותו מספר יציאה בשירות MCS אחד, גם אם הפרוטוקולים שונים.

ההגדרה הזו חלה גם בתוך שירות Kubernetes אחד וגם בכל שירותי Kubernetes של שירות MCS אחד.

‫MCS עם אשכולות בכמה פרויקטים

אי אפשר לייצא שירות אם הוא כבר מיוצא על ידי אשכולות אחרים בפרויקט אחר ב-fleet, עם אותו שם ומרחב שמות. אתם יכולים לגשת לשירות באשכולות אחרים ב-fleet בפרויקטים אחרים, אבל האשכולות האלה לא יכולים לייצא את אותו שירות באותו מרחב שמות.

פתרון בעיות

בקטעים הבאים מפורטים טיפים לפתרון בעיות ב-MCS.

צפייה בסטטוס התכונה "שירותי תוכן מנוהלים" (MCS)

כדי לוודא שהגדרתם את MCS כמו שצריך, אתם יכולים לבדוק את הסטטוס של המשאב Feature. כדי לראות את הסטטוס, משתמשים בפקודה הבאה:

gcloud container fleet multi-cluster-services describe

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

createTime: '2021-08-10T13:05:23.512044937Z'
membershipStates:
 projects/PROJECT_ID/locations/global/memberships/MCS_NAME:
   state:
     code: OK
     description: Firewall successfully updated
     updateTime: '2021-08-10T13:14:45.173444870Z'
name: projects/PROJECT_NAME/locations/global/features/multiclusterservicediscovery
resourceState:
 state: ACTIVE
spec: {}

הוא כולל, בין היתר, את מצב התכונה הכולל ב-Fleet, בקטע resourceState, ואת הסטטוס של כל מינוי בנפרד, בקטע membershipStates.

אם הפעלתם את התכונה MCS לפי ההוראות במאמר הפעלת MCS באשכול GKE, אבל הערך של resourceState.state הוא לא ACTIVE, פנו לתמיכה.

הסטטוס של כל חברות מורכב מהנתיב שלה ומהשדה state. האפשרות השנייה מכילה את code ו-description, שמועילים לפתרון בעיות.

קודים במצבי החברות

קוד, שמיוצג על ידי השדה state.code, מציין את המצב הכללי של החבר ביחס ל-MCS. יש ארבעה ערכים אפשריים:

  • ‫OK: החברות נוספה בהצלחה ל-MCS ומוכנה לשימוש.

  • ‫WARNING: שירות MCS נמצא בתהליך של התאמת הגדרת החברות. בשדה התיאור יכול להיות מידע נוסף על הסיבה לקוד הזה.

  • ‫FAILED: המינוי הזה לא נוסף ל-MCS. המינוי FAILED לא משפיע על מינויים אחרים ב-fleet עם קוד OK. בשדה התיאור יכול להיות מידע נוסף על הסיבה לקוד הזה.

  • ‫ERROR: חסרים משאבים במינוי הזה. המינוי ERROR לא משפיע על מינויים אחרים ב-fleet עם קוד OK. בשדה התיאור יכול להיות מידע נוסף על הסיבה לקוד הזה.

תיאורים של מצבי החברות

כדי לראות מידע על מצב החברות ב-MCS, בודקים את השדה state.description. בשדה הזה מופיע מידע על הגדרת הפרויקט וה-Hub, ועל סטטוס התקינות של ה-Fleet והמינויים. כדי לראות מידע על שירותים ספציפיים וההגדרות שלהם, עיינו בשדה Status.Conditions באובייקט ServiceExport, בקטע בדיקת ServiceExport.

השדה state.description מכיל את המידע הבא:

  • ‫Firewall successfully created: ההודעה הזו מציינת שכלל חומת האש של החבר נוצר או עודכן בהצלחה. קוד המינוי הוא OK.

  • ‫Firewall creation pending: ההודעה הזו מציינת שכלל חומת האש של החבר ממתין ליצירה או לעדכון. קוד המינוי הוא WARNING. יכול להיות שיהיו בעיות בעדכון המינוי הזה ובחיבור שלו לשירותים חדשים עם כמה אשכולות ולמינויים שנוספו בזמן שכלל חומת האש בהמתנה.

  • ‫GKE Cluster missing: ההודעה הזו מציינת שאשכול GKE הרשום לא זמין או נמחק. קוד המינוי הוא ERROR. אחרי שמוחקים אשכול GKE, צריך לבטל את הרישום של המינוי ל-fleet באופן ידני.

  • ‫Project that member lives in is missing required permissions and/or has not enabled all required APIs - additional setup steps are required: ההודעה הזו מציינת שיש שגיאות StatusForbidden‏ (403) פנימיות, וקוד החברות הוא FAILED. השגיאה הזו מתרחשת בתרחישים הבאים:

    • לא הפעלתם את ממשקי ה-API הנדרשים בפרויקט של החבר.

      אם אשכול החברים נמצא בפרויקט נפרד מה-fleet, עיינו בקטע הגדרה בפרויקטים שונים כדי לוודא שביצעתם את כל השלבים הנדרשים. אם השלמתם את כל השלבים, ודאו שממשקי ה-API הבאים מופעלים בפרויקט הרישום באמצעות הפקודות הבאות:

      gcloud services enable multiclusterservicediscovery.googleapis.com --project PROJECT_ID
gcloud services enable dns.googleapis.com --project PROJECT_ID
gcloud services enable trafficdirector.googleapis.com --project PROJECT_ID
gcloud services enable cloudresourcemanager.googleapis.com --project PROJECT_ID

      מחליפים את PROJECT_ID במזהה הפרויקט שבו רשמתם את האשכולות.

    • לחשבון השירות mcsd או gkehub נדרשות הרשאות נוספות בפרויקט של החבר.

      חשבונות השירות mcsd ו-gkehub אמורים להיווצר באופן אוטומטי בפרויקט המארח של ה-fleet עם כל ההרשאות הנדרשות. כדי לוודא שחשבונות השירות קיימים, מריצים את הפקודות הבאות:

      gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-mcsd
gcloud projects get-iam-policy PROJECT_ID | grep gcp-sa-gkehub

      מחליפים את PROJECT_ID במזהה הפרויקט של הפרויקט המארח של ה-fleet.

    הפקודות האלה אמורות להציג את השם המלא של חשבונות השירות mcsd ו-gkehub.

  • ‫Multiple VPCs detected in the hub - VPC must be peered with other VPCs for successful connectivity: ההודעה הזו מופיעה כשאשכולות שמתארחים ברשתות VPC שונות רשומים לאותו Fleet. סטטוס החברות הוא OK. רשת ה-VPC של האשכול מוגדרת על ידי הרשת של NetworkConfig. כדי להשתמש ב-Multi-cluster Services צריך רשת שטוחה, ורשתות ה-VPC האלה צריכות להיות מקושרות באופן פעיל כדי ש-Multi-cluster Services יתחברו זו לזו כמו שצריך. מידע נוסף זמין במאמר התאמת שתי רשתות.

  • ‫Member does not exist in the same project as hub - additional setup steps are required, errors may occur if not completed.: ההודעה הזו מזכירה לכם שאשכולות בכמה פרויקטים דורשים שלבי הגדרה נוספים. סטטוס החברות הוא OK. חברויות בפרויקטים שונים מוגדרות כאשכול חברים שלא נמצא באותו פרויקט כמו ה-fleet. מידע נוסף זמין במאמר הגדרה בפרויקטים שונים.

  • ‫Non-GKE clusters are currently not supported: ההודעה הזו מזכירה לכם ש-MCS תומך רק באשכולות GKE. אי אפשר להוסיף אשכולות שהם לא GKE ל-MCS. סטטוס החברות הוא FAILED.

בדיקת ServiceExport

כדי לראות את הסטטוס של שירות מסוים ואת השגיאות האפשריות, בודקים את השדה Status.Conditions במשאב ServiceExport של אותו שירות:

kubectl describe serviceexports PROJECT_ID -n NAMESPACE

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

Name:         SERVICE_NAME
Namespace:    NAMESPACE
Labels:       <none>
Annotations:  <none>
API Version:  net.gke.io/v1
Kind:         ServiceExport
Metadata:
  Creation Timestamp:  2024-09-06T15:57:40Z
  Finalizers:
    serviceexport.net.gke.io
  Generation:        2
  Resource Version:  856599
  UID:               8ac44d88-4c08-4b3d-8524-976efc455e4e
Status:
  Conditions:
    Last Transition Time:  2024-09-06T16:01:53Z
    Status:                True
    Type:                  Initialized
    Last Transition Time:  2024-09-06T16:02:48Z
    Status:                True
    Type:                  Exported
Events:                    <none>

כשהבקר של MCS מזהה משאב ServiceExport, הוא מוסיף את התנאים הבאים לשדה Status.Conditions:

  • ‫Initialized: הערך True אם בקר ה-MCS אסף את השירות שמיוצג על ידי ServiceExport וניסה להתאים אותו.

  • ‫Exported: הערך True אם השירות שמיוצג על ידי ServiceExport אומת בהצלחה.

כל תנאי מכיל את שדות החובה Type,‏ Status ו-LastTransitionTime. כשהבקר של MCS מתאים ומאמת את השירות, השדה Status של התנאי המתאים משתנה מ-False ל-True.

שגיאות

אם מתרחשת שגיאה באימות, הבקר מגדיר את השדה Status של התנאי Exported לערך False ומוסיף את השדות Reason ו-Message עם מידע נוסף על השגיאה. השדה Reason יכול להכיל אחד מהערכים הבאים:

  • ‫NoMatchingService: לא נמצא באשכול שירות שתואם לשם ולמרחב השמות של ServiceExport.
    בודקים אם שירות Kubernetes שרוצים לייצא נמצא באותו אשכול. בודקים אם השם ומרחב השמות בשני המשאבים (Service ו-ServiceExport) זהים.

  • ‫Conflict: כבר קיים שירות מיוצא עם אותו שם ומרחב שמות שלא תואם לשירות שמיוצא על ידי ServiceExport, או שהוא מיוצא מרשת או מפרויקט אחרים, וזה אסור. מידע נוסף זמין בקטע מגבלות.
    בודקים את השדה Message כדי לראות את הפרטים, ואם צריך, מעיינים בקטע מגבלות. מוודאים שהשם ומרחב השמות של Service ו-ServiceExport תואמים זה לזה, וכל המשאבים נוצרים באותה רשת או באותו פרויקט.

  • ‫ReadinessProbeError: הוגדר readinessProbe בקונטיינר ב-Pod שמגבה את השירות. Kubernetes ReadinessProbes מתורגמים ל-Google cloud HealthChecks, והם כפופים לאותן הגבלות.

    הערה: MCS משתמש ביציאה שמוגדרת בהגדרה readinessProbe של קונטיינר כיציאה המוסמכת לבדיקות תקינות שמופצות למישור הבקרה של Traffic Director. ‫MCS בוחר את הקונטיינר הראשון ב-Pod המצטבר הישן ביותר שחושף את targetPort של השירות, גם אם readinessProbe של הקונטיינר הזה מוצג ביציאה אחרת. אם יציאת השירות targetPort שונה מיציאת readinessProbe, צריך לוודא שיציאת readinessProbe נגישה ומוגדרת בצורה נכונה, כי היציאה הזו קובעת את סטטוס התקינות של השירות ב-Cloud Service Mesh.

    כך השדות של בדיקת המוכנות תואמים לפרמטרים של בדיקת התקינות:

    • ‫PeriodSeconds תואם ל-CheckInterval
    • ‫TimeoutSeconds תואם ל-Timeout
    • ‫SuccessThreshold תואם ל-HealthyThreshold
    • ‫FailureThreshold תואם ל-UnhealthyThreshold

    כדי להתאים את ReadinessProbes למגבלות של HealthCheck, ב-MCS מיושמים הדברים הבאים:

    • הערכים של PeriodSeconds ו-TimeoutSeconds מוגבלים ל-300 שניות. ערכים שחורגים מהמגבלה הזו גורמים לשגיאה.
    • הערכים של SuccessThreshold ו-FailureThreshold מוגבלים ל-10 שניות. ערכים שחורגים מהמגבלה הזו גורמים לשגיאה.
    • אם הערך של TimeoutSeconds גדול מהערך של PeriodSeconds, תדווח שגיאה ויצירת המשאבים (אולי כל המשאבים) תיכשל.

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

  • ‫ServiceError: אירעה שגיאה במהלך אחזור השירות התואם.
    בדרך כלל השגיאה הזאת קשורה לבעיה בתשתית של Google Cloud. אם הבעיה נמשכת, אפשר לפנות לתמיכה של Google Cloud.

  • ‫PodsError: אירעה שגיאה במהלך אחזור ה-Pod או ה-Pods לקצה העורפי
    בדרך כלל השגיאה הזאת קשורה לבעיה בתשתית ענן של Google Cloud. אם הבעיה נמשכת, צריך לפנות לתמיכה של Google Cloud.

  • ‫EndpointsError: אירעה שגיאה במהלך צבירת נקודות קצה (endpoints) לשירות ללא ממשק משתמש (headless)
    . בדרך כלל השגיאה הזו קשורה לבעיה בתשתית הענן של Google Cloud. אם הבעיה נמשכת, צריך לפנות לתמיכה של Google Cloud.

השדה Message מספק הקשר נוסף לגבי השגיאה.

בעיות נפוצות שקשורות להרשאות

  • ממשקי ה-API הנדרשים לא מופעלים בפרויקט.

    חשוב לוודא שהפעלתם את ממשקי ה-API הנדרשים, כמו שמוסבר בקטע לפני שמתחילים.

    ב-fleet עם כמה פרויקטים, פועלים לפי ההוראות בקטע הפעלת ממשקי ה-API הנדרשים במאמר הגדרת שירותים בכמה אשכולות עם VPC משותף.

  • לחשבון השירות mcsd או gkehub אין מספיק הרשאות

    בהגדרה של פרויקט יחיד, כל ההרשאות הנדרשות ניתנות באופן אוטומטי לחשבונות שירות שנוצרים באופן אוטומטי על ידי GKE Hub ו-MCS.

    ב-fleet שכולל כמה פרויקטים, צריך ליצור קישורי IAM נוספים. פועלים לפי ההוראות בקטע יצירת קישורי IAM במאמר הגדרת שירותים מרובי אשכולות באמצעות VPC משותף.

בעיות מוכרות

שימוש חוזר במספר יציאה בשירות MCS אחד

אי אפשר להשתמש שוב באותו מספר יציאה בתוך שירות MCS, גם אם הפרוטוקולים שונים.

ההגדרה הזו חלה גם בתוך שירות Kubernetes אחד וגם בכל שירותי Kubernetes של שירות MCS אחד.

בדיקת התקינות משתמשת ביציאת ברירת המחדל במקום ב-containerPort

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

כדי למנוע את הבעיה, השתמשו בערכים מספריים בשדה Service ports.targetPort ובשדה Deployment readinessProbe.httpGet.port במקום בערכים עם שמות.

הערה: נכון לעכשיו, MCS מפיק את יציאת בדיקת התקינות של שירותים מיוצאים רק מ-readinessProbe של ה-Pod.

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

יש שגיאה פוטנציאלית ידועה בהגדרת readinessProbe, שמתוארת בקטע בדיקת ServiceExports. בהטמעה הנוכחית של MCS, אם השגיאה הזו מתרחשת בשירות אחד שמיוצא, היא יכולה למנוע את הסנכרון של חלק מהשירותים האחרים ב-fleet או של כולם.

חשוב לשמור על תקינות ההגדרות של כל שירות. אם שירות MCS לא מתעדכן, ודאו שאף אחד מה-ServiceExports באף אחד מהאשכולות באף אחד ממרחבי השמות לא מדווח על ReadinessProbeError כסיבה לכך ש-Status Condition Exported הוא False. במאמר בדיקת ServiceExports מוסבר איך בודקים את התנאים.

המאמרים הבאים