times

VMware NSX Container Plugin 3.1.2 | 2021년 4월 15일 | 빌드 17855682

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

릴리스 정보에 포함된 내용

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

새로운 기능
호환성 요구 사항
해결된 문제
알려진 문제

새로운 기능

NCP(NSX Container Plugin) 3.1.2에는 다음과 같은 새로운 기능이 포함되어 있습니다.

계층 7 로드 밸런서 지속성의 경우 쿠키 이름 지정 지원

중단 알림

NCP 3.3에서 "ncp/whitelist-source-range" 주석을 더 이상 사용할 수 없습니다. NCP 3.1.1부터는 "ncp/allowed-source-range" 주석을 대신 사용할 수 있습니다.

호환성 요구 사항

제품	버전
TAS(Tanzu Application Service)에 대한 NCP/NSX-T 타일	3.1.2
NSX-T	3.0.3, 3.1.0, 3.1.1, 3.1.2, 3.1.3
vSphere	6.7, 7.0
Kubernetes	1.18, 1.19, 1.20
OpenShift 3	3.11 참고: OpenShift 3.x 지원은 향후 릴리스에서 더는 사용되지 않습니다.
OpenShift 4	RHCOS 4.6, 4.7
Kubernetes 호스트 VM OS	Ubuntu 18.04, Ubuntu 20.04 CentOS 7.8, CentOS 7.9, CentOS 8.3 RHEL 7.8, RHEL 7.9, RHEL 8.1, RHEL 8.3 아래의 참고를 참조하십시오.
OpenShift 3 호스트 VM OS	RHEL 7.7, RHEL 7.8(참고: 이 두 Kubernetes에 대한 RHEL 지원은 향후 릴리스에서 더는 사용되지 않습니다.)
Tanzu Application Service	Ops Manager 2.7 + TAS 2.7(LTS) Ops Manager 2.9 + TAS 2.9 Ops Manager 2.10 + TAS 2.10 Ops Manager 2.10 + TAS 2.11
TKGI(Tanzu Kubernetes Grid Integrated)	1.11

참고:

CentOS/RHEL에 nsx-ovs 커널 모듈을 설치하려면 특정 커널 버전이 필요합니다. 지원되는 RHEL 커널 버전은 RHEL 버전과 관계없이 1127 및 1160입니다. 기본 커널 버전은 RHEL 7.8의 경우 1127, RHEL 7.9의 경우 1160입니다. 다른 커널 버전을 실행 중인 경우 nsx-node-agent 구성 맵의 "nsx_node_agent" 섹션에서 "use_nsx_ovs_kernel_module"을 "False"로 설정하여 nsx-ovs 커널 모듈의 설치를 건너뛸 수 있습니다.

NCP 3.1.2부터 RHEL 이미지가 더 이상 배포되지 않습니다. 지원되는 모든 통합에 대해 Red Hat UBI(범용 기본 이미지)를 사용할 수 있습니다. 자세한 내용은 https://www.redhat.com/ko/blog/introducing-red-hat-universal-base-image를 참조하십시오.

이 릴리스로의 업그레이드 지원:

모든 이전 3.1.x 릴리스 및 모든 NCP 3.0.x 릴리스

해결된 문제

문제 2707883: nsx-ncp-operator가 실행되고 있지 않을 때 리소스가 삭제된 경우 nsx-ncp-operator가 NCP 관련 Kubernetes 리소스를 생성하지 않음
예를 들어, nsx-ncp-operator가 실행되고 있지 않을 때 nsx-node-agent 또는 nsx-ncp-bootstrap DaemonSet을 삭제하면 nsx-ncp-operator가 다시 실행될 때 다시 생성되지 않습니다.

알려진 문제

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

해결 방법: 없음. 이 문제는 TAS 문제입니다.
문제 2224218: 서비스 또는 애플리케이션을 삭제했을 때 SNAT IP가 다시 IP 풀로 릴리스되는 데 2분이 걸림
서비스 또는 애플리케이션을 삭제하고 2분 내에 다시 생성하면 IP 풀에서 새로운 SNAT IP를 받게 됩니다.

