Mengalokasikan resource jaringan menggunakan DRANET yang dikelola GKE

Autopilot Standard

DRANET Google Kubernetes Engine (GKE) adalah fitur GKE terkelola yang dibangun berdasarkan project DRANET open source, yang mengimplementasikan DRA API Kubernetes untuk resource jaringan. DRANET memungkinkan Anda meminta dan mengalokasikan resource jaringan berperforma tinggi untuk Pod, termasuk antarmuka jaringan yang mendukung Remote Direct Memory Access (RDMA). Pendekatan ini menyediakan API portabel yang selaras dengan upstream untuk pengelolaan resource jaringan.

Dokumen ini memberikan ringkasan konseptual tentang GKE DRANET dan menunjukkan cara mengalokasikan resource jaringan ke workload di cluster GKE Anda.

Dokumen ini ditujukan untuk Cloud Architect dan Spesialis Jaringan yang mendesain jaringan untuk organisasi mereka. Untuk ringkasan semua dokumentasi GKE, lihat Mempelajari dokumentasi GKE. Untuk mempelajari peran dan tugas umum yang dirujuk dalam konten Google Cloud , lihat Peran dan tugas pengguna GKE umum.

Sebelum membaca dokumen ini, pastikan Anda memahami hal-hal berikut:

• Alokasi Resource Dinamis
• Tentang alokasi resource dinamis di GKE
• Konsep Kubernetes
• Jaringan GKE
• Dasar-dasar Jaringan GKE

Cara kerja DRANET yang dikelola GKE

DRANET yang dikelola GKE diimplementasikan melalui DaemonSet networking-dra-driver. DaemonSet ini berjalan di node dengan GPU, TPU, atau VM yang dioptimalkan untuk penyimpanan yang mengaktifkan GKE DRANET.

Daemonset ini berfungsi sebagai agen level node untuk membuat antarmuka jaringan dapat ditemukan dan dialokasikan ke Pod melalui Kubernetes Dynamic Resource Allocation (DRA) API.

Di GKE versi 1.34.1-gke.1829001 dan yang lebih baru, GKE otomatis menginstal resource DeviceClass untuk jaringan. Class ini menentukan jenis perangkat jaringan yang dapat Anda minta. Misalnya, GKE membuat class mrdma.google.com untuk VM GPU, class netdev.google.com untuk TPU dan perangkat jaringan lainnya, serta class irdma.google.com untuk VM yang dioptimalkan untuk penyimpanan (seperti Z4M).

Untuk menggunakan GKE DRANET, Anda harus mengaktifkan driver GKE DRANET terlebih dahulu di node pool dengan GPU, TPU, atau VM yang dioptimalkan untuk penyimpanan.

Untuk meminta perangkat jaringan untuk workload, tentukan ResourceClaimTemplate. Template ini menentukan DeviceClass dan mode alokasi, seperti meminta semua perangkat yang tersedia di node. Dalam spesifikasi Pod, referensikan template ini di kolom resourceClaims untuk memberi Pod Anda akses ke antarmuka jaringan yang diminta pada node.

Kapan harus menggunakan DRANET terkelola GKE

GKE DRANET menyediakan cara standar untuk mengelola resource jaringan yang mengetahui topologi dan dependensi. Standardisasi ini menjadikannya solusi yang cocok untuk AI dan ML, sistem file paralel besar, dan workload penyimpanan intensif data lainnya yang memerlukan jaringan berperforma tinggi.

Kasus penggunaan umum untuk meminta antarmuka jaringan untuk Pod meliputi:

• Meminta semua antarmuka yang mendukung RDMA yang tersedia.
• Meminta sejumlah antarmuka yang mendukung RDMA.
• Meminta semua antarmuka non-RDMA yang tersedia.
• Meminta sejumlah antarmuka non-RDMA tertentu.

Pertimbangan utama saat menggunakan DRANET terkelola GKE untuk jaringan

Pertimbangkan poin-poin berikut saat menggunakan GKE DRANET untuk jaringan:

• Antarmuka jaringan khusus

  Saat Anda menggunakan GKE DRANET untuk mengklaim antarmuka jaringan untuk Pod, antarmuka tersebut dikhususkan untuk Pod tersebut. Pod lain di node yang sama tidak dapat membagikannya. Pendekatan ini membantu memastikan bahwa Pod memiliki akses tunggal ke bandwidth dan resource penuh antarmuka tersebut, yang merupakan manfaat utama untuk workload yang sensitif terhadap performa.

