VMware Tanzu Kubernetes Grid v2.2 Release Notes

명시된 경우를 제외하고 이러한 Release Notes는 TKG(Tanzu Kubernetes Grid)의 모든 v2.2.x 패치 버전에 적용됩니다.

TKG v2.2는 버전이 지정된 TKG 독립형 관리 클러스터를 배포하는 다운로드 가능한 Tanzu CLI 패키지로 배포됩니다. TKG v2.2는 vSphere 6.7, 7, 8, AWS, Azure를 포함한 여러 인프라에서 실행할 수 있는 독립형 관리 클러스터를 사용하여 워크로드 클러스터를 생성하고 관리할 수 있도록 지원합니다.

vSphere 8에서 v2.0, v2.2 및 vSphere with Tanzu Supervisor Tanzu Kubernetes Grid

중요
vSphere 8.0.1c 이상의 vSphere with Tanzu Supervisor는 TKG v2.2를 실행합니다. 이전 버전의 vSphere 8은 Supervisor와 독립적으로 릴리스되지 않은 TKG v2.0을 실행합니다. TKG 2.x를 실행하는 독립형 관리 클러스터는 TKG 2.1부터 사용할 수 있습니다. 이후의 TKG 릴리스는 향후 vSphere 업데이트 릴리스에서 Supervisor에 내장될 예정입니다. 따라서 지정된 시간에 최신 vSphere with Tanzu 버전에 내장된 TKG의 버전이 사용 중인 독립형 TKG 버전과 동일하지 않을 수 있습니다. 그러나 모든 TKG v2.x 릴리스와 호환되는 Tanzu CLI 버전은 모든 vSphere 8 릴리스에서 Supervisor와 함께 사용할 수 있도록 완전히 지원됩니다.

vSphere 7에서 v2.2 및 vSphere with Tanzu Tanzu Kubernetes Grid

주의
TKG 2.x 및 vSphere 8의 vSphere with Tanzu Supervisor와 호환되는 Tanzu CLI 버전은 vSphere 7의 Supervisor 클러스터와 호환되지 않습니다. vSphere 7의 vSphere with Tanzu Supervisor 클러스터에서 Tanzu CLI를 사용하려면 TKG v1.6의 Tanzu CLI 버전을 사용합니다. Supervisor와 TKG 2.x와 호환되는 Tanzu CLI 버전을 사용하려면 vSphere 8로 업그레이드합니다. vSphere with Tanzu Supervisor 클러스터가 없는 경우 독립형 TKG 2.x 관리 클러스터를 vSphere 7에 배포할 수 있습니다. Tanzu CLI와 VMware 제품 간의 호환성에 대한 자세한 내용은 Tanzu CLI 설명서를 참조하십시오.

새로운 기능

Tanzu Kubernetes Grid v2.2.x에는 다음과 같은 새로운 기능이 포함되어 있습니다.

Kubernetes v1.25.7, 1.24.11, 1.23.17 지원. 아래의 Tanzu Kubernetes Grid v2.1에서 지원되는 Kubernetes 버전을 참조하십시오.
독립형 관리 클러스터 및 클래스 기반 워크로드 클러스터의 경우 클러스터 구성 파일의 ADDITIONAL_IMAGE_REGISTRY* 변수 또는 Cluster 개체 규격의 additionalImageRegistries 설정을 사용하여 여러 개인 이미지 레지스트리에 대한 신뢰를 구성할 수 있습니다. 클래스 기반 클러스터에 대해 신뢰할 수 있는 레지스트리를 참조하십시오.
Harbor v2.7.1에서 jobservice.scandataExports 영구 볼륨 할당을 제거합니다. 이전에 Harbor 패키지에 Harbor Scandata 볼륨 EmptyDir 오버레이에 적용한 경우 Harbor 패키지를 v2.7.1로 업데이트하기 전에 실행 중인 Harbor 배포를 참조하십시오.
TKG 2.2.0부터 VMware는 Tanzu Kubernetes Grid 배포될 때 Harbor, Contour, Velero와 같은 VMware 지원 패키지에 대한 런타임 수준 지원을 제공합니다.
vSphere CSI 패키지는 vsphereCSI.netpermissions 구성을 지원합니다.

지원되는 Kubernetes 및 TKG 버전

TKG v2.2에서는 TKG 및 TKr의 이전 패치 버전에 대한 VMware 지원 정책이 변경되며, TKG에 대한 Kubernetes 버전을 패키지합니다. TKG v2.1 및 이전 버전의 TKG에 대한 지원 정책은 변경되지 않습니다.

아래 섹션에는 현재 지원되는 모든 TKG 및 TKr 버전에 대한 지원이 각각에 적용되는 지원 정책에 따라 요약되어 있습니다.

지원되는 Kubernetes 버전

알려진 문제에 언급된 곳을 제외하고, 각 버전의 Tanzu Kubernetes Grid 관리 클러스터의 Kubernetes 버전과 Tanzu Kubernetes 릴리스(TKr)로 배포되는 추가 Kubernetes 버전에 대한 지원을 추가합니다.

부 버전: VMware 릴리스 시 Kubernetes v1.25, v1.24, v1.23에서 TKG v2.2를 지원하며 TKG v2.1도 지원됩니다. TKG v2.1이 일반 지원 종료 이정표에 도달하면 VMware는 더 이상 TKG를 사용하여 Kubernetes v1.23 및 v1.24를 지원하지 않습니다.

패치 버전: VMware는 마이너 줄에 새 TKr 패치 버전을 게시한 후 2개월 동안 이전 패치 버전에 대한 지원을 유지합니다. 이를 통해 고객은 2개월 동안 새 TKr 패치 버전으로 업그레이드할 수 있습니다. TKG v2.2부터 VMware는 이전 부 버전의 Kubernetes에서 모든 TKr 패치 버전을 지원하지 않습니다.

