VMware NSX Container Plugin 4.1.1 릴리스 정보

VMware NSX Container Plugin 4.1.1 | 2023년 8월 17일 | 빌드 22071564 이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오.

새로운 기능

• 이 릴리스부터 새 TAS 배포는 NSX 정책에서만 허용됩니다. 기존 기반의 경우 업그레이드 시 NCP 설정이 변경되지 않습니다.

• 배포 네트워크를 위해 TKGi에서 생성한 NSX 리소스가 이제 MP-정책 마이그레이션 중에 정책으로 마이그레이션됩니다.

• NCP는 지정된 NSX 로드 밸런서 가상 서버에서 최대 500개의 OCP 경로를 지원합니다.

• NSX를 백업했다가 나중에 이전 상태로 복원할 수 있습니다. NCP는 OpenShift 클러스터 및 NSX 리소스가 일관된 상태인지 확인합니다.

• OpenShift Operator는 특정 옵션 구성을 자동화하여 NCP 배포를 간소화할 수 있습니다. configmap에서 입력한 옵션의 유효성 검사도 향상되었습니다.

중단 알림

"ncp/ingress_controller" 주석을 사용하여 NAT를 통해 수신 컨트롤러 포드에 대한 액세스를 허용하는 기능은 더 이상 사용할 수 없으며 2023년에 제거됩니다. 수신 컨트롤러 포드를 노출하는 권장 방법은 로드 밸런서 유형의 서비스를 사용하는 것입니다.

nsx-ovs 커널 모듈은 더 이상 사용되지 않습니다. 업스트림 OVS 커널 모듈만 지원되며 이것은 기본 동작입니다. nsx-node-agent configmap의 "nsx_node_agent" 섹션 아래에서 configmap 옵션 "use_nsx_ovs_kernel_module"이 제거되었습니다.

호환성 요구 사항

제품	버전
TAS(Tanzu Application Service)에 대한 NCP/NSX 타일	4.1.1
NSX	3.2.2, 3.2.3, 4.0.1.1, 4.1.0, 4.1.1
Kubernetes	1.24, 1.25, 1.26
OpenShift 4	4.10, 4.11, 4.12
Kubernetes 호스트 VM OS	Ubuntu 20.04 커널 5.15가 포함된 Ubuntu 22.04(nsx-ovs 커널 모듈 및 업스트림 OVS 커널 모듈이 모두 지원됨) 커널이 5.15 이상인 Ubuntu 22.04(업스트림 OVS 커널 모듈만 지원됨) RHEL: 8.4, 8.5, 8.6 아래의 참고를 참조하십시오.
TAS(Tanzu Application Service)	Ops Manager 2.10 + TAS 2.13 Ops Manager 3.0 + TAS 2.13 Ops Manager 2.10 + TAS 3.0 Ops Manager 3.0 + TAS 3.0 Ops Manager 2.10 + TAS 4.0 Ops Manager 3.0 + TAS 4.0
TKGI(Tanzu Kubernetes Grid Integrated)	1.17

참고:

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

TAS의 새 배포에서는 정책 모드만 지원됩니다.

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

• 4.1.0. 4.1.1 및 모든 4.0.x 릴리스.

제한 사항

• NCP의 "기준선 정책" 기능은 클러스터의 모든 멤버를 선택하는 동적 그룹을 생성합니다. NSX-T에는 동적 그룹의 유효 멤버가 8,000개로 제한됩니다(자세한 내용은 구성 최대값 참조). 따라서 포드가 8,000개 이상으로 증가할 것으로 예상되는 클러스터에 대해서는 이 기능을 사용하도록 설정하지 않아야 합니다. 이 제한을 초과하면 포드에 대한 리소스 생성이 지연될 수 있습니다.

• 투명 모드 로드 밸런서

  • Kubernetes 클러스터에 대한 북-남 트래픽만 지원됩니다. 클러스터 내 트래픽은 지원되지 않습니다.

  • LoadBalancer CRD에 연결된 서비스 또는 자동 크기 조정을 사용하도록 설정된 경우 지원되지 않습니다. 이 기능이 작동하려면 자동 크기 조정을 사용하지 않도록 설정해야 합니다.

  • 이 기능은 새로 배포된 클러스터에서만 사용하는 것이 좋습니다.

