네트워킹

1. tls.crt 및 tls.key 파일을 사용하여 openshift-ingress 네임스페이스에 사용자 정의 인증서를 포함하는 Secret 리소스를 만듭니다.

   $ oc --namespace openshift-ingress create secret tls custom-certs-default --cert=tls.crt --key=tls.key

2. 새 인증서 보안 키를 참조하도록 IngressController CR을 업데이트합니다.

   $ oc patch --type=merge --namespace openshift-ingress-operator ingresscontrollers/default \
     --patch '{"spec":{"defaultCertificate":{"name":"custom-certs-default"}}}'

3. 업데이트가 적용되었는지 확인합니다.

   $ echo Q |\
     openssl s_client -connect console-openshift-console.apps.<domain>:443 -showcerts 2>/dev/null |\
     openssl x509 -noout -subject -issuer -enddate

   다음과 같습니다.

   <domain>

   클러스터의 기본 도메인 이름을 지정합니다.

   출력 예

   subject=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = *.apps.example.com
   issuer=C = US, ST = NC, L = Raleigh, O = RH, OU = OCP4, CN = example.com
   notAfter=May 10 08:32:45 2022 GM

   인증서 보안 이름은 CR을 업데이트하는 데 사용된 값과 일치해야 합니다.

프로세스

1. 기본 IngressController의 현재 사용 가능한 복제본 개수를 살펴봅니다.

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   출력 예

   2

2. oc patch 명령을 사용하여 기본 IngressController의 복제본 수를 원하는 대로 조정합니다. 다음 예제는 기본 IngressController를 3개의 복제본으로 조정합니다.

   $ oc patch -n openshift-ingress-operator ingresscontroller/default --patch '{"spec":{"replicas": 3}}' --type=merge

   출력 예

   ingresscontroller.operator.openshift.io/default patched

3. 기본 IngressController가 지정한 복제본 수에 맞게 조정되었는지 확인합니다.

   $ oc get -n openshift-ingress-operator ingresscontrollers/default -o jsonpath='{$.status.availableReplicas}'

   출력 예

   3

프로세스

1. 다음 예제와 같이 <name>-ingress-controller.yam 파일에 IngressController CR(사용자 정의 리소스)을 생성합니다.

   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: <name> 1
   spec:
     domain: <domain> 2
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal 3

   1

   <name>을 IngressController 오브젝트의 이름으로 변경합니다.

   2

   컨트롤러가 게시한 애플리케이션의 domain을 지정합니다.

   3

   내부 로드 밸런서를 사용하려면 Internal 값을 지정합니다.

2. 다음 명령을 실행하여 이전 단계에서 정의된 Ingress 컨트롤러를 생성합니다.

   $ oc create -f <name>-ingress-controller.yaml 1

   1

   <name>을 IngressController 오브젝트의 이름으로 변경합니다.

3. 선택 사항: 다음 명령을 실행하여 Ingress 컨트롤러가 생성되었는지 확인합니다.

   $ oc --all-namespaces=true get ingresscontrollers

프로세스

1. 클러스터의 기본 Ingress 컨트롤러를 삭제하고 다시 생성하여 내부용으로 구성합니다.

   $ oc replace --force --wait --filename - <<EOF
   apiVersion: operator.openshift.io/v1
   kind: IngressController
   metadata:
     namespace: openshift-ingress-operator
     name: default
   spec:
     endpointPublishingStrategy:
       type: LoadBalancerService
       loadBalancer:
         scope: Internal
   EOF

프로세스

1. 와일드카드 정책을 구성합니다.

   1. 다음 명령을 사용하여 IngressController 리소스를 편집합니다.

      $ oc edit IngressController

   2. spec에서 wildcardPolicy 필드를 WildcardsDisallowed 또는 WildcardsAllowed로 설정합니다.

      spec:
        routeAdmission:
          wildcardPolicy: WildcardsDisallowed # or WildcardsAllowed

프로세스

1. Ingress 컨트롤러에 대한 HTTPHeaders 필드를 구성합니다.

   1. 다음 명령을 사용하여 IngressController 리소스를 편집합니다.

      $ oc edit IngressController

   2. spec에서 HTTPHeaders 정책 필드를 Append, Replace, IfNone 또는 Never로 설정합니다.

      apiVersion: operator.openshift.io/v1
      kind: IngressController
      metadata:
        name: default
        namespace: openshift-ingress-operator
      spec:
        httpHeaders:
          forwardedHeaderPolicy: Append

프로세스

1. PTP Operator 네임스페이스를 생성하려면 다음 명령을 입력합니다.

   $ cat << EOF| oc create -f -
   apiVersion: v1
   kind: Namespace
   metadata:
     name: openshift-ptp
     labels:
       name: openshift-ptp
       openshift.io/cluster-monitoring: "true"
   EOF

2. 해당 Operator에 대한 Operator group을 생성하려면 다음 명령을 입력합니다.

   $ cat << EOF| oc create -f -
   apiVersion: operators.coreos.com/v1
   kind: OperatorGroup
   metadata:
     name: ptp-operators
     namespace: openshift-ptp
   spec:
     targetNamespaces:
     - openshift-ptp
   EOF

3. PTP Operator에 등록합니다.

   1. 다음 명령을 실행하여 OpenShift Container Platform의 주 버전과 부 버전을 환경 변수로 설정합니다.이 변수는 다음 단계에서 channel 값으로 사용됩니다.

      $ OC_VERSION=$(oc version -o yaml | grep openshiftVersion | \
          grep -o '[0-9]*[.][0-9]*' | head -1)

   2. PTP Operator에 대한 서브스크립션을 만들려면 다음 명령을 입력합니다.

      $ cat << EOF| oc create -f -
      apiVersion: operators.coreos.com/v1alpha1
      kind: Subscription
      metadata:
        name: ptp-operator-subscription
        namespace: openshift-ptp
      spec:
        channel: "${OC_VERSION}"
        name: ptp-operator
        source: redhat-operators
        sourceNamespace: openshift-marketplace
      EOF

