מידע על GKE Hypercluster

הרבה לקוחות GKE מריצים עומסי עבודה של AI/ML בקנה מידה גדול או מחזיקים בקניין רוחני (IP) רגיש, כמו משקלים של מודלים קנייניים. במסמך הזה מתוארת ארכיטקטורת תשתית שמריצה קונטיינרים במכונות מרוחקות, שיכולות לפעול בכמה אזורים ומנוהלות על ידי צמתים באשכול. התשתית המקושרת הזו, כולל תמונות ומאפיינים שונים של מערכת ההפעלה (OS), נקראת GKE Hypercluster.

‫GKE Hypercluster מיועד ללקוחות שרוצים אבטחה ומדרגיות מעבר למגבלות של GKE או של AI Hypercomputer, ומוכנים לקבל חיכוך תפעולי מוגבר כדי להשיג את היעדים האלה.

מתי כדאי להשתמש ב-GKE Hypercluster

כברירת מחדל, אשכולות GKE מתוכננים לעמוד בדרישות של רוב עומסי העבודה של AI בסביבת ייצור, כולל עומסי עבודה עם דרישות מיוחדות של אבטחה ומדרגיות. לדוגמה, GKE תומך בתרחישים לדוגמה כמו:

  • להריץ מעבדי GPU בצמתים של Confidential Google Kubernetes Engine ולגשת למודולים של vTPM או של Confidential Computing מבוסס-חומרה מעומסי העבודה שלכם.
  • משתמשים באיחוד זהויות של עומסי עבודה ל-GKE כדי להגביל את הגישה לנתונים מוצפנים לזהויות מורשות ספציפיות.
  • פריסת צומתי TPU ו-GPU על סמך הקיבולת הזמינה באמצעות ComputeClasses ויצירה אוטומטית של מאגרי צמתים.
  • לשלוט בגישה של צוות Google ולעקוב אחריה באמצעות Access Approval,‏ Access Transparency ושליטה במישור הבקרה של GKE.

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

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

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

איך זה עובד

כפי שמתואר בארכיטקטורת אשכולות GKE, לאשכול במצב רגיל יש מישור בקרה אזורי או אזורי שמשרת את Kubernetes API ומנהל את כל הצמתים ומאגרי הצמתים באשכול. כל הצמתים באשכול משתמשים ברשת VPC ספציפית, שיכול להיות שמשאבים אחרים של Google Cloud משתמשים בה גם. כל צומת GKE מפעיל רכיבי מערכת שונים, כמו סוכני צומת kubelet, סוכני רישום ביומן וסוכני מדדים, ורכיבים אחרים של Kubernetes ו-GKE.

לעומת זאת, ב-GKE Hypercluster נעשה שימוש במופעים בשם linked runners שלא רשומים כאובייקטים מסוג Node בשרת ה-API של Kubernetes. למופעים האלה יש את המאפיינים הבאים:

  • אין סוכני Kubernetes וקבוצה מינימלית של רכיבי GKE.
  • קובצי אימג' של מערכת הפעלה מיוחדים על סמך תרחיש השימוש. אין קובצי אימג' של צומתי GKE.
  • המופעים משתמשים ברשת VPC נפרדת וייעודית.

ה-runners המקושרים מנוהלים על ידי צומתי בקרה באשכול שמקשרים את ה-runner לאשכול. בצמתי הבקרה מורצים רכיבי מערכת כמו תהליכי kubelet. צומת בקרה אחד יכול להיות מקושר לכמה רצים. ה-Runners המקושרים האלה מיועדים להרצת עומסי עבודה בקנה מידה גדול מאוד, כמו משימת אימון שדורשת יותר כוח ממה שמרכז הנתונים באזור האשכול יכול לספק.

במהלך הגדרת התשתית, יוצרים מריצים עם הגדרה ספציפית בהתאם לתרחיש לדוגמה, ואז מקשרים את המכונות לצומתי בקרה ייעודיים באשכול. ה-API של Kubernetes צריך לנהל רק את צמתי הבקרה, כי למופעי ה-Runner המקושרים אין kubelet והם לא יוצרים תנועה של שרת API. כשיוצרים את מופעי הרצת הבדיקות המקושרים, אפשר להגדיר את המופעים באחת מהדרכים הבאות:

  • הגדרת ברירת המחדל: כברירת מחדל, המכונות המקושרות הן מכונות וירטואליות של Compute Engine שמריצות קובץ אימג' של מערכת הפעלה שמותאמת לקונטיינרים. אדמינים של הפלטפורמה ואנשי צוות לטיפול במצבי חירום, כמו מהנדסי SRE, יכולים לגשת למופעים באמצעות SSH. המופעים האלה שימושיים כשרוצים לשמור על גישת אדמין לתשתית.
  • הגדרה אטומה: חלק מעומסי העבודה של ה-AI מעבדים נתונים רגישים, כמו משקלים של מודלים קנייניים ושאילתות מוצפנות. במצבים שבהם צריך להגן על נכסי ה-AI מפני כל גישה, כולל גישה של צוות Google והאדמינים שלכם, אפשר להגדיר את מופעי ה-Runner המקושרים במצב אטום. למופעים החתומים האלה יש את המאפיינים הבאים:
    • משתמשים בתמונה מינימלית של מערכת הפעלה.
    • משתמשים במובלעת Titanium Intelligence עבור TPUs וב-NVIDIA Confidential Computing עבור GPUs.
    • לבצע אימות ברמת עומס העבודה וברמת הקושחה.
    • אימות חתימות של קובצי אימג' של קונטיינרים.
    • למנוע גישת אדמין לכל המקרים ולמאגרי התגים.

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