해결 방법: 동일한 IP를 다시 사용하려면 서비스 또는 애플리케이션을 삭제하고 다시 생성하기 전에 2분을 기다립니다.
문제 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 3 설치가 실패함
OpenShift 3을 설치하려면 노드가 준비 상태여야 하며, 이를 위해서는 CNI 플러그인을 설치해야 합니다. 이 릴리스에서는 별도의 CNI 플러그인 파일이 없기 때문에 OpenShift를 설치하지 못합니다.

해결 방법: 설치를 시작하기 전에 각 노드에 /etc/cni/net.d 디렉토리를 생성하십시오.
문제 2413383: 일부 노드가 준비되지 않아 OpenShift 3을 업그레이드하지 못함
기본적으로 NCP 부트스트랩 포드는 마스터 노드에서 예약되지 않습니다. 따라서 마스터 노드 상태는 항상 [준비 안 됨]입니다.

해결 방법: “계산” 역할이 있는 마스터 노드를 할당하여 nsx-ncp-bootstrap 및 nsx-node-agent DaemonSets에서 포드를 생성할 수 있도록 하십시오. nsx-ncp-bootstrap이 NSX-CNI를 설치하면 노드 상태가 "준비"로 변경됩니다.
문제 2451442: NCP를 반복적으로 다시 시작하고 네임스페이스를 재생성한 후 NCP가 IP 주소를 포드에 할당하지 못할 수 있음
NCP를 다시 시작하는 동안 동일한 네임스페이스를 반복적으로 삭제하고 다시 생성한 경우 NCP가 해당 네임스페이스의 포드에 IP 주소를 할당하지 못할 수 있습니다.

해결 방법: 네임스페이스와 연결된 모든 부실 NSX 리소스(논리적 라우터, 논리적 스위치 및 논리적 포트)를 삭제한 다음, 다시 생성합니다.
문제 2460219: 기본 서버 풀이 없으면 HTTP 리디렉션이 작동하지 않음
HTTP 가상 서버가 서버 풀에 바인딩되지 않으면 HTTP 리디렉션이 실패합니다. 이 문제는 NSX-T 2.5.0 및 이전 릴리스에서 발생합니다.

해결 방법: 기본 서버 풀을 생성하거나 NSX-T 2.5.1로 업그레이드합니다.
문제 2518111: NCP가 NSX-T에서 업데이트된 NSX-T 리소스를 삭제하지 못함
NCP는 지정한 구성에 따라 NSX-T 리소스를 생성합니다. NSX Manager 또는 NSX-T API를 통해 해당 NSX-T 리소스를 업데이트하는 경우 NCP가 해당 리소스를 삭제했다가 필요할 때 다시 생성하지 못할 수 있습니다.

해결 방법: NCP가 NSX Manager 또는 NSX-T API를 통해 생성한 NSX-T 리소스를 업데이트하지 마십시오.
문제 2524778: NCP 마스터 노드를 삭제한 후에 NSX Manager에 NCP가 종료 또는 비정상으로 표시됨
NCP 마스터 노드를 삭제한 후(예: 백업 노드로 성공적으로 전환한 후), NCP의 상태가 실행 중일 때도 계속 종료로 표시됩니다.

해결 방법: Manager API DELETE /api/v1/systemhealth/container-cluster/<cluster-id>/ncp/status를 사용하여 오래된 상태를 수동으로 지우십시오.
문제 2517201: ESXi 호스트에서 포드를 생성할 수 없음
vSphere 클러스터에서 ESXi 호스트를 제거한 후 클러스터에 다시 추가하면 호스트에서 포드를 생성하지 못합니다.

해결 방법: NCP를 재부팅합니다.
문제 2416376: NCP에서 128개가 넘는 공백에 바인딩되는 TAS ASG(애플리케이션 보안 그룹)를 처리하지 못함
NSX-T 분산 방화벽 제한 때문에 NCP는 128개가 넘는 공백에 바인딩되는 TAS ASG를 처리할 수 없습니다.

