릴리스 정보에는 다음과 같은 항목이 포함됩니다.
릴리스 정보에는 다음과 같은 항목이 포함됩니다.
| 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일 |
새로운 기능
감독자
감독자 서비스를 이제 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 관리자를 개입시키지 않고도 게스트 운영 체제 내에서 문제 해결 및 디버깅이 가능합니다.
Tanzu Kubernetes Grid for vSphere
사용자 지정 클러스터 클래스 - 감독자의 TKG 클러스터에 대한 자체 클러스터 클래스를 가져옵니다. 자세한 내용은 https://kb.vmware.com/s/article/91826을 참조하십시오.
TKG 노드에 대한 사용자 지정 이미지 - vSphere TKG Image Builder(Ubuntu 및 Photon)를 사용하여 고유한 사용자 지정 노드 이미지를 구축합니다.
참고: v1alpha1 API에서 특정 TKR을 사용하려면 fullVersion을 사용합니다.
해결된 문제
v1beta1 API로 프로비저닝된 Tanzu Kubernetes Grid 2.0 클러스터는 기본 ClusterClass를 기반으로 해야 함
v1beta1 API를 사용하여 감독자에서 Tanzu Kubernetes Grid 2.0 클러스터를 생성하는 경우 클러스터는 기본 tanzukubernetescluster ClusterClass를 기반으로 해야 합니다. 다른 ClusterClass에 기반한 클러스터는 시스템에서 조정되지 않습니다.
| 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일 |
해결된 문제
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를 최신 버전으로 업그레이드하거나 배포된 모든 감독자를 업그레이드합니다.
| 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일 |
새로운 기능:
Cert-Manager CA 클러스터 발급자 지원 추가 - 관리자가 감독자에서 클러스터 범위의 CA 발급자를 감독자 서비스로 정의하고 배포할 수 있는 기능을 제공합니다. 클러스터 범위의 CA 발급자를 배포하면 감독자 네임스페이스의 소비자가 CA 발급자가 서명한 인증서를 요청하고 관리할 수 있습니다.
이 릴리스는 이 새로운 기능 외에도 버그 수정을 제공합니다.
해결된 문제
감독자 제어부 VM 루트 디스크가 가득 참
감독자 제어부 VM의 /var/log/audit/ 아래의 감사 로그 파일이 매우 큰 크기로 증가하여 루트 디스크를 가득 채울 수 있습니다. 이 상태를 반영하는 저널링된 로그에 "디바이스에 남아 있는 공간이 없습니다." 오류가 표시되어야 합니다. 이로 인해 다양한 측면의 감독자 제어부 기능(예: Kubernetes API)이 실패할 수 있습니다.
이 버전, vSphere 8.0.0b에서 해결되었습니다.
| 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일 |
새로운 기능
감독자 서비스로 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을 참조하십시오.
| 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일 |
vSphere with Tanzu 8.0에는 다음과 같은 새로운 기능과 향상된 기능이 추가되었습니다.
워크로드 관리 구성 모니터링 - 이제 감독자의 활성화, 비활성화 및 업그레이드 상태를 보다 자세히 추적할 수 있습니다. 감독자 활성화, 비활성화 또는 업그레이드를 시작하면 감독자는 감독자의 다양한 구성 요소(예: 제어부 VM)와 연결된 다양한 조건에 도달하여 원하는 상태에 도달하려고 시도합니다. 각 조건의 상태를 추적하고, 연결된 주의를 보고, 상태를 다시 시도하고, 도달한 조건과 해당 타임 스탬프를 볼 수 있습니다.
vSphere 영역 - vSphere 영역은 vSphere 클러스터에 가용성 영역을 할당할 수 있는 새로운 구성체입니다. vSphere 영역에 감독자를 배포하면 특정 가용성 영역 및 장애 도메인에서 Tanzu Kubernetes Grid 클러스터를 프로비저닝할 수 있습니다. 그러면 워크로드가 여러 클러스터에 걸쳐 있을 수 있기 때문에 하드웨어 및 소프트웨어 장애에 대한 복원력이 향상됩니다.
다중 클러스터 감독자 - vSphere 영역을 사용하면 여러 vSphere 클러스터에 감독자를 배포하여 Tanzu Kubernetes Grid 클러스터에 고가용성 및 장애 도메인을 제공할 수 있습니다. 이 릴리스는 메트로 클러스터 배포용이 아닙니다. 다중 클러스터 감독자의 사용 사례는 단일 물리적 데이터 센터의 별도 랙에 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 사용 설명서를 참조하십시오.
PVC를 삭제한 후 PV가 종료됨 상태로 유지됨
PVC(PersistentVolumeClaim)를 삭제한 후 해당 PV(영구 볼륨)가 감독자에서 종료됨 상태로 남아 있을 수도 있습니다. 또한 vSphere Client에 실패한 deleteVolume 작업이 여러 개 표시될 수도 있습니다.
해결 방법:
감독자로 인증합니다.
kubectl vsphere login --server=IP-ADDRESS --vsphere-username USERNAME
종료 중 상태의 영구 볼륨 이름을 가져옵니다.
kubectl get pv
영구 볼륨에서 볼륨 핸들을 적어둡니다.
kubectl describe pv <pv-name>
이전 단계의 볼륨 핸들을 사용하여 감독자에서 CnsVolumeOperationRequest 사용자 지정 리소스를 삭제합니다.
kubectl delete cnsvolumeoperationrequest delete-<volume-handle>
PV를 삭제하기 전에 클러스터의 다른 리소스에서 사용되고 있지 않은지 확인합니다.
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에서 네임스페이스를 수동으로 삭제합니다.
vSphere Client 홈 메뉴에서 워크로드 관리를 선택합니다.
네임스페이스 탭을 클릭합니다.
네임스페이스 목록에서 삭제되지 않은 네임스페이스를 선택하고 제거 버튼을 클릭하여 네임스페이스를 삭제합니다.
내장 연결 모드 토폴로지를 사용하는 vCenter Server에서 NSX Advanced Load Balancer를 사용할 수 없음
NSX Advanced Load Balancer 컨트롤러를 여러 클라우드에서 구성할 수 있습니다. 하지만 기본 클라우드 옵션만 지원되므로 vSphere with Tanzu를 사용하도록 설정하는 동안 여러 클라우드를 선택할 수는 없습니다. 따라서 내장 연결 모드 토폴로지를 사용하는 vCenter Server 버전에서는 NSX Advanced Load Balancer를 사용할 수 없습니다.
각 vCenter Server에 대해 NSX 로드 밸런서를 구성합니다.
감독자 업그레이드 없이 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의 문제로 인해 발생할 수 있습니다.
해결 방법:
다음 명령을 사용하여 스케줄링이 사용되지 않도록 설정된 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 볼륨이 있는지 확인합니다. 볼륨이 있는 경우 다음 단계로 진행합니다.
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단계의 출력에는 포드가 없는 노드에 연결된 볼륨이 표시되므로 다음 단계로 진행합니다.
모든 노드 개체에 대한 정보를 가져와서 동일한 볼륨이 다른 노드에 연결되어 있는지 확인합니다.
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
...볼륨 이름의 볼륨 핸들을 기반으로 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입니다.
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가 잘못되었음을 나타냅니다.
노드 개체에서 오래된 volumeAttached 항목을 삭제합니다.
kubectl edit node tkc_node_name
예:
kubectl edit node gcm-cluster-antrea-1-workers-pvx5v-5b9c4dbcc7-28p95
status.volumeAttached에서 오래된 볼륨 항목을 제거합니다.
status.volumeAttached 속성의 모든 오래된 볼륨에 대해 위 단계를 반복합니다.
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" deletedvSphere 관리자가 클러스터 용량을 초과하는 리소스 제한으로 셀프 서비스 네임스페이스 템플릿을 구성하는 경우 경고가 트리거되지 않음.
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>})
해결 방법:
계정 잠금 해제 시간을 가져옵니다.
vSphere Client에서 [관리]로 이동하고 [Single Sign-On]에서 [구성]을 클릭합니다.
[계정] 탭을 클릭합니다.
[잠금 정책]에서 [잠금 해제 시간](초)을 가져옵니다.
kubectl용 vSphere 플러그인을 사용하여 감독자로 인증합니다.
kubectl vsphere login –server IP-ADDRESS --vsphere-username USERNAME
vmware-system-csi-namespace에서 vsphere-csi-controller 배포의 원래 복제본 수를 기록해 둡니다.
kubectl get deployment vsphere-csi-controller -n vmware-system-csi -o=jsonpath='{.spec.replicas}'
original-replica-count
vsphere-csi-controller 배포 복제본 수를 0으로 스케일 다운합니다.
kubectl scale --replicas=0 deployment vsphere-csi-controller -n vmware-system-csi
[잠금 해제 시간]에 표시된 시간(초)을 기다립니다.
vsphere-csi-controller 배포 복제본 수를 원래 값으로 스케일 업합니다.
kubectl scale --replicas=original-replica-count deployment vsphere-csi-controller -n vmware-system-csi
프록시 서버로 구성된 기존 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에 필요한 사용 권한을 추가합니다.
TKC에서 기능 패키지 조정을 일시 중지합니다.
kubectl patch -n vmware-system-tkg pkgi tkc-capabilities -p '{"spec":{"paused": true}}' --type=merge새 파일 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-rbacTKC에서 기능 클러스터 역할을 패치합니다.
//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=mergeTKC에서 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에 기반한 클러스터는 시스템에서 조정되지 않습니다.
해결 방법: 없음
v1beta1 클러스터에 대해 노드 드레이닝 시간 초과가 올바르게 전파되지 않음
Tanzu Kubernetes 릴리스 확인자가 제어부 시스템 배포 토폴로지에 nodedraintimeout이 없는 상태에서 클러스터 유형을 기반으로 클러스터를 변경하기 때문에 nodedraintimeout이 올바르게 전파되지 않습니다.
해결 방법:
감독자에 루트 사용자로 로그인합니다.
작업자 노드에 대한 노드 드레이닝 시간 초과를 추가하려면 다음 명령을 실행합니다.
kubectl edit md <machine-deployment> -n <namespace>nodeDrainTimeout 값을 machineDeployment.spec.template.spec.nodeDrainTimeout에 추가합니다.
제어부 노드의 경우 다음 명령을 사용하여 Kubernetes 제어부 아래의 모든 제어부 시스템을 가져옵니다.
kubectl get machine -n ns01 -l cluster.x-k8s.io/control-plane=결과 예시(명확히 보이도록 형식이 지정됨):
NAME | CLUSTER| NODENAME | PROVIDERID | PHASE | AGE | VERSION
tkc-minimal-xz9vm-6bnqf | tkc-minimal | tkc-minimal-xz9vm-6bnqf | vsphere://422cc83a-81d9-55c7-402b-3d3510c52967 | Running | 75m | v1.22.6+vmware.1machine.spec.nodeDrainTimeout을 편집하고 nodeDrainTimeout 값을 추가합니다.
Kubernetes 제어부 규격 섹션을 편집하고 노드 드레이닝 시간 초과 값을 kcp.spec.machineTemplate.nodeDrainTimeout에 추가합니다.