• 관리자-정책 마이그레이션

  • 이전 마이그레이션이 실패하고 클러스터가 롤백된 경우 Kubernetes 클러스터를 마이그레이션할 수 없습니다. 이것은 NSX 4.0.0.1 이하 릴리스에만 적용되는 제한 사항입니다.

• 수신/송신 규칙에서 다중 선택기 조건을 사용하는 네트워크 정책을 구현할 때 실제 그룹 멤버 계산에서 성능이 크게 저하되어 네트워크 트래픽에 영향을 미칠 위험이 있습니다. 이 제한을 해결하기 위해 정책 모드에서 다중 선택기를 사용하는 Kubernetes 네트워크 정책에 영향을 미치는 새 구성 옵션인 enable_mixed_expression_groups가 있습니다. 관리자 모드의 클러스터는 영향을 받지 않습니다. 이 옵션의 기본값은 False입니다. 클러스터에서는 다음 값을 사용하는 것이 좋습니다.

  • TKGi

    • 새 클러스터, 정책 모드: False

    • 기존 클러스터(정책 기반): True

    • 관리자-정책 마이그레이션 후: True

  • OC: Kubernetes 네트워크 정책 준수를 보장하려면 True로 설정

  • DIY Kubernetes

    • 새 클러스터(정책 기반): 거짓

    • 기존 클러스터(정책 기반): True

    • 관리자-정책 마이그레이션 후: True

  이 제한은 enable_mixed_expression_groups를 True로 설정된 경우에 적용됩니다. 이는 NCP 버전 3.2.0 이상 및 NSX-T 버전 3.2.0 이상을 사용하는 설치에 영향을 미칩니다. 네트워크 정책이 영향을 미치는 네임스페이스 수에는 제한이 없습니다. 이 옵션이 True로 설정되고 NCP가 다시 시작되면 NCP는 모든 네트워크 정책을 다시 동기화하여 이 동작을 구현합니다.

  enable_mixed_expression_groups가 False로 설정하면 수신/송신 규칙에서 다중 선택기 조건을 사용하는 네트워크 정책이 실제 멤버를 계산할 때 성능 저하의 영향을 받지 않는 동적 NSX 그룹으로 구현됩니다. 그러나 네트워크 정책에 정의된 다른 조건에 따라 최대 5개의 네임스페이스에만 규칙을 적용할 수 있습니다. 네트워크 정책이 언제든지 6개 이상의 네임스페이스에 영향을 미치는 경우 "ncp/error: NETWORK_POLICY_VALIDATION_FAILED"가 주석으로 표시되며 NSX에서 적용되지 않습니다. 이 문제는 다중 선택기 조건을 충족하는 새 네임스페이스가 생성되거나 기존 네임스페이스가 업데이트될 때 발생할 수 있습니다. 이 옵션이 False로 설정되고 NCP가 다시 시작되면 NCP는 모든 네트워크 정책을 다시 동기화하여 이 동작을 구현합니다.

해결된 문제

• 문제 3049209: 관리자-정책 마이그레이션 후 클러스터를 삭제해도 mp_default_LR_xxx_user_rules 리소스가 삭제되지 않음

  관리자-정책 마이그레이션을 수행한 후 클러스터를 삭제하면 이름이 mp_default_LR_xxxx_user_rules인 일부 "GatewayPolicy" 리소스가 삭제되지 않을 수 있습니다.

  해결 방법: 리소스를 수동으로 삭제합니다.

• 문제 3113985: 단일 Tier1 토폴로지를 마이그레이션하는 경우 모든 고정 경로가 마이그레이션되지 않음

  loadbalancers.vmware.com 유형의 사용자 지정 리소스가 여러 개 있는 단일 Tier1 토폴로지에서는 로드 밸런서에 대해 관리자 모드에서 NCP가 생성한 일부 고정 경로가 마이그레이션되지 않습니다.

  해결 방법: Kubernetes에서 loadbalancers.vmware.com 유형의 사용자 지정 리소스를 삭제한 후 관리자 API를 사용하여 고정 경로를 수동으로 삭제합니다. 고정 경로의 태그에는 "ncp/crd_lb_uid" 범위가 있는 사용자 지정 리소스의 UID가 포함됩니다.

