יצירת אשכולות משתמשים

ב-Google Distributed Cloud, אשכולות משתמשים מריצים את עומסי העבודה, ובארכיטקטורה של כמה אשכולות, אשכולות משתמשים נוצרים ומנוהלים על ידי אשכול אדמין.

אחרי שיוצרים אשכול אדמין, הפעלת הפקודה bmctl create config יוצרת קובץ YAML שאפשר לערוך כדי להגדיר את אשכול המשתמשים. כדי להחיל את ההגדרה וליצור את אשכול המשתמשים, משתמשים בפקודה bmctl create cluster. בדיקות קדם-הפעלה רלוונטיות לאשכולות משתמשים שנוצרו באמצעות הפקודה bmctl create cluster.

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

דרישות מוקדמות

• הגרסה האחרונה של bmctl מורדת (gs://anthos-baremetal-release/bmctl/1.34.100-gke.93/linux-amd64/bmctl) מ-Cloud Storage.
• אשכול ניהול פעיל עם גישה לשרת ה-API של האשכול (controlPlaneVIP).
• לצמתים של אשכול האדמין יש קישוריות רשת לכל הצמתים באשכול המשתמשים של היעד.
• תחנת עבודה שמופעלת בה bmctl כוללת קישוריות לרשת לכל הצמתים באשכולות המשתמשים של היעד.
• תחנת העבודה של האדמין יכולה ליצור חיבור SSH לכל אחד מצמתי אשכול המשתמשים.
• חשבון השירות Connect-register מוגדר באשכול האדמין לשימוש ב-Connect.

הפעלת SELinux

אם רוצים להפעיל את SELinux כדי לאבטח את הקונטיינרים, צריך לוודא ש-SELinux מופעל במצב Enforced בכל המכונות המארחות. החל מגרסה 1.9.0 ואילך של Google Distributed Cloud, אפשר להפעיל או להשבית את SELinux לפני או אחרי יצירת אשכולות או שדרוגים של אשכולות. ‫SELinux מופעל כברירת מחדל ב-Red Hat Enterprise Linux ‏ (RHEL). אם SELinux מושבת במכונות המארחות שלכם או שאתם לא בטוחים, תוכלו לקרוא את המאמר אבטחת הקונטיינרים באמצעות SELinux כדי לקבל הוראות להפעלה שלו.

‫Google Distributed Cloud תומך ב-SELinux רק במערכות RHEL.

יצירת קובץ תצורה של אשכול משתמשים

קובץ התצורה ליצירת אשכול משתמשים כמעט זהה לקובץ שמשמש ליצירת אשכול אדמינים. ההבדל היחיד הוא שצריך להסיר את הקטע של הגדרת פרטי הכניסה המקומיים כדי שההגדרה תהיה אוסף תקין של משאבי Kubernetes. קטע ההגדרה נמצא בחלק העליון של הקובץ, בקטע bmctl configuration variables. דוגמאות להגדרות של אשכולות משתמשים מופיעות במאמר אשכולות משתמשים בדוגמאות להגדרת אשכולות.

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

1. יוצרים קובץ תצורה של אשכול משתמשים באמצעות הפקודה bmctl create config:

   bmctl create config -c USER_CLUSTER_NAME
   

   לדוגמה, מריצים את הפקודה הבאה כדי ליצור קובץ תצורה לאשכול משתמשים בשם user1:

   bmctl create config -c user1
   

   הקובץ נכתב בנתיב bmctl-workspace/user1/user1.yaml. הנתיב הגנרי לקובץ הוא bmctl-workspace/CLUSTER NAME/CLUSTER_NAME.yaml.

2. עורכים את קובץ התצורה עם השינויים הבאים:

   • מסירים את הנתיבים של קובץ פרטי הכניסה המקומי מההגדרה:

     ...
       gcrKeyPath: (path to Artifact Registry service account key)
       sshPrivateKeyPath: (path to SSH private key, used for node access)
       gkeConnectAgentServiceAccountKeyPath: (path to Connect agent service account key)
       gkeConnectRegisterServiceAccountKeyPath: (path to Hub registration service account key)
       cloudOperationsServiceAccountKeyPath: (path to Cloud Operations service account key)
     ...
     

   • משנים את ההגדרה כך שמציינים סוג אשכול של user במקום admin:

     ...
     spec:
       # Cluster type. This can be:
       #   1) admin:  to create an admin cluster. This can later be used to create
       #   user clusters.
       #   2) user:   to create a user cluster. Requires an existing admin cluster.
       #   3) hybrid: to create a hybrid cluster that runs admin cluster
       #   components and user workloads.
       #   4) standalone: to create a cluster that manages itself, runs user
       #   workloads, but does not manage other clusters.
       type: user
     ...
     

   • כדי לרשום את האשכולות ל-Fleet, מציינים את מזהה הפרויקט בשדה gkeConnect.projectID. הפרויקט הזה נקרא פרויקט המארח של ה-Fleet.

     ...
     gkeConnect:
        projectID: my-project-123
     ...
     

     • אפשר גם להוסיף את הדגל gkeConnect.location למפרט האשכול כדי לציין את האזור Google Cloud שבו פועלים שירותי Fleet ו-Connect. חברות אזורית כזו מגבילה את התנועה של שירותי צי הרכב לאזור שלכם. אם כוללים את gkeConnect.location במפרט האשכול, האזור שמציינים צריך להיות זהה לאזור שהוגדר ב-clusterOperations.location. אם האזורים לא זהים, יצירת האשכול תיכשל.

   • אם GKE On-Prem API מופעל בפרויקטGoogle Cloud , כל האשכולות בפרויקט נרשמים ל-GKE On-Prem API באופן אוטומטי באזור שהוגדר ב-clusterOperations.location.

     • אם רוצים לרשום את כל האשכולות בפרויקט ל-GKE On-Prem API, צריך לבצע את השלבים שבקטע לפני שמתחילים כדי להפעיל את GKE On-Prem API בפרויקט ולהשתמש בו.

     • אם לא רוצים לרשום את האשכול ל-GKE On-Prem API, צריך לכלול את הקטע הזה ולהגדיר את gkeOnPremAPI.enabled ל-false. אם לא רוצים לרשום אף אשכול בפרויקט, צריך להשבית את gkeonprem.googleapis.com (שם השירות של GKE On-Prem API) בפרויקט. הוראות מפורטות מופיעות במאמר השבתת שירותים.

   • מציינים את כתובת ה-IP של צומת מישור הבקרה.

     ...
     # Sample control plane config
     controlPlane:
      nodePoolSpec:
        nodes:
        - address: 10.200.0.20
     ...
     

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

     ...
     # Sample admin cluster config for load balancer and address pools
       loadBalancer:
         vips:
           controlPlaneVIP: 10.200.0.49
           ingressVIP: 10.200.0.50
         addressPools:
         - name: pool1
           addresses:
           - 10.200.0.50-10.200.0.70
     ...
     ...
     # Sample user cluster config for load balancer and address pools
     loadBalancer:
         vips:
           controlPlaneVIP: 10.200.0.71
           ingressVIP: 10.200.0.72
         addressPools:
         - name: pool1
           addresses:
           - 10.200.0.72-10.200.0.90
     ...
     

     שאר קובצי ההגדרות של אשכול המשתמשים זהים לקובץ ההגדרות של אשכול האדמין.

   • מציינים את צפיפות ה-Pods של צמתי האשכול:

     ...
     # NodeConfig specifies the configuration that applies to all nodes in the cluster.
     nodeConfig:
       # podDensity specifies the pod density configuration.
       podDensity:
         # maxPodsPerNode specifies at most how many pods can be run on a single node.
         maxPodsPerNode: 110
     ...
     

     במקרה של אשכולות משתמשים, הערכים המותרים לפרמטר maxPodsPerNode הם 32-250. ערך ברירת המחדל אם לא צוין הוא 110. אחרי שיוצרים את האשכול, אי אפשר לעדכן את הערך הזה.

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

יצירת אשכול המשתמשים

מריצים את הפקודה bmctl כדי להחיל את ההגדרה של אשכול המשתמשים וליצור את האשכול:

bmctl create cluster -c USER_CLUSTER_NAME --kubeconfig ADMIN_KUBECONFIG

מחליפים את מה שכתוב בשדות הבאים:

• ‫USER_CLUSTER_NAME: שם האשכול שנוצר בקטע הקודם.
• ‫ADMIN_KUBECONFIG: הנתיב לקובץ kubeconfig של אשכול האדמין.

לדוגמה, אם שם אשכול המשתמשים הוא user1 וקובץ ה-kubeconfig של אשכול האדמין נמצא בנתיב kubeconfig bmctl-workspace/admin/admin-kubeconfig, הפקודה תהיה:

bmctl create cluster -c user1 --kubeconfig bmctl-workspace/admin/admin-kubeconfig

דוגמאות להגדרות של אשכול משתמשים

דוגמאות להגדרות של אשכולות משתמשים מופיעות במאמר אשכולות משתמשים בדוגמאות להגדרות של אשכולות.