פריסת עומסי עבודה

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

לפני שמבצעים את השלבים האלה, צריך לעמוד בדרישות של התקנה מקושרת של Distributed Cloud ולהזמין את החומרה של Distributed Cloud.

כשציוד Google Distributed Cloud במודל מחובר מגיע ליעד שבחרתם, הוא מוגדר מראש עם חומרה, Google Cloudוחלק מהגדרות הרשת שציינתם כשביצעתם הזמנה של Distributed Cloud במודל מחובר.

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

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

סקירה כללית על הפריסה

כדי לפרוס עומס עבודה בחומרה המחוברת ל-Distributed Cloud, צריך לבצע את השלבים הבאים:

  1. אופציונלי: מפעילים את Distributed Cloud Edge Network API.

  2. אופציונלי: מא初始化 את הגדרת הרשת של האזור המחובר של Distributed Cloud.

  3. אופציונלי: הגדרת רשתות של Distributed Cloud.

  4. יצירת אשכול מחובר של Distributed Cloud.

  5. אופציונלי: מפעילים תמיכה במפתחות הצפנה בניהול הלקוח (CMEK) לאחסון מקומי אם רוצים לשלב עם Cloud Key Management Service כדי להפעיל תמיכה ב-CMEK לנתוני עומס העבודה. מידע על הצפנת נתוני עומס העבודה ב-Distributed Cloud Connected זמין במאמר אבטחת אחסון מקומי.

  6. יצירת מאגר צמתים בשלב הזה, מקצים צמתים למאגר צמתים, ואפשר גם להגדיר את מאגר הצמתים לשימוש ב-Cloud KMS כדי לעטוף ולבטל את העטיפה של ביטוי הגישה של Linux Unified Key Setup‏ (LUKS) להצפנת נתוני עומס העבודה.

  7. קבלת פרטי כניסה לאשכול כדי לבדוק את האשכול.

  8. כדי לתת למשתמשים גישה לאשכול, צריך להקצות להם את התפקיד Edge Container Viewer ‏(roles/edgecontainer.viewer) או את התפקיד Edge Container Admin ‏(roles/edgecontainer.admin) בפרויקט.

  9. מקצים למשתמשים גישה פרטנית מבוססת-תפקידים למשאבי האשכול באמצעות RoleBinding ו-ClusterRoleBinding.

  10. אופציונלי: מפעילים את התמיכה ב-VM Runtime ב-Google Distributed Cloud כדי להריץ עומסי עבודה במכונות וירטואליות ב-Distributed Cloud במודל מחובר.

  11. אופציונלי: הפעלת תמיכה ב-GPU כדי להריץ עומסי עבודה מבוססי-GPU ב-Distributed Cloud Connected.

פריסת מאזן העומסים NGINX כשירות

בדוגמה הבאה מוצג איך לפרוס את שרת NGINX ולחשוף אותו כשירות באשכול מחובר של Distributed Cloud:

  1. יוצרים קובץ YAML בשם nginx-deployment.yaml עם התוכן הבא:

    apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
labels:
  app: nginx
spec:
replicas: 1
selector:
  matchLabels:
     app: nginx
template:
  metadata:
     labels:
     app: nginx
  spec:
     containers:
     - name: nginx
     image: nginx:latest
     ports:
     - containerPort: 80

  2. מחילים את קובץ ה-YAML על האשכול באמצעות הפקודה הבאה:

    kubectl apply -f nginx-deployment.yaml

  3. יוצרים קובץ YAML בשם nginx-service.yaml עם התוכן הבא:

    apiVersion: v1
kind: Service
metadata:
name: nginx-service
spec:
type: LoadBalancer
selector:
  app: nginx
  ports:
     - protocol: TCP
       port: 8080
       targetPort: 80

  4. מחילים את קובץ ה-YAML על האשכול באמצעות הפקודה הבאה:

    kubectl apply -f nginx-deployment.yaml

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

    kubectl get services

    הפקודה מחזירה פלט שדומה לזה:

    NAME            TYPE           CLUSTER-IP     EXTERNAL-IP     PORT(S)          AGE
nginx-service   LoadBalancer   10.51.195.25   10.100.68.104   8080:31966/TCP   11d

הגדרת המשאבים NodeSystemConfigUpdate

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

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

    kubectl get nodes | grep -v master

    הפקודה מחזירה פלט שדומה לזה:

    NAME                                 STATUS   ROLES       AGE     VERSION
