VMware NSX Container Plug-in 2.5   |  2019년 9월 24일   |   빌드 14628220

이 설명서의 추가 사항 및 업데이트 사항을 정기적으로 확인하십시오.

릴리스 정보에 포함된 내용

릴리스 정보에는 다음과 같은 항목이 포함됩니다.

새로운 기능

NCP(NSX Container Plug-in) 2.5에는 다음과 같은 새로운 기능이 포함되어 있습니다.
  • 정책 API를 사용하여 NSX-T 리소스를 구성하기 위한 지원
  • 추가 토폴로지 지원 클러스터의 모든 네임스페이스 간에 공유되는 공유 Tier-1 라우터를 Kubernetes 클러스터별로 1개씩 소유하는 옵션이 제공됩니다. 이 토폴로지에서는 SNAT NAT 규칙(있는 경우)과 같은 상태 저장 서비스가 Tier-1 라우터에 연결되어 사용자에게 액티브-액티브 Tier-0 토폴로지를 유지하는 옵션을 제공합니다. 다른 토폴로지에서 사용 가능한 모든 기능을 공유 Tier-1 토폴로지에서도 사용할 수 있습니다.
  • Kubernetes 노드의 초기화를 자동화하는 새로운 DaemonSet, nsx-ncp-bootstrap
  • VM에서 OVS를 실행하는 nsx-node-agent DaemonSet 내부의 새 컨테이너인 nsx-ovs
  • NCP 설치를 간소화하는 단일 YAML 파일. YAML 파일에는 NCP 및 컨테이너 호스트 구성 요소에 필요한 모든 Kubernetes 리소스 정의가 포함되어 있습니다.
  • NCP 마스터 선택에 Kubernetes CustomResourceDefinitions 사용 지원
  • NSX BOSH 릴리스에서 여러 CNI 플러그인 지원

호환성 요구 사항

제품 버전
PAS에 대한 NCP/NSX-T 타일 2.5
NSX-T 2.4.1, 2.4.2, 2.5
Kubernetes 1.13, 1.14
OpenShift 3.10, 3.11
Kubernetes 호스트 VM OS     Ubuntu 16.04, Ubuntu 18.04, CentOS 7.6
OpenShift 호스트 VM OS RHEL 7.5, RHEL 7.6
OpenShift BMC RHEL 7.5, RHEL 7.6
PAS(PCF) Ops Manager 2.8 + PAS 2.8
Ops Manager 2.7 + PAS 2.7
Ops Manager 2.6 + PAS 2.6
Ops Manager 2.5 + PAS 2.5
참고: PAS 2.7.0 + NCP 2.5.0은 지원되지 않습니다.

참고: 이번 NCP 릴리스에서는 Linux 버전 4.15.0-59-generic 이상을 지원하지 않습니다.

RHEL 노드의 커널 버전이 3.10.0-957.27.2보다 이전인 경우 OpenShift 설치 사전 요구 사항이 실패합니다. OVS가 실행되지 않으므로 베어 메탈 컨테이너 노드에서 커널 버전을 업그레이드하지 않는 것이 좋습니다. 이전 커널 버전을 사용하여 OpenShift 3.11을 배포하려면 openshift-ansible 저장소에서 commit: e0499023ea91741ab4afd29391e420a26b8859b5를 최상위 커밋으로 사용해야 합니다.

 

