22.2. OpenShift SDN 클러스터 네트워크 공급자에서 마이그레이션


클러스터 관리자는 OpenShift SDN CNI 클러스터 네트워크 공급자에서 OVN-Kubernetes CNI (Container Network Interface) 클러스터 네트워크 공급자로 마이그레이션할 수 있습니다.

OVN-Kubernetes에 대한 자세한 내용은 OVN-Kubernetes 네트워크 공급자 정보를 읽어보십시오.

22.2.1. OVN-Kubernetes 네트워크 공급자로 마이그레이션

OVN-Kubernetes CNI(Container Network Interface) 클러스터 네트워크 공급자로 마이그레이션하는 것은 클러스터에 연결할 수 없는 몇 가지 중단 시간을 포함하는 수동 프로세스입니다. 롤백 절차가 제공되지만 마이그레이션은 단방향 프로세스로 설정됩니다.

다음 플랫폼에서 OVN-Kubernetes 클러스터 네트워크 공급자로의 마이그레이션이 지원됩니다.

  • 베어 메탈 하드웨어
  • AWS(Amazon Web Services)
  • GCP(Google Cloud Platform)
  • Microsoft Azure
  • Red Hat OpenStack Platform (RHOSP)
  • RHV(Red Hat Virtualization)
  • VMware vSphere

22.2.1.1. OVN-Kubernetes 네트워크 공급자로 마이그레이션에 대한 고려 사항

OpenShift Container Platform 클러스터에 150개 이상의 노드가 있는 경우 OVN-Kubernetes 네트워크 플러그인으로 마이그레이션하기 위한 지원 케이스를 엽니다.

노드에 할당된 서브넷과 개별 포드에 할당된 IP 주소는 마이그레이션 중에 유지되지 않습니다.

OVN-Kubernetes 네트워크 공급자는 OpenShift SDN 네트워크 공급자에 있는 많은 기능을 구현하지만 구성은 동일하지 않습니다.

  • 클러스터에서 다음 OpenShift SDN 기능을 사용하는 경우 OVN-Kubernetes에서 동일한 기능을 수동으로 구성해야 합니다.

    • 네임스페이스 격리
    • 송신 IP 주소
    • 송신 네트워크 정책
    • 송신 라우터 포드
    • 멀티 캐스트
  • 클러스터에서 100.64.0.0/16 IP 주소 범위의 모든 부분을 사용하는 경우 이 IP 주소 범위를 내부적으로 사용하므로 OVN-Kubernetes로 마이그레이션할 수 없습니다.

다음 섹션에서는 OVN-Kubernetes와 OpenShift SDN의 앞서 언급한 기능 간 구성의 차이점을 설명합니다.

네임스페이스 격리

OVN-Kubernetes는 네트워크 정책 격리 모드만 지원합니다.

중요

클러스터가 다중 테넌트 또는 서브넷 격리 모드에서 구성된 OpenShift SDN을 사용하는 경우 OVN-Kubernetes 네트워크 공급자로 마이그레이션할 수 없습니다.

송신 IP 주소

OVN-Kubernetes와 OpenShift SDN 간의 송신 IP 주소를 구성하는 데 있어서 차이점은 다음 표에 설명되어 있습니다.

표 22.2. 송신 IP 주소 구성의 차이점
OVN-KubernetesOpenShift SDN
  • EgressIPs 오브젝트 생성
  • Node 오브젝트에 주석 추가
  • NetNamespace 오브젝트 패치
  • HostSubnet 오브젝트 패치

OVN-Kubernetes에서 송신 IP 주소를 사용하는 방법에 대한 자세한 내용은 " 송신 IP 주소 구성"을 참조하십시오.

송신 네트워크 정책

OVN-Kubernetes와 OpenShift SDN 간의 송신 방화벽이라고도 하는 송신 네트워크 정책 구성의 차이점은 다음 표에 설명되어 있습니다.

표 22.3. 송신 네트워크 정책 구성의 차이점
OVN-KubernetesOpenShift SDN
  • 네임스페이스에 EgressFirewall 오브젝트 생성
  • 네임스페이스에서 EgressNetworkPolicy 오브젝트 생성

