הרבה לקוחות GKE מריצים עומסי עבודה של AI/ML בקנה מידה גדול או מחזיקים בקניין רוחני (IP) רגיש, כמו משקלים של מודלים קנייניים. במסמך הזה מתוארת ארכיטקטורת תשתית שמריצה קונטיינרים במופעים מרוחקים שיכולים לפעול בכמה אזורים ומנוהלים על ידי צמתים באשכול. התשתית המקושרת הזו, כולל התכונות והתמונות השונות של מערכת ההפעלה (OS), נקראת GKE Hypercluster.
GKE Hypercluster מיועד ללקוחות שרוצים אבטחה ומדרגיות מעבר למגבלות של GKE או של AI Hypercomputer, ומוכנים לקבל חיכוך תפעולי מוגבר כדי להשיג את היעדים האלה.
מתי כדאי להשתמש ב-GKE Hypercluster
כברירת מחדל, אשכולות GKE מתוכננים לעמוד בדרישות של רוב עומסי העבודה של AI בסביבת ייצור, כולל עומסי עבודה עם דרישות מיוחדות של אבטחה ומדרגיות. לדוגמה, GKE תומך בתרחישים כמו הבאים:
- הפעלת מעבדי GPU ב-Confidential Google Kubernetes Engine Nodes וגישה למודולים של Confidential Computing מבוסס-חומרה או ל-vTPM מעומסי העבודה.
- משתמשים באיחוד זהויות של עומסי עבודה ל-GKE כדי להגביל את הגישה לנתונים מוצפנים לזהויות מורשות ספציפיות.
- פריסת צמתי TPU ו-GPU על סמך הקיבולת הזמינה באמצעות ComputeClasses ויצירה אוטומטית של מאגר צמתים.
- אפשר לשלוט בגישה של צוות Google ולעקוב אחריה באמצעות אישור גישה, 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 נפרדת וייעודית.
הראנרים המקושרים מנוהלים על ידי צמתי בקרה באשכול שמקשרים את הראנר לאשכול. בצמתים של אמצעי הבקרה פועלים רכיבי מערכת כמו תהליכי kubelet. צומת בקרה אחת יכולה להיות מקושרת לכמה רצים. ה-runners המקושרים האלה מיועדים להרצת עומסי עבודה בקנה מידה גדול מאוד, כמו משימת אימון שדורשת יותר כוח ממה שמרכז הנתונים באזור האשכול יכול לספק.
במהלך הגדרת התשתית, יוצרים רצים עם הגדרה ספציפית על סמך תרחיש השימוש, ואז מקשרים את המכונות לצמתי בקרה ייעודיים באשכול. ה-API של Kubernetes צריך לנהל רק את צמתי הבקרה, כי למופעי הרצת הבדיקות המקושרים אין kubelet והם לא יוצרים תנועה של שרת API. כשיוצרים את מופעי ה-runner המקושרים, אפשר להגדיר את המופעים באחת מהדרכים הבאות:
- הגדרת ברירת מחדל: כברירת מחדל, המכונות המקושרות הן מכונות וירטואליות של 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, ומנהלים את מחזור החיים של עומסי העבודה שנפרסו.
מידע על הגדרות חתומות
אם מקרה השימוש העיקרי שלכם הוא להגן על הנכסים מפני גישה, אתם יכולים להגדיר את הרצים המקושרים כך שישתמשו בהגדרה אטומה, וכתוצאה מכך ייווצרו מופעים עם מאפייני האבטחה הבאים:
- כל מופע הוא סביבת מחשוב אמינה (TEE) שמבוססת על טכנולוגיות ספציפיות:
- יחידות ה-TPU משתמשות במובלעת Titanium Intelligence, שהיא חלק מפלטפורמת Private AI Compute.
- יחידות ה-GPU משתמשות ב-NVIDIA Confidential Computing כדי להגן על הנתונים בזמן השימוש.
- המופעים מריצים תמונה מינימלית של מערכת הפעלה שמבוססת על מערכת הפעלה שמותאמת לקונטיינרים, שמשביתת את הגישה ל-SSH, מונעת גישה למעטפת של קונטיינר ומריצה סוכן אימות.
- אתם מגדירים מדיניות שמציינת בדיוק אילו עומסי עבודה יכולים לפעול במופעים. לדוגמה, אתם יכולים לדרוש שעומסי עבודה ישתמשו בסיכומי תמונות של קונטיינרים חתומים או במפרט ספציפי של Pod.
- סוכן אימות שולח מדידות של קושחה ועומסי עבודה אל Google Cloud Attestation ומחזיר טוקנים של תוצאות אימות שאפשר לאמת.
המופעים שמתקבלים מספקים סביבות מוגבלות ומאומתות שבהן רק קוד מאושר יכול לפעול, ומידע אישי רגיש מעובד במובלעות מאובטחות שמבוססות על חומרה. פרטי האישור שמוחזרים על ידי המופעים מאמתים שעומסי העבודה מריצים קוד שאושר ושהם נפרסים במופעים הנכונים.
אתם יכולים להשתמש במופעים החתומים האלה כדי להגן על המודלים, השאילתות והתשובות המוצפנים שלכם בדרכים הבאות:
משקלי מודלים:
- הצפנת משקלי המודל באמצעות מפתח Cloud HSM ב-Cloud KMS.
- אחסון משקלי מודלים מוצפנים ב-Cloud Storage.
- מעניקים הרשאת קריאה לקטגוריה רק לעומסי עבודה מאומתים.
- צריך לתת גישה למפתח הפענוח רק לעומסי עבודה מאומתים.
שאילתות ותשובות:
- הצפנת שאילתות ותשובות באמצעות מפתח Cloud HSM ב-Cloud KMS.
- כדאי לתת גישת פענוח רק לעומסי עבודה מאומתים.
- נדרש אימות כששולחים נתונים מוצפנים בין עומסי עבודה.
ההגדרה 'אטום' היא שכבת אבטחה אופציונלית למופעי Runner מקושרים. בדומה להגדרת ברירת המחדל, אפשר ליצור את המופעים החתומים בכל אזור וכל תחום. עם זאת, מאפייני האבטחה של המקרים האלה אומרים שאדמינים ואנשי צוות של Google לא יכולים לגשת למקרים של המארח כדי לפתור בעיות.
זכאות להנחה
GKE Hypercluster מיועד לתרחישי שימוש ספציפיים של AI/ML שלא ניתן לממש באמצעות הארכיטקטורה והתכונות האופייניות של אשכול GKE. ללקוחות שמשתמשים ב-GKE Hypercluster יש דרישות לא שגרתיות בנוגע לאבטחה ולמדרגיות. GKE Hypercluster זמין רק ללקוחות GKE שעומדים בדרישות. כדי לבדוק אם אתם עומדים בדרישות ולבקש גישה, פנו לצוות ניהול החשבון הייעודי שלכם.