• 문제 3055618: 노드에서 여러 Windows 포드를 동시에 생성할 때 일부 포드에 네트워크 어댑터가 없음

  yaml 파일을 적용하여 동일한 노드에 여러 Windows 포드를 생성할 때 일부 포드에 네트워크 어댑터가 없습니다.

  해결 방법: 포드를 다시 시작합니다.

• 문제 3088138: nsx-node-agent-config configmap에서 log_file을 설정하면 nsx-node-agent 포드가 시작되지 않음

  nsx-node-agent-config configmap에서 log_file 옵션을 설정하고 nsx-node-agent 포드 전에 nsx-ncp-bootstrap 포드를 다시 시작하면 nsx-node-agent 포드가 시작되지 못하고 CrashLoopBackOff 상태가 됩니다.

  해결 방법: nsx-node-agent-config configmap에서 log_file 옵션을 설정한 후 nsx-ncp-bootstrap 포드를 다시 시작하기 전에 nsx-node-agent 포드를 다시 시작합니다.

• 문제 3091318: NCP가 종료된 경우 네임스페이스의 고정 서브넷을 업데이트한 후 포드 생성이 실패함

  ncp/subnets가 설정된 상태(예: 172.70.0.0/29)로 네임스페이스를 생성하는 경우 네임스페이스에 아직 포드가 생성되지 않았으며 NCP를 중지하고 ncp/subnets를 172.71.0.0/29 등으로 업데이트하면 NCP를 다시 시작한 후에 네임스페이스에서 포드를 생성하려고 하면 실패하고 포드가 "ContainerCreating" 상태로 중단됩니다.

  해결 방법: 포드를 다시 생성하십시오.

• 문제 3110833: TKGI Windows 작업자 노드의 포드를 시작할 수 없음. 상태는 "ContainerCreating"임

  Windows 작업자 노드의 모든 노드가 시작되지는 못합니다. 노드의 nsx-node-agent 로그가 계속해서 "오류 [...](으)로 인해 cif 구성 요청을 처리하지 못했습니다. 복구하려면 노드 에이전트 서비스를 다시 시작하십시오."를 보고합니다.

  해결 방법: 노드에서 nsx-node-agent 서비스를 다시 시작하십시오.

알려진 문제

• 문제 3306543: 포드를 삭제한 후 동일한 이름으로 생성된 새 포드의 네트워킹 구성이 잘못됨

  드문 경우지만 포드를 삭제하고 동일한 이름으로 새 포드를 생성하면 새 포드에 이전 포드의 네트워크 구성이 적용됩니다. 새 포드의 네트워크 구성이 올바르지 않습니다.

  해결 방법: 새 포드를 삭제하고 nsx-node-agent를 다시 시작한 다음 포드를 다시 생성합니다.

• 문제 3239352: TAS 환경에서 작업을 할당할 수 없는 경우 재시도가 작동하지 않을 수 있음

  NCP TAS 환경에서 작업을 할당할 수 없는 경우 경매인은 작업을 거부하고 BBS는 설정 task.max_retries에서 지정된 횟수까지 작업의 배치를 재시도합니다. task.max_retries에 도달하면 BBS는 작업을 [보류 중] 상태에서 [완료됨] 상태로 업데이트하여 [실패]로 표시하고 클러스터에 작업에 대한 용량이 없음을 설명하는 FailureReason을 포함합니다.

  재시도하는 동안 task_changed 이벤트와 함께 NCP에 알리는 새 셀로 작업을 스케줄링할 수 있습니다. NCP는 task_changed 이벤트를 처리하지 않으므로 작업에서 새 셀에 있는 새 포트를 할당할 수 없습니다. 작업이 제대로 실행될 수 없습니다.

  해결 방법: 재시도를 사용하지 않도록 설정하고 task.max_retries 값을 0으로 설정합니다.

