שימוש בחבילות Fleet ב-Distributed Cloud במודל מחובר

בדף הזה מוסבר איך להשתמש בחבילות של סנכרון תצורות ב-Google Distributed Cloud במודל מחובר. חבילות Fleet הן כלי שמשתמש במאגר Git כמקור יחיד למידע מהימן לגבי הגדרת האשכול.

חבילות Fleet בשימוש מחובר של Distributed Cloud מבוססות על אותה טכנולוגיה ופקודות כמו אשכולות רגילים של Google Kubernetes Engine. במסמכי התיעוד של GKE מוסבר איך ליצור ולנהל חבילות של Fleet במאמר פריסת חבילות של צי. בדף הזה מוסבר איך להתאים את המדריך הזה לסביבה המחוברת של Distributed Cloud.

בקטעים הבאים מוסבר מה צריך לעשות באופן שונה ב-Distributed Cloud connected, ואילו שלבים במסמכי התיעוד של GKE אפשר לבצע ללא שינויים.

דרישות

כדי להשתמש בחבילות של סנכרון תצורות ב-Distributed Cloud connected, צריך לעמוד בדרישות הבאות:

• מכיוון שבקר הפריסה נמצא בענן, צריך להיות אפשר להגיע אל מאגר ה-Git שלכם דרך האינטרנט הציבורי. אין תמיכה בשרתי Git פנימיים או מקומיים שלא חשופים לציבור.
• ב-Distributed Cloud Connected אפשר להשתמש רק באיחוד שירותי אימות הזהות של עומסי עבודה בצי כדי לבצע אימות מול שירותי Google Cloud . שיטות אימות אחרות של סנכרון תצורות, כמו מפתחות SSH או קובצי Cookie, לא אפשריות לחיבור בין האשכולות לבין מאגר חבילות עם ניהול גרסאות. מידע נוסף זמין במאמר Workload Identity Cluster Authentication.
• כל האשכולות ב-Fleet צריכים להיות באותו פרויקט. ‫Distributed Cloud Connected לא תומך ברישום של אשכולות בכמה פרויקטים בפרויקט מרכזי יחיד לניהול צי.
• מניפסטים של Kubernetes צריכים לעמוד בדרישות של הגבלות על עומסי עבודה שמחוברים ל-Distributed Cloud. מניפסטים שמפירים את ההגבלות האלה נחסמים על ידי בקר ההרשאות של האשכול.
• חבילות Fleet דורשות סנכרון תצורות בגרסה 1.16.0 ואילך.

התנהגות המערכת

חבילות Fleet ב-Distributed Cloud במודל מחובר מתנהגות באופן הבא:

• חבילות Fleet הופכות את מניפסטים של Kubernetes לתמונות OCI עם גרסאות. התמונות האלה מאוחסנות במאגר מנוהל של Artifact Registry בשם fleet-packages, שנוצר אוטומטית בפרויקט. האשכולות שלכם שולפים את התמונות האלה ישירות מהמאגר כדי להבטיח מסירה עקבית ומהימנה.
• חבילות Fleet מקבלות בירושה את אופן הפעולה של תיקון הסטיות של סנכרון תצורות. שינויים ידניים במשאבים באשכול נמחקים אוטומטית כדי להתאים לחבילות OCI עם ניהול גרסאות.
• אם אשכול מחובר של Distributed Cloud עובר למצב הישרדות, סוכן סנכרון תצורות ממשיך לאכוף את ההגדרה האחרונה שסונכרנה בהצלחה באופן מקומי. עם זאת, כל השקה או עדכון חדשים של חבילת הצי יושעו עד לחידוש הקישוריות לענן.
• חבילות Fleet מקבלות בירושה את ההתנהגות של גיזום אוטומטי של משאבים ב-Config Sync. כשיוצרים תג חדש במאגר Git ומעדכנים את ההגדרה של חבילת Fleet בתג החדש כדי להתחיל סנכרון, סוכן סנכרון תצורות מוחק את המשאב התואם מהאשכול אם מסירים מניפסט ממאגר Git.
• אם כמה חבילות של Fleet מנהלות את אותו משאב, נוצרות טענות בעלות סותרות. אם תנסו למחוק חבילת ציוד כשקיימת בעלות מתנגשת, יכול להיות שהמחיקה תיעצר. כדי לפתור את הבעיה, צריך לשנות את אחד מחבילות הצי המתחרות כדי להסיר את המשאב שגורם להתנגשות לפני שמנסים למחוק את החבילה.