해결 방법: 여러 개의 ASG를 생성하고 각각에 128개 이상의 공백이 포함되지 않도록 바인딩합니다.
문제 2534726: NSX-T 타일을 통해 NCP 3.0.1로 업그레이드하는 데 실패하는 경우 BOSH 명령줄을 사용하여 업그레이드를 다시 실행하면 성능 문제가 발생함
OpsMgr에서 NSX-T 타일을 통해 NCP 3.0.1로 업그레이드하는 경우 NCP에서 사용되는 NSX Manager의 HA 스위칭 프로파일이 비활성으로 표시됩니다. NCP가 다시 시작되면 스위칭 프로파일이 삭제됩니다. 업그레이드가 실패하고 “bosh deploy -d <deployment-id> -n <deployment>.yml”과 같은 BOSH 명령을 사용하여 업그레이드를 다시 실행하면 HA 스위칭 프로파일이 삭제되지 않습니다. NCP가 계속 실행되지만 성능이 저하됩니다.

해결 방법: 항상 BOSH 명령줄이 아닌 OpsMgr를 통해 NCP를 업그레이드하십시오.
문제 2537221: NSX-T를 3.0으로 업그레이드한 후 NSX Manager UI의 컨테이너 관련 개체에 대한 네트워킹 상태가 알 수 없음으로 표시됨
NSX Manager UI에서 탭 [인벤토리] > [컨테이너]에는 컨테이너 관련 개체와 해당 상태가 표시됩니다. TKGI 환경에서 NSX-T를 3.0으로 업그레이드한 후 컨테이너 관련 개체의 네트워킹 상태가 [알 수 없음]으로 표시됩니다. 이 문제는 TKGI에서 NSX-T의 버전 변경을 감지하지 못하기 때문에 발생합니다. NCP가 포드로 실행 중이고 작동 여부 프로브가 활성 상태인 경우에는 이 문제가 발생하지 않습니다.

해결 방법: NSX-T 업그레이드한 후에는 NSX Manager를 오버로드하지 않도록 NCP 인스턴스를 점진적으로(동시에 10개 이하) 다시 시작합니다.
문제 2550474: OpenShift 환경에서 HTTPS 경로를 HTTP로 변경하면 HTTP 경로가 예상대로 작동하지 않을 수 있음
HTTPS 경로를 편집하고 TLS 관련 데이터를 삭제하여 HTTP 경로로 변환하는 경우 HTTP 경로가 예상대로 작동하지 않을 수 있습니다.

해결 방법: HTTPS 경로를 삭제하고 새 HTTP 경로를 생성합니다.
문제 2552573: OpenShift 4.3 환경에서 DHCP가 정책 UI를 사용하여 구성된 경우 클러스터 설치가 실패할 수 있음
OpenShift 4.3 환경에서 클러스터를 설치하려면 DHCP 서버를 사용하여 IP 주소 및 DNS 정보를 제공할 수 있어야 합니다. 정책 UI를 사용하여 NSX-T에 구성된 DHCP 서버를 사용하는 경우 클러스터 설치가 실패할 수 있습니다.

해결 방법: 관리자 UI를 사용하여 DHCP 서버를 구성하고, 설치하지 못한 클러스터를 삭제했다가 클러스터를 다시 생성합니다.
문제 2552564: OpenShift 4.3 환경에서 겹치는 주소를 찾았으면 DNS 전달자가 작동을 중지할 수 있음
OpenShift 4.3 환경에서 클러스터를 설치하려면 DNS 서버를 구성해야 합니다. NSX-T를 사용하여 DNS 전달자를 구성하고 IP 주소가 DNS 서비스와 겹치면 DNS 전달자의 작동이 중지되고 클러스터 설치가 실패합니다.

해결 방법: 외부 DNS 서비스를 구성하고, 설치하지 못한 클러스터를 삭제한 후 클러스터를 다시 생성합니다.
문제 2483242: 컨테이너의 IPv6 트래픽이 NSX-T SpoofGuard에 의해 차단됨
SpooGuard를 사용하도록 설정한 경우 IPv6 링크 로컬 주소가 자동으로 화이트리스트에 추가되지 않습니다.

해결 방법: NCP 구성에서 nsx_v3.enable_spoofguard = False를 설정하여 SpoofGuard를 사용하지 않도록 설정합니다.
문제 2552609 - 잘못된 XFF(X-Forwarded-For) 및 X-Forwarded-Port 데이터
HTTPS 수신 규칙(Kubernetes) 또는 HTTPS 경로(OpenShift)에 대해 INSERT 또는 REPLACE를 사용하여 XFF를 구성하는 경우 XFF 헤더에 잘못된 X-Forwarded-For 및 X-Forwarded-Port 값이 표시될 수 있습니다.

