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

‫FleetPackage, ה-API ההצהרתי בסנכרון הגדרות, מאפשר לפרוס חבילות של Fleet ולנהל אותן באשכולות שרשומים ל-Fleet. חבילה היא קבוצה של מניפסטים של Kubernetes YAML שמגדירים את הגדרות האשכול. באמצעות חבילות לצי המכשירים, אתם יכולים לפרוס עדכוני הגדרות בצי המכשירים בבת אחת או בהדרגה, כדי לצמצם את הסיכון להפסקות נרחבות בשירות.

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

יתרונות

חבילות Fleet מבוססות על היכולות של סנכרון תצורות, כמו תיקון אוטומטי של סטיות, ומציעות את היתרונות הבאים:

  • פריסה אוטומטית של משאבים: אחרי שמגדירים חבילת Fleet, המשאבים ב-Kubernetes שהיא מפנה אליהם נפרסים באופן אוטומטי על ידי שירות חבילת Fleet בכל האשכולות.

  • הגדרה אוטומטית של אשכולות חדשים: אם מגדירים חבילת Fleet ואחר כך מוסיפים אשכולות חדשים ל-Fleet, כל המשאבים שמוגדרים בחבילת Fleet נפרסים באופן אוטומטי באשכול החדש.

  • ניהול הגדרות Kubernetes בקנה מידה נרחב: במקום לנהל אשכולות אחד אחרי השני, אפשר להשתמש בחבילות של Fleet כדי לפרוס משאבים ב-Fleet שלם של אשכולות.

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

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

יכול להיות שתעדיפו להשתמש בסנכרון ההגדרות עם אובייקטים מסוג RootSync או RepoSync במקום חבילות Fleet, אם אחד או יותר מהתרחישים הבאים רלוונטיים לכם:

  • אתם מנהלים מספר קטן של אשכולות.

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

דרישות ומגבלות

  • כשמגדירים חבילת Fleet, רק מאגרי Git נתמכים בתור מקור המידע המהימן.

  • המשאבים ב-Kubernetes שמאוחסנים ב-Git צריכים לייצג את המצב הסופי של המשאב. אין תמיכה בשכבות-על נוספות לשינוי המשאב שמאוחסן ב-Git. למידע נוסף על ההבדלים בין המשאבים האלה, קראו את המאמר שיטה מומלצת: יצירת מאגרים WET.

  • ממשק ה-API של FleetPackage זמין רק באזור us-central1. עדיין אפשר לפרוס באשכולות באזורים שונים, אבל צריך להגדיר את Cloud Build ואת ה-CLI של gcloud ב-us-central1.

  • המספר המקסימלי של חבילות לצי הוא 300 לכל פרויקט בכל אזור.

ארכיטקטורה

אתם יכולים להשתמש ב-API של FleetPackage כדי לפרוס מניפסטים של Kubernetes בצי של אשכולות. ‫FleetPackage API משתמש ב-Cloud Build כדי לסנכרן ולאחזר משאבי Kubernetes מהמאגר שלכם ב-Git. לאחר מכן, שירות חבילת ה-Fleet פורס את המשאבים האלה באשכולות שלכם.

תרשים שמראה את זרימת המשאבים של Kubernetes ב-Git שמסתנכרנים עם צי של אשכולות

איך נוצרות וריאציות

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

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

  1. ‫resourceBundleSelector.cloudBuildRepository.variantsPattern: תבנית glob שמשמשת לאיתור קבצים וספריות במאגר Git (ב-path שצוין, או בתיקיית השורש של המאגר אם לא צוין path). התבנית הזו קובעת אילו קבצים או ספריות יהפכו לווריאציות ואיזה תוכן הם יכללו.
  2. ‫variantSelector.variantNameTemplate: ביטוי שממפה כל אשכול ב-fleet לאחד משמות הווריאציות שנוצרו על ידי variantsPattern. הבחירה הזו מבוססת על המטא-נתונים של החברות ב-fleet של האשכול.

variantsPattern התאמות

השדה variantsPattern הוא שדה חובה, והוא משמש כדי לציין איך ליצור וריאציות מההגדרות ששמורות במאגר. ההתאמה מתבצעת לפי הלוגיקה הבאה:

  • התאמת קובץ: אם התבנית תואמת לקובץ YAML, נוצרת וריאציה.

    • שם הווריאנט: שם הקובץ בלי הסיומת (לדוגמה, prod-config.yaml הופך לווריאנט prod-config).
    • תוכן הווריאנט: התוכן של הקובץ היחיד הזה.

  • התאמה לספרייה: אם התבנית תואמת לספרייה, נוצרת וריאציה.

    • שם הווריאנט: שם הספרייה (לדוגמה, הספרייה dev הופכת לווריאנט dev).
    • תוכן הווריאנט: השילוב של כל קובצי ה-YAML שנמצאים בספרייה הזו ובכל ספריות המשנה שלה, באופן רקורסיבי.