지원되는 TKG 및 TKr 버전

현재 지원되는 TKG 패치 버전은 아래 나열된 TKr 패치 버전을 지원합니다.

Tanzu Kubernetes Grid 버전	관리 클러스터 Kubernetes 버전	제공된 Kubernetes(TKr) 버전
2.2.0	1.25.7	1.25.7, 1.24.11, 1.23.17
2.1.1	1.24.10	1.24.10, 1.23.16, 1.22.17
2.1.0	1.24.9	1.24.9, 1.23.15, 1.22.17
1.6.1	1.23.10	1.23.10, 1.22.13, 1.21.14
1.6.0	1.23.8	1.23.8, 1.22.11, 1.21.14

TKG v2.2.0에서 지원되는 TKr 버전

TKG v2.2.0은 다음 릴리스 날짜를 기준으로 아래 표에 나열된 TKr 패치 버전을 지원합니다.

v2.2.0: 2023년 5월 18일
v2.1.1: 2023년 3월 21일

Kubernetes 부	Kubernetes 패치	TKG와 함께 릴리스됨	지원 종료 날짜 (최신이 아닌 경우)
v1.25	v1.25.7	v2.2.0	최신 지원
v1.24	v1.24.11	v2.2.0	최신 지원
	v1.24.10	v2.1.1	2023년 7월 11일
	v1.24.9	v2.1.0	2023년 5월 21일
v1.23	v1.23.17	v2.2.0	최신 지원
	v1.23.16	v2.1.1	2023년 7월 11일
	v1.23.15	v2.1.0	2023년 5월 21일

지원되는 Tanzu Kubernetes Grid 버전

VMware는 다음과 같이 TKG 버전을 지원합니다.

부 버전: VMware는 TKG의 최신 및 이전 두 부 버전에 적용되는 N-2 수명 주기 정책에 따라 TKG를 지원합니다. TKG v2.2.0 릴리스에서는 TKG v1.5가 더 이상 지원되지 않습니다. 자세한 내용은 VMware 제품 수명 주기 매트릭스를 참조하십시오.

패치 버전: VMware는 이전 TKG 패치 버전을 모두 지원하지 않습니다. VMware는 TKG의 새 패치 버전을 릴리스한 후 2개월 동안 이전 패치 버전에 대한 지원을 유지합니다. 이를 통해 고객은 2개월 동안 새 TKG 패치 버전으로 업그레이드할 수 있습니다.

예를 들어 TKG v2.2.0에 대한 지원은 TKG v2.2.1의 일반 가용성 이후 2개월 후에 종료됩니다.

Tanzu 표준 저장소 패키지 지원 설명

VMware는 VMware Tanzu Standard 저장소에 제공되는 선택적 패키지에 대해 다음과 같이 지원합니다.

VMware는 Tanzu Kubernetes Grid 배포될 때 옵션인 VMware Tanzu Standard 저장소에 포함된 패키지에 대한 설치 및 업그레이드 검증을 제공합니다. 이 검증은 패키지의 설치 및 업그레이드로 제한되지만 CVE를 해결하는 데 필요한 사용 가능한 업데이트가 포함됩니다. 버그 수정, 기능 향상, 보안 수정 사항은 업스트림 패키지 프로젝트에서 사용할 수 있는 경우 새 패키지 버전에 제공됩니다.
VMware는 Tanzu 표준 저장소에서 제공하는 구성 요소에 대한 런타임 수준 지원을 제공하지 않습니다. 구성 디버깅, 성능 관련 문제 또는 패키지 자체의 디버깅 및 수정은 VMware에서 제공되지 않습니다.

Tanzu Standard 패키지에 대한 VMware 지원은 위의 새로운 기능 및 아래의 향후 동작 변경 고지 사항을 참조하십시오.

Tanzu Kubernetes Grid v2.2의 제품 스냅샷

Tanzu Kubernetes Grid v2.2는 클러스터 생성 및 관리, 네트워킹, 스토리지, 인증, 백업 및 마이그레이션, 관찰 가능성 구성 요소뿐만 아니라 다음과 같은 인프라 플랫폼 및 OS(운영 체제)를 지원합니다. 괄호 안에 나열된 구성 요소 버전은 Tanzu Kubernetes Grid v2.2.0에 포함되어 있습니다. 자세한 내용은 구성 요소 버전을 참조하십시오.

	vSphere	AWS	Azure
인프라 플랫폼	vSphere 6.7U3 vSphere 7 vSphere 8 VMware Cloud on AWS** Azure VMware Solution OCVS(Oracle Cloud VMware Solution) GCVE(Google Cloud VMware Engine)	네이티브 AWS	네이티브 Azure
CLI, API, 패키지 인프라	Tanzu Framework v0.29.0
클러스터 생성 및 관리	코어 클러스터 API(v1.2.8), 클러스터 API 제공자 vSphere(v1.5.3)	코어 클러스터 API(v1.2.8), 클러스터 API 제공자 AWS(v2.0.2)	코어 클러스터 API(v1.2.8), 클러스터 API 제공자 Azure(v1.6.3)
TKG와 함께 배포되는 Kubernetes 노드 OS	Photon OS 3, Ubuntu 20.04	Amazon Linux 2, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
자체 이미지 구축	Photon OS 3, Red Hat Enterprise Linux 7*** 및 8, Ubuntu 18.04, Ubuntu 20.04, Windows 2019	Amazon Linux 2, Ubuntu 18.04, Ubuntu 20.04	Ubuntu 18.04, Ubuntu 20.04
컨테이너 런타임	Containerd(v1.6.18)
컨테이너 네트워킹	Antrea(v1.9.0), Calico(v3.24.1)
컨테이너 레지스트리	Harbor(v2.7.1)
수신	NSX Advanced Load Balancer Essentials 및 Avi 컨트롤러 **** (v21.1.5-v21.1.6, v22.1.2-v22.1.3), Contour (v1.23.5)	Contour(v1.23.5)	Contour(v1.23.5)
스토리지	vSphere 컨테이너 스토리지 인터페이스(v2.7.1*) 및 vSphere 클라우드 네이티브 스토리지	Amazon EBS CSI 드라이버(v1.16.0) 및 트리 내 클라우드 제공자	Azure 디스크 CSI 드라이버(v1.27.0), Azure 파일 CSI 드라이버(v1.26.1), 트리 내 클라우드 제공자
인증	Pinniped를 통한 OIDC(v0.12.1), Pinniped를 통한 LDAP(v0.12.1) 및 Dex
관찰 가능성	Fluent Bit(v1.9.5), Prometheus(v2.37.0)*****, Grafana(v7.5.17)
백업 및 마이그레이션	Velero(v1.9.7)