4. Operator가 설치되었는지 확인하려면 다음 명령을 입력합니다.

   $ oc get csv -n openshift-ptp \
     -o custom-columns=Name:.metadata.name,Phase:.status.phase

   출력 예

   Name                                        Phase
   ptp-operator.4.4.0-202006160135             Succeeded

프로세스

1. OpenShift Container Platform 웹 콘솔을 사용하여 PTP Operator를 설치합니다.

   1. OpenShift Container Platform 웹 콘솔에서 Operator → OperatorHub를 클릭합니다.
   2. 사용 가능한 Operator 목록에서 PTP Operator를 선택한 다음 설치를 클릭합니다.
   3. Operator 설치 페이지의 클러스터의 특정 네임스페이스에서 openshift-ptp를 선택합니다. 그런 다음, 설치를 클릭합니다.

2. 선택 사항: PTP Operator가 성공적으로 설치되었는지 확인합니다.

   1. Operator → 설치된 Operator 페이지로 전환합니다.

   2. PTP Operator가 openshift-ptp 프로젝트에 InstallSucceeded 상태로 나열되어 있는지 확인합니다.

      참고

      설치 중에 Operator는 실패 상태를 표시할 수 있습니다. 나중에 InstallSucceeded 메시지와 함께 설치에 성공하면 이 실패 메시지를 무시할 수 있습니다.

      Operator가 설치된 것으로 나타나지 않으면 다음과 같이 추가 트러블슈팅을 수행하십시오.

      • Operator → 설치된 Operator 페이지로 이동하고 Operator 서브스크립션 및 설치 계획 탭의 상태에 장애나 오류가 있는지 검사합니다.
      • Workloads → Pod 페이지로 이동하여 openshift-ptp 프로젝트에서 Pod 로그를 확인합니다.

절차

1. 다음과 같이 정책 규칙을 생성합니다.

   1. <policy_name>.yaml 파일을 생성합니다.

      $ touch <policy_name>.yaml

      다음과 같습니다.

      <policy_name>

      네트워크 정책 파일 이름을 지정합니다.

   2. 방금 만든 파일에서 다음 예와 같이 네트워크 정책을 정의합니다.

      모든 네임스페이스의 모든 Pod에서 수신 거부

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: deny-by-default
      spec:
        podSelector:
        ingress: []

      동일한 네임 스페이스에 있는 모든 Pod의 수신 허용

      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}

2. 다음 명령을 실행하여 네트워크 정책 오브젝트를 생성합니다.

   $ oc apply -f <policy_name>.yaml -n <namespace>

   다음과 같습니다.

   <policy_name>

   네트워크 정책 파일 이름을 지정합니다.

   <namespace>

   선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 네임스페이스를 지정합니다.

   출력 예

   networkpolicy "default-deny" created

절차

1. 선택 사항: 네임스페이스의 네트워크 정책 오브젝트를 나열하려면 다음 명령을 입력합니다.

   $ oc get networkpolicy -n <namespace>

   다음과 같습니다.

   <namespace>

   선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 네임스페이스를 지정합니다.

2. NetworkPolicy 오브젝트를 편집합니다.

   • 네트워크 정책 정의를 파일에 저장한 경우 파일을 편집하고 필요한 사항을 변경한 후 다음 명령을 입력합니다.

     $ oc apply -n <namespace> -f <policy_file>.yaml

     다음과 같습니다.

     <namespace>

     선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 네임스페이스를 지정합니다.

     <policy_file>

     네트워크 정책이 포함된 파일의 이름을 지정합니다.

   • NetworkPolicy 오브젝트를 직접 업데이트해야 하는 경우 다음 명령을 입력합니다.

     $ oc edit networkpolicy <policy_name> -n <namespace>

     다음과 같습니다.

     <policy_name>

     네트워크 정책의 이름을 지정합니다.

     <namespace>

     선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 네임스페이스를 지정합니다.

3. NetworkPolicy 오브젝트가 업데이트되었는지 확인합니다.

   $ oc describe networkpolicy <policy_name> -n <namespace>

   다음과 같습니다.

   <policy_name>

   네트워크 정책의 이름을 지정합니다.

   <namespace>

   선택 사항: 오브젝트가 현재 네임스페이스와 다른 네임스페이스에 정의된 경우 네임스페이스를 지정합니다.

프로세스

1. cluster-admin 권한이 있는 사용자로 로그인합니다.

2. 기본 프로젝트 템플릿을 생성합니다.

   $ oc adm create-bootstrap-project-template -o yaml > template.yaml

3. 텍스트 편집기를 사용하여 오브젝트를 추가하거나 기존 오브젝트를 수정하여 생성된 template.yaml 파일을 수정합니다.

4. 프로젝트 템플릿은 openshift-config 네임스페이스에서 생성해야 합니다. 수정된 템플릿을 불러옵니다.

   $ oc create -f template.yaml -n openshift-config

5. 웹 콘솔 또는 CLI를 사용하여 프로젝트 구성 리소스를 편집합니다.

   • 웹 콘솔에 액세스:

     1. 관리 → 클러스터 설정으로 이동합니다.
     2. 전역 구성을 클릭하여 모든 구성 리소스를 확인합니다.
     3. 프로젝트 항목을 찾아 YAML 편집을 클릭합니다.

   • CLI 사용:

     1. 다음과 같이 project.config.openshift.io/cluster 리소스를 편집합니다.

        $ oc edit project.config.openshift.io/cluster

