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

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

  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.

  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.

יצירת רכיבי הרשת של 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.

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

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

מגבלות על עומסי עבודה ב-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_RESOURCE
  • SYS_TIME

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

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

  • hostPID
  • hostIPC
  • hostNetwork

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

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

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

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

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

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

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

ב-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, אסור למשתמשים ליצור Pods בצמתים של מישור הבקרה. בפרט, ב-Distributed Cloud אי אפשר לתזמן Pods עם מפתחות הסבילות הבאים:

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

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

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

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

ב-Distributed Cloud, למשתמשים אין גישה למרחבי השמות הבאים:

  • kube-system למעט מחיקה של ippools.whereabouts.cni.cncf.io
  • anthos-identity-service
  • cert-manager
  • gke-connect
  • kubevirt
  • metallb-system למעט עריכה של משאבי configMap כדי להגדיר טווחים של כתובות IP לאיזון עומסים
  • nf-operator
  • sriov-network-operator

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

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

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

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