* vsphere_csi_driver 버전입니다. Tanzu Kubernetes Grid v2.2 릴리스에 포함된 vSphere Container Storage Interface 구성 요소의 전체 목록은 Component 버전을 참조하십시오.

** 이 릴리스와 호환되는 VMware Cloud on AWS SDDC 버전 목록은 VMware 제품 상호 운용성 매트릭스를 참조하십시오.

Tanzu Kubernetes Grid v1.6은 Red Hat Enterprise Linux 7 이미지 구축을 지원하는 마지막 릴리스입니다.

**** TKG 독립형 관리 클러스터 및 해당 워크로드 클러스터에서 NSX Advanced Load Balancer를 사용하려면 NSX ALB v22.1.2 이상이 필요합니다.

클러스터를 Kubernetes v1.25로 업그레이드하는 경우 Prometheus를 버전 2.37.0+vmware.3-tkg.1로 업그레이드해야 합니다. 이전 버전의 Prometheus 패키지(예: 버전 2.37.0+vmware.1-tkg.1)는 Kubernetes 1.25와 호환되지 않습니다.

Tanzu Kubernetes Grid v2.2와 함께 제공되는 Kubernetes 버전의 전체 목록은 위의 Tanzu Kubernetes Grid v2.2에서 지원되는 Kubernetes 버전을 참조하십시오.

구성 요소 버전

Tanzu Kubernetes Grid v2.2.x 릴리스에는 다음과 같은 소프트웨어 구성 요소 버전이 포함됩니다.

구성 요소	TKG v2.2
aad-pod-identity	v1.8.15+vmware.1^*
addons-manager	v2.2+vmware.1^*
ako-operator	v1.8.0_vmware.1^*
alertmanager	v0.25.0_vmware.1^*
antrea	v1.9.0_vmware.2-tkg.1-advanced^*
aws-ebs-csi-driver	v1.16.0_vmware.1-tkg.1^*
azuredisk-csi-driver	v1.27.0_vmware.2-tkg.1^*
azurefile-csi-driver	v1.26.1_vmware.2-tkg.1^*
calico	v3.24.1_vmware.1-tkg.2^*
capabilities-package	v0.29.0-dev-capabilities^*
carvel-secretgen-controller	v0.11.2+vmware.1
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1
cloud_provider_vsphere	v1.25.1+vmware.2^*
cluster-api-provider-azure	v1.6.3_vmware.2^*
cluster_api	v1.2.8+vmware.2^*
cluster_api_aws	v2.0.2+vmware.2^*
cluster_api_vsphere	v1.5.3+vmware.2^*
cni_plugins	v1.1.1+vmware.20^*
configmap-reload	v0.7.1+vmware.2
containerd	v1.6.18+vmware.1^*
contour	v1.23.5+vmware.1-tkg.1^*
coredns	v1.9.3_vmware.8^*
crash-diagnostics	v0.3.7+vmware.6
cri_tools	v1.24.2+vmware.8^*
csi_attacher	v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1
csi_livenessprobe	v2.7.0+vmware.1, v2.6.0+vmware.1, v2.5.0+vmware.1, v2.4.0+vmware.1
csi_node_driver_registrar	v2.5.1+vmware.1, v2.5.0+vmware.1, v2.3.0+vmware.1
csi_provisioner	v3.2.1+vmware.1, v3.1.0+vmware.2, v3.0.0+vmware.1
dex	v2.35.3_vmware.3^*
envoy	v1.24.5_vmware.1^*
external-dns	v0.12.2+vmware.5^*
external-snapshotter	v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.9^*
fluent-bit	v1.9.5+vmware.1
gangway	v3.2.0+vmware.2
grafana	v7.5.17+vmware.2
guest-cluster-auth-service	v1.3.0^*
harbor	v2.7.1+vmware.1^*
image-builder	v0.1.13+vmware.3^*
image-builder-resource-bundle	v1.25.7+vmware.2-tkg.1^*
imgpkg	v0.31.1+vmware.1
jetstack_cert-manager	v1.10.2+vmware.1^*
k8s-sidecar	v1.15.6+vmware.5^, v1.12.1+vmware.6^
k14s_kapp	v0.53.2+vmware.1
k14s_ytt	v0.43.1+vmware.1
kapp-controller	v0.41.7_vmware.1-tkg.1^*
kbld	v0.35.1+vmware.1
kube-state-metrics	v2.7.0+vmware.2^*
kube-vip	v0.5.7+vmware.2^*
kube-vip-cloud-provider^*	v0.0.4+vmware.4^*
kube_rbac_proxy	v0.11.0+vmware.2
kubernetes	v1.25.7+vmware.2^*
kubernetes-csi_external-resizer	v1.4.0+vmware.1, v1.3.0+vmware.1
kubernetes-sigs_kind	v1.25.7+vmware.2-tkg.2_v0.17.0^*
kubernetes_autoscaler	v1.25.0+vmware.1^*
load-balancer-and-ingress-service (AKO)	v1.9.3_vmware.1-tkg.1^*
metrics-server	v0.6.2+vmware.1
multus-cni	v3.8.0+vmware.3^*
pinniped	v0.12.1_vmware.3-tkg.4^*
pinniped-post-deploy	v0.12.1+vmware.2-tkg.3
prometheus	v2.37.0+vmware.3^*
prometheus_node_exporter	v1.4.0+vmware.3^*
pushgateway	v1.4.3+vmware.3^*
sonobuoy	v0.56.16+vmware.1^*
standalone-plugins-package	v0.29.0-dev-standalone-plugins^*
tanzu-framework	v0.29.0^*
tanzu-framework-addons	v0.29.0^*
tanzu-framework-management-packages	v0.29.0-tf^*
tkg-bom	v2.2.0^*
tkg-core-packages	v1.25.7+vmware.2-tkg.1^*
tkg-standard-packages	v2.2.0^*
tkg-storageclass-package	v0.29.0-tkg-storageclass^*
tkg_telemetry	v2.2.0+vmware.1^*
velero	v1.9.7+vmware.1^*
velero-mgmt-cluster-plugin^*	v0.1.0+vmware.1
velero-plugin-for-aws	v1.5.5+vmware.1^*
velero-plugin-for-csi	v0.3.5+vmware.1^*
velero-plugin-for-microsoft-azure	v1.5.5+vmware.1^*
velero-plugin-for-vsphere	v1.4.3+vmware.1^*
vendir	v0.30.1+vmware.1
vsphere_csi_driver	v2.7.1+vmware.2^*
whereabouts	v0.5.4+vmware.2^*

