8.10. 설치 후 RHOSP 네트워크 구성


설치 후 Red Hat OpenStack Platform (RHOSP) 클러스터에서 OpenShift Container Platform의 일부를 구성할 수 있습니다.

8.10.1. 부동 IP 주소로 애플리케이션 액세스 구성

OpenShift Container Platform을 설치한 후 애플리케이션 네트워크 트래픽을 허용하도록 RHOSP(Red Hat OpenStack Platform)를 구성합니다.

참고

install-config.yaml 파일에서 platform.openstack.apiFloatingIPplatform.openstack.ingressFloatingIP 에 대한 값을 제공하거나 설치 중에 inventory.yaml 플레이 북의 os_api_fipos_ingress_fip에 대한 값을 제공한 경우 이 절차를 수행 할 필요가 없습니다. 부동 IP 주소가 이미 설정되어 있습니다.

전제 조건

  • OpenShift Container Platform 클러스터가 설치되어 있어야 합니다.
  • RHOSP의 OpenShift Container Platform 설치에 관한 문서에 설명 된대로 부동 IP 주소가 활성화됩니다.

프로세스

OpenShift Container Platform 클러스터를 설치한 후 부동 IP 주소를 인그레스 포트에 연결합니다.

  1. 포트 표시:

    $ openstack port show <cluster_name>-<cluster_ID>-ingress-port
  2. IP 주소에 포트 연결:

    $ openstack floating ip set --port <ingress_port_ID> <apps_FIP>
  3. *apps의 와일드카드 A 레코드를 DNS 파일에 추가:

    *.apps.<cluster_name>.<base_domain>  IN  A  <apps_FIP>
참고

DNS 서버를 제어하지 않지만 프로덕션 이외의 목적으로 애플리케이션 액세스를 활성화하려는 경우 다음과 같은 호스트 이름을 /etc/hosts에 추가할 수 있습니다.

<apps_FIP> console-openshift-console.apps.<cluster name>.<base domain>
<apps_FIP> integrated-oauth-server-openshift-authentication.apps.<cluster name>.<base domain>
<apps_FIP> oauth-openshift.apps.<cluster name>.<base domain>
<apps_FIP> prometheus-k8s-openshift-monitoring.apps.<cluster name>.<base domain>
<apps_FIP> <app name>.apps.<cluster name>.<base domain>

8.10.2. Kuryr 포트 풀

Kuryr 포트 풀은 Pod 생성을 위해 대기 중인 다수의 포트를 유지 관리합니다.

포트를 대기 상태로 유지하면 Pod 생성 시간이 최소화됩니다. 포트 풀이 없으면 Kuryr는 Pod를 생성하거나 삭제할 때마다 포트 생성 또는 삭제를 명시적으로 요청해야 합니다.

Kuryr가 사용하는 Neutron 포트는 네임스페이스에 연결된 서브넷에 생성됩니다. 이러한 Pod 포트도 OpenShift Container Platform 클러스터 노드의 기본 포트에 하위 포트로 추가됩니다.

Kuryr는 각 네임스페이스를 별도의 서브넷에 유지하므로 각 네임스페이스-작업자 쌍에 대해 별도의 포트 풀이 유지됩니다.

클러스터를 설치하기 전에 cluster-network-03-config.yml 매니페스트 파일에서 다음 매개변수를 설정하여 포트 풀 동작을 구성할 수 있습니다.

  • enablePortPoolsPrepopulation 매개변수는 Pod에 전용 네트워크를 사용하도록 구성된 첫 번째 Pod가 생성되어 Pod에 전용 네트워크를 사용하도록 구성된 경우 Kuryr가 풀에 Neutron 포트를 추가하도록 강제 적용합니다. 기본값은 false입니다.
  • poolMinPorts 매개변수는 풀에 보관되는 사용 가능한 최소 포트 수입니다. 기본값은 1 입니다.
  • poolMaxPorts 매개변수는 풀에 보관되는 사용 가능한 최대 포트 수입니다. 값이 0이면 해당 상한이 비활성화됩니다. 이 설정은 기본 설정입니다.

    OpenStack 포트 할당량이 낮거나 pod 네트워크에 IP 주소가 제한된 경우 이 옵션을 설정하여 불필요한 포트가 삭제되었는지 확인합니다.

  • poolBatchPorts 매개 변수는 한 번에 생성할 수 있는 최대 Neutron 포트 수를 정의합니다. 기본값은 3입니다.