• Menggunakan driver DRANET yang dikelola GKE secara independen

  Anda dapat mengaktifkan driver DRA GKE untuk mengelola resource jaringan tanpa mengaktifkan driver DRANET GKE lainnya. Untuk melakukannya, tambahkan label cloud.google.com/gke-networking-dra-driver=true ke node pool dengan GPU, TPU, atau VM yang dioptimalkan untuk penyimpanan.

• Menggunakan driver DRA GKE lainnya

  Untuk mencapai throughput yang lebih tinggi dalam workload AI/ML yang menuntut, gabungkan DRA API untuk akselerator (seperti GPU dan TPU) dengan jaringan terkelola GKE DRANET. Pendekatan gabungan ini meningkatkan penyelarasan resource dan kesadaran topologi. Untuk mempelajari lebih lanjut cara menggunakan DRA untuk resource lain, lihat Menyiapkan infrastruktur GKE untuk workload DRA.

• Menghindari konfigurasi yang bertentangan

  Driver DRANET GKE mengelola antarmuka RDMA dan gVNIC yang tidak memiliki rentang alamat IP sekunder yang dikonfigurasi. Jangan menggunakan driver GKE DRANET dan API multi-jaringan GKE dengan resource Jaringan jenis Device di cluster yang sama. Menggunakan driver dan API secara bersamaan tidak didukung karena kedua API tersebut mencoba mengelola kumpulan NIC yang sama, yang dapat menyebabkan penyiapan yang salah dan perilaku yang tidak dapat diprediksi.

• Siklus proses terkelola driver DRANET

  Di GKE versi 1.34 dan yang lebih baru, GKE secara otomatis membuat namespace gke-managed-networking-dra-driver terkelola di cluster Anda. Serupa dengan beberapa workload sistem GKE lainnya, Pod driver DRANET hanya berjalan di node yang relevan (seperti node dengan GPU, TPU, dan hardware khusus lainnya). Pada node yang tidak relevan dengan driver, tidak ada Pod untuk driver ini yang berjalan. Jangan mengubah DaemonSet networking-dra-driver secara manual. Perubahan manual, seperti memperbarui kolom nodeAffinity, dapat mengganggu pengelolaan fitur DRANET oleh GKE dan menyebabkan Pod daemon DRANET dijadwalkan pada node yang tidak didukung.

Persyaratan

Untuk menggunakan DRANET terkelola GKE, lingkungan Anda harus memenuhi persyaratan berikut:

• Standard: 1.34.1-gke.1829001 atau yang lebih baru (1.36.3-gke.1767000 atau yang lebih baru untuk VM Z4M).
• Autopilot: 1.35.2-gke.1842000 atau yang lebih baru (1.37.0-gke.4713000 atau yang lebih baru untuk VM Z4M).
• GKE Dataplane V2 diaktifkan di cluster.

Anda juga harus menggunakan salah satu jenis mesin yang dioptimalkan untuk akselerator atau dioptimalkan untuk penyimpanan berikut:

Seri mesin	Jenis mesin	Model akselerator	Teknologi jaringan	DeviceClass
A3 Ultra	a3-ultragpu-8g	GPU NVIDIA H200	RDMA	mrdma.google.com
A4	a4-highgpu-8g	GPU NVIDIA B200	RDMA	mrdma.google.com
A4X	a4x-highgpu-4g	GPU NVIDIA GB200	RDMA	mrdma.google.com
A4X Max	a4x-maxgpu-4g-metal	GPU NVIDIA B300	RDMA	mrdma.google.com
TPU v7	tpu7x-standard-4t	TPU v7	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-8t	TPU Trillium	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-4t	TPU Trillium	NetDevice	netdev.google.com
TPU v6e	ct6e-standard-1t	TPU Trillium	NetDevice	netdev.google.com
Z4M	Jenis mesin Z4M yang mendukung IRDMA	Tidak berlaku (dioptimalkan untuk penyimpanan)	RDMA	irdma.google.com

Batasan

GKE DRANET memiliki batasan berikut:

• Anda tidak dapat menggunakan GKE DRANET untuk mengalokasikan kartu antarmuka jaringan (NIC) default atau NIC virtual (seperti veth).
• Jenis instance tertentu, khususnya node bare metal seperti a4x-max, tidak kompatibel dengan cluster Autoscaling dan Autopilot.

Pertimbangan khusus mesin

Bergantung pada arsitektur hardware yang mendasari node Anda, beberapa seri mesin memerlukan flag node pool tambahan, paket image container, atau DaemonSet sistem untuk mengonfigurasi antarmuka RDMA dengan GKE DRANET.

Bare metal A4X Max

• Men-deploy asapd-lite: Saat menggunakan node GPU bare metal, seperti A4X Max, Anda harus men-deploy DaemonSet asapd-lite ke cluster. DaemonSet asapd-lite mengonfigurasi kartu antarmuka jaringan (NIC) RDMA. Tanpa itu, antarmuka turunan tidak akan dibuat, dan driver dranet akan memfilter NIC RDMA, sehingga mencegah fungsi RDMA dalam Pod Anda. Untuk petunjuk penyiapan lengkap, lihat Mengonfigurasi NIC MRDMA dengan asapd-lite.

VM Z4M yang dioptimalkan untuk penyimpanan

• Persyaratan image container: Untuk menggunakan RDMA pada instance Z4M, Anda harus menggunakan image container Rocky Linux 8 yang dikonfigurasi dengan paket RDMA ruang pengguna yang diperlukan. Distribusi lain, seperti Ubuntu atau Debian, tidak didukung. Paket upstream standar untuk distribusi ini tidak memiliki ekstensi ABI kustom yang diperlukan driver IRDMA. Tanpa ekstensi ini, paket akan gagal saat runtime dengan error -ENOSPC. Untuk mengetahui petunjuk penyiapan, lihat Menggunakan antarmuka RDMA di node pool yang dioptimalkan untuk penyimpanan.

Sebelum memulai

Sebelum memulai, pastikan Anda telah melakukan tugas berikut:

• Aktifkan Google Kubernetes Engine API.
Aktifkan Google Kubernetes Engine API
• Untuk menggunakan Google Cloud CLI untuk tugas ini, instal lalu lakukan inisialisasi gcloud CLI. Jika sebelumnya Anda telah menginstal gcloud CLI, dapatkan versi terbaru dengan menjalankan perintah gcloud components update. Versi gcloud CLI yang lebih lama mungkin tidak mendukung menjalankan perintah dalam dokumen ini.
  Catatan: Untuk penginstalan gcloud CLI yang ada, pastikan untuk menyetel properti compute/region. Jika Anda menggunakan cluster zona, tetapkan compute/zone. Dengan menetapkan lokasi default, Anda dapat menghindari error di gcloud CLI seperti berikut: One of [--zone, --region] must be supplied: Please specify location. Anda mungkin perlu menentukan lokasi dalam perintah tertentu jika lokasi cluster Anda berbeda dengan default yang Anda tetapkan.

Peran yang diperlukan

Untuk mendapatkan izin yang diperlukan untuk membuat node pool dan mengalokasikan resource jaringan, minta administrator untuk memberi Anda peran IAM Kubernetes Engine Admin (roles/container.admin) di project Anda. Untuk mengetahui informasi selengkapnya tentang cara memberikan peran, lihat Mengelola akses ke project, folder, dan organisasi.

Anda mungkin juga bisa mendapatkan izin yang diperlukan melalui peran khusus atau peran bawaan lainnya.

Membuat cluster

Buat cluster GKE Standard yang menggunakan GKE Dataplane V2:

gcloud container clusters create CLUSTER_NAME \
    --enable-dataplane-v2 \
    --region=CONTROL_PLANE_LOCATION \
    --project=PROJECT_ID \
    --cluster-version=CLUSTER_VERSION

Ganti kode berikut:

• CLUSTER_NAME: nama cluster baru.
• CONTROL_PLANE_LOCATION: region atau zona untuk bidang kontrol cluster, seperti us-central1 atau us-central1-a.
• PROJECT_ID: Project ID Google Cloud Anda.
• CLUSTER_VERSION: versi GKE untuk cluster Anda:
  • VM Z4M: 1.36.3-gke.1767000 atau yang lebih baru
  • Semua VM atau instance bare metal lain yang didukung: 1.34.1-gke.1829001 atau yang lebih baru