^* 이전 릴리스 이후의 새 구성 요소 또는 버전 범프를 나타냅니다. TKG v2.1.1은 v2.2.0 이전입니다.

TKG v2.2와 함께 제공되는 소프트웨어 구성 요소 버전의 전체 목록을 보려면 imgpkg를 사용하여 저장소 번들을 끌어온 다음 해당 컨텐츠를 나열합니다. TKG v2.1.1의 경우, 예:

imgpkg pull -b projects.registry.vmware.com/tkg/packages/standard/repo:v2.2.0 -o standard-2.2.0
cd standard-2.2.0/packages
tree

다음과 같은 로컬 BOM 파일도 패키지 버전을 나열하지만 최신이 아닐 수 있습니다.

~/.config/tanzu/tkg/bom/tkg-bom-v2.2.0.yaml
~/.config/tanzu/tkg/bom/tkr-bom-v1.25.7+vmware.1-tkg.1.yaml

지원되는 업그레이드 경로

TKG 업그레이드 경로에서 v2.2는 v2.1.1을 즉시 따릅니다.

v2.1.x에서만 Tanzu Kubernetes Grid v2.2.x로 업그레이드할 수 있습니다. v2.1.x 이전 버전에서 Tanzu Kubernetes Grid v2.2.x로 업그레이드하려면 먼저 v2.1.x로 업그레이드해야 합니다.

워크로드 클러스터에서 Kubernetes 버전을 업그레이드하는 경우 부 버전을 건너뛸 수 없습니다. 예를 들어 Tanzu Kubernetes 클러스터를 v1.23.x에서 v1.25.x로 직접 업그레이드할 수 없습니다. 클러스터를 v1.25.x로 업그레이드하기 전에 v1.23.x 클러스터를 v1.24.x로 업그레이드해야 합니다.

릴리스 날짜

Tanzu Kubernetes Grid v2.2 릴리스 날짜는 다음과 같습니다.

v2.2.0: 2023년 5월 9일

Tanzu Kubernetes Grid v2.2의 동작 변경

Tanzu Kubernetes Grid v2.2에는 최신 이전 릴리스인 v2.1.1과 비교하여 새로운 동작이 도입되었습니다.

향후 동작 변경 알림

이 섹션에서는 TKG v2.2 릴리스 후 향후 릴리스에 적용될 동작 변경 사항에 대한 사전 알림을 제공합니다.

VMware Tanzu Standard 저장소

중요
Tanzu Kubernetes Grid v2.2.x는 VMware Tanzu Standard 저장소가 릴리스의 일부로 패키지된 TKG의 최종 부 릴리스입니다. TKG v2.2.x 및 이전 릴리스에는 Tanzu 표준 저장소에 로그 전달, 수신 제어, 컨테이너 레지스트리 등의 기능을 추가하기 위해 클러스터에 배포할 수 있는 선택적 패키지 집합이 포함되어 있습니다. 향후 TKG v2.x 부 릴리스에서는 Tanzu CLI를 설치하고 관리 클러스터를 배포할 때 Tanzu Standard 저장소가 자동으로 다운로드되지 않습니다. 이 선택적 패키지 집합을 사용하려면 Tanzu CLI를 사용하여 수동으로 다운로드하고 추가합니다. 선택적 패키지를 TKG 릴리스에서 분리하면 VMware가 TKG 릴리스 외부에서 증분 패키지 업데이트를 제공하고 CVE에 보다 민감하게 반응할 수 있습니다.

사용 중단 알림

향후 TKG 릴리스에서는 Pinniped가 LDAP 제공자와 작업할 필요가 없으므로 Dex 구성 요소가 제거될 예정입니다. 이 변경 사항을 적용하면 LDAP 인증을 위한 다음과 같은 클러스터 구성 변수가 필요합니다. LDAP_BIND_DN 및 LDAP_BIND_PASSWORD. 자세한 내용은 구성 파일 변수 참조의 ID 제공자 - LDAP를 참조하십시오.

사용자 설명서

TKG 2.2 독립형 관리 클러스터 배포 및 관리에는 vSphere with Tanzu Supervisor에서 TKG를 사용하는 것과 관련이 없는 독립형 관리 클러스터와 관련된 항목이 포함되어 있습니다.

