Men-deploy workload

Halaman ini menjelaskan langkah-langkah untuk men-deploy workload di hardware yang terhubung ke Google Distributed Cloud dan batasan yang harus Anda patuhi saat mengonfigurasi workload.

Sebelum menyelesaikan langkah-langkah ini, Anda harus memenuhi persyaratan penginstalan yang terhubung ke Distributed Cloud dan memesan hardware Distributed Cloud.

Saat hardware Google Distributed Cloud terhubung tiba di tujuan yang Anda pilih, hardware tersebut telah dikonfigurasi sebelumnya dengan hardware, Google Cloud, dan beberapa setelan jaringan yang Anda tentukan saat memesan Distributed Cloud terhubung.

Penginstal Google menyelesaikan penginstalan fisik, dan administrator sistem Anda menghubungkan Distributed Cloud yang terhubung ke jaringan lokal Anda.

Setelah hardware terhubung ke jaringan lokal, hardware akan berkomunikasi dengan Google Cloud untuk mendownload update software dan terhubung dengan project Google Cloud Anda. Kemudian, Anda siap menyediakan kumpulan node dan men-deploy workload di Distributed Cloud terhubung.

Ringkasan deployment

Untuk men-deploy workload di hardware yang terhubung ke Distributed Cloud Anda, selesaikan langkah-langkah berikut:

  1. Opsional: Aktifkan Distributed Cloud Edge Network API.

  2. Opsional: Lakukan inisialisasi konfigurasi jaringan zona terhubung Distributed Cloud Anda.

  3. Opsional: Konfigurasi jaringan Distributed Cloud.

  4. Buat cluster yang terhubung ke Distributed Cloud.

  5. Opsional: Aktifkan dukungan untuk kunci enkripsi yang dikelola pelanggan (CMEK) untuk penyimpanan lokal jika Anda ingin berintegrasi dengan Cloud Key Management Service untuk mengaktifkan dukungan CMEK untuk data beban kerja Anda. Untuk mengetahui informasi tentang cara Distributed Cloud terhubung mengenkripsi data workload, lihat Keamanan penyimpanan lokal.

  6. Buat node pool. Pada langkah ini, Anda menetapkan node ke node pool dan secara opsional mengonfigurasi node pool untuk menggunakan Cloud KMS guna mengenkripsi dan mendekripsi frasa sandi Linux Unified Key Setup (LUKS) untuk mengenkripsi data workload.

  7. Dapatkan kredensial untuk cluster guna menguji cluster.

  8. Beri pengguna akses ke cluster dengan menetapkan peran Edge Container Viewer (roles/edgecontainer.viewer) atau peran Edge Container Admin (roles/edgecontainer.admin) pada project.

  9. Tetapkan akses berbasis peran terperinci kepada pengguna ke resource cluster menggunakan RoleBinding dan ClusterRoleBinding.

  10. Opsional: Aktifkan dukungan VM Runtime di Google Distributed Cloud untuk menjalankan workload di virtual machine di Distributed Cloud terhubung.

  11. Opsional: Aktifkan dukungan GPU untuk menjalankan workload berbasis GPU di Distributed Cloud terhubung.

  12. Opsional: Hubungkan cluster Distributed Cloud terhubung ke Google Cloud:

    1. Buat koneksi VPN ke Google Cloud project Anda.

    2. Periksa apakah koneksi VPN berfungsi.

  13. Opsional: Konfigurasi Akses Google Pribadi agar Pod Anda dapat mengakses Google Cloud API dan layanan menggunakan Cloud VPN.

  14. Opsional: Konfigurasi Private Service Connect untuk mengizinkan Pod Anda mengakses Google Cloud API dan layanan menggunakan Cloud VPN.

Men-deploy load balancer NGINX sebagai layanan

Contoh berikut mengilustrasikan cara men-deploy server NGINX dan mengeksposnya sebagai layanan di cluster yang terhubung Distributed Cloud:

  1. Buat file YAML bernama nginx-deployment.yaml dengan konten berikut:

    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. Terapkan file YAML ke cluster menggunakan perintah berikut:

    kubectl apply -f nginx-deployment.yaml

  3. Buat file YAML bernama nginx-service.yaml dengan konten berikut:

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

  4. Terapkan file YAML ke cluster menggunakan perintah berikut:

    kubectl apply -f nginx-deployment.yaml

  5. Dapatkan alamat IP eksternal yang ditetapkan ke layanan oleh load balancer MetalLB menggunakan perintah berikut:

    kubectl get services

    Perintah ini akan menampilkan output yang mirip dengan berikut ini:

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

