Menyiapkan jaringan SR-IOV

Dokumen ini menjelaskan cara menyiapkan virtualisasi input/output root tunggal (SR-IOV) untuk Google Distributed Cloud. SR-IOV menyediakan virtualisasi I/O untuk membuat kartu antarmuka jaringan (NIC), tersedia sebagai perangkat jaringan di Linux {i>kernel<i}. Hal ini memungkinkan Anda mengelola dan menetapkan koneksi jaringan ke pod Anda. Performa meningkat karena paket berpindah langsung antara NIC dan pod.

Gunakan fitur ini jika Anda memerlukan jaringan yang cepat ke workload pod Anda. SR-IOV untuk Google Distributed Cloud memungkinkan Anda mengonfigurasi fungsi virtual (VF) di perangkat yang didukung dari node cluster Anda. Anda juga dapat menentukan modul {i>kernel<i} untuk mengikat ke VF.

Fitur ini tersedia untuk cluster yang menjalankan workload, seperti hibrida, mandiri, dan cluster pengguna. Fitur jaringan SR-IOV mengharuskan cluster memiliki minimal dua node.

Proses penyiapan terdiri dari langkah-langkah tingkat tinggi berikut:

1. Konfigurasi cluster untuk mengaktifkan jaringan SR-IOV.
2. Konfigurasi operator SR-IOV, resource kustom SriovOperatorConfig.
3. Siapkan kebijakan SR-IOV dan konfigurasikan VF Anda.
4. Buat resource kustom NetworkAttachmentDefinition yang mereferensikan VF.

Persyaratan

Fitur jaringan SR-IOV memerlukan {i>driver<i} resmi untuk jaringan adaptor yang ada di node cluster. Instal {i>driver<i} sebelum menggunakan operator SR-IOV. Selain itu, agar dapat menggunakan modul vfio-pci untuk VF, pastikan bahwa modul tersedia pada {i> node <i}tempatnya akan digunakan.

Mengaktifkan jaringan SR-IOV untuk cluster

Untuk mengaktifkan jaringan SR-IOV untuk Google Distributed Cloud, tambahkan multipleNetworkInterfaces dan sriovOperator ke bagian clusterNetwork pada objek Cluster dan tetapkan kedua kolom ke true.

apiVersion: baremetal.cluster.gke.io/v1
kind: Cluster
metadata:
  name: cluster1
spec:
  clusterNetwork:
    multipleNetworkInterfaces: true
    sriovOperator: true
...

Kolom sriovOperator dapat diubah, dan dapat diubah setelah pembuatan cluster.

Mengonfigurasi operator SR-IOV

Resource kustom SriovOperatorConfig menyediakan konfigurasi global untuk fitur jaringan SR-IOV. Resource khusus yang dipaketkan ini memiliki nama default dan berada dalam namespace gke-operators. Kustom SriovOperatorConfig resource hanya diterima untuk nama dan namespace ini.

Anda dapat mengedit objek ini dengan perintah berikut:

kubectl -n gke-operators edit sriovoperatorconfigs.sriovnetwork.k8s.cni.cncf.io default

Berikut adalah contoh konfigurasi resource kustom SriovOperatorConfig:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovOperatorConfig
metadata:
  name: default
  namespace: gke-operators
spec:
  configDaemonNodeSelector:
    nodePool: "withSriov"
  disableDrain: false
  logLevel: 0

Bagian configDaemonNodeSelector memungkinkan Anda membatasi node mana yang digunakan oleh SR-IOV dapat ditangani oleh operator. Dalam contoh sebelumnya, operator dibatasi hanya untuk node yang memiliki label nodePool: withSriov. Jika configDaemonNodeSelector kolom tidak ditentukan, label default berikut akan diterapkan:

beta.kubernetes.io/os: linux
node-role.kubernetes.io/worker: ""

Kolom disableDrain menentukan apakah akan melakukan pengurasan node Kubernetes sebelum {i>node<i} harus dimulai ulang atau sebelum {i>node<i} VF tertentu jika konfigurasi berubah.

Membuat kebijakan SR-IOV

Untuk mengonfigurasi VF tertentu dalam cluster, Anda harus membuat Resource kustom SriovNetworkNodePolicy di namespace gke-operators.

Berikut contoh manifes untuk resource kustom SriovNetworkNodePolicy:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-1
  namespace: gke-operators
spec:
  deviceType: "netdevice"
  mtu: 1600
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
  nicSelector:
    pfNames:
    - enp65s0f0
    deviceID: "1015"
    rootDevices:
    - 0000:01:00.0
    vendor: "15b3"
  numVfs: 4
  priority: 80
  resourceName: "mlnx"