자세한 내용은 VMware Tanzu Kubernetes Grid 설명서 페이지에서 배포에 적합한 TKG 설명서 정의를 참조하십시오.

해결된 문제

이전 Tanzu Kubernetes Grid 릴리스의 알려진 문제로 기록된 다음 문제는 Tanzu Kubernetes Grid v2.2.0에서 해결되었습니다.

레거시 구성 파일에서 ClusterClass 구성 파일을 --dry-run와 함께 생성하면 빈 Antrea 구성이 포함됨

ANTREA_NODEPORTLOCAL 항목이 포함된 레거시 구성 파일과 함께 tanzu cluster create --dry-run -f를 사용하여 ClusterClass 구성 파일을 생성하면 레이블을 포함하지 않는 자동 생성된 Antrea 구성을 초래하므로 Antrea가 성공적으로 조정되지 않습니다.
패키지가 기본 기준선 PSA 프로파일을 준수하지 않음

TKG의 PSA 컨트롤러에서 지원되지 않는 기술 미리보기 상태에서 일부 TKG 패키지가 기본 baseline 프로파일을 준수하지 않습니다.
tanzu cluster create를 실행할 때 검증 오류

기본적으로 플랫 키-값 구성 파일을 tanzu cluster create의 --file 옵션에 전달할 경우 명령은 구성 파일을 Kubernetes-style 개체 규격 파일로 변환하고 종료합니다. 이 동작은 auto-apply-generated-clusterclass-based-configuration 기능에서 제어하며, 기본적으로 false로 설정되어 있습니다. 경우에 따라 --file 옵션에서 생성된 Kubernetes-style 개체 규격 파일을 tanzu cluster create에 전달하면 명령이 실패하고 다음과 유사한 오류가 발생합니다.
```
Error: workload cluster configuration validation failed...
```
이 오류는 --dry-run 옵션에서 생성된 Kubernetes-style 개체 규격 파일을 tanzu cluster create로 전달하는 경우에도 발생할 수 있습니다.
tanzu cluster create가 기본값이 아닌 Kubernetes 버전으로 생성된 클러스터 규격의 유효성을 올바르게 검사하지 않음

클래스 기반 클러스터 생성에 설명된 2단계 프로세스 중 하나를 사용하여 구성 파일에서 클래스 기반 워크로드 클러스터를 생성하고 첫 번째 단계에서 --tkr 값을 지정하여 클러스터를 기본값이 아닌 Kubernetes 버전으로 설정하면 유효성 검사 오류가 발생하면서 두 번째 단계가 실패할 수 있습니다.

알려진 문제

다음은 Tanzu Kubernetes Grid v2.2.x의 알려진 문제입니다. 후속 v2.2.x 패치 릴리스에서 해결된 v2.2.0에 있었던 모든 알려진 문제는 수정된 패치 릴리스의 해결된 문제에 있습니다.

관리 클러스터 문제 해결 및 워크로드 클러스터 문제 해결 또는 VMware 기술 자료 문서에서 자주 발생하는 문제에 대한 추가 솔루션을 찾을 수 있습니다.

패키지
클러스터 작업
네트워킹
ID 및 액세스 관리
스토리지
CLI
vSphere
AWS
Image Builder
AVS

패키지

NSX ALB v21.1.4 또는 이전 버전이 있는 vSphere 6.7에서 Grafana 설치가 실패함

NSX ALB v21.1.4 또는 이전 로드 밸런서 서비스로 사용하는 vSphere v6.7U3의 TKG v2.2 워크로드 클러스터에 Grafana v7.5.17 패키지를 설치할 수 없습니다.

해결 방법: 워크로드 클러스터가 Grafana 및 NSX ALB를 사용하는 경우 TKG를 v2.2로 업그레이드하기 전에 vSphere를 v7.0+로, NSX ALB를 v21.1.5+로 업그레이드하십시오.
실행 ID가 10000000+를 초과하면 Harbor CVE 내보내기가 실패할 수 있음

TKG v2.2용으로 패키지된 버전인 Harbor v2.7.1에는 실행 기본 키 자동 증분 ID가 10000000+로 증가할 때 CVE가 "404 페이지를 찾을 수 없음" 오류와 함께 내보내기를 보고하는 알 수 없는 문제가 있습니다.

이 Harbor 문제는 이후 버전의 TKG에 포함될 예정인 Harbor의 이후 버전에서 해결되었습니다.
Harbor의 Notary 구성 요소에 있는 Golang 취약성

CVE-2021-33194는 Notary에 있습니다. Notary 구성 요소는 Harbor v2.6+에서 더 이상 사용되지 않으며 Harbor v2.6.0 릴리스 정보에 설명된 대로 향후 릴리스에서 제거될 예정입니다. VMware는 컨테이너 서명 및 확인을 위해 Notary 대신 Sigstore Cosign을 사용하는 것을 권장합니다.
단일 노드 클러스터에 대한 표준 저장소 추가 실패

tanzu package repository add를 실행하여 tanzu-standard 저장소를 vSphere의 단일 노드 클러스터(기술 미리보기)에 설명된 유형의 단일 노드 클러스터에 추가하지 못할 수 있습니다.

이 문제는 단일 노드 클러스터가 cert-manager를 코어 추가 기능으로 부팅하여 tanzu-standard 저장소의 다른 cert-manager와 충돌하기 때문에 발생합니다.

해결 방법: tanzu-standard 저장소를 추가하기 전에 cert-manager 설치에 설명된 대로 cert-manager 패키지 주석을 패치합니다.

클러스터 작업

Antrea CNI를 사용하여 현재가 아닌 TKr 버전을 기준으로 하는 새 워크로드 클러스터를 생성할 수 없음

