Men-deploy workload

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

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

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

Penginstal Google akan menyelesaikan penginstalan fisik, dan administrator sistem Anda akan menghubungkan Distributed Cloud 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.

Ringkasan deployment

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

  1. Opsional: Aktifkan Distributed Cloud Edge Network API.

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

  3. Opsional: Konfigurasi jaringan Distributed Cloud.

  4. Buat cluster 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 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.

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

  12. Opsional: Hubungkan cluster Distributed Cloud 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 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 Distributed Cloud.

Membuat komponen jaringan Distributed Cloud

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

  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 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 target berada.
    • ZONE_NAME: nama target zona 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 target berada.
    • ZONE_NAME: nama target zona 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 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.

Batasan untuk workload Distributed Cloud

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

Batasan workload Linux

Distributed Cloud 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_RESOURCE
  • SYS_TIME

Pembatasan namespace

Distributed Cloud tidak mendukung namespace berikut:

  • hostPID
  • hostIPC
  • hostNetwork

Pembatasan jenis resource

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

Batasan konteks keamanan

Distributed Cloud tidak mendukung konteks keamanan mode istimewa.

Batasan pengikatan pod

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

hostPath pembatasan volume

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

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

Batasan jenis resource PersistentVolumeClaim

Distributed Cloud hanya mengizinkan jenis resource PersistentVolumeClaim berikut:

  • csi
  • nfs
  • local

Batasan jenis volume

Distributed Cloud hanya mengizinkan jenis volume berikut:

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

Batasan toleransi pod

Distributed Cloud tidak mengizinkan Pod yang dibuat pengguna di node bidang kontrol. Secara khusus, Distributed Cloud 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 tidak mendukung peniruan identitas pengguna atau grup.

Batasan namespace pengelolaan

Distributed Cloud tidak mengizinkan pengguna mengakses namespace berikut:

  • kube-system dengan pengecualian penghapusan ippools.whereabouts.cni.cncf.io
  • anthos-identity-service
  • cert-manager
  • gke-connect
  • kubevirt
  • metallb-system, kecuali mengedit resource configMap untuk menetapkan rentang alamat IP load balancing
  • nf-operator
  • sriov-network-operator

Pembatasan webhook

Distributed Cloud 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