해결 방법: 없음.
문제 2555336: 관리자 모드에서 생성된 중복된 논리적 포트로 인해 포드 트래픽이 작동하지 않음
이 문제는 여러 클러스터에 여러 개의 포드가 있을 때 발생할 가능성이 높습니다. 포드를 생성하면 포드 트래픽이 작동하지 않습니다. NSX-T에는 동일한 컨테이너에 대해 생성된 여러 논리적 포트가 표시됩니다. NCP 로그에는 논리적 포트 중 하나의 ID만 찾을 수 있습니다.

해결 방법: 포드를 삭제한 후 다시 생성합니다. NCP가 다시 시작되면 NSX-T의 오래된 포트가 제거됩니다.
문제 2554357: IPv6에는 로드 밸런서 자동 크기 조정이 작동하지 않음
IPv6 환경에서 기존 로드 밸런서 크기에 도달하면 LoadBalancer 유형의 Kubernetes 서비스가 활성화되지 않습니다.

해결 방법: TKGI 배포의 경우에는 /var/vcap/jobs/ncp/config/ncp.ini에서, 다른 배포의 경우에는 nsx-ncp-configmap에서 nsx_v3.lb_segment_subnet = FE80::/10을 설정합니다. 그런 다음, NCP를 다시 시작합니다.
문제 2597423: 관리자 개체를 정책으로 가져올 때 롤백으로 인해 일부 리소스의 태그가 손실되었습니다.
관리자 개체를 정책으로 가져올 때 롤백이 필요한 경우 다음 개체의 태그가 복원되지 않습니다.
- Spoofguard 프로필(공유 및 클러스터 리소스의 일부)
- BgpneighbourConfig(공유 리소스의 일부)
- BgpRoutingConfig(공유 리소스의 일부)
- StaticRoute BfdPeer(공유 리소스의 일부)
해결 방법: 공유 리소스의 일부인 리소스에서는 태그를 수동으로 복원합니다. 백업 및 복원 기능을 사용하여 클러스터 리소스의 일부인 리소스를 복원합니다.
문제 2579968: LoadBalancer 유형의 Kubernetes 서비스를 자주 변경하면 일부 가상 서버와 서버 풀이 예상대로 삭제되지 않습니다.
LoadBalancer 유형의 Kubernetes 서비스를 자주 변경하면 일부 가상 서버와 서버 풀이 삭제되어야 하는데도 NSX-T 환경에 남아 있을 수 있습니다.

해결 방법: NCP를 다시 시작합니다. 또는 오래된 가상 서버와 관련 리소스를 수동으로 제거합니다. LoadBalancer 유형의 Kubernetes 서비스에 있는 external_id 태그에 가상 서버의 식별자가 없는 경우 가상 서버가 오래된 것입니다.
문제 2536383: NSX-T를 3.0 이상으로 업그레이드한 후에 NSX-T UI에 NCP 관련 정보가 올바르게 표시되지 않습니다.
NSX-T를 3.0 이상으로 업그레이드한 후 NSX-T UI의 인벤토리 > 컨테이너 탭에 컨테이너 관련 개체의 네트워킹 상태가 [알 수 없음]으로 표시됩니다. 또한 NCP 클러스터가 시스템 > 패브릭 > 노드 > NCP 클러스터 탭에 표시되지 않습니다. 이 문제는 일반적으로 TKGI 환경에서 표시됩니다.

해결 방법: NSX-T 업그레이드한 후에는 NCP 인스턴스를 점진적으로(동시에 10개 이하) 다시 시작합니다.
문제 2622099: LoadBalancer 유형의 Kubernetes 서비스가 오류 코드 NCP00113 및 오류 메시지 "다른 사용자가 개체를 수정했습니다."를 나타내며 초기화에 실패했습니다.
정책 API를 사용하는 단일 계층 배포에서, 기존 Tier-1 게이트웨이를 상위 계층 게이트웨이로 사용하고 게이트웨이의 풀 할당 크기가 [라우팅]인 경우 유형 LoadBalancer의 Kubernetes 서비스가 오류 코드 NCP00113 및 오류 메시지 "다른 사용자가 개체를 수정했습니다. 다시 시도하십시오.”를 나타내며 초기화되지 않을 수 있습니다.