Bagian nodeSelector memungkinkan Anda membatasi lebih jauh node tempat VF harus dibuat. Keterbatasan ini berada di atas pemilih dari SriovOperatorConfig dijelaskan di bagian sebelumnya.

Kolom deviceType menentukan modul kernel yang akan digunakan untuk VF. Tersedia opsi untuk deviceType adalah:

• netdevice untuk modul kernel standar khusus VF
• vfio-pci untuk driver VFIO-PCI

resourceName menentukan nama VF yang direpresentasikan dalam Node Kubernetes.

Setelah proses konfigurasi selesai, node cluster yang Anda pilih berisi sumber daya yang didefinisikan seperti yang ditunjukkan dalam contoh berikut (perhatikan gke.io/mlnx):

apiVersion: v1
kind: Node
metadata:
  name: worker-01
spec:
…
status:
  allocatable:
    cpu: 47410m
    ephemeral-storage: "210725550141"
    gke.io/mlnx: "4"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 59884492Ki
    pods: "250"
  capacity:
    cpu: "48"
    ephemeral-storage: 228651856Ki
    gke.io/mlnx: "4"
    hugepages-1Gi: "0"
    hugepages-2Mi: "0"
    memory: 65516492Ki
    pods: "250"

Operator akan selalu menambahkan awalan gke.io/ ke setiap resource yang Anda tentukan dengan SriovNetworkNodePolicy.

Menentukan pemilih NIC

Agar SriovNetworkNodePolicy berfungsi dengan baik, tentukan minimal satu di bagian nicSelector. Bidang ini berisi beberapa opsi tentang cara mengidentifikasi fungsi fisik tertentu (PF) di node cluster Anda. Sebagian besar informasi yang dibutuhkan oleh isian ini ditemukan untuk Anda dan disimpan dalam Resource kustom SriovNetworkNodeState. Akan ada objek per setiap node yang dapat ditangani operator ini.

Gunakan perintah berikut untuk melihat semua node yang tersedia:

kubectl -n gke-operators get sriovnetworknodestates.sriovnetwork.k8s.cni.cncf.io -o yaml

Berikut adalah contoh node:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodeState
metadata:
  name: worker-01
  namespace: gke-operators
spec:
  dpConfigVersion: "6368949"
status:
  interfaces:
  - deviceID: "1015"
    driver: mlx5_core
    eSwitchMode: legacy
    linkSpeed: 10000 Mb/s
    linkType: ETH
    mac: 1c:34:da:5c:2b:9c
    mtu: 1500
    name: enp1s0f0
    pciAddress: "0000:01:00.0"
    totalvfs: 4
    vendor: 15b3
  - deviceID: "1015"
    driver: mlx5_core
    linkSpeed: 10000 Mb/s
    linkType: ETH
    mac: 1c:34:da:5c:2b:9d
    mtu: 1500
    name: enp1s0f1
    pciAddress: "0000:01:00.1"
    totalvfs: 2
    vendor: 15b3
  syncStatus: Succeeded

Menyetel partisi Fungsi Fisik

Berikan perhatian khusus pada kolom pfNames di bagian nicSelector. Di beberapa selain menentukan PF yang tepat untuk digunakan, ini memungkinkan Anda menentukan VF yang tepat untuk digunakan untuk PF dan resource yang ditentukan dalam kebijakan.

Berikut contohnya:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: policy-1
  namespace: gke-operators
spec:
  deviceType: "netdevice"
  mtu: 1600
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
  nicSelector:
    pfNames:
    - enp65s0f0#3-6
    deviceID: "1015"
    rootDevices:
    - 0000:01:00.0
    vendor: "15b3"
  numVfs: 7
  priority: 80
  resourceName: "mlnx"

