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, disableauto입니다.
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 주소 할당

프로세스

  1. type 을 whereabouts로 설정합니다.
  2. 다음 예와 같이 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"}
                  ]
           }
          }
  3. Pod에 네트워크를 연결합니다. 자세한 내용은 "추가 네트워크에 Pod 추가"를 참조하십시오.
  4. 모든 IP 주소가 할당되었는지 확인합니다.
  5. 다음 명령을 실행하여 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 주소 할당 구성에 대해 설명합니다.

표 18.2. IPAM 고정 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. static 값이 필요합니다.

주소

array

가상 인터페이스에 할당할 IP 주소를 지정하는 오브젝트의 배열입니다. IPv4 및 IPv6 IP 주소가 모두 지원됩니다.

routes

array

Pod 내부에서 구성할 경로를 지정하는 오브젝트의 배열입니다.

dns

array

선택 사항: DNS 구성을 지정하는 오브젝트 배열입니다.

address 배열에는 다음 필드가 있는 오브젝트가 필요합니다.

표 18.3. IPAM.addresses[] 배열
필드유형설명

address

string

지정하는 IP 주소 및 네트워크 접두사입니다. 예를 들어 10.10.21.10/24를 지정하면 추가 네트워크에 IP 주소 10.10.21.10이 할당되고 넷마스크는 255.255.255.0입니다.

gateway

string

송신 네트워크 트래픽을 라우팅할 기본 게이트웨이입니다.

표 18.4. ipam.routes[] array
필드유형설명

dst

string

CIDR 형식의 IP 주소 범위(예: 기본 경로의 경우 192.168.17.0/24 또는 0.0.0.0/0 )입니다.

GW

string

네트워크 트래픽이 라우팅되는 게이트웨이입니다.

표 18.5. IPAM.dns 오브젝트
필드유형설명

네임서버

array

DNS 쿼리를 보낼 하나 이상의 IP 주소로 이루어진 배열입니다.

domain

array

호스트 이름에 추가할 기본 도메인입니다. 예를 들어 도메인이 example.com으로 설정되면 example-host에 대한 DNS 조회 쿼리가 example-host.example.com으로 다시 작성됩니다.

search

array

DNS 조회 쿼리 중에 규정되지 않은 호스트 이름(예: example-host)에 추가할 도메인 이름 배열입니다.

고정 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 주소 할당을 위한 구성 매개 변수에 대해 설명합니다.

표 18.6. IPAM DHCP 구성 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. dhcp 값은 필수입니다.

다음 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 주소 할당을 위한 구성 오브젝트를 설명합니다.

표 18.7. IPAM 위치 설정 오브젝트
필드유형설명

type

string

IPAM 주소 유형입니다. 여기서about s 값이 필요합니다.

range

string

CIDR 표기법의 IP 주소 및 범위입니다. IP 주소는 이 주소 범위 내에서 할당됩니다.

exclude

array

선택 사항: CIDR 표기법의 0개 이상의 IP 주소 및 범위 목록입니다. 제외된 주소 범위 내의 IP 주소는 할당되지 않습니다.

network_name

string

선택 사항: 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 2network_name 과 일치해야 합니다.

NetworkAttachmentDefinition 2

{
  "ipam": {
    "type": "whereabouts",
    "range": "192.0.2.192/24",
    "network_name": "example_net_common", 1
  }
}

1
선택 사항: 설정된 경우 NetworkAttachmentDefinition 1network_name 과 일치해야 합니다.

18.3.2. SR-IOV 추가 네트워크 구성

SriovNetwork 오브젝트를 생성하여 SR-IOV 하드웨어를 사용하는 추가 네트워크를 구성할 수 있습니다. SriovNetwork 오브젝트를 생성하면 SR-IOV Network Operator가 NetworkAttachmentDefinition 오브젝트를 자동으로 생성합니다.

참고

SriovNetwork 오브젝트가 running 상태의 Pod에 연결된 경우 해당 오브젝트를 수정하거나 삭제하지 마십시오.

사전 요구 사항

  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 권한이 있는 사용자로 로그인합니다.

프로세스

  1. 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"
        }
  2. 오브젝트를 생성하려면 다음 명령을 입력합니다:

    $ oc create -f <name>.yaml

    여기서 <name>은 추가 네트워크의 이름을 지정합니다.

  3. 선택사항: 이전 단계에서 생성한 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 클러스터에 로그인합니다.

