This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

릴리스 정보에 포함된 내용

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

새로운 기능

새로운 기능, 2024년 6월 25일

VMware vSphere 8.0 업데이트 3 | 2024년 6월 25일 

vCenter Server 8.0 업데이트 3 | 2024년 6월 25일 | ISO 빌드 24022515

VMware ESXi 8.0 업데이트 3 | 2024년 6월 25일 | ISO 빌드 24022510

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023년 10월 11일

HAProxy 2.2.2 Community Edition, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 3.0 | 2024년 6월 25일

vSphere IaaS 제어부 8.0 업데이트 3에는 다음과 같은 새로운 기능과 향상된 기능이 추가되었습니다.

  • 감독자 및 TKG 인증서 자동 순환 - 이 릴리스는 새로운 인증서 순환 메커니즘을 제공합니다. 감독자 및 TKG 클러스터 인증서는 만료되기 전에 자동으로 순환됩니다. 자동 순환이 실패하면 vCenter에서 알림을 받게 되며 인증서를 수동으로 갱신해야 합니다.

  • 확장된 vSAN 클러스터의 감독자, vSphere 포드 및 TKG 클러스터 지원 - 이 릴리스부터 vSAN 확장된 클러스터에서 실행되도록 감독자를 구성할 수 있습니다. 이 구성은 그린필드 환경에서만 지원됩니다. 즉, vSAN 클러스터가 확장되어 있어야 하며 워크로드 관리 및 컨텐츠 라이브러리가 아직 구성되지 않은 상태여야 합니다. 이러한 두 구성 요소는 vSAN 확장된 클러스터 스토리지 정책으로 구성해야 합니다. 자세한 내용은 설명서를 참조하십시오.

  • VM 서비스 VM에 대한 VM 클래스가 이제 네임스페이스 범위임 - 이 릴리스에서는 kubectl을 사용하여 VM 클래스를 나열할 때 특정 vSphere 네임스페이스로 범위가 지정된 VM 클래스만 볼 수 있습니다. 이전에는 VM 클래스가 클러스터 범위의 리소스였기 때문에 특정 네임스페이스에 어떤 VM 클래스가 할당되었고 사용 가능한지 확인하기 어려웠습니다.

  • 감독자 백업 및 복원 - 이제 vSphere에서 감독자의 백업 및 복원이 지원됩니다. 이제 vCenter 백업의 일부로 감독자의 백업을 구성하고 재해 복구, 업그레이드 실패, 중단 및 기타 복구 시나리오의 경우 백업에서 감독자를 복원할 수 있습니다. 감독자 제어부 백업 및 복원을 참조하십시오.

  • VM 서비스 VM 백업 및 복원 - 이제 vSphere에서 VM 서비스 VM의 백업 및 복원이 지원됩니다. 이제 VADP 기반 백업 벤더를 사용하여 VM 서비스 VM을 보호할 수 있습니다. 중단 또는 데이터 손실과 관련된 다른 시나리오가 발생하는 경우 백업에서 vSphere 네임스페이스의 VM을 복원할 수 있습니다.

  • 이제 VM Operator API v1alpha2를 사용할 수 있음 - VM Operator API의 다음 버전인 VM Operator v1alpha2가 릴리스되었습니다. 이번 릴리스에서는 인라인 Cloud-Init 및 Windows 지원, 향상된 게스트 네트워킹 구성, 향상된 상태 기능, 사용자 정의 준비 게이트 지원, 새로운 VirtualMachineWebConsoleRequest API, 향상된 API 설명서 및 기타 기능을 포함한 향상된 부트스트랩 제공자 지원이 제공됩니다. 

  • 감독자에서 로그 전달을 위해 Fluent Bit 활용 - 이제 외부 로그 모니터링 플랫폼으로 감독자 제어부 로그 및 시스템 로그의 로그 전달을 지원할 수 있습니다. 자세한 내용은 설명서를 참조하십시오.

  • 감독자 서비스에 대한 개인 레지스트리 지원 - 이제 감독자 서비스로 배포된 워크로드가 개인 레지스트리에서 이미지 및 패키지를 끌어올 수 있도록 허용하는 개인 레지스트리 세부 정보를 정의할 수 있습니다. 이는 에어갭 환경을 지원하기 위한 일반적인 요구 사항입니다. 자세한 내용은 설명서를 참조하십시오.

  • 감독자 업그레이드 워크플로 개선 사항 - 이제 감독자 Kubernetes 버전 업그레이드를 시작할 때 감독자 업그레이드 사전 검사를 시작할 수 있습니다. 모든 사전 검사가 성공하는 경우에만 실제 업데이트가 수행됩니다. 이 릴리스에서는 이전에 실패했던 지점부터 구성 요소 업그레이드 프로세스를 재개할 수 있습니다. 자세한 내용은 감독자 업데이트를 참조하십시오.

  • Kubernetes 1.28에 대한 감독자 지원 - 이 릴리스에서는 Kubernetes 1.28에 대한 지원이 추가되었고 Kubernetes 1.25에 대한 지원이 삭제되었습니다.

감독자에 대해 지원되는 Kubernetes 버전:

이 릴리스에서 지원되는 Kubernetes 버전은 1.28, 1.27 및 1.26입니다. Kubernetes 버전 1.25에서 실행되는 감독자는, 지원되는 Kubernetes 버전에서 모든 감독자가 실행되도록 버전 1.26으로 자동 업그레이드됩니다.

Tanzu Kubernetes Grid Service for vSphere

  • 감독자 서비스로서의 TKG 서비스 – 이 릴리스는 TKG 서비스 구성 요소를 vCenter에서 분리하고 vCenter 및 감독자 릴리스에 대해 독립적으로 업데이트하고 관리할 수 있는 감독자 서비스로 패키징합니다. 여기에서 TKG 서비스의 릴리스 정보를 찾을 수 있습니다.

  • 확장된 vSAN 클러스터에서 TKG 서비스 클러스터 배포 지원 – 이 릴리스는 vSAN 확장된 클러스터 토폴로지에서 TKG 서비스 클러스터 배포를 지원합니다. vSAN 확장된 클러스터에서 TKG 서비스 클러스터의 HA를 구성하는 방법에 대한 자세한 내용은 설명서를 참조하십시오.

  • TKG 서비스 클러스터 자동 조정 – 이 릴리스는 TKG 서비스 클러스터에 클러스터 Autoscaler 패키지를 설치하여 작업자 노드의 자동화된 확장 및 축소를 사용하도록 지원합니다. 

  • TKG 클러스터 백업 및 복원 – 이 릴리스는 vSphere 네임스페이스 개체 및 TKG 클러스터 VM을 포함하는 감독자 데이터베이스의 백업 및 복원을 지원합니다. TKG 클러스터 워크로드는 별도로 백업 및 복원해야 합니다.

  • Antrea-NSX 통합 및 NSX 관리 프록시 서비스 지원 – 이 릴리스는 클러스터 네트워킹의 관찰 가능성 및 제어를 위해 Antrea CNI를 사용하는 TKG 클러스터를 NSX Manager와 통합할 수 있도록 지원합니다.

  • 구성 가능한 MachineHealthCheck – 이 릴리스는 v1beta1 클러스터에 대한 MachineHealthCheck 구성을 지원합니다.

  • 클러스터 전체 PSA 구성 – 이 릴리스는 클러스터 생성 또는 업데이트 동안 클러스터 전체에 대한 PSA 구성을 지원합니다.

  • 표준 패키지 설치 업데이트 – 이 릴리스에는 TKG 서비스 클러스터에 표준 패키지를 설치하기 위한 설명서 업데이트가 포함되어 있습니다. 

  • TKG 클러스터 프로비저닝을 위한 v1beta1 API 업데이트 – 이 릴리스에는 다음과 같은 v1beta1 API 변경 사항이 포함되어 있습니다.

    • podSecurityStandard가 클러스터 전체 PSA 구현을 위해 추가됨

    • controlPlaneCertificateRotation이 업데이트됨 

  • TKG 클러스터에 대한 제어부 노드 볼륨 크기 조정 지원.

국제화 업데이트

다음 주요 릴리스부터 지원되는 현지화 언어 수를 줄이려고 합니다. 지원되는 세 가지 언어는 다음과 같습니다.

  • 일본어

  • 스페인어

  • 프랑스어

다음 언어는 더 이상 지원되지 않습니다.

  • 이탈리아어, 독일어, 포르투갈어(브라질), 중국어 번체, 한국어, 중국어 간체

영향:

  • 지원 중단이 예정된 언어를 사용하는 사용자는 더 이상 해당 언어로 된 업데이트나 지원을 받을 수 없습니다.

  • 모든 사용자 인터페이스, 도움말 설명서 및 고객 지원은 영어 또는 위에 언급된 지원되는 3개 언어로만 사용할 수 있습니다.

새로운 기능, 2024년 3월 26일

VMware vSphere 8.0 업데이트 2c | 2024년 3월 26일 

ESXi 8.0 업데이트 2b | 2024년 2월 29일 | ISO 빌드 23305546

vCenter Server 8.0 업데이트 2c | 2024년 3월 26일 | ISO 빌드 23504390

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023년 10월 11일

HAProxy 2.2.2 Community Edition, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023년 5월 18일

vSphere IaaS 제어부 8.0 업데이트 2c에는 다음과 같은 새로운 기능과 향상된 기능이 추가되었습니다.

새로운 기능

  • TKr 1.27 지원 - 이 릴리스에는 향후 릴리스될 때 vSphere 8.x에서 TKr 1.27을 지원하는 데 필요한 변경 사항이 추가되어 있습니다. 자세한 내용은 VMware Tanzu Kubernetes 릴리스 정보를 참조하십시오.

  • vCenter 7.x에서 vCenter 8.x로의 업그레이드 지원 - vSphere 7.x에서 TKr 1.27.6을 실행하는 사용자를 위해 이 릴리스에서는 vCenter 8.x로 업그레이드할 수 있는 경로를 제공합니다. 이전에 vSphere 7.x용으로 출시된 TKr 1.27.6은 vCenter 8.x와 호환되지 않았습니다. KB 문서 96501을 참조하십시오.

해결된 문제

  • vCenter 8.0 업데이트 2b로 업그레이드한 후 vmon 관리 서비스 wcp가 STOPPED 상태가 되고 vCenter 패치 적용이 실패할 수 있습니다.

  • 라이브러리 연결을 해제하거나 공유 라이브러리가 있는 네임스페이스를 삭제하면 컨텐츠 라이브러리에서 연결된 항목이 삭제됩니다.

새로운 기능, 2024년 2월 29일

VMware vSphere 8.0 업데이트 2b | 2024년 2월 29일 

ESXi 8.0 업데이트 2b | 2024년 2월 29일 | ISO 빌드 23305546

vCenter Server 8.0 업데이트 2b | 2024년 2월 29일 | ISO 빌드 23319993

VMware NSX Advanced Load Balancer avi-22.1.5 | 2023년 10월 11일

HAProxy 2.2.2 Community Edition, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023년 5월 18일

vSphere IaaS 제어부 8.0 업데이트 2b에는 다음과 같은 새로운 기능과 향상된 기능이 추가되었습니다.

새로운 기능

  • vSphere Client를 통한 VM 서비스 VM 클래스 구성 지원 - 감독자의 VM 서비스는 현재 vSphere VM에서 지원되는 모든 구성으로 VM을 배포할 수 있도록 지원합니다. 이제 vSphere Client에서 VM 클래스에 대한 CPU, 메모리, 하드웨어, 보안 디바이스 및 패스스루 디바이스를 구성하려는 경우 VM 클래스 마법사를 사용할 수 있습니다. vSphere Client를 사용하면 AI/ML 워크로드를 실행하는 데 사용되는 VM 서비스 VM을 정의하고 관리하는 프로세스를 간소화할 수 있습니다.

  • 감독자의 Avi 클라우드 설정 지원 - AVI Load Balancer라고도 하는 NSX Advanced Load Balancer를 사용하는 경우 이제 각 슈퍼바이저에 대해 Avi 클라우드를 구성할 수 있습니다. 이렇게 하면 여러 vCenter Server 인스턴스 및 데이터 센터에서 단일 Avi 인스턴스를 사용할 수 있으므로 감독자를 배포하는 각 vCenter Server 또는 데이터 센터에 대해 Avi 인스턴스를 설정할 필요가 없습니다.

  • FQDN 로그인 지원 - 감독자 및 TKG 클러스터의 경우 이제 생성된 kubeconfigs의 IP를 유효한 FQDN으로 바꿀 수 있습니다. 적절한 호스트 이름 확인이 가능하도록 FQDN 및 IP 주소를 DNS에 추가해야 합니다.

  • 감독자의 Kubernetes 1.27 지원 - 감독자는 이제 Kubernetes 1.27을 지원하고 Kubernetes 1.24에 대한 지원을 중단합니다.

지원되는 Kubernetes 버전

  • 이 릴리스에서 지원되는 Kubernetes 버전은 1.27, 1.26 및 1.25입니다. Kubernetes 1.24에서 실행되는 감독자는 호환성을 보장하기 위해 버전 1.25로 자동 업그레이드합니다.

8.0 업데이트 2b로 업그레이드

8.0 업데이트 2 미만의 vSphere 8.x 버전에서 8.0 업데이트 2b 릴리스로 업그레이드하면 프로비저닝된 모든 TKGS 클러스터의 롤링 업데이트가 시작되어 다음 변경 사항이 전파됩니다.

  • 8.0 업데이트 2에는 ClusterClass의 일부로 TKGS 컨트롤러의 vSphere 7 및 vSphere 8 TKR 모두에 대한 변경 사항이 포함되어 있습니다.

  • 1.23 이상의 TKGS 클러스터는 8.0 업데이트 2b와 호환되기 때문에 모든 TKGS 클러스터는 롤링 업그레이드를 진행합니다.

해결된 문제

  • 감독자 업그레이드 프로세스가 20%에서 중단되었습니다.

새로운 기능, 2023년 9월 21일

VMware vSphere 8.0.2 | 2023년 9월 21일

ESXi 8.0.2 | 2023년 9월 21일 | 빌드 22380479

vCenter Server 8.0.2 | 2023년 9월 21일 | 빌드 22385739

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023년 1월 31일

HAProxy Community Edition 2.2.2, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023년 5월 18일

vSphere IaaS 제어부 8.0 업데이트 2에는 다음과 같은 새로운 기능과 향상된 기능이 추가되었습니다.

감독자

  • VM 서비스가 이제 Windows OS, GPU 및 기존 vSphere VM에 사용할 수 있는 기타 모든 옵션이 포함된 VM을 지원함 - 이제 VM 서비스는 현재 vSphere VM에서 지원되는 모든 구성으로 VM을 배포하여 vSphere의 기존 VM과 완전한 동등성을 달성합니다. 단 감독자에서 Infrastructure as a Service의 일부로 배포된 VM에만 해당합니다. 여기에는 Linux VM과 함께 Windows VM을 프로비저닝하기 위한 지원을 비롯하여 모든 하드웨어, 보안, 디바이스, 사용자 지정 또는 다중 NIC 지원 및 vSphere에서 지원되는 패스스루 디바이스에 대한 지원이 포함됩니다. 이제 AI/ML 워크로드를 지원하기 위해 GPU를 사용하여 워크로드 VM을 프로비저닝할 수 있습니다.

  • VM 이미지 서비스 - DevOps 팀, 개발자 및 기타 VM 소비자가 VM 이미지 서비스를 사용하여 셀프 서비스 방식으로 VM 이미지를 게시하고 관리할 수 있습니다. 이 서비스를 통해 소비자는 감독자 네임스페이스 범위 이미지 레지스트리 내에서 K8s API를 사용하여 이미지를 게시, 수정 및 삭제할 수 있습니다. VM 이미지 서비스는 각 CCS 지역 및 CCS 프로젝트에서 자동으로 생성되며 이미지 레지스트리에 이미지 채우기는 글로벌 또는 프로젝트 수준에서 개인 설정 및 소비 수준에 따라 범위가 지정됩니다. VM 서비스를 통해 VM을 배포하는 데 이미지를 사용할 수 있습니다.

    이 기능에는 VM 이미지 이름에 대한 새 형식이 도입되었습니다. 이름 변경으로 인한 잠재적 문제를 해결하는 방법에 대한 자세한 내용은 vSphere 8.0 U2의 VM 이미지 이름 형식 변경 사항을 참조하십시오.

  • 감독자 구성 가져오기 및 내보내기 - 이전 버전에서 감독자 활성화는 구성을 저장할 수 있는 기능 없이 수동으로 수행되는 단계별 프로세스였습니다. 현재 릴리스에서는 이제 사람이 읽을 수 있는 형식으로 또는 소스 제어 시스템 내에서 피어와 감독자 구성을 내보내서 공유하고, 구성을 새 감독자로 가져오고, 여러 감독자 간에 표준 구성을 복제할 수 있습니다. 감독자 구성을 내보내고 가져오는 방법에 대한 자세한 내용은 설명서에서 확인하십시오.

  • 조각화를 줄여 GPU 활용률 향상 - 워크로드 배치는 이제 GPU를 인식하며 DRS에서는 동일한 호스트에 유사한 프로파일 요구 사항을 가진 워크로드를 배치하려고 시도합니다. 이렇게 하면 리소스 활용률을 개선할 수 있고 이를 통해 더 적은 GPU 하드웨어 리소스로도 원하는 성능 수준을 달성할 수 있으므로 비용이 절감됩니다.

  • 감독자가 Kubernetes 1.26 지원 - 이 릴리스에서는 Kubernetes 1.26에 대한 지원이 추가되었고 Kubernetes 1.23 대한 지원이 삭제되었습니다. 이 릴리스에서 지원되는 Kubernetes 버전은 1.26, 1.25 및 1.24입니다. Kubernetes 버전 1.23에서 실행되는 감독자는, 지원되는 Kubernetes 버전에서 모든 감독자가 실행되도록 버전 1.24로 자동 업그레이드됩니다.

  • NSX 네트워킹으로 구성된 감독자에 대한 NSX Advanced Load Balancer 지원 - L4 로드 밸런싱은 물론 NSX 네트워킹을 사용하는 감독자 및 Tanzu Kubernetes Grid 클러스터의 제어부 노드에 대한 로드 밸런싱을 위해 NSX Advanced Load Balancer(Avi Networks)를 사용하여 감독자를 사용하도록 설정할 수 있습니다. NSX를 사용하여 NSX Advanced Load Balancer를 구성하는 방법에 대한 지침은 설명서 페이지를 확인하십시오.

  • 메트릭 및 이벤트 스트리밍에 대한 Telegraf 지원 -이제 Kubernetes API를 통해 Telegraf를 구성하여 내장형 Telegraf 버전과 호환되는 모든 메트릭 서비스에 감독자 메트릭을 푸시할 수 있습니다. Telegraf 구성은 설명서를 참조하십시오.

감독자의 Tanzu Kubernetes Grid

  • vSphere 8.0에서 TKR에 대한 STIG 규정 준수 - vSphere U2에서 1.23.x 이상의 모든 Tanzu Kubernetes Grid 클러스터는 STIG(Security Technical Implementation Guide)를 준수하며 여기에서 찾을 수 있는 예외에 대한 설명서가 포함되어 있습니다. 이러한 개선 사항은 규정 준수 프로세스 간소화를 위한 중요 단계로, 규정 준수 요구 사항을 훨씬 쉽게 충족할 수 있게 해주므로 미국 연방 시장 및 기타 규제 산업에서 Tanzu Kubernetes Grid를 신속하고 안전하게 사용할 수 있습니다.

  • 만료되는 인증서에 대한 제어부 롤아웃 켜기 – ClusterClass를 기반으로 TKG 클러스터를 프로비저닝하기 위한 v1beta1 API가 업데이트되어 클러스터의 제어부 노드 VM 인증서가 만료되기 전에 클러스터가 자동으로 갱신하도록 설정할 수 있습니다. 이 구성은 클러스터 규격에 변수로 추가할 수 있습니다. 자세한 내용은

    Cluster v1beta1 API 설명서를 참조하십시오.

  • TKR에 대한 CSI 스냅샷 지원 - Tanzu Kubernetes 릴리스 1.26.5 이상으로 프로비저닝된 TKG 클러스터는 CSI 볼륨 스냅샷을 지원하므로 데이터 보호 요구 사항을 달성할 수 있습니다. 볼륨 스냅샷은 완전히 새로운 볼륨을 생성하지 않고도 특정 시점에 볼륨의 컨텐츠를 복사하는 표준화된 방법을 제공합니다. 

  • Tanzu 패키지 설치 및 관리 – TKG 클러스터에 Tanzu 패키지를 설치하고 관리하기 위한 새로운 통합 저장소 및 자료입니다. 모든 패키지 요구 사항에 대해서는 "VMware Tanzu 패키지 설치 및 사용" 자료를 참조하십시오.

  • 사용자 지정 ClusterClass 개선 사항 – 사용자 지정 ClusterClass 클러스터를 구현하기 위한 워크플로가 vSphere 8 U2에서 간소화되었습니다.

  • TKG 클러스터에 대한 롤링 업데이트 – vSphere 8 U2로 업그레이드하는 경우 다음과 같은 시나리오에서 프로비저닝된 TKG 클러스터에 대한 롤링 업데이트를 기대할 수 있습니다.

    • 이전에 릴리스된 vSphere 8 버전에서 vSphere 8 U2로 업그레이드하는 경우 다음과 같은 이유가 있습니다.

      • vSphere 8 U2에는 TKR에 대한 Kubernetes 수준 STIG 변경 내용이 clusterclass의 일부로 포함되어 있음

      • 1.23 이상의 TKG 클러스터는 v8.0 U2와 호환되도록 롤링 업데이트가 진행됨

    • vSphere 7 버전에서 vSphere 8 U2로 업그레이드하는 경우 다음과 같은 이유가 있습니다.

      • 기본 CAPI 제공자를 CAPW에서 CAPV로 이동해야 함

      • 기존 클러스터를 클래스 없는 CAPI 클러스터에서 클래스 기반 CAPI 클러스터로 마이그레이션해야 함

해결된 문제

  • 감독자 제어부 VM의 /var/log/audit/ 아래의 감사 로그 파일이 매우 큰 크기로 증가하여 루트 디스크를 가득 채울 수 있습니다. 이 상태를 반영하는 저널링된 로그에 "디바이스에 남아 있는 공간이 없습니다." 오류가 표시되어야 합니다. 이로 인해 다양한 측면의 감독자 제어부 기능(예: Kubernetes API)이 실패할 수 있습니다.

새로운 기능, 2023년 7월 27일

VMware vSphere 8.0.1c | 2023년 7월 27일

ESXi 8.0.1c | 2023년 7월 27일 | 빌드 22088125

vCenter Server 8.0.1c | 2023년 7월 27일 | 빌드 22088981

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023년 1월 31일

HAProxy Community Edition 2.2.2, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.2.0 | 2023년 5월 18일

새로운 기능

  • Kubernetes 1.25에 대한 감독자 지원 - 이 릴리스에서는 Kubernetes 1.25에 대한 지원이 추가되었고 Kubernetes 1.22에 대한 지원이 삭제되었습니다.

  • 감독자의 Tanzu Kubernetes Grid 2.2.0 - 감독자의 Tanzu Kubernetes Grid 2.2.0 클러스터를 관리합니다.

지원되는 Kubernetes 버전

  • 이 릴리스에서 지원되는 Kubernetes 버전은 1.25, 1.24 및 1.23입니다. Kubernetes 버전 1.22에서 실행되는 감독자는, 지원되는 Kubernetes 버전에서 모든 감독자가 실행되도록 버전 1.23으로 자동 업그레이드됩니다.

지원

  • vRegistry 생성 지원 중단 - 내장된 Harbor 인스턴스인 vRegistry의 생성은 더 이상 지원되지 않습니다. 기존 vRegistry 인스턴스는 계속 작동하지만 새 vRegistry 인스턴스 생성은 더 이상 지원되지 않습니다. vRegistry 생성 API는 더 이상 사용되지 않는 것으로 표시되었으며 새 vRegistry 인스턴스를 배포하는 기능은 향후 릴리스에서 제거될 예정입니다. 대신 Harbor를 감독자 서비스로 사용하여 향상된 성능 및 기능을 위해 컨테이너 이미지 및 저장소를 관리하는 것이 좋습니다. 기존 vRegistry를 Harbor로 마이그레이션하여 감독자 서비스로 사용하려면 내장된 레지스트리에서 Harbor로 이미지 마이그레이션에서 마이그레이션 세부 정보를 참조하십시오.

해결된 문제

  • 감독자 또는 TKG 클러스터에서 인증서 만료에 대해 경고하는 새 경고 메시지가 vSphere Client에 표시됨. 경고는 감독자의 이름, 인증서 만료 날짜를 비롯한 세부 정보를 제공합니다. 또한 영향을 받는 인증서의 교체 방법을 단계별로 설명하는 KB 90627에 대한 링크가 포함됩니다.

  • kubectl get clustervirtualmachineimages 명령이 오류를 반환하거나 No resources found 메시지를 반환함. 이전 버전에서는 kubectl get clustervirtualmachineimages 명령을 사용하면 오류가 발생했습니다. 하지만 8.0 업데이트 1c로 업그레이드하면 명령이 No resources found. 가상 시스템 이미지에 대한 정보를 검색하려면 다음 명령을 대신 사용합니다. kubectl get virtualmachineimages

  • antrea-nsx-routed CNI가 vSphere IaaS 제어부 8.x 릴리스의 v1alpha3 Tanzu Kubernetes 클러스터에서 작동하지 않음

  • v1beta1 클러스터에 대해 노드 드레이닝 시간 초과가 올바르게 전파되지 않음

새로운 기능, 2023년 4월 18일

VMware vSphere 8.0.1 | 2023년 4월 18일

ESXi 8.0.1 | 2023년 4월 18일 | 빌드 21495797

vCenter Server 8.0.1 | 2023년 4월 18일 | 빌드 21560480

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023년 1월 31일

HAProxy Community Edition 2.2.2, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022년 10월 11일

새로운 기능

감독자

  • 감독자 서비스를 이제 VDS 기반 감독자에서 사용할 수 있음 - 이전에는 감독자 서비스의 가용성이 NSX 기반 감독자로만 제한되었습니다. 현재 릴리스에서는 VDS 기반 감독자에서 Harbor, Contour, S3 객체 스토리지 및 Velero 감독자 서비스를 배포할 수 있습니다. 참고: VDS 기반 감독자의 감독자 서비스 기능을 사용하려면 ESXi를 8.0 U1로 업데이트해야 합니다.

  • 모든 Linux 이미지에 대한 VM 서비스 지원 - 이제 CloudInit을 사용하여 VM 서비스 이미지 규격을 준수하는 OVF 형식의 모든 Linux 이미지를 사용자 지정할 수 있으며 vAppConfig를 통해 OVF 템플릿을 활용하여 레거시 Linux 이미지 배포가 가능하도록 설정할 수 있습니다.

  • VM 서비스 VM에 대한 웹 콘솔 지원 - VM 서비스 VM을 배포하면 DevOps 엔지니어가 kubectl CLI를 사용하여 해당 VM에 대한 웹 콘솔 세션을 시작할 수 있으므로 게스트 VM에 대한 액세스 권한을 얻기 위해 vSphere 관리자를 개입시키지 않고도 게스트 운영 체제 내에서 문제 해결 및 디버깅이 가능합니다.

  • 감독자 규정 준수 - vSphere IaaS 제어부 8 감독자 릴리스에 대한 STIG(Security Technical Implementation Guide) 자세한 내용은 Tanzu STIG 강화를 참조하십시오.

감독자의 Tanzu Kubernetes Grid 2.0

  • 사용자 지정 클러스터 클래스 - 감독자의 TKG 클러스터에 대한 자체 클러스터 클래스를 가져옵니다. 자세한 내용은 https://kb.vmware.com/s/article/91826을 참조하십시오.

  • TKG 노드에 대한 사용자 지정 이미지 - vSphere TKG Image Builder(Ubuntu 및 Photon)를 사용하여 고유한 사용자 지정 노드 이미지를 구축합니다.

    참고: v1alpha1 API에서 특정 TKR을 사용하려면 fullVersion을 사용합니다.

  • 새 TKR 이미지: 자세한 내용은 Tanzu Kubernetes 릴리스 릴리스 정보를 참조하십시오.

vSpere IaaS 제어부 8.0.0 GA 고객을 위한 중요 요구 사항

참고: 이 요구 사항은 VM 서비스를 통해 프로비저닝된 VM에 사용하는 컨텐츠 라이브러리에는 적용되지 않습니다. TKR 컨텐츠 라이브러리에만 적용됩니다.

vSphere IaaS 제어부 8.0.0 GA를 배포한 경우 vSphere IaaS 제어부 8 U1로 업그레이드하기 전에 TKG 2.0 TKR이 기존 컨텐츠 라이브러리로 푸시될 때 TKG 컨트롤러 포드가 CrashLoopBackoff 상태로 전환되는 알려진 문제를 방지하기 위해 임시 TKR 컨텐츠 라이브러리를 생성해야 합니다. 이 문제를 방지하려면 다음 단계를 완료합니다.

  1. 임시 구독 URL이 https://wp-content.vmware.com/v2/8.0.0/lib.json을 가리키는 새 구독 컨텐츠 라이브러리를 생성합니다.

  2. 임시 컨텐츠 라이브러리의 모든 항목을 동기화합니다.

  3. 임시 컨텐츠 라이브러리를 TKG 2 클러스터를 배포한 각 vSphere 네임스페이스와 연결합니다.

  4. kubectl get tkr 명령을 실행하고 모든 TKR이 생성되었는지 확인합니다.

  5. 이때 TKG 컨트롤러는 실행 중 상태여야 합니다. 이는 감독자 네임스페이스의 포드를 나열하여 확인할 수 있습니다.

  6. TKG 컨트롤러가 CLBO(CrashLoopBackOff) 상태인 경우 다음 명령을 사용하여 TKG 컨트롤러 배포를 다시 시작합니다.

    kubectl rollout restart deployment -n vmware-system-tkg vmware-system-tkg-controller-manager

  7. vSphere IaaS 제어부 8 업데이트 1로 업그레이드합니다.

  8. https://wp-content.vmware.com/v2/latest/lib.json에서 원래 구독 컨텐츠 라이브러리를 사용하도록 각 vSphere 네임스페이스를 업데이트합니다.

해결된 문제

  • v1beta1 API로 프로비저닝된 Tanzu Kubernetes Grid 2.0 클러스터는 기본 ClusterClass를 기반으로 해야 함

    v1beta1 API를 사용하여 감독자에서 Tanzu Kubernetes Grid 2.0 클러스터를 생성하는 경우 클러스터는 기본 tanzukubernetescluster ClusterClass를 기반으로 해야 합니다. 다른 ClusterClass에 기반한 클러스터는 시스템에서 조정되지 않습니다.

새로운 기능, 2023년 3월 30일

ESXi 8.0.0c | 2023년 3월 30일 | 빌드 21493926

vCenter Server 8.0.0c | 2023년 3월 30일 | 빌드 21457384

VMware NSX Advanced Load Balancer avi-22.1.3 | 2023년 1월 31일

HAProxy 2.2.2 Community Edition, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022년 10월 11일

해결된 문제

  • Harbor 비보안 기본 구성 문제

    이 릴리스에서는 감독자 7.0 또는 8.0에서 내장된 Harbor 레지스트리를 사용하도록 설정한 경우 존재하는 Harbor 비보안 기본 구성 문제를 해결합니다.

    이 vCenter 버전 8.0.0c에서 해결되었습니다. VMware 기술 자료 문서 91452에서 이 문제에 대한 세부 정보와 이 릴리스를 설치하거나 임시 해결 방법을 적용하여 문제를 해결하는 방법을 참조하십시오.

  • vCenter Server 8.0b로 업그레이드한 후 감독자 및 TKG 클러스터에 대한 로그인 시도가 실패함

    vCenter Server 8.0b에서 실행되는 구성 요소는 이전 릴리스의 vCenter Server를 사용하여 배포된 이전 버전 감독자와 호환되지 않습니다.

    해결 방법: vCenter Server를 최신 버전으로 업그레이드하거나 배포된 모든 감독자를 업그레이드합니다.

새로운 기능, 2023년 2월 14일

ESXi 8.0.0b | 2023년 2월 14일 | 빌드 21203435

vCenter Server 8.0.0b | 2023년 2월 14일 | 빌드 21216066

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 2022년 7월 15일

HAProxy 2.2.2 Community Edition, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022년 10월 11일

새로운 기능:

  • Cert-Manager CA 클러스터 발급자 지원 추가 - 관리자가 감독자에서 클러스터 범위의 CA 발급자를 감독자 서비스로 정의하고 배포할 수 있는 기능을 제공합니다. 클러스터 범위의 CA 발급자를 배포하면 감독자 네임스페이스의 소비자가 CA 발급자가 서명한 인증서를 요청하고 관리할 수 있습니다. 

이 릴리스는 이 새로운 기능 외에도 버그 수정을 제공합니다.

해결된 문제

  • 감독자 제어부 VM 루트 디스크가 가득 참

    감독자 제어부 VM의 /var/log/audit/ 아래의 감사 로그 파일이 매우 큰 크기로 증가하여 루트 디스크를 가득 채울 수 있습니다. 이 상태를 반영하는 저널링된 로그에 "디바이스에 남아 있는 공간이 없습니다." 오류가 표시되어야 합니다. 이로 인해 다양한 측면의 감독자 제어부 기능(예: Kubernetes API)이 실패할 수 있습니다.

    이 버전, vSphere 8.0.0b에서 해결되었습니다.

새로운 기능, 2022년 12월 15일

ESXi 8.0 | 2022년 10월 11일 | 빌드 20513097

vCenter Server 8.0.0a | 2022년 12월 15일 | 빌드 20920323

VMware NSX Advanced Load Balancer avi-22.1.1-9052 | 2022년 7월 15일

HAProxy 2.2.2 Community Edition, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022년 10월 11일

새로운 기능

  • 감독자 서비스로 Harbor 추가 - 감독자에서 실행되는 전체 기능 Harbor(OCI 이미지 레지스트리) 인스턴스를 제공합니다. Harbor 인스턴스는 Harbor 관리자에게 프로젝트와 사용자를 생성 및 관리하고 이미지 검색을 설정할 수 있는 기능을 제공합니다.

  • vRegistry 사용 중단 – vRegistry라고 하는 내장된 Harbor 인스턴스가 향후 릴리스에서 제거될 예정입니다. 대신 Harbor를 감독자 서비스로 사용할 수 있습니다. 마이그레이션 세부 정보는 "내장된 레지스트리에서 Harbor로 이미지 마이그레이션"을 참조하십시오.

  • 감독자에서 Kubernetes 1.24 지원 – 이 릴리스는 Kubernetes 1.24 지원을 추가하고 Kubernetes 1.21 지원을 삭제합니다. 이 릴리스에서 지원되는 Kubernetes 버전은 1.24, 1.23 및 1.22입니다. Kubernetes 버전 1.21에서 실행되는 감독자 클러스터는, 모든 감독자 클러스터가 지원되는 버전에서 실행되도록 버전 1.22로 자동 업그레이드됩니다.

  • vSphere 영역 API - vSphere 영역은 가용성 영역을 vSphere 클러스터에 할당하여 고가용성 감독자 및 Tanzu Kubernetes 클러스터를 만들 수 있는 구성체입니다. vSphere 8.0에서는 vSphere Client에서 vSphere 영역을 생성 및 관리할 수 있었습니다. vSphere 8.0.0a 릴리스에서 사용자는 DCLI 또는 vSphere Client API 탐색기를 사용하여 vSphere 영역을 생성하고 관리할 수 있습니다. 전체 SDK 바인딩 지원(예: Java, Python 등)은 향후 릴리스에서 제공될 예정입니다.

업그레이드 고려 사항:

  • Tanzu Kubernetes 클러스터의 롤링 업데이트가 다음 감독자 업그레이드 시나리오에서 발생합니다.

    • 8.0에서 8.0.0a로 업그레이드한 후 임의 Kubernetes 릴리스의 감독자를 감독자 Kubernetes 1.24로 업그레이드하고 다음 조건 중 하나가 충족되는 경우.

      • Tanzu Kubernetes 클러스터에서 비어 있지 않은 noProxy 목록이 있는 프록시 설정을 사용하는 경우.

      • vRegistry가 감독자에서 사용하도록 설정된 경우. 이 설정은 NSX 기반 감독자에서만 사용할 수 있습니다.

    • 임의 vSphere 7.0 릴리스에서 vSphere 8.0.0a로 업그레이드하는 경우.

해결된 문제

  • vSphere 8에서 Tanzu 8 라이센스 키가 아닌 Tanzu 7 라이센스 키가 지원됨

    vCenter 8.0은 Tanzu 8 라이센스 키 대신 Tanzu 7 라이센스 키를 지원합니다. 이 문제는 vCenter 8.0에서 Tanzu 기능을 완전히 사용하는 기능에는 영향을 주지 않습니다. vCenter 8.0 배포에서 Tanzu 라이센스를 수정하기 전에 VMware 기술 자료 문서 89839에서 자세한 내용을 참조하십시오.

  • NSX-ALB에 2개의 SE 그룹이 있는 경우 LoadBalancer 및 게스트 클러스터가 생성되지 않음

    SE 또는 할당된 가상 서비스가 있거나 없는 NSX-ALB에 두 번째 SE 그룹을 추가하면 새 감독자 또는 게스트 클러스터 생성이 실패하고 기존 감독자 클러스터를 업그레이드할 수 없습니다. NSX-ALB 컨트롤러에서 가상 서비스 생성이 실패하고 다음 오류가 발생합니다.

    get() returned more than one ServiceEngineGroup – it returned 2

    그 결과 새 로드 밸런서를 사용할 수 없으며 새 워크로드 클러스터를 성공적으로 생성할 수 없습니다. 자세한 내용은 VMware 기술 자료 문서 90386을 참조하십시오.

2022년 10월 11일 새로운 기능

VMware vSphere 8.0 | 2022년 10월 11일

ESXi 8.0 | 2022년 10월 11일 | 빌드 20513097

vCenter 8.0 | 2022년 10월 11일 | 빌드 20519528

VMware NSX Advanced Load Balancer 21.1.4 | 2022년 4월 7일

HAProxy 2.2.2 Community Edition, 데이터부 API 2.1.0

Tanzu Kubernetes Grid 2.0 | 2022년 10월 11일

vSphere IaaS 제어부 8.0에는 다음과 같은 새로운 기능과 향상된 기능이 추가되었습니다.

  • 워크로드 관리 구성 모니터링 - 이제 감독자의 활성화, 비활성화 및 업그레이드 상태를 보다 자세히 추적할 수 있습니다. 감독자 활성화, 비활성화 또는 업그레이드를 시작하면 감독자는 감독자의 다양한 구성 요소(예: 제어부 VM)와 연결된 다양한 조건에 도달하여 원하는 상태에 도달하려고 시도합니다. 각 조건의 상태를 추적하고, 연결된 주의를 보고, 상태를 다시 시도하고, 도달한 조건과 해당 타임 스탬프를 볼 수 있습니다.

  • vSphere 영역 - vSphere 영역은 vSphere 클러스터에 가용성 영역을 할당할 수 있는 새로운 구성체입니다. vSphere 영역에 감독자를 배포하면 특정 가용성 영역 및 장애 도메인에서 Tanzu Kubernetes Grid 클러스터를 프로비저닝할 수 있습니다. 그러면 워크로드가 여러 클러스터에 걸쳐 있을 수 있기 때문에 하드웨어 및 소프트웨어 장애에 대한 복원력이 향상됩니다.

  • 다중 클러스터 감독자 - vSphere 영역을 사용하면 여러 vSphere 클러스터에 감독자를 배포하여 Tanzu Kubernetes Grid 클러스터에 고가용성 및 장애 도메인을 제공할 수 있습니다. vSphere 클러스터를 별도의 vSphere 영역에 추가하고 여러 vSphere 영역에 걸쳐 있는 감독자를 활성화할 수 있습니다. 이렇게 하면 지역화된 하드웨어 및 소프트웨어 장애에 대한 페일오버 및 복원력이 제공됩니다. 영역 또는 vSphere 클러스터가 오프라인 상태가 되면 감독자가 장애를 감지하고 다른 vSphere 영역에서 워크로드를 다시 시작합니다. 지연 시간 최대값을 초과하지 않는 한 먼 거리에 걸쳐 있는 환경에서 vSphere 영역을 사용할 수 있습니다. 지연 시간 요구 사항에 대한 자세한 내용은 영역 감독자 배포 요구 사항을 참조하십시오.

  • 감독자가 Kubernetes 1.23 지원 - 이 릴리스는 Kubernetes 1.23에 대한 지원을 추가하고 Kubernetes 1.20에 대한 지원을 삭제합니다. 이 릴리스에서 지원되는 Kubernetes 버전은 1.23, 1.22 및 1.21입니다. Kubernetes 버전 1.20에서 실행되는 감독자는, 지원되는 Kubernetes 버전에서 모든 감독자가 실행되도록 버전 1.21로 자동 업그레이드됩니다.

  • SecurityPolicy CRD를 사용하여 일관된 네트워크 정책 제공 - SecurityPolicy 사용자 지정 리소스 정의는 감독자 네임스페이스에서 VM 및 vSphere Pod에 대한 네트워크 보안 제어를 구성하는 기능을 제공합니다.

  • 감독자의 Tanzu Kubernetes Grid 2.0 - 이제 Tanzu Kubernetes Grid가 버전 2.0으로 전환됩니다. Tanzu Kubernetes Grid 2.0은 Tanzu 및 Kubernetes 커뮤니티의 엄청난 혁신의 정점이며 Tanzu Kubernetes Grid를 통해 사설 및 공용 클라우드 전반에서 공통된 인터페이스 집합의 기초를 제공합니다. 이 릴리스의 새로운 사항은 다음과 같은 두 가지 주요 기능입니다.

    • ClusterClass - Tanzu Kubernetes Grid 2.0은 이제 ClusterClass를 지원합니다. ClusterClass는 Tanzu Kubernetes Cluster를 대체하는 업스트림 정렬 인터페이스를 제공하여 Tanzu Kubernetes Grid 플랫폼에 사용자 지정 기능을 제공합니다. ClusterClass를 사용하면 관리자가 엔터프라이즈 환경 요구 사항에 맞는 템플릿을 정의할 수 있으며 상용구를 줄이고 위임된 사용자 지정이 가능합니다.

    • Carvel - Carvel은 애플리케이션을 구축하고 구성하고 Kubernetes에 배포하는 데 도움이 되는 신뢰할 수 있는 단일 용도의 구성 가능한 도구 집합을 제공합니다. 특히 kapp 및 kapp-controller는 일련의 선언적 업스트림 정렬 도구를 통해 패키지 관리, 호환성 및 수명 주기를 제공합니다. 템플릿화를 위한 ytt와 결합하면 유연하지만 관리하기 쉬운 패키지 관리 기능이 구현됩니다.

  • vSphere 8의 새로운 설명서 구조 및 랜딩 페이지 - 이제 vSphere IaaS 제어부 설명서가 제품의 워크플로를 더 잘 반영하도록 구조가 개선되어 컨텐츠에 더욱 집중할 수 있습니다. 또한, vSphere IaaS 제어부에 사용할 수 있는 모든 기술 설명서를 새로운 설명서 랜딩 페이지에서 액세스할 수 있습니다.


이 릴리스의 설치 및 업그레이드

vSphere IaaS 제어부 설치 및 구성에 대한 지침은 vSphere IaaS 제어부 설치 및 구성 설명서를 참조하십시오. vSphere IaaS 제어부 업데이트에 대한 자세한 내용은 vSphere IaaS 제어부 업데이트 설명서를 참조하십시오.

업그레이드를 수행할 때는 다음 사항에 유의하십시오.

  • vCenter Server 8.0으로 업데이트하기 전에 모든 감독자의 Kubernetes 버전이 1.21 이상(가급적이면 지원되는 최신 버전)인지 확인합니다. Tanzu Kubernetes Grid 클러스터의 Tanzu Kubernetes 릴리스 버전은 1.21이어야 하며 가급적이면 지원되는 최신 버전이어야 합니다.

  • vSphere IaaS 제어부 8.0 MP1 릴리스부터는 레거시 TKGS TKr에서 TKG 2 TKr로의 업그레이드를 수행할 수 있습니다. 지원되는 버전 매트릭스는 Tanzu Kubernetes 릴리스의 릴리스 정보를 참조하십시오. 업그레이드 정보는 vSphere IaaS 제어부와 함께 감독자에서 TKG 사용 설명서를 참조하십시오.

알려진 문제

감독자 알려진 문제

  • vSphere 8.0 업데이트 3에서는 네트워크 재정의 옵션이 vSphere 네임스페이스 생성 페이지에 더 이상 존재하지 않음

    8.0 업데이트 3 릴리스 이전에는 vSphere 관리자가 vSphere 네임스페이스 생성 시 사용되는 기본 네트워크 구성 대신 사용자 지정 네트워크 구성을 제공할 수 있었습니다. 8.0 업데이트 3 릴리스에서는 네트워크 구성을 재정의하는 UI 옵션을 사용할 수 없습니다.

    해결 방법: DCLI를 사용하여 사용자 지정 네트워크 구성을 사용하는 vSphere 네임스페이스를 생성할 수 있습니다.

  • 때때로 vds-vsip 모듈을 로드할 수 없어 ESXi 호스트가 감독자 클러스터에 가입하지 못할 수 있음

    ESXi 호스트가 감독자 클러스터에 가입하지 못하면 ESXi 호스트 로그 파일에서 다음 오류를 볼 수 있습니다. /var/run/log/spherelet.log:

    cannot load module vds-vsip: cmd '/bin/vmkload_mod /usr/lib/vmware/vmkmod/vds-vsip' failed with status 1: stderr: '', stdout:'vmkmod: VMKModLoad: VMKernel_LoadKernelModule(vds-vsip): Failure\nCannot load module /usr/lib/vmware/vmkmod/vds-vsip: Failure\n'

    이 문제는 감독자 클러스터 업그레이드, 인증서 업그레이드 또는 spherelet을 다시 시작하는 다른 감독자 구성 변경 중에 발생할 수 있습니다.

    해결 방법: vds-vsip 모듈을 로드할 수 없는 ESXi 호스트를 재부팅합니다.

  • [매우 작음] 제어부 VM을 사용하는 감독자가 있는 vSphere IaaS 제어부 환경을 7.0 업데이트 3o에서 8.0 업데이트 3으로 업그레이드하려고 하면 작업이 실패하고 오류가 발생함

    vCenter 7.0 업데이트 3o에서 8.0 업데이트 3으로 업그레이드한 후 매우 작음 제어부 VM으로 구성된 감독자는 Kubernetes를 v1.26.8에서 v1.27.5로 업그레이드할 수 없습니다.

    다음과 같은 오류가 표시될 수 있습니다. Waiting for deployment \"snapshot-validation-deployment\" rollout to finish: 2 out of 3 new replicas have been updated...'kubectl get pods' in namespaces starting with the name 'vmware-system-' show pods in OutOfCpu state.

    해결 방법: 업그레이드하기 전에 제어부 VM의 크기를 매우 작음에서 작음 이상으로 스케일 업합니다. 감독자의 제어부 크기 변경을 참조하십시오.

  • vCenter와 vSphere IaaS 제어부 환경을 vSphere 8.0 U3으로 업그레이드한 후 감독자가 Kubernetes 버전 1.26을 사용하는 경우 vSphere 포드 생성 시도가 실패함

    환경을 vSphere 8.0 U3으로 업그레이드하고 감독자를 Kubernetes 버전 1.26으로 업그레이드한 경우 시스템이 이미지를 끌어오려고 시도하는 동안 vSphere 포드 생성 작업이 실패합니다. 클러스터에서 정적 네트워크가 사용되도록 설정되어 있는데도 failed to configure device eth0 with dhcp: getDHCPNetConf failed for interface 오류가 표시될 수 있습니다.

    해결 방법: vSphere IaaS 제어부 및 감독자를 Kubernetes 버전 1.27 이상으로 업그레이드합니다.

  • 볼륨 스냅샷 삭제와 PVC 복원 작업을 동시에 시도할 때 내부 종속성으로 인해 작업이 완료되지 않는 경우가 있음

    이 문제는 다음과 같은 상황에서 발생할 수 있습니다. 볼륨 스냅샷에 대한 복원 작업을 시작했는데 복원 작업을 완료하는 데 시간이 오래 걸리거나 다른 내부적 이유로 인해 작업이 재시도됩니다. 그 동안 소스 스냅샷 삭제를 트리거합니다. 그 결과 두 작업이 충돌하고 불완전한 상태로 유지됩니다. 이 스냅샷에 대한 복원 작업이 진행 중이므로 스냅샷 삭제가 계속 실패하고 스냅샷 삭제가 트리거되었기 때문에 복원 작업이 실패하기 시작합니다.

    해결 방법: 이 문제를 해결하려면 복원된 PVC를 삭제하여 복원 작업을 중지하고 스냅샷 삭제를 계속 진행해야 합니다. 이 경우 복원된 PVC 삭제 후 스냅샷이 삭제되므로 스냅샷 데이터가 손실되어 복원할 수 없습니다.

  • VM 서비스 VM이 스토리지 클래스의 volumeBindingMode 매개 변수가 WaitForFirstConsumer로 설정된 PVC를 사용할 수 없음

    VM 서비스 VM에 대해 이 유형의 PVC를 사용하면 예기치 않은 동작과 오류가 발생합니다. 예를 들어 Waiting for first consumer to be created before binding 오류가 발생할 수 있습니다.

    해결 방법: VM 서비스 VM은 스토리지 클래스에서 즉시 volumeBidingMode가 있는 PVC를 지원하지만 WaitForFirstConsumer는 지원하지 않습니다.

  • 새 라이센스 모델이 VMware vSphere IaaS 제어부 환경에서 NCP(NSX Container Plugin)의 동작을 변경함

    8.0 업데이트 3 릴리스에서는 NSX DFW(Distributed Firewall) 라이센스가 별도의 추가 기능 라이센스로 제공됩니다. 이 라이센스가 없으면 VMware vSphere IaaS 제어부 환경의 NCP가 NSX의 DFW 규칙을 조정하여 예측할 수 없는 동작을 유발합니다.

    예를 들어 DFW 라이센스가 없으면 NCP가 NSX Manager에서 규칙을 추가할 수 없기 때문에 VMware vSphere IaaS 제어부에 대해 생성된 새 보안 및 네트워크 정책이 작동하지 않습니다. 또한 새로 생성된 네임스페이스의 포드와 같은 리소스는 다른 네임스페이스에서 연결할 수 있습니다. 반대로 DFW 라이센스를 사용하면 기본적으로 다른 네임스페이스에서 새로 생성된 네임스페이스에 액세스할 수 없습니다.

    해결 방법: NSX DFW(Distributed Firewall) 라이센스는 NSX Manager에서 별도의 추가 기능 라이센스로 제공됩니다. 문제를 방지하려면 NSX Manager에 라이센스를 추가합니다.

  • Velero vSphere Operator는 성공적으로 설치되지만 Velero 인스턴스를 인스턴스화하려고 하면 실패할 수 있음

    Velero vSphere Operator는 제어부 VM에 운영자 포드를 배포하지만 Velero 인스턴스는 vSphere 포드로 배포합니다.

    vCenter를 8.x로 업그레이드하고 감독자가 VDS 네트워킹을 사용하는 경우 배포 문제가 발생할 수 있습니다. 그러나 해당 감독자의 ESXi 호스트는 업그레이드되지 않았으며 8.x 이전의 비동기 버전을 사용하고 있습니다. 이 시나리오에서는 ESXi 호스트가 vSphere 포드를 배포할 수 없습니다. 그 결과 Velero vSphere Operator는 성공적으로 설치되지만 관리자가 이를 사용하려고 하면 Velero 인스턴스에 대한 인스턴스화가 실패합니다.

    해결 방법: Velero 감독자 서비스가 제대로 작동하는지 확인하려면 먼저 ESXi를 버전 8.x로 업그레이드한 다음 vCenter 및 감독자를 동일한 8.x 버전으로 업그레이드해야 합니다.

  • 대규모 환경에서 리소스 부족으로 VM Operator 포드가 충돌함

    예를 들어 VM이 수천 개인 대규모 환경에서 VirtualMachine 리소스 준비에 시간이 오래 걸린다면 메모리 부족으로 인해 VM Operator 포드가 충돌하기 때문일 수 있습니다.

    해결 방법: 해결 방법 및 자세한 내용은 기술 자료 문서 88442를 참조하십시오.

  • vCenter 8.0 업데이트 2b로 업그레이드한 후 vmon 관리 서비스 wcp가 STOPPED 상태가 되고 vCenter 패치 적용이 실패할 수 있음

    이 문제는 vCenter 8.0 업데이트 1 이상을 vCenter 8.0 업데이트 2b로 업그레이드하고 VDS 네트워킹 토폴로지를 사용하면서 Kubernetes 1.24에 있는 감독자가 하나 이상 있는 경우에만 발생합니다.

    해결 방법: 이 문제를 방지하려면 vCenter를 8.0 업데이트 2b로 업그레이드하기 전에 감독자를 Kubernetes 1.25 이상으로 업그레이드합니다. 자세한 내용은 고객 지원에 문의하십시오.

  • 사용자 지정 vCenter 인증서의 크기가 8K보다 큰 경우 감독자 작업이 실패함

    vSphere 8.0 업데이트 2b에서는 vCenter 시스템의 CSR 최대 키 크기가 16384비트에서 8192비트로 감소했습니다. 인증서의 키 크기가 8192비트보다 큰 경우 감독자 작업에서 예기치 않은 동작이 발생할 수 있습니다. 예를 들어 감독자 사용 설정 또는 업그레이드와 같은 작업이 실패할 수 있습니다.

    해결 방법:

    키 크기가 8192비트보다 큰 vCenter 인증서를 재생성합니다.

    1. 키 크기가 8192비트보다 큰 인증서를 식별합니다.

      for store in TRUSTED_ROOTS MACHINE_SSL_CERT vpxd-extension wcp ; do echo $store; /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store "$store" --text | grep Public-Key; done

    2. 키 크기가 8192비트보다 큰 인증서를 교체합니다.

    3. NSX를 사용하는 경우 NSX에서 vCenter를 다시 등록합니다.

    4. WCP 서비스를 다시 시작합니다.

    자세한 내용은 기술 자료 문서 96562를 참조하십시오.

  • 라이브러리가 여러 vSphere 네임스페이스에 연결된 경우 vCenter 컨텐츠 라이브러리에서 템플릿이 삭제될 수 있음

    라이브러리가 vSphere IaaS 제어부의 여러 네임스페이스에 연결되어 있을 때 라이브러리가 네임스페이스에서 연결 해제되거나 네임스페이스가 삭제되는 경우 이 문제를 확인할 수 있습니다.

    해결 방법:

    라이브러리를 여러 네임스페이스에 연결하려는 경우 로컬 라이브러리를 사용하면 안 됩니다. 대신 vCenter에 게시된 라이브러리를 생성하고 모든 템플릿을 게시된 라이브러리에 업로드합니다. 그런 다음 동일한 vCenter에 게시된 라이브러리의 템플릿을 동기화할 구독 라이브러리를 생성하고 이 구독 라이브러리를 여러 네임스페이스에 연결합니다. 이렇게 하면 라이브러리가 네임스페이스에서 연결 해제되거나 네임스페이스가 삭제되는 경우에는 라이브러리 항목이 vCenter에서 삭제되지 않습니다.

  • VMware vSphere Automation REST API를 사용하여 VM 클래스를 생성하거나 업데이트하고 configSpec에 정수 필드를 포함하면 오류가 발생함

    configSpec에 numCPU 또는 memoryMB와 같은 정수 필드가 포함된 경우 다음 오류를 확인할 수 있습니다.

    알 수 없는 오류 - vcenter.wcp.vmclass.configspec.invalid: json: unsupported discriminator kind: struct.

    알 수 없는 오류 - vcenter.wcp.vmclass.configspec.invalid: json: cannot unmarshal string into Go struct field VirtualMachineConfigSpec.<fieldName> of type int32.

    이 문제는 VAPI 끝점에서 원시 REST configSpec JSON을 정수로 구문 분석하고 정수를 문자열로 전달하여 실패를 유발하는 알려진 문제로 인해 발생합니다. 이 문제는 VMware Developer Center를 통해 REST API를 사용하는 경우에만 발생합니다.

    해결 방법: REST API 대신 DCLI 또는 vSphere Client를 사용하여 VM 클래스를 생성하거나 업데이트합니다.

    또는 python/java에 대해 vSphere Automation SDK를 사용할 수 있습니다. 다음 예는 pyvmomi를 사용하여 vCenter에서 얻은 VirtualMachineConfigSpec(vim.vm.ConfigSpec) 개체를 변환하기 위해 공용 프로토콜 트랜스코더 서비스를 사용하는 방법을 보여줍니다. 이 예의 마지막 항목은 수동으로 작성된 JSON을 구문 분석하는 방법을 보여줍니다. 그런 다음 개체를 VirtualMachineClasses API로 보낼 수 있습니다.

  • 감독자에 유효한 vSphere VMware Foundation 라이센스를 적용한 후에도 워크로드 관리 페이지에 만료 주의와 함께 이전 평가판 라이센스가 계속 표시됨

    평가판 라이센스로 감독자를 사용하도록 설정했을 때 감독자에 vSphere VMware Foundation 라이센스를 적용하면 이 문제가 발생할 수 있습니다. 새 라이센스가 vSphere Client 워크로드 관리 페이지의 vCenter > 워크로드 관리 > 감독자 > 감독자 아래에 나타나지 않습니다. 새 라이센스 키가 성공적으로 적용되었는데도 vSphere Client는 이전 평가판 라이센스 만료 날짜가 포함된 주의를 계속 표시합니다.

    해결 방법: 없음. 새 라이센스는 vSphere Client의 관리 > 라이센스 > 자산 > 감독자 아래에 올바르게 표시됩니다.

  • 추가되거나 삭제된 규칙이 마지막 규칙이 아닌 경우 보안 정책 CRD의 업데이트된 보안 정책 규칙이 적용되지 않음

    DevOps는 NSX 기반 보안 정책을 감독자 클러스터 네임스페이스에 적용하도록 보안 정책 CRD를 구성할 수 있습니다. CRD를 업데이트하고 보안 정책 규칙을 추가하거나 삭제할 때 업데이트된 규칙이 규칙 목록의 마지막 규칙이 아니면 해당 규칙이 적용되지 않습니다.

    해결 방법: 규칙 목록의 끝에 규칙을 추가하거나 규칙 추가 또는 삭제를 위해 별도의 보안 정책을 사용합니다.

  • vSphere 8.0 U2에서 VM 이미지 이름 형식을 변경하면 이전 VM 이미지 이름이 사용될 때 문제가 발생할 수 있음

    vSphere 8.0 업데이트 2 이전에는 VM 이미지 리소스의 이름이 컨텐츠 라이브러리 항목의 이름에서 파생되었습니다. 예를 들어 컨텐츠 라이브러리 항목의 이름이 photonos-5-x64이면 해당 VirtualMachineImage 리소스의 이름도 photonos-5-x64가 됩니다. 이로 인해 서로 다른 라이브러리의 라이브러리 항목 이름이 동일할 때 문제가 발생했습니다.

    vSphere 8.0 업데이트 2 릴리스에서는 셀프 서비스 방식으로 VM 이미지를 관리하도록 VM 이미지 서비스가 도입되었습니다. vSphere IaaS 제어부에서 독립형 VM에 대한 컨텐츠 라이브러리 생성 및 관리를 참조하십시오.

    이 새로운 기능을 사용하면 컨텐츠 라이브러리를 네임스페이스 또는 전체 감독자 클러스터와 연결할 수 있으며 이를 위해 Kubernetes 클러스터의 VM 이미지 리소스 이름이 고유하고 예측 가능해야 합니다. 따라서 라이브러리 항목 이름과의 잠재적 충돌을 방지하기 위해 이제 VM 이미지는 새로운 이름 지정 형식(vmi-xxx)을 따릅니다. 그러나 이러한 변경으로 인해 이전 이미지 이름(예: photonos-5-x64 또는 centos-stream-8)을 참조하는 이전 VM YAML을 사용하는 경우 vSphere 8.0 업데이트 2 릴리스에서 문제가 발생할 수 있습니다.

    해결 방법:

    1. 다음 명령을 사용하여 VM 이미지에 대한 정보를 검색합니다.

      • 네임스페이스와 연결된 이미지를 표시하려면 kubectl get vmi -n <namespace>을 실행합니다.

      • 클러스터에서 사용할 수 있는 이미지를 가져오려면 kubectl get cvmi를 실행합니다.

    2. NAME 열 아래에 나열된 이미지 리소스 이름을 가져온 후 VM 배포 규격에서 이름을 업데이트합니다.

  • 감독자 자동 업그레이드 중에 vSphere의 WCP 서비스 프로세스가 패닉을 트리거하고 예기치 않게 중지될 수 있음

    WCP 서비스 프로세스에 대해 생성된 코어 덤프 파일을 확인할 수 있습니다.

    해결 방법: 없음. VMON 프로세스는 WCP 서비스를 자동으로 다시 시작하고 WCP 서비스는 더 이상 문제 없이 업그레이드를 재개합니다.

  • vSphere 포드에서 ErrImagePull 및 제공자 실패 상태로 인해 감독자 업그레이드가 중지됨. vSphere 포드에 연결된 영구 볼륨(감독자 서비스 포함)은 ErrImagePull 실패 시 분리되지 않을 수 있음

    ErrImagePull로 인해 vSphere 포드가 실패하는 경우 영구 볼륨이 분리되지 않을 수 있습니다. 이로 인해 vSphere 포드가 연속적으로 실패할 수 있습니다. 필요한 영구 볼륨이 실패한 인스턴스에 연결되어 있기 때문입니다. 감독자 업그레이드 중에 감독자 내의 vSphere 포드가 provider failed 상태로 전환되어 응답하지 않는 상태가 될 수 있습니다.

    해결 방법: 영구 볼륨이 연결되어 있는 실패한 vSphere 포드의 인스턴스를 삭제합니다. vSphere 포드와 연결된 PVC(영구 볼륨 할당) 및 영구 볼륨은 보존할 수 있다는 점에 유의해야 합니다. 업그레이드를 완료한 후 동일한 PodSpecPVC를 사용하여 vSphere 포드를 다시 생성하여 데이터 무결성 및 기능을 유지합니다. 이 문제를 완화하려면 ReplicaSet(DaemonSet, 배포)로 vSphere 포드를 생성하여 지정된 시간에 안정적인 복제 vSphere 포드 집합이 실행되도록 유지합니다.

  • 리더 선택으로 인해 감독자 업그레이드가 50%에서 중단되고 Pinniped 업그레이드가 실패함

    롤아웃 중에 Pinniped 포드가 보류 중 상태에서 중단되고 Pinniped 구성 요소 업그레이드 중에 감독자 업그레이드가 실패합니다.

    해결을 위한 단계는 다음과 같습니다.

    1. kubectl get pods -n vmware-system-pinniped를 실행하여 Pinniped 포드의 상태를 확인합니다.

    2. kubectl get leases -n vmware-system-pinniped pinniped-supervisor -o yaml을 실행하여 holderIdentity가 보류 중 상태의 Pinniped 포드가 아닌지 확인합니다.

    3. kubectl delete leases -n vmware-system-pinniped pinniped-supervisor를 실행하여 비활성 포드가 holderIdentity인 pinniped-supervisor의 리스 개체를 제거합니다.

    4. kubectl get pods -n vmware-system-pinniped를 다시 실행하여 vmware-system-pinniped 아래의 모든 포드가 가동되어 실행 중인지 확인합니다.

  • 감독자 제어부 VM의 전원이 켜진 상태에서 ESXi 호스트 노드가 유지 보수 모드로 전환될 수 없음

    NSX Advanced Load Balancer를 사용하는 감독자 설정에서 Avi 서비스 엔진 VM이 전원이 켜진 상태인 경우 ESXi 호스트가 유지 보수 모드로 전환되지 못합니다. 이는 유지 보수 모드에서의 ESXi 호스트 업그레이드 및 NSX 업그레이드에 영향을 미칩니다.

    해결 방법: ESXi 가 유지 보수 모드로 전환될 수 있도록 Avi 서비스 엔진 VM의 전원을 끕니다.

  • VDIS에서 vSphere 포드가 있는 ClusterIP를 사용하여 루프백 트래픽을 수신할 수 없음

    vSphere 포드 내의 애플리케이션이 동일한 vSphere 포드(다른 컨테이너) 내에서 제공되는 ClusterIP에 연결하려고 하면 VSIP 내의 DLB가 트래픽을 vSphere 포드로 다시 라우팅할 수 없습니다.

    해결 방법: 없음.

  • 네트워크 정책이 VDS 기반 감독자에서 적용되지 않음

    NetworkPolicy를 사용하는 기존 서비스 YAML은 변경할 필요가 없습니다. NetworkPolicy가 파일에 있는 경우 적용되지 않습니다.

    해결 방법: VDS용 네트워킹에 정책 기반 규칙을 설정해야 합니다. NetworkPolicy 지원의 경우 NSX 네트워킹 지원이 필요합니다.

  • 감독자에서 Carvel 서비스를 제거한 후에도 해당 서비스의 네임스페이스가 vSphere Client에 계속 표시될 수 있음

    감독자에서 Carvel 서비스를 제거하는 데 20분 넘게 걸리면 서비스가 제거된 후에도 해당 네임스페이스가 vSphere Client에 계속 표시될 수 있습니다.

    동일한 감독자에 서비스를 다시 설치하려는 시도는 네임스페이스가 삭제될 때까지 실패합니다. 그리고 다시 설치하는 동안 ns_already_exist_error 메시지가 표시됩니다.

    로그 파일에 다음 항목이 표시됩니다.

    /var/log/vmware/wcp/wcpsvc.log should have the message - "Time out for executing post-delete operation for Supervisor Service with serviceID '<service-id>' from cluster '<cluster-id>'. Last error: <error>"

    해결 방법: vSphere Client에서 네임스페이스를 수동으로 삭제합니다.

    1. vSphere Client 홈 메뉴에서 워크로드 관리를 선택합니다.

    2. 네임스페이스 탭을 클릭합니다.

    3. 네임스페이스 목록에서 삭제되지 않은 네임스페이스를 선택하고 제거 버튼을 클릭하여 네임스페이스를 삭제합니다.

  • 감독자 업그레이드 없이 ESXi 호스트를 7.0 업데이트 3에서 8.0으로 업그레이드하면 ESXi 호스트가 준비 안 됨으로 표시되고 워크로드가 오프라인으로 전환됨

    감독자의 일부인 ESXi 호스트를 vSphere 7.0 업데이트 3에서 vSphere 8.0으로 업그레이드하고 감독자의 Kubernetes 버전을 업그레이드하지 않으면 ESXi 호스트가 [준비 안 됨]으로 표시되고 호스트에서 실행 중인 워크로드가 오프라인이 됩니다.

    해결 방법: 감독자의 Kubernetes 버전을 1.21, 1.22 또는 1.23 이상으로 업그레이드합니다.

  • vCenter Server를 클릭 한 번으로 업그레이드하면 감독자가 자동으로 업그레이드되지 않음

    감독자의 Kubernetes 버전이 1.22 이전 버전인 경우, 클릭 한 번으로 vCenter Server를 8.0으로 업그레이드하면 8.0에 대해 지원되는 최소 Kubernetes 버전인 1.23으로 감독자가 자동 업그레이드할 수 없습니다.

    해결 방법: vCenter Server를 8.0으로 업그레이드하기 전에 감독자의 Kubernetes 버전을 1.22로 업그레이드합니다. vCenter Server를 8.0으로 이미 업그레이드한 경우에는 감독자의 Kubernetes 버전을 1.23으로 수동으로 업그레이드합니다.

  • 보안 정책 사용자 지정 리소스에서 규칙을 변경하는 경우 오래된 규칙이 삭제되지 않을 수 있음

    이 문제는 보안 정책을 업데이트할 때 발생할 수 있습니다. 예를 들어 규칙 A와 B가 포함된 보안 정책 사용자 지정 리소스를 생성한 다음, 규칙을 B와 C로 변경하여 정책을 업데이트합니다. 그 결과 규칙 A가 삭제되지 않습니다. NSX 관리부에 B와 C 외에 규칙 A가 계속 표시됩니다.

    해결 방법: 보안 정책을 삭제한 다음 동일한 정책을 생성합니다.

  • vCenter Server 및 vSphere IaaS 제어부 업그레이드 후 Tanzu Kubernetes Grid 클러스터가 클러스터의 노드에 연결된 것으로 나타나는 볼륨으로 인해 업그레이드를 완료할 수 없음

    Tanzu Kubernetes Grid 클러스터가 업그레이드에 실패하면 클러스터의 노드에 연결된 것으로 표시되고 지워지지 않는 볼륨을 확인할 수 있습니다. 이 문제는 업스트림 Kubernetes의 문제로 인해 발생할 수 있습니다.

    해결 방법:

    1. 다음 명령을 사용하여 스케줄링이 사용되지 않도록 설정된 TKG 클러스터 노드에 대한 정보를 가져옵니다.

      kubectl get node tkc_node_name -o yaml

      예:

      # kubectl get node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95 -o yaml
apiVersion: v1
kind: Node
metadata:
  annotations:
    cluster.x-k8s.io/cluster-name: gcm-cluster-antrea-1
    cluster.x-k8s.io/cluster-namespace: c1-gcm-ns
    cluster.x-k8s.io/machine: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
    cluster.x-k8s.io/owner-kind: MachineSet
    cluster.x-k8s.io/owner-name: gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7
    csi.volume.kubernetes.io/nodeid: '{"csi.vsphere.vmware.com":"gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"}'
    kubeadm.alpha.kubernetes.io/cri-socket: /run/containerd/containerd.sock
    node.alpha.kubernetes.io/ttl: "0"
    volumes.kubernetes.io/controller-managed-attach-detach: "true"
….
….
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

      이 노드의 status.volumeAttached 속성에 vSphere CSI 볼륨이 있는지 확인합니다. 볼륨이 있는 경우 다음 단계로 진행합니다.

    2. 1단계에서 식별된 노드에서 실행 중인 포드가 없는지 확인합니다. 다음 명령을 사용합니다.

      kubectl get pod -o wide | grep tkc_node_name

      예:

      kubectl get pod -o wide | grep gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      이 명령의 빈 출력은 포드가 없음을 의미합니다. 1단계의 출력에는 포드가 없는 노드에 연결된 볼륨이 표시되므로 다음 단계로 진행합니다.

    3. 모든 노드 개체에 대한 정보를 가져와서 동일한 볼륨이 다른 노드에 연결되어 있는지 확인합니다.

      kubectl get node -o yaml

      예:

      동일한 볼륨 이름이 두 개의 TKG 클러스터 노드 개체에 나타납니다.

      On old node - "gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd

On new node "gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88"
  volumesAttached:
  - devicePath: ""
    name: kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
    ...
  volumesInUse:
  - kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd
  ...

    4. 볼륨 이름의 볼륨 핸들을 기반으로 PV를 검색합니다.

      위의 예에서 볼륨 이름은 kubernetes.io/csi/csi.vsphere.vmware.com^943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd이고 볼륨 핸들은 943bd457-a6cb-4f3d-b1a5-e301e6fa6095-59c73cea-4b75-407d-8207-21a9a25f72fd입니다.

      다음 명령을 사용하여 모든 PV를 가져오고 위의 볼륨 핸들을 검색합니다.

      kubectl get pv -o yaml

      위 예에서 해당 볼륨 핸들이 있는 PV는 pvc-59c73cea-4b75-407d-8207-21a9a25f72fd입니다.

    5. volumeattachment 명령을 사용하여 이전 단계에서 찾은 PV를 검색합니다.

      kubectl get volumeattachment | grep pv_name

      예:

      # kubectl get volumeattachment | grep pvc-59c73cea-4b75-407d-8207-21a9a25f72fd
NAME                                                                   ATTACHER                 PV                                         NODE                                                 ATTACHED   AGE
csi-2ae4c02588d9112d551713e31dba4aab4885c124663ae4fcbb68c632f0f46d3e   csi.vsphere.vmware.com   pvc-59c73cea-4b75-407d-8207-21a9a25f72fd   gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88   true       3d20h

      노드 gcm-cluster-antrea-1-workers-pvx5v-84486fc97-ndh88 대신 노드 gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95에 연결된 볼륨 연결을 확인할 수 있습니다. 이는 gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95의 status.volumeAttached가 잘못되었음을 나타냅니다.

    6. 노드 개체에서 오래된 volumeAttached 항목을 삭제합니다.

      kubectl edit node tkc_node_name

      예:

      kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95

      status.volumeAttached에서 오래된 볼륨 항목을 제거합니다.

    7. status.volumeAttached 속성의 모든 오래된 볼륨에 대해 위 단계를 반복합니다.

    8. WCPMachine이 여전히 존재하는 경우 수동으로 삭제하고 몇 분 동안 기다렸다가 클러스터를 조정합니다.

      # kubectl get wcpmachines -n c1-gcm-ns
NAMESPACE   NAME                                       ZONE   PROVIDERID                                       IPADDR
c1-gcm-ns   gcm-cluster-antrea-1-workers-jrc58-zn6wl          vsphere://423c2281-d1bd-9f91-0e87-b155a9d291a1   192.168.128.17

# kubectl delete wcpmachine gcm-cluster-antrea-1-workers-jrc58-zn6wl -n c1-gcm-ns
wcpmachine.infrastructure.cluster.vmware.com "gcm-cluster-antrea-1-workers-jrc58-zn6wl" deleted

  • vSphere 관리자가 클러스터 용량을 초과하는 리소스 제한으로 셀프 서비스 네임스페이스 템플릿을 구성하는 경우 경고가 트리거되지 않음.

    vSphere 관리자가 클러스터 용량을 초과하는 리소스 제한을 구성하는 경우 DevOps 엔지니어는 템플릿을 사용하여 리소스가 많은 vSphere 포드를 배포할 수 있습니다. 그 결과로 워크로드가 실패할 수 있습니다.

    해결 방법: 없음

  • Tanzu Kubernetes Grid 클러스터가 포함된 감독자 네임스페이스를 삭제하면 감독자에 있는 영구 볼륨 할당이 종료 중 상태로 남을 수 있음

    이 문제는 시스템이 네임스페이스를 삭제하고 Tanzu Kubernetes Grid 클러스터의 포드에서 볼륨을 분리하는 동안 리소스 충돌이 발생할 때 관찰할 수 있습니다.

    감독자 네임스페이스 삭제가 완료되지 않은 상태로 남고 vSphere Client에 네임스페이스 상태가 종료 중으로 표시됩니다. Tanzu Kubernetes Grid 클러스터의 포드에 연결된 영구 볼륨 할당도 종료 중 상태로 남습니다.

    다음 명령을 실행하면 Persistentvolumeclaims에서 작업을 수행할 수 없습니다 오류가 표시됩니다.

    kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    kubectl logs vsphere-csi-controller-pod-name -n vmware-system-csi -c vsphere-syncer

    PersistentVolumeClaim 업데이트 실패: \\\"<pvc-name>\\\" on namespace: \\\"<supervisor-namespace>\\\". Error: persistentvolumeclaims \\\"<pvc-name>\\\"에서 작업을 수행할 수 없습니다. 개체가 수정되었습니다. 변경 사항을 최신 버전에 적용하고 다시 시도하십시오.\

    해결 방법:

    다음 명령을 사용하여 문제를 해결합니다.

    kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    kubectl patch pvc <pvc-name> -n <supervisor-namespace> -p '{"metadata":{"finalizers":[]}}' --type=merge

  • vSAN과 같은 공유 데이터스토어에서 여러 FCD 및 볼륨을 삭제하면 성능에 변화가 있을 수 있음

    해결된 문제로 인해 성능 변화가 발생할 수 있습니다. 해결되지 않은 동안은 이 문제로 인해 FCD 삭제 작업 실패 후 오래된 FCD 및 볼륨이 데이터스토어에 남아 있게 됩니다.

    해결 방법: 없음. 성능에 변화가 있어도 삭제 작업은 평소처럼 작동합니다.

  • vCenter Server를 재부팅하는 동안 DevOps 사용자가 볼륨 작업 또는 상태 저장 애플리케이션 배포를 시작하면 작업이 실패할 수 있음

    이 문제는 워크로드 스토리지 관리 사용자 계정이 잠기고 감독자에서 실행되는 vSphere CSI 플러그인이 인증에 실패하기 때문에 발생합니다. 그 결과 잘못된 로그인 오류로 인해 볼륨 작업이 실패합니다.

    로그 파일 /var/log/vmware/vpxd/vpxd.log에 다음 메시지가 표시됩니다.

    Authentication failed: The account of the user trying to authenticate is locked. :: The account of the user trying to authenticate is locked. :: User account locked: {Name: workload_storage_management-<id>, Domain: <domain>})

    해결 방법:

    1. 계정 잠금 해제 시간을 가져옵니다.

      1. vSphere Client에서 [관리]로 이동하고 [Single Sign-On]에서 [구성]을 클릭합니다.

      2. [계정] 탭을 클릭합니다.

      3. [잠금 정책]에서 [잠금 해제 시간](초)을 가져옵니다.

    2. kubectl용 vSphere 플러그인을 사용하여 감독자로 인증합니다.

      kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME

    3. vmware-system-csi-namespace에서 vsphere-csi-controller 배포의 원래 복제본 수를 기록해 둡니다.

      kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'

      original-replica-count

    4. vsphere-csi-controller 배포 복제본 수를 0으로 스케일 다운합니다.

      kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi

    5. [잠금 해제 시간]에 표시된 시간(초)을 기다립니다.

    6. vsphere-csi-controller 배포 복제본 수를 원래 값으로 스케일 업합니다.

      kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi

감독자의 TKG 알려진 문제

  • vSphere IaaS 제어부 7.0.x 환경을 vSphere 8.0.x로 업그레이드하면 v1.27.6의 모든 TKG 클러스터가 호환되지 않음

    vSphere 8.0.x는 TKR 1.27.6을 지원하지 않습니다.

    따라서 vSphere IaaS 제어부 7.0.x를 vSphere 8.0.x로 업그레이드하면 v1.27.6의 TKG 클러스터가 호환되지 않습니다. 감독자 업그레이드 중에는 사전 확인 주의가 수신되지 않습니다.

    해결 방법:

    • vSphere 7.0.x에서 v1.27.6의 TKGS 클러스터를 실행 중인 경우 vCenter 8.0.x로 업그레이드하지 마십시오(특히 vCenter 8.0 업데이트 2b). 자세한 내용은 VMware Tanzu Kubernetes 릴리스 정보 및 KB 문서 96501을 참조하십시오

    • vSphere 7.x 환경을 vCenter 8.x로 업그레이드하려는 경우 TKR 1.27.6으로 업그레이드하지 마십시오.

  • TKG 클러스터 작업자 노드 전원 켜기가 실패하고 nsx-ncp 포드에서 오류 로그 VIF restore activity already completed for attachment ID가 표시됨

    TKG 클러스터 작업자 노드 전원 켜기가 실패하고 다음 오류가 표시됩니다.

    nsx-container-ncp Generic error occurred during realizing network for VirtualNetworkInterface

    NCP에서 다음 오류를 기록합니다.

    VIF restore activity already completed for attachment ID

    NSX 백업 후 생성된 TKG 클러스터 노드의 VM이 NSX 복원 직후 vMotion으로 마이그레이션되면 연결 ID가 vMotion에서 재사용되고 NCP의 복원 요청을 차단하기 때문에 NCP가 VM의 포트를 복원할 수 없습니다.

    해결 방법:

    1. NSX Manager로 이동하여 삭제해야 하는 세그먼트 포트를 가져옵니다. 세그먼트 포트의 표시 이름 형식은 다음과 같습니다. <vm name>.vmx@<attachment id>

    2. 새로 생성된 포트를 삭제하기 전에 VM이 실행 중인 호스트를 찾고 호스트에서 /etc/init.d/nsx-opsagent stop을 실행하여 ops-agent를 끕니다.

    3. NSX API를 사용하여 포트를 삭제합니다. https://<nsx-mgr>/api/v1/logical-ports/<logical switch port id>?detach=true

    4. 호스트에서 /etc/init.d/nsx-opsagent start를 실행하여 ops-agent를 켭니다.

    5. NCP가 포트를 복원할 때까지 기다립니다.

  • TKG 클러스터 정리 중 또는 ESXi 호스트 다운타임에서 복구하는 동안 TKG 클러스터의 포드, PV 및 PVC가 Terminating 상태에서 중단될 수 있음

    일반적인 TKG 클러스터 삭제 및 정리 프로세스의 일환으로 모든 배포, statefulsets, PVC, PV 및 유사한 개체가 삭제됩니다. 그러나 TKR v1.24 이하를 기반으로 하는 TKG 클러스터의 경우 DetachVolume 오류로 인해 일부 PV가 Terminating 상태에서 중단될 수 있습니다. 이 문제는 VolumeAttachment 개체의 DetachVolume 오류로 인해 VolumeAttachment의 finalizers가 제거되지 않아 관련 개체를 삭제하지 못할 때 발생합니다. 이 시나리오는 ESXi 호스트에 다운타임이 있는 경우에도 발생할 수 있습니다.

    해결 방법: TKG 클러스터에서 다음 명령을 실행하여 detachError가 있는 volumeattachments에서 finalizers를 제거합니다.

    kubectl get volumeattachments \
-o=custom-columns='NAME:.metadata.name,UUID:.metadata.uid,NODE:.spec.nodeName,ERROR:.status.detachError' \
--no-headers | grep -vE '<none>$' | awk '{print $1}' | \
xargs -n1 kubectl patch -p '{"metadata":{"finalizers":[]}}' --type=merge volumeattachments

  • 백업 및 복원 후 TGK 클러스터에 연결할 수 없음

    NSX 백업 후에 vSphere 네임스페이스가 생성되고 사용자 지정된 수신/송신 CIDR로 구성된 경우 NSX가 백업에서 복원되면 NCP가 복원 프로세스를 완료하지 못하고 vSphere 네임스페이스의 TKG 클러스터를 사용할 수 없습니다. 복원 프로세스 중에 NCP가 실패하고 다음과 같은 오류가 발생합니다.

    NSX IP Pool ipp_<supervisor_namespace_id>_ingress not found in store

    해결 방법: 감독자의 백업이 NSX 백업과 거의 같은 시간에 하지만 영향을 받은 vSphere 네임스페이스가 생성되기 전에 수행된 경우에는 백업에서 감독자도 복원합니다. 또는 vSphere 네임스페이스 및 연결된 TKG 클러스터를 삭제하고 NCP가 다시 동기화될 때까지 기다린 다음, 삭제된 리소스를 다시 생성합니다.

  • NSX 백업 및 복원 후 TKG 클러스터에 연결할 수 없음

    사용자 지정된 수신 CIDR로 감독자가 구성된 경우 NSX 백업 복원 후 TKG 클러스터를 사용하지 못할 수 있습니다. NCP 구성 요소가 TKG 클러스터의 수신 VIP를 제대로 검증할 수 없기 때문입니다.

    해결 방법: NSX API를 사용하여 NSX의 TKG 클러스터에 대한 VIP를 수동으로 구성하여 액세스를 복원합니다.

  • 프록시 서버로 구성된 기존 Tanzu Kubernetes Grid 클러스터를 vSphere 8 감독자로 업그레이드할 수 없음

    해결됨: 이 알려진 문제는 vSphere 8 with Tanzu MP1 릴리스에서 수정되었습니다.

    프록시 서버를 사용하여 기존 Tanzu Kubernetes Grid 클러스터를 구성한 경우, vSphere 7 감독자의 해당 클러스터를 vSphere 8 감독자의 Tanzu Kubernetes Grid 2.0으로 업그레이드할 수 없습니다.

    해결 방법: noProxy 필드의 컨텐츠가 업그레이드 검사와 충돌합니다. 이 필드는 프록시 stanza가 클러스터 규격에 추가된 경우에 필요하기 때문에 vSphere 8로 업그레이드하기 전에 프록시 구성을 완전히 제거해야 합니다.

  • antrea-resource-init 포드가 보류 중 상태에서 중단됨

    Tanzu Kubernetes Grid 클러스터의 Tanzu Kubernetes 릴리스 버전을 업그레이드한 후 antrea-resource-init 포드가 보류 중 상태일 수 있습니다.

    해결 방법: 감독자에서 포드를 다시 시작합니다.

  • Tanzu Kubernetes Grid 클러스터 v1.21.6이 FALSE 상태가 되고 일부 시스템이 마이그레이션되지 않을 수 있음

    vCenter Server 8로 업그레이드하고 감독자를 업데이트한 후 v1.21.6 Tanzu Kubernetes Grid 클러스터가 FALSE 상태가 되고 일부 wcpmachine이 vspheremachine으로 마이그레이션되지 않을 수 있습니다.

    해결 방법: 없음

  • 기본적으로 vmware-system-user 계정의 암호는 TKR 버전 v1.23.8---vmware.2-tkg.2-zshippable을 실행 중인 TKG 클러스터에 대해 60일 후에 만료됩니다.

    STIG 강화의 일부로 TKR 버전 v1.23.8---vmware.2-tkg.2-zshippable을 실행 중인 TKG 클러스터의 경우 vmware-system-user 계정이 60일 후에 만료되도록 구성되어 있습니다. 이는 vmware-system-user 계정을 사용하여 SSH를 통해 클러스터 노드에 연결하는 사용자에게 영향을 미칠 수 있습니다.

    필요한 경우 TKG 클러스터 노드에 대한 SSH 세션을 허용하여 vmware-system-user 암호 만료를 업데이트하려면 다음 기술 자료 문서를 참조하십시오. https://kb.vmware.com/s/article/90469

  • vSphere IaaS 제어부 8.0.0a의 TKC에서 tanzu-capabilities-controller-manager 포드가 계속해서 다시 시작되고 CLBO가 됨

    서비스 계정 사용 권한 문제의 결과로, TKR 버전 v1.23.8+vmware.2-tkg.2-zshippable을 사용하는 경우 TKG 클러스터의 tanzu-capabilities-controller-manager 포드가 CLBO(충돌 루프 백오프)에서 중단됩니다.

    해결 방법: TKC의 기능 서비스 계정 tanzu-capabilities-manager-sa에 필요한 사용 권한을 추가합니다.

    1. TKC에서 기능 패키지 조정을 일시 중지합니다.

      kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge

    2. 새 파일 capabilities-rbac-patch.yaml을 생성합니다.

      apiVersion: v1
kind: Secret
metadata:
  name: tanzu-capabilities-update-rbac
  namespace: vmware-system-tkg
stringData:
  patch-capabilities-rbac.yaml: |
    #@ load("@ytt:overlay", "overlay")
    #@overlay/match by=overlay.subset({"kind":"ClusterRole", "metadata": {"name": "tanzu-capabilities-manager-clusterrole"}}),expects="1+"
    ---
    rules:
      - apiGroups:
        - core.tanzu.vmware.com
        resources:
          - capabilities
        verbs:
          - create
          - delete
          - get
          - list
          - patch
          - update
          - watch
      - apiGroups:
          - core.tanzu.vmware.com
        resources:
          - capabilities/status
        verbs:
          - get
          - patch
          - update-rbac

    3. TKC에서 기능 클러스터 역할을 패치합니다.

      //Replace tkc with the name of the Tanzu Kubernetes Grid cluster: kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"metadata":{"annotations":{"ext.packaging.carvel.dev/ytt-paths-from-secret-name.0":"tanzu-capabilities-update-rbac"}}}' --type=merge

    4. TKC에서 tanzu-capabilities-controller-manager를 삭제합니다.

  • 3개 vSphere 영역에 배포된 감독자의 Tanzu Kubernetes Grid 2.0 클러스터는 vGPU 및 인스턴스 스토리지가 있는 VM을 지원하지 않음

    3개 vSphere 영역에 배포된 감독자 인스턴스에 프로비저닝된 Tanzu Kubernetes Grid 2.0 클러스터는 vGPU 및 인스턴스 스토리지가 있는 VM을 지원하지 않습니다.

    해결 방법: 없음

  • TKR 버전 v1.22.9가 컨텐츠 라이브러리 이미지에 나열되지만 kubectl 명령에는 나열되지 않음

    TKR 이미지용 컨텐츠 라이브러리에 TKR v1.22.9가 나열됩니다. kubectl get tkr 명령을 실행하면 이 이미지가 사용 가능한 것으로 나열되지 않습니다. TKR v1.22.9는 사용할 수 없으며 사용해서도 안 되기 때문입니다. 이 이미지는 컨텐츠 라이브러리에 오류로 표시됩니다.

    해결 방법: TKR v1.22.9 이외의 TKR을 사용하십시오. 사용 가능한 TKR 목록은 TKR 릴리스 정보를 참조하십시오.

  • vSphere IaaS 제어부 8.0.0a에서 v1alpha1 API 및 v1.23.8 TKR을 사용하여 TKC를 프로비저닝할 수 없음

    TKC v1alpha1 API를 활용하여 TKC 버전 v1.23.8을 프로비저닝하는 경우, 요청이 실패하고 다음 오류 메시지가 표시됩니다. "버전 힌트 "1.23.8" 및 기본 OS 레이블: "os-arch=amd64,os-name=photon,os-type=linux,os-version=3.0"과 일치하는 호환되는 전체 버전을 찾을 수 없습니다."

    해결 방법: TKC를 프로비저닝할 때 TKC v1alpha2 또는 v1alpha3 API로 전환합니다.

  • v1beta1 API로 프로비저닝된 Tanzu Kubernetes Grid 2.0 클러스터는 기본 ClusterClass를 기반으로 해야 함

    v1beta1 API를 사용하여 감독자에서 Tanzu Kubernetes Grid 2.0 클러스터를 생성하는 경우 클러스터는 기본 tanzukubernetescluster ClusterClass를 기반으로 해야 합니다. 다른 ClusterClass에 기반한 클러스터는 시스템에서 조정되지 않습니다.

    해결 방법: vSphere 8 U1 릴리스부터 사용자 지정 ClusterClass를 기반으로 v1beta1 클러스터를 프로비저닝할 수 있습니다. KB 문서 https://kb.vmware.com/s/article/91826을 참조하십시오.

네트워킹에 대한 알려진 문제

  • NSX Advanced Load Balancer 설정에서 clusternetworkinfo 또는 namespacenetworkinfo 출력에 usage.ingressCIDRUsage 섹션이 없음

    NSX Advanced Load Balancer 설정에서 수신 IP는 Avi 컨트롤러에 의해 할당되며 ingressCIDR의 사용량이 clusternetworkinfo 또는 namespacenetworkinfo 출력에 표시되지 않습니다.

    해결 방법: Avi 컨트롤러 UI 애플리케이션 > VS VIP에서 ingressCIDR 사용량을 가져옵니다.

  • 라우팅된 감독자에 대한 네임스페이스를 삭제한 후 Tier-0 접두사 목록의 포드 CIDR이 제거되지 않음

    라우팅된 감독자에서 Tier-0 접두사 목록의 포드 CIDR은 네임스페이스를 삭제한 후에도 삭제되지 않습니다.

    해결 방법: 접두사 목록 개체를 삭제합니다.

    curl -k -u ‘admin:U2.HzP7QZ9Aw’ -X PATCH -d ‘{“prefixes”:[{“network” : “10.246.0.0/16”,“le” : 28,“action” : “PERMIT”}]}’ https://<IP ADDRESS>/policy/api/v1/infra/tier-0s/ContainerT0/prefix-lists/pl_domain-c9:45c1ce8d-d2c1-43cb-904f-c526abd8fffe_deny_t1_subnets -H ‘X-Allow-Overwrite: true’ -H ‘Content-type: application/json

  • NSX Advanced Load Blanacer를 사용할 때 Kubernetes 리소스 clusternetworkinfo 및 namespacenetworkinfo에 usage.ingressCIDRUsage가 포함되지 않음

    NSX 기반 감독자에서 NSX Advanced Load Balancer를 사용하는 경우 clusternetworkinfo 및 namespacenetworkinfo Kuberentes 리소스에 더 이상 usage.ingressCIDRUsage 필드가 포함되지 않습니다. 즉, kubectl get clusternetworkinfo <supervisor-cluster-name> -o json 또는 kubectl get namespacenetworkinfo <namespace-name> -n <namespace-name> -o json을 실행해도 출력에 ingressCIDR 사용량 개체가 포함되지 않습니다.

    해결 방법: Avi 컨트롤러 UI 페이지를 사용하여 ingressCIDR 사용량에 액세스합니다.

  • NSX 백업 및 복원 후 일부 네임스페이스에 오래된 Tier-1 세그먼트가 존재함

    NSX 백업 및 복원 절차 후에 서비스 엔진 NIC가 있는 오래된 Tier-1 세그먼트가 정리되지 않습니다.

    NSX 백업 후 네임스페이스가 삭제되면 복원 작업에서 NSX Advanced Load Balancer 컨트롤러 서비스 엔진 NIC와 연결된 오래된 Tier-1 세그먼트를 복원합니다.

    해결 방법: Tier-1 세그먼트를 수동으로 삭제합니다.

    1. NSX Manager에 로그인합니다.

    2. 네트워킹 > 세그먼트를 선택합니다.

    3. 삭제된 네임스페이스와 연결된 오래된 세그먼트를 찾습니다.

    4. 포트/인터페이스 섹션에서 오래된 서비스 엔진 NIC를 삭제합니다.

  • 로드 밸런서 모니터가 작동을 멈추고 감독자가 vSphere Client에서 "구성 중" 상태로 중단될 수 있음

    NSX Advanced Load Balancer를 사용하도록 설정한 경우 NSX에 여러 적용 지점이 있기 때문에 NCP가 로드 밸런서 상태를 끌어오지 못할 수 있습니다. 이것이 NSX Advanced Load Balancer(NSX에서 사용하도록 설정되면)로 구성된 기존 감독자에 영향을 미칩니다. 이 문제는 NSX Advanced Load Balancer를 활용하는 새 감독자에게 영향을 미칩니다. 이 문제의 영향을 받는 감독자는 LB 모니터 기능을 제외하고 계속 작동합니다.

    해결 방법: NSX에서 NSX Advanced Load Balancer를 사용하지 않도록 설정합니다. 그러면 NSX Advanced Load Balancer를 실행 중인 기존 감독자가 있는 WCP 환경에서 NSX Advanced Load Balancer를 사용하여 감독자를 배포하는 기능이 제한될 수 있습니다.

  • 내장 연결 모드 토폴로지를 사용하는 vCenter Server에서 NSX Advanced Load Balancer를 사용할 수 없음

    NSX Advanced Load Balancer 컨트롤러를 여러 클라우드에서 구성할 수 있습니다. 하지만 기본 클라우드 옵션만 지원되므로 vSphere IaaS 제어부를 사용하도록 설정하는 동안 여러 클라우드를 선택할 수는 없습니다. 따라서 내장 연결 모드 토폴로지를 사용하는 vCenter Server 버전에서는 NSX Advanced Load Balancer를 사용할 수 없습니다.

    각 vCenter Server에 대해 NSX 로드 밸런서를 구성합니다.

스토리지에 대한 알려진 문제

  • 데이터스토어가 vCenter 시스템 간에 공유되는 환경에서 여러 CNS 볼륨 동기화 오류가 발견됨

    크로스 vCenter 마이그레이션은 CNS에서 지원되지 않습니다. 그러나 CNS 정기 동기화는 자동으로 수행되고 공유 데이터스토어의 볼륨에 대한 잠금 경합을 생성합니다.

    해결 방법: 이 문제를 방지하려면 CNS 정기 동기화에 대해 큰 시간 간격을 설정합니다.

    1. vCenter에서 CNS 구성 파일을 찾습니다.

      /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml

    2. 다음 줄로 이동합니다.

      <newSyncInterval>60</newSyncInterval>

      기본적으로 주기적 동기화는 60초로 설정됩니다.

    3. 시간을 더 긴 기간으로 변경합니다(예: 1년의 경우 31536000).

  • vSAN Direct 데이터스토어의 디스크에 대한 볼륨 할당 유형을 변경할 수 없음

    vSAN Direct 데이터스토어의 디스크에 대한 볼륨 할당 유형을 결정한 후에는 변경할 수 없습니다. 기본 계층이 유형 변환을 지원하지 않기 때문입니다. 단, 복제 및 재배치와 같은 작업에는 새 디스크에 대한 볼륨 할당 유형 변경이 허용됩니다.

    해결 방법: 없음

  • 삭제된 VM으로 인해 CNS 작업이 대기열에 있음 상태에서 중단됨

    CNS로 전송된 작업이 작업 ID를 반환하지만 작업 상태가 대기열에 있음에서 변경되지 않습니다. 이 작업은 방금 삭제된 VM에 연결된 볼륨에 대한 작업입니다.

    해결 방법: 애플리케이션 계층이 호출 순서를 수정할 수 있는 경우 CNS 측에서는 어떤 작업도 수행할 필요가 없습니다. 그렇지 않은 경우 다음 단계에 따라 CNS 새 직렬화를 사용하지 않도록 설정합니다.

    1. vCenter에서 /usr/lib/vmware-vsan/VsanVcMgmtConfig.xml을 엽니다.

    2. 다음 구성을 false로 변경합니다. <newSerializationEnabled>true</newSerializationEnabled>

    3. 다음을 사용하여 vsan-health를 다시 시작합니다. vmon-cli -r vsan-health

    자세한 내용은 KB 93903을 참조하십시오.

  • PVC를 삭제한 후 PV가 종료됨 상태로 유지됨

    PVC(PersistentVolumeClaim)를 삭제한 후 해당 PV(영구 볼륨)가 감독자에서 종료됨 상태로 남아 있을 수도 있습니다. 또한 vSphere Client에 실패한 deleteVolume 작업이 여러 개 표시될 수도 있습니다.

    해결 방법:

    1. 감독자로 인증합니다.

      kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME

    2. 종료 중 상태의 영구 볼륨 이름을 가져옵니다.

      kubectl get pv

    3. 영구 볼륨에서 볼륨 핸들을 적어둡니다.

      kubectl describe pv <pv-name>

    4. 이전 단계의 볼륨 핸들을 사용하여 감독자에서 CnsVolumeOperationRequest 사용자 지정 리소스를 삭제합니다.

      kubectl delete cnsvolumeoperationrequest delete-<volume-handle>

    참고:

    PV를 삭제하기 전에 클러스터의 다른 리소스에서 사용되고 있지 않은지 확인합니다.

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