• 문제 3252571: NSX Manager를 사용할 수 없게 되면 관리자-정책 마이그레이션이 완료되지 않음

  관리자-정책 마이그레이션 중에 NSX Manager를 사용할 수 없게 되면 마이그레이션이 완료되지 않을 수 있습니다. 한 가지 징후는 로그에 마이그레이션에 대한 업데이트가 없다는 것입니다.

  해결 방법: NSX Manager에 대한 연결을 다시 설정하고 마이그레이션을 다시 시작합니다.

• 문제 3248662: 작업자 노드가 서비스에 액세스하지 못합니다. 서비스에 대한 OVS 흐름이 노드에 생성되지 않았습니다.

  nsx-kube-proxy 로그에 "greenlet.error: 다른 스레드로 전환할 수 없음" 오류 메시지가 표시됩니다.

  해결 방법: 노드에서 nsx-kube-proxy를 다시 시작합니다.

• 문제 3241693: 생성된 경로 수가 일부 제한을 초과하는 경우 계층 7 경로가 작동을 시작하는 데 10분 이상 소요됨

  OpenShift 환경에서는 ConfigMap에서 플래그 'relax_scale_validation'을 True로, 'l4_lb_auto_scaling'을 False로 설정하여 1000개가 넘는 경로를 배포할 수 있습니다. 그러나 생성된 경로 수가 제한을 초과하면 경로가 작동을 시작하는 데 10분 이상 걸립니다. 500개의 HTTP 경로와 2000개의 HTTP 경로로 제한할 수 있습니다.

  해결 방법: 경로 수에 대한 제한을 초과하지 마십시오. 500개의 HTTPS와 2000개의 HTTP 경로를 생성하는 경우 대형 Edge VM을 사용하여 경로를 배포해야 합니다.

• 문제 3158230: Ubuntu 20.04에서 AppArmor 프로파일을 로드하는 동안 nsx-ncp-bootstrap 컨테이너가 초기화에 실패함

  호스트 OS 및 컨테이너 이미지에 있는 다른 패키지 버전의 AppArmor로 인해 nsx-ncp-bootstrap DaemonSet의 nsx-ncp-bootstrap 컨테이너가 초기화에 실패합니다. 컨테이너의 로그에는 "'/etc/apparmor.d/abi/2.13'에서 정책 기능을 로드하지 못했습니다. 해당 파일 또는 디렉토리가 없습니다."와 같은 메시지가 표시됩니다.

  해결 방법: AppArmor를 버전 2.13.3-7ubuntu5.2 또는 호스트 OS의 focal-updates에서 사용할 수 있는 최신 버전으로 업데이트합니다.

• 문제 3179549: 기존 네임스페이스에 대한 NAT 모드 변경은 지원되지 않음

  기존 포드가 있는 네임스페이스의 경우 NAT 모드를 SNAT에서 NO_SNAT로 변경해도 포드는 container_ip_blocks에 지정된 IP 블록에서 할당된 IP 주소를 계속 사용합니다. 네임스페이스의 세그먼트 서브넷에 사용 가능한 IP 주소가 아직 있는 경우 새로 생성된 포드는 기존 세그먼트 서브넷의 IP 주소를 계속 사용합니다. 새로 생성된 세그먼트의 경우 서브넷이 no_snat_ip_block에서 할당됩니다. 하지만 네임스페이스에서 SNAT 규칙이 삭제됩니다.

  해결 방법: 없음.

• 문제 3218243: NCP를 버전 4.1.1로 업그레이드하거나 사용자가 네임스페이스를 생성/업데이트한 후 다중 선택기 조건을 사용하는 Kubernetes 네트워크 정책에 대해 생성된 NSX의 보안 정책이 제거됨

  NCP에서 "enable_mixed_expression_groups" 옵션이 False로 설정되어 있는지 확인합니다(기본값은 False). 이 경우 네트워크 정책은 지원되지 않는 6개 이상의 그룹 조건을 NSX에 생성합니다.

  해결 방법: NCP 구성 맵에서 enable_mixed_expression_groups를 True로 설정하고 NCP를 다시 시작합니다. 이 경우 네트워크 트래픽에 영향을 미치는 실제 그룹 멤버 계산에서 성능이 크게 저하될 위험이 있습니다.

