יצירת אשכולות היברידיים

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

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

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

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

אתם יוצרים אשכול היברידי עם מישור בקרה של זמינות גבוהה (HA) באמצעות הפקודה bmctl. אפשר להריץ את הפקודה bmctl בתחנת עבודה נפרדת או באחד מצמתי האשכול ההיברידי.

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

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

במדריך למתחילים בנושא Google Distributed Cloud מופיעות הוראות מפורטות ליצירת אשכול היברידי.

הפעלת SELinux

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

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

מתחברים ל-gcloud ויוצרים קובץ הגדרות של אשכול

1. מתחברים ל-CLI של gcloud כמשתמש באמצעות gcloud auth application-default login:

   gcloud auth application-default login
   

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

   אפשר גם להוסיף למשתמש את תפקידי ה-IAM הבאים:

   • אדמין בחשבון שירות
   • אדמין של מפתח לחשבון שירות
   • אדמין IAM של פרויקט
   • צפייה ב-Compute
   • אדמין של שימוש בשירות

   לחלופין, אם כבר יש לכם חשבון שירות עם התפקידים האלה, מריצים את הפקודה:

   export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
   

   מחליפים את JSON_KEY_FILE בנתיב של קובץ מפתח ה-JSON של חשבון השירות.

2. כדי ליצור אשכול, צריך להשיג את Google Cloud מזהה הפרויקט:

   export CLOUD_PROJECT_ID=$(gcloud config get-value project)
   

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

אחרי שמתחברים ל-CLI של gcloud ומגדירים את הפרויקט, אפשר ליצור את קובץ התצורה של האשכול באמצעות הפקודה bmctl.

כדי ליצור קובץ תצורה של אשכול:

1. מריצים את הפקודה הבאה כדי ליצור את קובץ התצורה של האשכול, ליצור את כל חשבונות השירות הנדרשים ולהפעיל את כל ממשקי ה-API הנדרשים:

   bmctl create config -c CLUSTER_NAME</var> --enable-apis \
       --create-service-accounts --project-id=CLOUD_PROJECT_ID
   

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

   • ‫CLUSTER_NAME: השם של האשכול שאתם יוצרים.
   • ‫CLOUD_PROJECT_ID: מזהה הפרויקט ב- Google Cloud .

   כברירת מחדל, קובץ התצורה נכתב בנתיב bmctl-workspace/CLUSTER_NAME/CLUSTER_NAME.yaml.

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

   מידע נוסף על אפשרויות הפקודה זמין במאמר בנושא יצירת קובץ הגדרה.

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

אחרי שיצרתם קובץ תצורה של אשכול, עורכים אותו כדי לבצע את השינויים הבאים:

1. מזינים את המפתח הפרטי של SSH כדי לגשת לצמתים של האשכול ההיברידי:

   # bmctl configuration variables. Because this section is valid YAML but not a valid Kubernetes
   # resource, this section can only be included when using bmctl to
   # create the initial admin/hybrid cluster. Afterwards, when creating user clusters by directly
   # applying the cluster and node pool resources to the existing cluster, you must remove this
   # section.
   gcrKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-gcr.json
   sshPrivateKeyPath: /path/to/your/ssh_private_key
   gkeConnectAgentServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-connect.json
   gkeConnectRegisterServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-register.json
   cloudOperationsServiceAccountKeyPath: bmctl-workspace/.sa-keys/my-gcp-project-anthos-baremetal-cloud-ops.json
   

2. רושמים את האשכולות ב-Fleet. מזהה הפרויקט שציינתם בפקודה bmctl create config נוסף אוטומטית לשדה gkeConnect.projectID בקובץ ההגדרה של האשכול. הפרויקט הזה נקרא פרויקט המארח של ה-Fleet.

   • אם יצרתם את קובץ התצורה באמצעות התכונות של הפעלת API אוטומטית ויצירת חשבון שירות, אתם יכולים לדלג על השלב הזה.
   • אם יצרתם את קובץ התצורה בלי להשתמש בתכונות של הפעלת API אוטומטית ויצירת חשבון שירות, צריך להפנות למפתחות ה-JSON של חשבון השירות שהורדתם בשדות gkeConnectAgentServiceAccountKeyPath ו-gkeConnectRegisterServiceAccountKeyPath המתאימים בקובץ התצורה של האשכול.

3. משנים את ההגדרה כך שמציינים סוג אשכול של hybrid במקום 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: hybrid
   

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

     # Control plane configuration
     controlPlane:
       nodePoolSpec:
         nodes:
         # Control plane node pools. Typically, this is either a single machine
         # or 3 machines if using a high availability deployment.
         - address: 10.200.0.4
         - address: 10.200.0.5
         - address: 10.200.0.6
   

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

5. מציינים את צפיפות ה-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: 250
   ....
   

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

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

יצירת האשכול ההיברידי באמצעות הגדרות האשכול

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

bmctl create cluster -c CLUSTER_NAME

מחליפים את CLUSTER_NAME בשם שבו השתמשתם כשיצרתם את קובץ התצורה של האשכול בקטע הקודם.

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

bmctl create cluster -c hybrid1

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

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