pool-example-node-1-01-b2d82cc7      Ready    <none>      2d      v1.22.8-gke.200
pool-example-node-1-02-52ddvfc9      Ready    <none>      2d      v1.22.8-gke.200

    רושמים את שמות הצמתים שהוחזרו וגוזרים מהם את השמות המקוצרים. לדוגמה, השם המקוצר של הצומת pool-example-node-1-01-b2d82cc7 הוא node101.

  2. לכל צומת שהקלטתם בשלב הקודם, יוצרים קובץ משאב ייעודי NodeSystemConfigUpdate עם התוכן הבא:

    apiVersion: networking.gke.io/v1
kind: NodeSystemConfigUpdate
metadata:
name: nodesystemconfigupdate-NODE_SHORT_NAME
namespace: nf-operator
spec:
kubeletConfig:
  cpuManagerPolicy: Static
  topologyManagerPolicy: SingleNumaNode
nodeName: NODE_NAME
osConfig:
  hugePagesConfig:
     ONE_GB: 2
     TWO_MB: 0
  isolatedCpusPerSocket:
     "0": 40
     "1": 40
sysctls:
  nodeLevel:
     net.core.rmem_max: "8388608"
     net.core.wmem_max: "8388608"

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

    • ‫NODE_NAME: השם המלא של צומת היעד. לדוגמה, pool-example-node-1-01-b2d82cc7.
    • ‫NODE_SHORT_NAME: השם המקוצר של צומת היעד, שנגזר מהשם המלא שלו. לדוגמה, node101.

    נותנים לכל קובץ שם node-system-config-update-NODE_SHORT_NAME.yaml.

  3. מחילים כל אחד מקובצי המשאבים NodeSystemConfigUpdate על האשכול באמצעות הפקודה הבאה:

    kubectl apply -f node-system-config-update-NODE_SHORT_NAME.yaml

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

    כשמחילים את המשאבים על האשכול, כל צומת מושפע מופעל מחדש, וזה יכול לקחת עד 30 דקות.

    1. עוקבים אחרי הסטטוס של הצמתים המושפעים עד שכולם מופעלים מחדש בהצלחה:
    kubectl get nodes | grep -v master

    הסטטוס של כל צומת משתנה מ-not-ready ל-ready כשההפעלה מחדש מסתיימת.

הגדרת Pod לשמירת תמונות במטמון

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

הגדרת ה-Pod צריכה לעמוד בדרישות המוקדמות הבאות:

  • חובה להגדיר את התווית gdce.baremetal.cluster.gke.io/cache-image: true ב-Pod.
  • אם אתם משתמשים במאגר תמונות פרטי, המשאב ImagePullSecret צריך להיות מסוג kubernetes.io/dockerconfigjson.
  • כדי להבטיח שתמיד נעשה שימוש בעותק במטמון של תמונת היעד, צריך להגדיר את מדיניות המשיכה של ה-Pod ל-IfNotPresent. אם עותק שמור במטמון לא זמין באופן מקומי, התמונה נשלפת מהמאגר.

בדוגמה הבאה מוצגת הגדרת Pod עם הפעלת שמירת נתונים במטמון:

apiVersion: v1
kind: Pod
metadata:
  name: cached-image-pod
  labels:
    gdce.baremetal.cluster.gke.io/cache-image: "true"
spec:
  containers:
    - name: my-container
      image: your-private-image-repo/your-image:tag
      imagePullPolicy: IfNotPresent
  imagePullSecrets:
    - name: my-image-secret  # If using a private registry

בדוגמה הבאה מוצגת הגדרת פריסה עם הפעלת שמירת נתונים במטמון:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cached-image-deployment
spec:
  template:
    metadata:
      labels:
        gdce.baremetal.cluster.gke.io/cache-image: "true"
    spec:
      containers:
        - name: my-container
          image: your-private-image-repo/your-image:tag
          imagePullPolicy: IfNotPresent
      imagePullSecrets:
        - name: my-image-secret  # If using a private registry

מגבלות של עומסי עבודה ב-Distributed Cloud

כשמגדירים את עומסי העבודה המחוברים של Distributed Cloud, צריך לפעול בהתאם למגבלות שמתוארות בקטע הזה. המגבלות האלה נאכפות על ידי Distributed Cloud connected בכל עומסי העבודה שאתם פורסים בציוד שלכם ב-Distributed Cloud connected.

מגבלות על עומסי עבודה ב-Linux

ב-Distributed Cloud במודל מחובר יש תמיכה רק ביכולות הבאות של Linux עבור עומסי עבודה:

  • AUDIT_READ
  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
  • FOWNER
  • FSETID
  • IPC_LOCK
  • IPC_OWNER
  • KILL
  • MKNOD
  • NET_ADMIN
  • NET_BIND_SERVICE
  • NET_RAW
  • SETFCAP
  • SETGID
  • SETPCAP
  • SETUID
  • SYS_CHROOT
  • SYS_NICE
  • SYS_PACCT
  • SYS_PTRACE
  • SYS_RESOURCE
  • SYS_TIME

