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

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

התכונה MCS ב-Google Kubernetes Engine ‏ (GKE) מרחיבה את טווח ההגעה של השירות ב-Kubernetes מעבר לגבולות האשכול, ומאפשרת לכם לגלות ולהפעיל שירותים בכמה אשכולות GKE. אפשר לייצא קבוצת משנה של שירותים קיימים או שירותים חדשים.

כשמייצאים שירות באמצעות MCS, השירות הזה זמין בכל האשכולות בצי.

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

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

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

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

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

  • ‫Cloud Service Mesh: מערכת MCS משתמשת ב-Cloud Service Mesh כמישור בקרה כדי לעקוב אחרי נקודות קצה והתקינות שלהן בכל האשכולות.

דרישות

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

  • ‫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),‏ מנהל המשאבים,‏ Cloud Service Mesh,‏ 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. זה פרויקט המארח של הצי.

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

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

    כדי לרשום את האשכול ב-Workload Identity Federation for 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. הרכיב הזה מקבל עדכונים של נקודות קצה מ-Cloud Service Mesh, ולכן כחלק מהפעלת MCS צריך לתת לחשבון השירות הרשאה לקרוא מידע מ-Cloud Service Mesh.

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

שימוש ב-MCS

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

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

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

  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

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

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

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

‫MCS תומך רק ב-ClusterSetIP ובשירותים ללא כתובת IP. אפשר להשתמש רק ברשומות DNS מסוג A.

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

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

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

kubectl get endpoints 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, או שהמיקום שלהם הוא אחד מהאזורים או התחומים שבהם נמצא הפוד, כמו us-central1.
  • ‫HOSTNAME: שם המארח של ה-Pod.

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

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.

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

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

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

    1. המשתמשים ServiceExports לא יוסרו.

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

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

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

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

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

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

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

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

סוגי השירות

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

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

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

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

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

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

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

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

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

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

פתרון בעיות

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

צפייה בסטטוס התכונות של MCS

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

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: {}

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

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

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

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

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

  • ‫OK: המינוי נוסף בהצלחה ל-MCS ומוכן לשימוש.

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

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

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

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

  • ‫Non-GKE clusters are currently not supported: בהודעה הזו מוזכר ש-MCS תומך רק באשכולות GKE. אי אפשר להוסיף ל-MCS אשכולות שאינם GKE. סטטוס המינוי הוא 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 וחייבים לעמוד באותן הגבלות.

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

    • ‫PeriodSeconds corresponds to CheckInterval
    • ‫TimeoutSeconds corresponds to Timeout
    • ‫SuccessThreshold corresponds to HealthyThreshold
    • ‫FailureThreshold corresponds to UnhealthyThreshold

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

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

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

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

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

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

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

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

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

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

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

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

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

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

בעיות מוכרות

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

קיימת בעיה ידועה בשירותים מרובי-אשכולות עם כמה יציאות (TCP/UDP) ב-GKE Dataplane V2, שבה חלק מנקודות הקצה לא מתוכנתות ב-dataplane. הבעיה הזו משפיעה על גרסאות 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 במקום בערכים עם שמות.

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

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

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

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