6. projectRequestTemplate 및 name 매개변수를 포함하도록 spec 섹션을 업데이트하고 업로드된 프로젝트 템플릿의 이름을 설정합니다. 기본 이름은 project-request입니다.

   사용자 정의 프로젝트 템플릿이 포함된 프로젝트 구성 리소스

   apiVersion: config.openshift.io/v1
   kind: Project
   metadata:
     ...
   spec:
     projectRequestTemplate:
       name: <template_name>

7. 변경 사항을 저장한 후 새 프로젝트를 생성하여 변경 사항이 성공적으로 적용되었는지 확인합니다.

프로세스

1. 다음 명령을 실행하여 새 프로젝트의 기본 템플릿을 편집합니다.

   $ oc edit template <project_template> -n openshift-config

   <project_template>을 클러스터에 대해 구성한 기본 템플릿의 이름으로 변경합니다. 기본 템플릿 이름은 project-request입니다.

2. 템플릿에서 각 NetworkPolicy 오브젝트를 objects 매개변수의 요소로 추가합니다. objects 매개변수는 하나 이상의 오브젝트 컬렉션을 허용합니다.

   다음 예제에서 objects 매개변수 컬렉션에는 여러 NetworkPolicy 오브젝트가 포함됩니다.

   중요

   OVN-Kubernetes 네트워크 공급자 플러그인의 경우 Ingress 컨트롤러가 HostNetwork 끝점 게시 전략을 사용하도록 구성된 경우 Ingress 트래픽이 허용되고 기타 모든 트래픽이 거부되도록 네트워크 정책을 적용하는 방법은 지원되지 않습니다.

   objects:
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-same-namespace
     spec:
       podSelector: {}
       ingress:
       - from:
         - podSelector: {}
   - apiVersion: networking.k8s.io/v1
     kind: NetworkPolicy
     metadata:
       name: allow-from-openshift-ingress
     spec:
       ingress:
       - from:
         - namespaceSelector:
             matchLabels:
               network.openshift.io/policy-group: ingress
       podSelector: {}
       policyTypes:
       - Ingress
   ...

3. 선택 사항: 다음 명령을 실행하여 새 프로젝트를 생성하여 네트워크 정책 오브젝트가 생성되었는지 확인합니다.

   1. 새 프로젝트를 생성합니다.

      $ oc new-project <project> 1

      1

      <project> 를 생성중인 프로젝트의 이름으로 변경합니다.

   2. 새 프로젝트 템플릿의 네트워크 정책 오브젝트가 새 프로젝트에 있는지 확인합니다.

      $ oc get networkpolicy
      NAME                           POD-SELECTOR   AGE
      allow-from-openshift-ingress   <none>         7s
      allow-from-same-namespace      <none>         7s

프로세스

1. 다음 NetworkPolicy 오브젝트를 생성합니다.

   1. 이름이 allow-from-openshift-ingress인 정책입니다.

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-ingress
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                policy-group.network.openshift.io/ingress: ""
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   2. 이름이 allow-from-openshift-monitoring인 정책:

      $ cat << EOF| oc create -f -
      apiVersion: networking.k8s.io/v1
      kind: NetworkPolicy
      metadata:
        name: allow-from-openshift-monitoring
      spec:
        ingress:
        - from:
          - namespaceSelector:
              matchLabels:
                network.openshift.io/policy-group: monitoring
        podSelector: {}
        policyTypes:
        - Ingress
      EOF

   3. 이름이 allow-same-namespace인 정책:

      $ cat << EOF| oc create -f -
      kind: NetworkPolicy
      apiVersion: networking.k8s.io/v1
      metadata:
        name: allow-same-namespace
      spec:
        podSelector:
        ingress:
        - from:
          - podSelector: {}
      EOF

2. 선택 사항: 네트워크 정책이 현재 프로젝트에 있는지 확인하려면 다음 명령을 입력합니다.

   $ oc describe networkpolicy

   출력 예

   Name:         allow-from-openshift-ingress
   Namespace:    example1
   Created on:   2020-06-09 00:28:17 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: ingress
     Not affecting egress traffic
     Policy Types: Ingress
   
   
   Name:         allow-from-openshift-monitoring
   Namespace:    example1
   Created on:   2020-06-09 00:29:57 -0400 EDT
   Labels:       <none>
   Annotations:  <none>
   Spec:
     PodSelector:     <none> (Allowing the specific traffic to all pods in this namespace)
     Allowing ingress traffic:
       To Port: <any> (traffic allowed to all ports)
       From:
         NamespaceSelector: network.openshift.io/policy-group: monitoring
     Not affecting egress traffic
     Policy Types: Ingress

절차

1. CNO 구성을 편집하려면 다음 명령을 입력합니다.

   $ oc edit networks.operator.openshift.io cluster

2. 다음 예제 CR과 같이 생성할 추가 네트워크의 구성을 추가하여 생성 중인 CR을 수정합니다.

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     # ...
     additionalNetworks:
     - name: tertiary-net
       namespace: project2
       type: Raw
       rawCNIConfig: |-
         {
           "cniVersion": "0.3.1",
           "name": "tertiary-net",
           "type": "ipvlan",
           "master": "eth1",
           "mode": "l2",
           "ipam": {
             "type": "static",
             "addresses": [
               {
                 "address": "192.168.1.23/24"
               }
             ]
           }
         }

3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.