Menggunakan antarmuka RDMA dari node pool GPU

Bagian berikut menjelaskan cara mengonfigurasi node pool GPU dan workload untuk menggunakan antarmuka jaringan RDMA dengan GKE DRANET.

Mengaktifkan driver DRANET yang dikelola GKE di node pool GPU

Untuk mengaktifkan driver GKE DRANET pada node pool GPU yang mendukung RDMA, tambahkan label cloud.google.com/gke-networking-dra-driver=true saat Anda membuat node pool.

gcloud beta container node-pools create NODE_POOL_NAME \
  --region=REGION \
  --cluster=CLUSTER_NAME \
  --node-locations=NODE_LOCATIONS \
  --accelerator type=ACCELERATOR_TYPE,count=ACCELERATOR_COUNT,gpu-driver-version=DRIVER_VERSION \
  --machine-type=MACHINE_TYPE \
  --num-nodes=NUM_NODES \
  --reservation-affinity=specific \
  --reservation=projects/RESERVATION_PROJECT/reservations/RESERVATION_NAME/reservationBlocks/RESERVATION_BLOCK \
  --accelerator-network-profile=auto \
  --node-labels=cloud.google.com/gke-networking-dra-driver=true

Ganti kode berikut:

• NODE_POOL_NAME: nama node pool baru.
• REGION: region Google Cloud untuk cluster Anda.
• CLUSTER_NAME: nama cluster Anda.

• ACCELERATOR_TYPE: jenis akselerator GPU:

  Contoh:

  • VM A4: masukkan nvidia-b200.
  • VM A3 Ultra: masukkan nvidia-h200-141gb.

• ACCELERATOR_COUNT: jumlah GPU yang akan dipasang ke node di node pool. Misalnya, untuk VM a4-highgpu-8g dan a3-ultragpu-8g, jumlah GPU adalah 8.

• DRIVER_VERSION: versi driver GPU yang akan digunakan. Misalnya default atau latest.

• MACHINE_TYPE: jenis mesin untuk node pool, misalnya, a3-ultragpu-8g.

• NUM_NODES: jumlah node untuk node pool. Untuk flex-start, nilai ini harus ditetapkan ke 0.

• RESERVATION_PROJECT: project ID pemesanan.

• RESERVATION_NAME: nama pemesanan Anda. Untuk menemukan nilai ini, lihat Melihat permintaan pemesanan untuk masa mendatang.

• RESERVATION_BLOCK: nama blok tertentu dalam pemesanan. Untuk menemukan nilai ini, lihat Melihat permintaan pemesanan untuk masa mendatang.

Perintah ini menggunakan profil jaringan akselerator untuk mengonfigurasi jaringan VPC dan subnet secara otomatis untuk VM akselerator Anda. Atau, Anda dapat secara eksplisit menentukan jaringan VPC dan subnet.

Men-deploy resource RDMA workload

Untuk mengalokasikan resource RDMA untuk Pod, tentukan ResourceClaimTemplate.

1. Buat ResourceClaimTemplate untuk menentukan cara mengalokasikan perangkat RDMA. Manifes berikut meminta semua perangkat mrdma yang tersedia di node. Simpan manifes sebagai all-mrdma-template.yaml:

   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: all-mrdma
   spec:
     spec:
       devices:
         requests:
         - name: req-mrdma
           exactly:
             deviceClassName: mrdma.google.com
             allocationMode: All
   

2. Terapkan manifes:

   kubectl apply -f all-mrdma-template.yaml
   

3. Deploy workload Anda dan referensikan ResourceClaimTemplate. Manifes berikut men-deploy Pod yang mereferensikan template all-mrdma, yang memberi Pod akses ke antarmuka RDMA di node. Simpan manifes sebagai agnhost-rdma-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: agnhost-rdma
     namespace: default
     labels:
       app: agnhost
   spec:
     containers:
     - name: agnhost
       image: registry.k8s.io/e2e-test-images/agnhost:2.39
       args: ["netexec", "--http-port", "80"]
       ports:
       - name: agnhost-port
         containerPort: 80
       resources:
         claims:
         - name: rdma
         limits:
           nvidia.com/gpu: 1
     resourceClaims:
     - name: rdma
       resourceClaimTemplateName: all-mrdma
   

