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

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

• ברירת מחדל: לפרופיל ברירת המחדל יש דרישות מוגבלות של משאבים.
• ‫Edge: פרופיל ה-Edge דורש הרבה פחות משאבי מערכת, ולכן מומלץ למכשירי Edge עם מגבלות משאבים גבוהות.

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

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

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

• הגרסה האחרונה של 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.

הפעלת 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, צריך לציין לפחות שלושה צמתים למישור הבקרה.

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

מתחברים אל gcloud

1. מתחברים אל gcloud בתור משתמש:

   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)
   

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

אחרי שנכנסים ל-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 block לשימוש ב-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 של תעבורת הכניסה.

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

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

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

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

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

bmctl create cluster -c CLUSTER_NAME

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

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

bmctl create cluster -c standalone1

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

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