Men-deploy container dengan fungsi SR-IOV

Contoh berikut menggambarkan cara men-deploy Pod yang menggunakan fitur operator fungsi jaringan SR-IOV dari Distributed Cloud yang terhubung.

Membuat komponen jaringan Distributed Cloud

Buat komponen jaringan yang diperlukan untuk deployment yang terhubung Distributed Cloud Anda sebagai berikut. Untuk mengetahui informasi selengkapnya tentang komponen ini, lihat Fitur jaringan Distributed Cloud yang terhubung.

  1. Buat jaringan:

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

    Ganti kode berikut:

    • NETWORK_NAME: nama deskriptif yang secara unik mengidentifikasi jaringan ini.
    • REGION: Google Cloud region tempat zona Distributed Cloud target berada.
    • ZONE_NAME: nama target zona yang terhubung Distributed Cloud.
    • MTU_SIZE: ukuran unit transmisi maksimum (MTU) untuk jaringan ini. Nilai yang valid adalah 1500 dan 9000. Nilai ini harus cocok dengan ukuran MTU jaringan default dan sama untuk semua jaringan.

  2. Buat subnetwork:

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

    Ganti kode berikut:

    • SUBNETWORK_NAME: nama deskriptif yang secara unik mengidentifikasi subnetwork ini.
    • NETWORK_NAME: jaringan yang mengenkapsulasi subnetwork ini.
    • IPV4_RANGE: rentang alamat IPv4 yang dicakup subnetwork ini dalam format alamat IP/awalan.
    • VLAN_ID: ID VLAN target untuk subnet ini.
    • REGION: Google Cloud region tempat zona Distributed Cloud terhubung target berada.
    • ZONE_NAME: nama target zona yang terhubung Distributed Cloud.

  3. Pantau status subnetwork hingga berhasil dibuat:

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

    Ganti kode berikut:

    • REGION: Google Cloud region tempat zona Distributed Cloud terhubung target berada.
    • ZONE_NAME: nama target zona yang terhubung Distributed Cloud.

    Status berlangsung dari PENDING ke PROVISIONING dan akhirnya ke RUNNING.

    Catat ID VLAN, blok CIDR subnetwork, dan alamat IP gateway untuk blok CIDR. Anda akan menggunakan nilai ini nanti dalam prosedur ini.

Mengonfigurasi resource NodeSystemConfigUpdate

Konfigurasi resource operator fungsi jaringan NodeSystemConfigUpdate untuk setiap node di cluster sebagai berikut.

  1. Cantumkan node yang berjalan di node pool cluster target menggunakan perintah berikut:

    kubectl get nodes | grep -v master

    Perintah ini akan menampilkan output yang mirip dengan berikut ini:

    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

    Catat nama node yang ditampilkan dan dapatkan nama pendeknya. Misalnya, untuk node pool-example-node-1-01-b2d82cc7, nama pendeknya adalah node101.

  2. Untuk setiap node yang telah Anda rekam di langkah sebelumnya, buat file resource NodeSystemConfigUpdate khusus dengan konten berikut:

    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"

    Ganti kode berikut:

    • NODE_NAME: nama lengkap node target. Contoh, pool-example-node-1-01-b2d82cc7.
    • NODE_SHORT_NAME: nama singkat node target yang berasal dari nama lengkapnya. Contoh, node101.

    Beri nama setiap file node-system-config-update-NODE_SHORT_NAME.yaml.

  3. Terapkan setiap file resource NodeSystemConfigUpdate ke cluster menggunakan perintah berikut:

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

    Ganti NODE_SHORT_NAME dengan nama pendek node target yang sesuai.

    Saat Anda menerapkan resource ke cluster, setiap node yang terpengaruh akan di-reboot, yang dapat memakan waktu hingga 30 menit.

    1. Pantau status node yang terpengaruh hingga semuanya berhasil di-reboot:
    kubectl get nodes | grep -v master

    Status setiap node bertransisi dari not-ready ke ready saat proses booting ulang selesai.