OVN-Kubernetes에서 송신 방화벽을 사용하는 방법에 대한 자세한 내용은 "프로젝트에 대한 송신 방화벽 구성"을 참조하십시오.

송신 라우터 Pod

OVN-Kubernetes는 리디렉션 모드에서 송신 라우터 pod를 지원합니다. OVN-Kubernetes는 HTTP 프록시 모드 또는 DNS 프록시 모드에서 송신 라우터 Pod를 지원하지 않습니다.

Cluster Network Operator를 사용하여 송신 라우터를 배포할 때 송신 라우터 Pod를 호스팅하는 데 사용되는 노드를 제어하기 위해 노드 선택기를 지정할 수 없습니다.

멀티 캐스트

OVN-Kubernetes 및 OpenShift SDN에서 멀티 캐스트 트래픽 활성화의 차이점은 다음 표에 설명되어 있습니다.

표 22.4. 멀티 캐스트 구성의 차이점
OVN-KubernetesOpenShift SDN
  • Namespace 오브젝트에 주석 추가
  • NetNamespace 오브젝트에 주석 추가

OVN-Kubernetes에서 멀티 캐스트를 사용하는 방법에 대한 자세한 내용은 "프로젝션에 멀티 캐스트 사용"을 참조하십시오.

네트워크 정책

OVN-Kubernetes는 networking.k8s.io/v1 API 그룹에서 Kubernetes NetworkPolicy API를 완전히 지원합니다. OpenShift SDN에서 마이그레이션할 때 네트워크 정책에 변경 사항이 필요하지 않습니다.

22.2.1.2. 마이그레이션 프로세스의 작동 방식

다음 표는 프로세스의 사용자 시작 단계와 마이그레이션이 수행하는 작업 간에 분할하여 마이그레이션 프로세스를 요약합니다.

표 22.5. OpenShift SDN에서 OVN-Kubernetes로 마이그레이션
사용자 시작 단계마이그레이션 활동

cluster라는 Network.operator.openshift.io CR(사용자 정의 리소스)의 migration 필드를 OVNKubernetes로 설정합니다. 값으로 설정하기 전에 migration 필드가 null인지 확인합니다.

CNO(Cluster Network Operator)
cluster라는 Network.config.openshift.io CR의 상태를 적절하게 업데이트합니다.
Machine Config Operator (MCO)
OVN-Kubernetes에 필요한 systemd 구성에 대한 업데이트를 롤아웃합니다. MCO는 기본적으로 풀당 단일 머신을 업데이트하여 기본적으로 클러스터 크기로 마이그레이션을 늘리는 데 걸리는 총 시간을 생성합니다.

Network.config.openshift.io CR의 networkType 필드를 업데이트합니다.

CNO

다음과 같은 작업을 수행합니다.

  • OpenShift SDN 컨트롤 플레인 pod를 삭제합니다.
  • OVN-Kubernetes 컨트롤 플레인 pod를 배포합니다.
  • 새 클러스터 네트워크 공급자를 반영하도록 Multus 오브젝트를 업데이트합니다.

클러스터의 각 노드를 재부팅합니다.

Cluster
노드가 재부팅되면 클러스터에서 OVN-Kubernetes 클러스터 네트워크의 Pod에 IP 주소를 할당합니다.

OpenShift SDN으로의 롤백이 필요한 경우 다음 표에서 프로세스를 설명합니다.

표 22.6. OpenShift SDN으로 롤백 수행
사용자 시작 단계마이그레이션 활동

MCO가 마이그레이션을 중단하지 않도록 일시 중지합니다.

MCO가 중지됩니다.

cluster 라는 Network.operator.openshift.io CR(사용자 정의 리소스)의 migration 필드를 OpenShiftSDN 으로 설정합니다. 값으로 설정하기 전에 migration 필드가 null인지 확인합니다.

CNO
cluster라는 Network.config.openshift.io CR의 상태를 적절하게 업데이트합니다.

networkType 필드를 업데이트합니다.

CNO

다음과 같은 작업을 수행합니다.

  • OVN-Kubernetes 컨트롤 플레인 pod를 삭제합니다.
  • OpenShift SDN 컨트롤 플레인 포드를 배포합니다.
  • 새 클러스터 네트워크 공급자를 반영하도록 Multus 오브젝트를 업데이트합니다.