תנאים מוקדמים לשימוש ב-Distributed Cloud במודל מחובר

לפני שמבצעים את השלבים במאמר פריסת חבילות Fleet, צריך לוודא שהסביבה המחוברת של Distributed Cloud והרשאות המשתמש מוגדרות בצורה תקינה.

רשתות ואבטחה

סביבת הרשת צריכה לעמוד בדרישות הבאות:

• VPC Service Controls. אם הפרויקט שלכם מוגן על ידי גבולות גזרה של שירות VPC, צריך לוודא שלסוכני השירות של Cloud Build ושל Config Delivery, לדוגמה, [e-mail], יש הרשאה לחצות את גבולות הגזרה ולמשוך תמונות מ-Artifact Registry. מידע נוסף זמין במאמר בנושא הגדרת שילוב של VPC Service Controls.
• גישה לתעבורת נתונים יוצאת. לאשכולות שלכם ב-Distributed Cloud במודל מחובר צריכה להיות גישה ליציאת תעבורת נתונים יוצאת (egress) אל us-central1-docker.pkg.dev. חבילות Fleet מאחסנות את חבילות המניפסט שלכם כתמונות OCI ב-Artifact Registry. האשכולות צריכים להיות מסוגלים לשלוף את התמונות האלה ישירות מ-Artifact Registry.

הגדרת מאגר

מאגר Artifact Registry שמכיל את חבילות המניפסט צריך להיות באותו פרויקט כמו חבילת הצי, והוא צריך להיות ממוקם ב-us-central1.

ההרשאות הנדרשות

כדי לבצע את השלבים בסביבה המחוברת של Distributed Cloud, צריכות להיות לכם התפקידים הבאים ב-IAM בפרויקט:

• ‫Config Delivery Admin (roles/configdelivery.admin): נדרש כדי ליצור ולנהל חבילות והפצות של צי מכשירים
• אדמין של Developer Connect (roles/developerconnect.admin): נדרש כדי ליצור ולנהל חיבורים למאגר
• אדמין IAM בפרויקט (roles/resourcemanager.projectIamAdmin): נדרש כדי להקצות את התפקידים הדרושים לחשבון השירות

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

ממשקי API נדרשים

צריך להפעיל ממשקי API לחיבורים למאגר ולתקשורת מאובטחת עם אשכולות מחוברים של Distributed Cloud. כדי להפעיל את ממשקי ה-API הנדרשים, מריצים את הפקודה הבאה של gcloud services enable:

gcloud services enable anthosconfigmanagement.googleapis.com \
    configdelivery.googleapis.com \
    cloudbuild.googleapis.com \
    connectgateway.googleapis.com \
    developerconnect.googleapis.com \
    artifactregistry.googleapis.com

ממשקי ה-API האלה נדרשים לרכיבים הבאים:

• ‫anthosconfigmanagement.googleapis.com: מנהל את סוכן סנכרון התצורות באשכולות
• ‫configdelivery.googleapis.com: מתאם את ההשקה של משאבי Kubernetes ב-Fleet של האשכולות
• ‫cloudbuild.googleapis.com: מאחזר את מניפסטים של Kubernetes מ-Git ואורז אותם בחבילות עם גרסאות
• ‫connectgateway.googleapis.com: מספק חיבור מאובטח בין שירות העברת ההגדרות לבין אשכולות מחוברים של Distributed Cloud
• ‫developerconnect.googleapis.com: מאפשר חיבורים מאובטחים למארח של מאגר Git חיצוני
• ‫artifactregistry.googleapis.com: מאחסן את חבילות החבילות עם הגרסאות כתמונות OCI בפרויקט

הגדרות ברירת מחדל של הסביבה

ה-API של Config Delivery לחבילות של צי רכבים נתמך רק ב-us-central1. כדי לוודא שהפקודות מנותבות בצורה נכונה, משתמשים בפקודה gcloud config set כדי להגדיר את פרויקט ברירת המחדל והמיקום:

1. מגדירים את פרויקט ברירת המחדל:

   gcloud config set project PROJECT_ID
   

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