Mengonfigurasi switch ToR untuk fungsi jaringan SR-IOV

Ikuti langkah-langkah di bagian ini untuk mengonfigurasi antarmuka jaringan di setiap switch ToR Distributed Cloud di rak yang terhubung Distributed Cloud untuk operasi fungsi jaringan SR-IOV.

  1. Buat file bernama mlnc6-pcie1-tor1-sriov.yaml dengan konten berikut. File ini mengonfigurasi antarmuka jaringan pertama di switch ToR pertama.

      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. Buat file bernama mlnc6-pcie1-tor2-sriov.yaml dengan konten berikut. File ini mengonfigurasi antarmuka jaringan kedua di switch ToR pertama.

      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. Buat file bernama mlnc6-pcie2-tor1-sriov.yaml dengan konten berikut. File ini mengonfigurasi antarmuka jaringan pertama di switch ToR kedua.

      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. Buat file bernama mlnc6-pcie2-tor2-sriov.yaml dengan konten berikut. File ini mengonfigurasi antarmuka jaringan kedua di switch ToR kedua.

      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. Terapkan file konfigurasi ToR ke cluster menggunakan perintah berikut:

    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

    Node yang terpengaruh akan diisolasi, dikuras, dan di-reboot.

  6. Pantau status node menggunakan perintah berikut:

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

    Saat semua node yang terpengaruh menampilkan syncStatus: Succeeded, tekan Ctrl+C untuk keluar dari loop perintah pemantauan.

    Perintah akan menampilkan output yang mirip dengan berikut, yang menunjukkan bahwa fitur fungsi jaringan SR-IOV telah diaktifkan di switch 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

Mengonfigurasi resource NetworkAttachmentDefinition

Konfigurasi resource NetworkAttachmentDefinition untuk cluster sebagai berikut:

  1. Buat file bernama network-attachment-definition.yaml dengan konten berikut:

    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"
}
}'

Ganti kode berikut:

  • VLAN_ID: ID VLAN subnetwork yang Anda buat sebelumnya dalam panduan ini.
  • SUBNETWORK_CIDR: blok CIDR untuk subnetwork.
  • GATEWAY_ADDRESS: alamat IP gateway untuk subnetwork.

  1. Terapkan resource ke cluster menggunakan perintah berikut:

    kubectl apply -f network-attachment-definition.yaml

Men-deploy Pod dengan fungsi jaringan SR-IOV

Selesaikan langkah-langkah di bagian ini untuk men-deploy Pod dengan fungsi jaringan SR-IOV di cluster. Kolom annotations dalam file konfigurasi Pod menentukan nama resource NetworkAttachmentDefinition yang Anda buat sebelumnya dalam panduan ini dan namespace tempat resource tersebut di-deploy (default dalam contoh ini).

  1. Buat file spesifikasi Pod bernama sriovpod.yaml dengan konten berikut:

         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. Terapkan file spesifikasi Pod ke cluster menggunakan perintah berikut:

    kubectl apply -f sriovpod.yaml

  3. Verifikasi bahwa Pod telah berhasil dimulai menggunakan perintah berikut:

    kubectl get pods

  4. Buat shell command line untuk Pod menggunakan perintah berikut:

    kubectl exec -it sriovpod -- sh

  5. Pastikan bahwa Pod berkomunikasi dengan switch ToR menggunakan fitur operator fungsi jaringan SR-IOV menggunakan perintah berikut di shell Pod:

    ip addr

    Perintah ini akan menampilkan output yang mirip dengan berikut ini:

    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

    Informasi yang ditampilkan untuk antarmuka net1 menunjukkan bahwa konektivitas jaringan antara switch ToR dan Pod telah dibuat.

Mengonfigurasi Pod untuk caching gambar

Anda dapat mengonfigurasi Pod yang berjalan di cluster yang terhubung ke Distributed Cloud untuk menyimpan image-nya dalam cache. Pod mulai menggunakan image yang di-cache setelah ditarik dari repositori untuk pertama kalinya. Jika node yang menghosting Pod kehabisan penyimpanan, gambar baru tidak di-cache dan cache gambar yang ada akan dihapus untuk memastikan workload Anda terus berjalan tanpa terganggu.

