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

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

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

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

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

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

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

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

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

דרישות

יש לעמוד בדרישות הבאות כדי להשתמש ב-MCS:

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

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

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

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

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

  • אין תמיכה ב-MCS במדיניות רשת.

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

תמחור

השירות Multi-cluster Services נכלל כחלק מעמלת ניהול אשכולות 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 בצי, כל האשכולות יכולים לייצא שירותים בין אשכולות בצי.

הפעלת 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 Importer:

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

    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.

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

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

  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

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

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

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

‫MCS תומך רק ב-ClusterSetIP ובשירותים ללא כתובת IP. רק רשומות 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. לכל אשכול בצי, מוחקים כל אובייקט 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. השבתת MCS תמשיך להיכשל עד שכל ServiceExports יימחקו לחלוטין.

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

      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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

בקטעים הבאים מפורטים טיפים לפתרון בעיות ב-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: חסרים משאבים במינוי הזה. מינויים אחרים בצי עם קוד OK לא מושפעים מהמינוי ERROR. בשדה התיאור אפשר לספק מידע נוסף על הגורם לקוד הזה.

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

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

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

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

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

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

  • ‫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 הנדרשים בפרויקט של החבר.

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

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

  • ‫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 corresponds to Timeout
    • ‫SuccessThreshold corresponds to HealthyThreshold
    • ‫FailureThreshold תואם ל-UnhealthyThreshold

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בעיות מוכרות

שירותי MCS עם כמה יציאות

יש בעיה מוכרת בשירותים מרובי-אשכולות עם כמה יציאות (TCP/UDP) ב-GKE Dataplane V2, שבה חלק מנקודות הקצה לא מתוכנתות במישור הנתונים. הבעיה הזו משפיעה על גרסאות GKE שקודמות ל-‎1.26.3-gke.400.

כפתרון עקיף, כשמשתמשים ב-GKE Dataplane V2, כדאי להשתמש בכמה MCS עם יציאה אחת במקום ב-MCS אחד עם כמה יציאות.

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

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

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

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

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

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

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

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

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

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

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