VMware vSphere with Tanzu 7.0 릴리스 정보

릴리스 정보에 포함된 내용

업데이트 날짜: 2023년 7월 6일

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

• 새로운 기능

• vSphere with Tanzu에 대해 알아보기

• 해결된 문제

• 알려진 문제

새로운 기능

VMware vSphere with Tanzu는 월간 패치를 통해 새로운 특징과 기능을 도입하고, Kubernetes 및 기타 서비스에 대한 업데이트를 제공하며, 업스트림을 유지하고, 보고된 문제를 해결합니다. 여기에는 각 월간 패치에 제공되는 내용이 설명되어 있습니다.

• 새로운 기능, 2023년 7월 6일

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

• 새로운 기능, 2023년 2월 23일

• 새로운 기능, 2022년 12월 8일

• 새로운 기능, 2022년 9월 13일

• 새로운 기능, 2022년 7월 12일

• 새로운 기능, 2022년 5월 12일

• 새로운 기능, 2022년 3월 29일

• 새로운 기능, 2021년 10월 21일

• 새로운 기능, 2021년 10월 5일

• 새로운 기능, 2021년 8월 24일

• 새로운 기능, 2021년 4월 27일

• 새로운 기능, 2021년 3월 9일

• 새로운 기능, 2021년 2월 2일

• 새로운 기능, 2020년 12월 17일

• 새로운 기능, 2020년 10월 6일

• 새로운 기능, 2020년 8월 25일

• 새로운 기능, 2020년 7월 30일

• 새로운 기능, 2020년 6월 23일

• 새로운 기능, 2020년 5월 19일

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

2023년 7월 6일 빌드 정보 ESXi 7.0 업데이트 3m | 2023년 5월 3일 | ISO 빌드 21686933 vCenter Server 7.0 업데이트 3n | 2023년 7월 6일 | ISO 빌드 21958406 VMware NSX Advanced Load Balancer AVI-22.1.3 | 2023년 1월 31일

• 새로운 기능
• 감독자 클러스터에 대해 지원되는 Kubernetes 버전:

새로운 기능

• 감독자 클러스터에서 Kubernetes 1.24 지원 - 이 릴리스는 Kubernetes 1.24에 대한 지원을 추가하고 Kubernetes 1.21에 대한 지원을 삭제합니다.

감독자 클러스터에 대해 지원되는 Kubernetes 버전:

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

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

2023년 3월 30일 빌드 정보 ESXi 7.0 업데이트 3l | 2023년 3월 30일 | ISO 빌드 21424296 vCenter Server 7.0 업데이트 3l | 2023년 3월 30일| ISO빌드 21477706 VMware NSX Advanced Load Balancer avi-22.1.3 | 2023년 1월 31일

• 새로운 기능:
• 감독자 클러스터에 대해 지원되는 Kubernetes 버전
• 해결된 문제

새로운 기능:

• 없음. 이것은 단순히 버그 수정 릴리스입니다.

감독자 클러스터에 대해 지원되는 Kubernetes 버전

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

해결된 문제

이 패치는 다음 문제를 해결합니다.

• LRO(대규모 수신 오프로드)가 활성화되면 Antrea-ENCAP를 사용하는 Tanzu Kubernetes Grid 클러스터 VM에서 네트워크 성능 문제가 발생할 수 있습니다.

• 감독자에서 내장된 Harbor 레지스트리를 사용하도록 설정하면 기본 구성이 안전하지 않게 될 수 있습니다.

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

2023년 2월 23일 빌드 정보 ESXi 7.0 업데이트 3i | 2022년 12월 8일 | ISO 빌드 20842708 vCenter Server 7.0 업데이트 3k | 2023년 2월 23일 | ISO 빌드 21290409 VMware NSX Advanced Load Balancer avi-22.1.3 | 2023년 1월 31일

• 새로운 기능:

새로운 기능:

감독자

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

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

2022년 12월 8일 빌드 정보 ESXi 7.0 업데이트 3i | 2022년 12월 8일 | ISO 빌드 20842708 vCenter Server 7.0 업데이트 3i | 2022년 12월 8일| ISO 빌드 20845200 VMware NSX Advanced Load Balancer avi-21.1.4-9009 | 2022년 4월 7일

• 새로운 기능:

새로운 기능:

새 SecurityPolicy CRD: vSphere 7.0 업데이트 3i에는 SecurityPolicy CRD가 도입되어 사용자가 감독자의 포드 및 VM에 NSX 기반 보안 정책을 적용할 수 있습니다. 감독자 네임스페이스에 대한 CRD를 통해 Kubernetes 네트워크 정책을 확장하여 코드를 통해 "Kubernetes 네트워크 정책"을 구성할 수 있는 기능이 제공됩니다.

지원: kube-apiserver-authproxy-svc 서비스 및 시스템 포드에 사용되는 TLS 버전이 TLSv1.2로 업데이트되었습니다.

새로운 기능, 2022년 9월 13일

2022년 9월 13일 빌드 정보 ESXi 7.0 업데이트 3g | 2022년 9월 13일 | ISO 빌드 20328353 vCenter Server 7.0 업데이트 3h | 2022년 9월 13일 | ISO 빌드 20395099 VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 2022년 3월 29일

• 새로운 기능
• 해결된 문제

새로운 기능

• 없음. 이것은 단순히 버그 수정 릴리스입니다.

해결된 문제

이 패치는 업그레이드 후 vCenter Server를 버전 70u3f로 업그레이드하려고 할 때 WCP 서비스가 시작되지 않아 실패하는 문제를 해결합니다. 이 오류는 70u3d 이전 버전에서 vSphere with Tanzu를 활성화한 상태로 vCenter Server를 업그레이드하려고 시도할 때 발생합니다. vCenter Server를 70u3d 이전 버전에서 vCenter Server 70u3d로 업그레이드한 다음 vCenter Server 70u3f로 업그레이드하려고 하면 실패합니다.

해결된 문제에 대한 자세한 내용은 기술 자료 문서 89010을 참조하십시오.

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

2022년 7월 12일 빌드 정보 ESXi 7.0 업데이트 3f | 2022년 7월 12일 | ISO 빌드 20036589 vCenter Server 7.0 업데이트 3f | 2022년 7월 12일 | ISO 빌드 20051473 VMware NSX Advanced Load Balancer avi-20.1.7-9154 | 2022년 3월 29일

• 새로운 기능

새로운 기능

• 감독자 클러스터

  • VM 서비스에 대한 LoadBalancer IP 문자열 값 지원 - NSX-T에서 생성되고 태그가 지정된 IP 풀을 나타내거나 일치시키는 spec.LoadBalancerIP 값에 사용자가 문자열 값을 제공할 수 있습니다.

  • VM 서비스 VM 백업 및 복원 – VMware는 이제 vADP(vSphere Storage API for Data Protection)를 기반으로 Veeam 및 기타 백업 벤더를 지원하는 포괄적이고 완전히 문서화된 워크플로를 통해 온-프레미스 vSphere 및 VMware Cloud on AWS에서 VM 서비스 VM에 대한 백업 및 복원을 지원하여 VMware Cloud on AWS에서 VM 서비스의 일반 가용성 및 보다 완벽한 데이터 보호 솔루션을 보장합니다.

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

2022년 5월 12일 빌드 정보 ESXi 7.0 업데이트 3d | 2022년 3월 29일 | ISO 빌드 19482537 vCenter Server 7.0 업데이트 3e | 2022년 5월 12일 | ISO 빌드 19717403 VMware NSX Advanced Load Balancer 20.1.7-9154 | 2022년 3월 29일

• 새로운 기능
• 업그레이드 고려 사항

새로운 기능

• VM Operator 서비스를 통해 배포된 VM에 대한 네트워크 보안 정책 지원이 추가됨 - NSX-T 보안 정책은 태그를 기반으로 보안 그룹을 통해 생성할 수 있습니다. 이제 NSX-T 기반 보안 정책을 생성하고 NSX-T 태그를 기반으로 VM Operator를 통해 배포된 VM에 적용할 수 있습니다.

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

업그레이드 고려 사항

vCenter Server를 7.0 업데이트 3c 이전 버전에서 업그레이드했고 감독자 클러스터가 Kubernetes 1.19.x에 있는 경우 tkg-controller-manager 포드는 CrashLoopBackOff 상태가 되고 게스트 클러스터를 관리할 수 없게 됩니다. 다음과 유사한 오류가 표시됩니다.

패닉이 발견됨: 잘못된 메모리 주소 또는 nil 포인터 역참조

해결 방법: 이 문제에 대해 알아보고 해결하려면 기술 자료 문서 88443을 읽어보십시오.

새로운 기능, 2022년 3월 29일

2022년 3월 29일 빌드 정보 ESXi 7.0 업데이트 3d | 2022년 3월 29일 | ISO 빌드 19482537 vCenter Server 7.0 업데이트 3d | 2022년 3월 29일| ISO 빌드 19480866 VMware NSX Advanced Load Balancer 20.1.7-9154 | 2022년 3월 29일

• 새로운 기능
• 해결된 문제

새로운 기능

• 없음. 이것은 단순히 버그 수정 릴리스입니다.

해결된 문제

• vTPM 호스트에서 Spherelet VIB 설치 실패

  • vTPM 호스트에서 '신뢰할 수 있는 서명자를 찾을 수 없음: 자체 서명된 인증서' 오류와 함께 Spherelet VIB 설치가 실패합니다.

• vSphere 업그레이드하면 감독자 클러스터가 불안정해짐

  • vSphere를 7.0 업데이트 1에서 7.0 업데이트 2로 업그레이드하면 감독자 클러스터가 구성 중 상태로 전환됩니다.

• NSX-T Advanced Load Balancer를 사용할 때 감독자 클러스터 사용 설정이 일시 중지됨

  • NSX-T Advanced Load Balancer로 감독자 클러스터를 사용하도록 설정하면 기본 인증 구성에 따라 구성이 일시 중지될 수 있습니다.

새로운 기능, 2021년 10월 21일

2021년 10월 21일 빌드 정보 ESXi 7.0 업데이트 3 | 2022년 1월 27일 | ISO 빌드 19193900 vCenter Server 7.0 업데이트 3a | 2021년 10월 21일 | ISO 빌드 18778458 VMware NSX Advanced Load Balancer 20.1.7 | 2021년 10월 21일 | ISO 빌드 18778458

중요: 업그레이드에 영향을 미치는 문제로 인해 2021년 11월 19일에 모든 사이트에서 ESXi 7.0 업데이트 3, 7.0 업데이트 3a 및 7.0 업데이트 3b가 제거되었습니다. ESXi 7.0 업데이트 3c ISO용 빌드 19193900이 빌드 18644231을 대체합니다. 자세한 내용은 VMware ESXi 7.0 업데이트 3c 릴리스 정보를 참조하십시오.

• 새로운 기능

새로운 기능

• Tanzu Kubernetes Grid Service for vSphere

  • 컨테이너화된 워크로드가 Tanzu Kubernetes 클러스터에서 GPU 가속화를 활용하도록 지원 - 이제 vSphere 관리자는 GPU 가속 VM을 Tanzu Kubernetes 클러스터에 프로비저닝할 수 있고 개발자는 네이티브 Kubernetes 명령을 사용하여 GPU 가속 VM을 Tanzu Kubernetes Grid 클러스터에 추가할 수 있습니다.

  • Ubuntu 20.04 기반 TKr(Tanzu Kubernetes 릴리스) - Ubuntu 20.04에 기반한 첫 번째 TKr 릴리스입니다. 이 이미지는 특히 GPU(AI/ML) 워크로드용으로 최적화되고 테스트되었습니다. 자세한 내용은 TKr 릴리스 정보를 참조하십시오.

새로운 기능, 2021년 10월 5일

2021년 9월 28일 빌드 정보 ESXi 7.0 업데이트 3 | 2022년 1월 27일 | ISO 빌드 19193900 vCenter Server 7.0 업데이트 3 | 2021년 10월 5일 | ISO 빌드 18700403 VMware NSX Advanced Load Balancer 20.1.6 | 2021년 10월 5일 | ISO 빌드 18700403

중요: 업그레이드에 영향을 미치는 문제로 인해 2021년 11월 19일에 모든 사이트에서 ESXi 7.0 업데이트 3, 7.0 업데이트 3a 및 7.0 업데이트 3b가 제거되었습니다. ESXi 7.0 업데이트 3c ISO용 빌드 19193900이 빌드 18644231을 대체합니다. 자세한 내용은 VMware ESXi 7.0 업데이트 3c 릴리스 정보를 참조하십시오.

• 새로운 기능

새로운 기능

• 감독자 클러스터

  • vSphere 서비스 - vSphere 서비스 프레임워크를 사용하면 이제 vSphere 관리자가 MinIO, Cloudian Hyperstore, Dell ObjectScale, Velero를 비롯한 감독자 서비스를 비동기식으로 관리할 수 있습니다. 감독자 서비스의 분리된 특성으로 인해 관리자가 vCenter Server 릴리스 외부의 서비스 카탈로그에 새 서비스를 추가하여 DevOps 커뮤니티의 역량을 강화할 수 있습니다. 감독자 서비스는 NSX-T Data Center 네트워킹으로 구성된 감독자 클러스터에서만 사용할 수 있습니다. 설명서에서 vSphere Client의 감독자 서비스 관리에 대한 자세한 내용을 확인하십시오.

  • VM 서비스에서 vGPU 지원 - vSphere 관리자는 Kubernetes를 사용하는 VM을 통해 VM 클래스를 통해 적용되는 제한에 따라 GPU를 사용할 수 있도록 개발자에게 셀프 서비스 액세스를 제공할 수 있습니다. 그러면 DevOps 사용자는 미리 정의된 VM 클래스 및 이미지를 사용하여 GPU가 포함된 VM을 빠르게 생성할 수 있습니다.

  • DHCP 네트워킹으로 워크로드 관리 사용 - 이 릴리스는 DHCP 네트워크를 대체 네트워크 설정 경로로 추가하여 더 빠른 POC를 위한 사용 설정을 간소화합니다. vSphere 관리자는 네트워크 및 포트 그룹을 선택하기만 하면 DHCP를 통해 관리 네트워크 및 워크로드 네트워크를 구성할 수 있으며 DNS, NTP 및 부동 IP를 포함한 다른 모든 입력은 DHCP를 사용하여 자동으로 획득됩니다.

  • 사용 설정 중 네트워크 및 로드 밸런서 상태 점검 - 사용하도록 설정하는 동안 네트워크 연결, DNS, NTP 및 로드 밸런서 연결에 대한 상태 점검을 통해 감독자 클러스터 사용 설정의 성공 여부가 검증되며, 일반적인 문제를 진단하고 조치를 취하는 데 도움이 되도록 사람이 읽을 수 있는 오류 메시지가 제공됩니다. 오류 메시지 해결에 대한 추가 지침은 설명서를 참조하십시오.

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

  • 감독자 네임스페이스에 대한 레이블 및 주석 - 네임스페이스 셀프 서비스 템플릿을 통해 DevOps 사용자가 생성한 네임스페이스에 이제 Kubernetes 레이블 및 주석이 포함될 수 있습니다.

  • 사용 설정 후 감독자 클러스터 구성 편집 - vSphere 네트워킹 스택으로 감독자 클러스터를 사용하도록 설정하면 이제 vSphere 관리자가 API 및 vSphere Client 둘 다에서 다음 설정을 편집할 수 있습니다. 로드 밸런서 사용자 이름 및 암호, 관리 네트워크 DNS 검색 도메인, 워크로드 네트워크 DNS 서버 및 NTP 서버. 서비스 IP 범위를 확장하고 새 워크로드 네트워크를 추가합니다. vSphere 또는 NSX-T 네트워킹을 사용하는 클러스터의 경우 사용 설정 후 제어부 크기를 스케일 업할 수 있습니다. 클러스터의 규모를 늘릴 수만 있으며 현재 축소는 지원되지 않습니다. vSphere Client를 통해 감독자 클러스터 설정을 변경하는 방법에 대한 자세한 내용은 설명서를 참조하십시오.

  • Tanzu 라이센스 키 만료 - 이제 vSphere 관리자는 만료된 Tanzu Edition 라이센스 키를 더 유연하게 관리할 수 있습니다. Tanzu 라이센스 키가 만료되면 하드 적용이 자동으로 수행되지 않으므로 관리자는 정상적인 작업에 영향을 주지 않으면서 새 라이센스 키를 보다 유연하게 확보하고 할당할 수 있습니다.

• Tanzu Kubernetes Grid Service for vSphere

  • vSAN 영구 볼륨에 대한 RWX 지원 - Tanzu Kubernetes 클러스터에서 실행되는 워크로드는 이제 RWX를 사용하여 vSAN 기반 영구 볼륨을 마운트할 수 있습니다.

  • Tanzu Kubernetes Grid Service v1alpha2 API 업데이트 - Tanzu Kubernetes 클러스터 API에 대한 API 업데이트는 여러 작업자 노드 풀에 대한 지원을 포함하여 Tanzu Kubernetes Grid Service의 향상된 구성을 허용하는 새 필드를 제공합니다. v1alpha1 API 대신 새로운 v1alpha2 API가 사용됩니다. 자세한 내용은 설명서를 참조하십시오.

  • 메트릭 서버 - 이제 1.20.9 이상 및 1.21 Tanzu Kubernetes 릴리스를 시작으로 Tanzu Kubernetes 클러스터에 메트릭 서버가 기본적으로 포함됩니다.

  • No-NAT(라우팅된) 토폴로지를 지원하는 기능 - 이제 클러스터 노드를 클러스터 네트워크 외부로 라우팅할 수 있는 네트워킹 토폴로지를 사용하여 Tanzu Kubernetes 클러스터를 생성할 수 있습니다. 자세한 내용은 설명서를 참조하십시오.

새로운 기능, 2021년 8월 24일

2021년 8월 24일 빌드 정보 ESXi 7.0 업데이트 2c | 2021년 8월 24일 | ISO 빌드 18426014 vCenter Server 7.0 업데이트 2c | 2021년 8월 24일 | ISO 빌드 18356314 VMware NSX Advanced Load Balancer 20.1.5 | 2021년 8월 24일| ISO 빌드 18379150

• 새로운 기능

새로운 기능

• 감독자 클러스터

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

  • vSphere Pod를 위한 vSphere용 Velero 플러그인 지원 - 이 릴리스는 vSphere Pod의 백업 및 복원을 위해 Velero 1.5.1 및 vSphere 1.1.0 이상용 Velero 플러그인을 지원합니다.

