Dokumen ini menjelaskan cara menyiapkan jaringan 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 kernel Linux. Dengan demikian, Anda dapat mengelola dan menetapkan koneksi jaringan ke pod. Performa ditingkatkan karena paket bergerak langsung antara NIC dan pod.
Gunakan fitur ini jika Anda memerlukan jaringan yang cepat untuk 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 kernel tertentu untuk diikat ke VF.
Fitur ini tersedia untuk cluster yang menjalankan workload, seperti cluster hybrid, mandiri, dan pengguna. Fitur jaringan SR-IOV mengharuskan cluster memiliki minimal dua node.
Proses penyiapan terdiri dari langkah-langkah tingkat tinggi berikut:
- Konfigurasi cluster untuk mengaktifkan jaringan SR-IOV.
- Konfigurasi operator SR-IOV, resource kustom
SriovOperatorConfig
. - Siapkan kebijakan SR-IOV dan konfigurasi VF Anda.
- Buat resource kustom
NetworkAttachmentDefinition
yang mereferensikan VF Anda.
Persyaratan
Fitur jaringan SR-IOV memerlukan driver resmi untuk adaptor jaringan agar ada di node cluster. Instal driver sebelum menggunakan
operator SR-IOV. Selain itu, untuk menggunakan modul vfio-pci
untuk VF, pastikan
modul tersedia di node tempat modul akan digunakan.
Mengaktifkan jaringan SR-IOV untuk cluster
Untuk mengaktifkan jaringan SR-IOV untuk Google Distributed Cloud, tambahkan kolom
multipleNetworkInterfaces
dan
sriovOperator
ke bagian clusterNetwork
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 kustom gabungan ini memiliki nama default
dan berada di namespace gke-operators
. Resource kustom SriovOperatorConfig
hanya berlaku 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 oleh operator SR-IOV. Dalam contoh sebelumnya, operator hanya dibatasi 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 melakukan operasi pengurasan node Kubernetes
sebelum node harus di-reboot atau sebelum konfigurasi VF
tertentu diubah.
Membuat kebijakan SR-IOV
Untuk mengonfigurasi VF tertentu di cluster, Anda harus membuat resource kustom SriovNetworkNodePolicy
di 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 VFvfio-pci
untuk driver VFIO-PCI
resourceName
menentukan nama VF ditampilkan di Node Kubernetes.
Setelah proses konfigurasi selesai, node cluster yang Anda pilih akan berisi resource yang ditentukan 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
pemilih di bagian nicSelector
. Kolom ini berisi beberapa opsi tentang cara mengidentifikasi fungsi fisik (PF) tertentu di node cluster Anda. Sebagian besar informasi yang diperlukan oleh kolom ini ditemukan untuk Anda dan disimpan dalam resource kustom SriovNetworkNodeState
. Akan ada objek per setiap node yang dapat ditangani oleh 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 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
Menetapkan partisi Physical Function
Berikan perhatian khusus pada kolom pfNames
di bagian nicSelector
. Selain menentukan PF yang tepat untuk digunakan, Anda juga dapat menentukan VF yang tepat untuk digunakan bagi 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
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
, harus setidaknya sama
dengan nilai penutup 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 minimal 5
.
Jika partisi tidak ditentukan, numVfs
akan menentukan rentang VF yang digunakan, yang selalu dimulai dari nol. Misalnya, jika Anda menyetel 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 beberapa objek dan vendor dapat menjadi masalah jika beberapa kebijakan mereferensikan PF yang sama. Untuk menangani situasi tersebut, kolom priority
menyelesaikan konflik berdasarkan per-node.
Berikut logika pemrioritasan untuk kebijakan PF yang tumpang-tindih:
Kebijakan dengan prioritas lebih tinggi akan menggantikan kebijakan dengan prioritas lebih rendah hanya jika partisi PF tumpang-tindih.
Kebijakan dengan prioritas yang sama digabungkan:
- Kebijakan diurutkan menurut nama dan diproses dalam urutan tersebut
- Kebijakan dengan partisi PF yang tumpang-tindih akan ditimpa
- Kebijakan dengan partisi PF yang tidak tumpang-tindih digabungkan dan semuanya ada
Kebijakan prioritas tinggi adalah kebijakan dengan nilai numerik yang lebih rendah di kolom priority
. Misalnya, prioritas lebih tinggi untuk kebijakan dengan priority: 10
,
daripada untuk kebijakan dengan priority: 20
.
Bagian berikut memberikan contoh kebijakan untuk berbagai konfigurasi partisi.
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 akan membuat 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
, 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 yang lebih tinggi
daripada policy-2
, karena partisi PF tidak tumpang-tindih, kita 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 dalam resource kustom SriovNetworkNodeState
untuk node tertentu. Di bagian status
, kolom syncStatus
merepresentasikan
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 tersebut 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 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.
Referensi resource kustom NetworkAttachmentDefinition
yang di-deploy di pod Anda dengan anotasi k8s.v1.cni.cncf.io/networks
.
Berikut adalah 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 mengkhawatirkan definisi resource Pod, atau penempatan di
Node tertentu, yang dilakukan secara otomatis untuk Anda.
Contoh berikut menunjukkan resource kustom NetworkAttachmentDefinition
dengan
konfigurasi VLAN. Dalam contoh ini, setiap VF termasuk dalam 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.
Mulai ulang node
Saat operator SR-IOV mengonfigurasi node, node mungkin perlu di-reboot. Mulai ulang node mungkin diperlukan selama konfigurasi VF atau kernel. Konfigurasi kernel melibatkan pengaktifan dukungan fungsi SR-IOV di sistem operasi.
Adaptor Jaringan yang Didukung
Tabel berikut mencantumkan adaptor jaringan yang didukung untuk cluster versi 1.33.x:
Nama | ID Vendor | ID Perangkat | ID perangkat VF |
---|---|---|---|
Intel i40e XXV710 | 8086 | 158a | 154c |
Intel i40e 25G SFP28 | 8086 | 158b | 154c |
Intel i40e 10G X710 SFP | 8086 | 1572 | 154c |
Intel i40e XXV710 N3000 | 8086 | 0d58 | 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 | 159b | 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 | 101b | 101c |
Nvidia mlx5 ConnectX-6_Dx | 15b3 | 101d | 101e |
Nvidia mlx5 MT42822 BlueField-2 terintegrasi ConnectX-6 Dx | 15b3 | a2d6 | 101e |
Broadcom bnxt BCM57414 2x25G | 14e4 | 16d7 | 16dc |
Broadcom bnxt BCM75508 2x100G | 14e4 | 1750 | 1806 |