8.10.3. RHOSP의 활성 배포에서 Kuryr 포트 풀 설정 조정

CR(사용자 정의 리소스)을 사용하여 Kuryr가 RHOSP(Red Hat OpenStack Platform) Neutron 포트를 관리하는 방법을 구성하여 배포된 클러스터에서 Pod 생성 속도와 효율성을 제어할 수 있습니다.

절차

  1. 명령줄에서 편집을 위해 CNO(Cluster Network Operator) CR을 엽니다.

    $ oc edit networks.operator.openshift.io cluster
  2. 요구 사항에 맞게 설정을 편집합니다. 다음 파일은 예제로 제공됩니다.

    apiVersion: operator.openshift.io/v1
    kind: Network
    metadata:
      name: cluster
    spec:
      clusterNetwork:
      - cidr: 10.128.0.0/14
        hostPrefix: 23
      serviceNetwork:
      - 172.30.0.0/16
      defaultNetwork:
        type: Kuryr
        kuryrConfig:
          enablePortPoolsPrepopulation: false 1
          poolMinPorts: 1 2
          poolBatchPorts: 3 3
          poolMaxPorts: 5 4
    1
    Pod에 전용 네트워크를 사용하도록 구성된 첫 번째 Pod가 네임스페이스에 생성되는 경우 Kuryr가 Neutron 포트를 생성하도록 하려면 enablePortPoolsPrepopulationtrue 로 설정합니다. 이 설정은 Neutron 포트 할당량을 높이지만 pod를 생성하는 데 필요한 시간을 줄일 수 있습니다. 기본값은 false입니다.
    2
    Kuryr는 풀의 사용 가능한 포트 수가 poolMinPorts 값보다 낮은 경우 풀에 대한 새 포트를 만듭니다. 기본값은 1 입니다.
    3
    poolBatchPorts는 사용 가능한 포트 수가 poolMinPorts 값보다 낮은 경우 생성되는 새 포트 수를 제어합니다. 기본값은 3입니다.
    4
    풀에서 사용 가능한 포트 수가 poolMaxPorts 값보다 크면 Kuryr는 숫자가 해당 값과 일치할 때까지 해당 포트를 삭제합니다. 값을 0으로 설정하면 이 상한이 비활성화되므로 풀이 축소되지 않습니다. 기본값은 0입니다.
  3. 변경 사항을 저장하고 텍스트 편집기를 종료하여 변경 사항을 커밋합니다.
중요

실행 중인 클러스터에서 이러한 옵션을 수정하면 kuryr-controller 및 kuryr-cni Pod가 다시 시작됩니다. 결과적으로 새 Pod 및 서비스 생성이 지연됩니다.

8.10.4. OVS 하드웨어 오프로드 활성화

RHOSP(Red Hat OpenStack Platform)에서 실행되는 클러스터의 경우 OVS(Open vSwitch) 하드웨어 오프로드를 활성화할 수 있습니다.

OVS는 대규모의 다중 서버 네트워크 가상화를 활성화하는 다중 계층 가상 스위치입니다.

사전 요구 사항

  • SR-IOV(Single-root input/output virtualization)용으로 구성된 RHOSP에 클러스터를 설치했습니다.
  • 클러스터에 SR-IOV Network Operator가 설치되어 있어야 합니다.
  • 클러스터에 두 개의 hw-offload 유형의 VF(가상 기능) 인터페이스가 생성되었습니다.
참고

애플리케이션 계층 게이트웨이 흐름은 OpenShift Container Platform 버전 4.10, 4.11 및 4.12에서 손상됩니다. 또한 OpenShift Container Platform 버전 4.13의 애플리케이션 계층 게이트웨이 흐름을 오프로드할 수 없습니다.