• Tanzu Kubernetes Grid Service for vSphere

  • Harbor 및 external-dns가 새로운 클러스터 내 확장으로 지원됨 - 이제 플랫폼 운영자가 지원되는 두 가지 추가 클러스터 내 확장인 Harbor 및 external-dns에 액세스할 수 있습니다. Harbor는 CNCF 등급 컨테이너 레지스트리이며 external-dns는 Kubernetes 로드 밸런싱된 서비스를 기반으로 DNS 레코드를 동적으로 구성하는 데 널리 사용되는 도구입니다.

  • 제어부 노드의 업데이트 적용 기능 향상 - 이제 Tanzu Kubernetes 클러스터에서 공통 제어부 노드 장애에 자동으로 업데이트가 적용되어 보다 강력한 Kubernetes 런타임을 제공합니다.

  • Tanzu Kubernetes 클러스터 워크로드를 위한 vSphere용 Velero 플러그인 지원 - 이 릴리스는 Tanzu Kubernetes 클러스터에서 실행되는 워크로드의 백업 및 복원을 위해 Velero 1.5.1 이상 및 vSphere 1.1.0 이상용 Velero 플러그인을 지원합니다.

  • Tanzu Kubernetes 클러스터 워크로드를 위한 독립형 Velero 지원 - 이 릴리스에서는 Restic이 있는 독립형 Velero를 사용하여 Tanzu Kubernetes 클러스터 워크로드를 백업 및 복원할 수 있도록 Velero 1.6을 지원합니다.

새로운 기능, 2021년 4월 27일

2021년 4월 27일 빌드 정보 ESXi 7.0 | 2021년 3월 9일 | ISO 빌드 17630552 vCenter Server 7.0 | 2021년 4월 27일 | ISO 빌드 17920168

• 새로운 기능

새로운 기능

• 감독자 클러스터

  • 가상 시스템 서비스를 통해 Kubernetes를 사용하여 VM 관리. 이 릴리스에서는 vSphere with Tanzu에 포함된 인프라 서비스에 가상 시스템 서비스를 추가하여 개발자를 위한 Kubernetes 네이티브 VM 관리를 제공합니다. 개발자는 VM 서비스를 통해 Kubernetes 명령을 사용하여 네임스페이스에서 VM을 배포하고 관리할 수 있습니다. 동시에, vSphere 관리자는 리소스 소비 및 서비스의 가용성을 관리하면서 개발자에게 클라우드 네이티브 환경을 제공할 수 있습니다.

  • 개발자를 위한 네임스페이스 셀프 서비스 생성. 이제 vSphere 관리자가 감독자 네임스페이스를 셀프 서비스 네임스페이스 템플릿으로 생성하고 구성할 수 있습니다. 이 템플릿은 사용량에 대한 리소스 제한 및 사용 권한을 정의합니다. 그러면 개발자는 이 템플릿을 사용하여 네임스페이스를 프로비저닝하고 그 안에서 워크로드를 실행할 수 있습니다. 요청하고 승인을 기다릴 필요가 없습니다.

• Tanzu Kubernetes Grid Service for vSphere

  • 중요: TKR에 대한 CVE 수정: CVE-2021-30465를 해결하는 데 사용 가능한 새로운 Tanzu Kubernetes 릴리스가 있습니다.

  • 중요: Contour 수신 확장에 대한 CVE 수정: CVE-2021-28682, CVE-2021-28683 및 CVE-2021-29258을 해결하기 위한 새로운 Envoy 이미지 버전이 있습니다. 자세한 내용은 관련 KB 문서를 참조하십시오.

  • 기본 VM 클래스 사용을 위한 새 워크플로. 기본 VM 클래스를 사용하여 Tanzu Kubernetes 클러스터를 프로비저닝하는 새로운 워크플로가 있습니다. 새 클러스터를 생성하기 전에 클러스터를 프로비저닝하는 vSphere 네임스페이스에 기본 VM 클래스를 추가하십시오. 지침은 설명을 참조하십시오.

  • 시스템 변형 Webhook이 모의 실행 모드를 지원함. 이제 사용자가 Terraform Kubernetes 제공자와 같은 인기 있는 도구를 Tanzu Kubernetes Grid 서비스와 통합할 수 있습니다. 이전에는 시스템 Webhook이 Terraform 'plan' 명령의 요구 사항인 모의 실행 모드를 지원하지 않았습니다.

  • 사용자 지정 VM 클래스. Tanzu Kubernetes 클러스터는 VM 서비스를 통해 사용자 지정 가상 시스템 클래스를 사용할 수 있습니다. 이를 통해 사용자는 Tanzu Kubernetes 클러스터를 구성하는 가상 시스템에 할당되는 다양한 양의 CPU 및 메모리를 구성할 수 있습니다.

새로운 기능, 2021년 3월 9일

2021년 3월 9일 빌드 정보 ESXi 7.0 | 2020년 3월 9일 | ISO 빌드 17630552 vCenter Server 7.0 | 2021년 3월 9일 | ISO 빌드 17694817 VMware NSX Advanced Load Balancer | 2020년 10월 12일 | 20.1.X

• 새로운 기능
• Tanzu Kubernetes 클러스터에 대한 업데이트 고려 사항
• 해결된 문제

새로운 기능

• 감독자 클러스터

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

  • Kubernetes 1.16을 실행하는 감독자 클러스터의 자동 업그레이드를 통해 감독자 클러스터를 Kubernetes 1.19로 업그레이드. 감독자 클러스터를 Kubernetes 1.19로 업그레이드할 수 있습니다. 이 업데이트에서는 다음과 같은 감독자 클러스터 버전이 지원됩니다. 1.19, 1.18 및 1.17. Kubernetes 1.16을 실행하는 감독자 클러스터는 vCenter Server가 업데이트되면 1.17로 자동 업그레이드됩니다. 이렇게 하면 모든 감독자 클러스터가 지원되는 Kubernetes 버전으로 실행됩니다.

  • PVC(영구 볼륨 할당) 확장. 이제 볼륨이 활성 상태인 경우에도 PersistentVolumeClaim 개체를 수정하여 기존 볼륨을 확장할 수 있습니다. 감독자 클러스터 및 Tanzu Kubernetes 클러스터의 볼륨에 적용됩니다.

  • vSphere Lifecycle Manager를 사용하여 감독자 클러스터 수명 주기 관리. NSX-T 네트워킹으로 구성된 감독자 클러스터의 경우 인프라 구성 및 수명 주기 관리에 vSphere Lifecycle Manager를 사용할 수 있습니다.

• Tanzu Kubernetes Grid Service for vSphere

  • 개인 컨테이너 레지스트리 지원 – 개인 컨테이너 레지스트리를 신뢰하기 위해 Tanzu Kubernetes 클러스터에서 사용할 추가 CA(인증 기관) 인증서를 이제 vSphere 관리자 및 Kubernetes 플랫폼 운영자가 정의할 수 있습니다. 이 기능을 사용하면 Tanzu Kubernetes 클러스터가 엔터프라이즈 또는 자체 서명된 인증서가 있는 컨테이너 레지스트리에서 컨테이너 이미지를 끌어올 수 있습니다. 감독자 클러스터 전체에서 또는 Tanzu Kubernetes 클러스터별로 개인 CA를 Tanzu Kubernetes 클러스터의 기본값으로 구성할 수 있습니다. Tanzu Kubernetes 클러스터에 대한 개인 컨테이너 레지스트리 지원을 구성하는 방법에 대한 자세한 내용은 설명서를 참조하십시오.

  • NSX-T 및 NSX Advanced Load Balancer를 사용한 서비스 유형: LoadBalancer에 대한 사용자 정의 IP. 서비스에 대한 정적 IP 끝점을 허용하는 서비스 유형: LoadBalancer를 구성할 때 Kubernetes 애플리케이션 운영자가 사용자 정의 LoadBalancerIP를 제공할 수 있습니다. 이러한 고급 기능에는 감독자 클러스터를 통한 NSX Advanced Load Balancer 또는 NSX-T 밸런싱이 필요합니다. 이 기능을 구성하는 방법은 설명서 페이지에서 확인하십시오.

  • NSX-T를 사용한 서비스 유형: LoadBalancer에 대한 ExternalTrafficPolicy 및 LoadBalancerSourceRanges - Kubernetes 애플리케이션 운영자는 클라이언트 IP 주소를 엔드 포드에 전파하도록 서비스에 대한 ExternalTrafficPolicy를 'local'로 구성할 수 있습니다. 서비스에 대한 loadBalancerSourceRanges를 정의하여 로드 밸런싱된 서비스에 액세스할 수 있는 클라이언트 IP를 제한할 수도 있습니다. 이러한 두 가지 고급 기능을 사용하려면 감독자 클러스터를 통한 NSX-T 로드 밸런싱이 필요합니다.

  • Kubernetes 버전 관리 및 표시. kubectl을 사용하여 TanzuKubernetesReleases와 기본 감독자 클러스터 환경의 호환성을 검사할 수 있습니다. Tanzu Kubernetes 클러스터에 사용 가능한 Kubernetes 업그레이드가 있는지 여부가 표시되고 다음으로 사용할 TanzuKubernetesRelease가 권장됩니다. 새로운 기능을 사용하는 방법에 대한 자세한 내용은 설명서 페이지를 참조하십시오.

  • 클러스터 상태 한눈에 보기. 이전 릴리스에서 VMware는 일반적인 문제와 오류를 표시하는 조건부 상태 보고를 구현하여 WCPCluster 및 WCPMachine CRD를 확장했습니다. vSphere 7.0 업데이트 2 릴리스에서는 TanzuKubernetesCluster CRD 기능이 향상되어 하위 시스템 구성 요소에 대한 조건부 상태 보고가 요약되고 문제를 조사하는 데 도움이 되는 즉각적인 답변과 세분화된 지침이 제공됩니다. 이 기능을 구성하는 방법은 설명서 페이지에서 확인하십시오.

  • Tanzu Kubernetes 클러스터별 HTTP 프록시 구성. HTTP/HTTPS 프록시 구성을 Tanzu Kubernetes 클러스터별로 정의하거나, 기본 구성을 통해 관리자 클러스터 전체에서 정의할 수 있습니다. 이 기능을 구성하는 방법에 대한 자세한 내용은 설명서 페이지를 참조하십시오.

  • Tanzu Kubernetes Grid 확장 지원. 이제 클러스터 내 확장이 Fluent Bit, Contour, Prometheus, AlertManager, Grafana를 포함한 Tanzu Kubernetes Grid Service에서 완전히 지원됩니다.

Tanzu Kubernetes 클러스터에 대한 업데이트 고려 사항

vSphere 7.0 업데이트 2 릴리스에는 vCenter Server가 업데이트될 때 감독자 클러스터를 자동으로 업그레이드하는 기능이 포함되어 있습니다. 환경에 프로비저닝된 Tanzu Kubernetes 클러스터가 있는 경우, vCenter Server 7.0 업데이트 2로 업그레이드하기 전에 기술 자료 문서 82592를 참조하십시오. 이 문서에는 감독자 클러스터가 자동으로 업그레이드된 후 Tanzu Kubernetes 클러스터가 비호환 상태가 될지 여부를 판단하기 위해 사전 확인을 실행하는 방법에 대한 지침이 제공됩니다.

해결된 문제

• 내장형 컨테이너 레지스트리 SSL 인증서가 Tanzu Kubernetes 클러스터 노드에 복사되지 않음

  • 내장형 컨테이너 레지스트리가 감독자 클러스터에 대해 사용되도록 설정되고 SC에서 생성된 Tanzu Kubernetes 클러스터 노드에 Harbor SSL 인증서가 포함되지 않으면 해당 노드의 레지스트리에 연결할 수 없습니다.

• Tanzu Kubernetes Grid 1.16.8에서 1.17.4로 업그레이드한 후 제어부 노드 중 하나의 "guest-cluster-auth-svc" 포드가 "컨테이너 생성" 상태로 중단됨

  • Tanzu Kubernetes 클러스터를 Tanzu Kubernetes Grid Service 1.16.8에서 1.17.4로 업데이트한 후 클러스터 제어부 노드 중 하나의 "guest-cluster-auth-svc" 포드가 "컨테이너 생성" 상태로 중단됩니다.

• 클러스터 업데이트를 수행하는 동안 또는 수행한 후에 사용자가 Tanzu Kubernetes 클러스터의 기존 포드를 관리할 수 없음

  • 클러스터 업데이트를 수행하는 동안 또는 수행한 후에 사용자가 Tanzu Kubernetes 클러스터의 기존 포드를 관리할 수 없음

• Tanzu Kubernetes 클러스터 업그레이드 작업이 실패하고 "etcd 상태 점검 통과를 기다리는 중 시간 초과됨"이 표시됨

  • Tanzu Kubernetes 클러스터 업그레이드와 연관된 vmware-system-tkg 네임스페이스 업그레이드 작업이 실패하고 다음 오류 메시지가 표시됩니다. "etcd 상태 점검 통과를 기다리는 중 시간 초과됨" 이 문제는 etcd 포드에 누락된 PodIP 주소로 인해 발생합니다.

• 현재 TKC 버전에서는 Antrea CNI가 지원되지 않음

  • Tanzu Kubernetes 클러스터를 프로비저닝하는 동안 "현재 TKC 버전에서는 Antrea CNI가 지원되지 않음" 오류 메시지가 표시됩니다.

    옵션 1(권장): Antrea(v1.17.8 이상)를 지원하는 OVA 버전을 사용하도록 Tanzu Kubernetes 클러스터를 업데이트합니다.

    옵션 2: Tanzu Kubernetes 클러스터 규격 YAML의 spec.settings.network.cni 션에 "calico"를 입력합니다.

    옵션 3: 기본 CNI를 Calico로 변경합니다. 이 작업을 수행하는 방법에 대한 자세한 내용은 설명서의 항목을 참조하십시오.

새로운 기능, 2021년 2월 2일

2021년 2월 2일 빌드 정보 ESXi 7.0 | 2020년 12월 17일 | ISO 빌드 17325551 vCenter Server 7.0 | 2021년 2월 2일 | ISO 빌드 17491101

• 새로운 기능
• 해결된 문제

새로운 기능

• 감독자 클러스터

  • vSphere 네트워킹을 사용하는 감독자 클러스터 업데이트: 이제 vSphere 네트워킹을 사용하는 감독자 클러스터를 이전 버전의 Kubernetes에서 사용 가능한 최신 버전으로 업데이트할 수 있습니다. 새 감독자 클러스터 버전에서는 최신 Tanzu Kubernetes Grid Service 기능도 사용할 수 있습니다.

해결된 문제

• vSphere 네트워킹을 사용하는 기존의 감독자 클러스터에서 새 Tanzu Kubernetes Grid Service 기능을 사용할 수 없음

  • 이전 릴리스에서, 새 Tanzu Kubernetes Grid Service 기능과 버그 수정은 vSphere 네트워킹을 사용하는 새로 생성된 감독자 클러스터에서만 사용할 수 있었습니다. 이 릴리스에서 사용자는 이제 vSphere 네트워킹을 사용하는 감독자 클러스터를 업데이트하여 최신 Tanzu Kubernetes Grid Service 기능 및 버그 수정을 활용할 수 있습니다.

새로운 기능, 2020년 12월 17일

2020년 12월 17일 빌드 정보 ESXi 7.0 | 2020년 12월 17일 | ISO 빌드 17325551 vCenter Server 7.0 | 2020년 12월 17일 | ISO 빌드 17327517

참고: 이 릴리스의 새로운 Tanzu Kubernetes Grid 서비스 기능과 버그 수정을 활용하려면 vSphere 네트워킹이 사용되는 경우 새 감독자 클러스터를 생성해야 합니다.

• 새로운 기능
• 해결된 문제

새로운 기능

• 감독자 클러스터

  • 전용 T1 라우터를 통한 감독자 네임스페이스 분리. NSX-T 네트워크를 사용하는 감독자 클러스터는 각 네임스페이스에 자체 전용 T1 라우터가 있는 새 토폴로지를 사용합니다.

    • 새로 생성된 감독자 클러스터는 이러한 새 토폴로지를 자동으로 사용합니다.

    • 기존 감독자 클러스터는 업그레이드 중에 이러한 새 토폴로지로 마이그레이션됩니다.

  • 감독자 클러스터가 NSX-T 3.1.0 지원. 감독자 클러스터는 NSX-T 3.1.0과 호환됩니다.

  • 감독자 클러스터 버전 1.16.x 지원 제거. 이제 감독자 클러스터 버전 1.16.x가 제거되었습니다. 1.16.x를 실행하는 감독자 클러스터는 새 버전으로 업그레이드해야 합니다.

• Tanzu Kubernetes Grid Service for vSphere

  • HTTP/HTTPS 프록시 지원. 새로 생성된 Tanzu Kubernetes 클러스터는 송신 트래픽은 물론 인터넷 레지스트리에서 컨테이너 이미지를 가져오는 데 글로벌 HTTP/HTTPS 프록시를 사용할 수 있습니다.

  • 레지스트리 서비스와 통합. 새로 생성된 Tanzu Kubernetes 클러스터는 vSphere 레지스트리 서비스와 함께 즉시 작동합니다. 기존 클러스터도 새 버전으로 업데이트되면 레지스트리 서비스와 함께 작동합니다.

  • 구성 가능한 노드 스토리지. Tanzu Kubernetes 클러스터는 이제 가상 시스템에 추가 스토리지 볼륨을 마운트할 수 있으므로 사용 가능한 노드 스토리지 용량을 늘릴 수 있습니다. 이를 통해 사용자는 기본 16GB 루트 볼륨 크기를 초과할 수 있는 더 큰 컨테이너 이미지를 배포할 수 있습니다.

  • 향상된 상태 정보. WCPCluster 및 WCPMachine 사용자 지정 리소스 정의가 이제 조건부 상태 보고를 구현합니다. 성공적인Tanzu Kubernetes 클러스터 수명 주기 관리는 여러 하위 시스템(예: 감독자, 스토리지, 네트워킹)에 따라 달라지며 오류를 이해하기가 어려울 수 있습니다. 이제 WCPCluster 및 WCPMachine CRD에 일반적인 상태 및 실패 조건이 표시되어 쉽게 문제를 해결할 수 있습니다.

해결된 문제

• vCenter Server 7.0 업데이트 1에 도입된 새로운 기본 VM 클래스 누락

  • vSphere 7.0.1로 업그레이드한 후 감독자 클러스터의 vSphere 네임스페이스 업데이트를 수행하고, "kubectl get virtualmachineclasses" 명령을 실행하면 새 VM 클래스 크기(2배 대형, 4배 대형, 8배 대형)가 나열되지 않습니다. 이 문제가 해결되었으며 모든 감독자 클러스터가 올바른 기본 VM 클래스 집합으로 구성됩니다.

새로운 기능, 2020년 10월 6일

2020년 10월 6일 빌드 정보 ESXi 7.0 | 2020년 10월 6일 | ISO 빌드 16850804 vCenter Server 7.0 | 2020년 10월 6일 | ISO 빌드 16860138

