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

‫Fleets ב- Google Cloud הם קבוצות לוגיות של אשכולות Kubernetes ומשאבים אחרים שאפשר לנהל יחד. הם נוצרים על ידי רישום אשכולות ב- Google Cloud. שער Connect מבוסס על היכולות של צי GKE ומאפשר למשתמשי GKE להתחבר לאשכולות חברים בצי ולהריץ בהם פקודות בצורה פשוטה, עקבית ומאובטחת, בין אם האשכולות נמצאים ב- Google Cloud, בעננים ציבוריים אחרים או בפריסה מקומית. השער גם מקל על אוטומציה של תהליכי DevOps בכל האשכולות.

במדריך הזה אנחנו מניחים שאתם כבר מכירים כמה מושגים בסיסיים שקשורים לצי, וגם את תהליך רישום האשכולות לצי. אם לא, תוכלו לקרוא מידע נוסף במאמרים סקירה כללית על ניהול ה-Fleet וסקירה כללית על יצירת ה-Fleet ובמדריכים המקושרים. כדאי גם להכיר את הכלים והמושגים של Kubernetes, כולל kubectl,‏ client-go (אם רוצים להשתמש בשער למטרות אוטומציה), בקרת גישה מבוססת-תפקידים (RBAC) ומשאבי ליבה של Kubernetes.

כברירת מחדל, Connect gateway משתמש במזהה Google שלכם כדי לבצע אימות לאשכולות, עם תמיכה בספקי זהויות של צד שלישי באמצעות איחוד שירותי אימות הזהות של כוח עבודה, ועם תמיכה באימות מבוסס-קבוצות באמצעות GKE Identity Service. אם רוצים לקבל מידע נוסף על GKE Identity Service או להשתמש בו כאפשרות אימות עצמאית של צד שלישי, אפשר לעיין במאמר היכרות עם GKE Identity Service.

למה כדאי להשתמש בשער Connect?

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

שער Connect מאפשר לכם בקלות:

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

השער מאמת את הזהות שלכם Google Cloud ומספק את החיבור לשרת ה-API של האשכול דרך שירות Connect.

אתם יכולים לקיים אינטראקציה עם אשכולות ישירות דרך השער באמצעות כלי שורת פקודה שמקבלים kubeconfig כמו kubectl. אפשר גם להשתמש בקלות בשער עם צינורות build ואוטומציה אחרת של DevOps. דוגמה לאופן ההגדרה מופיעה במדריך בנושא שילוב עם Cloud Build.

אפשר גם להשתמש בשירות Connect כדי להתחבר לאשכולות רשומים מחוץ Google Cloud עם הזהות Google Cloud שלכם במסוף Google Cloud . כדי לעשות את זה, פועלים לפי ההוראות במאמר עבודה עם אשכולות במסוף Google Cloud .

איך זה עובד

זהו התהליך שמשתמש או שירות טיפוסיים (כמו צינור CI/CD) מבצעים כדי להשתמש בשער Connect, אחרי שמגדירים אימות והרשאה מתאימים. הוראות מפורטות יותר למשתמשים זמינות במדריך לשימוש.

  1. המשתמש או השירות מגלים אשכולות על ידי הצגת רשימה של משאבי חברות בצי באמצעות Google Cloud CLI.

    gcloud container fleet memberships list

  2. המשתמש או השירות מאחזרים את kubeconfig הספציפיים לשער Connect שנדרשים כדי להגיע לאשכול שנבחר באמצעות Google Cloud CLI.

    gcloud container fleet memberships get-credentials membership-name

    אם אתם כבר יודעים איך להשתמש ב-CLI של gcloud עם GKE, הפעולה דומה להרצת gcloud container clusters get-credentials באמצעות החשבון שלכם, ומאפשרת לכם (אם יש לכם הרשאה) לגשת לכל אשכול שרשום ומחובר בצי הפרויקטים שלכם. Google Cloud

  3. המשתמש או השירות מבצעים את הפקודות כרגיל עםkubectl או client-go, באמצעות קובץ kubeconfig שהורד.

    1. המשתמש או השירות מאומתים על ידי Connect gateway, וההרשאה נבדקת כדי לוודא שיש להם הרשאה להשתמש ב-gateway. באשכולות GKE, שער הגישה מתחבר ישירות לאשכול GKE.
    2. באשכולות Kubernetes שאינם GKE, הבקשה מועברת דרך שירות Connect ו-Connect Agent לשרת ה-API המתאים של Kubernetes.
    3. במקרה של אשכולות Kubernetes שאינם GKE, שרת Kubernetes API מאשר את הבקשה. לשם כך, סוכן Connect צריך להיות מורשה להתחזות למשתמש או לשירות, והמשתמש או השירות צריכים להיות מורשים להריץ את הבקשה הרצויה.

תמיכה בקבוצות Google

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

מידע נוסף על אופן הפעולה של התכונה הזו ועל אופן ההגדרה שלה בהגדרת שער ה-Connect באמצעות קבוצות Google.

אם רוצים להשתמש בתכונה הזו עם אשכולות מצורפים או סביבות GKE אחרות, אפשר לפנות אל Cloud Customer Care או אל צוות שער Connect.

תמיכה בזהויות של צד שלישי

בנוסף לעבודה עם משתמשים וקבוצות ב-Google Workspace, Connect gateway תומך בהרשאה באמצעות זהויות של צד שלישי, כמו Azure Active Directory ו-Okta. באמצעות איחוד שירותי אימות הזהות של כוח עבודה, אתם יכולים להשתמש בספק זהויות חיצוני כדי לאמת ולאשר לכוח העבודה שלכם את הגישה לשירותיGoogle Cloud , כמו Connect Gateway, באמצעות ניהול זהויות והרשאות גישה (IAM). כוח העבודה יכול להיות קבוצה של משתמשים, כמו עובדים, שותפים או קבלנים. בעזרת הגדרה נוספת באמצעות שירות הזהויות של GKE, אפשר להגדיר את שער Connect כך שיקבל מידע על חברות בקבוצות של צד שלישי עבור משתמשים.

באשכולות GKE מצורפים, התכונה הזו זמינה לכל גרסאות האשכולות של Kubernetes שנתמכות.

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

אם אתם מעדיפים, אתם יכולים להגדיר אימות של צד שלישי באמצעות שירות הזהויות של GKE בלבד, לפי ההוראות במסמכי התיעוד שלו.

זמן אחזור

אפשר לחלק את זמן האחזור הכולל של בקשה דרך השער לשני חלקים: זמן הלוך ושוב (RTT) משירות שער Connect לסוכן Connect, וזמן הביצוע של הבקשה בתוך האשכול. זמן האחזור הנוסף שנובע מ-RTT הוא p95<500ms ו-p99<1s. שימו לב שרוב הפקודות של kubectl מבצעות סדרה של כמה בקשות שונות, שכל אחת מהן דורשת הלוך ושוב, לפני שהתשובה מוצגת למשתמש.

מה השלב הבא?