해결 방법: 이 문제가 나타나면 5분 동안 기다립니다. 그런 다음, NCP를 다시 시작합니다. 문제가 해결될 것입니다.
문제 2633679: NCP Operator가 API/policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id>를 사용하여 생성된 Tier-1 세그먼트에 연결되는 OpenShift 노드를 지원하지 않습니다.
NCP Operator가 API/policy/api/v1/infra/tier-1s/<tier1-id>/segments/<segment-id>를 사용하여 생성된 Tier-1 세그먼트에 연결되는 OpenShift 노드를 지원하지 않습니다.

해결 방법: API/policy/api/v1/infra/segments/<segment-id>를 사용하여 세그먼트를 생성합니다.
Kubernetes 설치 중에 "파일에 로깅"을 사용하도록 설정하면 NCP가 시작되지 않습니다.
이 문제는 컨테이너 호스트의 uid:gid=1000:1000에 로그 폴더에 대한 사용 권한이 없는 경우에 발생합니다.

해결 방법: 다음 중 하나를 수행합니다.
- 컨테이너 호스트에서 로그 폴더의 모드를 777로 변경합니다.
- 컨테이너 호스트에서 로그 폴더의 "rwx" 사용 권한을 uid:gid=1000:1000에 부여합니다.
- "파일에 로깅" 기능을 사용하지 않도록 설정합니다.
문제 2653214: 노드의 IP 주소가 변경된 후에 노드에서 세그먼트 포트를 검색하는 동안 오류가 발생했습니다.
노드의 IP 주소를 변경한 후 NCP를 업그레이드하거나 NCP Operator 포드를 다시 시작하는 경우 "oc describe co nsx-ncp" 명령을 사용하여 NCP Operator 상태를 확인하면 "노드에서 세그먼트 포트를 검색하는 동안 오류가 발생했습니다."라는 오류 메시지가 표시됩니다.

해결 방법: 없음. DHCP 구성도 있는 노드 인터페이스에 고정 IP 주소를 추가하는 것은 지원되지 않습니다.
문제 2664457: OpenShift에서 DHCP를 사용하는 동안 nsx-node-agent가 시작되거나 다시 시작되면 연결이 일시적으로 끊어질 수 있음
nsx-ovs는 5개 임시 연결 프로파일을 생성하고 활성화하여 ovs_bridge를 구성하지만 NetworkManager에서 해당 활성화가 일시적으로 실패할 수 있습니다. 따라서 ovs_uplink_port 및/또는 ovs_bridge에 VM에 IP(연결)가 없습니다.

해결 방법: VM을 다시 시작하거나 모든 프로파일이 NetworkManager에서 활성화될 때까지 기다릴 수 있습니다.
문제 2672677: 고도로 과부하된 OpenShift 4 환경에서 노드가 응답하지 않을 수 있음
노드당 포드 밀도가 높으며 포드 삭제 및 생성 빈도가 높은 OpenShift 4 환경에서 RHCOS 노드가 "준비되지 않음" 상태로 전환될 수 있습니다. daemonset 멤버를 제외하고 영향을 받는 노드에서 실행되는 포드는 해당 환경의 다른 노드에서 제거된 후 다시 생성됩니다.

해결 방법: 영향을 받는 노드를 재부팅합니다.
문제 2706551: 설치 중에 노드가 준비되지 않은 경우 OpenShift의 IPI(전체 스택 자동 설치)가 실패함
연결 유지 포드는 Kubernetes API 서버가 실행되기 전에 Kubernetes VIP를 마스터 노드의 ovs_bridge 클러스터에 추가합니다. 그 결과 Kubernetes API 서버에 대한 모든 요청이 실패하고 설치를 완료할 수 없습니다.