• 새로운 기능
• 해결된 문제

새로운 기능

• 감독자 클러스터

  • vSphere 네트워킹을 사용하여 감독자 클러스터 구성. 감독자 클러스터를 위한 vSphere 네트워킹이 도입되어 기존 네트워크 인프라를 사용하여 개발자가 사용할 수 있는 플랫폼을 제공할 수 있습니다.

  • vSphere 네트워킹을 사용하여 감독자 클러스터를 설정하는 HAproxy 로드 밸런서 지원. vSphere 네트워킹으로 감독자 클러스터를 구성하는 경우 최신 워크로드를 처리하기 위해 로드 밸런서를 추가해야 합니다. HAproxy OVA를 사용하여 로드 밸런서를 배포하고 설정할 수 있습니다.

  • vSphere Lifecycle Manager를 사용하여 감독자 클러스터 수명 주기 관리. vSphere 네트워킹으로 구성된 감독자 클러스터의 경우 인프라 구성 및 수명 주기 관리를 위해 vSphere Lifecycle Manager를 사용할 수 있습니다.

  • 하드웨어에 vSphere with Tanzu를 사용해 볼 수 있는 기회. 하드웨어에서 감독자 클러스터를 사용하도록 설정하고 최신 애플리케이션 플랫폼을 추가 비용 없이 테스트하려는 경우 제품 내 평가판이 제공됩니다.

• Tanzu Kubernetes Grid Service for vSphere

  • DevOps 사용자에게 Kubernetes 버전 공개. 감독자 클러스터에 새로운 'TanzuKubernetesRelease' 사용자 지정 리소스 정의가 도입되었습니다. 이 사용자 지정 리소스 정의는 DevOps 사용자에게 자신의 Tanzu Kubernetes 클러스터에서 사용할 수 있는 Kubernetes 버전에 대한 자세한 정보를 제공합니다.

  • VMware Container Networking과 Kubernetes용 Antrea 통합. 상용 지원 버전 Antrea가 새로운 Tanzu Kubernetes 클러스터의 기본 CNI(Container Network Interface)로 통합되었습니다. Antrea는 Tanzu Kubernetes Grid 서비스에 대한 포괄적인 엔터프라이즈 네트워크 정책 기능 제품군을 제공합니다. 자세한 내용은 릴리스 공지를 참조하십시오. Antrea가 기본 CNI이지만 vSphere 관리자와 DevOps 사용자는 Calico를 Tanzu Kubernetes 클러스터의 CNI로 여전히 선택할 수 있습니다.

  • vSphere 네트워킹을 사용하는 감독자 클러스터 환경 지원. 이제 vSphere 네트워킹을 사용하는 감독자 클러스터 환경이 지원되기 때문에 기존 네트워크 인프라를 활용할 수 있습니다.

해결된 문제

• 나열 항목이 없습니다. 이 릴리스는 기능 릴리스입니다.

새로운 기능, 2020년 8월 25일

2020년 8월 25일 빌드 정보 ESXi 7.0 | 2020년 6월 23일 | ISO 빌드 16324942 vCenter Server 7.0 | 2020년 8월 25일 | ISO 빌드 16749653

• 새로운 기능
• 해결된 문제
• 새로운 기능, 2020년 7월 30일
• 새로운 기능, 2020년 6월 23일
• 새로운 기능, 2020년 5월 19일
• 초기 vSphere with Kubernetes 릴리스에 대한 빌드 정보

새로운 기능

• 없음. 이것은 단순히 버그 수정 릴리스입니다.

해결된 문제

• 7월 30일 패치로 업그레이드 시 CPU 활용률이 높음

  • vCenter Server를 7월 30일 패치로 업그레이드한 후 높은 CPU 활용도가 발생합니다. 이 문제는 이제 해결되었습니다.

• Windows 줄 끝이 있는 인증서로 인해 감독자 클러스터를 사용하도록 설정하지 못함

  • 인증서에 Windows 줄 끝이 있는 경우 감독자 클러스트를 사용하도록 설정하지 못할 수 있습니다. 이 문제는 이제 해결되었습니다.

새로운 기능, 2020년 7월 30일

2020년 7월 30일 빌드 정보 ESXi 7.0 | 2020년 6월 23일 | ISO 빌드 16324942 vCenter Server 7.0 | 2020년 7월 30일 | ISO 빌드 16620007

새로운 기능

• 감독자 클러스터: 새 버전의 Kubernetes, 사용자 지정 인증서 및 PNID 변경 지원

  • 감독자 클러스터에서 Kubernetes 1.18.2(1.16.7 및 1.17.4와 함께)가 지원됩니다.

  • 시스템 SSL 인증서를 사용자 지정 인증서로 교체하는 것이 지원됩니다.

  • vCenter Server에 감독자 클러스터가 있는 경우 vCenter PNID 업데이트가 지원됩니다.

• Tanzu Kubernetes Grid Service for vSphere 클러스터 축소, 네트워킹 및 스토리지에 대해 추가된 새로운 기능

  • 클러스터 축소 작업이 Tanzu Kubernetes Grid 서비스 클러스터에서 지원됩니다.

  • 수신 방화벽 규칙이 모든 Tanzu Kubernetes Grid 서비스 클러스터에 기본적으로 적용됩니다.

  • 새로운 버전의 Kubernetes가 비동기적으로 vSphere 패치에 정기적으로 전달됩니다. 현재 버전은 1.16.8, 1.16.12, 1.17.7, 1.17.8입니다.

• 네트워크 서비스: 새로운 버전의 NCP

  • SessionAffinity가 ClusterIP 서비스에서 지원됩니다.

  • IngressClass, PathType 및 와일드 카드 도메인이 Kubernetes 1.18에서 수신에 대해 지원됩니다.

  • 클라이언트 인증이 수신 컨트롤러에서 지원됩니다.

• 레지스트리 서비스: 새로운 버전의 Harbor

  • 레지스트리 서비스가 1.10.3으로 업그레이드되었습니다.

업그레이드 방법에 대한 정보와 지침은 vSphere with Tanzu 클러스터 업데이트 설명서를 참조하십시오.

해결된 문제

• Tanzu Kubernetes Grid 서비스 클러스터 NTP 동기화 문제

새로운 기능, 2020년 6월 23일

2020년 6월 23일 빌드 정보 ESXi 7.0 | 2020년 6월 23일 | ISO 빌드 16324942 vCenter Server 7.0 | 2020년 6월 23일 | ISO 빌드 16386292 Tanzu Kubernetes 클러스터 OVA: v1.16.8+vmware.1-tkg.3.60d2ffd

새로운 기능

• 없음. 이것은 단순히 버그 수정 릴리스입니다.

해결된 문제

• Tanzu Kubernetes Grid 서비스 클러스터 업그레이드 실패

  • "오류: 알 수 없는 이전 노드"로 인해 Tanzu Kubernetes Grid 서비스 클러스터 업그레이드가 실패할 수 있는 문제를 해결했습니다.

• 감독자 클러스터 업그레이드 실패

  • 내장된 Harbor가 실패 상태인 경우 감독자 클러스터 업데이트가 중단될 수 있는 문제를 해결했습니다.

새로운 기능, 2020년 5월 19일

2020년 5월 19일 빌드 정보 ESXi 7.0 | 2020년 4월 2일 | ISO 빌드 15843807 vCenter Server 7.0 | 2020년 5월 19일 | ISO 빌드 16189094 Tanzu Kubernetes 클러스터 OVA: v1.16.8+vmware.1-tkg.3.60d2ffd

새로운 기능

• Tanzu Kubernetes Grid Service for vSphere: 롤링 업그레이드 및 서비스 업그레이드

  • 이제 고객이 Tanzu Kubernetes Grid Service for vSphere의 작업자 노드 및 제어부 노드에서 롤링 업그레이드를 수행하고 pvCSI, Calico 및 authsvc 서비스를 업그레이드할 수 있습니다. 여기에는 이 서비스 매트릭스에 대한 업그레이드 호환성 및 사전 확인이 포함됩니다.

  • 롤링 업그레이드는 작업자 노드를 수직으로 확장하는 데 사용할 수 있습니다. 예를 들어 작업자 노드의 VM 클래스를 더 작거나 큰 크기로 변경할 수 있습니다.

• 감독자 클러스터: 새로운 버전의 Kubernetes, 업그레이드 지원됨

  • 감독자 클러스터는 Kubernetes 1.17.4를 지원합니다.

  • 감독자 클러스터는 Kubernetes 1.16.x에서 1.17.x로의 업그레이드를 지원합니다.

해결된 문제

• 삭제한 네임스페이스의 이름 충돌

  • 사용자가 vSphere 네임스페이스를 삭제했다가 동일한 이름으로 새 vSphere 네임스페이스를 생성하면 이름 충돌이 발생하여 Tanzu Kubernetes 클러스터를 생성할 수 없는 문제가 해결되었습니다.

• 배포 이름 관련 개선

  • OVF 버전 정보를 별도의 열로 이동하여, 실행 중인 Kubernetes 버전이 보다 명확해졌습니다.

초기 vSphere with Kubernetes 릴리스에 대한 빌드 정보

2020년 4월 2일 목요일 빌드 정보 ESXi 7.0 | 2020년 4월 2일 | ISO 빌드 15843807 vCenter Server 7.0 | 2020년 4월 2일 | ISO 빌드 15952498 Tanzu Kubernetes 클러스터 OVA: v1.16.8+vmware.1-tkg.3.60d2ffd

vSphere with Tanzu에 대해 알아보기

VMware는 vSphere with Tanzu에 대해 알아볼 수 있는 다양한 리소스를 제공합니다.

• vSphere with Tanzu 구성 및 관리를 읽어 vSphere with Tanzu를 구성, 관리 및 사용하는 방법을 알아봅니다. 이 가이드는 vSphere 시스템 관리자 및 DevOps 팀을 위해 설계되었으며 vSphere with Tanzu 아키텍처, 서비스, 라이센싱, 시스템 요구 사항, 설정 및 사용에 대한 세부 정보를 제공합니다.

• VMware 호환성 가이드를 사용하여 vSphere with Tanzu의 하드웨어 호환성 및 제품 상호 운용성에 대해 알아보십시오. vSphere with Tanzu에는 vSphere 7.0과 동일한 하드웨어 요구 사항이 있습니다. 또한 특정 구성에는 NSX-T Edge 가상 시스템을 사용해야 하며, 해당 VM에는 자체적으로 작은 CPU 호환성 하위 집합이 있습니다. 자세한 내용은 NSX-T Data Center 설치 가이드를 참조하십시오.

• vSphere with Tanzu에서 사용할 수 있는 언어는 vSphere 7.0 릴리스 정보의 국제화 섹션에서 확인하십시오. 이러한 언어는 VMware에서 vSphere에 대해 제공하는 언어와 동일합니다.

• vSphere with Tanzu 오픈 소스 구성 요소의 저작권 및 라이센스는 vSphere 7.0 릴리스 정보의 오픈 소스 섹션에서 확인하십시오. 또한 vSphere 7.0 릴리스 정보는 vSphere 오픈 소스 구성 요소를 다운로드할 수 있는 위치를 알려줍니다.

해결된 문제

• vCenter를 vCenter Server 7.0 업데이트 2c로 업그레이드한 후 네임스페이스 요약 페이지의 VM 서비스 카드가 사라짐

  vCenter를 vCenter Server 7.0 업데이트 2a에서 vCenter Server 7.0 업데이트 2c로 업그레이드한 후 업그레이드 전에 생성된 기존 네임스페이스의 [네임스페이스 요약] 보기 아래에 VM 클래스 및 컨텐츠 라이브러리 카드가 표시되지 않습니다. 이 문제는 vCenter Server 7.0 업데이트 2a 소스에만 해당되며 이전 버전(예: vCenter Server 7.0 업데이트 2)에서 업그레이드하는 데는 영향을 미치지 않습니다.

  영향을 받는 네임스페이스의 경우 감독자 클러스터를 업그레이드하면 [네임스페이스 요약] 보기에 카드가 복원됩니다.

• VM 서비스로 생성된 가상 시스템에 대한 특정 작업이 호환되지 않는 가상 시스템 하드웨어 버전으로 인해 실패할 수 있음

  OVF 이미지의 가상 시스템 하드웨어 버전이 작업을 지원하지 않으면 가상 시스템에 대한 작업이 실패합니다. 예를 들어 가상 하드웨어 버전이 vmx-11인 이미지의 경우 영구 볼륨을 연결하면 실패하고 다음 오류가 표시됩니다.

  Attach a virtual disk: The device or operation specified at index '-1' is not supported for the current virtual machine version 'vmx-11'. A minimum version of 'vmx-13' is required for this operation to succeed

  해결 방법: 없음

• 데몬 집합을 사용하는 경우, 감독자 클러스터 업그레이드 중에 추가로 vSphere 포드가 생성되고 보류 상태로 중단될 수 있음

  감독자 클러스터를 업그레이드하는 동안, 데몬 집합 컨트롤러가 감독자 제어부 노드마다 추가로 vSphere 포드를 생성합니다. 이 문제는 업스트림 Kubernetes 문제로 인해 발생합니다.

  해결 방법: vSphere 포드 규격에 NodeSelector/NodeAffinity를 추가합니다. 그러면 데몬 집합 컨트롤러가 포드 생성을 위한 제어부 노드를 건너뛸 수 있습니다.

• 포드 생성이 간헐적으로 실패함:

  일부 환경에서 다음 오류로 인해 포드 생성이 간헐적으로 실패하는 것으로 보고되었습니다. "이미지를 가져오지 못했습니다." 호스트에 경로 없음 오류로 인해 연결 시간이 초과되었습니다." 이 문제는 이미지 가져오기 요청 중 기본 3초 시간 초과로 인해 발생합니다.

  기본 시간 초과 값을 늘리려면 GSS에 문의하십시오.

• VC에 연결이 끊긴 호스트가 많으면 감독자 서비스가 충돌할 수 있음:

  사용자 이름 및 암호가 잘못되어 많은 호스트의 연결이 끊긴 환경에서는 감독자 서비스가 충돌하여 다시 나타나지 않을 수 있습니다.

  이 문제가 최신 릴리스에서 해결되었습니다.

• vCenter Server 7.0 업데이트 3에서 NSX-T Data Center를 사용하여 감독자 클러스터를 구성하지 못할 수 있음

  NSX-T Data Center를 사용하여 감독자 클러스터를 구성하면 ESXi 호스트에 spherelet VIB를 설치하지 못하고 다음 오류가 발생할 수 있습니다.

  Could not find a trusted signer: self signed certificate

  자체 서명된 Spherelet VIB는 vCenter Server 7.0 업데이트 3과 함께 번들로 제공됩니다. 하지만 vSphere 클러스터의 일부인 ESXi 호스트에서 보안 부팅을 사용하도록 설정하지 않았거나 클러스터에서 호스트의 vLCM(vSphere Life Cycle Manager)이 사용되도록 설정되어 있지 않으면 감독자 클러스터를 사용하도록 설정하는 작업이 성공합니다. 이제 이 문제가 최신 릴리스에서 해결되었습니다.

• WCP 서비스가 시작되지 않아서 vCenter를 70u3f로 업그레이드하지 못했습니다.

  기술 자료 문서 89010을 참조하십시오.

  이 해결 방법은 실패 상태의 vCenter Server 7.0u3f 자체 또는 7.0u3f로 업그레이드를 시작하기 전인 vCenter Server 7.0u3d에 적용할 수 있습니다.

  1. 루트 자격 증명을 사용하여 vCenter Server SSH 세션에 연결합니다.

  2. 아래 명령을 사용하여 WCP 데이터베이스에 연결합니다.

  PGPASSFILE=/etc/vmware/wcp/.pgpass /opt/vmware/vpostgres/current/bin/psql -d VCDB -U wcpuser -h localhost

  3. 다음 명령을 실행하여 instance_id가 null인 항목을 확인합니다.

  SELECT cluster, instance_id FROM cluster_db_configs WHERE instance_id is NULL;

  4. cluster_db_configs의 instance_id를 null인 임의의 UUID로 업데이트합니다.

  UPDATE cluster_db_configs SET instance_id=gen_random_uuid() WHERE instance_id is NULL;

  5. DB 항목이 수정되면 WCP 서비스(및 업그레이드 후 시작되지 않은 다른 서비스)를 다시 시작해야 합니다.

  service-control --status --all

  service-control --restart --all (--stop or --start)

  또는

  service-control --restart wcp (--stop or --start)

  6. 2단계와 3단계를 다시 실행하여 instance_id가 NULL이 아닌지 확인합니다. 이제 vCenter Server가 실행되어야 합니다.

  7. 이 단계에서 사용자가 vCenter Server 70u3d에서 이 해결 방법을 적용했다면 vCenter Server 70u3f로 업그레이드를 진행하고 vCenter Server 70u3f에서 해결 방법을 적용했다면 VAMI(VMware Appliance Management Interface) 또는 CLI 설치 관리자를 방문하여 업그레이드를 재개합니다.

• 업그레이드 후 보안 정책 기능을 사용하지 못할 수 있음

  NSX-T 3.1.x/3.0.x가 있고 vCenter가 업그레이드된 후 감독자, 마지막으로 NSX-T가 3.2 이상으로 업그레이드된 경우 SecurityPolicy 기능을 사용하지 못할 수 있습니다. NCP가 NSX-T 업그레이드를 인식하지 못했기 때문입니다.

• 활성화된 LRO와 함께 Antrea-ENCAP를 사용하는 Tanzu Kubernetes Grid 클러스터 VM의 네트워크 처리량 성능 향상

  LRO를 사용하도록 설정된 Antrea-ENCAP를 사용하는 Tanzu Kubernetes Grid 클러스터의 네트워크 처리량 성능을 개선하기 위한 데이터 경로 최적화가 추가되었습니다.

  없음

• 감독자에서 내장된 Harbor 레지스트리를 사용하도록 설정하면 기본 구성이 안전하지 않게 될 수 있음

  "내장된 Harbor 레지스트리를 감독자 클러스터에서 사용하도록 설정합니다."에 설명된 단계를 완료한 경우 내장된 Harbor 레지스트리에 안전하지 않은 기본 구성이 있을 수 있습니다. 이 문제에 대한 자세한 내용은 VMware 기술 자료 문서 91452에서 확인할 수 있습니다.

  해결 방법: 이 문제는 이 릴리스를 설치하거나 KB 91452에 설명된 임시 해결 방법을 구현하여 해결할 수 있습니다.

알려진 문제

알려진 문제는 다음과 같이 그룹화되어 있습니다.

• 감독자 클러스터

• 네트워킹

• 스토리지

• VMware Tanzu Kubernetes Grid Service for vSphere

• vSAN 데이터 지속성 플랫폼

• VM 서비스