절차

1. 다음 예와 같이 추가 네트워크 구성을 사용하여 YAML 파일을 생성합니다.

   apiVersion: k8s.cni.cncf.io/v1
   kind: NetworkAttachmentDefinition
   metadata:
     name: next-net
   spec:
     config: |-
       {
         "cniVersion": "0.3.1",
         "name": "work-network",
         "type": "host-device",
         "device": "eth1",
         "ipam": {
           "type": "dhcp"
         }
       }

2. 추가 네트워크를 생성하려면 다음 명령을 입력합니다.

   $ oc apply -f <file>.yaml

   다음과 같습니다.

   <file>

   YAML 매니페스트가 포함된 파일의 이름을 지정합니다.

프로세스

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/networks-status: |- 1
         [{
             "name": "openshift-sdn",
             "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/networks-status 매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

1. 기본 텍스트 편집기에서 CNO(Cluster Network Operator) CR을 편집하려면 다음 명령을 실행합니다.

   $ oc edit networks.operator.openshift.io cluster

2. additionalNetworks 컬렉션에서 변경 내용으로 추가 네트워크를 업데이트합니다.
3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.

4. 선택 사항: CNO가 다음 명령을 실행하여 NetworkAttachmentDefinition 오브젝트를 업데이트했는지 확인합니다. <network-name>을 표시할 추가 네트워크의 이름으로 변경합니다. CNO가 변경 사항을 반영하기 위해서 NetworkAttachmentDefinition 오브젝트를 업데이트하기 전에 지연이 발생할 수 있습니다.

   $ oc get network-attachment-definitions <network-name> -o yaml

   예를 들어, 다음 콘솔 출력은 net1이라는 NetworkAttachmentDefinition 오브젝트를 표시합니다.

   $ oc get network-attachment-definitions net1 -o go-template='{{printf "%s\n" .spec.config}}'
   { "cniVersion": "0.3.1", "type": "macvlan",
   "master": "ens5",
   "mode": "bridge",
   "ipam":       {"type":"static","routes":[{"dst":"0.0.0.0/0","gw":"10.128.2.1"}],"addresses":[{"address":"10.128.2.100/23","gateway":"10.128.2.1"}],"dns":{"nameservers":["172.30.0.10"],"domain":"us-west-2.compute.internal","search":["us-west-2.compute.internal"]}} }

1. 다음 명령을 실행하여 기본 텍스트 편집기에서 CNO(Cluster Network Operator)를 편집합니다.

   $ oc edit networks.operator.openshift.io cluster

2. 제거할 네트워크 연결 정의에 대한 additionalNetworks 컬렉션에서 구성을 제거하여 CR을 수정합니다.

   apiVersion: operator.openshift.io/v1
   kind: Network
   metadata:
     name: cluster
   spec:
     additionalNetworks: [] 1

   1

   additionalNetworks 컬렉션에서 유일한 추가 네트워크 첨부 파일 정의에 대한 구성 매핑을 제거하는 경우 빈 컬렉션을 지정해야 합니다.

3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.

4. 선택 사항: 다음 명령을 실행하여 추가 네트워크 CR이 삭제되었는지 확인합니다.

   $ oc get network-attachment-definition --all-namespaces

절차

1. SriovNetworkNodePolicy 오브젝트를 생성한 후 YAML을 <name>-sriov-node-network.yaml 파일에 저장합니다. <name>을 이 구성의 이름으로 바꿉니다.
2. 선택 사항: SriovNetworkNodePolicy.Spec.NodeSelector 로 SR-IOV 가능 클러스터 노드에 레이블을 지정하지 않은 경우 레이블을 지정합니다. 노드 레이블링에 대한 자세한 내용은 "노드에서 라벨을 업데이트하는 방법"을 참조하십시오.

2. SriovNetworkNodePolicy 오브젝트를 생성합니다.

   $ oc create -f <name>-sriov-node-network.yaml

   <name>은 이 구성의 이름을 지정합니다.

   구성 업데이트를 적용하면 sriov-network-operator 네임스페이스의 모든 Pod가 Running 상태로 전환됩니다.

3. SR-IOV 네트워크 장치가 구성되어 있는지 확인하려면 다음 명령을 입력합니다. <node_name>을 방금 구성한 SR-IOV 네트워크 장치가 있는 노드 이름으로 바꿉니다.

   $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

프로세스

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>

프로세스

1. SriovIBNetwork 오브젝트를 생성한 다음 <name>.yaml 파일에 YAML을 저장합니다. 여기서 <name>은 이 추가 네트워크의 이름입니다. 오브젝트 사양은 다음 예와 유사할 수 있습니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovIBNetwork
   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. 선택 사항: 이전 단계에서 생성한 SriovIBNetwork 오브젝트와 연결된 NetworkAttachmentDefinition 오브젝트가 존재하는지 확인하려면 다음 명령을 입력합니다. <namespace>를 SriovIBNetwork 오브젝트에 지정한 networkNamespace로 바꿉니다.

   $ oc get net-attach-def -n <namespace>

프로세스

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/networks-status: |- 1
         [{
             "name": "openshift-sdn",
             "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/networks-status 매개변수는 JSON 오브젝트 배열입니다. 각 오브젝트는 Pod에 연결된 추가 네트워크의 상태를 설명합니다. 주석 값은 일반 텍스트 값으로 저장됩니다.

절차

1. 다음과 같은 SR-IOV Pod 사양을 생성한 다음 YAML을 <name>-sriov-pod.yaml 파일에 저장합니다. <name>을 이 Pod의 이름으로 바꿉니다.

   다음 예는 SR-IOV Pod 사양을 보여줍니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: sample-pod
     annotations:
       k8s.v1.cni.cncf.io/networks: <name> 1
   spec:
     containers:
     - name: sample-container
       image: <image> 2
       command: ["sleep", "infinity"]
       resources:
         limits:
           memory: "1Gi" 3
           cpu: "2" 4
         requests:
           memory: "1Gi"
           cpu: "2"

   1

   <name>을 SR-IOV 네트워크 첨부 파일 정의 CR의 이름으로 바꿉니다.

   2

   <image>를 sample-pod 이미지의 이름으로 바꿉니다.

   3

   보장된 QoS로 SR-IOV Pod를 생성하려면 메모리 제한을 메모리 요청과 동일하게 설정합니다.

   4

   보장된 QoS로 SR-IOV Pod를 생성하려면 cpu 제한을 CPU 요청과 동일하게 설정합니다.

2. 다음 명령을 실행하여 샘플 SR-IOV Pod를 만듭니다.

   $ oc create -f <filename> 1

   1

   <filename>을 이전 단계에서 생성한 파일 이름으로 바꿉니다.

3. sample-pod가 보장된 QoS로 구성되어 있는지 확인하십시오.

   $ oc describe pod sample-pod

4. sample-pod에 전용 CPU가 할당되어 있는지 확인하십시오.

   $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

5. sample-pod에 할당된 SR-IOV 장치 및 CPU가 동일한 NUMA 노드에 있는지 확인하십시오.

   $ oc exec sample-pod -- cat /sys/fs/cgroup/cpuset/cpuset.cpus

프로세스

1. SriovNetworkNodePolicy 오브젝트를 생성합니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: policy-example
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: example
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     numVfs: 4
     nicSelector:
       vendor: "8086"
       pfNames: ['ens803f0']
       rootDevices: ['0000:86:00.0']

2. SriovNetwork 오브젝트를 생성합니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: net-example
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: default
     ipam: | 1
       {
         "type": "host-local", 2
         "subnet": "10.56.217.0/24",
         "rangeStart": "10.56.217.171",
         "rangeEnd": "10.56.217.181",
         "routes": [
           {"dst": "224.0.0.0/5"},
           {"dst": "232.0.0.0/5"}
         ],
         "gateway": "10.56.217.1"
       }
     resourceName: example

   1 2

   DHCP를 IPAM으로 구성하도록 선택하는 경우 DHCP 서버를 통해 다음 기본 경로를 프로비저닝해야 합니다. 224.0.0.0/5 및 232.0.0.0/5. 이는 기본 네트워크 공급자가 설정한 정적 멀티 캐스트 경로를 재정의하는 것입니다.

3. 멀티 캐스트 애플리케이션으로 pod를 생성합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: testpmd
     namespace: default
     annotations:
       k8s.v1.cni.cncf.io/networks: nic1
   spec:
     containers:
     - name: example
       image: rhel7:latest
       securityContext:
         capabilities:
           add: ["NET_ADMIN"] 1
       command: [ "sleep", "infinity"]

   1

   NET_ADMIN 기능은 애플리케이션이 멀티 캐스트 IP 주소를 SR-IOV 인터페이스에 할당해야 하는 경우에만 필요합니다. 그 밖의 경우에는 생략할 수 있습니다.

절차

1. 다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 intel-dpdk-node-policy.yaml 파일에 저장합니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: intel-dpdk-node-policy
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: intelnics
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     priority: <priority>
     numVfs: <num>
     nicSelector:
       vendor: "8086"
       deviceID: "158b"
       pfNames: ["<pf_name>", ...]
       rootDevices: ["<pci_bus_id>", "..."]
     deviceType: vfio-pci 1

   1

   가상 기능의 드라이버 유형을 vfio-pci로 지정합니다.

   참고

   SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성 섹션을 참조하십시오.

   SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

   구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

   $ oc create -f intel-dpdk-node-policy.yaml

3. 다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 intel-dpdk-network.yaml 파일에 저장합니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: intel-dpdk-network
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: <target_namespace>
     ipam: "{}" 1
     vlan: <vlan>
     resourceName: intelnics

   1

   ipam CNI 플러그인에 빈 오브젝트 "{}"을 지정합니다. DPDK는 사용자 공간 모드에서 작동하며 IP 주소가 필요하지 않습니다.

   참고

   SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.

4. 다음 명령을 실행하여 SriovNetwork 오브젝트를 생성합니다.

   $ oc create -f intel-dpdk-network.yaml

5. 다음 Pod 사양을 생성한 다음 YAML을 intel-dpdk-pod.yaml 파일에 저장합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: dpdk-app
     namespace: <target_namespace> 1
     annotations:
       k8s.v1.cni.cncf.io/networks: intel-dpdk-network
   spec:
     containers:
     - name: testpmd
       image: <DPDK_image> 2
       securityContext:
         runAsUser: 0
         capabilities:
           add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3
       volumeMounts:
       - mountPath: /dev/hugepages 4
         name: hugepage
       resources:
         limits:
           openshift.io/intelnics: "1" 5
           memory: "1Gi"
           cpu: "4" 6
           hugepages-1Gi: "4Gi" 7
         requests:
           openshift.io/intelnics: "1"
           memory: "1Gi"
           cpu: "4"
           hugepages-1Gi: "4Gi"
       command: ["sleep", "infinity"]
     volumes:
     - name: hugepage
       emptyDir:
         medium: HugePages

   1

   SriovNetwork 오브젝트 intel-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면 Pod 사양과 SriovNetowrk 오브젝트 모두에서 target_namespace를 변경합니다.

   2

   애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.

   3

   hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.

   4

   /dev/hugepages 아래 DPDK pod에 hugepage 볼륨을 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.

   5

   선택 사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. 명시적으로 지정되지 않은 경우 이 리소스 요청 및 제한은 SR-IOV 네트워크 리소스 인젝터에 의해 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.

   6

   CPU 수를 지정합니다. DPDK pod는 일반적으로 kubelet에서 배타적 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 보장된 Pod를 생성합니다.

   7

   hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi 및 1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다. 예를 들어, 커널 인수 default_hugepagesz = 1GB, hugepagesz = 1G 및 hugepages = 16을 추가하면 시스템 부팅 시 16 * 1Gi hugepage가 할당됩니다.

6. 다음 명령을 실행하여 DPDK Pod를 생성합니다.

   $ oc create -f intel-dpdk-pod.yaml

절차

1. 다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 mlx-dpdk-node-policy.yaml 파일에 저장합니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: mlx-dpdk-node-policy
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: mlxnics
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     priority: <priority>
     numVfs: <num>
     nicSelector:
       vendor: "15b3"
       deviceID: "1015" 1
       pfNames: ["<pf_name>", ...]
       rootDevices: ["<pci_bus_id>", "..."]
     deviceType: netdevice 2
     isRdma: true 3

   1

   SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다. Mellanox 카드에 허용되는 유일한 값은 1015, 1017입니다.

   2

   netdevice에 가상 기능의 드라이버 유형을 지정합니다. Mellanox SR-IOV VF는 vfio-pci 장치 유형을 사용하지 않고도 DPDK 모드에서 작동할 수 있습니다. VF 장치는 컨테이너 내부에 커널 네트워크 인터페이스로 나타납니다.

   3

   RDMA 모드를 활성화합니다. 이는 DPDK 모드에서 작동하기 위해 Mellanox 카드에 필요합니다.

   참고

   SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 Configuring SR-IOV network devices 섹션을 참조하십시오.

   SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

   구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

   $ oc create -f mlx-dpdk-node-policy.yaml

3. 다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 mlx-dpdk-network.yaml 파일에 저장합니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: mlx-dpdk-network
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: <target_namespace>
     ipam: |- 1
       ...
     vlan: <vlan>
     resourceName: mlxnics

   1

   ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.

   참고

   SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.

4. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

   $ oc create -f mlx-dpdk-network.yaml

5. 다음 Pod 사양을 생성한 다음 YAML을 mlx-dpdk-pod.yaml 파일에 저장합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: dpdk-app
     namespace: <target_namespace> 1
     annotations:
       k8s.v1.cni.cncf.io/networks: mlx-dpdk-network
   spec:
     containers:
     - name: testpmd
       image: <DPDK_image> 2
       securityContext:
         runAsUser: 0
         capabilities:
           add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3
       volumeMounts:
       - mountPath: /dev/hugepages 4
         name: hugepage
       resources:
         limits:
           openshift.io/mlxnics: "1" 5
           memory: "1Gi"
           cpu: "4" 6
           hugepages-1Gi: "4Gi" 7
         requests:
           openshift.io/mlxnics: "1"
           memory: "1Gi"
           cpu: "4"
           hugepages-1Gi: "4Gi"
       command: ["sleep", "infinity"]
     volumes:
     - name: hugepage
       emptyDir:
         medium: HugePages

   1

   SriovNetwork 오브젝트 mlx-dpdk-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면 Pod 사양과 SriovNetowrk 오브젝트 모두에서 target_namespace를 변경합니다.

   2

   애플리케이션 및 애플리케이션이 사용하는 DPDK 라이브러리를 포함하는 DPDK 이미지를 지정합니다.

   3

   hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.

   4

   hugepage 볼륨을 /dev/hugepages 아래의 DPDK Pod에 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.

   5

   선택 사항: DPDK Pod에 할당된 DPDK 장치 수를 지정합니다. SR-IOV 네트워크 리소스 인젝터에서 명시적으로 지정하지 않은 경우 이 리소스 요청 및 제한이 자동으로 추가됩니다. SR-IOV 네트워크 리소스 인젝터는 SR-IOV Operator에서 관리하는 승인 컨트롤러 구성 요소입니다. 기본적으로 활성화되어 있으며 기본 SriovOperatorConfig CR에서 enableInjector 옵션을 false로 설정하여 비활성화할 수 있습니다.

   6

   CPU 수를 지정합니다. DPDK Pod에서는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 Guaranteed Pod를 생성합니다.

   7

   hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 DPDK Pod에 할당할 hugepage 수량을 지정합니다. 2Mi 및 1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.

6. 다음 명령을 실행하여 DPDK Pod를 생성합니다.

   $ oc create -f mlx-dpdk-pod.yaml

절차

1. 다음 SriovNetworkNodePolicy 오브젝트를 생성한 다음 YAML을 mlx-rdma-node-policy.yaml 파일에 저장합니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetworkNodePolicy
   metadata:
     name: mlx-rdma-node-policy
     namespace: openshift-sriov-network-operator
   spec:
     resourceName: mlxnics
     nodeSelector:
       feature.node.kubernetes.io/network-sriov.capable: "true"
     priority: <priority>
     numVfs: <num>
     nicSelector:
       vendor: "15b3"
       deviceID: "1015" 1
       pfNames: ["<pf_name>", ...]
       rootDevices: ["<pci_bus_id>", "..."]
     deviceType: netdevice 2
     isRdma: true 3

   1

   SR-IOV 네트워크 장치의 장치 16진수 코드를 지정합니다. Mellanox 카드에 허용되는 유일한 값은 1015, 1017입니다.

   2

   netdevice에 가상 기능의 드라이버 유형을 지정합니다.

   3

   RDMA 모드를 활성화합니다.

   참고

   SriovNetworkNodePolicy의 각 옵션에 대한 자세한 설명은 SR-IOV 네트워크 장치 구성 섹션을 참조하십시오.

   SriovNetworkNodePolicy 오브젝트에 지정된 구성을 적용하면 SR-IOV Operator가 노드를 비우고 경우에 따라 노드를 재부팅할 수 있습니다. 구성 변경 사항을 적용하는 데 몇 분이 걸릴 수 있습니다. 제거된 워크로드를 사전에 처리하는 데 클러스터에 사용 가능한 노드가 충분한지 확인하십시오.

   구성 업데이트가 적용되면 openshift-sriov-network-operator 네임스페이스의 모든 Pod 상태가 Running으로 변경됩니다.

2. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

   $ oc create -f mlx-rdma-node-policy.yaml

3. 다음 SriovNetwork 오브젝트를 생성한 다음 YAML을 mlx-rdma-network.yaml 파일에 저장합니다.

   apiVersion: sriovnetwork.openshift.io/v1
   kind: SriovNetwork
   metadata:
     name: mlx-rdma-network
     namespace: openshift-sriov-network-operator
   spec:
     networkNamespace: <target_namespace>
     ipam: |- 1
       ...
     vlan: <vlan>
     resourceName: mlxnics

   1

   ipam CNI 플러그인의 구성 오브젝트를 YAML 블록 스칼라로 지정합니다. 플러그인은 연결 정의에 대한 IP 주소 할당을 관리합니다.

   참고

   SriovNetwork의 각 옵션에 대한 자세한 설명은 " SR-IOV 추가 네트워크 구성" 섹션을 참조하십시오.

4. 다음 명령을 실행하여 SriovNetworkNodePolicy 오브젝트를 생성합니다.

   $ oc create -f mlx-rdma-network.yaml

5. 다음 Pod 사양을 생성한 다음 YAML을 mlx-rdma-pod.yaml 파일에 저장합니다.

   apiVersion: v1
   kind: Pod
   metadata:
     name: rdma-app
     namespace: <target_namespace> 1
     annotations:
       k8s.v1.cni.cncf.io/networks: mlx-rdma-network
   spec:
     containers:
     - name: testpmd
       image: <RDMA_image> 2
       securityContext:
         runAsUser: 0
         capabilities:
           add: ["IPC_LOCK","SYS_RESOURCE","NET_RAW"] 3
       volumeMounts:
       - mountPath: /dev/hugepages 4
         name: hugepage
       resources:
         limits:
           memory: "1Gi"
           cpu: "4" 5
           hugepages-1Gi: "4Gi" 6
         requests:
           memory: "1Gi"
           cpu: "4"
           hugepages-1Gi: "4Gi"
       command: ["sleep", "infinity"]
     volumes:
     - name: hugepage
       emptyDir:
         medium: HugePages

   1

   SriovNetwork 오브젝트 mlx-rdma-network가 생성되는 동일한 target_namespace를 지정합니다. 다른 네임스페이스에서 포드를 생성하려면 Pod 사양과 SriovNetowrk 오브젝트 모두에서 target_namespace를 변경합니다.

   2

   애플리케이션 및 애플리케이션에서 사용하는 RDMA 라이브러리를 포함하는 RDMA 이미지를 지정합니다.

   3

   hugepage 할당, 시스템 리소스 할당 및 네트워크 인터페이스 액세스를 위해 컨테이너 내부의 애플리케이션에 필요한 추가 기능을 지정합니다.

   4

   hugepage 볼륨을 /dev/hugepages 아래의 RDMA Pod에 마운트합니다. hugepage 볼륨은 매체가 Hugepages인 emptyDir 볼륨 유형으로 지원됩니다.

   5

   CPU 수를 지정합니다. RDMA Pod는 일반적으로 kubelet에서 전용 CPU를 할당해야 합니다. 이를 위해 CPU 관리자 정책을 static으로 설정하고 QoS가 Guaranteed Pod를 생성합니다.

   6

   hugepage 크기 hugepages-1Gi 또는 hugepages-2Mi를 지정하고 RDMA Pod에 할당할 hugepage 수량을 지정합니다. 2Mi 및 1Gi hugepage를 별도로 구성합니다. 1Gi hugepage를 구성하려면 커널 인수를 노드에 추가해야 합니다.

6. 다음 명령을 실행하여 RDMA Pod를 생성합니다.

   $ oc create -f mlx-rdma-pod.yaml

절차

1. 모든 SR-IOV 사용자 정의 리소스(CR)를 삭제합니다.

   $ oc delete sriovnetwork -n openshift-sriov-network-operator --all

   $ oc delete sriovnetworknodepolicy -n openshift-sriov-network-operator --all

   $ oc delete sriovibnetwork -n openshift-sriov-network-operator --all

2. "클러스터에서 Operator 삭제" 섹션의 지침에 따라 클러스터에서 SR-IOV Network Operator를 제거합니다.

3. SR-IOV Network Operator가 제거된 후 클러스터에 남아 있는 SR-IOV 사용자 정의 리소스 정의를 삭제합니다.

   $ oc delete crd sriovibnetworks.sriovnetwork.openshift.io

   $ oc delete crd sriovnetworknodepolicies.sriovnetwork.openshift.io

   $ oc delete crd sriovnetworknodestates.sriovnetwork.openshift.io

   $ oc delete crd sriovnetworkpoolconfigs.sriovnetwork.openshift.io

   $ oc delete crd sriovnetworks.sriovnetwork.openshift.io

   $ oc delete crd sriovoperatorconfigs.sriovnetwork.openshift.io

4. SR-IOV 웹 후크를 삭제합니다.

   $ oc delete mutatingwebhookconfigurations network-resources-injector-config

   $ oc delete MutatingWebhookConfiguration sriov-operator-webhook-config

   $ oc delete ValidatingWebhookConfiguration sriov-operator-webhook-config

5. SR-IOV Network Operator 네임스페이스를 삭제합니다.

   $ oc delete namespace openshift-sriov-network-operator

프로세스

1. 다음 JSON을 사용하여 송신 IP 주소로 NetNamespace 오브젝트를 업데이트합니다.

    $ oc patch netnamespace <project_name> --type=merge -p \ 1
     '{
       "egressIPs": [
         "<ip_address>" 2
       ]
     }'

   1

   프로젝트 이름을 지정합니다.

   2

   단일 송신 IP 주소를 지정합니다. 다중 IP 주소 사용은 지원되지 않습니다.

   예를 들어 project1을 IP 주소 192.168.1.100에 할당하고 project2를 IP 주소 192.168.1.101에 할당하려면 다음을 수행합니다.

   $ oc patch netnamespace project1 --type=merge -p \
     '{"egressIPs": ["192.168.1.100"]}'
   $ oc patch netnamespace project2 --type=merge -p \
     '{"egressIPs": ["192.168.1.101"]}'

   참고

   OpenShift SDN은 NetNamespace 오브젝트를 관리하므로 기존 NetNamespace 오브젝트를 수정하기만 하면 됩니다. 새 NetNamespace 오브젝트를 생성하지 마십시오.

2. 다음 JSON을 사용하여 각 호스트에 대해 egressCIDRs 매개변수를 설정하여 송신 IP 주소를 호스팅할 수 있는 노드를 표시합니다.

   $ oc patch hostsubnet <node_name> --type=merge -p \ 1
     '{
       "egressCIDRs": [
         "<ip_address_range_1>", "<ip_address_range_2>" 2
       ]
     }'

   1

   노드 이름을 지정합니다.

   2

   CIDR 형식으로 하나 이상의 IP 주소 범위를 지정합니다.

   예를 들어, node1 및 node2를 192.168.1.0에서 192.168.1.255 범위의 송신 IP 주소를 호스팅하도록 설정하려면 다음을 수행합니다.

   $ oc patch hostsubnet node1 --type=merge -p \
     '{"egressCIDRs": ["192.168.1.0/24"]}'
   $ oc patch hostsubnet node2 --type=merge -p \
     '{"egressCIDRs": ["192.168.1.0/24"]}'

   OpenShift Container Platform은 특정 송신 IP 주소를 균형 잡힌 방식으로 사용 가능한 노드에 자동으로 할당합니다. 이 경우 송신 IP 주소 192.168.1.100을 node1에 할당하고 송신 IP 주소 192.168.1.101을 node2에 할당하거나 그 반대의 경우도 마찬가지입니다.

프로세스

1. 원하는 IP 주소로 다음 JSON 오브젝트를 지정하여 NetNamespace 오브젝트를 업데이트합니다.

   $ oc patch netnamespace <project> --type=merge -p \ 1
     '{
       "egressIPs": [ 2
         "<ip_address>"
         ]
     }'

   1

   프로젝트 이름을 지정합니다.

   2

   하나 이상의 송신 IP 주소를 지정합니다. egressIPs 매개변수는 배열입니다.

   예를 들어, project1 프로젝트를 IP 주소 192.168.1.100에 할당하려면 다음을 수행합니다.

   $ oc patch netnamespace project1 --type=merge \
     -p '{"egressIPs": ["192.168.1.100"]}'

   고가용성을 제공하기 위해 egressIP를 다른 노드에서 둘 이상의 IP 주소로 설정할 수 있습니다. 여러 송신 IP 주소가 설정되어 있으면 Pod는 목록의 첫 번째 IP를 송신에 사용하지만, 해당 IP 주소를 호스팅하는 노드가 실패하면 Pod는 잠시 후 목록의 다음 IP를 사용하도록 전환됩니다.

   참고

   OpenShift SDN은 NetNamespace 오브젝트를 관리하므로 기존 NetNamespace 오브젝트를 수정하기만 하면 됩니다. 새 NetNamespace 오브젝트를 생성하지 마십시오.

2. 송신 IP를 노드 호스트에 수동으로 할당합니다. 노드 호스트의 HostSubnet 오브젝트에서 egressIPs 매개변수를 설정합니다. 다음 JSON을 사용하여 해당 노드 호스트에 할당하려는 IP 수를 포함합니다.

   $ oc patch hostsubnet <node_name> --type=merge -p \ 1
     '{
       "egressIPs": [ 2
         "<ip_address_1>",
         "<ip_address_N>"
         ]
     }'

   1

   노드 이름을 지정합니다.

   2

   하나 이상의 송신 IP 주소를 지정합니다. egressIPs 필드는 배열입니다.

   예를 들어 node1에 송신 IP 192.168.1.100, 192.168.1.101 및 192.168.1.102가 있도록 지정하려면 다음을 수행합니다.

   $ oc patch hostsubnet node1 --type=merge -p \
     '{"egressIPs": ["192.168.1.100", "192.168.1.101", "192.168.1.102"]}'

   이전 예에서 project1의 모든 송신 트래픽은 지정된 송신 IP를 호스팅하는 노드로 라우팅된 다음 NAT를 사용하여 해당 IP 주소에 연결됩니다.