절차

  1. 클러스터에 있는 두 개의 hw-offload 유형 VF 인터페이스에 대한 SriovNetworkNodePolicy 정책을 생성합니다.

    첫 번째 가상 기능 인터페이스

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy 1
    metadata:
      name: "hwoffload9"
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice
      isRdma: true
      nicSelector:
        pfNames: 2
        - ens6
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: 'true'
      numVfs: 1
      priority: 99
      resourceName: "hwoffload9"

    1
    여기에서 SriovNetworkNodePolicy 값을 삽입합니다.
    2
    두 인터페이스에는 물리적 기능(PF) 이름이 포함되어야 합니다.

    두 번째 가상 기능 인터페이스

    apiVersion: sriovnetwork.openshift.io/v1
    kind: SriovNetworkNodePolicy 1
    metadata:
      name: "hwoffload10"
      namespace: openshift-sriov-network-operator
    spec:
      deviceType: netdevice
      isRdma: true
      nicSelector:
        pfNames: 2
        - ens5
      nodeSelector:
        feature.node.kubernetes.io/network-sriov.capable: 'true'
      numVfs: 1
      priority: 99
      resourceName: "hwoffload10"

    1
    여기에서 SriovNetworkNodePolicy 값을 삽입합니다.
    2
    두 인터페이스에는 물리적 기능(PF) 이름이 포함되어야 합니다.
  2. 두 개의 인터페이스에 대해 NetworkAttachmentDefinition 리소스를 생성합니다.

    첫 번째 인터페이스에 대한 NetworkAttachmentDefinition 리소스

    apiVersion: k8s.cni.cncf.io/v1
    kind: NetworkAttachmentDefinition
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload9
      name: hwoffload9
      namespace: default
    spec:
        config: '{ "cniVersion":"0.3.1", "name":"hwoffload9","type":"host-device","device":"ens6"
        }'

    두 번째 인터페이스에 대한 NetworkAttachmentDefinition 리소스

    apiVersion: k8s.cni.cncf.io/v1
    kind: NetworkAttachmentDefinition
    metadata:
      annotations:
        k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload10
      name: hwoffload10
      namespace: default
    spec:
        config: '{ "cniVersion":"0.3.1", "name":"hwoffload10","type":"host-device","device":"ens5"
        }'

  3. Pod로 생성한 인터페이스를 사용합니다. 예를 들어 다음과 같습니다.

    두 개의 OVS 오프로드 인터페이스를 사용하는 Pod

    apiVersion: v1
    kind: Pod
    metadata:
      name: dpdk-testpmd
      namespace: default
      annotations:
        irq-load-balancing.crio.io: disable
        cpu-quota.crio.io: disable
        k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload9
        k8s.v1.cni.cncf.io/resourceName: openshift.io/hwoffload10
    spec:
      restartPolicy: Never
      containers:
      - name: dpdk-testpmd
        image: quay.io/krister/centos8_nfv-container-dpdk-testpmd:latest

8.10.5. OVS 하드웨어 오프로드 네트워크 연결

OVS(Open vSwitch) 하드웨어 오프로드 네트워크를 클러스터에 연결할 수 있습니다.

사전 요구 사항

  • 클러스터가 설치되어 실행 중입니다.
  • 클러스터와 함께 사용할 RHOSP(Red Hat OpenStack Platform)에서 OVS 하드웨어 오프로드 네트워크를 프로비저닝합니다.

절차

  1. 다음 템플릿에서 network.yaml 이라는 파일을 생성합니다.

    spec:
      additionalNetworks:
      - name: hwoffload1
        namespace: cnf
        rawCNIConfig: '{ "cniVersion": "0.3.1", "name": "hwoffload1", "type": "host-device","pciBusId": "0000:00:05.0", "ipam": {}}' 1
        type: Raw

    다음과 같습니다.

    pciBusId

    오프로드 네트워크에 연결된 장치를 지정합니다. 없는 경우 다음 명령을 실행하여 이 값을 찾을 수 있습니다.

    $ oc describe SriovNetworkNodeState -n openshift-sriov-network-operator
  2. 다음 명령을 입력하여 파일을 사용하여 클러스터를 패치합니다.

    $ oc apply -f network.yaml
Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.