Antrea CNI를 사용하고 이전 버전 TKG와 함께 제공된 Kubernetes 버전(예: Kubernetes v1.23.10)을 실행하는 새 워크로드 클러스터를 생성할 수 없습니다. 이는 Tanzu Kubernetes Grid v2.2에서 지원되는 Kubernetes 버전에 있는 TKG v1.6.1의 기본 Kubernetes 버전입니다.

해결 방법: Kubernetes 1.25.7, 1.24.11 또는 1.23.17을 실행하는 워크로드 클러스터를 생성합니다. Kubernetes 프로젝트는 현재 부 버전의 최신 패치 버전에서 구성 요소를 실행할 것을 권장합니다.
클래스 기반 클러스터의 자동조정기에는 수동 주석이 필요합니다.

클러스터 API 레이블 전파 문제로 인해 클래스 기반 워크로드 클러스터용 클러스터 구성 파일의 AUTOSCALER_MIN_SIZE_* 및 AUTOSCALER_MAX_SIZE_* 설정이 클러스터의 MachineDeployment 개체에 설정되지 않습니다.

해결 방법: 클러스터 자동조정기를 사용하도록 설정한 상태에서 클래스 기반 워크로드 클러스터를 생성한 후 최소 및 최대 크기 주석 수동 추가에 설명된 대로 각 AZ의 최소 및 최대 시스템 수 설정을 수동으로 추가합니다.
노드 풀 labels 및 기타 구성 속성을 변경할 수 없음

구성 속성에 나열된 대로 기존 노드 풀의 labels, az, nodeMachineType 또는 vSphere 속성을 추가하거나 변경할 수 없습니다.

해결 방법: 원하는 속성을 사용하여 클러스터에 새 노드 풀을 생성하고, 워크로드를 새 노드 풀로 마이그레이션하고, 원래 노드 풀을 삭제합니다.
관리 클러스터 제어부 노드를 짝수로 확장할 수 없음

관리 클러스터에서 tanzu cluster scale을 실행하고 짝수를 --controlplane-machine-count 옵션에 전달하는 경우 TKG는 제어부 노드의 크기를 조정하지 않으며 CLI가 오류를 출력하지 않습니다. 쿼럼을 유지하려면 제어부 노드 수가 항상 홀수여야 합니다.

해결 방법: 제어부 노드 수를 짝수로 조정하지 마십시오.
클래스 기반 클러스터 이름에는 로드 밸런서 서비스 또는 수신 컨트롤러로 NSX ALB가 있는 25자로 제한

NSX ALB(Advanced Load Balancer)가 독립 실행형 관리 클러스터가 있는 클래스 기반 클러스터의 로드 밸런서 서비스 또는 수신 컨트롤러로 사용되는 경우, 애플리케이션 이름에는 클러스터 이름과 AKO 패키지의 내부 이름과 load-balancer-and-ingress-service가 모두 포함됩니다. 결합된 이름이 Avi Controller 애플리케이션에 대한 64자 제한을 초과하면 tanzu cluster create 명령이 avi-system 네임스페이스를 찾을 수 없습니다.

해결 방법: NSX ALB를 로드 밸런서 또는 수신 컨트롤러로 사용하는 경우 클래스 기반 클러스터 이름 길이를 25자 이하로 제한합니다.

네트워킹

참고
v4.0 이상의 경우 VMware NSX-T Data Center 이름이 "VMware NSX"로 변경됩니다.

IPv6 네트워킹은 vSphere 8에서 지원되지 않습니다.

TKG v2.2는 vSphere 8에서 IPv6 네트워킹을 지원하지 않지만 IPv6 네트워킹에 설명된 대로 vSphere 7에서 Kube-Vip를 사용하는 단일 스택 IPv6 네트워킹을 지원합니다.

해결 방법: vSphere IPv6 환경에서 TKG가 필요하거나 현재 사용 중인 경우 vSphere 8로 업그레이드하거나 설치하지 마십시오.
NSX ALB NodePortLocal 수신 모드는 관리 클러스터에서 지원되지 않습니다.

TKG v2.2에서는 관리 클러스터로의 트래픽에 대해 수신 모드 NodePortLocal을 사용하여 ALB(NSX Advanced Load Balancer)를 서비스 유형으로 실행할 수 없습니다.

이 문제는 NodePortLocal 모드의 L7 수신에 설명된 대로 워크로드 클러스터에 대한 NodePortLocal 수신 지원에는 영향을 주지 않습니다.

해결 방법: NodePort 또는 ClusterIP로 설정된 AVI_INGRESS_SERVICE_TYPE으로 관리 클러스터를 구성합니다. 기본값은 NodePort입니다.
이전 NSX-T 버전 및 Photon 3 또는 Linux 커널 5.8 VM이 있는 Ubuntu에서 관리 클러스터 생성이 실패하거나 성능이 느려짐

다음 인프라 및 구성을 사용하여 관리 클러스터를 배포하면 실패하거나 포드 간 트래픽이 제한됨:
- 다음 버전의 NSX-T가 있는 vSphere:
  - 고급 데이터 경로가 활성화된 v3.1.3 NSX-T
  - v3.1.3보다 낮은 v3.1.x NSX-T
  - v3.0.2 핫 패치보다 낮은 v3.0.x NSX-T
  - NSX-T v2.x. 여기에는 NSX-T v2.5를 사용하는 AVS(Azure VMware Solution) v2.0이 포함됩니다.
- 기본 이미지: linux 커널 5.8이 있는 Photon 3 또는 Ubuntu
이 조합은 이전 버전의 NSX-T Antrea CNI 간에 체크섬 문제를 노출합니다.

TMC: 관리 클러스터가 TMC(Tanzu Mission Control)에 등록된 경우 이 문제에 대한 해결 방법은 없습니다. 그렇지 않으면 아래의 해결 방법을 참조하십시오.

