주요 기능

워커 노드당 정적 VNI

베어메탈 기반 Red Hat OpenShift on IBM Cloud 클러스터 또는 IBM Cloud VPC 에서 새 워커 풀을 생성하면 두 개의 VNI가 자동으로 생성되어 모든 베어메탈 워커 노드에 정적으로 연결됩니다. 하나의 VNI는 일반 워커 트래픽(포드 네트워크, 오버레이 UDN, 마스터 통신)을 처리합니다. 두 번째 VNI는 사용자가 관리하는 동적 VNI 첨부 파일의 캐리어 역할을 합니다.

동적 VNI 첨부 파일

클러스터 생성 후 필요에 따라 VNI를 생성하고 관리할 수 있습니다. 실시간 마이그레이션 중 VM 워크로드에 따라 특정 워커에 동적 VNI를 연결하거나 동일한 영역의 워커 간에 유동적으로 이동하도록 구성할 수 있습니다.

실시간 마이그레이션 지원

베어 메탈 워커 노드에 VNI를 연결하면 OpenShift 가상화 기반 VM의 라이브 마이그레이션을 통해 네트워크 연결을 보존할 수 있습니다. VNI는 암시적으로 동일한 영역 내의 베어메탈 워커 인스턴스 간의 워크로드를 따라 이동합니다.

VNI에 대한 중요한 제한 사항 및 고려 사항은 제한 사항 및 고려 사항을 참조하세요.

교차 계정 연결

Red Hat OpenShift on IBM Cloud 에서는 워커 노드가 계정에서 프로비저닝되지 않으므로 VNI의 수명 주기 관리가 독립 실행형 VPC 베어메탈 인스턴스와 약간 다릅니다. Red Hat OpenShift on IBM Cloud 클러스터 관리자는 계정 내에서 볼 수 없는 워크로드에 VNI가 첨부되어 있기 때문에 VNI의 첨부 파일에 대해 다른 가시성을 가집니다. 이 문서에서는 VNI 관리의 차이점에 대해 설명합니다.

독립 실행형 VPC 베어메탈 인스턴스의 VNI에 대한 자세한 내용은 가상 네트워크 인터페이스에 대한 정보를 참조하세요.

기본 UDN 만들기

파드 또는 VM 워크로드에 기본 사용자 정의 네트워크를 사용하려면 먼저 UDN 자체를 생성하세요.

네임스페이스 전반에서 사용할 수 있는 클러스터 사용자 정의 네트워크의 예시입니다:

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: primary
spec:
  namespaceSelector:
    matchLabels:
      kubernetes.io/metadata.name: green
  network:
    layer2:
      ipam:
        lifecycle: Persistent
      role: Primary
      subnets:
        - 10.0.0.0/24
    topology: Layer2

그런 다음 이를 사용할 네임스페이스를 만듭니다. 네임스페이스에는 기본 UDN 사용을 위해 생성 시 특정 레이블( k8s.ovn.org/primary-user-defined-network)이 포함되어야 합니다.

예:

kind: Namespace
apiVersion: v1
metadata:
  name: green
  labels:
    k8s.ovn.org/primary-user-defined-network: ''

(C)UDN과 네임스페이스가 설정되면 이 네임스페이스에서 생성된 모든 워크로드는 기본 경로를 사용하여 UDN에 액세스합니다.

보조 UDN 만들기

보조 UDN 구성은 기본 UDN과 유사하지만 역할이 Secondary 으로 설정되어 있습니다. 자세한 내용은 Red Hat OpenShift 다중 네트워크 문서를 참조하세요.

NMState 연산자 설치

OpenShift 가상화 서비스 클러스터에는 NMState 오퍼레이터가 미리 설치되어 있으며, ‘ openshift-virtualization ’ 애드온을 통해 관리됩니다. 가상화 서비스를 사용하는 경우 이 단계를 건너뛰십시오.

1. Red Hat OpenShift on IBM Cloud 콘솔의 OperatorHub 또는 CLI를 사용하여 NMState 오퍼레이터를 배포합니다.

2. 기본 구성으로 NMState 인스턴스를 만듭니다.

   apiVersion: nmstate.io/v1
   kind: NMState
   metadata:
     name: nmstate
   spec:
     probeConfiguration:
       dns:
         host: root-servers.net
   

OVS 브리지 만들기

OpenShift 가상화 서비스 클러스터에는 필요한 NNCP 리소스가 미리 구성되어 있습니다. OpenShift 가상화 기능을 수동으로 설치한 표준 OpenShift 클러스터의 경우에만 이러한 리소스를 수동으로 생성해야 합니다.

1. 다음 NMState 사용자 지정 리소스를 배포하여 eth1 가 첨부된 전용 OVS 브리지를 만듭니다.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "br-eth1"
   spec:
     desiredState:
       interfaces:
       - name: "br-eth1"
         description: A dedicated OVS bridge with a NIC as a port
         type: ovs-bridge
         state: up
         bridge:
           allow-extra-patch-ports: true
           options:
             stp: false
           port:
           - name: "eth1"
   

2. 사용자 지정 리소스 상태를 확인하고 해당되는 모든 클러스터 노드가 브리지 생성 요청을 조정할 때까지 기다립니다.

