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

בדף הזה מוסבר על חבילות של צי מכשירים, על FleetPackage API ועל הקשר שלהם ל-סנכרון תצורות.

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

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

יתרונות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ארכיטקטורה

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

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

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

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

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

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

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

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

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

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

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" בצי:

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

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

פריסת חבילות של צי מכשירים