2. הגדרת מיקום ברירת המחדל לחבילות של צי הרכבים. כל חיבורי המאגרים של Cloud Build שמשמשים עם חבילות Fleet צריכים להיות באזור us-central1.

   gcloud config set config_delivery/location us-central1
   

הבדלים בתהליך

השתמשו בטבלה הבאה כדי להבין איך להחיל את השלבים שבמאמר פריסת חבילות Fleet על סביבה מקושרת של Distributed Cloud.

שלב רגיל	התאמה של Distributed Cloud במודל מחובר
רישום אשכולות ב-Fleet	דלג על שלב זה. אשכולות מחוברים של Distributed Cloud נרשמים באופן אוטומטי ל-Fleet בפרויקט כשיוצרים אותם.
התקנת סנכרון תצורות	פועלים לפי השלבים הרגילים, אבל מומלץ להשתמש בשיטה התקנה בכל ה-Fleet (ברירת מחדל של ה-Fleet). מגדירים את השיטה הזו בהגדרות של Hub או Fleet במסוף Google Cloud . ההטמעה הזו מבטיחה שכל הצמתים הקיימים או העתידיים שמחוברים ל-Distributed Cloud באזור שלכם יקבלו באופן אוטומטי את סוכן סנכרון תצורות. בסוג חבר האימות, צריך לבחור באפשרות Workload Identity.‫ לחשבון השירות שבו אתם משתמשים ל-Workload Identity צריך להיות התפקיד roles/artifactregistry.reader בפרויקט, כדי שסוכן סנכרון תצורות יוכל לשלוף חבילות מניפסט ממאגר fleet-packages המנוהל.
יצירה של חשבון שירות	פועלים לפי ההוראות ליצירת חשבון שירות בשביל Cloud Build ונותנים את ההרשאות הנדרשות. חשבון השירות חייב להיות באותו פרויקט כמו חבילת הצי. מומלץ להשתמש בפקודות הבאות: כדי ליצור את חשבון השירות, מריצים את הפקודה gcloud iam service-accounts create: ‫ gcloud iam service-accounts create "SERVICE_ACCOUNT_NAME" מחליפים את הערך SERVICE_ACCOUNT_NAME בשם שרוצים לתת לחשבון השירות. מוסיפים את התפקידים הנדרשים של ניהול זהויות והרשאות גישה (IAM) על ידי הרצת הפקודה gcloud projects add-iam-policy-binding לכל אחד מהתפקידים הבאים. למידע נוסף על IAM, ראו סקירה כללית על IAM. roles/configdelivery.resourceBundlePublisher: מאפשר לחשבון השירות ליצור ולנהל חבילות משאבים וגרסאות ‫roles/cloudbuild.connectionUser: מאפשר לחשבון השירות להשתמש בחיבור למאגר ב-Cloud Build ‫roles/logging.logWriter: מאפשר לחשבון השירות לכתוב יומני בנייה ‫roles/artifactregistry.writer: מאפשר לחשבון השירות לדחוף חבילות של חבילות בגרסה ל-Artifact Registry roles/developerconnect.connectionUser: מאפשר לחשבון השירות להשתמש בחיבור Developer Connect לחשבון השירות צריכה להיות גם הרשאת קריאה ממאגר Git המקושר אצל ספק Git. מידע על הרשאת החיבור מופיע במאמר חיבור למאגר.
זיהוי שם המועדון	כשפקודה מבקשת MEMBERSHIP_NAME, משתמשים בשם של אשכול מחובר של Distributed Cloud. אפשר למצוא את שם האשכול באמצעות הפעלת הפקודה gcloud container fleet memberships list.
זיהוי אשכול	לפני שמטרגטים אשכול עם חבילת צי, אם עומסי העבודה דורשים הגדרת רשת ברמת המארח, כמו HugePages או SR-IOV, צריך להחיל ולאמת את המשאבים NodeSystemConfigUpdate בכל צומת באשכול.
זיהוי תגי Git	בכלי השליטה בהשקה נדרשים תגי Git בפורמט מלא של גרסה סמנטית (major.minor.patch). לדוגמה, v1.0.0 הוא פורמט תקין, אבל v1 לא.
טירגוט אשכולות ספציפיים	אף על פי שהאשכולות נרשמים אוטומטית, אם רוצים לטרגט קבוצות משנה של אשכולות באמצעות בוררי תוויות, צריך להוסיף תוויות באופן ידני לחברות באשכול.
אסטרטגיות פריסה	אפשר להשתמש בתוויות ובמאפייני וריאציה כדי לטרגט אשכולות ספציפיים. ב-Distributed Cloud connected, משתני מטא-נתונים של חברות, כמו פרויקט ומיקום, שמשמשים בתבניות של הווריאציות, מתייחסים למשאבים בצד הענן שמשויכים לאשכול Distributed Cloud connected. המטא-נתונים הבאים של חברות שספציפיים ל-Distributed Cloud זמינים לשימוש בתבניות של וריאציות: cluster_name: השם של האשכול המחובר שלכם ב-Distributed Cloud ‫location: Google Cloud האזור שמשויך לאשכול ‫project: מזהה הפרויקט שבו האשכול רשום ‫labels: כל התוויות שהחלתם על החברות באשכול