4. Terapkan manifes:

   kubectl apply -f agnhost-rdma-pod.yaml
   

5. Pastikan antarmuka jaringan tambahan yang dialokasikan terlihat di dalam Pod.

   kubectl exec agnhost-rdma -- ls /sys/class/net
   

   Contoh output berikut menunjukkan antarmuka eth0 dan lo default, serta antarmuka RDMA yang dialokasikan, seperti gpu0rdma0. Jumlah dan nama antarmuka jaringan (NIC) bervariasi berdasarkan jenis mesin node GKE.

   eth0
   gpu0rdma0
   gpu1rdma0
   gpu2rdma0
   gpu3rdma0
   lo
   

Menggunakan antarmuka jaringan non-RDMA di TPU node pool

Bagian berikut menjelaskan cara mengonfigurasi node pool dan workload TPU untuk menggunakan antarmuka jaringan non-RDMA dengan GKE DRANET.

Memverifikasi DeviceClasses jaringan

Pastikan resource DeviceClass untuk jaringan ada di cluster Anda.

kubectl get deviceclass netdev.google.com

Outputnya mirip dengan hal berikut ini:

NAME                AGE
netdev.google.com   2d22h

Mengaktifkan driver DRANET yang dikelola GKE di node pool slice TPU

Untuk mengaktifkan driver GKE DRANET saat membuat node pool slice TPU, tambahkan label cloud.google.com/gke-networking-dra-driver=true.

gcloud beta container node-pools create NODE_POOL_NAME \
    --location=LOCATION \
    --cluster=CLUSTER_NAME \
    --node-locations=NODE_LOCATIONS \
    --machine-type=MACHINE_TYPE \
    --tpu-topology=TPU_TOPOLOGY \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto \
    --node-labels=cloud.google.com/gke-networking-dra-driver=true

Ganti kode berikut:

• NODE_POOL_NAME: Nama node pool baru.
• LOCATION: Region atau zona Google Cloud untuk cluster Anda.
• CLUSTER_NAME: Nama cluster Anda.
• NODE_LOCATIONS: Google Cloud Zona untuk node dalam node pool.
• MACHINE_TYPE: Jenis mesin yang akan digunakan untuk node. Untuk mengetahui informasi selengkapnya tentang jenis mesin yang kompatibel dengan TPU, lihat Memilih versi TPU.
• TPU_TOPOLOGY: Topologi TPU, misalnya, 2x4x4. Format topologi bergantung pada versi TPU. Untuk mempelajari lebih lanjut topologi TPU, lihat Memilih topologi.
• NUM_NODES: Jumlah node di node pool.

Untuk mengetahui informasi selengkapnya, lihat Membuat node pool slice TPU host tunggal.

Men-deploy workload yang mengklaim semua perangkat jaringan

Untuk mengalokasikan perangkat jaringan non-RDMA untuk Pod, tentukan ResourceClaimTemplate.

1. Buat ResourceClaimTemplate yang mereferensikan netdev.google.com DeviceClass. Manifes berikut meminta semua perangkat jaringan non-RDMA yang tersedia di node.

   Simpan manifes sebagai all-netdev-template.yaml:

   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: all-netdev
   spec:
     spec:
       devices:
         requests:
         - name: req-netdev
           exactly:
             deviceClassName: netdev.google.com
             allocationMode: All
   

2. Terapkan manifes:

   kubectl apply -f all-netdev-template.yaml
   

3. Deploy workload Anda dan referensikan ResourceClaimTemplate. Manifes berikut men-deploy Pod yang menggunakan template all-netdev untuk memberi Pod akses ke semua perangkat jaringan non-RDMA di node. Simpan manifes sebagai netdev-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: agnhost-netdev
     namespace: default
     labels:
       app: agnhost
   spec:
     containers:
     - name: agnhost
       image: registry.k8s.io/e2e-test-images/agnhost:2.39
       args: ["netexec", "--http-port", "80"]
       ports:
       - name: agnhost-port
         containerPort: 80
       resources:
         claims:
         - name: netdev
         limits:
           google.com/tpu: 4
     nodeSelector:
       cloud.google.com/gke-tpu-accelerator: TPU_ACCELERATOR
       cloud.google.com/gke-tpu-topology: TPU_TOPOLOGY
     resourceClaims:
     - name: netdev
       resourceClaimTemplateName: all-netdev
   

   Ganti kode berikut:

   • TPU_ACCELERATOR: Jenis akselerator TPU, misalnya, tpu-v5p-slice.
   • TPU_TOPOLOGY: Topologi TPU, misalnya, 2x4x4.