해결된 문제

  • 문제 2389094: NCP에서 로드 밸런서 서버를 삭제할 때 해당 Tier-1 라우터가 삭제되지 않음

    자동 크기 조정을 사용하도록 설정한 경우 사용자가 LoadBalancer 유형의 여러 서비스를 생성하면 NCP가 필요한 만큼의 로드 밸런서 가상 서버를 생성합니다. 그런 다음, 사용자가 서비스 개수를 줄이면 이로 인해 NCP가 로드 밸런서 가상 서버를 삭제해도 해당하는 Tier-1 라우터가 삭제되지 않습니다.

  • 문제 2118515: 대규모 설정에서 NCP가 NSX-T에 방화벽을 생성하는 시간이 오래 걸림

    대규모(예: Kubernetes 노드 250개, 포드 5000개, 네트워크 정책 2500개) 설정에서 NCP가 NSX-T에 방화벽 섹션과 규칙을 생성하는 데 몇 분 정도 걸릴 수 있습니다.

  • 문제 2125755: 카나리아 업데이트 및 단계적 롤링 업데이트를 수행할 때 StatefullSet의 네트워크 연결이 끊길 수 있음

    NCP가 현재 릴리스로 업그레이드되기 전에 StatefulSet이 생성된 경우 카나리아 업데이트 및 단계적 롤링 업데이트를 수행할 때 StatefullSet의 네트워크 연결이 끊길 수 있습니다.

  • 문제 2193901: 단일 Kubernetes 네트워크 정책 규칙에 대해 여러 PodSelector 또는 여러 NsSelector가 지원되지 않음

    여러 선택기를 적용하면 특정 포드에서 들어오는 트래픽만 허용됩니다.

  • 문제 2194646: NCP가 다운되면 네트워크 정책 업데이트가 지원되지 않음

    NCP가 종료된 상태에서 네트워크 정책을 업데이트하면 NCP가 다시 시작될 때 네트워크 정책의 대상 IPset가 유효하지 않게 됩니다.

  • 문제 2199504: NCP에서 생성된 NSX-T 리소스의 표시 이름이 80자로 제한됨

    NCP에서 컨테이너 환경의 리소스에 대한 NSX-T 리소스가 생성되는 경우, 클러스터 이름, 네임스페이스 또는 프로젝트 이름, 컨테이너 환경에 있는 리소스의 이름을 결합하여 NSX-T 리소스의 표시 이름이 생성됩니다. 표시 이름이 80자 보다 길면 80자로 잘립니다.

  • 문제 2199778: NSX-T 2.2에서는 이름이 65자보다 긴 수신, 서비스 및 암호가 지원되지 않음

    NSX-T 2.2에서 use_native_loadbalancerTrue로 설정되면 수신, 수신에서 참조하는 암호 및 서비스, LoadBalancer 유형 서비스 등의 이름이 65자 이하여야 합니다. 그렇지 않으면 수신 또는 서비스가 정상적으로 작동하지 않습니다.

  • 문제 2065750: 파일 충돌로 인해 NSX-T CNI 패키지 설치가 실패함

    Kubernetes가 설치된 RHEL 환경에서 yum localinstall 또는 rpm -i를 사용하여 NSX-T CNI 패키지를 설치하면, kubernetes-cni 패키지의 파일과 충돌을 나타내는 오류가 발생합니다.

  • 문제 2317608: 여러 CNI 플러그인이 지원되지 않음

    Kubernetes에는 .conflist 유형의 CNI 구성 파일이 있어야 합니다. 이 파일에는 플러그인 구성 목록이 포함되어 있습니다. Kubelet에서 이 conflist 파일에 정의된 플러그인을 정의된 순서대로 하나씩 호출합니다. 현재 nsx-cf-cni bosh 릴리스에서는 단일 CNI 플러그인 구성만 지원합니다. 추가 CNI 플러그인은 지정된 cni_config_dir에서 기존 CNI 구성 파일 10-nsx.conf를 덮어씁니다. 

