בעיות מוכרות

היקף הסביבה והיכולות של Google Distributed Cloud (GDC) Sandbox:

  • עקביות: סביבת GDC Sandbox לא עקבית, והיא מתרעננת בהדרגה מדי חודש. כשמבצעים רענון של סביבות, הן חוזרות למצב ברירת מחדל, כלומר צריך לפרוס מחדש את ההגדרות. מומלץ לשמור את ההגדרות, הקוד והקונטיינרים במאגר המקורות של הקוד, שמאפשר גם פיתוח מסביבות נמוכות לסביבות ייצור.
  • משאבים: במהדורה הזו יש הגבלה על הכמות של המשאבים הבאים:
    • ארגון אחד.
    • דייר אחד.
    • שני אשכולות Kubernetes.
  • משתמשים: כדי להבטיח שימוש הולם במשאבים משותפים, מספר המשתמשים מוגבל ל-25 לכל היותר.
  • מידע אישי רגיש: המשתמשים צריכים להסכים לתנאי השימוש לפני שהם ניגשים לארגז החול של GDC. אנחנו ממליצים לא להשתמש ב-GDC Sandbox למידע אישי רגיש או לעומסי עבודה של ייצור, כי הוא מיועד למטרות בדיקה, פיתוח ואימון.
  • חוויית IO: ארגז החול של GDC תומך רק ב-Application Operator (AO) או בחוויית Persona של משתמש הקצה בארגז החול של GDC.

בעיות מוכרות:

  1. מצב מדיניות הרשת של הפרויקט תמיד מוצג כ-Not Read בממשק המשתמש, בלי קשר לסטטוס שלו. כדי לבדוק את הסטטוס האמיתי, צריך להשתמש ב-API או ב-CLI.
  2. אם עדיין לא ביצעתם את השלבים שמפורטים במאמר בנושא גישה לסביבה כדי להתקין אישורים, תופיע השגיאה הבאה בזמן העלאת קובץ לקטגוריה (אחסון אובייקטים): Check network speed to ensure your file size is within limits and certificates are properly set. אפשר להתקין את האישורים או לפעול לפי הפתרון העקיף הבא:

    1. בדפדפן בארגז החול של GDC, פותחים את דף האינטרנט https://objectstorage.org-1.zone1.google.gdch.test ומאשרים את האישור.
    2. כדאי לנסות להעלות את הקובץ שוב.
    3. אם הבעיה נמשכת, כמו ErrPresignSignatureNotRecognized, אפשר לנסות להשבית את אימות ה-TLS באמצעות gdcloud config set storage/s3_insecure_skip_tls_verify true.
  3. פסק זמן להתחברות: יכול להיות שפסק הזמן לאימות יחול גם בממשק המשתמש וגם ב-CLI אם לא ניגשים לסביבה במשך כמה דקות.

    1. אם חלף הזמן הקצוב לתגובה של ממשק המשתמש: מוחקים את המטמון של הדפדפן ומרעננים את הדפדפן.
    2. אם חלף הזמן הקצוב לתפוגה ב-gdcloud: נכנסים שוב לחשבון. איך מתחברים למכונה
  4. standard-rwo: ReadWriteOnce הוא סוג האחסון היחיד שנתמך ביצירת אובייקטים של PersistentVolumeClaim. אין תמיכה במחלקת האחסון standard-rwx: ReadWriteMany.

  5. אחרי שמגדירים את auth/login_config_cert_path באמצעות gdcloud config set, הערך לא מוגדר אחרי שמריצים את gdcloud auth login. הפתרון הזמני לבעיה הזו הוא להוסיף תמיד את --login-config-cert=/tmp/org-1-web-tls-ca.cert כשמריצים את gdcloud auth login.

  6. אי אפשר להפעיל את Chrome אחרי כניסה ל-RDP. אפשר לנסות את הפתרון הבא:

    1. הסרה של ~/.local/share/keyrings
    2. מפעילים את Chrome באמצעות הפקודה:
    /opt/google/chrome/google-chrome --password-store=basic
    
  7. אם תפקיד האדמין ב-IAM של הארגון יוסר מהמשתמש fop-platform-admin@example.com, לא ניתן יהיה להקצות מחדש את התפקיד והמשתמש יאבד את הגישה לרוב התכונות. במקרה כזה, צריך לפנות לתמיכה של GDC Sandbox.

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

    docker images prune -a
    docker volumes prune
    docker containers prune
    
  9. ניסיונות להתחבר למכונה הווירטואלית (VM) באמצעות gcloud compute ssh ייכשלו. במקום זאת, משתמשים ב-sshuttle כמו שמתואר במאמר התחברות למכונה וירטואלית.

  10. אם האימות של חשבון השירות נכשל עם dial tcp: lookup service-accounts.org-1.google.gdch.test on with no such host, צריך לשנות את token_uri ל-https://service-accounts.org-1.zone1.google.gdch.test/authenticate ב-KEY_FILE עם פרטי הכניסה שמוגדרים כברירת מחדל לאפליקציה.

  11. המארחים של ה-GPU שומרים על בידוד ארכיטקטוני משאר המערכת האקולוגית. שירותים במישור הנתונים (כמו DBS ואחסון אובייקטים) ומכונות וירטואליות לשימוש כללי מוחרגים במפורש מהגישה למשאבים שבהם פועלות עומסי העבודה של ה-GPU.