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

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

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

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

לפני שיוצרים אשכול נפרד, צריך לוודא את הדברים הבאים:

• הגרסה האחרונה של bmctl (gs://anthos-baremetal-release/bmctl/1.36.200-gke.118/linux-amd64/bmctl) יורדת מ-Cloud Storage.
• לתחנת העבודה שבה פועל bmctl יש קישוריות רשת לכל הצמתים באשכול העצמאי (standalone) המיועד.
• תחנת עבודה שפועלת בה bmctl עם קישוריות רשת ל-VIP של מישור הבקרה של אשכול היעד העצמאי.
• מפתח ה-SSH שמשמש ליצירת האשכול העצמאי זמין ל-root, או שיש גישת משתמש SUDO בכל הצמתים באשכול העצמאי המיועד.
• חשבון השירות 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.

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

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

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

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

התחברות אל gcloud

1. התחברות אל gcloud כמשתמש:

   gcloud auth application-default login
   

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

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

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

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

   export GOOGLE_APPLICATION_CREDENTIALS=JSON_KEY_FILE
   

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

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

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

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

קובץ תצורה

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

bmctl create config -c STANDALONE_CLUSTER_NAME --enable-apis \
    --create-service-accounts --project-id=$CLOUD_PROJECT_ID

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

• ‫STANDALONE_CLUSTER_NAME בשם של האשכול העצמאי שרוצים ליצור.

דוגמה

הפקודה הבאה יוצרת קובץ תצורה לאשכול עצמאי בשם standalone1 שמשויך למזהה הפרויקט my-gcp-project:

bmctl create config -c standalone1 --create-service-accounts --project-id=my-gcp-project

הקובץ נכתב ב-bmctl-workspace/standalone1/standalone1.yaml.

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

bmctl create config -c standalone1

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

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

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. משנים את ההגדרה כדי לציין סוג אשכול של standalone במקום admin. כדי להפעיל את פרופיל הקצה (edge) ולצמצם את צריכת המשאבים, צריך לציין את הערך profile: edge:

   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: standalone
     # Edge profile minimizes the resource consumption of Google Distributed Cloud. It is only available for standalone clusters.
     profile: edge
   

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. בקובץ התצורה של האשכול, ממלאים או עורכים את פרטי הרשת של האשכול:

   • ‫clusterNetwork.pods.cidrBlocks: טווח של כתובות IP בסימון בלוק CIDR לשימוש על ידי Pods. הערך ההתחלתי המומלץ, שממולא מראש בקובץ התצורה של האשכול שנוצר, הוא 192.168.0.0/16.

   • ‫clusterNetwork.services.cidrBlocks: טווח של כתובות IP בסימון בלוק CIDR לשימוש על ידי השירות. ערך ההתחלה המומלץ, שממולא מראש בקובץ התצורה של האשכול שנוצר, הוא 10.96.0.0/20.

   • ‫loadBalancer.vips.controlPlaneVIP: כתובת ה-IP הווירטואלית (VIP) של שרת ה-API של Kubernetes באשכול.

   • ‫loadBalancer.vips.ingressVIP: כתובת ה-VIP שמשמשת ככתובת החיצונית של שרת ה-proxy של Ingress.

   • ‫loadBalancer.addressPools.addresses:: טווח של עשר כתובות IP לשימוש ככתובות IP חיצוניות לשירותים מסוג LoadBalancer. שימו לב שהטווח הזה כולל את ה-VIP של הכניסה, שנדרש על ידי MetalLB. כתובות IP אחרות לא יכולות לחפוף לטווח הזה.

6. מציינים את צפיפות ה-Pod של צומתי האשכול:

   ....
   # 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. ערך ברירת המחדל אם לא צוין ערך הוא 110. אחרי שיוצרים את האשכול, אי אפשר לעדכן את הערך הזה.

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

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

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

bmctl create cluster -c CLUSTER_NAME

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

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

bmctl create cluster -c standalone1

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

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