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

בדף הזה מתוארים השלבים לפריסת עומסי עבודה בציוד המחובר ל-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.

  12. אופציונלי: מחברים את האשכול המחובר של Distributed Cloud אל Google Cloud:

    1. יוצרים חיבור VPN לפרויקט Google Cloud .

    2. בודקים שחיבור ה-VPN פועל.

  13. אופציונלי: הגדרת גישה פרטית ל-Google כדי לאפשר ל-Pods לגשת ל-Google Cloud APIs ולשירותים באמצעות Cloud VPN.

  14. אופציונלי: הגדרת Private Service Connect כדי לאפשר ל-Pods שלכם לגשת אלGoogle Cloud ממשקי API ושירותים באמצעות Cloud VPN.

פריסת מאזן העומסים 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

פריסת קונטיינר עם פונקציות SR-IOV

בדוגמה הבאה אפשר לראות איך פורסים Pod שמשתמש בתכונות של אופרטור פונקציית הרשת SR-IOV של Distributed Cloud Connected.

יצירת רכיבי הרשת של Distributed Cloud

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

  1. כדי ליצור רשת:

    gcloud edge-cloud networking networks create NETWORK_NAME \
    --location=REGION \
    --zone=ZONE_NAME \
    --mtu=MTU_SIZE

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

    • ‫NETWORK_NAME: שם תיאורי שמזהה באופן ייחודי את הרשת הזו.
    • ‫REGION: האזור Google Cloud שאליו שייך אזור היעד של Distributed Cloud.
    • ‫ZONE_NAME: השם של אזור היעד המחובר של Distributed Cloud.
    • ‫MTU_SIZE: גודל יחידת השידור המקסימלית (MTU) של הרשת הזו. הערכים החוקיים הם 1,500 ו-9,000. הערך הזה צריך להיות זהה לגודל ה-MTU של רשת default, והוא צריך להיות זהה לכל הרשתות.

  2. יצירת רשת משנה:

    gcloud edge-cloud networking subnets create SUBNETWORK_NAME \
    --network=NETWORK_NAME \
    --ipv4-range=IPV4_RANGE \
    --vlan-id=VLAN_ID \
    --location=REGION \
    --zone=ZONE_NAME

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

    • ‫SUBNETWORK_NAME: שם תיאורי שמזהה באופן ייחודי את רשת המשנה הזו.
    • ‫NETWORK_NAME: הרשת שמכילה את רשת המשנה הזו.
    • ‫IPV4_RANGE: טווח כתובות ה-IPv4 שהרשת המשנית הזו מכסה בפורמט כתובת ה-IP/קידומת.
    • ‫VLAN_ID: מזהה ה-VLAN של רשת המשנה הזו.
    • ‫REGION: Google Cloud האזור שאליו שייך אזור היעד המחובר של Distributed Cloud.
    • ‫ZONE_NAME: השם של אזור היעד המחובר של Distributed Cloud.

  3. עוקבים אחרי הסטטוס של רשת המשנה עד שהיא נוצרת בהצלחה:

    watch -n 30 'gcloud edge-cloud networking subnets list \
    --location=REGION \
    --zone=ZONE_NAME

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

    • ‫REGION: Google Cloud האזור שאליו שייך אזור היעד המחובר של Distributed Cloud.
    • ‫ZONE_NAME: השם של אזור היעד המחובר של Distributed Cloud.

    הסטטוס משתנה מPENDING לPROVISIONING ולבסוף לRUNNING.

    רושמים את מזהה ה-VLAN, את בלוק ה-CIDR של תת-הרשת ואת כתובת ה-IP של השער עבור בלוק ה-CIDR. תשתמשו בערכים האלה בהמשך התהליך הזה.

הגדרת המשאבים 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 כשההפעלה מחדש מסתיימת.

הגדרת מתגי ToR לפונקציות רשת SR-IOV

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

  1. יוצרים קובץ בשם mlnc6-pcie1-tor1-sriov.yaml עם התוכן הבא. הקובץ הזה מגדיר את ממשק הרשת הראשון במתג ToR הראשון.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor1_sriov

  2. יוצרים קובץ בשם mlnc6-pcie1-tor2-sriov.yaml עם התוכן הבא. הקובץ הזה מגדיר את ממשק הרשת השני במתג ToR הראשון.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie1-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp59s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie1_tor2_sriov

  3. יוצרים קובץ בשם mlnc6-pcie2-tor1-sriov.yaml עם התוכן הבא. הקובץ הזה מגדיר את ממשק הרשת הראשון במתג השני של ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor1-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f0np0
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor1_sriov

  4. יוצרים קובץ בשם mlnc6-pcie2-tor2-sriov.yaml עם התוכן הבא. הקובץ הזה מגדיר את ממשק הרשת השני במתג השני של ToR.

      apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
  kind: SriovNetworkNodePolicy
  metadata:
  name: mlnx6-pcie2-tor2-sriov
  namespace: sriov-network-operator
  spec:
  deviceType: netdevice
  isRdma: false
  linkType: eth
  mtu: 9000
  nicSelector:
     pfNames:
     - enp216s0f1np1
  nodeSelector:
     edgecontainer.googleapis.com/network-sriov.capable: "true"
  numVfs: 31
  priority: 99
  resourceName: mlnx6_pcie2_tor2_sriov

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

    kubectl apply -f mlnc6-pcie1-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie1-tor2-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor1-sriov.yaml