Konfigurasi Pod Anda harus memenuhi prasyarat berikut:

  • Anda harus menetapkan label gdce.baremetal.cluster.gke.io/cache-image: true pada Pod.
  • Jika Anda menggunakan repositori image pribadi, resource ImagePullSecret Anda harus berjenis kubernetes.io/dockerconfigjson.
  • Anda harus menyetel kebijakan penarikan Pod ke IfNotPresent untuk memastikan salinan cache gambar target selalu digunakan. Jika salinan yang di-cache tidak tersedia secara lokal, image akan ditarik dari repositori.

Contoh berikut mengilustrasikan konfigurasi Pod dengan caching yang diaktifkan:

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

Contoh berikutnya mengilustrasikan konfigurasi Deployment dengan caching yang diaktifkan:

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

Batasan untuk workload Distributed Cloud

Saat mengonfigurasi beban kerja yang terhubung ke Distributed Cloud, Anda harus mematuhi batasan yang dijelaskan di bagian ini. Batasan ini diterapkan oleh Distributed Cloud terhubung pada semua workload yang Anda deploy di hardware Distributed Cloud terhubung.

Batasan workload Linux

Distributed Cloud Connected hanya mendukung kemampuan Linux berikut untuk workload:

  • 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

Pembatasan namespace

Distributed Cloud yang terhubung tidak mendukung namespace berikut:

  • hostPID
  • hostIPC
  • hostNetwork

Pembatasan jenis resource

Distributed Cloud Connected tidak mendukung jenis resource CertificateSigningRequest, yang memungkinkan klien meminta penerbitan sertifikat X.509, berdasarkan permintaan penandatanganan.

Batasan konteks keamanan

Distributed Cloud Connected tidak mendukung konteks keamanan mode istimewa.

Batasan pengikatan pod

Distributed Cloud Connected tidak mendukung pengikatan Pod ke port host di namespace HostNetwork. Selain itu, namespace HostNetwork tidak tersedia.

hostPath pembatasan volume

Distributed Cloud yang terhubung hanya mengizinkan hostPath volume dengan akses baca/tulis berikut:

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

Batasan jenis resource PersistentVolumeClaim

Distributed Cloud yang terhubung hanya mengizinkan jenis resource PersistentVolumeClaim berikut:

  • csi
  • nfs
  • local

Batasan jenis volume

Distributed Cloud yang terhubung hanya mengizinkan jenis volume berikut:

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

Batasan toleransi pod

Distributed Cloud terhubung tidak mengizinkan Pod yang dibuat pengguna di node bidang kontrol. Secara khusus, Distributed Cloud Connected tidak mengizinkan penjadwalan Pod yang memiliki kunci toleransi berikut:

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

Batasan peniruan identitas

Distributed Cloud connected tidak mendukung peniruan identitas pengguna atau grup.

Batasan namespace pengelolaan

Distributed Cloud connected tidak mengizinkan akses ke namespace berikut:

  • 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 dengan pengecualian penghapusan ippools.whereabouts.cni.cncf.io
  • metallb-system, kecuali mengedit resource configMap untuk menetapkan rentang alamat IP load balancing
  • nf-operator
  • oclcm-system
  • prediction
  • rm-system
  • robinio
  • saas-system
  • sriov-fec-system
  • sriov-network-operator
  • vm-system

PROJECT_ID menunjukkan ID project Google Cloud target.

Hindari penggunaan namespace dengan awalan g- dalam namanya. Namespace tersebut biasanya merupakan namespace yang dicadangkan dan digunakan oleh Distributed Cloud yang terhubung.

Pembatasan webhook

Distributed Cloud terhubung membatasi webhook sebagai berikut:

  • Webhook yang bermutasi yang Anda buat akan otomatis mengecualikan namespace kube-system.
  • Webhook yang mengubah dimatikan untuk jenis resource berikut:
    • nodes
    • persistentvolumes
    • certificatesigningrequests
    • tokenreviews

Langkah berikutnya