4. Terapkan manifes:

   kubectl apply -f netdev-pod.yaml
   

5. Pastikan antarmuka jaringan tambahan yang dialokasikan terlihat di dalam Pod.

   kubectl exec agnhost-netdev -- ls /sys/class/net
   

   Contoh output berikut menunjukkan antarmuka eth0 dan lo default, bersama dengan perangkat jaringan yang dialokasikan, yang memiliki nama seperti eth1 dan eth2. Jumlah NIC dan namanya akan bervariasi berdasarkan jenis mesin node GKE.

   eth0
   eth1
   eth2
   lo
   

Menggunakan antarmuka RDMA di node pool yang dioptimalkan untuk penyimpanan

Bagian berikut menjelaskan cara mengonfigurasi node pool dan workload yang dioptimalkan untuk penyimpanan agar dapat menggunakan antarmuka jaringan RDMA dengan GKE DRANET, menggunakan VM Z4M (z4m-highmem-192) sebagai contoh.

Membuat node pool yang dioptimalkan untuk penyimpanan

Buat node pool yang dioptimalkan untuk penyimpanan dengan flag --accelerator-network-profile=auto agar GKE otomatis menyediakan dan memasang jaringan VPC, subnet, dan antarmuka jaringan sekunder Falcon yang mendasarinya. Pada node pool Z4M, GKE mengaktifkan DRANET secara default, sehingga Anda tidak perlu menentukan label node cloud.google.com/gke-networking-dra-driver=true saat membuat node pool. Contoh ini menggunakan jenis mesin z4m-highmem-192, yang memiliki NIC Titanium fisik ganda dan menyediakan dua antarmuka RDMA. Untuk daftar jenis mesin yang didukung, lihat Persyaratan.

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --project=PROJECT_ID \
    --zone=ZONE \
    --machine-type=z4m-highmem-192 \
    --num-nodes=NUM_NODES \
    --accelerator-network-profile=auto

Ganti kode berikut:

• NODE_POOL_NAME: nama node pool baru.
• CLUSTER_NAME: nama cluster Anda.
• PROJECT_ID: Project ID Google Cloud Anda.
• ZONE: zona Google Cloud untuk node pool Anda.
• NUM_NODES: jumlah node di node pool. Untuk menguji traffic RDMA di seluruh node dengan contoh Pod rdma-server dan rdma-client, tentukan minimal 2.

Menyiapkan image container workload yang dioptimalkan untuk penyimpanan

Workload yang menggunakan Cloud RDMA pada node yang dioptimalkan untuk penyimpanan memerlukan image container Rocky Linux 8 dengan library RDMA ruang pengguna kustom (rdma-core) untuk Cloud RDMA yang diinstal. Jangan gunakan paket upstream default; paket tersebut tidak memiliki ekstensi ABI kustom yang diperlukan oleh driver IRDMA host dan gagal saat runtime dengan error -ENOSPC. Untuk memverifikasi penetapan alamat IP dan menguji konektivitas RDMA, instal juga iproute, libibverbs-utils, librdmacm-utils, infiniband-diags, dan perftest.

Untuk contoh Dockerfile yang mengonfigurasi repositori paket yang diperlukan, lihat Menyiapkan image Docker Anda. Dalam perintah dnf install, sertakan iproute agar Anda dapat memeriksa penetapan IP dengan perintah ip. Untuk mengetahui informasi selengkapnya tentang paket yang diperlukan, lihat RPM Cloud RDMA.

Men-deploy workload dengan resource RDMA

Untuk mengalokasikan antarmuka RDMA ke Pod pada node yang dioptimalkan untuk penyimpanan, buat ResourceClaimTemplate yang meminta irdma.google.com DeviceClass:

1. Buat manifes ResourceClaimTemplate dan simpan sebagai irdma-template.yaml:

   apiVersion: resource.k8s.io/v1
   kind: ResourceClaimTemplate
   metadata:
     name: irdma-template
   spec:
     spec:
       devices:
         requests:
         - name: irdma
           exactly:
             deviceClassName: irdma.google.com
             allocationMode: ExactCount
             count: 2
   

   Dalam manifes ini:

   • deviceClassName: irdma.google.com: meminta antarmuka jaringan IRDMA yang dikelola oleh GKE DRANET pada node yang dioptimalkan untuk penyimpanan.
   • allocationMode: ExactCount dan count: 2: meminta kedua antarmuka IRDMA yang tersedia di node z4m-highmem-192. Jika workload Anda hanya memerlukan satu antarmuka RDMA, atau jika Anda menggunakan jenis mesin Z4M yang menyediakan satu antarmuka IRDMA, tentukan 1.

2. Terapkan manifes:

   kubectl apply -f irdma-template.yaml
   

3. Buat manifes yang menentukan dua Pod, rdma-server dan rdma-client, sehingga Anda dapat menguji traffic RDMA antar-node. Setiap Pod menambahkan kemampuan IPC_LOCK dan mereferensikan ResourceClaimTemplate irdma-template. Simpan manifes sebagai irdma-pods.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-server
     labels:
       app: perftest
       role: server
   spec:
     restartPolicy: Never
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["perftest"]
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: perftest
       image: IMAGE_URI
       command: ["sleep", "infinity"]
       securityContext:
         capabilities:
           add: ["IPC_LOCK"]
       resources:
         claims:
         - name: irdma
     resourceClaims:
     - name: irdma
       resourceClaimTemplateName: irdma-template
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-client
     labels:
       app: perftest
       role: client
   spec:
     restartPolicy: Never
     affinity:
       podAntiAffinity:
         requiredDuringSchedulingIgnoredDuringExecution:
         - labelSelector:
             matchExpressions:
             - key: app
               operator: In
               values: ["perftest"]
           topologyKey: "kubernetes.io/hostname"
     containers:
     - name: perftest
       image: IMAGE_URI
       command: ["sleep", "infinity"]
       securityContext:
         capabilities:
           add: ["IPC_LOCK"]
       resources:
         claims:
         - name: irdma
     resourceClaims:
     - name: irdma
       resourceClaimTemplateName: irdma-template
   

   Ganti kedua instance IMAGE_URI dengan URI image container RDMA Rocky Linux 8 Anda.

   Dalam manifes ini:

   • metadata.labels: memberi label pada setiap Pod dengan label app: perftest dan role. Kedua Pod menggunakan label app: perftest yang sama sehingga aturan anti-afinitas berlaku untuk keduanya. Label role membedakan Pod rdma-server (role: server) dari Pod rdma-client (role: client) sehingga Anda dapat menguji konektivitas RDMA Pod-ke-Pod di seluruh node.
   • affinity.podAntiAffinity: mencegah Kubernetes menjadwalkan Pod yang memiliki label app: perftest yang sama di node yang sama. Karena kedua Pod memiliki label ini, keduanya berjalan di host fisik terpisah untuk pengujian RDMA lintas node, bahkan saat ResourceClaimTemplate Anda hanya meminta satu antarmuka (count: 1). Node pool Anda harus memiliki setidaknya dua node untuk menjadwalkan kedua Pod.
   • securityContext.capabilities.add: ["IPC_LOCK"]: memungkinkan container mengunci halaman memori, yang diperlukan agar library ruang pengguna RDMA dapat mendaftarkan region memori untuk akses memori langsung.
   • spec.resourceClaims: menghasilkan ResourceClaim khusus Pod (bernama irdma) dari irdma-template ResourceClaimTemplate.
   • containers.resources.claims: memberikan akses container perftest ke antarmuka yang dialokasikan oleh klaim irdma.

4. Terapkan manifes:

   kubectl apply -f irdma-pods.yaml
   

5. Pastikan antarmuka RDMA yang dialokasikan (rdma0 dan rdma1) terlihat di dalam Pod server:

   kubectl exec rdma-server -- ip -br addr show
   

   Outputnya mirip dengan hal berikut ini:

   lo               UNKNOWN        127.0.0.1/8
   rdma1            UP             10.5.0.3/32
   rdma0            UP             10.31.0.3/32
   eth0@if18        UP             10.120.2.6/32
   