• 문제 3235394: TKGI 설정에서 네임스페이스 설정이 있는 기준선 정책이 작동하지 않음

  TGKI 환경에서 baseline_policy_type allow_namespace 또는 allow_namespace_strict를 설정하면 NCP는 동일한 네임스페이스 내의 포드만 서로 통신하고 다른 네임스페이스의 수신을 거부하도록 명시적 기준선 정책을 생성합니다. 이 기준선 정책은 kube-system과 같은 시스템 네임스페이스가 서로 다른 네임스페이스의 포드에 액세스하지 못하도록 차단합니다.

  해결 방법: 없음. NCP는 TKGI 설정에서 이 기능을 지원하지 않습니다.

• 문제 3179960: vMotion 후 애플리케이션 인스턴스에 연결할 수 없으며 다른 애플리케이션 인스턴스와 IP 주소가 동일함

  예를 들어 NSX 호스트 업그레이드 중에 대량 vMotion이 발생하면 호스트가 하나씩 유지 보수 모드로 전환되고 Diego 셀이 호스트 간에 마이그레이션됩니다. vMotion 후 일부 세그먼트 포트가 누락되고, 일부 애플리케이션 인스턴스에 연결할 수 없으며, 두 애플리케이션 인스턴스의 IP 주소가 같을 수 있습니다. 이 문제는 TAS 2.13.18에서 발생할 가능성이 높습니다.

  해결 방법: 이 문제의 영향을 받는 애플리케이션 인스턴스를 다시 생성합니다.

• 문제 3108579: LB CRD를 삭제하고 동일한 암호를 사용하여 즉시 다시 생성하지 못함

  관리자 모드에서 LB CRD에서 수신을 삭제하고 LB CRD를 삭제한 후 동일한 인증서로 수신 및 LB CRD를 즉시 다시 생성하면 "이미 가져온 인증서를 가져오려고 했습니다." 오류가 표시될 수 있습니다. 이 문제는 LB CRD 삭제는 수신 삭제가 완료될 때까지 기다려야 하므로 타이밍 문제로 인해 발생합니다.

  해결 방법: 다음 중 하나를 수행합니다.

  - 다음 명령을 실행하여 수신 삭제가 완료될 때까지 기다린 후 LB CRD를 삭제합니다.

  • kubectl exec -ti <pod name> -nnsx-system -- nsxcli -c get ingress-caches|grep ‘name: <Ingress name>’

  - 수신 및 LB CRD를 다시 생성하기 전에 2분 이상 기다립니다.

• 문제 3161931: nsx-ncp-bootstrap 포드를 Ubuntu 18.04 및 Ubuntu 20.04 호스트 VM에서 실행하지 못함

  nsx-ncp-bootstrap 포드의 nsx-ncp-bootstrap 컨테이너가 다음 로그 메시지와 함께 "AppArmor"를 다시 로드하지 못합니다. "'/etc/apparmor.d/abi/2.13'에서 정책 기능을 로드하지 못했습니다. 해당 파일 또는 디렉토리가 없습니다." 이 문제는 nsx-ncp-bootstrap 포드 및 호스트 OS를 실행하는 데 사용되는 이미지에 설치된 다양한 버전의 "AppArmor" 패키지로 인해 발생합니다. 이 문제는 Ubuntu 22.04 호스트 VM에는 존재하지 않습니다.

  해결 방법: Ubuntu 18.04는 NCP 4.1.1에서 지원되지 않습니다. Ubuntu 20.04에서 "AppArmor"를 최소 버전 2.13.3-7ubuntu5.2로 업데이트합니다. 패키지는 소형 업데이트를 통해 사용할 수 있습니다.

• 문제 3221191: 클러스터에 4000개 이상의 포드가 있는 경우 도메인 그룹 생성이 실패함

  NCP 옵션 k8s.baseline_policy_type이 allow_cluster, allow_namespace 또는 allow_namespace_strict로 설정되고 클러스터에 4000개가 넘는 포드가 있는 경우 포드의 모든 IP 주소를 포함하는 도메인 그룹(dg-k8sclustername과 같은 이름 사용)이 생성되지 않습니다. 이 문제는 NSX의 제한으로 인해 발생합니다.

  해결 방법: k8s.baseline_policy_type 옵션을 설정하거나 클러스터에 4000개 미만의 포드가 있는지 확인하십시오.