해결 방법: 없음
문제 2697547: RHEL/CentOS/RHCOS 노드에서 HostPort가 지원되지 않음
nsx-node-agent ConfigMap에서 'enable_hostport_snat'를 True로 설정하여 네이티브 Kubernetes의 hostPorts 및 Ubuntu 노드의 TKGI를 지정할 수 있습니다. 그러나 RHEL/CentOS/RHCOS 노드에서 hostPort는 지원되지 않으며 ‘enable_hostport_snat’ 매개 변수는 무시됩니다.

해결 방법: 없음
문제 2707174: 삭제한 후 동일한 네임스페이스 및 이름으로 다시 생성한 포트에 네트워크 연결이 없음
NCP가 실행되고 있지 않고 nsx-ncp-agent가 실행 중일 때 포드를 삭제한 후 동일한 네임스페이스 및 이름으로 다시 생성하면 포드에는 잘못된 네트워크 구성이 지정될 수 있으며 네트워크에 액세스할 수 없습니다.

해결 방법: NCP가 실행 중일 때 포드를 삭제한 후 다시 생성하십시오.
문제 2713782: NSX API 호출이 실패하고 다음 오류가 표시됩니다. "SSL: DECRYPTION_FAILED_OR_BAD_RECORD_MAC"
경우에 따라 NCP를 시작할 때 로드 밸런서에 대해 중복된 로드 밸런싱 서버 또는 로드 밸런스용 Tier-1 논리적 라우터가 존재하기 때문에 NCP가 다시 시작될 수도 있고, 로드 밸런서 서비스를 초기화하지 못할 수 있습니다. 또한 NCP가 실행되는 짧은 시간(1초 미만) 동안 NSX 끝점이 DOWN 상태로 보고될 수 있습니다. 로드 밸런서 초기화에 실패하면 NCP 로그에 "로드 밸런서 서비스를 초기화하지 못했습니다."라는 메시지가 표시됩니다.

이 동작은 NCP가 여러 NSX Manager 인스턴스에서 클라이언트 측 로드 밸런싱을 수행하고 있을 때만 발생합니다. 단일 API 끝점이 ncp.ini에 구성된 경우에는 발생하지 않습니다.

해결 방법: nsx_v3.conn_idle_timeout 매개 변수 값을 늘립니다. 이로 인해 클라이언트 측 로드 밸런싱을 사용할 때 일시적으로 연결이 끊긴 후 끝점이 사용 가능하다고 감지될 때까지 대기 시간이 길어질 수 있습니다.
문제 2745904: "기본 실행 ASG에 IPSet 사용" 기능은 기존 컨테이너 IP 블록의 제거 또는 교체를 지원하지 않습니다.
NCP 타일에서 "기본 실행 ASG에 IPSet 사용"을 사용하도록 설정하면 NCP는 동일한 NCP 타일에서 "컨테이너 네트워크의 IP 블록"으로 구성된 모든 컨테이너 IP 블록에 대해 전용 NSGroup을 생성합니다. 이 NSGroup은 모든 컨테이너에 대한 트래픽을 허용하기 위해 글로벌 실행 ASG에 대해 생성된 방화벽 규칙에 사용됩니다. 나중에 기존 컨테이너 IP 블록을 제거하거나 교체하면 NSGroup에서 제거되거나 교체됩니다. 원래 IP 블록의 모든 기존 컨테이너가 실행 중인 글로벌 ASG와 더 이상 연결되지 않습니다. 해당 트래픽이 더 이상 작동하지 않을 수 있습니다.

해결 방법: 새 IP 블록만 "컨테이너 네트워크의 IP 블록"에 추가합니다.
문제 2744480: Kubernetes 서비스 셀프 액세스가 KVM에서 지원되지 않습니다.
Kubernetes 포드가 끝점인 Kubernetes 서비스를 통해 자신에게 액세스하려고 할 경우 KVM 호스트에서 응답 패킷이 삭제됩니다.

해결 방법: 없음
문제 2744361: nsx-node-agent 포드가 종료될 때 고정 IP 주소로 구성된 OpenShift의 워크로드 VM 연결이 끊어될 수 있습니다.
경우에 따라 nsx-node-agent 포드가 종료될 때 고정 IP 주소로 구성된 OpenShift의 워크로드 VM 연결이 끊어집니다.