3. 다음 NMState 사용자 지정 리소스를 생성하여 새 OVS 브리지를 기본 브리지에 패치합니다. vpc-vlans 을 원하는 네트워크 이름으로 바꿉니다.

   apiVersion: nmstate.io/v1
   kind: NodeNetworkConfigurationPolicy
   metadata:
     name: "vpc-vlans"
   spec:
     desiredState:
       ovn:
         bridge-mappings:
         - localnet: "vpc-vlans"
           bridge: "br-eth1"
           state: present
   

4. 사용자 지정 리소스 상태를 확인하고 해당되는 모든 클러스터 노드가 브리지 매핑 요청을 조정할 때까지 기다립니다.

로컬넷 사용자 정의 네트워크 만들기

선택한 VLAN을 사용하여 VNI의 트래픽을 사용할 수 있는 UDN 또는 ClusterUserDefinedNetwork (CUDN)을 만듭니다.

apiVersion: k8s.ovn.org/v1
kind: ClusterUserDefinedNetwork
metadata:
  name: "vlan250"
spec:
  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: In
      values:
      - "default"
  network:
    topology: Localnet
    localnet:
      role: "Secondary"
      physicalNetworkName: "vpc-vlans"
      ipam:
        mode: Disabled
      vlan:
        mode: Access
        access:
          id: 250

다음 값을 대체하십시오.

• vlan250: CUDN의 이름
• default: CUDN을 사용할 네임스페이스입니다
• vpc-vlans: 브리지 매핑에서 정의한 물리적 네트워크 이름입니다
• 250: 원하는 VLAN ID(범위: 1-500)

이것으로 특정 VLAN의 네트워크 배관을 마칩니다. 브리지 매핑을 재사용하면서 서로 다른 VLAN ID를 사용하여 여러 CUDN을 정의할 수 있습니다.

로컬넷 UDN 설정을 완료한 후 IBM Cloud 콘솔 또는 IBM Cloud CLI ks vni 명령을 사용하여 클러스터에 VNI를 연결할 수 있습니다. 다음 섹션의 예를 참조하세요.

시작하기 전에

1. 적절한 서브넷 및 IP 주소 구성으로 VPC에 VNI를 생성합니다.

2. 클러스터와 VNI를 모두 관리하는 데 필요한 권한이 있는지 확인하세요.

예

ibmcloud ks vni attach baremetal --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123 --vlan 251

출력 예

OK
Successfully attached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba to worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.
Worker Node ID                                         VNI ID                                      VLAN ID
kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   251

출력 예

ibmcloud ks vni ls --cluster-id c9pqfcmw0tq431jdnrrg

OK
VNI ID                                      Worker Node                                            IP Address   MAC Address         VLAN   Floating   Auto-delete
0716-d97d3626-acb2-476b-8b12-bcafa1dec5bb   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000456   10.240.1.5   02:00:02:00:73:A5   250    -          false
0716-aac49630-f3b4-4ef6-9a3a-5145481697ba   kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123   10.240.1.4   02:00:01:00:73:A5   251    -          false

예

ibmcloud ks vni detach --vni 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba --worker kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123

Detach VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123? This action cannot be undone. [y/N]> y
OK
Successfully detached VNI 0716-aac49630-f3b4-4ef6-9a3a-5145481697ba from worker node kube-c9pqfcmw0tq431jdnrrg-mycluster-default-00000123.

일반 파드를 로컬넷 UDN에 연결할 수 없는 이유는 무엇인가요?

로컬넷 UDN은 OVN 측에서 IPAM(IP 주소 관리)이 비활성화되어 있으므로 OVN에서 파드에 대한 정적 IP 주소 할당이 발생하지 않습니다. 이 구성은 DHCP를 사용하거나 게스트 운영 체제 내에서 고정 IP를 설정하는 VM 워크로드용으로 설계되었습니다. 이러한 옵션은 파드 워크로드에는 사용할 수 없습니다.

작업자 풀 전체에서 실시간 마이그레이션이 보류 중인 이유는 무엇인가요?

워커 풀마다 세대와 기능이 다른 CPU를 사용하는 워커의 성향이 다를 수 있습니다. 전체 CPU 기능 세트가 VM 워크로드에 투명하게 표시되는 경우 모든 CPU 기능을 지원하지 않는 다른 워크로드( VM )로 라이브 마이그레이션할 수 없습니다. 게스트 운영 체제에 표시되는 CPU 기능을 처음에 제한하여 워커 버전 간 호환성을 높일 수 있습니다.

동적으로 연결된 VNI가 작동하지 않는 이유는 무엇인가요?

다음 항목을 확인하십시오.

• CUDN의 VLAN ID가 VNI 첨부파일의 VLAN ID와 일치하는지 확인합니다. VLAN이 일치하지 않는 경우에도 VPC DHCP는 추가 트래픽 없이 작동할 수 있습니다.
• 플로팅이 활성화되어 있지 않은 경우 VNI가 연결된 워커에서 워크로드가 예약되어 있는지 확인하세요.
• 전용 OVS 브리지와 매핑이 워크포스에 있는지 확인합니다. NodeNetworkConfigurationPolicy 리소스 상태를 확인하세요.