Google Distributed Cloud הוא פתרון תוכנה וחומרה מנוהל, שמרחיב את התשתית והשירותים שלGoogle Cloud למרכז הנתונים שלכם. Google Distributed Cloud זמין גם במודל מחובר וגם במודל Air-gapped, שפועלים בחומרה ש-Google מספקת. Google Distributed Cloud זמין גם כמוצר תוכנה בלבד שפועל על החומרה שלכם. אפשר להתקין את תוכנת Google Distributed Cloud ב-VMware או בשרת פיזי. המדריך הזה מיועד לתוכנת Google Distributed Cloud שפועלת ישירות במכונות פיזיות.
התוכנה של Google Distributed Cloud מבוססת על Google Kubernetes Engine (GKE), עם חבילת Kubernetes משלה שמרחיבה את GKE לשימוש בסביבה מקומית. באמצעות Google Distributed Cloud אתם יכולים ליצור, לנהל ולשדרג אשכולות GKE באתר שלכם, תוך שימוש בתכונות שלGoogle Cloud , וגם לפרוס ולהפעיל אפליקציות בקונטיינרים באשכולות שלכם בקנה מידה נרחב באמצעות התשתית של Google.
למה להשתמש ב-Distributed Cloud software only לשרת פיזי?
הפעלת תוכנת Distributed Cloud רק לשרת פיזי מאפשרת לכם לנצל את התשתית הארגונית הקיימת, ועוזרת לכם לשדרג את האפליקציות לאורך מחזור החיים שלהן.
צומת משלכם (BYON)
בהתקנה של תוכנה בלבד בשרת פיזי של Google Distributed Cloud, אתם פורסים אפליקציות ישירות בתשתית החומרה שלכם, מה שמאפשר לכם ליהנות מהביצועים ומהגמישות הטובים ביותר. יש לכם שליטה ישירה על קנה המידה של האפליקציה, האבטחה וזמן האחזור ברשת. בנוסף, אתם נהנים מהיתרונות של אפליקציות בקונטיינרים באמצעות רכיבי GKE.
ביצועים משופרים ועלות נמוכה יותר
Google Distributed Cloud מנהל את הפריסה והתקינות של האפליקציות במרכזי הנתונים הקיימים של הארגון, כדי לייעל את התפעול. בנוסף, אפשר להריץ קונטיינרים בקצה הרשת, כך שאפליקציות ניתוח יכולות לפעול בביצועים מלאים.
שימוש בתוכנת Distributed Cloud רק ל-bare metal במקום למכונות וירטואליות מאפשר לכם לנהל קונטיינרים של אפליקציות במגוון רחב של סוגי חומרה עם ביצועים אופטימליים, כמו GPUs ו-SSDs. הפעלת תוכנת Distributed Cloud רק לשרת פיזי מאפשרת גם גישה ישירה של האפליקציה לחומרה.
אבטחה תואמת
מכיוון שאתם שולטים בסביבת הצומת, אתם יכולים לבצע אופטימיזציה של הרשת, החומרה והאפליקציות כדי לעמוד בדרישות הספציפיות שלכם. כתוצאה מכך, אתם יכולים לשלוט ישירות באבטחת המערכת, בלי לדאוג לתאימות עם מכונות וירטואליות ומערכות הפעלה.
פריסת אפליקציות במעקב
ב-Google Distributed Cloud יש כלים מתקדמים למעקב אחרי התקינות והביצועים של הסביבה. יכולת המעקב הזו עוזרת להתאים את קנה המידה של האפליקציות תוך שמירה על האמינות, למרות התנודות בעומס העבודה ובתנועה ברשת.
אתם יכולים לנהל את המעקב, הרישום ביומן והניתוח של אשכולות ועומסי עבודה באמצעות Connect Agent.
זמן האחזור של הרשת וגמישות
מכיוון שאתם מנהלים את דרישות הרשת, אתם יכולים לבצע אופטימיזציה של הרשת לזמן אחזור קצר. האופטימיזציה הזו של הרשת יכולה להיות חיונית לביצועים בניתוח נתונים מסחריים או פיננסיים, ובאפליקציות אחרות של ארגונים או של קצה הרשת.
זמינות גבוהה
ב-Google Distributed Cloud יש תמיכה בכמה צומתי מישור בקרה באשכול. אם צומת של מישור הבקרה מושבת, עדיין אפשר לנהל את הסביבה.
תכנון ובקרה מאובטחים
אתם יכולים להתאים אישית את אבטחת התשתית לפי הצרכים שלכם, עם מינימום חיבורים למשאבים חיצוניים. והכי חשוב, אין מורכבות נוספת של מכונות וירטואליות כשפורסים מערכות אבטחה, ואתם שומרים על שליטה מלאה במערכת ההפעלה כשאתם מקיימים אינטראקציה עם מערכות אבטחה קיימות.
Google Distributed Cloud פועל עם חיבורים מאובטחים וקלים ל-Google APIs. אתם יכולים לנהל אשכולות ואפליקציות ממיקום מרכזי באמצעות Connect ו-Cloud Monitoring. הריכוזיות הזו גם עוזרת לשמור על פריסות תקינות, ומאפשרת לצוות התמיכה של Google Cloud לפתור בעיות בצורה יעילה יותר.
בדיקות קדם-הפעלה בהתקנה
ב-Google Distributed Cloud, האשכולות פועלים במערכות Linux בקוד פתוח ובמערכות Linux ארגוניות, ובתשתית חומרה מינימלית, מה שיוצר גמישות בסביבה שלכם. הוא כולל גם בדיקות קדם הפעלה שונות כדי לוודא שההגדרות וההתקנות בוצעו בהצלחה.
פריסת אפליקציות ואיזון עומסים
Google Distributed Cloud כולל מנגנונים לאיזון עומסים בשכבה 4 ובשכבה 7 בזמן יצירת האשכול.
שיפור האמינות של etcd
כדי לעקוב אחרי הגודל ולבצע דפרגמנטציה של מסדי נתונים של etcd, מישורי הבקרה של Google Distributed Cloud כוללים Pod של etcddefrag. ה-Pod של etcddefrag מפנה נפח אחסון ממסדי נתונים גדולים של etcd ומשחזר את etcd כשאין יותר מקום פנוי בדיסק.
איך זה עובד
Google Distributed Cloud מרחיב את Google Kubernetes Engine (GKE) ומאפשר לכם ליצור אשכולות בשרתי Linux מקומיים משלכם. אתם מנהלים את האשכולות המקומיים האלה ב- Google Cloud, יחד עם אשכולות GKE רגילים ואשכולות בסביבות אחרות, כחלק מ-fleet.
אשכולות GKE פועלים ב- Google Cloud , שבו מישור הבקרה של Kubernetes ותשתית הרשת מנוהלים על ידי Google Cloud. מכיוון שאשכולות שנוצרו באמצעות Google Distributed Cloud פועלים במרכז הנתונים שלכם, אנחנו מספקים תוכנה לניהול ולמישור הבקרה בנוסף לתוכנת GKE. התוכנה שפועלת במרכז הנתונים שלכם יורדת כחלק מתהליכי ההתקנה והשדרוג.
התרשים הבא מציג את התוצאה הפשוטה של התקנה שהושלמה:
הרכיבים העיקריים
הרכיבים הבאים מרכיבים התקנה של תוכנה בלבד בשרת פיזי של Google Distributed Cloud:
אשכול האדמין מורכב מצומת אחד או יותר של מישור הבקרה. כל צומת הוא מכונה פיזית שפועלת בה מערכת הפעלה נתמכת של Linux. הפריסה הרגילה כוללת אשכול אדמין שמנהל את מחזור החיים של אשכול משתמש אחד או יותר באמצעות ניהול משאבים ב-Kubernetes (KRM). לכל מכונת צומת בהתקנה יש כתובת IP משלה.
אשכול משתמש הוא המקום שבו פועלים עומסי העבודה שמטמיעים את האפליקציות, כמו ב-GKE ב- Google Cloud. כל אשכול משתמש מורכב מצומת אחד לפחות של מישור הבקרה ומצומת עובד אחד.
תחנת העבודה של האדמין היא מכונה נפרדת (בדרך כלל) שכוללת את הכלים ואת פריטי המידע שנוצרו באשכול, כמו קובצי תצורה. מפתחים ויוצרים של אשכולות משתמשים בכלים ובפריטי המידע שנוצרו בתהליך הפיתוח (artifacts) כדי לנהל את האשכולות המקומיים שלהם, עם ההרשאות המתאימות:
הפעלת
bmctlמתחנת העבודה של האדמין מאפשרת ליצור ולעדכן אשכולות ולבצע משימות ניהוליות אחרות.הפעלת
kubectlמתחנת העבודה של האדמין מאפשרת לכם לנהל אינטראקציה עם אשכולות האדמין והמשתמשים, כולל פריסה וניהול של עומסי עבודה.
GKE On-Prem API הוא ממשק API שמתארח ב- Google Cloudלניהול מחזור החיים של אשכולות. אתם יכולים להשתמש בלקוחות ה-API (Google Cloud מסוף, Google Cloud CLI ו-Terraform) כדי ליצור ולנהל את מחזור החיים של האשכולות המקומיים, במקום להיכנס לתחנת העבודה של האדמין כדי לנהל את האשכולות באמצעות ה-CLI של
bmctl.במסוף יש גם ממשק אינטרנט לפרויקט ב-Google Cloud , כולל אשכולות מקומיים. במסוף מוצגים מדדים מרכזיים לגבי האשכולות, כדי לעזור לכם לעקוב אחרי תקינות האשכולות.
מפתחים ואדמינים של אשכולות משתמשים ב-
kubectlכדי לגשת למישורי הבקרה של האשכולות דרך כתובות IP וירטואליות (VIP) שצוינו כחלק מהגדרת האשכול. משתמשי האפליקציה והמפתחים משתמשים בכתובות VIP של שירות ו-Ingress כדי לגשת לעומסי עבודה ולחשוף אותם, בהתאמה.
מתחברים לצי
כל אשכולות המשתמשים (ואופציונלית גם אשכולות האדמין) הם חברים בfleet: קיבוץ לוגי של אשכולות Kubernetes. בעזרת קבוצות של אשכולות, הארגון יכול לשדרג את הניהול מאשכולות נפרדים לקבוצות שלמות של אשכולות, והצוותים יכולים לאמץ שיטות מומלצות שדומות לאלה שמשתמשים בהן ב-Google. אתם יכולים לראות ולנהל את האשכולות ב-fleet ביחד במסוף Google Cloud , ולהשתמש בתכונות של GKE שמופעלות ב-fleet כדי לנהל, לפקח ולהפעיל את עומסי העבודה בקנה מידה נרחב. כאן תוכלו לראות את הרשימה המלאה של התכונות הזמינות ב-Fleet לסביבות מקומיות.
החיבור של כל אשכול ב-fleet אל Google Cloud מנוהל על ידי Connect Agent, שנפרס כחלק מתהליך ההתקנה של Google Distributed Cloud. ב סקירה הכללית על Connect Agent תוכלו לקרוא מידע נוסף על אופן הפעולה של הסוכן.
החברות ב-Fleet משמשת גם לניהול התמחור של Google Distributed Cloud ב-bare metal, כפי שמתואר בקטע הבא.
תמחור
החיוב על אשכולות מקומיים שנוצרו באמצעות Google Distributed Cloud הוא לפי vCPU. כדי להפעיל את החיוב, צריך להפעיל את Anthos API בפרויקט ב- Google Cloud.
ב מחירון של Google Kubernetes Engine תוכלו לקרוא את כל הפרטים על המחירים, כולל איך לפנות למחלקת המכירות.
גרסאות
למידע על גרסאות של Google Distributed Cloud, קראו את מדיניות התמיכה בגרסאות.
המסמכים האלה כוללים את כל הגרסאות הנתמכות של Google Distributed Cloud. במקרים הרלוונטיים, אנחנו שומרים גם מידע מוגבל על גרסאות ישנות יותר שלא נתמכות במסמכי התיעוד האלה. ההבדלים בדרישות ובהתנהגות בין הגרסאות השונות מצוינים במסמכי התיעוד. באופן דומה, כשפיצ'ר חדש הופך לזמין, הגרסה שנתמכת לפיצ'ר מתועדת.
במאמר ניהול גרסאות מפורטת רשימה של גרסאות המשנה הנתמכות והתיקונים הזמינים.
החל מגרסה 1.29, אנחנו לא יוצרים יותר ספרייה ממוספרת לתיעוד של הגרסה המשנית הקודמת. כדי למצוא את המסמכים של גרסה 1.16 וגרסאות קודמות, צריך להוסיף את מספר הגרסה המשנית לכתובת ה-URL הבאה:
https://cloud.google.com/anthos/clusters/docs/bare-metal/VERSION/
מחליפים את VERSION בגרסה משנית מ-1.6 עד 1.16 ומעתיקים את כתובת ה-URL לסרגל הכתובות בדפדפן.
התקנת תוכנת Distributed Cloud רק לשרת פיזי
מכיוון שאשכולות שנוצרו באמצעות Google Distributed Cloud פועלים בתשתית שלכם, הם ניתנים להגדרה בקלות. אחרי שבוחרים את מודל הפריסה שמתאים לצרכים של הארגון ולתרחיש לדוגמה, אפשר לבחור מתוך מגוון מצבים נתמכים של איזון עומסים, אפשרויות של כתובות IP, תכונות אבטחה, אפשרויות קישוריות ועוד. הגדרת אשכול כוללת קבלת החלטות לפני ההתקנה ובמהלכה. המסמכים האלה כוללים מדריכים שיעזרו לצוות שלכם להחליט אילו תכונות ואפשרויות מתאימות לכם. כדי לוודא שההתקנה עונה על צורכי הארגון, כדאי להתייעץ עם צוותי הרשת והאפליקציות.
איפה הנתונים שלכם שמורים
כשמריצים את תוכנת Distributed Cloud רק ב-bare metal, האשכולות, האפליקציות והנתונים העסקיים נשארים במרכז הנתונים שלכם. כברירת מחדל, Google Distributed Cloud שולח מידע על האשכולות שלכם, כמו ההגדרות, התקינות והשימוש שלהם, אבל לא שולח את נתוני האפליקציה. Google Cloud
נתונים שנשארים במרכז הנתונים שלכם
הנתונים הבאים נשארים במרכז הנתונים:
- קונטיינרים, Pods, PersistentVolumes, קצוות עורפיים של אחסון מקומי והנתונים שהאפליקציות מעבדות.
- מישור הבקרה (
kube-apiserver,kube-schedulerו-kube-controller-manager) ומסד הנתוניםetcd, שבו מאוחסנים כל האובייקטים של Kubernetes. - מפתחות פרטיים של רשויות האישורים (CA), כולל ה-CA של האשכול, ה-CA של
etcdוה-CA של שרת ה-proxy הקדמי. מרחב השמות של אשכול המשתמשים באשכול האדמין מאחסן את רשויות האישורים של אשכול המשתמשים. - סודות של אפליקציות, אסימוני OAuth, מפתחות פרטיים של SSH, פרטי כניסה ל-Container Registry וקובצי מפתחות של חשבונות שירות מאוחסנים ב-
etcdאו בתחנת העבודה של האדמין. הם לא נשלחים ל-GKE On-Prem API, ותמונת המצב של האבחון שמוגדרת כברירת מחדל לא כוללת את פרטי הכניסה לאשכול. - קובץ התצורה של האשכול מאוחסן בתחנת העבודה של האדמין. אם אשכול רשום ב-GKE On-Prem API, חלק מההגדרות נשלחות. מידע נוסף זמין במאמר הנתונים שנשלחים אל Google Cloud.
- יומני הביקורת נכתבים בדיסק רק אם משביתים את Cloud Audit Logs בצמתים של מישור הבקרה.
- אם הגדרתם חשבון שירות להעלאת קובצי תמונת מצב לאבחון, הקובץ יועלה ל-Cloud Storage. אתם יכולים לבחור אם לשתף את תמונת המצב עם Cloud Customer Care.
הנתונים שנשלחים אל Google Cloud
בטבלה הבאה מפורט מה נשלח, איך משתמשים במידע הזה ואיפה הוא נשמר, ואם אפשר להשבית את השליחה שלו:
| נתונים | אילו נתונים נשלחים? | שימוש ואחסון | ברירת מחדל |
|---|---|---|---|
| חיבור ורישום של Fleet ( gkehub.googleapis.com,
gkeconnect.googleapis.com) |
|
ניהול אשכולות ממסוףGoogle Cloud , משער הקישור ומ-Fleet באמצעות Connect Agent. | חובה |
| הגדרות וסטטוס של אשכול ( gkeonprem.googleapis.com) |
|
מאפשר לנהל אשכולות באמצעות מסוף Google Cloud , Google Cloud CLI או Terraform. מאוחסנים על ידי GKE On-Prem API באזור שמוגדר ב-gkeOnPremAPI.location, שמוגדר כברירת מחדל ל-clusterOperations.location. |
מופעל בגרסה 1.16 ואילך, אם GKE On-Prem API מופעל בפרויקט Google Cloud . כדי להשבית אותה, מגדירים את gkeOnPremAPI.enabled לערך false. |
| שימוש בחיוב ( anthos.googleapis.com) |
קיבולת ה-vCPU, מספר הצמתים וסטטוס הזכאות לרישיון. | משמש למדידה, לחיוב ולבדיקות רישוי. | חובה. רשומות החיוב נשמרות במאגר זמני במהלך הפסקה בשירות ונשלחות מאוחר יותר. |
| נתוני בריאות וכושר של המערכת ( logging.googleapis.com, monitoring.googleapis.com,
opsconfigmonitoring.googleapis.com) |
|
משמש ל-Cloud Monitoring, לתצוגות סטטוס במסוף Google Cloud ולפתרון בעיות ב-Customer Care. מאוחסנים בפרויקט Google Cloud שמוגדר ב-clusterOperations.projectID. המדדים מאוחסנים באזור שמוגדר ב-clusterOperations.location, והיומנים מאוחסנים בהתאם להגדרות של נתב היומנים. |
מופעל ליומני מערכת ולמדדים, שנדרשים לתמיכה מלאה של שירות לקוחות ולכיסוי SLA. מושבת ליומנים ולמדדים של האפליקציה, אלא אם מגדירים את enableCloudLoggingForApplications או את enableGMPForApplications לערך true במשאב Stackdriver. |
| יומני ביקורת ( anthosaudit.googleapis.com) |
יומני הביקורת Admin Activity (audit-proxy): מי שינה מה באמצעות kube-apiserver ומתי. הרשומות כוללות את השעה, האשכול, המארח או ה-VM, המשתמש או חשבון השירות, תפקיד ה-RBAC, הפעולה והתוצאה. בקשות הקריאה לא נשמרות. |
הנתונים נשמרים ביומני הביקורת של Cloud בפרויקט ב- Google Cloud , בקטגוריה _Required, למשך 400 ימים. |
מופעל. כדי להשבית אותה, מגדירים את clusterOperations.disableCloudAuditLogging לערך true.
יומני הביקורת נשמרים רק בדיסקים של צומתי מישור הבקרה. |
המאמרים הבאים
כדי להתחיל להשתמש ב-Google Distributed Cloud, תוכלו להיעזר במדריכים הבאים:
- יצירת אשכולות אדמין ואשכולות משתמשים לדוגמה ב-Google Distributed Cloud במכונות וירטואליות של Compute Engine
- תכנון התקנה בסיסית בחומרה
- יצירת אשכולות בסיסיים בחומרה שלכם