해결 방법: VM을 재부팅합니다.
문제 2746362: nsx-kube-proxy가 Kubernetes apiserver로부터 Kubernetes 서비스 이벤트를 수신하지 못합니다.
경우에 따라 OpenShift 클러스터에서 nsx-kube-proxy가 Kubernetes apiserver로부터 Kubernetes 서비스 이벤트를 수신하지 못합니다. "nsxcli -c get kube-proxy-watchers" 명령은 출력 "Watcher thread status: Up"을 제공하지만 "처리된 이벤트 수"가 0입니다. 즉, nsx-kube-proxy가 apiserver로부터 이벤트를 수신하지 못했습니다.

해결 방법: nsx-kube-proxy 포드를 다시 시작합니다.
문제 2745907: "monit" 명령이 nsx-node-agent에 대한 잘못된 상태 정보를 반환합니다.
diego_cell VM에서 monit가 nsx-node-agent를 다시 시작할 때 nsx-node-agent가 완전히 시작되는 데 30초가 넘게 걸리는 경우 monit는 nsx-node-agent의 상태를 "실행 실패"로 표시하고 nsx-node-agent가 나중에 완전히 작동할 때도 해당 상태를 "실행 중"으로 업데이트하지 않습니다.

해결 방법: 없음.
문제 2735244: 작동 여부 프로브 오류로 인한 nsx-node-agent 및 nsx-kube-proxy 충돌
nsx-node-agent 및 nsx-kube-proxy는 sudo를 사용하여 일부 명령을 실행합니다. /etc/resolv.conf에 DNS 서버 및 검색 도메인에 대한 항목이 많은 경우 sudo가 호스트 이름을 확인하는 데 시간이 오래 걸릴 수 있습니다. 이로 인해 nsx-node-agent 및 nsx-kube-proxy가 sudo 명령에 의해 장시간 차단되어 작동 프로브가 실패합니다.

해결 방법: 다음 두 작업 중 하나를 수행합니다.
- /etc/hosts에 호스트 이름 항목을 추가합니다. 예를 들어 호스트 이름이 'host1'이면 '127.0.0.1 host1' 항목을 추가합니다.
- nsx-node-agent 작동 프로브 시간제한에 대해 더 큰 값을 설정합니다. 'kubectl edit ds nsx-node-agent -nsx-system’ 명령을 실행하여 nsx-node-agent 및 nsx-kube-proxy 컨테이너 둘 다에 대한 시간제한 값을 업데이트합니다.
문제 2744557: 캡처 그룹 () 및 {0} 둘 다를 포함하는 복잡한 정규식 패턴은 수신 경로 일치에서 지원되지 않습니다.
예를 들어 정규식 패턴이 다음과 같은 경우: /foo/bar/(abc){0,1}, /foo/bar/을 검색하지 않습니다.

해결 방법: 수신 정규식 규칙을 생성할 때 캡처 그룹 () 및 {0}을(를) 사용하지 않습니다. /foo/bar/를 일치 항목으로 검색하려면 정규식 패턴 EQUALS를 사용합니다.
문제 2751080: KVM 호스트 업그레이드 후 컨테이너 호스트가 Kubernetes 포드를 실행할 수 없습니다.
KVM 호스트 업그레이드 후 업그레이드된 호스트에 배포된 컨테이너 호스트는 Kubernetes 포드를 실행할 수 없습니다. 포드는 컨테이너 생성 상태로 유지됩니다. NCP Operator가 배포되면 노드의 상태가 NotReady가 되고 networkUnavailable 노드 조건이 True가 될 수 있습니다. 이 문제는 RHEL에서만 볼 수 있으며 Ubuntu에서는 나타나지 않습니다.

해결 방법: KVM 하이퍼바이저에서 nsx-opsagent를 다시 시작합니다.
문제 2736412: max_allowed_virtual_servers 매개 변수가 설정되어 있으면 members_per_small_lbs는 무시됩니다.
max_allowed_virtual_servers 및 members_per_small_lbs가 둘 다 설정된 경우 max_allowed_virtual_servers만 고려되므로 가상 서버는 사용 가능한 로드 밸런서에 연결하지 못할 수 있습니다.