해결 방법:
- ANTREA_DISABLE_UDP_TUNNEL_OFFLOAD가 "true"로 설정된 상태로 워크로드 클러스터를 배포합니다. 이 설정은 Antrea의 UDP 체크섬 오프로딩을 비활성화하여 일부 언더레이 네트워크 및 물리적 NIC 네트워크 드라이버의 알려진 문제를 방지합니다.
- 고급 데이터 경로를 비활성화하지 않은 NSX-T v3.0.2 핫 패치, v3.1.3 이상으로 업그레이드
- Linux 커널 5.9 이상에서 Ubuntu 기본 이미지를 사용합니다.

ID 및 액세스 관리

독립형 관리 클러스터를 다시 생성해도 Pinniped 인증이 복원되지 않음

관리 및 워크로드 클러스터 인프라 백업 및 복원 관리(기술 미리보기)에 설명된 대로 독립형 관리 클러스터를 다시 생성한 후에는 Pinniped 인증을 통해 워크로드 클러스터에 로그인할 수 없습니다.

해결 방법: 관리 클러스터를 다시 생성한 후 기존 배포에서 ID 관리 활성화 및 구성에 설명된 대로 ID 관리를 다시 구성합니다.
Pinniped 구성 요소의 Golang 취약성

CVE-2022-41723는 Pinniped v0.12.1에 있습니다. 이 취약성을 악용하면 Pinniped 서비스의 DDoS 공격이 발생할 수 있습니다. 악용 확률을 낮게 줄이려면 수신 필터링을 사용하여 회사 VPN CIDR과 같은 알려진 IP 주소의 트래픽만 허용할 수 있습니다. 이 취약성은 향후 Tanzu Kubernetes Grid 릴리스에서 해결될 예정입니다.
감독자 배포 워크로드 클러스터에 kubeconfig를 생성하고 사용하면 "알 수 없는 플래그" 오류가 발생함

Tanzu CLI v0.25.0 이상에서 cluster 플러그인은 인수 --concierge-is-cluster-scoped를 포함할 수 있는 kubeconfig 파일을 생성합니다. Tanzu CLI v0.29.0 pinniped-auth 플러그인이 이 인수를 인식하지 못합니다. 이 임시 회귀는 후속 버전에서 수정되었습니다.

vSphere 8.0은 v0.25.0 cluster 플러그인을 포함하므로 TKG v2.2의 버전인 CLI v0.29.0에서 Supervisor 배포 클러스터에 연결하면 다음 오류가 발생할 수 있습니다.
```
Error: unknown flag: --concierge-is-cluster-scoped
Unable to connect to the server: getting credentials: exec: executable tanzu failed with exit code 1
```
해결 방법: kubeconfig 파일에서 --concierge-is-cluster-scoped를 설정하는 args 아래의 줄을 제거합니다.

스토리지

워크로드 클러스터가 여러 데이터스토어에 스토리지를 분산할 수 없음

데이터스토어 클러스터를 사용하는 클러스터 배포에 설명된 대로 워크로드 클러스터가 여러 데이터스토어에 스토리지를 분산하도록 설정할 수 없습니다. 워크로드 클러스터의 스토리지 정책의 기반으로 데이터스토어 클러스터의 여러 데이터스토어에 태그를 지정하는 경우 워크로드 클러스터는 데이터스토어 중 하나만 사용합니다.

해결 방법: 없음

Tanzu CLI

HTTP/HTTPS 프록시 암호에는 영숫자가 아닌 문자를 사용할 수 없습니다.

CLI를 사용하여 관리 클러스터를 배포할 때 영숫자가 아닌 문자 # ` ^ | / ? % ^ { [ ] } \ " < >는 암호에서 사용할 수 없습니다. 또한 UI를 사용하여 관리 클러스터를 배포할 때는 HTTP/HTTPS 프록시 암호에서 영숫자가 아닌 문자를 사용할 수 없습니다.

해결 방법: CLI와 함께 관리 클러스터를 배포할 경우 # ` ^ | / ? % ^ { [ ] } \ " < >를 제외한 비-영숫자를 사용할 수 있습니다.
ARM 프로세서가 있는 macOS 시스템에서 TANZU CLI가 작동하지 않음

Tanzu CLI v0.11.6은 Finder > 이 Mac 정보(About This Mac) > 개요(Overview)에서 식별된 대로 ARM(Apple M1) 칩이 탑재된 macOS 시스템에서 작동하지 않습니다.

해결 방법: Linux 또는 Windows OS가 있는 부트스트랩 시스템 또는 Intel 프로세서가 탑재된 macOS 시스템을 사용합니다.
Tanzu CLI에 tanzu management-cluster osimage 표시

management-cluster 명령 그룹은 tanzu management-cluster osimage를 표시합니다. 이 기능은 현재 개발 중이며 향후 사용할 수 있습니다.

해결 방법: tanzu management-cluster osimage를 사용하지 마십시오.
tanzu package available get의 --default-values-file-output 옵션이 불완전한 Harbor 패키지용 구성 템플릿 파일을 출력

tanzu package available get harbor.tanzu.vmware.com/PACKAGE-VERSION --default-values-file-output FILE-PATH가 실행되면 Harbor 패키지용 구성 템플릿 파일이 생성됩니다. 전체 파일을 가져오려면 서비스 레지스트리용 Harbor 설치에 설명된 대로 imgpkg pull 명령을 사용합니다.

vSphere

small 노드로 생성된 노드 풀이 Provisioning에서 멈출 수 있음

small로 구성된 노드 SIZE로 생성된 노드 풀이 Provisioning 상태에서 중단되고 Running으로 진행하지 않을 수 있습니다.

해결 방법: 최소 medium 크기의 노드로 노드 풀을 구성합니다.

AWS

CAPA 리소스 태그 지정 문제로 인해 AWS 관리 클러스터 배포 및 업그레이드 중에 조정 실패가 발생합니다.