클러스터의 각 노드를 재부팅합니다.

Cluster
노드가 재부팅되면 클러스터에서 OpenShift-SDN 네트워크의 pod에 IP 주소를 할당합니다.

클러스터 재부팅의 모든 노드 후에 MCO를 활성화합니다.

MCO
OpenShift SDN에 필요한 systemd 구성에 대한 업데이트를 롤아웃합니다. MCO는 기본적으로 풀당 한 번에 단일 시스템을 업데이트하므로 마이그레이션에 걸리는 총 시간은 클러스터 크기에 따라 늘어납니다.

22.2.2. OVN-Kubernetes 기본 CNI 네트워크 공급자로 마이그레이션

클러스터 관리자는 클러스터의 기본 CNI(Container Network Interface) 네트워크 공급자를 OVN-Kubernetes로 변경할 수 있습니다. 마이그레이션하는 동안 클러스터의 모든 노드를 재부팅해야 합니다.

중요

마이그레이션을 수행하는 동안 클러스터를 사용할 수 없으며 워크로드가 중단될 수 있습니다. 서비스 중단이 허용되는 경우에만 마이그레이션을 수행합니다.

사전 요구 사항

  • 네트워크 정책 격리 모드에서 OpenShift SDN CNI 네트워크 공급자로 구성된 클러스터입니다.
  • OpenShift CLI(oc)를 설치합니다.
  • cluster-admin 역할의 사용자로 클러스터에 액세스할 수 있어야 합니다.
  • etcd 데이터베이스의 최근 백업을 사용할 수 있습니다.
  • 각 노드에 대해 재부팅을 수동으로 트리거할 수 있습니다.
  • 클러스터가 오류 없이 알려진 정상 상태입니다.