נהלים משותפים

במשימות התפעוליות הבאות, תחביר הפקודות והתנהגות השירות זהים ב-Distributed Cloud connected וב-GKE רגיל. כשפועלים לפי ההוראות האלה, צריך להשתמש בהגדרות ובערכים שמוגדרים בטבלה שבקטע הבדלים פרוצדורליים במסמך הזה.

• יצירת חבילת Fleet: מגדירים את משאב FleetPackage לאחזור ולפריסה של ההגדרה.
• עדכון חבילת צי: משנים את החבילה כדי להשיק שינויים או לעדכן הגדרות.
• ניהול פריסת חבילות לצי הרכב: השהיה, המשכה או ביטול של פריסות פעילות.
• בדיקת חבילות משאבים וגרסאות: ניפוי באגים ביצירת וריאנטים ובניהול גרסאות. חבילות משאבים הן קונטיינרים להגדרות, ומהדורות הן מופעים עם גרסאות של החבילות האלה. כדי לוודא שההעברה לחומרה המחוברת ל-Distributed Cloud הצליחה, משתמשים בפקודה gcloud container fleet memberships get-credentials כדי לקבל גישה לאשכול, ואז משתמשים בפקודה kubectl כדי לבדוק את הסטטוס של RootSync באשכול.
• מחיקת חבילת Fleet: הסרת חבילת Fleet והמשאבים המנוהלים שלה. כדי לוודא שההסרה תתבצע בצורה נקייה, צריך לוודא שאובייקטים מנוהלים של RootSync שמשויכים לחבילת ה-Fleet יוסרו מהאשכולות.

מעקב ופתרון בעיות

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

לדוגמה, מריצים את הפקודה הבאה gcloud container fleet packages rollouts describe כדי לראות הודעת סטטוס מפורטת לכל אשכול ב-Fleet:

gcloud container fleet packages rollouts describe ROLLOUT_NAME \
    --fleet-package=FLEET_PACKAGE_NAME \
    --format=json

מחליפים את הערכים הבאים:

• ‫ROLLOUT_NAME: שם ההשקה.
• ‫FLEET_PACKAGE_NAME: השם של חבילת הצי.

אם בנייה נכשלת או נתקעת, אפשר למצוא קישור ליומני הסטרימינג של משימת Cloud Build בפלט של הפקודה gcloud container fleet packages list. אם ההשקה נשארת במצב PENDING או STALLED, צריך לבדוק את הקישוריות של הציוד שמחובר ל-Distributed Cloud, כמו שמתואר במאמר פתרון בעיות ב-Distributed Cloud.

מידע נוסף על אבחון שגיאות שקשורות ל-Cloud Build זמין במאמר בנושא פתרון בעיות ב-build.

אימות סטטוס הסנכרון באשכול

כדי לוודא שהאשכול מסתנכרן בהצלחה עם חבילת ה-Fleet, בודקים את המשאב RootSync באשכול. השם של האובייקט RootSync באשכול זהה לשם FLEET_PACKAGE_NAME שבחרתם לחבילה.

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

kubectl get rootsync FLEET_PACKAGE_NAME -n config-management-system

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

kubectl describe rootsync FLEET_PACKAGE_NAME -n config-management-system

מידע נוסף זמין במאמר מעקב אחרי אובייקטים של RootSync ו-RepoSync במאמרי העזרה של GKE.

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