• 감독자 클러스터
• 네트워킹
• 스토리지
• VMware Tanzu Kubernetes Grid Service for vSphere
• vSAN 데이터 지속성 플랫폼
• VM 서비스

감독자 클러스터

• <span style="color:#FF0000">새 문제:</span> vSAN과 같은 공유 데이터스토어에서 여러 FCD 및 볼륨을 삭제하면 성능에 변화가 있을 수 있음

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

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

• 연결이 끊긴 ESXi 노드를 클러스터에서 이동해도 동일한 데이터 센터 아래에 있으면 노드에서 실행 중인 포드 및 PVC가 [종료 중] 상태로 유지됨

  PSOD로 인해 ESXi 호스트가 [응답 없음] 상태이고 이 호스트를 동일한 데이터 센터 아래에 있는 클러스터 외부로 이동하면 호스트에서 실행되는 포드 및 PVC가 [종료 중] 상태로 중단됩니다. 이 문제는 클러스터에서 예비 노드를 사용할 수 있는 경우에도 발생합니다.

  이 문제는 일반적으로 다음과 같은 경우에 발생합니다.

  1. 감독자 클러스터에서 파트너 서비스를 사용하도록 설정하고 서비스 인스턴스를 생성합니다.

  2. 서비스 인스턴스가 실행되는 ESXi 노드에 PSOD가 발생합니다.

  3. 응답하지 않는 호스트의 연결을 끊고 동일한 데이터 센터에 있는 클러스터 외부로 이동합니다.

     호스트가 클러스터 외부에 있으면 노드에 있는 포드 및 PVC가 [종료 중] 상태로 유지되는 것을 볼 수 있습니다.

  해결 방법: 호스트를 동일한 데이터 센터에 있는 클러스터 외부로 이동하는 대신 인벤토리에서 제거합니다.

• DRS가 수동 모드로 설정된 경우 감독자 클러스터에서 포드 생성이 종종 실패함

  워크로드 관리를 사용하도록 설정한 클러스터에는 HA 및 자동화된 DRS도 사용되도록 설정되어 있어야 합니다. HA 및 DRS가 사용되도록 설정되지 않았거나 DRS가 수동 모드에서 실행되는 클러스터에서 워크로드 관리를 사용하도록 설정하면 일관되지 않은 동작이 발생하고 포드 생성이 실패할 수 있습니다.

  해결 방법: 클러스터에서 DRS를 사용하도록 설정하고 DRS를 완전히 자동화 또는 부분적으로 자동화로 설정합니다. 또한 HA가 클러스터에서 사용되도록 설정되어 있는지도 확인합니다.

• 해당 스토리지 정책을 제거한 후에도 kubectl get sc를 실행할 때 스토리지 클래스가 표시됨

  스토리지 정책을 생성하고 네임스페이스에 정책을 추가한 다음 정책을 제거한 상태에서 kubectl get sc를 실행하는 경우 명령 응답으로 여전히 해당 스토리지 클래스가 나열됩니다.

  해결 방법: kubectl describe namespace를 실행하여 네임스페이스에 실제로 연결된 스토리지 클래스를 확인합니다.

• 감독자 클러스터에서 kubectl describe storage-class 또는 kubectl get storage-class를 실행하면 감독자 네임스페이스에 대한 스토리지 클래스뿐 아니라 모든 스토리지 클래스가 반환됨

  감독자 클러스터에서 kubectl describe storage-class 또는 kubectl get storage-class 명령을 실행하는 경우 감독자 네임스페이스에 대한 스토리지 클래스뿐 아니라 모든 스토리지 클래스가 반환됩니다.

  해결 방법: 할당량의 세부 정보 표시 이름에서 네임스페이스와 연결된 스토리지 클래스 이름을 유추합니다.

• FQDN이 구성된 경우에도 Kubernetes API 끝점 공유 버튼이 FQDN을 무시함

  FQDN이 감독자 클러스터 네임스페이스의 Kubernetes 제어부에 대해 구성된 경우에도 [네임스페이스 공유] 버튼은 FQDN 대신 IP 주소를 제공합니다.

  해결 방법: FQDN이 구성된 감독자 클러스터 네임스페이스를 수동으로 공유합니다.

• kubectl vSphere 로그인을 통해 로드 밸런서에 액세스할 수 없음

  로드 밸런싱된 끝점을 사용하는 경우 kubectl vSphere 로그인을 통해 API 서버에 액세스할 수 없습니다.

  해결 방법: 이 문제는 두 가지 형태로 나타날 수 있습니다.

  1. 제어부 <curl -k https://vip:6443(또는 443)>을 통해 API 서버에 액세스할 수 있는지 확인합니다.

     1. API 서버에서 로드 밸런서에 액세스할 수 없는 경우에는 해당 API 서버가 아직 작동하지 않습니다.

     2. 해결 방법: API 서버에 액세스할 수 있을 때까지 몇 분 정도 기다립니다.

  2. Edge 가상 시스템 노드 상태가 작동 중 상태인지 확인합니다.

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

     2. 시스템 > 패브릭 > 노드 > Edge 전송 노드로 이동합니다. 노드 상태가 작동 중 상태여야 합니다.

     3. 네트워킹 > 로드 밸런서 > 가상 서버로 이동합니다. kube-apiserver-lb-svc-6443 및 kube-apiserver-lb-svc-443으로 끝나는 VIP를 찾습니다. 작동 중 상태가 아니라면 다음 해결 방법을 사용합니다.

     4. 해결 방법: Edge VM을 재부팅합니다. 재부팅 후 Edge VM을 재구성해야 합니다.

• vSphere with Tanzu 클러스터 구성 중 시간 초과 오류가 표시됨

  클러스터를 구성하는 동안 다음 오류 메시지가 표시될 수 있습니다.

  Api request to param0 failed

  또는

  Config operation for param0 node VM timed out

  해결 방법: 없음. vSphere with Tanzu를 사용하도록 설정하는 데에는 30~60분이 걸릴 수 있습니다. 이러한 또는 유사한 param0 시간 초과 메시지가 표시되면 오류가 아니므로 무시해도 됩니다.

• vSphere with Tanzu에서 vSphere 서비스를 사용하지 않도록 설정했다가 바로 다시 사용하도록 설정하면 vCenter Server의 해당 네임스페이스가 응답하지 않게 됩니다.

  vSphere 서비스를 사용하지 않도록 설정했다가 바로 다시 사용하도록 설정하면 감독자 클러스터의 네임스페이스가 삭제되고 다시 생성됩니다. 하지만 vCenter Server의 해당 네임스페이스는 "종료 중" 상태로 유지됩니다. 그 결과, 리소스 할당량이 vCenter Server의 네임스페이스에 할당될 수 없으며 DevOps 엔지니어는 네임스페이스에 포드 및 PVC와 같은 리소스를 생성할 수 없습니다. 또한 서비스 운영자 포드를 실행할 수 없기 때문에 UI 플러그인 배포가 실패합니다.

  감독자 클러스터에서 kubectl -n vmware-system-appplatform-operator-system logs vmware-system-appplatform-operator-mgr-0 명령을 실행하여 앱 플랫폼 로그를 얻을 수 있습니다.

  해결 방법:

  서비스를 다시 사용하도록 설정하기 전에 vCenter Server에서 네임스페이스가 완전히 삭제될 때까지 기다립니다.

  네임스페이스가 종료 중 상태에서 멈추면 다음 단계를 수행합니다.

  1. 서비스를 다시 사용하지 않도록 설정합니다.

  2. vCenter Server에서 wcp 서비스를 다시 시작합니다.

  3. 네임스페이스가 삭제될 때까지 기다립니다. 이 단계에는 다소 시간이 걸릴 수 있습니다.

  4. 서비스를 다시 사용하도록 설정합니다.

• 오류로 인해 컨테이너 레지스트리를 사용하도록 설정하지 못함

  사용자가 UI에서 컨테이너 레지스트리를 사용하도록 설정하면 10분 후에 시간 초과 오류로 인해 사용 설정 작업이 실패합니다.

  해결 방법: 컨테이너 레지스트리를 사용하지 않도록 설정했다가 다시 사용하도록 설정해봅니다. 시간 초과 오류가 다시 발생할 수 있습니다.

• 클러스터를 사용하지 않도록 설정한 후 다시 사용하도록 설정을 시도하면 작업이 실패하고 오류가 발생함

  클러스터를 사용하지 않도록 설정한 직후 클러스터를 사용하도록 설정하면 서비스 계정 암호 재설정 프로세스에서 충돌이 발생할 수 있습니다. 사용 설정 작업이 실패하고 오류가 발생합니다.

  해결 방법: vmon-cli --restart wcp 명령으로 다시 시작합니다.

• 내장형 컨테이너 레지스트리에서 컨테이너 이미지 태그를 삭제하면 동일한 물리적 컨테이너 이미지를 공유하는 모든 이미지 태그가 삭제될 수 있음

  태그가 다른 여러 이미지를 동일한 컨테이너 이미지의 내장형 컨테이너 레지스트리에 있는 프로젝트로 푸시할 수 있습니다. 프로젝트의 이미지 중 하나가 삭제되면 동일한 이미지에서 푸시되는 서로 다른 태그를 가진 기타 모든 이미지가 삭제됩니다.

  해결 방법: 이 작업은 실행 취소할 수 없습니다. 이미지를 프로젝트로 다시 푸시합니다.

• 레지스트리 프로젝트에서 지우기 작업이 실패하면 프로젝트가 '오류' 상태가 됨

  레지스트리 프로젝트에서 지우기 작업을 수행할 때 프로젝트가 일시적으로 오류 상태로 표시됩니다. 이러한 프로젝트에서는 이미지를 푸시하거나 가져올 수 없습니다. 일정한 간격으로 프로젝트가 검사되고 오류 상태에 있는 모든 프로젝트는 삭제된 후 다시 생성됩니다. 이 경우 모든 이전 프로젝트 멤버가 다시 생성된 프로젝트에 다시 추가되고 이전에 프로젝트에 있던 모든 저장소와 이미지는 삭제되어 지우기 작업이 효과적으로 완료됩니다.

  해결 방법: 없음.

• 스토리지 용량이 2000메비바이트 미만인 경우 컨테이너 레지스트리 사용 설정이 실패함

  VMODL에서 "제한" 필드로 처리되는, 컨테이너 레지스트리에 대한 최소 총 스토리지 용량 요구 사항이 있습니다. 이는 일부 Kubernetes 포드가 제대로 작동하려면 충분한 스토리지 공간이 필요하기 때문입니다. 컨테이너 레지스트리 기능을 구현하기 위한 최소 용량은 5기가바이트입니다. 이 제한을 충족하더라도 성능이 향상된다거나 지원 가능한 이미지 수 또는 크기가 증가한다고 보장할 수는 없습니다.

  해결 방법: 이 문제는 총 용량이 더 큰 컨테이너 레지스트리를 배포하여 방지할 수 있습니다. 권장 스토리지 볼륨은 최소 5GB입니다.

• Kubernetes 클러스터에 대한 NSX 로드 밸런서의 TLS 인증서를 교체하는 경우 Docker 클라이언트 또는 Harbor UI에서 내장된 Harbor 레지스트리에 로그인하지 못할 수 있음

  Kubernetes 클러스터에 대한 NSX 로드 밸런서의 TLS 인증서를 교체하려면 vSphere UI에서 구성 > 네임스페이스 > 인증서 > NSX 로드 밸런서 > 작업으로 이동하고 인증서 바꾸기를 클릭합니다. NSX 인증서를 교체하면 Docker 클라이언트 또는 Harbor UI에서 내장된 Harbor 레지스트리에 대한 로그인 작업이 실패하고 unauthorized: authentication required 또는 Invalid user name or password 오류가 표시될 수 있습니다.

  해결 방법: vmware-system-registry 네임스페이스에서 레지스트리 에이전트 포드를 다시 시작합니다.

  1. kubectl get pod -n vmware-system-registry 명령을 실행합니다.

  2. kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry 명령을 실행하여 포드 출력을 삭제합니다.

  3. 포드가 다시 시작될 때까지 기다립니다.

• DNSDefault를 사용하여 배포된 포드에 clusterDNS 설정이 사용됨

  DNSDefault를 사용하는 감독자 클러스터에 배포된 vSphere 포드는 클러스터에 대해 구성된 clusterDNS를 사용하도록 대체됩니다.

  해결 방법: 없음.

• 감독자 클러스터를 업그레이드할 때 클러스터의 모든 호스트가 동시에 업데이트될 수 있음

  감독자 클러스터 업그레이드 프로세스 중에 클러스터의 모든 호스트가 병렬로 업데이트되는 경우가 있습니다. 그러면 이 클러스터에서 실행 중인 모든 포드에 다운타임이 발생합니다.

  해결 방법: 감독자 클러스터를 업그레이드할 때는 wcpsvc를 다시 시작하거나 호스트를 제거/추가하지 마십시오.

• VMCA가 중간 CA로 사용되면 감독자 클러스터 업그레이드가 무기한 멈출 수 있음

  VMCA를 중간 CA로 사용하는 경우 감독자 클러스터 업그레이드가 "구성 중" 상태로 무기한 중단될 수 있습니다.

  해결 방법: VMCA를 중간이 아닌 CA로 전환하고 "구성 중" 상태로 중지된 제어부 VM을 삭제합니다.

• 포드 사용 후 삭제 디스크에 대해 암호화가 사용되도록 설정된 스토리지 정책이 할당되면 vSphere 포드 배포가 실패함

  암호화가 사용되도록 설정된 스토리지 정책이 포드 사용 후 삭제 디스크에 사용되는 경우 vSphere 포드 생성이 "볼륨에 대해 AttachVolume.Attach가 실패함" 오류와 함께 실패합니다.

  해결 방법: 포드 사용 후 삭제 디스크에 대해 암호화가 없는 스토리지 정책을 사용합니다.

• 감독자 클러스터 업그레이드가 "네임스페이스 클러스터 업그레이드가 호스트 업그레이드 단계에 있습니다"가 표시되는 동안 50%에서 중단됨

  이 문제는 Kubernetes 제어부 노드를 업그레이드하는 동안 vSphere 포드가 "종료 중" 상태에서 중단되면 발생합니다. 제어부 노드의 컨트롤러는 Spherelet 프로세스를 업그레이드하려고 하며 이 단계 중에 vSphere 포드가 제어부 노드에서 제거되거나 종료되어 Kubernetes 제어부에서 노드가 등록 취소됩니다. 이런 이유 때문에 감독자 클러스터 업그레이드는 "종료 중" 상태의 vSphere 포드가 인벤토리에서 제거될 때까지 이전 버전에서 중단됩니다.

  해결 방법:

  1. vSphere 포드가 "종료 중" 상태로 중단된 ESXi 호스트에 로그인합니다.

  2. 다음 명령을 사용하여 "종료 중" vSphere 포드를 제거합니다.

  # vim-cmd vmsvc/getallvms

  # vim-cmd vmsvc/destroy

  이 단계가 끝나면 vSphere 포드는 vSphere Client에 분리된 상태로 표시됩니다.

  3. 먼저 사용자를 ServiceProviderUsers 그룹에 추가하여 분리된 vSphere 포드를 삭제합니다.

  a.) vSphere Client에 로그인하고 관리 -> 사용자 및 그룹 -> 사용자 생성을 선택한 후 그룹을 클릭합니다.

  b.) ServiceProviderUsers 또는 관리자 그룹을 검색하여 그룹에 사용자를 추가합니다.

  4. 방금 생성한 사용자를 사용하여 vSphere Client에 로그인하고 분리된 vSphere 포드를 삭제합니다.

  5. kubectl에서 다음 명령을 사용합니다.

  kubectl patch pod -p -n '{"metadata":{"finalizers":null}}'

• 워크로드 관리 UI에서 다음과 같은 라이센스 오류가 발생합니다. 이 vCenter에 연결된 호스트에는 워크로드 관리 라이센스가 없습니다.

  vSphere 클러스터에서 워크로드 관리를 사용하도록 설정한 후, 워크로드 관리를 사용하도록 설정한 vCenter Server를 재부팅하거나 ESXI 호스트를 업그레이드한 후 다음과 같은 라이센싱 오류가 표시될 수 있습니다. 이 vCenter에 연결된 호스트에는 워크로드 관리 라이센스가 없습니다. 이는 표면적인 UI 오류입니다. 라이센스가 여전히 유효하며 워크로드가 계속 실행되고 있습니다.

  해결 방법: 사용자는 vSphere Client에 대한 브라우저 캐시를 지워야 합니다.

• 대규모 vSphere 환경은 VMware NSX Advanced Load Balancer 컨트롤러를 사용하여 클라우드에서 동기화하는 데 시간이 오래 걸릴 수 있음

  2,000개가 넘는 ESXi 호스트와 45,000개가 넘는 가상 시스템이 포함된 인벤토리가 있는 vSphere 환경은 NSX Advanced Load Balancer 컨트롤러를 사용하여 클라우드에서 동기화하는 데 최대 2시간이 걸릴 수 있습니다.

  해결 방법: 없음

• vCenter Server 7.0 업데이트 2에서 VMCA(VMware 인증 기관) 루트 인증서가 변경된 후, 감독자 클러스터의 개인 컨테이너 레지스트리가 비정상 상태가 될 수 있음

  vCenter Server 시스템 7.0 업데이트 2에서 VMCA(VMware 인증 기관) 루트 인증서를 변경한 후, 감독자 클러스터의 개인 컨테이너 레지스트리가 비정상 상태가 되고 레지스트리 작업이 예상대로 작동하지 않을 수 있습니다. 컨테이너 레지스트리에 대한 다음과 같은 상태 메시지가 클러스터 구성 UI에 표시됩니다.

  Harbor registry harbor-1560339792 on cluster domain-c8 is unhealthy. Reason: failed to get harbor health: Get https://30.0.248.2/api/health: x509: certificate signed by unknown authority

  해결 방법:

  vSphere Kubernetes 클러스터의 vmware-system-registry 네임스페이스에서 레지스트리 에이전트 포드를 수동으로 다시 시작하십시오.

  1. kubectl get pod -n vmware-system-registry 명령을 실행하여 레지스트리 에이전트 포드를 가져옵니다.

  2. kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry 명령을 실행하여 포드 출력을 삭제합니다.

  3. 포드가 다시 시작될 때까지 기다립니다.

  4. 클러스터 구성 UI에서 이미지 레지스트리를 새로 고치면 상태가 곧 실행 중으로 표시됩니다.

