17.3. SR-IOV イーサネットネットワーク割り当ての設定
クラスター内の Single Root I/O Virtualization (SR-IOV) デバイスのイーサネットネットワーク割り当てを設定できます。
次のドキュメントのタスクを実行する前に、SR-IOV Network Operator がインストールされている ことを確認してください。
17.3.1. イーサネットデバイス設定オブジェクト
イーサネットネットワークデバイスは、SriovNetwork
オブジェクトを定義して設定できます。
以下の YAML は SriovNetwork
オブジェクトを説明しています。
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: <name> namespace: openshift-sriov-network-operator spec: resourceName: <sriov_resource_name> networkNamespace: <target_namespace> vlan: <vlan> spoofChk: "<spoof_check>" ipam: |- {} linkState: <link_state> maxTxRate: <max_tx_rate> minTxRate: <min_tx_rate> vlanQoS: <vlan_qos> trust: "<trust_vf>" capabilities: <capabilities>
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
name: <name>
namespace: openshift-sriov-network-operator
spec:
resourceName: <sriov_resource_name>
networkNamespace: <target_namespace>
vlan: <vlan>
spoofChk: "<spoof_check>"
ipam: |-
{}
linkState: <link_state>
maxTxRate: <max_tx_rate>
minTxRate: <min_tx_rate>
vlanQoS: <vlan_qos>
trust: "<trust_vf>"
capabilities: <capabilities>
- 1
- オブジェクトの名前。SR-IOV Network Operator は、同じ名前を持つ
NetworkAttachmentDefinition
オブジェクトを作成します。 - 2
- SR-IOV Network Operator がインストールされている namespace。
- 3
- この追加ネットワークの SR-IOV ハードウェアを定義する
SriovNetworkNodePolicy
オブジェクトのspec.resourceName
パラメーターの値。 - 4
SriovNetwork
オブジェクトのターゲット namespace。ターゲット namespace の Pod のみを追加ネットワークに割り当てることができます。- 5
- オプション: 追加ネットワークの仮想 LAN (VLAN) ID。整数値は
0
から4095
である必要があります。デフォルト値は0
です。 - 6
- オプション: VF の spoof チェックモード。許可される値は、文字列の
"on"
および"off"
です。重要指定する値は引用符で囲む必要があります。引用符で囲まないと、オブジェクトが SR-IOV Network Operator によって拒否されます。
- 7
- YAML ブロックスケーラーとしての IPAM CNI プラグインの設定オブジェクトプラグインは、アタッチメント定義への IP アドレスの割り当てを管理します。
- 8
- オプション: Virtual Function (VF) のリンク状態。許可される値は、
enable
、disable
、およびauto
です。 - 9
- オプション: VF の最大伝送レート (Mbps)。
- 10
- オプション: VF の最小伝送レート (Mbps)。この値は、最大伝送レート以下である必要があります。注記
Intel NIC は
minTxRate
パラメーターをサポートしません。詳細は、BZ#1772847 を参照してください。 - 11
- オプション: VF の IEEE 802.1p 優先度レベル。デフォルト値は
0
です。 - 12
- オプション: VF の信頼モード。許可される値は、文字列の
"on"
および"off"
です。重要指定する値を引用符で囲む必要があります。囲まないと、SR-IOV Network Operator はオブジェクトを拒否します。
- 13
- オプション: この追加ネットワークに設定する機能。
'{ "ips": true }'
を指定して IP アドレスのサポートを有効にするか、'{ "mac": true }'
を指定して MAC アドレスのサポートを有効にすることができます。
17.3.1.1. デュアルスタック IP アドレスを動的に割り当てる設定の作成
デュアルスタックの IP アドレスの割り当ては、ipRanges
パラメーターで設定できます。
- IPv4 アドレス
- IPv6 アドレス
- 複数の IP アドレスの割り当て
手順
-
type
をwhereabouts
に設定します。 以下の例のように、
ipRanges
を使用して IP アドレスを割り当てます。cniVersion: operator.openshift.io/v1 kind: Network =metadata: name: cluster spec: additionalNetworks: - name: whereabouts-shim namespace: default type: Raw rawCNIConfig: |- { "name": "whereabouts-dual-stack", "cniVersion": "0.3.1, "type": "bridge", "ipam": { "type": "whereabouts", "ipRanges": [ {"range": "192.168.10.0/24"}, {"range": "2001:db8::/64"} ] } }
cniVersion: operator.openshift.io/v1 kind: Network =metadata: name: cluster spec: additionalNetworks: - name: whereabouts-shim namespace: default type: Raw rawCNIConfig: |- { "name": "whereabouts-dual-stack", "cniVersion": "0.3.1, "type": "bridge", "ipam": { "type": "whereabouts", "ipRanges": [ {"range": "192.168.10.0/24"}, {"range": "2001:db8::/64"} ] } }
Copy to Clipboard Copied! - ネットワークを Pod にアタッチします。詳細は、「セカンダリーネットワークへの Pod の追加」を参照してください。
- すべての IP アドレスが割り当てられていることを確認します。
以下のコマンドを実行して、IP アドレスがメタデータとして割り当てられることを確認します。
$ oc exec -it mypod -- ip a
$ oc exec -it mypod -- ip a
Copy to Clipboard Copied!
17.3.1.2. ネットワークアタッチメントの IP アドレス割り当ての設定
セカンダリーネットワークでは、Dynamic Host Configuration Protocol (DHCP) や静的割り当てなど、さまざまな割り当て方法をサポートする IP アドレス管理 (IPAM) CNI プラグインを使用して IP アドレスを割り当てることができます。
IP アドレスの動的割り当てを担当する DHCP IPAM CNI プラグインは、2 つの異なるコンポーネントを使用して動作します。
- CNI プラグイン: Kubernetes ネットワークスタックと統合して IP アドレスを要求および解放する役割を担います。
- DHCP IPAM CNI デーモン: 環境内の既存の DHCP サーバーと連携して IP アドレス割り当て要求を処理する DHCP イベントのリスナー。このデーモン自体は DHCP サーバーでは ありません。
IPAM 設定で type: dhcp
を必要とするネットワークの場合は、次の点を確認してください。
- DHCP サーバーが環境内で利用可能かつ実行されている。DHCP サーバーはクラスターの外部にあり、お客様の既存のネットワークインフラストラクチャーの一部である必要があります。
- DHCP サーバーが、ノードに IP アドレスを提供するように適切に設定されている。
環境内で DHCP サーバーが利用可能でない場合は、代わりに Whereabouts IPAM CNI プラグインを使用することを推奨します。Whereabouts CNI は、外部 DHCP サーバーを必要とせずに同様の IP アドレス管理機能を提供します。
外部 DHCP サーバーがない場合、または静的 IP アドレス管理が望ましい場合は、Whereabouts CNI プラグインを使用してください。Whereabouts プラグインには、古くなった IP アドレスの割り当てを管理するためのリコンサイラーデーモンが含まれています。
コンテナーの有効期間中、DHCP リースを定期的に更新する必要があるため、別のデーモンである DHCP IPAM CNI デーモンが必要です。DHCP IPAM CNI デーモンをデプロイするには、セカンダリーネットワーク設定の一部としてこのデーモンのデプロイをトリガーするように Cluster Network Operator (CNO) 設定を変更します。
17.3.1.2.1. 静的 IP アドレス割り当ての設定
以下の表は、静的 IP アドレスの割り当ての設定を説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
|
| 仮想インターフェイスに割り当てる IP アドレスを指定するオブジェクトの配列。IPv4 と IPv6 の IP アドレスの両方がサポートされます。 |
|
| Pod 内で設定するルートを指定するオブジェクトの配列です。 |
|
| オプション: DNS の設定を指定するオブジェクトの配列です。 |
addresses
の配列には、以下のフィールドのあるオブジェクトが必要です。
フィールド | 型 | 説明 |
---|---|---|
|
|
指定する IP アドレスおよびネットワーク接頭辞。たとえば、 |
|
| Egress ネットワークトラフィックをルーティングするデフォルトのゲートウェイ。 |
フィールド | 型 | 説明 |
---|---|---|
|
|
CIDR 形式の IP アドレス範囲 ( |
|
| ネットワークトラフィックがルーティングされるゲートウェイ。 |
フィールド | 型 | 説明 |
---|---|---|
|
| DNS クエリーの送信先となる 1 つ以上の IP アドレスの配列。 |
|
|
ホスト名に追加するデフォルトのドメイン。たとえば、ドメインが |
|
|
DNS ルックアップのクエリー時に非修飾ホスト名に追加されるドメイン名の配列 (例: |
静的 IP アドレス割り当ての設定例
{ "ipam": { "type": "static", "addresses": [ { "address": "191.168.1.7/24" } ] } }
{
"ipam": {
"type": "static",
"addresses": [
{
"address": "191.168.1.7/24"
}
]
}
}
17.3.1.2.2. 動的 IP アドレス (DHCP) 割り当ての設定
Pod は、作成時に元の DHCP リースを取得します。リースは、クラスターで実行している最小限の DHCP サーバーデプロイメントで定期的に更新する必要があります。
イーサネットネットワークアタッチメントの場合、SR-IOV Network Operator は DHCP サーバーデプロイメントを作成しません。Cluster Network Operator は最小限の DHCP サーバーデプロイメントを作成します。
DHCP サーバーのデプロイメントをトリガーするには、以下の例にあるように Cluster Network Operator 設定を編集して shim ネットワーク割り当てを作成する必要があります。
shim ネットワーク割り当ての定義例
apiVersion: operator.openshift.io/v1 kind: Network metadata: name: cluster spec: additionalNetworks: - name: dhcp-shim namespace: default type: Raw rawCNIConfig: |- { "name": "dhcp-shim", "cniVersion": "0.3.1", "type": "bridge", "ipam": { "type": "dhcp" } } # ...
apiVersion: operator.openshift.io/v1
kind: Network
metadata:
name: cluster
spec:
additionalNetworks:
- name: dhcp-shim
namespace: default
type: Raw
rawCNIConfig: |-
{
"name": "dhcp-shim",
"cniVersion": "0.3.1",
"type": "bridge",
"ipam": {
"type": "dhcp"
}
}
# ...
次の表は、DHCP による動的 IP アドレス割り当ての設定パラメーターを示しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
以下の JSON の例は、DHCP を使用した動的 IP アドレスの割り当ての設定を説明しています。
動的 IP アドレス (DHCP) 割り当ての設定例
{ "ipam": { "type": "dhcp" } }
{
"ipam": {
"type": "dhcp"
}
}
17.3.1.2.3. Whereabouts を使用した動的 IP アドレス割り当ての設定
Whereabouts CNI プラグインにより、DHCP サーバーを使用せずに IP アドレスをセカンダリーネットワークに動的に割り当てることができます。
Whereabouts CNI プラグインは、重複する IP アドレス範囲と、別々の NetworkAttachmentDefinitions
CRD 内で同じ CIDR 範囲を複数回設定することもサポートしています。これにより、マルチテナント環境での柔軟性と管理機能が向上します。
17.3.1.2.3.1. 動的 IP アドレス設定オブジェクト
以下の表は、Whereabouts を使用した動的 IP アドレス割り当ての設定オブジェクトを説明しています。
フィールド | 型 | 説明 |
---|---|---|
|
|
IPAM のアドレスタイプ。値 |
|
| IP アドレスと範囲を CIDR 表記。IP アドレスは、この範囲内のアドレスから割り当てられます。 |
|
| オプション: CIDR 表記の IP アドレスと範囲 (0 個以上) のリスト。除外されたアドレス範囲内の IP アドレスは割り当てられません。 |
|
| オプション: 同じ範囲の IP アドレスを共有する場合でも、Pod の各グループまたはドメインが独自の IP アドレスセットを取得するようにします。このフィールドを設定することは、特にマルチテナント環境でネットワークを分離して整理しておく場合に重要です。 |
17.3.1.2.3.2. Whereabouts を使用した動的 IP アドレス割り当て設定
次の例は、Whereabouts を使用する動的アドレス割り当て設定を示しています。
whereabouts 動的 IP アドレスの割り当て
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/27", "exclude": [ "192.0.2.192/30", "192.0.2.196/32" ] } }
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/27",
"exclude": [
"192.0.2.192/30",
"192.0.2.196/32"
]
}
}
17.3.1.2.3.3. IP アドレス範囲が重複する場合に Whereabouts を使用した動的 IP アドレス割り当て
次の例は、マルチテナントネットワークで重複する IP アドレスの範囲を使用する、動的な IP アドレスの割り当てを示しています。
NetworkAttachmentDefinition 1
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/29", "network_name": "example_net_common", } }
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/29",
"network_name": "example_net_common",
}
}
- 1
- 任意。設定されている場合、
NetworkAttachmentDefinition 2
のnetwork_name
と一致する必要があります。
NetworkAttachmentDefinition 2
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/24", "network_name": "example_net_common", } }
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/24",
"network_name": "example_net_common",
}
}
- 1
- 任意。設定されている場合、
NetworkAttachmentDefinition 1
のnetwork_name
と一致する必要があります。
17.3.2. SR-IOV の追加ネットワークの設定
SriovNetwork
オブジェクトを作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。SriovNetwork
オブジェクトの作成時に、SR-IOV Network Operator は NetworkAttachmentDefinition
オブジェクトを自動的に作成します。
SriovNetwork
オブジェクトが running
状態の Pod に割り当てられている場合、これを変更したり、削除したりしないでください。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。
手順
SriovNetwork
オブジェクトを作成してから、YAML を<name>.yaml
ファイルに保存します。<name>
はこの追加ネットワークの名前になります。オブジェクト仕様は以下の例のようになります。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: attach1 namespace: openshift-sriov-network-operator spec: resourceName: net1 networkNamespace: project2 ipam: |- { "type": "host-local", "subnet": "10.56.217.0/24", "rangeStart": "10.56.217.171", "rangeEnd": "10.56.217.181", "gateway": "10.56.217.1" }
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: attach1 namespace: openshift-sriov-network-operator spec: resourceName: net1 networkNamespace: project2 ipam: |- { "type": "host-local", "subnet": "10.56.217.0/24", "rangeStart": "10.56.217.171", "rangeEnd": "10.56.217.181", "gateway": "10.56.217.1" }
Copy to Clipboard Copied! オブジェクトを作成するには、以下のコマンドを入力します。
oc create -f <name>.yaml
$ oc create -f <name>.yaml
Copy to Clipboard Copied! ここで、
<name>
は追加ネットワークの名前を指定します。オプション: 以下のコマンドを実行して、直前の手順で作成した
SriovNetwork
オブジェクトに関連付けられたNetworkAttachmentDefinition
オブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace>
をSriovNetwork
オブジェクトで指定した networkNamespace に置き換えます。oc get net-attach-def -n <namespace>
$ oc get net-attach-def -n <namespace>
Copy to Clipboard Copied!
17.3.3. SR-IOV ネットワークの VRF への割り当て
クラスター管理者は、CNI VRF プラグインを使用して、SR-IOV ネットワークインターフェイスを VRF ドメインに割り当てることができます。
これを実行するには、VRF 設定を SriovNetwork
リソースのオプションの metaPlugins
パラメーターに追加します。
VRF を使用するアプリケーションを特定のデバイスにバインドする必要があります。一般的な使用方法として、ソケットに SO_BINDTODEVICE
オプションを使用できます。SO_BINDTODEVICE
は、渡されるインターフェイス名で指定されているデバイスにソケットをバインドします (例: eth1
)。SO_BINDTODEVICE
を使用するには、アプリケーションに CAP_NET_RAW
機能がある必要があります。
ip vrf exec
コマンドを使用した VRF の使用は、OpenShift Container Platform Pod ではサポートされません。VRF を使用するには、アプリケーションを VRF インターフェイスに直接バインドします。
17.3.3.1. CNI VRF プラグインを使用した追加 SR-IOV ネットワーク割り当ての作成
SR-IOV Network Operator は追加ネットワークの定義を管理します。作成する追加ネットワークを指定する場合、SR-IOV Network Operator は NetworkAttachmentDefinition
カスタムリソース (CR) を自動的に作成します。
SR-IOV Network Operator が管理する NetworkAttachmentDefinition
カスタムリソースは編集しないでください。これを実行すると、追加ネットワークのネットワークトラフィックが中断する可能性があります。
CNI VRF プラグインで追加の SR-IOV ネットワーク割り当てを作成するには、以下の手順を実行します。
前提条件
- OpenShift Container Platform CLI (oc) をインストールします。
- cluster-admin 権限を持つユーザーとして OpenShift Container Platform クラスターにログインします。
手順
追加の SR-IOV ネットワーク割り当て用の
SriovNetwork
カスタムリソース (CR) を作成し、以下のサンプル CR のようにmetaPlugins
設定を挿入します。YAML をsriov-network-attachment.yaml
ファイルとして保存します。SriovNetwork
カスタムリソース (CR) の例apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: example-network namespace: additional-sriov-network-1 spec: ipam: | { "type": "host-local", "subnet": "10.56.217.0/24", "rangeStart": "10.56.217.171", "rangeEnd": "10.56.217.181", "routes": [{ "dst": "0.0.0.0/0" }], "gateway": "10.56.217.1" } vlan: 0 resourceName: intelnics metaPlugins : | { "type": "vrf", "vrfname": "example-vrf-name" }
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: example-network namespace: additional-sriov-network-1 spec: ipam: | { "type": "host-local", "subnet": "10.56.217.0/24", "rangeStart": "10.56.217.171", "rangeEnd": "10.56.217.181", "routes": [{ "dst": "0.0.0.0/0" }], "gateway": "10.56.217.1" } vlan: 0 resourceName: intelnics metaPlugins : | { "type": "vrf",
1 "vrfname": "example-vrf-name"
2 }
Copy to Clipboard Copied! SriovNetwork
リソースを作成します。oc create -f sriov-network-attachment.yaml
$ oc create -f sriov-network-attachment.yaml
Copy to Clipboard Copied!
NetworkAttachmentDefinition
CR が正常に作成されることの確認
以下のコマンドを実行して、SR-IOV Network Operator が
NetworkAttachmentDefinition
CR を作成していることを確認します。oc get network-attachment-definitions -n <namespace>
$ oc get network-attachment-definitions -n <namespace>
1 Copy to Clipboard Copied! - 1
<namespace>
を、ネットワーク割り当ての設定時に指定した namespace に置き換えます (例:additional-sriov-network-1
)。
出力例
NAME AGE additional-sriov-network-1 14m
NAME AGE additional-sriov-network-1 14m
Copy to Clipboard Copied! 注記SR-IOV Network Operator が CR を作成するまでに遅延が生じる可能性があります。
追加の SR-IOV ネットワーク割り当てが正常であることの確認
VRF CNI が正しく設定され、追加の SR-IOV ネットワーク割り当てが接続されていることを確認するには、以下を実行します。
- VRF CNI を使用する SR-IOV ネットワークを作成します。
- ネットワークを Pod に割り当てます。
Pod のネットワーク割り当てが SR-IOV の追加ネットワークに接続されていることを確認します。Pod にリモートシェルを実行し、以下のコマンドを実行します。
ip vrf show
$ ip vrf show
Copy to Clipboard Copied! 出力例
Name Table ----------------------- red 10
Name Table ----------------------- red 10
Copy to Clipboard Copied! 次のコマンドを実行して、VRF インターフェイスがセカンダリーインターフェイスの
master
であることを確認します。ip link
$ ip link
Copy to Clipboard Copied! 出力例
... 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode ...
... 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode ...
Copy to Clipboard Copied!
17.3.4. イーサネットベースの SR-IOV 割り当てのランタイム設定
Pod を追加のネットワークに割り当てる場合、ランタイム設定を指定して Pod の特定のカスタマイズを行うことができます。たとえば、特定の MAC ハードウェアアドレスを要求できます。
Pod 仕様にアノテーションを設定して、ランタイム設定を指定します。アノテーションキーは k8s.v1.cni.cncf.io/networks
で、ランタイム設定を記述する JSON オブジェクトを受け入れます。
以下の JSON は、イーサネットベースの SR-IOV ネットワーク割り当て用のランタイム設定オプションを説明しています。
[ { "name": "<name>", "mac": "<mac_address>", "ips": ["<cidr_range>"] } ]
[
{
"name": "<name>",
"mac": "<mac_address>",
"ips": ["<cidr_range>"]
}
]
- 1
- SR-IOV ネットワーク割り当て定義 CR の名前。
- 2
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの MAC アドレス。この機能を使用するには、
SriovNetwork
オブジェクトで{ "mac": true }
も指定する必要があります。 - 3
- オプション: SR-IOV ネットワーク割り当て定義 CR で定義されるリソースタイプから割り当てられる SR-IOV デバイスの IP アドレス。IPv4 と IPv6 アドレスの両方がサポートされます。この機能を使用するには、
SriovNetwork
オブジェクトで{ "ips": true }
も指定する必要があります。
ランタイム設定の例
apiVersion: v1 kind: Pod metadata: name: sample-pod annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "net1", "mac": "20:04:0f:f1:88:01", "ips": ["192.168.10.1/24", "2001::1/64"] } ] spec: containers: - name: sample-container image: <image> imagePullPolicy: IfNotPresent command: ["sleep", "infinity"]
apiVersion: v1
kind: Pod
metadata:
name: sample-pod
annotations:
k8s.v1.cni.cncf.io/networks: |-
[
{
"name": "net1",
"mac": "20:04:0f:f1:88:01",
"ips": ["192.168.10.1/24", "2001::1/64"]
}
]
spec:
containers:
- name: sample-container
image: <image>
imagePullPolicy: IfNotPresent
command: ["sleep", "infinity"]
17.3.5. セカンダリーネットワークに Pod を追加する
セカンダリーネットワークに Pod を追加できます。Pod は、デフォルトネットワークで通常のクラスター関連のネットワークトラフィックを継続的に送信します。
Pod が作成されると、セカンダリーネットワークが Pod にアタッチされます。ただし、Pod がすでに存在する場合は、セカンダリーネットワークをその Pod にアタッチすることはできません。
Pod はセカンダリーネットワークと同じ namespace に存在する必要があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 - クラスターにログインする。
手順
アノテーションを
Pod
オブジェクトに追加します。以下のアノテーション形式のいずれかのみを使用できます。カスタマイズせずにセカンダリーネットワークをアタッチするには、次の形式でアノテーションを追加します。
<network>
が、Pod に関連付けるセカンダリーネットワークの名前に置き換えます。metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...]
1 Copy to Clipboard Copied! - 1
- 複数のセカンダリーネットワークを指定するには、各ネットワークをコンマで区切ります。コンマの間にはスペースを入れないでください。同じセカンダリーネットワークを複数回指定した場合、Pod は複数のネットワークインターフェイスをそのネットワークにアタッチします。
カスタマイズしてセカンダリーネットワークをアタッチするには、次の形式でアノテーションを追加します。
metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>", "namespace": "<namespace>", "default-route": ["<default-route>"] } ]
metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>",
1 "namespace": "<namespace>",
2 "default-route": ["<default-route>"]
3 } ]
Copy to Clipboard Copied!
Pod を作成するには、以下のコマンドを入力します。
<name>
を Pod の名前に置き換えます。oc create -f <name>.yaml
$ oc create -f <name>.yaml
Copy to Clipboard Copied! オプション: アノテーションが
Pod
CR に存在することを確認するには、<name>
を Pod の名前に置き換えて、以下のコマンドを入力します。oc get pod <name> -o yaml
$ oc get pod <name> -o yaml
Copy to Clipboard Copied! 次の例では、
example-pod
Pod がnet1
セカンダリーネットワークにアタッチされています。oc get pod example-pod -o yaml
$ oc get pod example-pod -o yaml apiVersion: v1 kind: Pod metadata: annotations: k8s.v1.cni.cncf.io/networks: macvlan-bridge k8s.v1.cni.cncf.io/network-status: |-
1 [{ "name": "ovn-kubernetes", "interface": "eth0", "ips": [ "10.128.2.14" ], "default": true, "dns": {} },{ "name": "macvlan-bridge", "interface": "net1", "ips": [ "20.2.2.100" ], "mac": "22:2f:60:a5:f8:00", "dns": {} }] name: example-pod namespace: default spec: ... status: ...
Copy to Clipboard Copied! - 1
k8s.v1.cni.cncf.io/network-status
パラメーターは、オブジェクトの JSON 配列です。各オブジェクトは、Pod にアタッチされているセカンダリーネットワークのステータスを表します。アノテーションの値はプレーンテキストの値として保存されます。
17.3.5.1. vfio-pci SR-IOV デバイスの MTU を Pod に公開する
追加のネットワークに Pod を追加した後、SR-IOV ネットワークで MTU が使用可能であることを確認できます。
手順
次のコマンドを実行して、Pod アノテーションに MTU が含まれていることを確認します。
oc describe pod example-pod
$ oc describe pod example-pod
Copy to Clipboard Copied! 次の例はサンプル出力を示しています。
"mac": "20:04:0f:f1:88:01", "mtu": 1500, "dns": {}, "device-info": { "type": "pci", "version": "1.1.0", "pci": { "pci-address": "0000:86:01.3" } }
"mac": "20:04:0f:f1:88:01", "mtu": 1500, "dns": {}, "device-info": { "type": "pci", "version": "1.1.0", "pci": { "pci-address": "0000:86:01.3" } }
Copy to Clipboard Copied! 次のコマンドを実行して、Pod 内の
/etc/podnetinfo/
で MTU が使用可能であることを確認します。oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
$ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
Copy to Clipboard Copied! 次の例はサンプル出力を示しています。
k8s.v1.cni.cncf.io/network-status="[{ \"name\": \"ovn-kubernetes\", \"interface\": \"eth0\", \"ips\": [ \"10.131.0.67\" ], \"mac\": \"0a:58:0a:83:00:43\", \"default\": true, \"dns\": {} },{ \"name\": \"sriov-tests/sriov-nic-1\", \"interface\": \"net1\", \"ips\": [ \"192.168.10.1\" ], \"mac\": \"20:04:0f:f1:88:01\", \"mtu\": 1500, \"dns\": {}, \"device-info\": { \"type\": \"pci\", \"version\": \"1.1.0\", \"pci\": { \"pci-address\": \"0000:86:01.3\" } } }]"
k8s.v1.cni.cncf.io/network-status="[{ \"name\": \"ovn-kubernetes\", \"interface\": \"eth0\", \"ips\": [ \"10.131.0.67\" ], \"mac\": \"0a:58:0a:83:00:43\", \"default\": true, \"dns\": {} },{ \"name\": \"sriov-tests/sriov-nic-1\", \"interface\": \"net1\", \"ips\": [ \"192.168.10.1\" ], \"mac\": \"20:04:0f:f1:88:01\", \"mtu\": 1500, \"dns\": {}, \"device-info\": { \"type\": \"pci\", \"version\": \"1.1.0\", \"pci\": { \"pci-address\": \"0000:86:01.3\" } } }]"
Copy to Clipboard Copied!
17.3.6. SR-IOV ネットワークポリシーの更新中に並列ノードドレインを設定する
デフォルトでは、SR-IOV Network Operator は、ポリシーを変更するたびに、ノードからワークロードをドレイン (解放) します。Operator は、再設定によってワークロードが影響を受けないように、一度に 1 つのノードに対してこのアクションを実行します。
大規模なクラスターでは、ノードを順番にドレインするには時間がかかり、数時間または数日かかることもあります。時間に敏感な環境では、SriovNetworkPoolConfig
カスタムリソース (CR) で並列ノードドレインを有効にして、SR-IOV ネットワーク設定のロールアウトを高速化できます。
並列ドレインを設定するには、SriovNetworkPoolConfig
CR を使用してノードプールを作成します。次に、プールにノードを追加し、Operator が並行してドレインできるプール内のノードの最大数を定義できます。このアプローチでは、実行中のワークロードを処理するために十分なノードがプール内に残っていることを確認しながら、並列ドレインを有効にして再設定を高速化できます。
ノードは 1 つの SR-IOV ネットワークプール設定にのみ属することができます。ノードがプールの一部でない場合は、一度に 1 つのノードのみをドレインするように設定された仮想のデフォルトプールに追加されます。
ドレイン処理中にノードが再起動する可能性があります。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
cluster-admin
権限を持つユーザーとしてログインしている。 - SR-IOV Network Operator をインストールします。
- ノードには SR-IOV をサポートするハードウェアがあります。
手順
SriovNetworkPoolConfig
リソースを作成します。SriovNetworkPoolConfig
リソースを定義する YAML ファイルを作成します。sriov-nw-pool.yaml
ファイルの例apiVersion: v1 kind: SriovNetworkPoolConfig metadata: name: pool-1 namespace: openshift-sriov-network-operator spec: maxUnavailable: 2 nodeSelector: matchLabels: node-role.kubernetes.io/worker: ""
apiVersion: v1 kind: SriovNetworkPoolConfig metadata: name: pool-1
1 namespace: openshift-sriov-network-operator
2 spec: maxUnavailable: 2
3 nodeSelector:
4 matchLabels: node-role.kubernetes.io/worker: ""
Copy to Clipboard Copied! - 1
SriovNetworkPoolConfig
オブジェクトの名前を指定します。- 2
- SR-IOV Network Operator がインストールされている namespace を指定します。
- 3
- 更新中にプール内で使用できなくなるノードの整数値またはパーセンテージ値を指定します。たとえば、ノードが 10 個あり、使用不可の最大数を 2 に設定した場合は、一度に並列ドレインできるノードは 2 個だけとなり、ワークロードの処理には 8 個のノードが残ります。
- 4
- ノードセレクターを使用して、プールを追加するノードを指定します。この例では、
worker
ロールを持つすべてのノードをプールに追加します。
次のコマンドを実行して、
SriovNetworkPoolConfig
リソースを作成します。oc create -f sriov-nw-pool.yaml
$ oc create -f sriov-nw-pool.yaml
Copy to Clipboard Copied!
次のコマンドを実行して、
sriov-test
namespace を作成します。oc create namespace sriov-test
$ oc create namespace sriov-test
Copy to Clipboard Copied! SriovNetworkNodePolicy
リソースを作成します。SriovNetworkNodePolicy
リソースを定義する YAML ファイルを作成します。sriov-node-policy.yaml
ファイルの例apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: sriov-nic-1 namespace: openshift-sriov-network-operator spec: deviceType: netdevice nicSelector: pfNames: ["ens1"] nodeSelector: node-role.kubernetes.io/worker: "" numVfs: 5 priority: 99 resourceName: sriov_nic_1
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: sriov-nic-1 namespace: openshift-sriov-network-operator spec: deviceType: netdevice nicSelector: pfNames: ["ens1"] nodeSelector: node-role.kubernetes.io/worker: "" numVfs: 5 priority: 99 resourceName: sriov_nic_1
Copy to Clipboard Copied! 次のコマンドを実行して、
SriovNetworkNodePolicy
リソースを作成します。oc create -f sriov-node-policy.yaml
$ oc create -f sriov-node-policy.yaml
Copy to Clipboard Copied!
SriovNetwork
リソースを作成します。SriovNetwork
リソースを定義する YAML ファイルを作成します。sriov-network.yaml
ファイルの例apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: sriov-nic-1 namespace: openshift-sriov-network-operator spec: linkState: auto networkNamespace: sriov-test resourceName: sriov_nic_1 capabilities: '{ "mac": true, "ips": true }' ipam: '{ "type": "static" }'
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: sriov-nic-1 namespace: openshift-sriov-network-operator spec: linkState: auto networkNamespace: sriov-test resourceName: sriov_nic_1 capabilities: '{ "mac": true, "ips": true }' ipam: '{ "type": "static" }'
Copy to Clipboard Copied! 次のコマンドを実行して、
SriovNetwork
リソースを作成します。oc create -f sriov-network.yaml
$ oc create -f sriov-network.yaml
Copy to Clipboard Copied!
検証
次のコマンドを実行して、作成したノードプールを表示します。
oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
$ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
Copy to Clipboard Copied! 出力例
NAME AGE pool-1 67s
NAME AGE pool-1 67s
1 Copy to Clipboard Copied! - 1
- この例では、
pool-1
にはworker
ロールを持つすべてのノードが含まれています。
上記の手順のシナリオ例を使用してノードドレインプロセスをデモンストレーションするには、次の手順を実行します。
クラスター内のワークロードのドレインをトリガーするには、
SriovNetworkNodePolicy
リソース内の Virtual Function の数を更新します。oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
$ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
Copy to Clipboard Copied! 次のコマンドを実行して、ターゲットクラスターのドレインステータスを監視します。
oc get sriovNetworkNodeState -n openshift-sriov-network-operator
$ oc get sriovNetworkNodeState -n openshift-sriov-network-operator
Copy to Clipboard Copied! 出力例
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 InProgress Drain_Required DrainComplete 3d10h openshift-sriov-network-operator worker-1 InProgress Drain_Required DrainComplete 3d10h
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 InProgress Drain_Required DrainComplete 3d10h openshift-sriov-network-operator worker-1 InProgress Drain_Required DrainComplete 3d10h
Copy to Clipboard Copied! ドレインプロセスが完了すると、
SYNC STATUS
がSucceeded
に変わり、DESIRED SYNC STATE
とCURRENT SYNC STATE
の値がIDLE
に戻ります。出力例
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 Succeeded Idle Idle 3d10h openshift-sriov-network-operator worker-1 Succeeded Idle Idle 3d10h
NAMESPACE NAME SYNC STATUS DESIRED SYNC STATE CURRENT SYNC STATE AGE openshift-sriov-network-operator worker-0 Succeeded Idle Idle 3d10h openshift-sriov-network-operator worker-1 Succeeded Idle Idle 3d10h
Copy to Clipboard Copied!
17.3.7. NUMA 対応スケジューリングのための SR-IOV ネットワークトポロジーの除外
SR-IOV ネットワークリソースの Non-Uniform Memory Access (NUMA) ノードを Topology Manager にアドバタイズする場合を除外するには、SriovNetworkNodePolicy
カスタムリソースで excludeTopology
仕様を設定できます。NUMA 対応 Pod のスケジューリングでより柔軟な SR-IOV ネットワークデプロイメントを行うには、この設定を使用します。
前提条件
-
OpenShift CLI (
oc
) がインストールされている。 -
CPU マネージャーのポリシーを
static
に設定している。CPU マネージャーの詳細は、関連情報 セクションを参照してください。 -
Topology Manager ポリシーを
single-numa-node
に設定している。 - SR-IOV Network Operator がインストールされている。
手順
SriovNetworkNodePolicy
CR を作成します。次の YAML を
sriov-network-node-policy.yaml
ファイルに保存し、環境に合わせて YAML 内の値を置き換えます。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: <policy_name> namespace: openshift-sriov-network-operator spec: resourceName: sriovnuma0 nodeSelector: kubernetes.io/hostname: <node_name> numVfs: <number_of_Vfs> nicSelector: vendor: "<vendor_ID>" deviceID: "<device_ID>" deviceType: netdevice excludeTopology: true
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetworkNodePolicy metadata: name: <policy_name> namespace: openshift-sriov-network-operator spec: resourceName: sriovnuma0
1 nodeSelector: kubernetes.io/hostname: <node_name> numVfs: <number_of_Vfs> nicSelector:
2 vendor: "<vendor_ID>" deviceID: "<device_ID>" deviceType: netdevice excludeTopology: true
3 Copy to Clipboard Copied! 注記複数の
SriovNetworkNodePolicy
リソースが同じ SR-IOV ネットワークリソースをターゲットとする場合、SriovNetworkNodePolicy
リソースの値はexcludeTopology
仕様と同じである必要があります。そうでない場合、矛盾するポリシーは拒否されます。次のコマンドを実行して、
SriovNetworkNodePolicy
リソースを作成します。oc create -f sriov-network-node-policy.yaml
$ oc create -f sriov-network-node-policy.yaml
Copy to Clipboard Copied! 出力例
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
Copy to Clipboard Copied!
SriovNetwork
CR を作成します。次の YAML を
sriov-network.yaml
ファイルに保存します。その場合、YAML 内の値は環境に合わせて置き換えます。apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: sriov-numa-0-network namespace: openshift-sriov-network-operator spec: resourceName: sriovnuma0 networkNamespace: <namespace> ipam: |- { "type": "<ipam_type>", }
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: sriov-numa-0-network
1 namespace: openshift-sriov-network-operator spec: resourceName: sriovnuma0
2 networkNamespace: <namespace>
3 ipam: |-
4 { "type": "<ipam_type>", }
Copy to Clipboard Copied! 次のコマンドを実行して、
SriovNetwork
リソースを作成します。oc create -f sriov-network.yaml
$ oc create -f sriov-network.yaml
Copy to Clipboard Copied! 出力例
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
Copy to Clipboard Copied!
Pod を作成し、前の手順で作成した SR-IOV ネットワークリソースを割り当てます。
次の YAML を
sriov-network-pod.yaml
ファイルに保存します。その場合、YAML 内の値は環境に合わせて置き換えます。apiVersion: v1 kind: Pod metadata: name: <pod_name> annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "sriov-numa-0-network", } ] spec: containers: - name: <container_name> image: <image> imagePullPolicy: IfNotPresent command: ["sleep", "infinity"]
apiVersion: v1 kind: Pod metadata: name: <pod_name> annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "sriov-numa-0-network",
1 } ] spec: containers: - name: <container_name> image: <image> imagePullPolicy: IfNotPresent command: ["sleep", "infinity"]
Copy to Clipboard Copied! - 1
- これは、
SriovNetworkNodePolicy
リソースを使用するSriovNetwork
リソースの名前です。
次のコマンドを実行して、
Pod
リソースを作成します。oc create -f sriov-network-pod.yaml
$ oc create -f sriov-network-pod.yaml
Copy to Clipboard Copied! 出力例
pod/example-pod created
pod/example-pod created
Copy to Clipboard Copied!
検証
次のコマンドを実行して、Pod のステータスを確認します。その場合、
<pod_name>
は Pod の名前に置き換えます。oc get pod <pod_name>
$ oc get pod <pod_name>
Copy to Clipboard Copied! 出力例
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
Copy to Clipboard Copied! ターゲット Pod とのデバッグセッションを開き、SR-IOV ネットワークリソースがメモリーおよび CPU リソースとは異なるノードにデプロイされていることを確認します。
次のコマンドを実行して、Pod とのデバッグセッションを開きます。その場合、<pod_name> はターゲット Pod の名前に置き換えます。
oc debug pod/<pod_name>
$ oc debug pod/<pod_name>
Copy to Clipboard Copied! /host
をデバッグシェル内の root ディレクトリーとして設定します。デバッグ Pod は、Pod 内の/host
にホストからのルートファイルシステムをマウントします。ルートディレクトリーを/host
に変更すると、ホストファイルシステムからのバイナリーを実行できます。chroot /host
$ chroot /host
Copy to Clipboard Copied! 次のコマンドを実行して、CPU 割り当てに関する情報を表示します。
lscpu | grep NUMA
$ lscpu | grep NUMA
Copy to Clipboard Copied! 出力例
NUMA node(s): 2 NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,... NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,...
NUMA node(s): 2 NUMA node0 CPU(s): 0,2,4,6,8,10,12,14,16,18,... NUMA node1 CPU(s): 1,3,5,7,9,11,13,15,17,19,...
Copy to Clipboard Copied! cat /proc/self/status | grep Cpus
$ cat /proc/self/status | grep Cpus
Copy to Clipboard Copied! 出力例
Cpus_allowed: aa Cpus_allowed_list: 1,3,5,7
Cpus_allowed: aa Cpus_allowed_list: 1,3,5,7
Copy to Clipboard Copied! cat /sys/class/net/net1/device/numa_node
$ cat /sys/class/net/net1/device/numa_node
Copy to Clipboard Copied! 出力例
0
0
Copy to Clipboard Copied! この例では、CPU 1、3、5、7 が
NUMA node1
に割り当てられていますが、SR-IOV ネットワークリソースはNUMA node0
の NIC を使用できます。
excludeTopology
仕様が True
に設定されている場合、必要なリソースが同じ NUMA ノードに存在する可能性があります。