• 문제 3043496: 관리자-정책 마이그레이션이 실패하면 NCP가 실행을 중지함

  NCP는 NCP 및 TKGI에서 사용하는 NSX 리소스를 마이그레이션하기 위한 migrate-mp2p 작업을 제공합니다. 마이그레이션이 실패하면 마이그레이션된 모든 리소스가 롤백되지만 관리자 모드에서 NCP가 다시 시작되지 않습니다.

  해결 방법:

  1. 모든 리소스가 롤백되었는지 확인합니다. 이 작업은 migrate-mp2p 작업의 로그를 확인하여 수행할 수 있습니다. 로그는 "정책으로 가져온 모든 MP 리소스가 완전히 롤백되었습니다." 줄로 끝나야 합니다.

  2. 모든 리소스가 롤백된 경우 각 마스터 노드에 대해 ssh를 실행하고 "sudo /var/vcap/bosh/bin/monit start ncp" 명령을 실행합니다.

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

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

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

• 문제 2999131: 포드에서 ClusterIP 서비스에 연결할 수 없음

  대규모 TKGi 환경에서는 포드에서 ClusterIP 서비스에 연결할 수 없습니다. 기타 관련 문제는 다음과 같습니다. (1) nsx-kube-proxy가 nsx-kube-proxy의 로그 출력을 중지합니다. (2) OVS 흐름이 노드에 생성되지 않습니다.

  해결 방법: nsx-kube-proxy를 다시 시작합니다.

• 문제 2984240: matchExpressions의 "NotIn" 연산자가 네트워크 정책 규칙의 namespaceSelector에서 작동하지 않음

  네트워크 정책에 대한 규칙을 지정할 때 namespaceSelector, matchExpressions 및 "NotIn" 연산자를 지정하면 규칙이 작동하지 않습니다. NCP 로그에 "NS 선택기에서 NotIn 연산자가 지원되지 않습니다."라는 오류 메시지가 표시됩니다.

  해결 방법: matchExpressions를 다시 작성하여 "NotIn" 연산자를 사용하지 않도록 합니다.

• 문제 3033821: 관리자-정책 마이그레이션 후 분산 방화벽 규칙이 올바르게 적용되지 않음

  관리자-정책 마이그레이션 후 새로 생성된 네트워크 정책 관련 DFW(분산 방화벽) 규칙이 마이그레이션된 DFW 규칙보다 우선 순위가 높습니다.

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

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

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

  해결 방법: 없음

• 문제 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 생성 가상 서버에 연결하도록 선택하면 다른 애플리케이션 워크플로가 손상될 수 있습니다.

  해결 방법: 없음

• 문제 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 리소스를 업데이트하지 마십시오.

• 문제 2416376: NCP에서 128개가 넘는 공백에 바인딩되는 TAS ASG(애플리케이션 보안 그룹)를 처리하지 못함

  NSX-T 분산 방화벽 제한 때문에 NCP는 128개가 넘는 공백에 바인딩되는 TAS ASG를 처리할 수 없습니다.

  해결 방법: 여러 개의 ASG를 생성하고 각각에 128개 이상의 공백이 포함되지 않도록 바인딩합니다.

• 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 주소를 추가하는 것은 지원되지 않습니다.

• 문제 2672677: 고도로 과부하된 OpenShift 4 환경에서 노드가 응답하지 않을 수 있음

  노드당 포드 밀도가 높으며 포드 삭제 및 생성 빈도가 높은 OpenShift 4 환경에서 RHCOS 노드가 "준비되지 않음" 상태로 전환될 수 있습니다. daemonset 멤버를 제외하고 영향을 받는 노드에서 실행되는 포드는 해당 환경의 다른 노드에서 제거된 후 다시 생성됩니다.

  해결 방법: 영향을 받는 노드를 재부팅합니다.

• 문제 2707174: 삭제한 후 동일한 네임스페이스 및 이름으로 다시 생성한 포트에 네트워크 연결이 없음

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

  해결 방법: NCP가 실행 중일 때 포드를 삭제한 후 다시 생성하십시오.