• 감독자 클러스터에서 새로 생성된 네임스페이스에 대한 프로젝트가 개인 컨테이너 레지스트리에 자동으로 생성되지 않음

  감독자 클러스터의 새로 생성된 네임스페이스에 대한 개인 컨테이너 레지스트리에 프로젝트가 자동으로 생성되지 않을 수 있습니다. 컨테이너 레지스트리의 상태는 여전히 정상으로 표시되지만 새 네임스페이스가 생성될 때 클러스터의 컨테이너 레지스트리에 프로젝트가 표시되지 않습니다. 컨테이너 레지스트리에 있는 새 네임스페이스의 프로젝트로 이미지를 푸시하거나 끌어올 수 없습니다.

  해결 방법:

  1. kubectl get pod -n vmware-system-registry 명령을 실행하여 레지스트리 에이전트 포드를 가져옵니다.

  2. kubectl delete pod vmware-registry-controller-manager-xxxxxx -n vmware-system-registry 명령을 실행하여 포드 출력을 삭제합니다.

  3. 포드가 다시 시작될 때까지 기다립니다.

  4. 개인 컨테이너 레지스트리에 로그인하여 클러스터의 네임스페이스에 대해 프로젝트가 생성되었는지 확인합니다.

• 복제본 10개로 포드를 생성하는 동안 ErrImgPull이 표시될 수 있음

  이 문제는 YAML에서 복제 포드가 10개인 배포를 사용하려고 할 때 발생할 수 있습니다. 개인 컨테이너 레지스트리를 사용하여 이런 YAML로 생성하려고 하면 복제본 10개 중 최소 7개는 통과하고 3개는 "ErrImgPull" 문제로 인해 실패할 수 있습니다.

  해결 방법: 복제 집합을 더 적게(최대 5개) 사용합니다.

• vCenter Server가 사용자 지정 포트를 사용하여 배포된 경우 NSX Advanced Load Balancer 컨트롤러가 지원되지 않음

  NSX Advanced Load Balancer 컨트롤러에 vCenter Server를 등록할 수 없습니다. 등록하는 동안 NSX Advanced Load Balanced 컨트롤러 UI에서 사용자 지정 vCenter Server 포트를 제공하기 위한 옵션이 없기 때문입니다.

  NSX Advanced Load Balancer 컨트롤러는 vCenter Server가 기본 포트 80 및 443으로 배포된 경우에만 작동합니다.

• 실행 중인 감독자 클러스터가 이미 포함된 vCenter Server에서 도메인 연결 대상 변경을 수행하면 감독자 클러스터가 [구성 중] 상태가 됨

  감독자 클러스터가 있는 vCenter Server에서는 도메인 연결 대상 변경이 지원되지 않습니다. 도메인 연결 대상 변경을 수행하려고 하면 기존 감독자 클러스터가 [구성 중] 상태가 되고 제어부 VM 및 Tanzu Kubernetes 클러스터 VM이 [호스트 및 클러스터] 보기의 인벤토리에 더 이상 표시되지 않습니다.

  해결 방법: 없음

• 감독자 클러스터에서 Kubernetes를 사용하여 생성된 VM에는 태그 및 사용자 지정 특성 할당이 작동하지 않음

  vSphere UI 클라이언트를 통해 또는 vAPI를 사용하여 감독자 클러스터에서 생성된 VM에 태그 또는 사용자 지정 특성을 할당하려고 하면, 작업이 실패하고 "An error occurred while attaching tags" 메시지가 표시됩니다.

  해결 방법: 없음

• 셀프 서비스 네임스페이스에 대한 사용 권한이 있는 개발자가 스토리지 클래스와 같은 클러스터 범위의 리소스에 액세스할 수 없음

  개발자가 kubectl 명령을 사용하여 클러스터 범위 스토리지 클래스를 나열하려고 하면

  kubectl get storageclass -n test-ns or kubectl get storageclass

  다음과 같은 오류가 발생합니다.

  Error from server (Forbidden): storageclasses.storage.k8s.io is forbidden: User "<sso:DEVUSER@DOMAIN>" cannot list resource "storageclasses" in API group "storage.k8s.io" at the cluster scope

  해결 방법: 개발자는 액세스 권한이 있는 네임스페이스 템플릿에 할당된 스토리지 클래스에만 액세스할 수 있기 때문에 이것은 예상되는 동작입니다. 이 동작은 vSphere 관리자가 미리 결정합니다.

  아래 명령을 사용하여 네임스페이스와 연결된 스토리지 클래스를 나열합니다.

  kubectl get resourcequota <NAMESPACE>-storagequota -n <NAMESPACE>

• 셀프 서비스에 "kubectl apply -f" 사용 시 네임스페이스 실패

  매니페스트와 kubectl apply -f 명령을 사용하여 네임스페이스를 생성하려고 하면 오류와 함께 실패함

  Error from server (Forbidden): namespaces is forbidden: User "sso:[email protected]"cannot list resource "namespaces"inAPI group ""at the cluster scope

  해결 방법: 개발자는 kubectl create -f 명령을 대신 사용하여 네임스페이스를 생성할 수 있습니다.

• 셀프 서비스 네임스페이스에서 vSphere 포드 생성이 간헐적으로 실패함

  셀프 서비스 네임스페이스 템플릿을 사용하여 생성된 네임스페이스에서 vSphere 포드를 생성하려고 할 때 cannot "create resource pods" 오류가 발생할 수 있습니다.

  해결 방법: 네임스페이스 생성 후 몇 초 동안 기다렸다가 네임스페이스에 vSphere 포드를 생성합니다.

• 셀프 서비스 네임스페이스 템플릿을 사용하여 생성된 네임스페이스에 개발자가 레이블과 주석을 추가할 수 없음

  kubectl apply -f 명령을 사용하여 네임스페이스를 생성하거나 수정하는 데 사용되는 매니페스트에서 레이블 및 주석을 지정하려고 할 때 오류와 함께 실패함

  Error from server (Forbidden): User "sso:[email protected]"cannot patch resource "namespaces"inAPI group ""inthe namespace ""

  해결 방법: 네임스페이스 매니페스트에 필요한 레이블 및 주석을 추가하고 kubectl create -f 를 대신 사용하여 레이블과 주석을 추가합니다.

• 감독자 클러스터 업그레이드가 실행될 때 네임스페이스 템플릿을 사용할 수 없음

  감독자 클러스터 업그레이드를 시작하면 활성화, 비활성화 또는 업데이트와 같이 네임스페이스 템플릿과 관련된 모든 작업은 업그레이드가 완료될 때까지 대기열에 유지됩니다.

  해결 방법: 네임스페이스 템플릿을 조작하는 명령을 실행하기 전에 업그레이드 작업이 완료될 때까지 기다립니다.

• Tanzu Kubernetes 클러스터의 포드에 영구 볼륨을 연결하려고 시도하면 실패하고 "CNS: SCSI 컨트롤러가 없어 디스크를 연결하지 못함" 오류 메시지가 표시됨

  Tanzu Kubernetes 클러스터의 포드에 영구 볼륨을 연결하려고 하면 실패하고 포드가 보류 중 상태로 유지됩니다. 오류 메시지는 작업자 노드 VM에 PVSCSI 컨트롤러가 구성되어 있더라도 SCSI 컨트롤러가 누락되었음을 나타냅니다.

  이 문제는 작업자 노드 VM이 블록 볼륨 제한인 60개 볼륨에 도달하면 발생할 수 있습니다. 하지만, Kubernetes는 vSphere 볼륨 제한을 무시하고 해당 노드에서 블록 볼륨 생성을 스케줄링합니다.

  해결 방법: 작업자 노드를 클러스터에 추가합니다. 포드를 삭제하여 새 작업자 노드에 배포를 스케줄링합니다.

• 비활성 vCenter Server 세션 후 상태 저장 포드를 삭제하고 나중에 Tanzu Kubernetes 클러스터에서 해당 볼륨을 다시 사용하거나 삭제하려고 시도하면 작업이 실패하고 예측할 수 없는 동작이 발생할 수 있음

  비활성 상태가 되고 하루 정도 후에 상태 저장 포드를 삭제하면 해당 볼륨이 Tanzu Kubernetes 클러스터의 노드 VM에서 성공적으로 분리된 것으로 보입니다. 하지만, 해당 볼륨을 사용하여 새 상태 저장 포드를 생성하거나 볼륨을 삭제하려고 하면 작업이 실패합니다. 해당 볼륨이 vCenter Server의 노드 VM에 아직 연결되어 있기 때문입니다.

  해결 방법: CNS API를 사용하여 노드 VM에서 볼륨을 분리하여 Tanzu Kubernetes 클러스터와 vCenter Server의 볼륨 상태를 동기화합니다. 또한 감독자 클러스터에서 CSI 컨트롤러를 다시 시작하여 비활성 세션을 갱신합니다.

• 감독자 클러스터의 기본 워크로드 네트워크(vSphere 네트워킹을 사용하는 경우)/NCP 클러스터 네트워크 포드 CIDR(NSX-T Container Plug-in을 사용하는 경우)의 IP 범위 소진으로 인해 감독자 클러스터 업그레이드가 중단됨/완료되지 않음

  감독자 클러스터 업그레이드가 보류 중 상태에서 중단되고 다음 메시지가 표시됩니다. "네임스페이스 클러스터 업그레이드가 새 마스터 프로비저닝 단계에 있습니다."

  클러스터 업그레이드 중에 배포된 새로운 제어부 VM은 네트워크 인터페이스를 하나만 수신합니다. 제어부 VM에는 네트워크 인터페이스가 2개 있어야 합니다. 하나는 관리 네트워크에 연결되고 다른 하나는 워크로드 네트워크에 연결되어야 합니다.

  새 제어부 VM에 배포되어야 하는 coredns와 같은 특정 시스템 포드는 보류 중 상태에서 중단될 수 있습니다.

  해결 방법: 적은 수의 워크로드(VM, PodVM, TKG 클러스터)를 삭제하여 업그레이드 프로세스가 완료될 수 있도록 충분한 IP를 확보합니다. IP를 3개 이상 확보해야 합니다.

• 감독자 서비스 구성에 대한 키 값 쌍 또는 레지스트리 자격 증명 업데이트

  잘못된 로그인 자격 증명을 입력했거나 레지스트리 암호가 만료되었기 때문에 감독자 서비스의 구성 레지스트리 키-값 쌍을 변경해야 할 수 있습니다.

  해결 방법:

  1. 감독자 클러스터에 새 비밀 리소스를 생성합니다.

  kubectl -n vmware-system-supervisor-services create secret generic new-secret --from-literal=registryName= --from-literal=registryPasswd= --from-literal=registryUsername=

  2. 감독자 서비스 리소스에 대한 서비스 참조를 업데이트합니다.

  # kubectl edit supervisorservice svc-minio -n vmware-system-supervisor-services

  3. spec.config 세션을 업데이트합니다.

  spec:

  config:

  secretNamespace: vmware-system-supervisor-services

  secretRef: new-secret

• Tanzu Kubernetes Grid Service 및 감독자 서비스 UI 플러그인이 작동하지 않음

  vCenter Server가 사용자 지정 CA 인증서로 서명되고 감독자 클러스터가 사용되도록 설정되면 vSphere Client에 배포된 감독자 서비스 UI 플러그인 및 Tanzu Kubernetes Grid 서비스 UI 플러그인이 작동하지 않습니다. 감독자 클러스터에서 해당하는 백엔드 서버와 통신을 시도할 때 UI 플러그인에서 SSL 인증 문제가 발생합니다. Tanzu Kubernetes Grid Service 플러그인에 다음 오류가 표시됩니다.

  The Tanzu Kubernetes Grid Service failed to authenticate with kubernetes; see the browser console for more technical details

  해결 방법: /etc/ssl/certs의 별도의 파일(vmca.pem 아님)에 신뢰 루트를 추가하고 c_rehash를 사용하여 해시를 재생성합니다. 3개의 제어부 VM 모두에서 이 작업을 수행해야 합니다.

  /etc/ssl/certs/vmca.pem을 편집하는 것은 바람직하지 않습니다. 클러스터를 동기화할 때마다 이 파일의 내용을 update-controller가 덮어쓰기 때문입니다.

  감독자 클러스터의 제어부 VM 중 하나가 다시 배포되는 경우(예: 제어부 VM의 크기를 조정한 후 또는 복구 작업으로 인해) /etc/ssl/certs 에 수동으로 추가한 인증서가 손실되며 해결 방법은 해당 VM에 다시 적용하는 것입니다.

• 감독자 클러스터가 구성 중 상태에서 중단됨

  vSphere 클러스터를 감독자 클러스터로 구성한 후 클러스터가 구성 중 상태에서 중단됩니다. vSphere 포드 및 Tanzu Kubernetes 클러스터를 생성할 수 없습니다.

  해결 방법: 다음 명령을 사용하여 wcp 서비스를 다시 시작합니다.

  vmon-cli restart wcp

  자세한 지침은 설명서를 확인하십시오.

• 연결된 컨텐츠 라이브러리가 VM 이미지로 채워진 경우에도 "kubectl get virtualmachineimages"가 결과를 반환하지 않음

  VM 서비스에서 사용 중인 컨텐츠 라이브러리가 보안 정책과 함께 사용되도록 설정된 경우 VM 서비스가 이미지를 읽지 못하고 이 컨텐츠 라이브러리의 이미지를 사용하여 VM을 배포할 수 없습니다.

  해결 방법: 감독자 네임스페이스에서 보안 정책과 컨텐츠 라이브러리의 연결을 끊습니다. 관련 컨텐츠 라이브러리에서 "기본 OVF 보안 정책" 설정을 제거한 다음 컨텐츠 라이브러리와 네임스페이스를 다시 연결합니다.

• 호스트가 유지 보수 모드로 전환되면 개발자에게 VM 서비스에서 관리하는 패스스루 디바이스 및 vGPU가 있는 VM에 대해 잘못된 POWERSTATE가 표시됩니다.

  호스트가 유지 보수 모드로 전환되면 VM 서비스에서 관리하는 vGPU 및 패스스루 디바이스가 있는 VM의 전원이 DRS에 의해 자동으로 꺼집니다. 하지만 kubectl get vm의 출력에는 이전 전원 상태 및 VM이 표시됩니다. 그래서 vCenter에서 VM의 전원이 꺼진 경우에도 POWERSTATE=poweredOn이 표시됩니다.

  없음.

• NSX-T가 설정된 감독자 클러스터에서 ESXi 호스트가 자체 서명된 Spherelet VIB를 계속 사용할 수 있음

  vCenter Server 7.0 업데이트 3에서 사용할 수 있는 Kubernetes 버전으로 감독자 클러스터를 구성하거나 업그레이드하고 감독자 클러스터의 Kubernetes 버전을 vCenter Server 7.0 업데이트 3a에서 사용 가능한 버전으로 추가 업그레이드한 경우 ESXi 호스트는 자체 서명된 Spherelet VIB를 계속 사용할 수 있습니다. 이 문제는 vCenter Server 7.0 업데이트 3 및 vCenter Server 7.0 업데이트 3a에 설치된 자체 서명된 Spherelet VIB 버전이 동일하기 때문에 발생합니다. 이 문제는 vSphere 네트워킹 스택으로 구성된 감독자 클러스터에는 적용되지 않습니다.

  해결 방법 1:

  vSphere 클러스터가 vSphere Lifecycle Manager를 기반으로 하지 않는 경우 아래 단계를 수행하여 VMware 인증 Spherelet VIB를 설치합니다.

  1. ESXi 호스트를 유지 보수 모드로 전환하고 감독자 클러스터에서 "준비되지 않음"으로 표시될 때까지 기다립니다.

  2. 해당 호스트를 클러스터 외부에 독립형 호스트로 이동하고 spherelet 및 NSX-T VIB가 제거될 때까지 기다립니다.

  3. 동일한 호스트를 클러스터로 다시 이동하고 유지 보수 모드를 종료한 후 새 spherelet 및 NSX-T VIB가 다시 구성될 때까지 기다립니다.

  4. 클러스터 내의 각 ESXi 호스트에 대해 위 단계를 반복합니다.

  vSphere Lifecycle Manager에서 감독자 클러스터를 사용하도록 설정된 경우 감독자 클러스터를 비활성화하고 다시 구성합니다.

  해결 방법 2:

  vCenter Server가 vCenter Server 7.0 업데이트 3a로 업그레이드되면 감독자 클러스터를 비활성화하고 다시 구성합니다. 이것은 vSphere Lifecycle Manager를 사용하도록 설정된 클러스터와 vLCM/VUM 기반이 아닌 클러스터 모두에 적용됩니다.

• 호스트 재부팅 또는 감독자 클러스터 업그레이드 후 일부 vSphere 포드에 NodeAffinity 상태가 표시됨

  호스트를 재부팅하거나 감독자 클러스터를 업그레이드한 후 일부 vSphere 포드에 대해 NodeAffinity 상태가 표시될 수 있습니다. 이 동작은 Kubernetes 스케줄러가 kubelet 다시 시작 후 클러스터에서 NodeAffinity 상태의 중복 포드를 생성하는 업스트림 Kubernetes의 문제로 인해 발생합니다. 이 문제는 클러스터 기능에 영향을 주지 않습니다. 업스트림 Kubernetes 문제에 대한 자세한 내용은 https://github.com/kubernetes/kubernetes/issues/92067을 읽어보십시오.

  해결 방법: NodeAffinity 상태의 중복 포드를 삭제합니다.

• 환경을 7.0 업데이트 3e 이상으로 업그레이드한 후 vSphere with Tanzu에서 사용하도록 설정된 vDPp 서비스 운영자 및 인스턴스 포드가 보류 중 상태로 전환됨

  이 문제는 감독자 클러스터에 설치된 파트너 서비스의 버전이 Kubernetes 버전 1.22를 지원하지 않는 경우에 발생합니다. vSphere with Tanzu 환경을 1.22 규정 준수 버전 7.0 업데이트 3e 이상으로 업그레이드하면 서비스가 호환되지 않습니다. 그 결과 운영자 및 인스턴스 포드가 보류 중 상태가 됩니다.

  서비스를 최신 버전으로 업그레이드하려는 시도가 실패합니다.

  해결 방법: vSphere with Tanzu를 7.0 업데이트 3e로 업그레이드하기 전에 vDPp 서비스를 Kubernetes 1.22와 호환되는 버전으로 업그레이드합니다.

• Kubernetes 1.19.1에서 1.20.8로의 클러스터 자동 업그레이드가 진행되지 않음

  드문 경우지만 클러스터를 Kubernetes 1.19.1에서 1.20.8로 자동 업그레이드하면 다음 오류가 표시되면서 실패할 수 있습니다.

  업그레이드 작업을 찾을 수 없습니다. 업그레이드를 다시 트리거하십시오.

  해결 방법: 클러스터 업그레이드를 수동으로 시작합니다.

• 감독자 네임스페이스가 짧은 시간 내에 재사용된 경우 작업이 실패할 수 있음:

  감독자 네임스페이스를 삭제했다가 짧은 시간 내에 동일한 이름으로 다시 생성하면 캐시 항목이 잘못되어 작업이 실패할 수 있습니다.

  이 문제는 최신 릴리스에서 해결되었습니다.

