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. 사용자 생성 경로에 대한 대체 기본 도메인을 지정하여 appsDomain 필드를 구성합니다.

   1. Ingress 클러스터 리소스를 편집합니다.

      $ oc edit ingresses.config/cluster -o yaml

   2. YAML 파일을 편집합니다.

      test.example.com에 대한 샘플 appsDomain 구성

      apiVersion: config.openshift.io/v1
      kind: Ingress
      metadata:
        name: cluster
      spec:
        domain: apps.example.com            1
        appsDomain: <test.example.com>      2

      1

      기본 도메인

      2

      선택 사항: 애플리케이션 경로에 사용할 OpenShift Container Platform 인프라의 도메인입니다. 기본 접두사인 apps 대신 test 와 같은 대체 접두사를 사용할 수 있습니다.

2. 경로를 노출하고 경로 도메인 변경을 확인하여 기존 경로에 appsDomain 필드에 지정된 도메인 이름이 포함되어 있는지 확인합니다.

   참고

   경로를 노출하기 전에 openshift-apiserver가 롤링 업데이트를 완료할 때까지 기다립니다.

   1. 경로를 노출합니다.

      $ oc expose service hello-openshift
      route.route.openshift.io/hello-openshift exposed

      출력 예:

      $ oc get routes
      NAME              HOST/PORT                                   PATH   SERVICES          PORT       TERMINATION   WILDCARD
      hello-openshift   hello_openshift-<my_project>.test.example.com
      hello-openshift   8080-tcp                 None

프로세스

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

      참고

      policy-group.network.openshift.io/ingress: "" 는 OpenShift SDN의 기본 네임스페이스 선택기 레이블입니다. network.openshift.io/policy-group: ingress 네임스페이스 선택기 레이블을 사용할 수 있지만 이는 레거시 레이블입니다.

   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