업스트림 CAPA(클러스터 API 제공자 AWS)의 리소스 태그 지정 문제로 인해 오프라인 배포가 ResourceTagging API에 액세스할 수 없으므로 관리 클러스터 생성 또는 업그레이드 중에 조정에 실패합니다.

해결 방법: 오프라인 AWS 환경에서 tanzu mc create 또는 tanzu mc upgrade를 실행하기 전에 로컬 환경 또는 관리 클러스터 구성 파일에서 EXP_EXTERNAL_RESOURCE_GC=false를 설정합니다.
AWS의 워크로드 클러스터 노드 풀은 독립형 관리 클러스터와 동일한 가용성 영역에 있어야 합니다.

관리 클러스터가 있는 위치와 다른 az 구성된 노드 풀을 생성할 때 새 노드 풀이 tanzu cluster node-pool list에 나열된 대로 ScalingUp 상태로 멈춰 있고 Ready 상태에 도달하지 않을 수 있습니다.

해결 방법: 독립형 관리 클러스터와 동일한 AZ에 노드 풀만 생성합니다.
클러스터가 Tanzu Kubernetes Grid 함께 배포되지 않은 네트워킹 리소스를 사용하는 경우 AWS에서 클러스터 삭제가 실패합니다.

tanzu cluster delete 및 tanzu management-cluster delete 명령은 Tanzu Kubernetes Grid 배포 프로세스와 독립적으로 AWS Cloud Controller Manager에서 생성된 네트워킹 리소스를 사용하는 클러스터에 중단되었을 수 있습니다. 이러한 리소스에는 Kubernetes AWS 클라우드 공급자 설명서의 서비스 컨트롤러에 나열된 로드 밸런서 및 기타 네트워킹 서비스가 포함될 수 있습니다.

자세한 내용은 클러스터 API 문제 해체 시 service Type=Loadbalancer의 워크로드 클러스터 드레인을 참조하십시오.

해결 방법: kubectl delete를 사용하여 클러스터에서 LoadBalancer 유형의 서비스를 삭제합니다. 그렇지 않으면 AWS 콘솔을 사용하여 Cloud Controller 관리자가 이 서비스에 생성한 LoadBalancer 및 SecurityGroup 개체를 수동으로 삭제합니다.

주의
key: sigs.k8s.io/cluster-api-provider-aws/cluster/CLUSTER-NAME, value: owned 태그가 있는 Tanzu 의해 관리되는 로드 밸런서 또는 보안 그룹을 삭제하지 마십시오.

Azure

스토리지 볼륨이 전용 끝점이 있는 계정을 사용하는 경우 클러스터 삭제가 실패함

관리되지 않는 리소스 그룹의 Azure 워크로드 클러스터를 사용하면 Azure CSI 드라이버가 개인 끝점이 있는 스토리지 계정을 사용하는 PV(영구 볼륨)를 생성하면 PV가 삭제되면 삭제되지 않는 privateEndpoint 및 vNet 리소스를 생성합니다. 그 결과 클러스터 삭제가 subnets failed to delete. err: failed to delete resource ... Subnet management-cluster-node-subnet is in use와 같은 오류와 함께 실패합니다.

해결 방법: Azure 클러스터를 삭제하기 전에 스토리지 계정 개인 끝점에 대한 네트워크 인터페이스를 수동으로 삭제합니다.
1. 브라우저의 경우 Azure Resource Explorer에 로그인합니다.
2. 왼쪽에서 구독(subscriptions)을 클릭하고 구독을 확장합니다.
3. 구독에서 왼쪽의 resourceGroups을 확장하고 TKG 배포의 리소스 그룹을 확장합니다.
4. 리소스 그룹에서 제공자(providers) > Microsoft.Network > networkinterfaces를 확장합니다.
5. networkinterfaces에서 삭제하지 못하는 NIC 리소스를 선택합니다.
6. 맨 위에 있는 읽기/쓰기(Read/Write) 버튼을 클릭한 다음 바로 아래에 있는 작업(게시, 삭제)(Actions)(POST, DELETE) 탭을 클릭합니다.
7. 삭제(Delete)를 클릭합니다.
8. NIC가 삭제되면 Azure 클러스터를 삭제합니다.

Windows

Windows 작업자가 인터넷 제한 환경에서 지원되지 않음

VMware는 프록시 또는 에어갭 환경에서 Windows Worker 노드가 있는 TKG 워크로드 클러스터를 지원하지 않습니다.

해결 방법: VMware 담당자에게 문의하십시오. 일부 TKG 사용자는 Windows 사용자 지정 이미지를 구축하고 오프라인 환경에서 Windows 작업자와 함께 워크로드 클러스터를 실행합니다(예: 이 비공식 저장소에 설명된 대로).

Image-Builder

이미지 빌드 중 무시할 수 있는 goss 테스트 실패

Kubernetes Image Builder를 실행하여 사용자 지정 Linux 사용자 지정 시스템 이미지를 생성하면 goss 테스트 python-netifaces, python-requests, ebtables에 실패합니다. 명령 출력이 실패를 보고합니다. 오류는 무시해도 됩니다. 성공적인 이미지 빌드를 방지하지는 않습니다.

AVS

VSPHERE CSI 볼륨 삭제가 AVS에서 실패할 수 있음

AVS(Azure vSphere Solution)에서 vSphere CSI PV(영구 볼륨) 삭제가 실패할 수 있습니다. PV를 삭제하려면 cns.searchable 권한이 필요합니다. AVS의 기본 관리자 계정인 [email protected]이 사용 권한으로 생성되지 않습니다. 자세한 내용은 vSphere 역할 및 권한을 참조하십시오.

해결 방법: AVS에서 vSphere CSI PV를 삭제하려면 Azure 지원에 문의하십시오.