הגבלות על מרחבי שמות

‫Google Distributed Cloud במודל מחובר לא תומך במרחבי השמות הבאים:

  • hostPID
  • hostIPC
  • hostNetwork

הגבלות על סוגי משאבים

‫Distributed Cloud Connected לא תומך בסוג המשאב CertificateSigningRequest, שמאפשר ללקוח לבקש הנפקה של אישור X.509 על סמך בקשת חתימה.

הגבלות על הקשר האבטחתי

‫Distributed Cloud connected לא תומך בהקשר האבטחה של מצב הרשאות.

הגבלות על שיוך של Pod

‫Distributed Cloud connected לא תומך באיגוד של Pods ליציאות של מארחים במרחב השמות HostNetwork. בנוסף, מרחב השמות HostNetwork לא זמין.

hostPath הגבלות על עוצמת הקול

‫Google Distributed Cloud במודל מחובר מאפשר רק את hostPathהאחסון הבא עם גישת קריאה/כתיבה:

  • /dev/hugepages
  • /dev/infiniband
  • /dev/vfio
  • /dev/char
  • /sys/devices

PersistentVolumeClaim הגבלות על סוג המשאב

‫Distributed Cloud במודל מחובר מאפשר רק את סוגי המשאבים הבאים:PersistentVolumeClaim

  • csi
  • nfs
  • local

הגבלות על סוגי נפח אחסון

‫Distributed Cloud במודל מחובר מאפשר רק את סוגי אמצעי האחסון הבאים:

  • configMap
  • csi
  • downwardAPI
  • emptyDir
  • hostPath
  • nfs
  • persistentVolumeClaim
  • projected
  • secret

הגבלות על סבילות של Pod

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

  • ""
  • node-role.kubernetes.io/master
  • node-role.kubernetes.io/control-plane

הגבלות על התחזות

‫Distributed Cloud Connected לא תומך בהתחזות למשתמש או לקבוצה.

הגבלות על מרחב שמות לניהול

‫Google Distributed Cloud במודל מחובר לא מאפשר גישה למרחבי השמות הבאים:

  • ai-system
  • ai-speech-system
  • ai-ocr-system
  • ai-translation-system
  • anthos-identity-service
  • cert-manager
  • dataproc-system
  • dataproc-PROJECT_ID
  • dns-system
  • g-istio-system
  • gke-connect
  • gke-managed-metrics-server
  • gke-operators
  • g-ospf-servicecontrol-system
  • g-ospf-system
  • g-pspf-system
  • gke-system
  • gpc-backup-system
  • iam-system
  • kube-node-lease
  • kube-public
  • kube-system למעט מחיקה של ippools.whereabouts.cni.cncf.io
  • metallb-system למעט עריכה של משאבי configMap כדי להגדיר טווחים של כתובות IP לאיזון עומסים
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • vm-system

‫PROJECT_ID מציין את המזהה של פרויקט היעד Google Cloud .

אל תשתמשו במרחב שמות עם הקידומת g- בשם שלו. מרחבי שמות כאלה הם בדרך כלל מרחבי שמות שמורים שמשמשים את Google Distributed Cloud במודל מחובר.