프로세스

  1. 클러스터 네트워크의 구성을 백업하려면 다음 명령을 입력합니다.

    $ oc get Network.config.openshift.io cluster -o yaml > cluster-openshift-sdn.yaml
  2. 마이그레이션을 위해 모든 노드를 준비하려면 다음 명령을 입력하여 Cluster Network Operator 구성 개체에서 migration 필드를 설정합니다.

    $ oc patch Network.operator.openshift.io cluster --type='merge' \
      --patch '{ "spec": { "migration": {"networkType": "OVNKubernetes" } } }'
    참고

    이 단계는 OVN-Kubernetes를 즉시 배포하지 않습니다. 대신 migration 필드를 지정하면 OVN-Kubernetes 배포를 준비하기 위해 MCO(Machine Config Operator)가 클러스터의 모든 노드에 새 머신 구성을 적용합니다.

  3. 선택 사항: OVN-Kubernetes에 대해 다음 설정을 사용자 정의하여 네트워크 인프라 요구 사항을 충족할 수 있습니다.

    • 최대 전송 단위(MTU)
    • Geneve(Generic Network Virtualization Encapsulation) 오버레이 네트워크 포트

    이전에 명시된 설정 중 하나를 사용자 정의하려면 다음 명령을 입력하고 사용자 정의합니다. 기본값을 변경할 필요가 없는 경우 패치에서 키를 생략합니다.

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":<mtu>,
              "genevePort":<port>
        }}}}'
    mtu
    Geneve 오버레이 네트워크용 MTU입니다. MTU 값은 일반적으로 자동으로 지정되지만 클러스터의 모든 노드가 동일한 MTU를 사용하지 않을 때는 최소 노드 MTU 값에서 100을 뺀 값으로 명시적으로 설정해야 합니다.
    port
    Geneve 오버레이 네트워크용 UDP 포트입니다. 값을 지정하지 않으면 기본값은 6081입니다. 이 포트는 OpenShift SDN에서 사용하는 VXLAN 포트와 같을 수 없습니다. VXLAN 포트의 기본값은 4789입니다.

    mtu 필드를 업데이트하는 패치 명령 예

    $ oc patch Network.operator.openshift.io cluster --type=merge \
      --patch '{
        "spec":{
          "defaultNetwork":{
            "ovnKubernetesConfig":{
              "mtu":1200
        }}}}'

  4. MCO는 각 머신 구성 풀의 머신을 업데이트할 때 각 노드를 하나씩 재부팅합니다. 모든 노드가 업데이트될 때까지 기다려야 합니다. 다음 명령을 입력하여 머신 구성 풀 상태를 확인합니다.

    $ oc get mcp

    업데이트된 노드의 상태가 UPDATED=true, UPDATING=false,DEGRADED=false입니다.

    참고

    기본적으로 MCO는 풀당 한 번에 하나의 시스템을 업데이트하므로 클러스터 크기에 따라 마이그레이션에 걸리는 총 시간이 증가합니다.

  5. 호스트의 새 머신 구성 상태를 확인합니다.

    1. 머신 구성 상태 및 적용된 머신 구성 이름을 나열하려면 다음 명령을 입력합니다.

      $ oc describe node | egrep "hostname|machineconfig"

      출력 예

      kubernetes.io/hostname=master-0
      machineconfiguration.openshift.io/currentConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/desiredConfig: rendered-master-c53e221d9d24e1c8bb6ee89dd3d8ad7b
      machineconfiguration.openshift.io/reason:
      machineconfiguration.openshift.io/state: Done

      다음 구문이 올바른지 확인합니다.

      • machineconfiguration.openshift.io/state 필드의 값은 Done입니다.
      • machineconfiguration.openshift.io/currentConfig 필드의 값은 machineconfiguration.openshift.io/desiredConfig 필드의 값과 동일합니다.
    2. 머신 구성이 올바른지 확인하려면 다음 명령을 입력합니다.

      $ oc get machineconfig <config_name> -o yaml | grep ExecStart

      여기서 <config_name>machineconfiguration.openshift.io/currentConfig 필드에서 머신 구성의 이름입니다.

      머신 구성은 다음 업데이트를 systemd 구성에 포함해야 합니다.

      ExecStart=/usr/local/bin/configure-ovs.sh OVNKubernetes
    3. 노드가 NotReady 상태에 있는 경우 머신 구성 데몬 포드 로그를 조사하고 오류를 해결합니다.

      1. 포드를 나열하려면 다음 명령을 입력합니다.

        $ oc get pod -n openshift-machine-config-operator

        출력 예

        NAME                                         READY   STATUS    RESTARTS   AGE
        machine-config-controller-75f756f89d-sjp8b   1/1     Running   0          37m
        machine-config-daemon-5cf4b                  2/2     Running   0          43h
        machine-config-daemon-7wzcd                  2/2     Running   0          43h
        machine-config-daemon-fc946                  2/2     Running   0          43h
        machine-config-daemon-g2v28                  2/2     Running   0          43h
        machine-config-daemon-gcl4f                  2/2     Running   0          43h
        machine-config-daemon-l5tnv                  2/2     Running   0          43h
        machine-config-operator-79d9c55d5-hth92      1/1     Running   0          37m
        machine-config-server-bsc8h                  1/1     Running   0          43h
        machine-config-server-hklrm                  1/1     Running   0          43h
        machine-config-server-k9rtx                  1/1     Running   0          43h

        구성 데몬 포드의 이름은 다음 형식입니다. machine-config-daemon-<seq>. <seq> 값은 임의 5자 영숫자 순서입니다.

      2. 다음 명령을 입력하여 이전 출력에 표시된 첫 번째 머신 구성 데몬 포드에 대한 포드 로그를 표시합니다.

        $ oc logs <pod> -n openshift-machine-config-operator

        여기서 pod는 머신 구성 데몬 포드의 이름입니다.

      3. 이전 명령의 출력에 표시된 로그의 오류를 해결합니다.
  6. 마이그레이션을 시작하려면 다음 명령 중 하나를 사용하여 OVN-Kubernetes 클러스터 네트워크 공급자를 구성합니다.

    • 클러스터 네트워크 IP 주소 블록을 변경하지 않고 네트워크 공급자를 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{ "spec": { "networkType": "OVNKubernetes" } }'
    • 다른 클러스터 네트워크 IP 주소 블록을 지정하려면 다음 명령을 입력합니다.

      $ oc patch Network.config.openshift.io cluster \
        --type='merge' --patch '{
          "spec": {
            "clusterNetwork": [
              {
                "cidr": "<cidr>",
                "hostPrefix": <prefix>
              }
            ],
            "networkType": "OVNKubernetes"
          }
        }'

      여기서 cidr은 CIDR 블록이며 prefix는 클러스터의 각 노드에 승인된 CIDR 블록 조각입니다. OVN-Kubernetes 네트워크 공급자가 이 블록을 내부에서 사용하므로 100.64.0.0/16 CIDR 블록과 겹치는 CIDR 블록을 사용할 수 없습니다.

      중요

      마이그레이션 중에 서비스 네트워크 주소 블록을 변경할 수 없습니다.

  7. 후속 단계를 계속 진행하기 전에 Multus 데몬 세트 롤아웃이 완료되었는지 확인합니다.

    $ oc -n openshift-multus rollout status daemonset/multus

    Multus pod의 이름은 multus-<xxxxx> 형식이며 여기서 <xxxxx>는 임의 문자 순서입니다. 포드를 다시 시작하는 데 시간이 다소 걸릴 수 있습니다.

    출력 예

    Waiting for daemon set "multus" rollout to finish: 1 out of 6 new pods have been updated...
    ...
    Waiting for daemon set "multus" rollout to finish: 5 of 6 updated pods are available...
    daemon set "multus" successfully rolled out

  8. 마이그레이션을 완료하려면 클러스터의 각 노드를 재부팅합니다. 예를 들어 다음 예와 유사한 bash 스크립트를 사용할 수 있습니다. 이 스크립트는 ssh를 사용하여 각 호스트에 연결할 수 있고 암호를 묻지 않도록 sudo를 구성했다고 가정합니다.

    #!/bin/bash
    
    for ip in $(oc get nodes  -o jsonpath='{.items[*].status.addresses[?(@.type=="InternalIP")].address}')
    do
       echo "reboot node $ip"
       ssh -o StrictHostKeyChecking=no core@$ip sudo shutdown -r -t 3
    done

    ssh 액세스를 사용할 수 없는 경우 인프라 공급자의 관리 포털을 통해 각 노드를 재부팅할 수 있습니다.

  9. 마이그레이션이 성공했는지 확인합니다.

    1. CNI 클러스터 네트워크 공급자가 OVN-Kubernetes인지 확인하려면 다음 명령을 입력합니다. status.networkType의 값은 OVNKubernetes이어야 합니다.

      $ oc get network.config/cluster -o jsonpath='{.status.networkType}{"\n"}'
    2. 클러스터 노드가 준비 상태에 있는지 확인하려면 다음 명령을 입력합니다.

      $ oc get nodes
    3. Pod가 오류 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get pods --all-namespaces -o wide --sort-by='{.spec.nodeName}'

      노드의 Pod가 오류 상태인 경우 해당 노드를 재부팅합니다.

    4. 모든 클러스터 Operator가 비정상적인 상태가 아닌지 확인하려면 다음 명령을 입력합니다.

      $ oc get co

      모든 클러스터 Operator의 상태는 AVAILABLE="True", PROGRESSING="False", DEGRADED="False"여야 합니다. 클러스터 Operator를 사용할 수 없거나 성능이 저하된 경우 자세한 내용은 클러스터 Operator의 로그를 확인합니다.

  10. 마이그레이션이 성공하고 클러스터가 양호한 상태인 경우에만 다음 단계를 완료합니다.

    1. CNO 구성 오브젝트에서 마이그레이션 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "migration": null } }'
    2. OpenShift SDN 네트워크 제공자에 대한 사용자 정의 구성을 제거하려면 다음 명령을 입력합니다.

      $ oc patch Network.operator.openshift.io cluster --type='merge' \
        --patch '{ "spec": { "defaultNetwork": { "openshiftSDNConfig": null } } }'
    3. OpenShift SDN 네트워크 공급자 네임스페이스를 제거하려면 다음 명령을 입력합니다.

      $ oc delete namespace openshift-sdn

22.2.3. 추가 리소스

Red Hat logoGithubRedditYoutubeTwitter

자세한 정보

평가판, 구매 및 판매

커뮤니티

Red Hat 문서 정보

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

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

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

Red Hat 소개

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

© 2024 Red Hat, Inc.