프로세스

  1. 추가 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
        }

    1
    typevrf로 설정해야 합니다.
    2
    vrfname은 인터페이스가 할당된 VRF의 이름입니다. 포드에 없는 경우 생성됩니다.
  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 네트워크 연결이 연결되었는지 확인하려면 다음을 수행하십시오.

  1. VRF CNI를 사용하는 SR-IOV 네트워크를 생성합니다.
  2. 포드에 네트워크를 할당합니다.
  3. 포드 네트워크 연결이 SR-IOV 추가 네트워크에 연결되어 있는지 확인합니다. Pod로 원격 쉘을 설치하고 다음 명령을 실행합니다.

    $ ip vrf show

    출력 예

    Name              Table
    -----------------------
    red                 10

  4. 다음 명령을 실행하여 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)를 설치합니다.
  • 클러스터에 로그인합니다.

프로세스

  1. Pod 오브젝트에 주석을 추가합니다. 다음 주석 형식 중 하나만 사용할 수 있습니다.

    1. 사용자 정의 없이 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다. <network>를 Pod와 연결할 추가 네트워크의 이름으로 변경합니다.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: <network>[,<network>,...] 1
      1
      둘 이상의 추가 네트워크를 지정하려면 각 네트워크를 쉼표로 구분합니다. 쉼표 사이에 공백을 포함하지 마십시오. 동일한 추가 네트워크를 여러 번 지정하면 Pod에 해당 네트워크에 대한 인터페이스가 여러 개 연결됩니다.
    2. 사용자 정의된 추가 네트워크를 연결하려면 다음 형식으로 주석을 추가합니다.

      metadata:
        annotations:
          k8s.v1.cni.cncf.io/networks: |-
            [
              {
                "name": "<network>", 1
                "namespace": "<namespace>", 2
                "default-route": ["<default-route>"] 3
              }
            ]
      1
      NetworkAttachmentDefinition 오브젝트에서 정의한 추가 네트워크의 이름을 지정합니다.
      2
      NetworkAttachmentDefinition 오브젝트가 정의된 네임스페이스를 지정합니다.
      3
      선택 사항: 기본 경로에 대한 재정의를 지정합니다(예: 192.168.17.1).
  2. Pod를 생성하려면 다음 명령을 입력합니다. <name>을 Pod 이름으로 교체합니다.

    $ oc create -f <name>.yaml
  3. 선택사항: 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를 사용할 수 있는지 확인할 수 있습니다.

프로세스

  1. 다음 명령을 실행하여 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"
        }
      }
  2. 다음 명령을 실행하여 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를 지원하는 하드웨어가 있습니다.

프로세스

  1. SriovNetworkPoolConfig 리소스를 생성합니다.

    1. 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 역할이 있는 모든 노드를 풀에 추가합니다.
    2. 다음 명령을 실행하여 SriovNetworkPoolConfig 리소스를 생성합니다.

      $ oc create -f sriov-nw-pool.yaml
  2. 다음 comand를 실행하여 sriov-test 네임스페이스를 생성합니다.

    $ oc create namespace sriov-test
  3. SriovNetworkNodePolicy 리소스를 생성합니다.

    1. 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

    2. 다음 명령을 실행하여 SriovNetworkNodePolicy 리소스를 생성합니다.

      $ oc create -f sriov-node-policy.yaml
  4. SriovNetwork 리소스를 생성합니다.

    1. 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" }'

    2. 다음 명령을 실행하여 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 역할이 있는 모든 노드가 포함됩니다.

위 절차의 예제 시나리오를 사용하여 노드 드레이닝 프로세스를 시연하려면 다음 단계를 완료합니다.

  1. SriovNetworkNodePolicy 리소스의 가상 함수 수를 업데이트하여 클러스터에서 워크로드 드레이닝을 트리거합니다.

    $ oc patch SriovNetworkNodePolicy sriov-nic-1 -n openshift-sriov-network-operator --type merge -p '{"spec": {"numVfs": 4}}'
  2. 다음 명령을 실행하여 대상 클러스터에서 드레이닝 상태를 모니터링합니다.

    $ 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 STATUSSucceeded 로 변경되고 DESIRED SYNC STATECURRENT 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가 설치되어 있습니다.