Pada contoh sebelumnya, resource gke.io/mlnx hanya menggunakan VF bernomor 3-6 dan hanya menampilkan empat VF yang tersedia. Karena VF selalu dibuat dari indeks nol, jumlah VF yang Anda minta, numVfs, minimal harus setinggi sebagai nilai penutup rentang (dihitung dari nol). Logika penomoran ini adalah mengapa Dalam contoh sebelumnya, numVfs disetel ke 7. Jika Anda menetapkan rentang dari 3 hingga 4 (enp65s0f0#3-4), numVfs Anda minimal harus 5.

Jika partisi tidak ditentukan, numVfs akan menentukan rentang VF yang yang digunakan, yang selalu dimulai dari nol. Misalnya, jika Anda menetapkan numVfs=3 tanpa menentukan partisi, VF 0-2 akan digunakan.

Memahami prioritas kebijakan

Anda dapat menentukan beberapa objek SriovNetworkNodePolicy untuk menangani berbagai vendor atau konfigurasi VF yang berbeda. Mengelola banyak objek dan vendor bisa menjadi masalah ketika banyak kebijakan merujuk pada PF yang sama. Untuk ditangani situasi tersebut, kolom priority akan menyelesaikan konflik per node.

Berikut adalah logika penentuan prioritas untuk kebijakan PF yang tumpang-tindih:

1. Kebijakan dengan prioritas yang lebih tinggi akan menimpa kebijakan dengan prioritas yang lebih rendah hanya jika Partisi PF tumpang tindih.

2. Kebijakan prioritas yang sama digabungkan:

   1. Kebijakan diurutkan berdasarkan nama dan diproses dalam urutan tersebut
   2. Kebijakan dengan partisi PF yang tumpang-tindih akan ditimpa
   3. Kebijakan dengan partisi PF yang tidak tumpang-tindih akan digabungkan dan semuanya ada

Kebijakan prioritas tinggi adalah kebijakan dengan nilai numerik yang lebih rendah dalam priority kolom tersebut. Misalnya, prioritasnya lebih tinggi untuk kebijakan dengan priority: 10, dibandingkan dengan kebijakan dengan priority: 20.

Bagian berikut memberikan contoh kebijakan untuk berbagai partisi konfigurasi standar.

PF yang dipartisi

Men-deploy dua manifes SriovNetworkNodePolicy berikut akan menghasilkan dua resource yang tersedia: gke.io/dev-kernel dan gke.io/dev-vfio. Setiap resource memiliki dua VF yang tidak tumpang-tindih.

kind: SriovNetworkNodePolicy
metadata:
  name: policy-1
spec:
  deviceType: "netdevice"
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
  nicSelector:
    pfNames:
    - enp65s0f0#0-1
  numVfs: 2
  priority: 70
  resourceName: "dev-kernel"

kind: SriovNetworkNodePolicy
metadata:
  name: policy-2
spec:
  deviceType: "vfio-pci"
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
  nicSelector:
    pfNames:
    - enp65s0f0#2-3
  numVfs: 4
  priority: 70
  resourceName: "dev-vfio"

Partisi PF yang tumpang-tindih

Men-deploy dua manifes SriovNetworkNodePolicy berikut hanya menghasilkan resource gke.io/dev-vfio tersedia. Rentang VF policy-1 adalah 0-2, yang tumpang-tindih dengan policy-2. Karena penamaan, policy-2 diproses setelah policy-1. Oleh karena itu, hanya resource yang ditentukan dalam policy-2, gke.io/dev-vfio, tersedia.

kind: SriovNetworkNodePolicy
metadata:
  name: policy-1
spec:
  deviceType: "netdevice"
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
  nicSelector:
    pfNames:
    - enp65s0f0
  numVfs: 3
  priority: 70
  resourceName: "dev-kernel"

kind: SriovNetworkNodePolicy
metadata:
  name: policy-2
spec:
  deviceType: "vfio-pci"
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
  nicSelector:
    pfNames:
    - enp65s0f0#2-3
  numVfs: 4
  priority: 70
  resourceName: "dev-vfio"

Partisi PF yang tidak tumpang-tindih dengan prioritas yang berbeda

Men-deploy dua manifes SriovNetworkNodePolicy berikut akan menghasilkan dua resource yang tersedia: gke.io/dev-kernel dan gke.io/dev-vfio. Setiap resource memiliki dua VF yang tidak tumpang-tindih. Meskipun policy-1 memiliki prioritas yang lebih tinggi daripada policy-2, karena partisi PF tidak tumpang-tindih, kita menggabungkan keduanya kebijakan izin yang relevan.

kind: SriovNetworkNodePolicy
metadata:
  name: policy-1
spec:
  deviceType: "netdevice"
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
  nicSelector:
    pfNames:
    - enp65s0f0
  numVfs: 2
  priority: 10
  resourceName: "dev-kernel"

kind: SriovNetworkNodePolicy
metadata:
  name: policy-2
spec:
  deviceType: "vfio-pci"
  nodeSelector:
    baremetal.cluster.gke.io/node-pool: node-pool-1
  nicSelector:
    pfNames:
    - enp65s0f0#2-3
  numVfs: 4
  priority: 70
  resourceName: "dev-vfio"

Memeriksa status penyiapan kebijakan SR-IOV

Saat menerapkan kebijakan SR-IOV, Anda dapat melacak dan melihat konfigurasi node dalam resource kustom SriovNetworkNodeState untuk ke node tertentu. Di bagian status, kolom syncStatus mewakili tahap saat ini untuk daemon konfigurasi. Status Succeeded menunjukkan konfigurasi tersebut selesai. Bagian spec dari Resource kustom SriovNetworkNodeState menentukan status akhir VF untuk Node tersebut, berdasarkan jumlah kebijakan dan prioritas Anda. Semua VF yang dibuat akan dicantumkan di bagian status untuk PF yang ditentukan.

Berikut adalah contoh resource kustom SriovNetworkNodeState:

apiVersion: sriovnetwork.k8s.cni.cncf.io/v1
kind: SriovNetworkNodeState
metadata:
  name: worker-02
  namespace: gke-operators
spec:
  dpConfigVersion: "9022068"
  interfaces:
  - linkType: eth
    name: enp1s0f0
    numVfs: 2
    pciAddress: "0000:01:00.0"
    vfGroups:
    - deviceType: netdevice
      policyName: policy-1
      resourceName: mlnx
      vfRange: 0-1
status:
  interfaces:
  - Vfs:
    - deviceID: "1016"
      driver: mlx5_core
      mac: 96:8b:39:d8:89:d2
      mtu: 1500
      name: enp1s0f0np0v0
      pciAddress: "0000:01:00.2"
      vendor: 15b3
      vfID: 0
    - deviceID: "1016"
      driver: mlx5_core
      mac: 82:8e:65:fe:9b:cb
      mtu: 1500
      name: enp1s0f0np0v1
      pciAddress: "0000:01:00.3"
      vendor: 15b3
      vfID: 1
    deviceID: "1015"
    driver: mlx5_core
    eSwitchMode: legacy
    linkSpeed: 10000 Mb/s
    linkType: ETH
    mac: 1c:34:da:5c:2b:9c
    mtu: 1500
    name: enp1s0f0
    numVfs: 2
    pciAddress: "0000:01:00.0"
    totalvfs: 2
    vendor: 15b3
  - deviceID: "1015"
    driver: mlx5_core
    linkSpeed: 10000 Mb/s
    linkType: ETH
    mac: 1c:34:da:5c:2b:9d
    mtu: 1500
    name: enp1s0f1
    pciAddress: "0000:01:00.1"
    totalvfs: 2
    vendor: 15b3
  syncStatus: Succeeded

Membuat resource kustom NetworkAttachmentDefinition

Setelah Anda berhasil mengonfigurasi VF di cluster, dan VF tersebut akan terlihat di Node Kubernetes sebagai resource, Anda harus membuat NetworkAttachmentDefinition yang mereferensikan resource. Buat referensi dengan anotasi k8s.v1.cni.cncf.io/resourceName. Berikut adalah contoh manifes NetworkAttachmentDefinition yang mereferensikan Resource gke.io/mlnx:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-sriov-1
  annotations:
    k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx
spec:
  config: '{
      "cniVersion": "0.3.0",
      "name": "mynetwork",
      "type": "sriov",
      "ipam": {
        "type": "whereabouts",
        "range": "21.0.108.0/21",
        "range_start": "21.0.111.16",
        "range_end": "21.0.111.18"
      }
    }'

