18.3. SR-IOV 이더넷 네트워크 연결 구성
클러스터에서 SR-IOV(Single Root I/O Virtualization) 장치에 대한 이더넷 네트워크 연결을 구성할 수 있습니다.
다음 문서에서 작업을 수행하기 전에 SR-IOV Network Operator를 설치 했는지 확인합니다.
18.3.1. 이더넷 장치 구성 오브젝트
SriovNetwork
오브젝트를 정의하여 이더넷 네트워크 장치를 구성할 수 있습니다.
다음 YAML은 SriovNetwork
오브젝트를 설명합니다.
apiVersion: sriovnetwork.openshift.io/v1 kind: SriovNetwork metadata: name: <name> 1 namespace: openshift-sriov-network-operator 2 spec: resourceName: <sriov_resource_name> 3 networkNamespace: <target_namespace> 4 vlan: <vlan> 5 spoofChk: "<spoof_check>" 6 ipam: |- 7 {} linkState: <link_state> 8 maxTxRate: <max_tx_rate> 9 minTxRate: <min_tx_rate> 10 vlanQoS: <vlan_qos> 11 trust: "<trust_vf>" 12 capabilities: <capabilities> 13
- 1
- 오브젝트의 이름입니다. SR-IOV Network Operator는 동일한 이름으로
NetworkAttachmentDefinition
오브젝트를 생성합니다. - 2
- SR-IOV Network Operator가 설치된 네임스페이스입니다.
- 3
- 이 추가 네트워크에 대한 SR-IOV 하드웨어를 정의하는
SriovNetworkNodePolicy
오브젝트의spec.resourceName
매개변수 값입니다. - 4
SriovNetwork
오브젝트의 대상 네임스페이스입니다. 대상 네임스페이스의 포드만 추가 네트워크에 연결할 수 있습니다.- 5
- 선택사항: 추가 네트워크의 VLAN(Virtual LAN) ID입니다. 정수 값은
0
에서4095
사이여야 합니다. 기본값은0
입니다. - 6
- 선택사항: VF의 스푸핑 검사 모드입니다. 허용되는 값은 문자열
"on"
및"off"
입니다.중요SR-IOV Network Operator가 지정한 값을 따옴표로 묶거나 오브젝트를 거부해야 합니다.
- 7
- YAML 블록 스칼라로서의 IPAM CNI 플러그인의 구성 오브젝트입니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.
- 8
- 선택사항: VF(가상 기능)의 링크 상태입니다. 허용되는 값은
enable
,disable
및auto
입니다. - 9
- 선택사항: VF의 경우 최대 전송 속도(Mbps)입니다.
- 10
- 선택사항: VF의 경우 최소 전송 속도(Mbps)입니다. 이 값은 최대 전송 속도보다 작거나 같아야 합니다.참고
인텔 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 주소 지원을 활성화할 수 있습니다.
18.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"} ] } }
- Pod에 네트워크를 연결합니다. 자세한 내용은 "추가 네트워크에 Pod 추가"를 참조하십시오.
- 모든 IP 주소가 할당되었는지 확인합니다.
다음 명령을 실행하여 IP 주소가 메타데이터로 할당되었는지 확인합니다.
$ oc exec -it mypod -- ip a
18.3.1.2. 네트워크 연결을 위한 IP 주소 할당 구성
추가 네트워크의 경우 DHCP(Dynamic Host Configuration Protocol) 및 고정 할당을 포함하여 다양한 할당 방법을 지원하는 IPAM(IP Address Management) CNI 플러그인을 사용하여 IP 주소를 할당할 수 있습니다.
IP 주소의 동적 할당을 담당하는 DHCP IPAM CNI 플러그인은 다음 두 가지 구성 요소로 작동합니다.
- CNI 플러그인: Kubernetes 네트워킹 스택과 통합하여 IP 주소를 요청 및 릴리스할 수 있습니다.
- DHCP IPAM CNI Daemon: IP 주소 할당 요청을 처리하기 위해 환경의 기존 DHCP 서버와 조정하는 DHCP 이벤트의 리스너입니다. 이 데몬은 DHCP 서버 자체가 아닙니다.
type: dhcp
를 IPAM 구성에 필요한 네트워크의 경우 다음을 확인합니다.
- DHCP 서버가 사용 가능하며 환경에서 실행됩니다. DHCP 서버는 클러스터 외부에 있으며 고객의 기존 네트워크 인프라의 일부가 될 것으로 예상됩니다.
- DHCP 서버는 노드에 IP 주소를 제공하도록 적절하게 구성됩니다.
환경에서 DHCP 서버를 사용할 수 없는 경우 대신 Whereabouts IPAM CNI 플러그인을 사용하는 것이 좋습니다. Whereabouts CNI는 외부 DHCP 서버 없이도 유사한 IP 주소 관리 기능을 제공합니다.
외부 DHCP 서버가 없거나 고정 IP 주소 관리를 선호하는 경우 Whereabouts CNI 플러그인을 사용합니다. Whereabouts 플러그인에는 오래된 IP 주소 할당을 관리하기 위한 조정기 데몬이 포함되어 있습니다.
DHCP 리스는 컨테이너 수명 동안 주기적으로 갱신해야 하므로 별도의 데몬인 DHCP IPAM CNI Daemon이 필요합니다. DHCP IPAM CNI 데몬을 배포하려면 CNO(Cluster Network Operator) 구성을 수정하여 이 데몬의 배포를 추가 네트워크 설정의 일부로 트리거합니다.
18.3.1.2.1. 고정 IP 주소 할당 구성
다음 표에서는 고정 IP 주소 할당 구성에 대해 설명합니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
IPAM 주소 유형입니다. |
|
| 가상 인터페이스에 할당할 IP 주소를 지정하는 오브젝트의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다. |
|
| Pod 내부에서 구성할 경로를 지정하는 오브젝트의 배열입니다. |
|
| 선택 사항: DNS 구성을 지정하는 오브젝트 배열입니다. |
address
배열에는 다음 필드가 있는 오브젝트가 필요합니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 |
|
| 송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다. |
필드 | 유형 | 설명 |
---|---|---|
|
|
CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 |
|
| 네트워크 트래픽이 라우팅되는 게이트웨이입니다. |
필드 | 유형 | 설명 |
---|---|---|
|
| DNS 쿼리를 보낼 하나 이상의 IP 주소로 이루어진 배열입니다. |
|
|
호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 |
|
|
DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: |
고정 IP 주소 할당 구성 예
{ "ipam": { "type": "static", "addresses": [ { "address": "191.168.1.7/24" } ] } }
18.3.1.2.2. DHCP(Dynamic IP 주소) 할당 구성
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" } } # ...
다음 표에서는 DHCP를 사용한 동적 IP 주소 할당을 위한 구성 매개 변수에 대해 설명합니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
IPAM 주소 유형입니다. |
다음 JSON 예제에서는 DHCP를 사용한 동적 IP 주소 할당을 위한 구성 p를 설명합니다.
DHCP(Dynamic IP 주소) 할당 구성 예
{ "ipam": { "type": "dhcp" } }
18.3.1.2.3. Whereabouts를 사용한 동적 IP 주소 할당 구성
Whereabouts CNI 플러그인을 사용하면 DHCP 서버를 사용하지 않고도 IP 주소를 추가 네트워크에 동적으로 할당할 수 있습니다.
Whereabouts CNI 플러그인은 별도의 NetworkAttachmentDefinition
CRD 내에서 동일한 CIDR 범위의 중복 IP 주소 범위 및 구성을 여러 번 지원합니다. 이를 통해 멀티 테넌트 환경에서 유연성 및 관리 기능이 향상됩니다.
18.3.1.2.3.1. 동적 IP 주소 구성 오브젝트
다음 표에서는 Whereabouts를 사용하여 동적 IP 주소 할당을 위한 구성 오브젝트를 설명합니다.
필드 | 유형 | 설명 |
---|---|---|
|
|
IPAM 주소 유형입니다. 여기서about |
|
| CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다. |
|
| 선택 사항: CIDR 표기법의 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다. |
|
| 선택 사항: Pod의 각 그룹 또는 도메인이 동일한 IP 주소 범위를 공유하는 경우에도 자체 IP 주소 집합을 갖도록 합니다. 이 필드를 설정하는 것은 특히 다중 테넌트 환경에서 네트워크를 분리하고 정리하는 데 중요합니다. |
18.3.1.2.3.2. Whereabouts를 사용하는 동적 IP 주소 할당 구성
다음 예제에서는 Whereabouts를 사용하는 동적 주소 할당 구성을 보여줍니다.
Whereabouts dynamic IP address assignment
{ "ipam": { "type": "whereabouts", "range": "192.0.2.192/27", "exclude": [ "192.0.2.192/30", "192.0.2.196/32" ] } }
18.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", 1
}
}
- 1
- 선택 사항: 설정된 경우
NetworkAttachmentDefinition 2
의network_name
과 일치해야 합니다.
NetworkAttachmentDefinition 2
{
"ipam": {
"type": "whereabouts",
"range": "192.0.2.192/24",
"network_name": "example_net_common", 1
}
}
- 1
- 선택 사항: 설정된 경우
NetworkAttachmentDefinition 1
의network_name
과 일치해야 합니다.
18.3.2. SR-IOV 추가 네트워크 구성
SriovNetwork
오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovNetwork
오브젝트를 생성하면 SR-IOV Network Operator가 NetworkAttachmentDefinition
오브젝트를 자동으로 생성합니다.
SriovNetwork
오브젝트가 running
상태의 Pod에 연결된 경우 해당 오브젝트를 수정하거나 삭제하지 마십시오.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. -
cluster-admin
권한이 있는 사용자로 로그인합니다.
프로세스
SriovNetwork
오브젝트를 생성한 다음<name>.yaml
파일에 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" }
오브젝트를 생성하려면 다음 명령을 입력합니다:
$ oc create -f <name>.yaml
여기서
<name>
은 추가 네트워크의 이름을 지정합니다.선택사항: 이전 단계에서 생성한
SriovNetwork
오브젝트에 연결된NetworkAttachmentDefinition
오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다.<namespace>
를SriovNetwork
오브젝트에 지정한 networkNamespace로 바꿉니다.$ oc get net-attach-def -n <namespace>
18.3.3. SR-IOV 네트워크를 VRF에 할당
클러스터 관리자는 CNI VRF 플러그인을 사용하여 SR-IOV 네트워크 인터페이스를 VRF 도메인에 할당할 수 있습니다.
이렇게 하려면 SriovNetwork
리소스의 선택적 metaPlugins
매개변수에 VRF 구성을 추가합니다.
VRF를 사용하는 애플리케이션은 특정 장치에 바인딩해야 합니다. 일반적인 사용은 소켓에 SO_BINDTODEVICE
옵션을 사용하는 것입니다. SO_BINDTODEVICE
는 소켓을 전달된 인터페이스 이름(예: eth1
)에 지정된 장치에 바인딩합니다. SO_BINDTODEVICE
를 사용하려면 애플리케이션에 CAP_NET_RAW
기능이 있어야 합니다.
OpenShift Container Platform Pod에서는 ip vrf exec
명령을 통해 VRF를 사용할 수 없습니다. VRF를 사용하려면 애플리케이션을 VRF 인터페이스에 직접 바인딩합니다.
18.3.3.1. CNI VRF 플러그인으로 추가 SR-IOV 네트워크 연결 생성
SR-IOV Network Operator는 추가 네트워크 정의를 관리합니다. 생성할 추가 SR-IOV 네트워크를 지정하면 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", 1 "vrfname": "example-vrf-name" 2 }
SriovNetwork
리소스를 생성합니다.$ oc create -f sriov-network-attachment.yaml
NetworkAttachmentDefinition
CR이 성공적으로 생성되었는지 확인
SR-IOV Network Operator가 다음 명령을 실행하여
NetworkAttachmentDefinition
CR을 생성했는지 확인합니다.$ oc get network-attachment-definitions -n <namespace> 1
- 1
<namespace>
를 네트워크 연결을 구성할 때 지정한 네임스페이스(예:additional-sriov-network-1
)로 바꿉니다.
출력 예
NAME AGE additional-sriov-network-1 14m
참고SR-IOV Network Operator가 CR을 생성하기 전에 지연이 발생할 수 있습니다.
추가 SR-IOV 네트워크 연결에 성공했는지 확인
VRF CNI가 올바르게 구성되어 추가 SR-IOV 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.
- VRF CNI를 사용하는 SR-IOV 네트워크를 생성합니다.
- 포드에 네트워크를 할당합니다.
포드 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. Pod로 원격 쉘을 설치하고 다음 명령을 실행합니다.
$ ip vrf show
출력 예
Name Table ----------------------- red 10
다음 명령을 실행하여 VRF 인터페이스가 보조 인터페이스의
마스터
인지 확인합니다.$ ip link
출력 예
... 5: net1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master red state UP mode ...
18.3.4. 이더넷 기반 SR-IOV 연결을 위한 런타임 구성
추가 네트워크에 pod를 연결할 때 런타임 구성을 지정하여 pod에 대한 특정 사용자 정의를 수행할 수 있습니다. 예를 들어 특정 MAC 하드웨어 주소를 요청할 수 있습니다.
Pod 사양에서 주석을 설정하여 런타임 구성을 지정합니다. 주석 키는 k8s.v1.cni.cncf.io/networks
이며 런타임 구성을 설명하는 JSON 오브젝트를 허용합니다.
다음 JSON은 이더넷 기반 SR-IOV 네트워크 연결에 대한 런타임 구성 옵션을 설명합니다.
[ { "name": "<name>", 1 "mac": "<mac_address>", 2 "ips": ["<cidr_range>"] 3 } ]
- 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"]
18.3.5. 추가 네트워크에 Pod 추가
추가 네트워크에 Pod를 추가할 수 있습니다. Pod는 기본 네트워크를 통해 정상적인 클러스터 관련 네트워크 트래픽을 계속 전송합니다.
Pod가 생성되면 추가 네트워크가 연결됩니다. 그러나 Pod가 이미 있는 경우에는 추가 네트워크를 연결할 수 없습니다.
Pod는 추가 네트워크와 동일한 네임스페이스에 있어야 합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)를 설치합니다. - 클러스터에 로그인합니다.
프로세스
Pod
오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.사용자 정의 없이 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.
<network>
를 Pod와 연결할 추가 네트워크의 이름으로 변경합니다.metadata: annotations: k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
- 1
- 둘 이상의 추가 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
사용자 정의된 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.
metadata: annotations: k8s.v1.cni.cncf.io/networks: |- [ { "name": "<network>", 1 "namespace": "<namespace>", 2 "default-route": ["<default-route>"] 3 } ]
Pod를 생성하려면 다음 명령을 입력합니다.
<name>
을 Pod 이름으로 교체합니다.$ oc create -f <name>.yaml
선택사항:
Pod
CR에 주석이 있는지 확인하려면 다음 명령을 입력하고<name>
을 Pod 이름으로 교체합니다.$ oc get pod <name> -o yaml
다음 예에서
example-pod
Pod는net1
추가 네트워크에 연결되어 있습니다.$ 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: ...
- 1
k8s.v1.cni.cncf.io/network-status
매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.
18.3.5.1. vfio-pci SR-IOV 장치의 MTU를 Pod에 노출
추가 네트워크에 Pod를 추가한 후 SR-IOV 네트워크에 MTU를 사용할 수 있는지 확인할 수 있습니다.
프로세스
다음 명령을 실행하여 pod 주석에 MTU가 포함되어 있는지 확인합니다.
$ oc describe pod example-pod
다음 예제에서는 샘플 출력을 보여줍니다.
"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" } }
다음 명령을 실행하여 pod 내부의
/etc/podnetinfo/
에서 MTU를 사용할 수 있는지 확인합니다.$ oc exec example-pod -n sriov-tests -- cat /etc/podnetinfo/annotations | grep mtu
다음 예제에서는 샘플 출력을 보여줍니다.
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\" } } }]"
18.3.6. SR-IOV 네트워크 정책 업데이트 중 병렬 노드 드레이닝 구성
기본적으로 SR-IOV Network Operator는 모든 정책이 변경되기 전에 노드에서 워크로드를 드레이닝합니다. Operator는 한 번에 하나의 노드인 이 작업을 수행하여 재구성의 영향을 받지 않도록 합니다.
대규모 클러스터에서 노드를 순차적으로 드레이닝하는 것은 시간이 오래 걸리는데 몇 시간 또는 며칠이 걸릴 수 있습니다. 시간에 민감한 환경에서는 SriovNetworkPoolConfig
CR(사용자 정의 리소스)에서 병렬 노드를 드레이닝하여 SR-IOV 네트워크 구성을 더 빠르게 롤아웃할 수 있습니다.
병렬 드레이닝을 구성하려면 SriovNetworkPoolConfig
CR을 사용하여 노드 풀을 생성합니다. 그런 다음 풀에 노드를 추가하고 Operator가 병렬로 드레이닝할 수 있는 풀의 최대 노드 수를 정의할 수 있습니다. 이 방법을 사용하면 실행 중인 워크로드를 처리할 수 있는 충분한 노드가 풀에 남아 있도록 동시에 재구성할 수 있도록 병렬 드레이닝을 활성화할 수 있습니다.
노드는 하나의 SR-IOV 네트워크 풀 구성에만 속할 수 있습니다. 노드가 풀의 일부가 아닌 경우 한 번에 하나의 노드를 드레이닝하도록 구성된 가상 기본 풀에 추가됩니다.
드레이닝 프로세스 중에 노드가 다시 시작될 수 있습니다.
사전 요구 사항
-
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 1 namespace: openshift-sriov-network-operator 2 spec: maxUnavailable: 2 3 nodeSelector: 4 matchLabels: node-role.kubernetes.io/worker: ""
- 1
SriovNetworkPoolConfig
오브젝트의 이름을 지정합니다.- 2
- SR-IOV Network Operator가 설치된 네임스페이스를 지정합니다.
- 3
- 업데이트 중에 풀에서 사용할 수 없는 노드에 대해 정수 숫자 또는 백분율 값을 지정합니다. 예를 들어 10개의 노드가 있고 사용할 수 없는 최대 노드를 2개로 설정하면 언제든지 2개의 노드만 병렬로 드레이닝되어 워크로드를 처리하기 위해 8개의 노드를 유지할 수 있습니다.
- 4
- 노드 선택기를 사용하여 풀을 추가할 노드를 지정합니다. 이 예제에서는
worker
역할이 있는 모든 노드를 풀에 추가합니다.
다음 명령을 실행하여
SriovNetworkPoolConfig
리소스를 생성합니다.$ oc create -f sriov-nw-pool.yaml
다음 comand를 실행하여
sriov-test
네임스페이스를 생성합니다.$ oc create namespace sriov-test
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
다음 명령을 실행하여
SriovNetworkNodePolicy
리소스를 생성합니다.$ oc create -f sriov-node-policy.yaml
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" }'
다음 명령을 실행하여
SriovNetwork
리소스를 생성합니다.$ oc create -f sriov-network.yaml
검증
다음 명령을 실행하여 생성한 노드 풀을 확인합니다.
$ oc get sriovNetworkpoolConfig -n openshift-sriov-network-operator
출력 예
NAME AGE pool-1 67s 1
- 1
- 이 예에서
pool-1
에는worker
역할이 있는 모든 노드가 포함됩니다.
위 절차의 예제 시나리오를 사용하여 노드 드레이닝 프로세스를 시연하려면 다음 단계를 완료합니다.
SriovNetworkNodePolicy
리소스의 가상 함수 수를 업데이트하여 클러스터에서 워크로드 드레이닝을 트리거합니다.$ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
다음 명령을 실행하여 대상 클러스터에서 드레이닝 상태를 모니터링합니다.
$ oc get sriovNetworkNodeState -n openshift-sriov-network-operator
출력 예
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
드레이닝 프로세스가 완료되면
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
18.3.7. NUMA 인식 스케줄링을 위한 SR-IOV 네트워크 토폴로지 제외
SR-IOV 네트워크 리소스의 NUMA(Non-Uniform Memory Access) 노드를 토폴로지 관리자로 알리기 위해 SriovNetworkNodePolicy
사용자 정의 리소스에서 excludeTopology
사양을 구성할 수 있습니다. NUMA 인식 Pod 예약 중에 보다 유연한 SR-IOV 네트워크 배포를 위해 이 구성을 사용합니다.
사전 요구 사항
-
OpenShift CLI(
oc
)가 설치되어 있습니다. -
CPU 관리자 정책을
static
으로 구성했습니다. CPU 관리자에 대한 자세한 내용은 추가 리소스 섹션을 참조하십시오. -
토폴로지 관리자 정책을
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 1 nodeSelector: kubernetes.io/hostname: <node_name> numVfs: <number_of_Vfs> nicSelector: 2 vendor: "<vendor_ID>" deviceID: "<device_ID>" deviceType: netdevice excludeTopology: true 3
참고여러
SriovNetworkNodePolicy
리소스가 동일한 SR-IOV 네트워크 리소스를 대상으로 하는 경우SriovNetworkNodePolicy
리소스에excludeTopology
사양과 동일한 값이 있어야 합니다. 그러지 않으면 충돌하는 정책이 거부됩니다.다음 명령을 실행하여
SriovNetworkNodePolicy
리소스를 생성합니다.$ oc create -f sriov-network-node-policy.yaml
출력 예
sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created
SriovNetwork
CR을 생성합니다.다음 YAML을
sriov-network.yaml
파일에 저장하고 YAML의 값을 해당 환경과 일치하도록 교체합니다.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>", }
다음 명령을 실행하여
SriovNetwork
리소스를 생성합니다.$ oc create -f sriov-network.yaml
출력 예
sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created
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", 1 } ] spec: containers: - name: <container_name> image: <image> imagePullPolicy: IfNotPresent command: ["sleep", "infinity"]
- 1
SriovNetworkNodePolicy
리소스를 사용하는SriovNetwork
리소스의 이름입니다.
다음 명령을 실행하여
Pod
리소스를 생성합니다.$ oc create -f sriov-network-pod.yaml
출력 예
pod/example-pod created
검증
다음 명령을 실행하여 Pod의 상태를 확인하고 <
pod_name>
을 Pod 이름으로 교체합니다.$ oc get pod <pod_name>
출력 예
NAME READY STATUS RESTARTS AGE test-deployment-sriov-76cbbf4756-k9v72 1/1 Running 0 45h
대상 Pod로 디버그 세션을 열어 SR-IOV 네트워크 리소스가 메모리 및 CPU 리소스와 다른 노드에 배포되었는지 확인합니다.
다음 명령을 실행하여 Pod로 디버그 세션을 열고 <pod_name>을 대상 Pod 이름으로 교체합니다.
$ oc debug pod/<pod_name>
디버그 쉘 내에서
/host
를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의/host
에 호스트의 root 파일 시스템을 마운트합니다. root 디렉토리를/host
로 변경하면 호스트 파일 시스템에서 바이너리를 실행할 수 있습니다.$ chroot /host
다음 명령을 실행하여 CPU 할당에 대한 정보를 확인합니다.
$ lscpu | grep NUMA
출력 예
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,...
$ cat /proc/self/status | grep Cpus
출력 예
Cpus_allowed: aa Cpus_allowed_list: 1,3,5,7
$ cat /sys/class/net/net1/device/numa_node
출력 예
0
이 예에서 CPU 1,3,5, 7은
NUMA node1
에 할당되지만 SR-IOV 네트워크 리소스는NUMA node0
의 NIC를 사용할 수 있습니다.
excludeTopology
사양이 True
로 설정된 경우 필요한 리소스가 동일한 NUMA 노드에 존재할 수 있습니다.