kubectl apply -f mlnc6-pcie2-tor2-sriov.yaml

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

  6. עוקבים אחרי הסטטוס של הצמתים באמצעות הפקודה הבאה:

    watch -n 5 'kubectl get sriovnetworknodestates -o yaml -A | \ 
grep "syncStatus\|pool-"|sed "N;s/\n/ /"'

    כשכל הצמתים המושפעים מציגים syncStatus: Succeeded, לוחצים על Ctrl+C כדי לצאת מהלולאה של פקודת המעקב.

    הפקודה מחזירה פלט דומה לזה, שמציין שהתכונות של פונקציית הרשת SR-IOV הופעלו במתגי ToR:

    Allocated resources:
(Total limits may be over 100 percent, i.e., overcommitted.)
Resource                       Requests     Limits
--------                       --------     ------
cpu                            2520m (3%)   7310m (9%)
memory                         3044Mi (1%)  9774Mi (3%)
ephemeral-storage              0 (0%)       0 (0%)
hugepages-1Gi                  0 (0%)       0 (0%)
hugepages-2Mi                  0 (0%)       0 (0%)
devices.kubevirt.io/kvm        0            0
devices.kubevirt.io/tun        0            0
devices.kubevirt.io/vhost-net  0            0
gke.io/mlnx6_pcie1_tor1_sriov  3            3
gke.io/mlnx6_pcie1_tor2_sriov  0            0
gke.io/mlnx6_pcie2_tor1_sriov  0            0
gke.io/mlnx6_pcie2_tor2_sriov  0            0

הגדרת משאב NetworkAttachmentDefinition

מגדירים משאב NetworkAttachmentDefinition עבור האשכול באופן הבא:

  1. יוצרים קובץ בשם network-attachment-definition.yaml עם התוכן הבא:

    apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
name: sriov-net1
annotations:
  k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx6_pcie1_tor1_sriov
spec:
config: '{
"type": "sriov",
"cniVersion": "0.3.1",
"vlan": VLAN_ID,
"name": "sriov-network",
"ipam": {
  "type": "host-local",
  "subnet": "SUBNETWORK_CIDR",
  "routes": [{
     "dst": "0.0.0.0/0"
  }],
  "gateway": "GATEWAY_ADDRESS"
}
}'

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

  • ‫VLAN_ID: מזהה ה-VLAN של רשת המשנה שיצרתם קודם במדריך הזה.
  • ‫SUBNETWORK_CIDR: חסימת ה-CIDR של רשת המשנה.
  • ‫GATEWAY_ADDRESS: כתובת ה-IP של השער ברשת המשנה.

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

    kubectl apply -f network-attachment-definition.yaml

פריסת Pod עם פונקציות רשת SR-IOV

כדי לפרוס Pod עם פונקציות רשת SR-IOV באשכול, צריך לבצע את השלבים שבקטע הזה. השדה annotations בקובץ ההגדרות של ה-Pod מציין את השם של משאב NetworkAttachmentDefinition שיצרתם קודם במדריך הזה, ואת מרחב השמות שבו הוא נפרס (default בדוגמה הזו).

  1. יוצרים קובץ מפרט של Pod בשם sriovpod.yaml עם התוכן הבא:

         apiVersion: v1
     kind: Pod
     metadata:
     name: sriovpod
     annotations:
        k8s.v1.cni.cncf.io/networks: default/sriov-net1
     spec:
     containers:
     - name: sleeppodsriov
        command: ["sh", "-c", "trap : TERM INT; sleep infinity & wait"]
        image: busybox
        securityContext:
           capabilities:
           add:
              - NET_ADMIN

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

    kubectl apply -f sriovpod.yaml

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

    kubectl get pods

  4. מקימים מעטפת של שורת פקודה עבור ה-Pod באמצעות הפקודה הבאה:

    kubectl exec -it sriovpod -- sh

  5. כדי לוודא ש-Pod מתקשר עם מתגי ToR באמצעות התכונה של אופרטור פונקציית הרשת SR-IOV, מריצים את הפקודה הבאה במעטפת של Pod:

    ip addr

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

    1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host 
      valid_lft forever preferred_lft forever
51: net1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 9000 qdisc mq qlen 1000
   link/ether 2a:af:96:a5:42:ab brd ff:ff:ff:ff:ff:ff
   inet 192.168.100.11/25 brd 192.168.100.127 scope global net1
      valid_lft forever preferred_lft forever
228: eth0@if229: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue qlen 1000
   link/ether 46:c9:1d:4c:bf:32 brd ff:ff:ff:ff:ff:ff
   inet 10.10.3.159/32 scope global eth0
      valid_lft forever preferred_lft forever
   inet6 fe80::44c9:1dff:fe4c:bf32/64 scope link 
      valid_lft forever preferred_lft forever

    המידע שמוחזר עבור הממשק net1 מציין שנוצר חיבור לרשת בין מתגי ה-ToR לבין ה-Pod.

הגדרת 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
  • sriov-fec-system
  • sriov-network-operator
  • 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 הוא פתרון ארגז חול שמציג בידוד חזק בין עומס העבודה לבין המארח שלו.

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