• 감독자 지원 번들에 VC 지원 번들 포함:

  감독자 지원 번들을 생성하면 VC 지원 번들이 자동으로 포함되지 않았습니다.

  최신 버전에서 해결되었습니다.

• 네트워크 지원 검사 목록의 컨텐츠가 현지화되지 않음

  워크로드 관리를 사용하도록 설정하는 동안 네트워크 검사 목록 시트를 다운로드할 수 있습니다. 시트에 현지화가 적용되지 않았습니다.

  최신 릴리스에서 해결되었습니다.

• 확장된 Tanzu Kubernetes 클러스터 설정에서 WCP 시스템 포드 capi-kubeadm-control-plane-controller-manager에서 OOM 문제가 발생함

  KB 문서에 설명되어 있음

  https://kb.vmware.com/s/article/88914

  KB 문서 참조

• TKG 또는 capw 업그레이드 실패로 인해 감독자 클러스터 업그레이드가 구성 요소 업그레이드 단계에서 중단됨

  KB 문서에 설명되어 있음

  https://kb.vmware.com/s/article/88854

• 보안 정책이 업데이트된 규칙을 제거하지 않음

  규칙 A와 B를 포함하는 보안 정책 CR이 생성되고 규칙을 B와 C로 변경하는 정책이 업데이트되는 경우 규칙 A는 여전히 작동합니다.

  해결 방법: 보안 정책을 삭제하고 업데이트된 규칙으로 다시 생성합니다.

• NSX Advanced Load Balancer에 두 개의 SE 그룹이 있는 경우 LoadBalancer 및 Tanzu Kubernetes 클러스터가 생성되지 않음

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

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

  그 결과 새 로드 밸런서를 사용할 수 없으며 새 워크로드 클러스터를 성공적으로 생성할 수 없습니다.

  자세한 내용은 VMware 기술 자료 문서 90386을 참조하십시오.

  해결 방법: VirtualService 생성에는 SEGroup 'Default-Group'만 사용해야 합니다. NSX Advanced Load Balancer에서 default-group을 제외한 다른 모든 SE 그룹을 삭제하고 작업을 다시 시도합니다.

• 업데이트된 보안 정책이 적용되지 않음

  규칙 A와 B가 포함된 보안 정책 CR을 생성한 후 업데이트하여 규칙을 B와 C로 변경해도 규칙 A가 계속 적용되고 제거되지 않습니다.

  해결 방법: 규칙 B와 C를 포함하는 새 정책을 생성하여 적용하고 A와 B가 포함된 이전 정책은 삭제합니다.

• 네임스페이스 관리 API가 경우에 따라 HTTP 500 오류를 반환하여 요청을 인증하지 못할 수 있음

  워크로드 관리 요청이 간헐적으로 실패할 수 있습니다. API가 500 상태 코드와 함께 반환되고 요청이 처리되지 않습니다. 인증하는 동안 예기치 않은 오류가 발생했다는 로그 메시지가 표시됩니다. 이 문제는 간헐적으로 발생하지만 하나 이상의 감독자를 적극적으로 구성하는 경우와 같이 워크로드 관리 로드가 진행되고 있을 때 발생할 가능성이 높습니다.

  해결 방법: 오류가 발생했을 때 시도한 작업을 다시 시도합니다.

• 간헐적으로 감독자 클러스터가 구성 중 또는 오류 상태로 유지될 수 있음

  감독자 클러스터의 사용 설정, 업그레이드 또는 기타 노드 재배포 중에 구성 중 또는 오류 상태로 남아있고 다음 오류 메시지가 표시될 수 있습니다.

  "VMware vCenter Server(vpxd)에 대한 API 요청이 실패했습니다. 세부 정보: 'ServerFaultCode: 일반 시스템 오류가 발생했습니다. vix 오류 코드 = (1, 0)"이 중단될 수 있습니다."

  관련 로그는 다음에서 찾을 수 있습니다. /var/log/vmware/wcp/wcpsvc.log

  노드를 강제로 다시 배포하는 데 문제가 발생한 제어부 VM에 해당하는 vSphere Agent Manager(EAM)를 삭제합니다.

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

  PVC(영구 볼륨 할당)를 삭제한 후 해당 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를 삭제하기 전에 클러스터의 다른 리소스에서 사용되고 있지 않은지 확인합니다.

네트워킹

• 저속 네트워크에서 NSX Edge 가상 시스템 배포가 실패함

  NSX Edge OVF 배포 및 NSX Edge VM 등록에는 총 60분의 시간 초과가 있습니다. 저속 스토리지가 포함된 저속 네트워크 또는 환경에서 Edge 배포 및 등록에 경과된 시간이 이 60분을 초과하면 작업이 실패합니다.

  해결 방법: Edge를 정리하고 배포를 다시 시작합니다.

• 클러스터 구성 후 vCenter Server DNS, NTP 또는 Syslog 설정이 변경되면 NSX Edge가 업데이트되지 않음

  DNS, NTP 및 Syslog 설정은 클러스터 구성 중에 vCenter Server에서 NSX Edge 가상 시스템으로 복사됩니다. 이러한 vCenter Server 설정이 구성 후 변경되면 NSX Edge가 업데이트되지 않습니다.

  해결 방법: NSX Manager API를 사용하여 NSX Edge의 DNS, NTP 및 Syslog 설정을 업데이트 합니다.

• NSX Edge 관리 네트워크 구성은 선택된 포트 그룹의 서브넷 및 게이트웨이 구성만 제공합니다.

  NSX Edge 관리 네트워크 호환성 드롭다운 목록에는 선택한 VDS의 DVPG에 의해 백업되는 ESXi VMKnic이 호스트에 구성되어 있는 경우에만 서브넷 및 게이트웨이 정보가 표시됩니다. VMKnic이 연결되어 있지 않은 분산 포트 그룹을 선택하는 경우 네트워크 구성을 위해 서브넷 및 게이트웨이를 제공해야 합니다.

  해결 방법: 다음 구성 중 하나를 사용합니다.

  • 개별 포트 그룹: 이것은 현재 VMK가 상주하지 않는 포트 그룹입니다. 이 포트 그룹에 대해 적절한 서브넷 및 게이트웨이 정보를 제공해야 합니다.

  • 공유 관리 포트 그룹: 이것은 ESXi 호스트의 관리 VMK가 상주하는 포트 그룹입니다. 서브넷 및 게이트웨이 정보를 자동으로 끌어옵니다.

• 클러스터 구성 중에 VLAN 0을 사용할 수 없음

  오버레이 터널 끝점 또는 업링크 구성에 VLAN 0을 사용하려고 하면 작업이 실패하고 다음 메시지가 표시됩니다.

  Argument 'uplink_network vlan' is not a valid VLAN ID for an uplink network. Please use a VLAN ID between 1-4094

  해결 방법: 다음 프로세스 중 하나를 사용하여 수동으로 VLAN 0 지원을 사용하도록 설정합니다.

  1. SSH를 사용하여 배포된 VC(root/vmware)에 로그인합니다.

  2. /etc/vmware/wcp/nsxdsvc.yaml을 엽니다. 다음과 유사한 컨텐츠가 표시됩니다.

  logging: 
    level: debug
    maxsizemb: 10 

  a. NSX 클러스터 오버레이 네트워크에 대해 VLAN0 지원을 사용하도록 설정하려면 다음 줄을 /etc/vmware/wcp/nsxdsvc.yaml에 추가하고 파일을 저장합니다.

  experimental:
   supportedvlan: 
    hostoverlay: 
      min: 0 
      max: 4094 
    edgeoverlay: 
      min: 1 
      max: 4094 
    edgeuplink: 
      min: 1 
      max: 4094 

  b. NSX Edge 오버레이 네트워크에 대해 VLAN0 지원을 사용하도록 설정하려면 다음 줄을 /etc/vmware/wcp/nsxdsvc.yaml에 추가하고 파일을 저장합니다.

  experimental: 
   supportedvlan: 
    hostoverlay: 
      min: 1 
      max: 4094 
    edgeoverlay: 
      min: 0 
      max: 4094 
    edgeuplink: 
      min: 1 
      max: 4094 

  c. NSX Edge 업링크 네트워크에 대해 VLAN0 지원을 사용하도록 설정하려면 다음 줄을 /etc/vmware/wcp/nsxdsvc.yaml에 추가하고 파일을 저장합니다.

  experimental: 
   supportedvlan: 
    hostoverlay: 
      min: 1 
      max: 4094 
    edgeoverlay: 
      min: 1 
      max: 4094 
    edgeuplink: 
      min: 0 
      max: 4094 

  3. vmon-cli --restart wcp를 사용하여 워크로드 관리 서비스를 다시 시작합니다.

• vSphere Lifecycle Manager 이미지가 사용되도록 설정된 클러스터에서 vSphere with Tanzu 및 NSX-T를 사용하도록 설정할 수 없음

  vSphere with Tanzu 및 NSX-T는 vSphere Lifecycle Manager 이미지와 호환되지 않으며 vSphere Lifecycle Manager 기준선과만 호환됩니다. 클러스터에서 vSphere Lifecycle Manager 이미지를 사용하도록 설정한 경우 해당 클러스터에서vSphere with Tanzu 또는 NSX-T를 사용하도록 설정할 수 없습니다.

  해결 방법: vSphere Lifecycle Manager 이미지가 사용되지 않도록 설정된 클러스터로 호스트를 이동합니다. vSphere Lifecycle Manager 기준선이 있는 클러스터를 사용해야 합니다. 호스트가 이동했다면 해당 새 클러스터에서 NSX-T를 사용하도록 설정한 다음 vSphere with Tanzu를 사용하도록 설정할 수 있습니다.

• NSX-T를 사용하여 vSphere with Tanzu 네트워킹을 구성한 경우 "ExternalTrafficPolicy: local"이 지원되지 않음

  LoadBalancer 유형의 Kubernetes 서비스의 경우 "ExternalTrafficPolicy: local" 구성이 지원되지 않습니다.

  해결 방법: 없음.

• NSX-T를 사용하여 vSphere with Tanzu 네트워킹을 구성한 경우 Tanzu Kuberetes 클러스터에서 지원할 수 있는 LoadBalancer 유형의 서비스 수는 감독자 클러스터의 NodePort 범위에 의해 제한됩니다.

  LoadBalancer 유형의 각 VirtualMachineService는 LoadBalancer 유형의 Kubernetes 서비스 하나와 Kubernetes 끝점 하나로 변환됩니다. 감독자 클러스터에서 생성할 수 있는 LoadBalancer 유형의 Kubernetes 서비스의 최대 수는 2767입니다. 여기에는 감독자 클러스터 자체에 생성된 서비스와 Tanzu Kubernetes 클러스터에서 생성된 서비스가 포함됩니다.

  해결 방법: 없음.

• NSX Advanced Load Balancer 컨트롤러가 vCenter Server PNID 변경을 지원하지 않음

  NSX Advanced Load Balancer를 사용하여 감독자 클러스터를 구성한 후에는 vCenter Server PNID를 변경할 수 없습니다.

  해결 방법: vCenter Server의 PNID를 변경해야 하는 경우에는 NSX Advanced Load Balancer 컨트롤러를 제거하고 vCenter Server PNID에 대해 변경한 다음, vCenter Server의 새 PNID를 사용하여 NSX Advanced Load Balancer 컨트롤러를 다시 배포하고 구성합니다.

• vDS(vSphere Distributed Switch) 환경에서는 감독자 클러스터와 겹치거나 충돌하는 네트워크 CIDR 범위를 사용하여 Tanzu Kubernetes 클러스터를 구성하거나 그 반대로 할 수 있지만 이로 인해 구성 요소가 통신할 수 없게 됩니다.

  vDS 환경에서는 감독자 클러스터에 대한 CIDR 범위를 구성하거나 Tanzu Kubernetes 클러스터에 대한 CIDR 범위를 구성할 때 설계 시 네트워크 검증이 수행되지 않습니다. 그 결과 다음과 같은 두 가지 문제가 발생할 수 있습니다.

  1) Tanzu Kubernetes 클러스터에 예약된 기본 CIDR 범위와 충돌하는 CIDR 범위를 사용하여 감독자 클러스터를 생성합니다.

  2) 감독자 클러스터에 사용되는 CIDR 범위와 겹치는 사용자 지정 CIDR 범위를 사용하여 Tanzu Kubernetes 클러스터를 생성합니다.

  해결 방법: vDS 환경의 경우, 감독자 클러스터를 구성할 때 Tanzu Kubernetes 클러스터에 사용되는 기본 CIDR 범위를 사용하지 마십시오. 192.168.0.0/16는 서비스에 대해 예약되고, 10.96.0.0/12는 포드에 대해 예약됩니다. 자세한 내용은 vSphere with Tanzu 설명서의 "Tanzu Kubernetes 클러스터의 구성 매개 변수"도 참조하십시오.

  vDS 환경의 경우, Tanzu Kubernetes 클러스터를 생성할 때 감독자 클러스터에 사용되는 것과 동일한 CIDR 범위를 사용하지 마십시오.

• 18개가 넘는 사용자 지정 레이블이 연결된 경우 게스트 클러스터 가상 네트워크 생성이 실패함

  사용자가 네임스페이스에서 게스트 클러스터 및 VirtualMachines를 생성하려는 경우 네임스페이스에 대해 최대 18개의 사용자 지정 레이블을 추가할 수 있습니다. 그렇지 않으면 네임스페이스에서 게스트 클러스터에 대한 가상 네트워크를 성공적으로 생성할 수 없습니다.

  네임스페이스에서 레이블을 제거하여 총 개수가 18개 이하가 되도록 합니다. NCP 재시도 메커니즘이 재시도되고 네임스페이스가 생성되지만 간격에 따라 최대 6시간이 소요될 수 있습니다.

• WCP에 대한 정책 API를 통해 생성된 전송 영역 지원:

  정책 API를 통해 NSX 전송 영역이 생성된 경우 감독자 사용 설정이 실패했을 수 있습니다. 이제 정책 API를 통해 NSX 전송 영역을 생성하는 동시에 MP API로 생성된 NSX 전송 영역의 이전 버전과의 호환성을 유지하도록 지원됩니다.

  최신 릴리스에서 해결되었습니다.

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

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

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

스토리지

• <span style="color:#FF0000">새 문제:</span> vSAN Direct 데이터스토어에서 디스크 제거 작업을 실행하려고 시도하면 실패하고 VimFault - 작업을 완료할 수 없음 오류가 표시됨

  일반적으로 다음 시나리오 중 하나가 발생할 때 이 오류를 볼 수 있습니다.

  • 디스크 제거 작업의 일환으로 vSAN Direct 데이터스토어에 배치된 모든 영구 볼륨은 동일한 ESXi 호스트의 다른 vSAN Direct 데이터스토어로 재배치됩니다. 대상 vSAN Direct 데이터스토어에 사용 가능한 공간이 없으면 재배치가 실패할 수 있습니다. 이러한 실패를 방지하려면 대상 vSAN Direct 데이터스토어에 애플리케이션을 실행하기에 충분한 스토리지 공간이 있는지 확인하십시오.

  • 디스크 제거 작업은 ESXi 호스트의 대상 vSAN Direct 데이터스토어에 충분한 스토리지가 있을 때도 실패할 수 있습니다. 이 문제는 디스크 제거 상위 작업에 의해 생성된 기본 영구 볼륨 재배치 작업이 볼륨 크기로 인해 30분 넘게 걸리는 경우 발생할 수 있습니다. 이런 경우 작업 보기에서 기본 vSphere 포드에 대한 재구성이 계속 진행 중인 것을 볼 수 있습니다.

    진행 중 상태는 디스크 제거 작업이 시간 초과되어 실패하더라도 vSphere 포드 재구성에 의해 수행된 기본 영구 볼륨 재배치가 중단되지 않음을 의미합니다.

  해결 방법:

  vSphere 포드에 대한 재구성 작업이 완료된 후 디스크 제거 작업을 다시 실행하십시오. 디스크 제거 작업이 성공적으로 진행됩니다.

• 오프라인 또는 온라인 모드에서 감독자 클러스터 PVC를 확장해도 해당 Tanzu Kubernetes 클러스터 PVC가 확장되지 않음

  Tanzu Kubernetes 클러스터 PVC를 사용하는 포드는 파일 시스템의 크기가 조정되지 않았기 때문에 감독자 클러스터 PVC의 확장된 용량을 사용할 수 없습니다.

  해결 방법: Tanzu Kubernetes 클러스터 PVC의 크기를 감독자 클러스터 PVC의 크기보다 크거나 같은 크기로 조정합니다.

• 정적으로 프로비저닝된 TKG PVC의 크기가 기본 볼륨과 비교할 때 불일치함

  Kubernetes의 정적 프로비저닝은 PV 및 백업 볼륨 크기가 동일한지 여부를 확인하지 않습니다. Tanzu Kubernetes 클러스터에 PVC를 정적으로 생성하고 PVC 크기가 해당하는 기본 감독자 클러스터 PVC의 크기보다 작으면, PV에 요청한 공간보다 더 많은 공간을 사용할 수 있습니다. Tanzu Kubernetes 클러스터에서 정적으로 생성한 PVC의 크기가 기본 감독자 클러스터 PVC의 크기보다 크면, Tanzu Kubernetes 클러스터 PV에서 요청된 크기를 소진하기 전이라도 No space left on device 오류가 발생할 수 있습니다.

  해결 방법:

  1. Tanzu Kubernetes 클러스터 PV에서 persistentVolumeReclaimPolicy를 Retain으로 변경합니다.

  2. Tanzu Kubernetes 클러스터 PV의 volumeHandle을 기록한 다음 Tanzu Kubernetes 클러스터에서 PVC 및 PV를 삭제합니다.

  3. volumeHandle을 사용하여 Tanzu Kubernetes 클러스터 PVC 및 PVC를 정적으로 다시 생성하고 스토리지를 해당 감독자 클러스터 PVC의 크기와 동일한 크기로 설정합니다.

