Menyiapkan jaringan SR-IOV

Dokumen ini menjelaskan cara menyiapkan networking virtualisasi input/output (SR-IOV) root tunggal untuk GKE di Bare Metal. SR-IOV menyediakan virtualisasi I/O untuk membuat kartu antarmuka jaringan (NIC), yang tersedia sebagai perangkat jaringan di kernel Linux. Dengan begitu, Anda dapat mengelola dan menetapkan koneksi jaringan ke pod Anda. Performa meningkat karena paket bergerak langsung antara NIC dan pod.

Gunakan fitur ini jika Anda memerlukan jaringan yang cepat ke workload pod Anda. SR-IOV untuk GKE di Bare Metal memungkinkan Anda mengonfigurasi fungsi virtual (VF) pada perangkat node cluster yang didukung. Anda juga dapat menentukan modul kernel tertentu untuk diikat ke VF.

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

Proses penyiapan terdiri dari langkah-langkah tingkat tinggi berikut:

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

Persyaratan

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

Mengaktifkan jaringan SR-IOV untuk cluster

Guna mengaktifkan jaringan SR-IOV untuk GKE di Bare Metal, tambahkan kolom multipleNetworkInterfaces dan kolom sriovOperator ke bagian clusterNetwork dari objek Cluster, lalu 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 berubah, dan dapat diubah setelah pembuatan cluster.

Mengonfigurasi operator SR-IOV

Resource kustom SriovOperatorConfig menyediakan konfigurasi global untuk fitur jaringan SR-IOV. Resource kustom yang dipaketkan ini memiliki nama default dan berada dalam namespace gke-operators. Resource kustom SriovOperatorConfig diterapkan hanya 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 yang dapat ditangani operator SR-IOV. Pada contoh sebelumnya, operator dibatasi hanya untuk node yang memiliki label nodePool: withSriov. Jika kolom configDaemonNodeSelector tidak ditentukan, label default berikut akan diterapkan:

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

Kolom disableDrain menentukan apakah akan menjalankan operasi pengosongan node Kubernetes sebelum node harus dimulai ulang atau sebelum konfigurasi VF tertentu diubah.

Membuat kebijakan SR-IOV

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

Berikut adalah 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 lanjut node tempat VF harus dibuat. Batasan ini berada di atas pemilih dari SriovOperatorConfig yang dijelaskan di bagian sebelumnya.

Kolom deviceType menentukan modul kernel yang akan digunakan untuk VF. Opsi yang tersedia 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 akan berisi resource yang ditentukan seperti yang ditampilkan 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 setidaknya satu pemilih di bagian nicSelector. Kolom ini berisi beberapa opsi cara mengidentifikasi fungsi fisik (PF) tertentu di node cluster Anda. Sebagian besar informasi yang diperlukan oleh kolom ini telah ditemukan dan disimpan di 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 pada bagian nicSelector. Selain menentukan PF yang tepat, Anda juga dapat menentukan VF yang tepat untuk digunakan untuk PF yang ditentukan 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"

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

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

Memahami prioritas kebijakan

Anda dapat menentukan beberapa objek SriovNetworkNodePolicy untuk menangani berbagai vendor atau konfigurasi VF yang berbeda. Mengelola beberapa objek dan vendor dapat merepotkan jika beberapa kebijakan merujuk pada PF yang sama. Untuk menangani situasi seperti itu, kolom priority akan menyelesaikan konflik per node.

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

  1. Kebijakan dengan prioritas yang lebih tinggi akan menimpa kebijakan yang memiliki prioritas lebih rendah hanya saat partisi PF tumpang-tindih.

  2. Kebijakan dengan prioritas yang sama digabungkan:

    1. Kebijakan diurutkan menurut 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 digabungkan dan semua kebijakan

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

Bagian berikut memberikan contoh kebijakan untuk konfigurasi partisi yang berbeda.

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 yang 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, yang 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 lebih tinggi daripada policy-2, karena partisi PF tidak tumpang-tindih, kami menggabungkan kedua kebijakan tersebut.

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 akhir node di resource kustom SriovNetworkNodeState untuk node tertentu. Di bagian status, kolom syncStatus mewakili tahap saat ini untuk daemon konfigurasi. Status Succeeded menunjukkan bahwa konfigurasi telah selesai. Bagian spec dari resource kustom SriovNetworkNodeState menentukan status akhir konfigurasi VF untuk Node tersebut, berdasarkan jumlah kebijakan dan prioritasnya. 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 berhasil mengonfigurasi VF di cluster, dan VF terlihat di Node Kubernetes sebagai resource, Anda perlu membuat NetworkAttachmentDefinition yang mereferensikan resource tersebut. Buat referensi dengan anotasi k8s.v1.cni.cncf.io/resourceName. Berikut adalah contoh manifes NetworkAttachmentDefinition yang merujuk ke 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. Referensikan semua resource kustom NetworkAttachmentDefinition yang di-deploy di pod Anda dengan anotasi k8s.v1.cni.cncf.io/networks.

Berikut ini contoh cara mereferensikan resource kustom NetworkAttachmentDefinition sebelumnya dalam pod:

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

Saat mereferensikan resource kustom NetworkAttachmentDefinition dalam workload, Anda tidak perlu khawatir dengan definisi resource Pod, atau penempatannya 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 jaringan SR-IOV.

Memulai ulang node

Saat operator SR-IOV mengonfigurasi node, node mungkin perlu dimulai ulang. Memulai ulang node mungkin diperlukan selama konfigurasi VF atau kernel. Konfigurasi kernel melibatkan pengaktifan dukungan fungsi SR-IOV dalam sistem operasi.

Adaptor Jaringan yang Didukung

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

Nama ID Vendor ID Perangkat ID perangkat VF
Intel i40e XXV710 8086 158a 154c
Intel i40e 25G SFP28 8086 158 M 154c
Intel i40e 10G X710 SFP 8086 1572 154c
Intel i40e XXV710 N3000 8086 0h58 154c
Intel i40e 40G XL710 QSFP 8086 1583 154c
Intel Ice Columbiaville E810-CQDA2 2CQDA2 8086 1.592 1889
Intel Ice Columbiaville E810-XXVDA4 8086 1593 1889
Intel Ice Columbiaville E810-XXVDA2 8086 159 m 1889
Nvidia mlx5 ConnectX-4 15b3 1013 1014
Nvidia mlx5 ConnectX-4LX 15b3 1015 1016
Nvidia mlx5 ConnectX-5 15b3 1017 1018
Nvidia mlx5 ConnectX-5 Ex 15b3 1019 101a
Nvidia mlx5 ConnectX-6 15b3 101 M 101c
Nvidia mlx5 ConnectX-6_Dx 15b3 101 hr 101e
Nvidia mlx5 MT42822 BlueField-2 ConnectX-6 Dx terintegrasi 15b3 A2D6 101e
Broadcom bnxt BCM57414 2x25G 14e4 16h7 16dc
Broadcom bnxt BCM75508 2x100G 14e4 1750 1806