מידע על הגדרות ברירת המחדל

כברירת מחדל, המכונות שאתם יוצרים עבור GKE Hypercluster מיועדות להרצת עומסי עבודה של ייצור, תוך מתן מנגנונים דומים לצמתי GKE רגילים לצורך פתרון בעיות ותגובה למקרי חירום. המופעים פועלים בסוגי מכונות של Compute Engine ומשתמשים בקובץ אימג' של מערכת ההפעלה שמותאמת לקונטיינרים. במהלך אירועים כמו שיבושים או קריסות, האדמינים יכולים לגשת ישירות למופעים כדי לפתור בעיות. בניגוד לצמתים של Kubernetes, המופעים לא מריצים הרבה מרכיבים של המערכת שמאפשרים את התכונות של Kubernetes ו-GKE, ולכן יש יותר משאבים להקצאה בכל מופע.

אתם יכולים ליצור מופעים בכל אזור Google Cloud ולקשר את המופעים האלה לצמתי בקרה באשכול. צמתי הבקרה מבצעים רבות מהפונקציות של רמת הבקרה של Kubernetes, ומנהלים את מחזור החיים של עומסי העבודה שנפרסו.

מידע על ההגדרה הסגורה

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

  • כל מופע הוא סביבת מחשוב אמינה (TEE) שמבוססת על טכנולוגיות ספציפיות:
    • יחידות ה-TPU משתמשות במובלעת Titanium Intelligence, שהיא חלק מפלטפורמת Private AI Compute.
    • יחידות ה-GPU משתמשות ב-NVIDIA Confidential Computing כדי להגן על הנתונים בזמן השימוש.
  • המופעים מריצים תמונה מינימלית של מערכת הפעלה שמבוססת על מערכת הפעלה שמותאמת לקונטיינרים, שמשביתה את הגישה ל-SSH, מונעת גישה למעטפת של קונטיינר ומריצה סוכן אימות.
  • אתם מגדירים מדיניות שמציינת בדיוק אילו עומסי עבודה יכולים לפעול במכונות. לדוגמה, אתם יכולים לדרוש שעומסי העבודה ישתמשו בתקצירים חתומים של קובצי אימג' של קונטיינרים, או שיהיה להם מפרט Pod ספציפי.
  • סוכן אימות שולח מדידות של קושחה ועומס עבודה אל Google Cloud Attestation ומחזיר אסימונים של תוצאות אימות שאפשר לאמת.

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

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

  • משקלי המודל:

    1. הצפנת משקלי המודל באמצעות מפתח Cloud HSM ב-Cloud KMS.
    2. אחסון משקלים של מודלים מוצפנים ב-Cloud Storage.
    3. נותנים לעומסי עבודה מאומתים בלבד הרשאת קריאה לקטגוריה.
    4. צריך לתת גישה למפתח הפענוח רק לעומסי עבודה מאומתים.

  • שאילתות ותשובות:

    1. הצפנת שאילתות ותשובות באמצעות מפתח Cloud HSM ב-Cloud KMS.
    2. צריך לתת גישת פענוח רק לעומסי עבודה מאומתים.
    3. נדרשת הוכחת אימות כששולחים נתונים מוצפנים בין עומסי עבודה.

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

זכאות להנחה

‫GKE Hypercluster מיועד לתרחישי שימוש ספציפיים של AI/ML שלא ניתן לממש באמצעות הארכיטקטורה והתכונות האופייניות של אשכול GKE. ללקוחות שמשתמשים ב-GKE Hypercluster יש דרישות אבטחה ודרישות מדרגיות לא אופייניות. ‫GKE Hypercluster זמין רק ללקוחות GKE שעומדים בדרישות. כדי לבדוק אם אתם עומדים בדרישות ולבקש גישה, פנו לצוות ניהול החשבון הייעודי שלכם.