• 외부 csi.vsphere.vmware.com 프로비저너가 리더 선택에 대한 리스를 잃을 경우 감독자 네임스페이스 또는 TKG 클러스터에서 PVC를 생성하려는 시도가 실패함

  kubectl 명령을 사용하여 감독자 네임스페이스 또는 TKG 클러스터에서 PVC를 생성하려는 시도가 성공하지 않을 수 있습니다. PVC는 보류 중 상태로 남습니다. PVC를 설명하는 경우 이벤트 필드에 테이블 레이아웃으로 다음 정보가 표시됩니다.

  • 유형 – Normal

  • 이유 – ExternalProvisioning

  • 경과한 시간 – 56s (x121 over 30m)

  • 발생 위치 - persistentvolume-controller

  • 메시지 – waiting for a volume to be created, either by external provisioner "csi.vsphere.vmware.com" or manually created by system administrator

  해결 방법:

  1. vmware-system-csi 네임스페이스 내 vsphere-csi-controller 포드의 모든 컨테이너가 실행 중인지 확인합니다.

     kubectl describe pod vsphere-csi-controller-pod-name -n vmware-system-csi

  2. 다음 명령을 사용하여 외부 프로비저너 로그를 확인합니다.

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

     다음 항목은 외부 프로비저너 사이드카 컨테이너가 해당 리더 선택을 잃었음을 나타냅니다.

     I0817 14:02:59.582663 1 leaderelection.go:263] failed to renew lease vmware-system-csi/csi-vsphere-vmware-com: failed to tryAcquireOrRenew context deadline exceededF0817 14:02:59.685847 1 leader_election.go:169] stopped leading

  3. 이 vsphere-csi-controller 인스턴스를 삭제합니다.

     kubectl delete pod vsphere-csi-controller-pod-name -n vmware-system-csi

  Kubernetes는 CSI 컨트롤러의 새 인스턴스를 생성하고 모든 사이드카 다시 초기화됩니다.

• CSI가 vCenter Server에 연결할 수 없는 동안 볼륨 생성, 연결, 분리 또는 삭제와 같은 모든 PVC 작업이 실패함

  작업 실패 외에도 감독자 클러스터에서 볼륨 상태 정보 및 스토리지 풀 CR을 업데이트할 수 없습니다. CSI 및 Syncer 로그에 vCenter Server에 연결할 수 없다는 오류가 표시됩니다.

  CSI는 특정 솔루션 사용자로 vCenter Server에 연결합니다. 이 SSO 사용자의 암호는 wcpsvc에 의해 24시간마다 한 번씩 순환되며 새 암호는 CSI 드라이버가 vCenter Server에 연결하기 위해 읽는 Secret으로 전송됩니다. 새 암호가 Secret에 전달되지 않으면 오래된 암호가 감독자 클러스터에 남아 있고 CSI 드라이버로 인해 해당 작업이 실패합니다.

  이 문제는 vSAN 데이터 지속성 플랫폼 및 모든 CSI 볼륨 작업에 영향을 미칩니다.

  해결 방법:

  일반적으로 WCP 서비스는 Kubernetes 클러스터에서 실행되는 CSI에 업데이트된 암호를 전달합니다. 간혹 연결 문제나 동기화 프로세스의 초기 오류와 같은 문제로 인해 암호가 전달되지 않는 경우가 있습니다. CSI에서 이전 암호를 계속해서 사용하다가 결과적으로 인증 실패가 너무 많아서 계정이 잠깁니다.

  WCP 클러스터가 정상 및 실행 중 상태인지 확인합니다. [워크로드 관리] 페이지에 해당 클러스터에 대한 오류가 보고되어서는 안 됩니다. 동기화 실패를 유발하는 문제가 해결된 후 암호 새로 고침을 강제 실행하여 잠긴 계정의 잠금을 해제합니다.

  암호를 강제로 재설정하려면:

  1. wcpsvc를 중지합니다.

     vmon-cli -k wcp

  2. /etc/vmware/wcp/.storageUser의 3번째 행을 1로 변경하여 마지막 암호 순환 시간을 작은 값(예: 1)으로 편집합니다.

  3. wcpsvc를 시작합니다.

     vmon-cli -i wcp

  wcpsvc가 암호를 재설정하면 계정 잠금이 해제되고 새 암호가 클러스터에 전달됩니다.

VMware Tanzu Kubernetes Grid Service for vSphere

• 감독자 클러스터 업그레이드 후에 Tanzu Kubernetes 클러스터가 "업데이트 중" 상태로 중단됨

  감독자 클러스터가 업그레이드되면 모든 Tanzu Kubernetes 클러스터의 롤링 업데이트를 트리거하여 새로운 구성 설정을 전파할 수 있습니다. 이 프로세스 중에 이전에 "실행 중"이었던 TKC 클러스터가 "업데이트 중" 단계에서 중단될 수 있습니다. "실행 중"인 Tanzu Kubernetes 클러스터는 제어부의 가용성만을 나타내며, 필요한 제어부 및 작업자 노드가 성공적으로 생성되지 않았을 수 있습니다. 이러한 Tanzu Kubernetes 클러스터는 감독자 클러스터 업그레이드가 완료되면 시작되는 롤링 업데이트 중에 수행되는 상태 점검에 실패할 수 있습니다. 이로 인해 Tanzu Kubernetes 클러스터가 "업데이트 중" 단계에서 중단되고 Tanzu Kubernetes 클러스터와 연결된 KubeadmControlPlane 리소스의 이벤트를 보면 확인할 수 있습니다. 리소스가 내보낸 이벤트는 아래와 유사합니다.

  Warning ControlPlaneUnhealthy 2m15s (x1026 over 5h42m) kubeadm-control-plane-controller Waiting for control plane to pass control plane health check to continue reconciliation: machine's (gc-ns-1597045889305/tkg-cluster-3-control-plane-4bz9r) node (tkg-cluster-3-control-plane-4bz9r) was not checked

  해결 방법: 없음.

• Tanzu Kubernetes 클러스터가 제거된 스토리지 정책에 계속 액세스함

  VI 관리자가 vCenter Server 네임스페이스에서 스토리지 클래스를 삭제하는 경우 이 스토리지 클래스를 이미 사용중인 Tanzu Kubernetes 클러스터에 대해서는 해당 스토리지 클래스에 대한 액세스가 제거되지 않습니다.

  해결 방법:

  1. VI 관리자는 vCenter Server 네임스페이스에서 스토리지 클래스를 삭제한 후 동일한 이름의 새 스토리지 정책을 생성합니다.

  2. 기존 스토리지 정책이나 방금 재생성한 스토리지 정책을 감독자 네임스페이스에 다시 추가합니다. 이 스토리지 클래스를 사용하는 TanzuKubernetesCluster 인스턴스는 이제 완전하게 작동해야 합니다.

  3. 삭제할 스토리지 클래스를 사용하는 각 TanzuKubernetesCluster 리소스에 대해 다른 스토리지 클래스를 사용하여 새 TanzuKubernetesCluster 인스턴스를 생성하고 Velero를 사용하여 워크로드를 새 클러스터로 마이그레이션합니다.

  4. 해당 스토리지 클래스를 사용하는 TanzuKubernetesCluster 또는 PersistentVolume이 없으면 스토리지 클래스를 안전하게 제거할 수 있습니다.

• 내장형 컨테이너 레지스트리 SSL 인증서가 Tanzu Kubernetes 클러스터 노드에 복사되지 않음

  내장형 컨테이너 레지스트리가 감독자 클러스터에 대해 사용되도록 설정되고 SC에서 생성된 Tanzu Kubernetes 클러스터 노드에 Harbor SSL 인증서가 포함되지 않으면 해당 노드의 레지스트리에 연결할 수 없습니다.

  해결 방법: 감독자 클러스터 제어부에서 Tanzu Kubernetes Cluster 작업자 노드로 SSL 인증서를 복사하여 붙여넣습니다.

• 컨텐츠 라이브러리에서 가상 시스템 이미지를 사용할 수 없음

  내장 연결 모드 설정에서 여러 vCenter Server 인스턴스가 구성되면 사용자가 UI를 통해 다른 vCenter Server 인스턴스에 생성된 컨텐츠 라이브러리를 선택할 수 있습니다. 이러한 라이브러리를 선택하면 DevOps 사용자가 Tanzu Kubernetes 클러스터를 프로비저닝하는 데 가상 시스템 이미지를 사용할 수 없습니다. 이 경우 `kubectl get virtualmachineimages`는 결과를 반환하지 않습니다.

  해결 방법: 컨텐츠 라이브러리를 Tanzu Kubernetes 클러스터 VM 이미지용 감독자 클러스터와 연결할 때는 감독자 클러스터가 상주하는 동일한 vCenter Server 인스턴스에서 생성된 라이브러리를 선택합니다. 또는 Tanzu Kubernetes 클러스터의 에어갭 프로비저닝을 지원하는 로컬 컨텐츠 라이브러리를 생성합니다.

• 컨텐츠 라이브러리 구독자가 게시자와 동기화 할 수 없어 새 Tanzu Kubernetes 클러스터를 프로비저닝하거나 기존 클러스터를 확장할 수 없음

  Tanzu Kubernetes 클러스터 OVA에 대해 구독 컨텐츠 라이브러리를 설정하면 SSL 인증서가 생성되고 인증서 지문을 확인하여 인증서를 수동으로 신뢰하라는 메시지가 표시됩니다. 초기 라이브러리 설정 후 SSL 인증서가 변경되면 지문을 업데이트하여 새 인증서를 다시 신뢰해야 합니다.

  구독 컨텐츠 라이브러리의 설정을 편집합니다. 이렇게 하면 라이브러리를 변경할 필요 없이 구독 URL 프로브가 시작됩니다. 프로브는 SSL 인증서를 신뢰할 수 없다는 것을 감지하고 이를 신뢰하라는 메시지를 표시합니다.

• Tanzu Kubernetes 릴리스 버전 1.16.8은 vCenter Server 7.0 업데이트 1과 호환되지 않음

  Tanzu Kubernetes 릴리스 버전 1.16.8은 vCenter Server 7.0 업데이트 1과 호환되지 않습니다. vSphere 네임스페이스를 U1로 업데이트를 수행하기 전에 Tanzu Kubernetes 클러스터를 최신 버전으로 업데이트해야 합니다.

  vSphere 네임스페이스를 vCenter Server 7.0 업데이트 1 릴리스로 업데이트를 수행하기 전에 버전 1.16.8을 실행하는 각 Tanzu Kubernetes 클러스터를 최신 버전으로 업데이트합니다. 자세한 내용은 설명서에서 Tanzu Kubernetes 릴리스 목록을 참조하십시오.

• 워크로드 제어부를 vCenter Server 7.0 업데이트 1로 업그레이드한 후 새 VM 클래스 크기를 사용할 수 없음

  설명: vSphere 7.0.1로 업그레이드한 후 감독자 클러스터의 vSphere 네임스페이스 업데이트를 수행하고, Tanzu Kubernetes 클러스터에 대해 "kubectl get virtualmachineclasses" 명령을 실행하면 새 VM 클래스 크기(2배 대형, 4배 대형, 8배 대형)가 나열되지 않습니다.

  해결 방법: 없음. 새 VM 클래스 크기는 워크로드 제어부의 새 설치에만 사용할 수 있습니다.

• Calico CNI를 사용하는 경우 Tanzu Kubernetes 릴리스 버전 1.17.11 vmware.1-tkg.1이 클러스터 DNS 서버에 연결하는 데 시간 초과됨

  Tanzu Kubernetes 릴리스 버전 v1.17.11+vmware.1-tkg.1에는 Calico CNI를 사용할 경우 이미지가 예상대로 작동하지 못하는 Photon OS 커널 문제가 있습니다.

  해결 방법: Tanzu Kubernetes 릴리스 버전 1.17.11의 경우 "v1.17.11+vmware.1-tkg.2.ad3d374.516"로 식별된 이미지는 Calico와 관련된 문제를 해결합니다. Kubernetes 1.17.11을 실행하려면 "v1.17.11+vmware.1-tkg.1.15f1e18.489" 대신 이 버전을 사용하십시오. 또는 다른 Tanzu Kubernetes 릴리스(예: 버전 1.18.5, 1.17.8 또는 1.16.14)를 사용합니다.

• vSphere with Tanzu 네트워킹이 NSX-T Data Center로 구성된 경우 "ExternalTrafficPolicy: Local" 서비스를 "ExternalTrafficPolicy: Cluster"로 업데이트하면 SV 마스터에서 이 서비스의 LB IP에 액세스할 수 없게 됨

  LoadBalancer 유형 Kubernetes 서비스가 처음에 ExternalTrafficPolicy: Local을 사용하여 워크로드 클러스터에서 생성되고 나중에 ExternalTrafficPolicy: Cluster로 업데이트되면 감독자 클러스터 VM에서 이 서비스의 LoadBalancer IP에 대한 액세스가 삭제됩니다.

  해결 방법: 서비스를 삭제하고 ExternalTrafficPolicy: Cluster를 사용하여 다시 생성합니다.

• Tanzu Kubernetes 클러스터 제어부 노드의 CPU 사용량이 높음

  Kubernetes 업스트림 프로젝트에는 kube-controller-manager가 루프에 진입하면 CPU 사용량이 높아져서 Tanzu Kubernetes 클러스터의 기능에 영향을 주는 경우가 있는 알려진 문제가 있습니다. kube-controller-manager 프로세스가 예상보다 많은 양의 CPU를 사용하고 있으며 failed for updating Node.Spec.PodCIDRs를 나타내는 반복 로그를 출력하는 것을 알 수 있습니다.

  해결 방법: 이런 문제가 있는 제어부 노드 내부에 있는 kube-controller-manager 포드를 삭제하십시오. 포드가 다시 생성되고 문제는 다시 나타나지 않습니다.

• K8s 1.16으로 생성된 Tanzu Kubernetes 클러스터를 1.19로 업데이트할 수 없음

  Kubelet의 구성 파일은 kubeadm init가 실행될 때 생성된 후 클러스터 업그레이드 중에 복제됩니다. 1.16일 때 kubeadm init는 resolvConf를 /etc/resolv.conf로 설정하는 구성 파일을 생성하고, 나중에 /run/systemd/resolve/resolv.conf를 가리키는 명령줄 플래그 --resolv-conf가 이것을 덮어씁니다. 1.17 및 1.18인 동안 kubeadm은 올바른 --resolv-conf로 Kubelet을 계속 구성합니다. 1.19부터는 kubeadm이 명령줄 플래그를 더 이상 구성하지 않고 대신 Kubelet 구성 파일에 의존합니다. 클러스터 업그레이드 중 복제 프로세스로 인해 1.16에서 업그레이드된 1.19 클러스터에는 resolvConf가 /run/systemd/resolve/resolv.conf 대신 /etc/resolv.conf를 가리키는 구성 파일이 포함됩니다.

  해결 방법: Tanzu Kubernetes 클러스터를 1.19로 업그레이드하기 전에 올바른 resolv.conf를 가리키도록 Kubelet 구성 파일을 재구성합니다. kube-system 네임스페이스에서 ConfigMap kubelet-config-1.18을 kubelet-config-1.19에 수동으로 복제한 다음 /run/systemd/resolve/resolv.conf에서 새 ConfigMap's의 데이터가 resolvConf를 가리키도록 수정합니다.

• 감독자 클러스터 네트워킹이 NSX-T로 구성된 경우 서비스를 "ExternalTrafficPolicy: Local"에서 "ExternalTrafficPolicy: Cluster"로 업데이트한 후, 감독자 클러스터 제어부 노드에서 이 서비스의 로드 밸런서 IP에 대한 요청이 실패함

  ExternalTrafficPolicy: Local을 사용하여 Tanzu Kubernetes 클러스터에서 서비스를 생성하고 나중에 이 서비스를 ExternalTrafficPolicy: Cluster로 업데이트하면 kube-proxy가 감독자 클러스터 제어부 노드에서 IP 테이블 규칙을 잘못 생성하여 서비스의 LoadBalancer IP로 향하는 트래픽을 차단합니다. 예를 들어 이 서비스에 LoadBalancer IP 192.182.40.4가 있는 경우 다음 IP 테이블 규칙이 제어부 노드 중 하나에 생성됩니다.

  -A KUBE-SERVICES -d 192.182.40.4/32 -p tcp -m comment --comment "antrea-17-171/antrea-17-171-c1-2bfcfe5d9a0cdea4de6eb has no endpoints" -m tcp --dport 80 -j REJECT --reject-with icmp-port-unreachable

  그 결과 해당 IP에 대한 액세스가 삭제됩니다.

  해결 방법: 서비스를 삭제하고 ExternalTrafficPolicy: Cluster를 사용하여 새 서비스를 생성합니다.

• TkgServiceConfiguration 규격에서 HTTP 프록시 및/또는 신뢰 설정을 사용하도록 설정한 후에는 프록시/신뢰 설정이 없는 기존의 모든 클러스터가 업데이트될 때 글로벌 프록시/신뢰 설정을 상속함

  TkgServiceConfiguration 규격을 편집하여 기본 CNI, HTTP 프록시 및 신뢰 인증서를 포함한 TKG 서비스를 구성할 수 있습니다. TkgServiceConfiguration 규격에 대한 구성을 변경하면 해당 서비스를 통해 프로비저닝되거나 업데이트되는 모든 Tanzu Kuberentes 클러스터에 전역으로 적용됩니다. 클러스터별 설정을 사용하여 글로벌 구성에서 옵트아웃할 수 없습니다.

  예를 들어 TkgServiceConfiguration 규격을 편집하고 HTTP 프록시를 사용하도록 설정하면 해당 클러스터에 의해 프로비저닝된 모든 새 클러스터는 해당 프록시 설정을 상속합니다. 또한 프록시 서버가 없는 기존의 모든 클러스터는 클러스터가 수정되거나 업데이트될 때 글로벌 프록시 구성을 상속합니다. 클러스터별 구성을 지원하는 HTTP/S 프록시의 경우 다른 프록시 서버로 클러스터 규격을 업데이트할 수 있지만 글로벌 프록시 설정을 제거할 수는 없습니다. HTTP 프록시가 전역적으로 설정되어 있으면 이를 사용하거나 다른 프록시 서버로 덮어써야 합니다.

  해결 방법: TkgServiceConfiguration 규격이 전역적으로 적용된다는 것을 이해합니다. 모든 클러스터가 하나의 HTTP 프록시를 사용하도록 설정하지 않으려면 글로벌 수준에서 사용하도록 설정하지 마십시오. 클러스터 수준에서 설정하십시오.

• 다수의 Tanzu Kubernetes 클러스터 및 VM이 있는 대규모 감독자 클러스터 배포에서 OutOfMemory 때문에 vmop-controller-manager 포드가 실패하여 Tanzu Kubernetes 클러스터의 수명 주기를 관리할 수 없음

  감독자 클러스터 내에서 vmop-controller-manager 포드는 Tanzu Kubernetes 클러스터를 구성하는 VM의 수명 주기 관리를 담당합니다. 이러한 VM이 매우 많은 경우(감독자 클러스터당 850개 이상 VM) vmop-controller-manager 포드에서 OutOfMemory CrashLoopBackoff가 발생할 수 있습니다. 그러면 vmop-controller-manager 포드가 작업을 재개할 때까지 Tanzu Kubernetes 클러스터의 수명 주기 관리가 중단됩니다.

  클러스터를 삭제하거나 클러스터를 축소하여 감독자 클러스터에서 관리되는 Tanzu Kubernetes 클러스터 작업자 노드의 총 수를 줄입니다.