해결 방법: 자동 크기 조정을 사용하도록 설정하는 대신 확장 제약 조건을 완화합니다.
문제 2740552: api-server를 사용하여 고정 포드를 삭제하는 경우 nsx-node-agent가 포드의 OVS 브리지 포트를 제거하지 않으며 Kubernetes에서 자동으로 다시 생성된 고정 포드의 네트워크를 사용할 수 없습니다.
Kubernetes는 api-server에서 고정 포드를 제거할 수 없습니다. 고정 포드의 미러 포드가 Kubernetes에서 생성되면 api-server에서 고정 포드를 검색할 수 있습니다. api-server에서 포드를 삭제하는 동안 미러 포드만 삭제되고 NCP가 포드에 할당된 모든 NSX 리소스 제거 요청을 수신하고 처리합니다. 그러나 고정 포드는 여전히 존재하게 되며 nsx-node-agent는 고정 포드의 OVS 브리지 포트를 제거하기 위한 CNI의 삭제 요청을 받지 못합니다.

해결 방법: api-server에서 고정 포드를 제거하는 대신 매니페스트 파일을 삭제하여 고정 포드를 제거합니다.
문제 2795268: nsx-node-agent와 hyperbus의 대칭 이동 및 Kubernetes 포드 간 연결이 생성 상태에서 중단됩니다.
대규모 환경에서는 nsx-node-agent가 Kubernetes apiserver에 연결하여 포드 정보를 얻지 못할 수 있습니다. 많은 양의 정보가 전송 중이기 때문에 keepalive 메시지를 hyperbus로 전송할 수 없는 경우 hyperbus가 연결을 닫습니다.

해결 방법: nsx-node-agent를 다시 시작합니다. Kubernetes apiserver가 사용 가능한지, apiserver에 연결하는 인증서가 올바른지 확인합니다.
문제 2795482: 노드/하이퍼바이저 재부팅 또는 다른 작업 후 실행 중인 포드가 컨테이너 생성 상태에서 중단됩니다.
wait_for_security_policy_sync 플래그가 true인 경우 포드는 작업자 노드 하드 재부팅, 하이퍼바이저 재부팅 또는 기타 다른 이유로 인해 1시간 이상 실행 상태 유지 후 컨테이너 생성 상태가 될 수 있습니다. 포드가 계속해서 생성 상태에 있게 됩니다.

해결 방법: 포드를 삭제하고 다시 생성합니다.
문제 2871314: TKGI를 1.10.x에서 1.11.x(1.11.6 이전)로 업그레이드한 후 NSX 로드 밸런서의 수신 인증서가 삭제됩니다.
NCP 3.1.1부터 인증서가 수정 번호로 추적됩니다. 이로 인해 TKGI 1.10.x를 TKGI 1.11.x(1.11.6 이전)로 업그레이드할 때 문제가 발생하여 NSX 로드 밸런서의 수신 인증서가 삭제되고 다시 가져오지 않습니다.

해결 방법: 다음 중 하나를 수행합니다.
1. NCP를 다시 시작합니다. 또는
2. Kubernetes 환경에서 암호를 삭제하고 동일한 암호를 다시 생성합니다. 또는
3. TKGI 1.11.6 이상으로 업그레이드하십시오.
문제 2871321: TKGI를 1.10.x에서 1.11.x(1.11.6 이전)로 업그레이드한 후 CRD LoadBalancer가 L7 쿠키 지속성을 사용하는 경우 IP 주소가 손실됩니다.
이 문제는 NSX 로드 밸런서에서 쿠키 이름 업데이트를 지원하는 NCP 3.1.1의 새로운 기능으로 인해 발생합니다.

해결 방법: 다음 중 하나를 수행합니다.
1. 쿠키 지속성 대신 소스 IP 지속성을 사용합니다.
2. TKGI 1.11.6 이상으로 업그레이드하십시오.
문제 3033821: 관리자-정책 마이그레이션 후 분산 방화벽 규칙이 올바르게 적용되지 않음
관리자-정책 마이그레이션 후 새로 생성된 네트워크 정책 관련 DFW(분산 방화벽) 규칙이 마이그레이션된 DFW 규칙보다 우선 순위가 높습니다.

해결 방법: 정책 API를 사용하여 필요에 따라 DFW 규칙의 순서를 변경합니다.