• 문제 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 컨테이너 둘 다에 대한 시간제한 값을 업데이트합니다.

• 문제 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에서 고정 포드를 제거하는 대신 매니페스트 파일을 삭제하여 고정 포드를 제거합니다.

• 문제 2824129: 노드가 다시 시작되고 3분 넘게 network-unavailable true 상태를 유지함

  NCP Operator를 사용하여 NCP의 수명 주기를 관리하는 경우 nsx-node-agent daemonset이 비실행 중 상태에서 복구되면 해당 노드는 3분 동안 실행될 때까지 network-unavailable 상태가 true로 유지됩니다. 이는 예상된 동작입니다.

  해결 방법: nsx-node-agent가 다시 시작되면 최소 3분 동안 기다리십시오.

• 문제 2832480: ClusterIP 유형의 Kubernetes 서비스에 대해 sessionAffinityConfig.clientIP.timeoutSeconds는 65535를 초과할 수 없음

  ClusterIP 유형의 Kubernetes 서비스의 경우 sessionAffinityConfig.clientIP.timeoutSeconds를 65535보다 큰 값으로 설정하면 실제 값은 65535가 됩니다.

  해결 방법: 없음

• 문제: 2940772: NSX-T 3.2.0을 사용할 경우 NCP 리소스를 관리자에서 정책으로 마이그레이션하면 실패함

  NCP 리소스를 관리자에서 정책으로 마이그레이션하는 것은 NSX-T 3.1.3 및 NSX-T 3.2.1에서는 지원되지만 NSX-T 3.2.0에서는 지원되지 않습니다.

  해결 방법: 없음

• 문제 2934195: 일부 유형의 NSX 그룹은 분산 방화벽 규칙에 대해 지원되지 않습니다.

  "IP 주소만" 유형의 NSX 그룹은 DFW(분산 방화벽) 규칙에 대해 지원되지 않습니다. 수동으로 IP 주소를 멤버로 추가한 "일반" 유형의 NSX 그룹도 지원되지 않습니다.

  해결 방법: 없음

• 문제 2939886: 관리자 모드에서 정책 모드로의 개체 마이그레이션이 실패함

  네트워크 정책 규격에서 송신 및 수신에 동일한 선택기가 사용되는 경우 관리자 모드에서 정책 모드로의 개체 마이그레이션이 실패합니다.

  해결 방법: 없음

• 문제 3066449: use_ip_blocks_in_order가 True로 설정된 경우 네임스페이스 서브넷이 사용 가능한 첫 번째 IP 블록에서 항상 할당되지는 않음

  use_ip_blocks_in_order가 True로 설정된 여러 네임스페이스를 생성하는 경우 사용 가능한 첫 번째 IP 블록에서 첫 번째 네임스페이스의 서브넷이 할당되지 않는 경우가 있습니다. 예를 들어 container_ip_blocks가 '172.52.0.0/28,172.53.0.0/28'이고 서브넷 접두사 길이가 29이고 서브넷 172.52.0.0/29가 이미 할당되어 있다고 가정합니다. 2개의 네임스페이스 ns-1 및 ns-2를 생성하는 경우 서브넷 할당은 (1) ns-1일 수 있습니다. 172.52.0.8/29, ns-2: 172.53.0.0/29 또는 (2) ns-1: 172.53.0.0/29, ns-2: 172.52.0.8/29.

  use_ip_blocks_in_order 매개 변수는 다른 IP 블록이 container_ip_blocks 매개 변수에 표시되는 순서대로만 사용되도록 합니다. 여러 네임스페이스를 동시에 생성하는 경우 네임스페이스가 다른 네임스페이스보다 먼저 API 호출을 통해 서브넷을 요청할 수 있습니다. 따라서 특정 네임스페이스에 특정 IP 블록의 서브넷이 할당된다는 보장은 없습니다.

  해결 방법: 다음 네임스페이스를 별도로 생성합니다. 첫 번째 네임스페이스를 생성하고 해당 서브넷이 할당되었는지 확인한 후, 다음 네임스페이스를 생성합니다.