לתבניות התאמה של קבצים יש את המגבלות הבאות:

  • אין תווים כלליים לחיפוש רקורסיביים (כפולים). התבנית ** לא נתמכת.
  • אם התבנית כוללת נקודה (.), צריך להוסיף אחריה תו אלפאנומרי.
  • התבניות לא יכולות לכלול מירכאות בודדות (').
  • השמות של הווריאציות חייבים להיות ייחודיים. אם התבנית תואמת לכמה קבצים עם אותו שם (לדוגמה, app1/deploy.yaml ו-app2/deploy.yaml), שניהם ינסו ליצור וריאנט בשם deploy, וכך תיווצר התנגשות שמות.

לדוגמה, נניח שיש מאגר עם המבנה הבא:

repo-root/
└── FleetPackages/
    └── clusters/
        ├── common-ingress.yaml
        ├── us-central1-a/
        │   ├── gke-1/
        │   │   ├── deployment.yaml
        │   │   └── service.yaml
        │   └── gke-2/
        │       ├── deployment.yaml
        │       └── service.yaml
        └── us-central1-b/
            ├── gke-1.yaml
            └── blue-green.yaml

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

  • variantsPattern: "*": תואם ל-common-ingress.yaml, ל-us-central1-a ול-us-central1-b. יוצר וריאציות:

    • common-ingress (מקובץ)
    • ‫us-central1-a (שילוב של כל קובצי ה-YAML בתיקייה הזו)
    • ‫us-central1-b (שילוב של כל קובצי ה-YAML בתיקייה הזו)

  • ‫variantsPattern: "*.yaml": תואם ל-common-ingress.yaml. יוצר וריאנט:

    • common-ingress

  • variantsPattern: "us-*": תואם ל-us-central1-a ול-us-central1-b. יוצר וריאציות:

    • us-central1-a
    • us-central1-b

  • ‫variantsPattern: "us-central1-b/*.yaml": תואם ל-us-central1-b/gke-1.yaml ול-us-central1-b/blue-green.yaml. יוצר וריאציות:

    • gke-1
    • blue-green

variantNameTemplate התאמות

אחרי שמגדירים את הווריאציות, השדה variantNameTemplate בקטע variantSelector קובע איזו וריאציה תוחל על כל אשכול. התבנית יכולה להשתמש במשתנים כדי לגשת למטא-נתונים הבאים של החברות ב-Fleet:

  • ‫${membership.name}: שם החברות ב-fleet של האשכול.
  • ‫${membership.location}: המיקום של החברות ב-Fleet.
  • ‫${membership.project}: הפרויקט של החברות ב-Fleet.
  • ‫${membership.labels['KEY']}: הערך של התווית KEY ב-fleet membership.

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

  • ‫variantNameTemplate: "${membership.labels['env']}": אשכול עם התווית env: prod מסתנכרן עם וריאנט בשם prod.
  • ‫variantNameTemplate: "${membership.location}": אשכולות מסתנכרנים עם גרסאות שתואמות למיקום שלהם (לדוגמה, us-central1-a).
  • ‫variantNameTemplate: "default": האשכולות מסתנכרנים עם וריאנט בשם default. זוהי פעולת ברירת המחדל אם לא מציינים את variantSelector. אם המאגר לא מכיל קובץ בשם default.yaml או ספרייה בשם default, שום דבר לא מסונכרן.

שילוב של variantsPattern ו-variantNameTemplate

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

לדוגמה, כדי לפרוס באשכולות על סמך תווית סביבה, אתם יכולים לבנות את מאגר Git עם ספריות כמו dev,‏ staging ו-prod. במקרה כזה, צריך להשתמש במפרט הבא של חבילת הצי:

resourceBundleSelector:
  cloudBuildRepository:
    # ... other fields
    path: "manifests"
    variantsPattern: "*" # Matches dev, staging, prod directories
variantSelector:
  variantNameTemplate: "${membership.labels['env']}"

בהגדרה הזו, אשכול עם התווית env: staging מקבל את התוכן של הספרייה manifests/staging/.

אסטרטגיות פריסה

אתם יכולים להשתמש בחבילות של Fleet כדי לפרוס משאבים ממאגר Git בכל אשכולות ה-Fleet. אתם יכולים גם להגדיר את חבילת ה-Fleet כדי לקבוע איך, איפה ואיזה סוג של משאבים נפרסים.

בקטע הבא מוצגות דוגמאות להגדרות שונות של FleetPackage. מידע נוסף על החלת חבילות Fleet זמין במאמר פריסת חבילות Fleet.

פריסה לכל האשכולות ב-fleet

הקוד הבא של FleetPackage משתמש באסטרטגיית פריסה הדרגתית כדי לפרוס משאבים ב-Kubernetes בשלושה אשכולות בכל פעם, ומטרגט את כל האשכולות ב-fleet:

resourceBundleSelector:
  cloudBuildRepository:
    name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
    tag: v1.0.0
    variantsPattern: "*.yaml"
    serviceAccount: projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
target:
  fleet:
    project: projects/my-project
rolloutStrategy:
  rolling:
    maxConcurrent: 3
variantSelector:
  variantNameTemplate: deployment # matches a file named deployment.yaml

פריסה לקבוצת משנה של אשכולות

הקוד הבא של FleetPackage משתמש בבורר תוויות כדי לפרוס משאבים ב-Kubernetes רק באשכולות עם תווית המינוי country שתואמת ל-"us" ב-fleet:

resourceBundleSelector:
  cloudBuildRepository:
    name: projects/my-project/locations/us-central1/connections/my-connection/repositories/my-repo
    tag: v1.0.0
    variantsPattern: "*.yaml"
    serviceAccount: projects/my-project/serviceAccounts/my-service-account@my-project.iam.gserviceaccount.com
target:
  fleet:
    project: projects/my-project
    selector:
      matchLabels:
        country: "us"
rolloutStrategy:
  rolling:
    maxConcurrent: 3

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

פריסת חבילות לצי