Untuk memverifikasi traffic RDMA antara dua Pod, jalankan rping antara rdma-server dan rdma-client:

1. Mulai server rping di Pod server:

   kubectl exec -it rdma-server -- rping -s -a RDMA_IP -v -d
   

   Ganti RDMA_IP dengan alamat IP rdma0 atau rdma1 Pod server, seperti 10.31.0.3.

2. Di terminal kedua, jalankan klien rping di Pod klien:

   kubectl exec -it rdma-client -- rping -c -a RDMA_IP -C 5 -v -d
   

   Dalam output klien, verifikasi indikator koneksi RDMA yang berhasil berikut:

   • RDMA_CM_EVENT_ADDR_RESOLVED dan RDMA_CM_EVENT_ROUTE_RESOLVED: mengonfirmasi bahwa RDMA Communication Manager me-resolve alamat IP dan rute RDMA target.
   • ESTABLISHED dan rdma_connect successful: mengonfirmasi bahwa klien membuat Queue Pair (qp), Completion Queue (cq), dan Protection Domain (pd), serta membuat koneksi RDMA.
   • Lima entri send completion, recv completion, dan ping data: rdma-ping-: mengonfirmasi bahwa lima iterasi pulang pergi baca dan tulis RDMA selesai melalui antarmuka RDMA sebelum menutup koneksi (destroy cm_id).

Mengaktifkan DRANET dengan ComputeClass kustom

Untuk menggunakan DRANET terkelola GKE di cluster Autopilot atau dengan node auto-provisioning di cluster Standard, Anda harus menggunakan resource ComputeClass kustom untuk mengaktifkan fitur ini.

1. Buat manifes ComputeClass yang mengaktifkan driver DRANET dan menetapkan profil jaringan akselerator ke auto:

   apiVersion: cloud.google.com/v1
   kind: ComputeClass
   metadata:
     name: dranet-compute-class
   spec:
     nodePoolAutoCreation:
       enabled: true
     nodePoolConfig:
       dra:
         networking:
           enabled: true
     priorities:
     - machineType: MACHINE_TYPE
       # Omit the gpu section for storage-optimized VMs (such as Z4M).
       gpu:
         count: GPU_COUNT
         type: GPU_TYPE
       acceleratorNetworkProfile: auto
   

   Ganti kode berikut:

   • MACHINE_TYPE: jenis mesin untuk node pool, seperti a3-ultragpu-8g atau z4m-highmem-192.
   • GPU_COUNT: jumlah GPU untuk jenis mesin.
   • GPU_TYPE: jenis GPU, seperti nvidia-h200.

2. Terapkan manifes:

   kubectl apply -f COMPUTE_CLASS_FILENAME.yaml
   

3. Dalam spesifikasi Pod, referensikan ComputeClass menggunakan pemilih node cloud.google.com/compute-class:

   apiVersion: v1
   kind: Pod
   metadata:
     name: dranet-pod
   spec:
     nodeSelector:
       cloud.google.com/compute-class: "dranet-compute-class"
     ...
   

Meminta sejumlah perangkat jaringan tertentu

Contoh GPU dan TPU sebelumnya menunjukkan cara meminta semua perangkat jaringan yang tersedia dari jenis tertentu dengan menetapkan allocationMode ke All. Untuk meminta jumlah perangkat tertentu, tetapkan allocationMode ke ExactCount di ResourceClaimTemplate, seperti yang ditunjukkan dalam Men-deploy workload dengan resource RDMA.

Contoh berikut meminta dua perangkat jaringan RDMA:

apiVersion: resource.k8s.io/v1
kind: ResourceClaimTemplate
metadata:
  name: two-mrdma
spec:
  spec:
    devices:
      requests:
      - name: req-mrdma
        exactly:
          deviceClassName: mrdma.google.com
          allocationMode: ExactCount
          count: 2

Langkah berikutnya

• Pelajari lebih lanjut Alokasi Resource Dinamis.
• Pelajari lebih lanjut cara Mengonfigurasi jaringan otomatis untuk VM akselerator.