프로세스

  1. SriovNetworkNodePolicy CR을 생성합니다.

    1. 다음 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
      1
      SR-IOV 네트워크 장치 플러그인의 리소스 이름입니다. 이 YAML은 샘플 resourceName 값을 사용합니다.
      2
      NIC 선택기를 사용하여 Operator가 구성할 장치를 식별합니다.
      3
      SR-IOV 네트워크 리소스의 NUMA 노드를 토폴로지 관리자로 알리려면 값을 true 로 설정합니다. 기본값은 false입니다.
      참고

      여러 SriovNetworkNodePolicy 리소스가 동일한 SR-IOV 네트워크 리소스를 대상으로 하는 경우 SriovNetworkNodePolicy 리소스에 excludeTopology 사양과 동일한 값이 있어야 합니다. 그러지 않으면 충돌하는 정책이 거부됩니다.

    2. 다음 명령을 실행하여 SriovNetworkNodePolicy 리소스를 생성합니다.

      $ oc create -f sriov-network-node-policy.yaml

      출력 예

      sriovnetworknodepolicy.sriovnetwork.openshift.io/policy-for-numa-0 created

  2. SriovNetwork CR을 생성합니다.

    1. 다음 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>",
          }
      1
      sriov-numa-0-network 를 SR-IOV 네트워크 리소스의 이름으로 교체합니다.
      2
      이전 단계의 SriovNetworkNodePolicy CR의 리소스 이름을 지정합니다. 이 YAML은 샘플 resourceName 값을 사용합니다.
      3
      SR-IOV 네트워크 리소스의 네임스페이스를 입력합니다.
      4
      SR-IOV 네트워크의 IP 주소 관리 구성을 입력합니다.
    2. 다음 명령을 실행하여 SriovNetwork 리소스를 생성합니다.

      $ oc create -f sriov-network.yaml

      출력 예

      sriovnetwork.sriovnetwork.openshift.io/sriov-numa-0-network created

  3. Pod를 생성하고 이전 단계의 SR-IOV 네트워크 리소스를 할당합니다.

    1. 다음 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 리소스의 이름입니다.
    2. 다음 명령을 실행하여 Pod 리소스를 생성합니다.

      $ oc create -f sriov-network-pod.yaml

      출력 예

      pod/example-pod created

검증

  1. 다음 명령을 실행하여 Pod의 상태를 확인하고 < pod_name> 을 Pod 이름으로 교체합니다.

    $ oc get pod <pod_name>

    출력 예

    NAME                                     READY   STATUS    RESTARTS   AGE
    test-deployment-sriov-76cbbf4756-k9v72   1/1     Running   0          45h

  2. 대상 Pod로 디버그 세션을 열어 SR-IOV 네트워크 리소스가 메모리 및 CPU 리소스와 다른 노드에 배포되었는지 확인합니다.

    1. 다음 명령을 실행하여 Pod로 디버그 세션을 열고 <pod_name>을 대상 Pod 이름으로 교체합니다.

      $ oc debug pod/<pod_name>
    2. 디버그 쉘 내에서 /host를 root 디렉터리로 설정합니다. 디버그 Pod는 Pod 내의 /host에 호스트의 root 파일 시스템을 마운트합니다. root 디렉토리를 /host로 변경하면 호스트 파일 시스템에서 바이너리를 실행할 수 있습니다.

      $ chroot /host
    3. 다음 명령을 실행하여 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 노드에 존재할 수 있습니다.

18.3.8. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

Red Hat을 사용하는 고객은 신뢰할 수 있는 콘텐츠가 포함된 제품과 서비스를 통해 혁신하고 목표를 달성할 수 있습니다.

보다 포괄적 수용을 위한 오픈 소스 용어 교체

Red Hat은 코드, 문서, 웹 속성에서 문제가 있는 언어를 교체하기 위해 최선을 다하고 있습니다. 자세한 내용은 다음을 참조하세요.Red Hat 블로그.

Red Hat 소개

Red Hat은 기업이 핵심 데이터 센터에서 네트워크 에지에 이르기까지 플랫폼과 환경 전반에서 더 쉽게 작업할 수 있도록 강화된 솔루션을 제공합니다.

© 2024 Red Hat, Inc.