הגבלות על תגובות לפעולות מאתרים אחרים (web

ב-Distributed Cloud במודל מחובר, יש הגבלות על השימוש ב-webhook:

  • כל webhook לשינוי שתיצרו יכלול באופן אוטומטי את מרחב השמות kube-system.
  • האפשרות 'שינוי של webhook' מושבתת לסוגי המשאבים הבאים:
    • nodes
    • persistentvolumes
    • certificatesigningrequests
    • tokenreviews

הגבלות על העדיפות של ה-Pod

כדי להשתמש ב-Distributed Cloud connected, צריך להגדיר את העדיפות של ה-Pods של עומס העבודה לערך נמוך מ-500000000.

הגדרת מחלקת זמן ריצה ל-Pod

באמצעות Distributed Cloud Connected אפשר לציין את מחלקת זמן הריצה של Pod בהגדרה שלו באמצעות השדה runtimeClassName. ההגדרה הזו מחליפה את מחלקת זמן הריצה שמוגדרת כברירת מחדל ברמת האשכול. המחלקות הזמינות של זמן הריצה הן runc ו-gvisor. לדוגמה:

apiVersion: v1
kind: Pod
metadata:
  name: myPod
spec:
  runtimeClassName: gvisor
  containers:
  - name: myPod
    image: myPodImage
  restartPolicy: OnFailure

אם לא מציינים את זה בהגדרת ה-Pod, ה-Pod משתמש במחלקה שצוינה ברמת האשכול. כברירת מחדל, סביבת זמן הריצה ברמת האשכול היא runc, אלא אם מגדירים סביבת זמן ריצה כברירת מחדל באמצעות הפרמטר --default-container-runtime, כמו שמתואר במאמר יצירה וניהול של אשכולות.

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

gvisor runtime class

הגדרת זמן הריצה של המחלקה gvisor מעבירה את ה-Pod לזמן הריצה המאובטח של Open Container Initiative ‏ (OCI) שמבוסס על gVisor. ‏gVisor הוא פתרון ארגז חול שמציג בידוד חזק בין עומס העבודה לבין המארח שלו.

הגדרת שילוב עם VPC Service Controls

כדי להגדיר את השילוב של Distributed Cloud Edge Container API עם VPC Service Controls, צריך לבצע את השלבים שבקטע הזה. למידע נוסף, קראו את המאמרים הבאים:

כללים נדרשים לתעבורת נתונים יוצאת (egress)

כדי לשלב את Distributed Cloud Edge Container API עם VPC Service Controls, צריך להגדיר את כללי התעבורה היוצאת (egress) שמתוארים בקטע הזה. מידע על התחביר של כללי תעבורת נתונים יוצאת (egress) אפשר למצוא במאמר בנושא כללים לתעבורת נתונים יוצאת (egress).

גישה לאזור המכונה ולפרויקט Google Cloud

הכלל הזה מאפשר לזהות הקוראת לגשת לאזור המכונה ולפרויקט כשמבצעים קריאות באמצעות Distributed Cloud Edge Container API. Google Cloud הכלל הזה חל כשהמכונה והאשכול לא נמצאים באותוGoogle Cloud פרויקט והפרויקט של המכונה Google Cloud נמצא מחוץ לגבולות. הכלל הזה נדרש אם הגבלתם את Distributed Cloud Edge Container API בתוך גבולות הגזרה באמצעות VPC Service Controls.

הנה דוגמה להגדרת egressFrom של הכלל הזה בפורמט JSON:

egressFrom:
  identityType: ANY_SERVICE_ACCOUNT
  sources:
    - accessLevel: "*"

דוגמה להגדרת egressTo של הכלל הזה:

egressTo:
 resources:
 - "projects/280968151686"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

כללים נדרשים לתעבורת נתונים נכנסת (ingress)

כדי לשלב את Distributed Cloud Edge Container API עם VPC Service Controls, צריך להגדיר את כללי הכניסה שמתוארים בקטע הזה. מידע על התחביר של כללי כניסה זמין במאמר בנושא הפניה לכללי כניסה.

גישה ל-Distributed Cloud Edge Container API

הכלל הזה מאפשר לזהויות ספציפיות לגשת ל-Distributed Cloud Edge Container API ולקיים איתו אינטראקציה. צריך להגדיר את הכלל הזה אם הגבלתם את Distributed Cloud Edge Container API בתוך גבולות הגזרה באמצעות VPC Service Controls, והזהות שקוראת ל-Distributed Cloud Edge Container API נמצאת מחוץ לגבולות הגזרה.

דוגמה להגדרת ingressFrom של הכלל הזה:

ingressFrom:
   sources:
     - accessLevel: '*'
   identities:
     - serviceAccount:testuser@kubernetesedge-e2e-testing.iam.gserviceaccount.com

דוגמה להגדרת ingressTo של הכלל הזה:

ingressTo:
 resources:
 - "*"
 operations:
   - serviceName: "edgecontainer.googleapis.com"
     methodSelectors:
       - method: "*"

גישה ל-Connect API ול-Security Token Service API

הכלל הזה מאפשר לעומסי עבודה לגשת ל-Connect API ול-Security Token Service API. אם הגבלתם את הגישה ל-Connect API ול-Security Token Service API בתוך גבולות הגזרה באמצעות VPC Service Controls, אתם צריכים להגדיר את הכלל הזה. מידע על הגדרת מדיניות גישה ברמת כתובת ה-IP מופיע במאמר בנושא כתובת IP.

דוגמה להגדרת ingressFrom של הכלל הזה:

- ingressFrom:
   identityType: ANY_IDENTITY
   sources:
     - accessLevel: "accessPolicies/100637171436/accessLevels/fwi"

דוגמה להגדרת ingressTo של הכלל הזה:

ingressTo:
   resources:
   - "*"
   operations:
     - serviceName: "gkeconnect.googleapis.com"
       methodSelectors:
         - method: "*"
     - serviceName: "sts.googleapis.com"
       methodSelectors:
         - method: "*"

המאמרים הבאים