• vSphere 6.5 이전 버전에서 vSphere 7 with Tanzu로 업그레이드하면 PhotonOS 유형이 지원되지 않는다는 오류가 발생할 수 있음

  vSphere 6 환경을 vSphere 7 with Tanzu로 업그레이드한 후 Tanzu Kubernetes 클러스터를 배포하려고 하면 PhotonOS가 "지원되지 않습니다."라는 오류 메시지가 표시됩니다. 구체적으로:

  failed to create or update VirtualMachine: admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType vmwarePhoton64Guest on image v1.19.7---vmware.1-tkg.1.fc82c41'

  vSphere 6.5 이전의 vSphere 버전(예: vSphere 6)에서 vSphere 7 with Tanzu로 업그레이드한 경우, PhotonOS가 지원되는 게스트 운영 체제로 표시되려면 기본 VM 호환성 수준이 적어도 "ESXi 6.5 이상"으로 설정되어 있는지 확인해야 합니다. 이렇게 하려면 [워크로드 관리]를 사용하도록 설정된 vSphere 클러스터를 선택하고 마우스 오른쪽 버튼을 클릭한 다음 [기본 VM 호환성 편집]을 선택합니다. "ESXi 6.5 이상"을 선택합니다.

• 작은 크기의 VM을 사용하여 Tanzu Kubernetes 클러스터를 프로비저닝한 다음 해당 클러스터에 워크로드를 배포하면 작업자 노드는 NotReady 상태가 되고 노드 재생성을 시도하는 연속 루프가 됨

  설명: 클러스터의 소형 또는 초소형 작업자 노드에서 /bin/opm 프로세스가 VM 메모리의 과도한 부분을 사용하여 작업자 노드에 대한 메모리 부족 오류가 발생할 수 있습니다.

  해결 방법: 작업자 노드에는 소형 또는 초소형 VM 클래스를 사용하지 마십시오. 사용 후 삭제 개발 또는 테스트 클러스터의 경우에도 사용하지 마십시오. 모범 사례로, 모든 환경에서 작업자 노드의 최소 VM 클래스는 중형입니다. 자세한 내용은 설명서에서 기본 가상 시스템 클래스를 참조하십시오.

• 구독 컨텐츠 라이브러리에서 Tanzu Kubernetes 릴리스 동기화가 실패하고 다음 HTTP 요청 오류 메시지가 표시됨: "호스트 wp-content.vmware.com에 대해 SSL 인증서를 인증할 수 없습니다."

  설명: Tanzu Kubernetes 클러스터 OVA에 대한 구독 컨텐츠 라이브러리를 구성하면 wp-content.vmware.com에 대한 SSL 인증서가 생성됩니다. 인증서 지문을 확인하여 인증서를 수동으로 신뢰하라는 메시지가 표시됩니다. 초기 라이브러리 설정 후 SSL 인증서가 변경되면 지문을 업데이트하여 새 인증서를 다시 신뢰해야 합니다. 컨텐츠 라이브러리에 대한 현재 SSL 인증서는 2021년 6월 말에 만료됩니다. wp-content.vmware.com을 구독한 고객은 컨텐츠 라이브러리 동기화가 실패하는 것을 보게 되며, 해결 방법의 단계를 수행하여 지문을 업데이트해야 합니다. 추가 지침은 https://kb.vmware.com/s/article/85268에서 관련 VMware 기술 자료 문서를 참조하십시오.

  해결 방법: vSphere Client를 사용하여 vCenter Server에 로그인합니다. 구독 컨텐츠 라이브러리를 선택하고 설정 편집을 클릭합니다. 그러면 라이브러리에 변경이 요청되지 않은 경우에도 구독 URL 프로브가 시작됩니다. 프로브는 SSL 인증서를 신뢰할 수 없다는 것을 감지하고 이를 신뢰하라는 메시지를 표시합니다. 표시되는 작업 드롭다운 메뉴에서 계속을 선택하면 지문이 업데이트됩니다. 이제 라이브러리의 컨텐츠 동기화를 진행할 수 있습니다.

• TKGS는 VM 클래스 및 노드 스케일 업을 동시에 수정하도록 지원하지 않음

  VMClass 수정 및 노드 스케일 업이 모두 포함된 클러스터에 업데이트를 적용한 후 실패가 표시될 수 있습니다.

  두 필드 중 하나만 수정하고 변경 사항을 다시 적용하도록 TKC 구성을 수정하십시오.

• 증상: 클러스터 규격에서 레이블 또는 taint를 업데이트한 후 클러스터에 대한 예기치 않은 롤링 업데이트가 발생함

  설명: TKGS v1alpha2 API를 사용할 때 한 노드 풀의 spec.topology.nodePools[*].labels또는 spec.topology.nodePools[*].taints를 수정하면 해당 노드 풀에 대한 롤링 업데이트가 트리거됩니다.

  해결 방법: 없음

• 증상: 클러스터 업데이트 후 노드 풀에 수동으로 추가된 taint 및 레이블이 더 이상 존재하지 않음

  설명: TKGS v1alpha2 API를 사용하는 경우 업데이트 전에 수동으로 추가되어 존재했던 spec.topology.nodePools[*].taints 및 spec.topology.nodePools[*].labels가 클러스터 업데이트 동안 유지되지 않습니다.

  해결 방법: 업데이트가 완료되면 수동으로 레이블 및 taint 필드를 다시 추가합니다.

• 증상: 제어부 VM 중 하나가 IP 주소를 가져오지 않아 Tanzu Kubernetes 클러스터가 생성 단계에서 중단됨

  설명: 제어부 VM 중 하나가 IP 주소를 가져오지 않아 Tanzu Kubernetes 클러스터가 생성 단계에서 중단됩니다.

  해결 방법: 이 문제를 방지하려면 Tanzu Kubernetes 릴리스 1.20.7 이상을 사용합니다.

• 증상: Tanzu Kubernetes 클러스터를 생성하는 동안 "WaitingForNetworkAddress" 이유로 인해 프로세스가 업데이트 중 상태로 중단됨

  설명: 제어부 VM 및 작업자 노드의 전원이 켜져 있지만 IP가 할당되어 있지 않습니다. 이것은 vmware-tools의 메모리가 부족하여 다시 시작되지 않았기 때문일 수 있습니다.

  해결 방법: 특정 문제는 Tanzu Kubernetes 릴리스 v1.20.7 이상에서 해결되었습니다. 또한 VM 메모리를 늘려 문제를 해결할 수 있습니다. best-effort-xsmall VM 클래스는 2G의 메모리만 제공합니다. 더 많은 메모리가 포함된 VM 클래스를 사용하여 Tanzu Kubernetes 클러스터를 배포합니다.

• 증상: 셀프 서비스 vSphere 네임스페이스가 [제거 중] 상태로 중단됨

  설명: vSphere 네임스페이스를 삭제한 후 프로세스가 진행되지 않고 몇 시간 동안 [제거 중] 상태로 중단됩니다.

  해결 방법: kubectl을 사용하여 네임스페이스에서 아직 삭제되지 않은 나머지 Kubernetes 개체를 확인합니다. kubeadm-control-plane과 관련된 개체가 남아 있는 경우 capi-kubeadm-control-plane-controller-manager 포드를 다시 시작합니다. 이 작업을 수행하면 삭제할 개체가 다시 대기열에 추가됩니다.

  참고: 이 작업은 고급 작업입니다. 이 해결 방법을 수행하기 전에 VMware 지원팀에 문의하십시오.

• TKC v1alpha2 API가 호환되지 않는 TKr을 사용한 TKC 생성을 차단하지 않음

  7.0.3 MP2 릴리스부터 TKr < 1.18.x는 호환되지 않지만 TKC API는 여전히 v1.18.x보다 낮은 버전의 TKC를 생성할 수 있도록 허용하며 호환되지 않는 TKr로 생성될 때 TKC 개체의 생성을 차단하지 않습니다. 이러한 TKC는 생성되지 않습니다.

  실행 중 상태가 아니며 호환되지 않는 TKr로 생성된 TKC를 삭제합니다. 호환되는 버전을 사용하여 다시 생성합니다.

vSAN 데이터 지속성 플랫폼

• vDPP UI 플러그인이 vSphere Client에 배포되지 않고 더 이상 존재하지 않는 감독자 클러스터에서 플러그인 다운로드를 시도했음을 나타내는 오류 메시지가 표시됨

  이 문제는 클러스터에 vDPP UI 플러그인을 배포한 다음 이 클러스터를 제거한 경우 발생할 수 있습니다. 하지만 이 vDPP UI 플러그인과 관련된 오래된 항목은 vCenter Extension Manager에 남아 있습니다. 나중에 새 클러스터를 생성하면 이 클러스터에 동일한 버전의 vDPP UI 플러그인을 설치하려고 시도하면 실패합니다. vSphere Client가 오래된 항목을 사용하여 존재하지 않는 이전 클러스터에서 플러그인을 다운로드하기 때문입니다.

  해결 방법:

  1. https://vc-ip/mob and 를 사용하여 vCenter Extension Manager로 이동하고 플러그인 확장을 찾습니다.

  2. 이전 클러스터의 이름을 포함하는 모든 ClientInfo 및 ServerInfo 항목을 제거합니다.

  3. ClientInfo 어레이에서 버전 번호가 가장 큰 ClientInfo를 선택하고 해당 유형을 vsphere-client-remote-backup에서 vsphere-client-remote로 변경합니다.

• 감독자 클러스터의 vSphere 포드가 vm-uuid 주석 없이 보류 중 상태로 유지됨

  간혹 포드가 오랫동안 보류 중 상태로 유지되는 경우가 있습니다. 이는 일반적으로 vDPP(vSAN 데이터 지속성 플랫폼)를 사용할 때 발생하며 내부 오류 또는 사용자 작업으로 인해 발생할 수 있습니다.

  kubectl 명령을 사용하여 포드 인스턴스를 쿼리하는 경우 메타데이터 주석에 vmware-system-vm-uuid/vmware-system-vm-moid 주석이 없습니다.

  해결 방법: kubectl delete pod pending_pod_name 명령을 사용하여 포드를 삭제합니다. 포드가 상태 저장 집합의 일부이면 포드가 자동으로 다시 생성됩니다.

• 두 복제본 포드의 호스트 로컬 PVC가 동일한 클러스터 노드에 바인딩된 경우 vDPP 서비스의 인스턴스가 배포되지 않음

  경우에 따라 vSAN 데이터 지속성 플랫폼 서비스의 인스턴스(예: MinIO 또는 Cloudian)가 두 개의 복제본 포드의 호스트 로컬 PVC가 동일한 클러스터 노드에 할당된 상태가 될 수 있습니다. 일반적으로 동일한 인스턴스의 두 복제본은 동일한 클러스터 노드에 호스트 로컬 스토리지를 가질 수 없습니다. 이런 경우가 발생하면 복제본 포드 중 하나가 무기한 보류 상태로 유지되어 인스턴스 배포가 실패할 수 있습니다.

  실패 시 보이는 증상에는 다음이 모두 포함됩니다.

  • 인스턴스 상태가 노란색입니다.

  • 하나 이상의 인스턴스 포드가 10분 넘게 보류 중 상태로 유지됩니다.

  • 보류 중인 포드와 동일한 인스턴스의 실행 중인 복제 포드 중 하나에 동일 클러스터 노드에 할당된 호스트 로컬 PVC가 있습니다.

  이 문제로 이어질 수 있는 실패 시나리오는 다음과 같습니다.

  • 클러스터의 일부 노드에 인스턴스에 대한 스토리지 리소스가 부족합니다.

  • 복제본 수가 클러스터의 노드 수보다 많습니다. 이것은 하나 이상의 노드를 일시적으로 사용할 수 없기 때문일 수 있습니다.

  해결 방법:

  1. 클러스터에 충분한 스토리지 리소스가 있고 클러스터 노드 수가 인스턴스 복제본 수보다 많은지 확인합니다.

  2. 보류 중인 포드 및 해당 호스트 로컬 PVC를 모두 삭제합니다.

  서비스 운영자는 포드가 스케줄링되는 새 노드에서 볼륨 데이터를 재구축해야 합니다. 볼륨의 크기 및 볼륨의 유효한 데이터 양에 따라 완료하는 데 다소 시간이 걸릴 수 있습니다.

• ESXi 노드가 [액세스 지원 보장] 모드에서 유지 보수를 종료한 후 유지 보수 중에 노드에 적용된 taint가 노드에 계속 남아 있을 수 있음

  이 문제는 vDPP(vSAN 데이터 지속성 플랫폼)를 사용하여 파트너 서비스의 인스턴스를 생성하는 경우 발생할 수 있습니다. ESXi 노드가 [액세스 지원 보장] 모드에서 유지 보수를 종료한 후에도 노드에 남아 있는 taint node.vmware.com/drain=planned-downtime:NoSchedule을 찾을 수 있습니다.

  일반적으로 이 문제는 다음 작업이 수행될 때 발생합니다.

  1. 파트너 서비스가 감독자 클러스터에서 사용되도록 설정되고 서비스의 인스턴스가 생성됩니다.

  2. ESXi 노드가 [액세스 지원 보장] 모드에서 유지 보수로 전환됩니다.

  3. 노드가 [액세스 지원 보장]에서 유지 보수 모드로 전환됩니다.

  4. taint node.vmware.com/drain=planned-downtime:NoSchedule이 노드에 적용됩니다.

  5. 노드가 유지 보수 모드를 종료합니다.

  노드가 유지 보수 모드를 종료한 후 다음 명령을 사용하여 노드에 taint가 남아 있지 않은지 확인합니다.

  kubectl describe node | grep Taints

  해결 방법:

  taint node.vmware.com/drain=planned-downtime:NoSchedule이 호스트에 있으면 taint를 수동으로 제거합니다.

  kubectl taint nodes nodeNamekey=value:Effect-

  참고: 명령 끝에 하이픈을 사용해야 합니다.

  이 예제를 따릅니다.

  kubectl taint nodes wdc-10-123-123-1.eng.vmware.com node.vmware.com/drain=planned-downtime:NoSchedule-

• APD 복구 후 vSAN 데이터 지속성 플랫폼에서 실행되는 영구 서비스 포드가 AttachVolume 오류로 인해 보류 중 상태로 유지될 수 있음

  ADP 및 ESXi 호스트 복구 후 vDPP 서비스 인스턴스 포드가 보류 중 상태로 유지될 수 있습니다. kubectl -n instance_namespace describe pod name_of_pod_in_pending 명령을 실행하면 AttachVolume 오류를 볼 수 있습니다.

  포드가 15분 넘게 보류 중 상태로 유지되면 그 상태에서 벗어날 가능성이 낮습니다.

  해결 방법: 다음 명령을 사용하여 보류 중인 포드를 삭제합니다. kubectl -n instance_namespace delete pod name_of_pod_in_pending. 포드가 다시 생성되고 실행 중 상태로 전환됩니다.

VM 서비스

• <span style="color:#FF0000">새 문제:</span> 이름이 동일한 vSphere 포드 및 VM 서비스 VM을 배포하려고 하면 오류와 예기치 않은 동작이 발생함

  실패 및 오류 또는 기타 문제가 있는 동작이 발생할 수 있습니다. 네임스페이스에서 실행 중인 vSphere 포드가 있는 경우 동일한 네임스페이스에 동일한 이름을 가진 VM 서비스 가상 시스템을 배포하려고 시도하면 이러한 문제가 발생할 수 있으며 그 반대의 경우도 마찬가지입니다.

  해결 방법: 동일한 네임스페이스의 vSphere 포드 및 VM에 동일한 이름을 사용하지 않습니다.

• VM 서비스에서 제한된 VM 이미지 집합을 사용할 수 있음

  VM 서비스와 호환되지 않는 VM 이미지를 사용하려고 하면 VM 생성 시 다음 메시지가 표시됩니다.

  Error from server (GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image): error when creating : admission webhook "default.validating.virtualmachine.vmoperator.vmware.com" denied the request: GuestOS not supported for osType on image or VMImage is not compatible with v1alpha1 or is not a TKG Image

  해결 방법: VM 서비스에서 작동하는 것으로 확인된 VMware Marketplace의 VM 이미지만 사용합니다.

• 이름이 DNS 규격이 아닌 가상 시스템 이미지를 사용할 수 없음

  컨텐츠 라이브러리의 OVF 이미지 이름이 DNS 하위 도메인 이름과 호환되지 않으면 VM 서비스는 OVF 이미지에서 VirtualMachineImage를 생성하지 않습니다. 그 결과 kubectl get vmimage는 네임스페이스의 이미지를 나열하지 못하며 개발자는 이 이미지를 사용할 수 없습니다.

  해결 방법: OVF 이미지에 DNS 하위 도메인 규정 준수 이름을 사용합니다.

• 중복된 OVF 이미지가 중복된 VirtualMachineImages로 나타나지 않음

  다른 컨텐츠 라이브러리에서 이름이 같은 OVF 이미지가 다른 VirtualMachineImages로 표시되지 않음

  해결 방법: VM 서비스로 구성된 컨텐츠 라이브러리 전체에서 OVF 이미지에 고유한 이름을 사용합니다.

• VM 서비스에서 생성된 VM이 웹 또는 원격 콘솔에 대한 액세스를 허용하지 않음

  VM 서비스에서 생성된 가상 시스템은 원격 콘솔에 대한 액세스를 허용하지 않습니다. 따라서 관리자가 vSphere Web Client에서 웹 콘솔 시작 및 Remote Console 시작 옵션을 사용하여 VM에 로그인할 수 없습니다.

  해결 방법: 관리자는 VM이 있는 ESXi 호스트에 로그인하여 VM 콘솔에 액세스할 수 있습니다.

• VM 서비스에서 관리되는 vGPU 및 패스스루 디바이스가 있는 VM은 ESXi 호스트가 유지 보수 모드로 전환되면 전원이 꺼짐

  VM 서비스를 사용하면 DevOps 엔지니어가 vGPU 또는 패스스루 디바이스에 연결된 VM을 생성할 수 있습니다. 일반적으로 ESXi 호스트가 유지 보수 모드로 전환되면 DRS는 호스트에서 실행되는 VM에 대한 권장 사항을 생성합니다. 그러면 vSphere 관리자가 권장 사항을 수락하여 vMotion을 트리거할 수 있습니다.

  하지만 VM 서비스에서 관리되는 vGPU 및 패스스루 디바이스가 있는 VM은 자동으로 전원이 꺼집니다. 그러면 해당 VM에서 실행되는 워크로드에 일시적으로 영향을 줄 수 있습니다. 호스트가 유지 보수 모드를 종료하면 VM의 전원이 자동으로 켜집니다.

  해결 방법: 없음.