RSS
 

릴리스 정보에 포함된 내용

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

새로운 기능

새로운 기능, 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 with Tanzu 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을 배포하는 데 이미지를 사용할 수 있습니다.

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

  • 조각화를 줄여 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년 4월 18일 | 빌드 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 with Tanzu 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 with Tanzu 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 릴리스 릴리스 정보를 참조하십시오.

vSphere with Tanzu 8.0.0 GA 고객을 위한 중요 요구 사항

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

vSphere with Tanzu 8.0.0 GA를 배포한 경우 vSphere with Tanzu 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 with Tanzu 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 with Tanzu 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 with Tanzu 설명서가 제품의 워크플로를 더 잘 반영하도록 구조가 개선되어 컨텐츠에 더욱 집중할 수 있습니다. 또한, vSphere with Tanzu에 사용할 수 있는 모든 기술 설명서를 새로운 설명서 랜딩 페이지에서 액세스할 수 있습니다.


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

vSphere with Tanzu 설치 및 구성에 대한 지침은 vSphere with Tanzu 설치 및 구성 설명서를 참조하십시오. vSphere with Tanzu 업데이트에 대한 자세한 내용은 vSphere with Tanzu 유지 보수 설명서를 참조하십시오.

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

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

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

알려진 문제

감독자 알려진 문제

  • 감독자 자동 업그레이드 중에 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 with Tanzu 업그레이드 후 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 알려진 문제

  • 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 with Tanzu 8.0.0a의 TKC에서 tanzu-capabilities-controller-manager 포드가 계속해서 다시 시작되고 CLBO가 됨

    서비스 계정 사용 권한 문제의 결과로, TKR 버전 v1.23.8+vmware.2-tkg.2-zshippable을 사용하는 경우 Tanzu Kubernetes 클러스터의 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 with Tanzu 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 with Tanzu를 사용하도록 설정하는 동안 여러 클라우드를 선택할 수는 없습니다. 따라서 내장 연결 모드 토폴로지를 사용하는 vCenter Server 버전에서는 NSX Advanced Load Balancer를 사용할 수 없습니다.

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

스토리지

  • 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