알려진 문제

  • 문제 2131494: 수신 클래스를 nginx에서 nsx로 변경한 후에도 NGINX Kubernetes 수신이 계속 작동함

    NGINX Kubernetes 수신을 생성할 때 NGINX에서 트래픽 전달 규칙이 생성됩니다. 수신 클래스를 다른 값으로 변경하면 클래스를 변경한 후에 Kubernetes 수신을 삭제하더라도 NGINX에서 규칙이 삭제되지 않고 계속 적용됩니다. 이 문제는 NGINX의 제한 사항입니다.

    해결 방법: NGINX에서 생성된 규칙을 삭제하려면 클래스 값이 nginx일 때 Kubernetes 수신을 삭제합니다. 그런 다음 Kubernetes 수신을 다시 생성합니다.

  • ClusterIP 유형의 Kubernetes 서비스에 대해 클라이언트 IP 기반 세션 선호도가 지원되지 않음

    NCP는 ClusterIP 유형의 Kubernetes 서비스에 대해 클라이언트 IP 기반 세션 선호도를 지원하지 않습니다.

    해결 방법: 없음

  • ClusterIP 유형의 Kubernetes 서비스에 대해 hairpin-mode 플래그가 지원되지 않음

    NCP는 ClusterIP 유형의 Kubernetes 서비스에 대해 hairpin-mode 플래그를 지원하지 않습니다.

    해결 방법: 없음

  • 문제 2192489: PAS director 구성에서 'BOSH DNS server'를 사용하지 않도록 설정한 후에도 컨테이너의 resolve.conf 파일에 Bosh DNS 서버(169.254.0.2)가 계속 나타남

    PAS 2.2를 실행하는 PAS 환경의 PAS director 구성에서 'BOSH DNS 서버'를 사용하지 않도록 설정한 후에도 컨테이너의 resove.conf 파일에 Bosh DNS 서버(169.254.0.2)가 여전히 나타납니다. 이로 인해 FQDN(정규화된 도메인 이름)을 사용한 ping 명령에 시간이 오래 걸립니다. PAS 2.1에는 이 문제가 존재하지 않습니다.

    해결 방법: 없음. 이 문제는 PAS 문제입니다.

  • 문제 2224218: 서비스 또는 애플리케이션을 삭제했을 때 SNAT IP가 다시 IP 풀로 릴리스되는 데 2분이 걸림

    서비스 또는 애플리케이션을 삭제하고 2분 내에 다시 생성하면 IP 풀에서 새로운 SNAT IP를 받게 됩니다.

    해결 방법: 동일한 IP를 다시 사용하려면 서비스 또는 애플리케이션을 삭제하고 다시 생성하기 전에 2분을 기다립니다.

  • 문제 2330811: NCP가 종료된 상태에서 LoadBalancer 유형의 Kubernetes 서비스를 생성할 경우 NCP가 다시 시작되면 서비스가 생성되지 않을 수 있음

    NSX-T 리소스가 LoadBalancer 유형의 Kubernetes 서비스에 사용되는 경우 기존 서비스 중 일부를 삭제한 후 새 서비스를 생성할 수 있습니다. 하지만 NCP가 종료된 상태에서 서비스를 삭제했다가 생성하면 NCP가 새 서비스를 생성하지 못합니다.

    해결 방법: NSX-T 리소스가 LoadBalancer 유형의 Kubernetes 서비스에 사용되는 경우 NCP가 종료된 상태에서 삭제 및 생성 작업을 둘 다 수행하지는 마십시오.

  • 문제 2370137: OVS 데이터베이스 파일이 /etc/openvswitch에 있지 않으므로 nsx-ovs 및 nsx-node-agent 컨테이너가 실행되지 않음

    nsx-ovs 및 nsx-node-agent 컨테이너는 시작 시 /etc/openvswitch에서 OVS 데이터베이스 파일을 찾습니다. 실제 OVS 파일(예: conf.db)에 연결되는 디렉토리에 심볼릭 링크가 있는 경우 nsx-ovs 및 nsx-node-agent 컨테이너가 실행되지 않습니다.

    해결 방법: OVS 데이터베이스 파일을 /etc/openvswitch로 이동하고 symlink를 제거하십시오.

  • 문제 2397438: 다시 시작한 후 NCP에서 MultipleObjects 오류를 보고함

    다시 시작하기 전에 NCP가 ServerOverload 오류 때문에 분산 방화벽 섹션을 생성하지 못합니다. 최대 시도 횟수에 도달할 때까지 NCP가 다시 시도됩니다. 그러나 방화벽 섹션이 계속 생성됩니다. NCP가 다시 시작되면 중복된 방화벽 섹션이 수신되고 MultipleObjects 오류가 보고됩니다.

    해결 방법: 오래된 중복 분산 방화벽 섹션을 수동으로 삭제한 다음, NCP를 다시 시작하십시오.

  • 문제 2397684: NCP가 정확한 전송 영역을 찾았지만 "기본 전송 영역이 구성되지 않았습니다." 오류와 함께 실패함

    정책 API 기반 NCP를 사용하여 Kubernetes 네임스페이스를 생성할 때 NSX-T에 여러 오버레이 전송 영역이 있기 때문에 인프라 세그먼트가 생성되지 않을 수 있습니다. 이 문제는 기본값으로 표시된 오버레이 전송 영역이 없는 경우에 발생합니다.

    해결 방법: NCP ConfigMap에 구성된 오버레이 전송 영역을 업데이트하고 "is_default" 필드를 "True"로 설정하십시오.

  • 문제 2404302: NSX-T에 동일한 리소스 유형(예: HTTP)의 로드 밸런서 애플리케이션 프로파일이 여러 개 있는 경우 NCP가 이 중 하나를 선택해서 가상 서버에 연결함

    NSX-T에 여러 HTTP 로드 밸런서 애플리케이션 프로파일이 있는 경우 NCP는 적절한 x_forwarded_for 구성의 프로파일을 하나 선택해서 HTTP 및 HTTPS 가상 서버에 연결합니다. NSX-T에 여러 FastTCP 및 UDP 애플리케이션 프로파일이 있는 경우 NCP는 이 중 하나를 선택해서 TCP 및 UDP 가상 서버에 각각 연결합니다. 로드 밸런서 애플리케이션 프로파일이 다른 설정이 적용된 다른 애플리케이션에서 생성되었을 수 있습니다. NCP가 로드 밸런서 애플리케이션 프로파일 중 하나를 NCP 생성 가상 서버에 연결하도록 선택하면 다른 애플리케이션 워크플로가 손상될 수 있습니다.

    해결 방법: 없음

  • 문제 2397621: OpenShift를 설치하지 못함

    OpenShift를 설치하려면 노드가 준비 상태여야 하며, 이를 위해서는 CNI 플러그인을 설치해야 합니다. 이 릴리스에서는 별도의 CNI 플러그인 파일이 없기 때문에 OpenShift를 설치하지 못합니다.

    해결 방법: 설치를 시작하기 전에 각 노드에 /etc/cni/net.d 디렉토리를 생성하십시오.

  • 문제 2398430: 다시 시작한 후 노드에 대한 연결이 끊어짐

    시작 시 노드에서 OVS가 실행되도록 구성되고, NSX 노드 에이전트 DaemonSet이 실행 중이고 IP가 ovs_uplink_port 상태일 때 노드를 다시 시작하면 노드에 대한 연결이 끊어집니다.

    해결 방법: 노드를 시작할 때 해당 서비스를 제거하여 호스트에서 OVS를 시작할 수 없도록 설정하십시오. 예를 들어, Ubuntu에서 update-rc.d -f openvswitch-switch remove를 실행할 수 있습니다.

  • 문제 2408100: 대형 Kubernetes 클러스터에서 액티브-대기 모드인 NCP 인스턴스가 여러 개이거나 작동 여부 프로브를 사용하도록 설정하면 NCP가 자주 다시 시작됨

    대형 Kubernetes 클러스터(약 25,000개 포드, 2,500개 네임스페이스 및 2,500개 네트워크 정책)에서 여러 NCP 인스턴스가 액티브-대기 모드에서 실행 중이거나 작동 여부 프로브를 사용하도록 설정한 경우, NCP 프로세스가 “잠금 획득 중 충돌 발생” 또는 작동 여부 프로브 실패로 인해 중지되었다가 자주 다시 시작될 수 있습니다. 

    해결 방법: 다음 단계를 수행합니다.

    1. NCP 배포의 replicas를 1로 설정하거나 ncp.ini의 구성 옵션 ha.master_timeout을 기본값 18에서 30으로 늘립니다.
    2. 작동 여부 프로브 인수를 다음과 같이 늘립니다.
        containers:
          - name: nsx-ncp
            livenessProbe:
              exec:
                command:
                  - /bin/sh
                  - -c
                  - timeout 20 check_pod_liveness nsx-ncp
              initialDelaySeconds: 20
              timeoutSeconds: 20
              periodSeconds: 20
              failureThreshold: 5
      
  • 문제 2412421: Docker가 컨테이너를 다시 시작하지 못함

    (1) ConfigMap이 업데이트되고, (2) 컨테이너가 subPath를 사용해서 ConfigMap을 탑재하고, (3) 컨테이너가 다시 시작될 경우 Docker가 컨테이너를 시작하지 못합니다.

    해결 방법: 포드를 삭제하여 DaemonSet가 포드를 다시 생성하도록 하십시오.

  • 문제 2413383: 일부 노드가 준비되지 않아 OpenShift를 업그레이드하지 못함

    기본적으로 NCP 부트스트랩 포드는 마스터 노드에서 예약되지 않습니다. 따라서 마스터 노드 상태는 항상 [준비 안 됨]입니다.

    해결 방법: “계산” 역할이 있는 마스터 노드를 할당하여 nsx-ncp-bootstrap 및 nsx-node-agent DaemonSets에서 포드를 생성할 수 있도록 하십시오. nsx-ncp-bootstrap이 NSX-CNI를 설치하면 노드 상태가 "준비"로 변경됩니다.

  • 문제 2410909: 다시 시작한 후 NCP가 대규모 환경(특히 많은 네트워크 정책이 있는 경우)에서 캐시를 초기화하는 데 오랜 시간이 걸릴 수 있으며, 새 포드 및 리소스를 표시하고 처리할 때까지 약 30분 정도 걸릴 수 있음

    다시 시작한 후 NCP를 표시하는 데 시간이 오래 걸릴 수 있습니다. 포드, 네임스페이스 및 네트워크 정책과 같은 리소스를 처리하려면 관련 리소스의 양에 따라 추가 시간이 걸릴 수 있습니다.

    해결 방법: 없음

  • 문제 2423240: IP 경로가 링크-종료 상태인 경우 nsx-ncp-bootstrap 컨테이너가 실행되지 않음

    nsx-ncp-bootstrap 컨테이너는 모든 IP 경로의 링크 상태가 "실행"이라고 가정하고, 그렇지 않으면 실행되지 않습니다.

    해결 방법: 부트스트랩이 완료된 후 링크 상태가 "실행"이 아닌 경로를 제거했다가 다시 추가하십시오.

  • 문제 2425050: nsx-ncp-bootstrap 컨테이너가 Linux 버전 4.15.0-59-generic 이상에서 OVS 패키지를 컴파일하지 못함

    OVS 커널 모듈을 컴파일하는 동안 헤더 파일이 누락되어 컴파일하지 못합니다.

    해결 방법: 없음. NCP 2.5.0에서는 Linux 버전 4.15.0-59-generic 이상을 지원하지 않습니다.

check-circle-line exclamation-circle-line close-line
Scroll to top icon