NetworkAttachmentDefinition harus memiliki sriov sebagai jenis CNI. Merujuk ke resource kustom NetworkAttachmentDefinition yang di-deploy di pod dengan anotasi k8s.v1.cni.cncf.io/networks.

Berikut contoh cara mereferensikan NetworkAttachmentDefinition resource kustom dalam pod:

apiVersion: v1
kind: Pod
metadata:
  name: samplepod
  annotations:
    k8s.v1.cni.cncf.io/networks: gke-sriov-1
spec:
  containers:
  ...

Saat merujuk ke resource kustom NetworkAttachmentDefinition dalam workload, Anda tidak perlu mengkhawatirkan Pod definisi sumber daya, atau penempatan dalam Node tertentu, yang dilakukan secara otomatis untuk Anda.

Contoh berikut menunjukkan resource kustom NetworkAttachmentDefinition dengan konfigurasi VLAN. Dalam contoh ini, setiap VF adalah milik VLAN 100:

apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: gke-sriov-vlan-100
  annotations:
    k8s.v1.cni.cncf.io/resourceName: gke.io/mlnx
spec:
  config: '{
      "cniVersion": "0.3.0",
      "name": "mynetwork",
      "type": "sriov",
      "vlan": 100,
      "ipam": {
        "type": "whereabouts",
        "range": "21.0.100.0/21"
      }
    }'

Informasi tambahan

Bagian berikut berisi informasi untuk membantu Anda mengonfigurasi SR-IOV berjejaring (netrworking){b>.<b}

Memulai ulang node

Ketika operator SR-IOV mengkonfigurasi {i> node<i}, {i>node<i} mungkin perlu dimulai ulang. Mulai ulang node mungkin diperlukan selama konfigurasi VF atau kernel. Tujuan konfigurasi {i>kernel<i} melibatkan pengaktifan dukungan fungsionalitas SR-IOV dalam yang dibutuhkan serta sistem operasi.

Adaptor Jaringan yang Didukung

Tabel berikut mencantumkan adaptor jaringan yang didukung untuk versi 1.30.x cluster: