VMware Tanzu Kubernetes Grid v2.1 Release Notes

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

TKG v2.1은 버전이 지정된 TKG 독립형 관리 클러스터를 배포하는 다운로드 가능한 Tanzu CLI 패키지로 배포됩니다. TKG v2.1은 vSphere, AWS, Azure 등 여러 인프라에서 실행할 수 있는 독립형 관리 클러스터를 사용하여 클래스 기반 워크로드 클러스터 생성 및 관리를 지원하는 TKG의 첫 번째 버전입니다.

vSphere 8에서 Tanzu Kubernetes Grid v2.x 및 vSphere with Tanzu Supervisor

중요
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.1 및 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.1.x에는 다음과 같은 새로운 기능이 포함되어 있습니다.

Tanzu Kubernetes Grid v2.1.1

Tanzu Kubernetes Grid v2.1.1의 새로운 기능:

TKG 독립형 관리 클러스터 및 해당 워크로드 클러스터가 있는 vSphere 8에서 NSX Advanced Load Balancer v22.1.2 이상을 사용하도록 지원합니다.
TKG v2.1.1의 FIPS 버전을 설치할 수 있습니다. 자세한 내용은 FIPS 지원 버전을 참조하십시오.
구성 변수:
- 시스템 상태 점검: MHC_MAX_UNHEALTHY_CONTROL_PLANE 및 MHC_MAX_UNHEALTHY_WORKER_NODE. 자세한 내용은 구성 파일 변수 참조의 시스템 상태 점검을 참조하십시오.
- 사용자 지정 인증서가 있는 tdnf 서버 지원: CUSTOM_TDNF_REPOSITORY_CERTIFICATE(기술 미리보기). 자세한 내용은 구성 파일 변수 참조의 노드 구성을 참조하십시오.
- 노드 수준 프록시 설정 지원: TKG_NODE_SYSTEM_WIDE_PROXY(기술 미리보기). 자세한 내용은 구성 파일 변수 참조의 프록시 구성을 참조하십시오.

Tanzu Kubernetes Grid v2.1.0

Tanzu Kubernetes Grid v2.1.0의 새로운 기능:

TKG 2.x 지원: 독립형 관리 클러스터가 있는 vSphere, AWS 또는 Azure에서는 워크로드 클러스터 유형에 설명된 대로 클래스 기반 클러스터를 구성하고 생성합니다.
TKG v2.1.0의 FIPS 버전을 설치할 수 있습니다. 자세한 내용은 FIPS 지원 버전을 참조하십시오.
Tanzu CLI:
- package 플러그인은 기본적으로 kctrl 스타일의 명령을 사용합니다. Tanzu CLI 명령 참조에서 Tanzu 패키지를 참조하십시오.
- isolated-cluster 플러그인 download-bundle 및 upload-bundle 명령은 인터넷 제한 환경 준비에 설명된 대로 TKG에 필요한 모든 컨테이너 이미지를 검색하고 전송합니다.
- tanzu cluster list의 -A 및 --all-namespaces 옵션에는 관리 클러스터에서 관리되고 사용자에게 기본 네임스페이스뿐만 아니라 View 사용 권한이 있는 모든 네임스페이스의 클러스터가 포함됩니다.
- context 명령 그룹을 사용하면 대상 서버와 적용할 kubeconfig를 포함하는 Tanzu CLI의 컨텍스트를 설정하고 관리할 수 있습니다. Tanzu CLI 명령 참조에서 tanzu context를 참조하십시오.
  - 이후 버전에서는 tanzu context 명령에 따라 tanzu login 명령을 더 이상 사용하지 않습니다.
- Target 범주는 아래의 Tanzu Kubernetes Grid v2.1 변경 사항에 설명된 대로 CLI 동작을 변경하고 나중에 사용하도록 예약된 기능을 추가합니다.
- auto-apply-generated-clusterclass-based-configuration 기능은 레거시 클러스터 구성 파일을 tanzu cluster create에 전달할 때 Tanzu CLI에서 생성된 클래스 기반 클러스터 구성을 자동으로 적용합니다. 이 기능은 기본적으로 false로 설정됩니다. Tanzu CLI 아키텍처 및 구성의 기능을 참조하십시오.
- allow-legacy-cluster 기능을 사용하면 계획 기반 클러스터를 생성할 수 있습니다. 이 기능은 기본적으로 false로 설정됩니다. Tanzu CLI 아키텍처 및 구성의 기능을 참조하십시오.
- tanzu mc credentials update 및 tanzu cluster credentials update 명령은 Azure 옵션을 추가합니다. 여기에는 --azure-client-id, --azure-client-secret 및 --azure-tenant-id가 포함됩니다.
다음 클러스터 구성 변수는 구성 파일 변수 참조에 설명된 대로 클래스 기반 클러스터 및 독립형 관리 클러스터에 대해 지원됩니다.
- 노드 구성: CONTROL_PLANE_NODE_LABELS, CONTROL_PLANE_NODE_NAMESERVERS, CONTROL_PLANE_NODE_SEARCH_DOMAINS, WORKER_NODE_NAMESERVERS, WORKER_NODE_SEARCH_DOMAINS
- ExtraArgs 속성: APISERVER_EXTRA_ARGS, CONTROLPLANE_KUBELET_EXTRA_ARGS, ETCD_EXTRA_ARGS, KUBE_CONTROLLER_MANAGER_EXTRA_ARGS, KUBE_SCHEDULER_EXTRA_ARGS, WORKER_KUBELET_EXTRA_ARGS
- 속도 제한 및 동기화: NTP_SERVERS, APISERVER_EVENT_RATE_LIMIT_CONF_BASE64
클러스터는 제어부 노드 VM 인증서를 자동으로 갱신할 수 있습니다. 제어부 노드 인증서 자동 갱신을 참조하십시오.
(vSphere) 다중 OS 워크로드 클러스터 배포에 설명된 대로 Windows 및 Linux 기반 Worker 노드를 모두 실행하는 다중 OS 워크로드 클러스터를 배포할 수 있습니다. 이 릴리스에서는 Windows 워크로드 클러스터가 다중 OS 워크로드 클러스터로 대체됩니다. 자세한 내용은 Tanzu Kubernetes Grid v2.1의 동작 변경을 참조하십시오.
- vSphere에서 여러 가용성 영역에 워크로드 클러스터 배포(기술 미리보기)에 설명된 대로 여러 가용성 영역에 Worker를 사용하여 멀티 OS 워크로드 클러스터를 배포할 수 있습니다.
(vSphere) 클래스 기반 워크로드 클러스터는 할당된 IP 풀을 통해 IPAM(클러스터 내 IP 주소 관리)으로 구성할 수 있어 노드 수 또는 인스턴스가 변경될 때 DHCP 예약을 구성할 필요가 없습니다.
(vSphere) 클러스터 노드 Machine 개체 레이블은 nodeSelector를 사용하여 특수 하드웨어에서 특정 워크로드를 실행하도록 지원하기 위해 ESXi 호스트의 주소를 식별합니다.
(vSphere) Ubuntu OVA 이미지는 부팅에 UEFI(Unified Extensible Firmware Interface) 모드를 사용하여 기존 BIOS 펌웨어 모드를 대체합니다. UEFI 모드는 GPU(그래픽 처리 장치) 워크로드를 사용하도록 설정하고 노드 보안을 향상시킵니다. Ubuntu의 UEFI에 대한 자세한 내용은 Ubuntu 설명서의 UEFI를 참조하십시오.
Kube-VIP를 워크로드의 L4 LoadBalancer 서비스로 사용할 수 있습니다. Kube-VIP 로드 밸런서(기술 미리보기)를 참조하십시오.
vSphere의 단일 노드 클러스터(기술 미리보기)에 설명된 대로 에지 애플리케이션을 위해 단일 ESXi 호스트에서 호스팅된 워크로드와 제어부 인프라를 모두 실행하는 단일 노드 워크로드 클러스터를 배포할 수 있습니다.
- 설치 공간을 최소화하는 tiny TKr를 기준으로 최소 단일 노드 클러스터를 배포할 수 있습니다.
관리 및 워크로드 클러스터 인프라 백업 및 복원(기술 미리보기)에 설명된 대로 클러스터 인프라를 백업하고 배포할 수 있습니다.
포드 보안 승인 컨트롤러(기술 미리보기)에 설명된 대로 네임스페이스에 설명된 대로 포드 보안 정책을 교체하기 위한 PSA(포드 보안 승인) 컨트롤러를 지원합니다.

Tanzu Kubernetes Grid v2.1에서 지원되는 Kubernetes 버전

각 버전의 Tanzu Kubernetes Grid 관리 클러스터의 Kubernetes 버전과 Tanzu Kubernetes 릴리스(TKr)로 배포되는 추가 Kubernetes 버전에 대한 지원을 추가합니다.

알려진 문제에 명시된 것을 제외하고, 모든 버전의 Tanzu Kubernetes Grid 이전 두 부 줄의 모든 TKr 버전을 지원합니다. 예를 들어 TKG v2.1.x는 아래에 나열된 Kubernetes 버전 v1.23.x 및 v1.22.x를 지원하지만 v1.21.x 이하 버전은 지원하지 않습니다.

Tanzu Kubernetes Grid 버전	관리 클러스터 Kubernetes 버전	제공된 Kubernetes(TKr) 버전
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
1.5.4	1.22.9	1.22.9, 1.21.11, 1.20.15
1.5.3	1.22.8	1.22.8, 1.21.11, 1.20.15
1.5.2, 1.5.1, 1.5.0	1.22.5	1.22.5, 1.21.8, 1.20.14

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

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

	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.28.1
클러스터 생성 및 관리	코어 클러스터 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.6)
컨테이너 네트워킹	Antrea(v1.7.2), Calico(v3.24.1)
컨테이너 레지스트리	Harbor(v2.6.3)
수신	NSX Advanced Load Balancer Essentials 및 Avi 컨트롤러 **** (v21.1.3- v21.1.6, v22.1.1, v22.1.2), Contour (v1.22.3)	Contour(v1.22.3)	Contour(v1.22.3)
스토리지	vSphere 컨테이너 스토리지 인터페이스(v2.5.2*) 및 vSphere 클라우드 네이티브 스토리지	Amazon EBS CSI 드라이버(v1.8.0) 및 트리 내 클라우드 제공자	Azure 디스크 CSI 드라이버(v1.19.0), Azure 파일 CSI 드라이버(v1.21.0), 트리 내 클라우드 제공자
인증	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.5)

* vsphere_csi_driver 버전입니다. Tanzu Kubernetes Grid v1.6 릴리스에 포함된 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 이상이 필요합니다.

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

구성 요소 버전

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

구성 요소	TKG v2.1.1	TKG v2.1.0
aad-pod-identity	v1.8.13+vmware.2^*	v1.8.13+vmware.1^*
addons-manager	v2.1+vmware.1-tkg.3	v2.1+vmware.1-tkg.3
ako-operator	v1.7.0+vmware.3	v1.7.0+vmware.3^*
alertmanager	v0.24.0+vmware.2^*	v0.24.0+vmware.1
antrea	v1.7.2+vmware.1-advanced	v1.7.2+vmware.1-advanced^*
aws-ebs-csi-driver	v1.8.0+vmware.2	v1.8.0+vmware.2^*
azuredisk-csi-driver	v1.19.0+vmware.1	v1.19.0+vmware.1^*
azurefile-csi-driver^*	v1.21.0+vmware.1	v1.21.0+vmware.1
calico_all	v3.24.1+vmware.1	v3.24.1+vmware.1^*
capabilities-package	v0.28.1-dev-capabilities^*	v0.28.0-dev-capabilities^*
carvel-secretgen-controller	v0.11.2+vmware.1	v0.11.2+vmware.1^*
cloud-provider-azure	v1.1.26+vmware.1, v1.23.23+vmware.1, v1.24.10+vmware.1	v1.1.26+vmware.1^, v1.23.23+vmware.1^, v1.24.9+vmware.1^*
cloud_provider_vsphere	v1.24.3+vmware.1	v1.24.3+vmware.1^*
cluster-api-provider-azure	v1.6.3_vmware.1^*	v1.6.1_vmware.1^*
cluster_api	v1.2.8+vmware.1	v1.2.8+vmware.1^*
cluster_api_aws	v2.0.2+vmware.1	v2.0.2+vmware.1^*
cluster_api_vsphere	v1.5.3+vmware.1l^*	v1.5.1+vmware.1l^*
cni_plugins	v1.1.1+vmware.18^*	v1.1.1+vmware.16^*
configmap-reload	v0.7.1+vmware.2^*	v0.7.1+vmware.1
containerd	v1.6.6+vmware.3^*	v1.6.6+vmware.1^*
contour	v1.22.3+vmware.1	v1.22.3+vmware.1^*
coredns	v1.8.6+vmware.17^*	v1.8.6+vmware.15^*
crash-diagnostics	v0.3.7+vmware.6	v0.3.7+vmware.6^*
cri_tools	v1.23.0+vmware.8^*	v1.23.0+vmware.7^*
csi_attacher	v3.5.0+vmware.1, v3.4.0+vmware.1, v3.3.0+vmware.1	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	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	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	v3.2.1+vmware.1^*, v3.1.0+vmware.2, v3.0.0+vmware.1
dex	v2.35.3+vmware.2	v2.35.3+vmware.2^*
envoy	v1.23.3+vmware.2	v1.23.3+vmware.2^*
external-dns	v0.12.2+vmware.4	v0.12.2+vmware.4^*
external-snapshotter	v6.0.1+vmware.1, v5.0.1+vmware.1	v6.0.1+vmware.1, v5.0.1+vmware.1
etcd	v3.5.6+vmware.6^*	v3.5.6+vmware.3^*
fluent-bit	v1.9.5+vmware.1	v1.9.5+vmware.1^*
gangway	v3.2.0+vmware.2	v3.2.0+vmware.2
grafana	v7.5.17+vmware.1^*	v7.5.16+vmware.1
guest-cluster-auth-service	v1.2.0^*	v1.1.0^*
harbor	v2.6.3+vmware.1	v2.6.3+vmware.1^*
image-builder	v0.1.13+vmware.2	v0.1.13+vmware.2^*
image-builder-resource-bundle	v1.24.10+vmware.1-tkg.1^*	v1.24.9+vmware.1-tkg.1^*
imgpkg	v0.31.1+vmware.1	v0.31.1+vmware.1^*
jetstack_cert-manager	v1.10.1+vmware.1	v1.10.1+vmware.1^*
k8s-sidecar	v1.15.6+vmware.3^, v1.12.1+vmware.5^	v1.15.6+vmware.2, v1.12.1+vmware.3^*
k14s_kapp	v0.53.2+vmware.1	v0.53.2+vmware.1^*
k14s_ytt	v0.43.1+vmware.1	v0.43.1+vmware.1^*
kapp-controller	v0.41.5+vmware.1, v0.38.5+vmware.2	v0.41.5+vmware.1^, v0.38.5+vmware.2^
kbld	v0.35.1+vmware.1	v0.35.1+vmware.1^*
kube-state-metrics	v2.6.0+vmware.2^*	v2.6.0+vmware.1^*
kube-vip	v0.5.7+vmware.1	v0.5.7+vmware.1^*
kube-vip-cloud-provider^*	v0.0.4+vmware.2	v0.0.4+vmware.2
kube_rbac_proxy	v0.11.0+vmware.2	v0.11.0+vmware.2
kubernetes	v1.24.10+vmware.1^*	v1.24.9+vmware.1^*
kubernetes-csi_external-resizer	v1.4.0+vmware.1, v1.3.0+vmware.1	v1.4.0+vmware.1^*, v1.3.0+vmware.1
kubernetes-sigs_kind	v1.24.10+vmware.1-tkg.1_v0.17.0^*	v1.24.9+vmware.1-tkg.1_v0.17.0^*
kubernetes_autoscaler	v1.24.0+vmware.1	v1.24.0+vmware.1^*
load-balancer-and-ingress-service (AKO)	v1.8.2+vmware.1	v1.8.2+vmware.1^*
metrics-server	v0.6.2+vmware.1	v0.6.2+vmware.1^*
multus-cni	v3.8.0+vmware.2	v3.8.0+vmware.2^*
pinniped	v0.12.1+vmware.1-tkg.1	v0.12.1+vmware.1-tkg.1
pinniped-post-deploy	v0.12.1+vmware.2-tkg.3	v0.12.1+vmware.2-tkg.3^*
prometheus	v2.37.0+vmware.2^*	v2.37.0+vmware.1^*
prometheus_node_exporter	v1.4.0+vmware.2^*	v1.4.0+vmware.1^*
pushgateway	v1.4.3+vmware.2^*	v1.4.3+vmware.1
sonobuoy	v0.56.13+vmware.1	v0.56.13+vmware.1^*
standalone-plugins-package	v0.28.1-dev-standalone-plugins^*	v0.28.1-dev-standalone-plugins^*
tanzu-framework	v0.28.1^*	v0.28.0^*
tanzu-framework-addons	v0.28.1^*	v0.28.0^*
tanzu-framework-management-packages	v0.28.1-tf^*	v0.28.0-tf^*
tkg-bom	v2.1.1^*	v2.1.0^*
tkg-core-packages	v1.24.10+vmware.1-tkg.1^*	v1.24.9+vmware.1-tkg.1^*
tkg-standard-packages	v2.1.1^*	v2.1.0^*
tkg-storageclass-package	v0.28.1-tkg-storageclass^*	v0.28.0-tkg-storageclass^*
tkg_telemetry	v2.1.1+vmware.1^*	v2.1.0+vmware.1^*
velero	v1.9.5+vmware.1	v1.9.5+vmware.1^*
velero-mgmt-cluster-plugin^*	v0.1.0+vmware.1	v0.1.0+vmware.1
velero-plugin-for-aws	v1.5.3+vmware.1	v1.5.3+vmware.1^*
velero-plugin-for-csi	v0.3.3+vmware.1	v0.3.3+vmware.1^*
velero-plugin-for-microsoft-azure	v1.5.3+vmware.1	v1.5.3+vmware.1^*
velero-plugin-for-vsphere	v1.4.2+vmware.1	v1.4.2+vmware.1^*
vendir	v0.30.1+vmware.1	v0.30.1+vmware.1^*
vsphere_csi_driver	v2.6.2+vmware.2	v2.6.2+vmware.2^*
whereabouts	v0.5.4+vmware.1	v0.5.4+vmware.1^*

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

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

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

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

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

지원되는 업그레이드 경로

TKG 업그레이드 경로에서 v2.1은 v1.6을 즉시 따릅니다. TKG v2.0은 다운로드 가능한 TKG 버전이 아닙니다. 이 버전은 vSphere 8의 vSphere with Tanzu Supervisor에 내장된 TKG 버전입니다.

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

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

릴리스 날짜

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

v2.1.0: 2023년 1월 29일
v2.1.1: 2023년 3월 21일

Tanzu Kubernetes Grid v2.1의 동작 변경

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

--include-management-cluster 옵션을 사용하여 클러스터 목록을 tanzu cluster list 독립형 관리 클러스터를 나열하려면 -A 옵션이 필요합니다. -A 옵션을 사용하면 모든 네임스페이스의 클러스터가 나열됩니다.
Tanzu CLI package 플러그인은 기본적으로 kctrl 스타일의 명령을 사용합니다. Tanzu CLI 명령 참조의 kctrl이 포함된 Tanzu 패키지를 참조하십시오.
- TKG v1.6에서 package 플러그인은 기본적으로 아래의 kctrl 모드가 비활성화된 legacy 모드와 함께 실행됩니다.
- kctrl 모드 및 레거시 모드 명령은 다음과 다릅니다.
  - 패키지 구성용 기본값 파일을 생성하려면 kctrl 스타일 tanzu package available get 명령은 --default-values-file-output 대신 --generate-default-values-file 플래그를 사용합니다.
  - --create-namespace 플래그가 제거됩니다. -n 또는 --namespace를 사용하여 대상 네임스페이스를 지정하는 경우 네임스페이스가 이미 존재해야 합니다.
  - package repository update에 대해 --create 플래그가 제거됩니다.
  - --package-name 플래그의 이름이 package installed create 및 package install에 대해 --package로 변경됩니다.
  - package installed update에 대해 --install 플래그가 제거됩니다.
  - --verbose 글로벌 플래그가 제거됩니다.
  - --poll-interval 및 -poll-timeout 플래그의 이름이 --wait-interval 및 --wait-timeout으로 변경됩니다.
  - package available get 출력에서 패키지에 사용 가능한 버전이 추가 테이블에 나열됩니다.
  - package available list 출력에서 LATEST-VERSION 열이 제거되고 SHORT-DESCRIPTION이 기본적으로 표시되지 않습니다. --wide 플래그를 사용하여 표시합니다.
  - package repository list 출력에서 REPOSITORY 및 TAG 열은 소스 유형(예: SOURCE), 저장소 URL, 태그로 구성된 imgpkg 열로 대체됩니다.
- tanzu package 플러그인이 kctrl 모드를 비활성화한 상태에서 작동하는 방식에 대해서는 TKG v1.6 설명서의 CLI 관리 패키지 항목을 참조하십시오.
tanzu-standard 패키지 저장소가 클래스 기반 클러스터에 미리 설치되어 있지 않음. 패키지 저장소를 추가하려면 패키지 저장소 추가를 참조하십시오.
Tanzu CLI 관리 클러스터 생성 프로세스는 더 이상 새 VPC 생성을 지원하지 않습니다. 설치 관리자 인터페이스에는 새 VPC를 생성하는 옵션이 포함되지 않으며 클러스터 구성 파일은 지정된 CIDR에 대한 새 VPC를 생성하기 위한 AWS_* 옵션을 더 이상 지원하지 않습니다. 새 VPC를 사용하려면 AWS에 독립형 관리 클러스터를 배포하기 전에 AWS 콘솔을 사용하여 TKG 배포를 위한 VPC를 생성해야 합니다.
Tanzu CLI는 새 대상 추상화를 사용하여 다른 명령 그룹을 명령이 적용되는 서버 유형과 연결합니다. tanzu context list 명령은 --target 플래그를 사용하여 context 유형 같은 개념을 나타냅니다. 명령 그룹이 CLI 플러그인을 기반으로 하기 때문입니다.
- Kubernetes 클러스터의 명령을 정의하는 플러그인에는 대상이 있습니다. k8s
- TMC 명령의 명령을 정의하는 플러그인에는 나중에 사용할 수 있도록 예약된 대상 tmc가 있습니다.
- 컨텍스트에 독립적인 명령을 정의하는 플러그인에는 대상이 없습니다.
- 서로 다른 대상에 이름이 동일한 플러그인을 사용하면 Tanzu CLI가 명령 그룹(예: tanzu cluster)에서 명령을 조정하여 컨텍스트에 맞게 조정할 수 있습니다.
TKG v2.1에서 지원되는 유일한 대상 또는 컨텍스트 유형은 k8s이며 다음으로도 표시됩니다.
- tanzu help 명령 출력의 Kubernetes cluster operations
- tanzu plugin list 출력의 TARGET 열에 있는 kubernetes
VMware는 TKG v1.6 설명서에 설명된 대로 Windows 기반 작업자만 있는 Windows 워크로드 클러스터를 배포하지 않습니다. 대신 다중 OS 워크로드 클러스터 배포에 설명된 대로 다중 OS 클러스터를 생성하는 것을 권장합니다. 다중 OS 클러스터는 Windows 및 Linux 컨테이너를 모두 실행할 수 있으므로 Linux 기반 TKG 구성 요소와 Linux 워크로드를 모두 지원할 수 있습니다.
Go v1.18의 인증서 처리 변경으로 인해 MacOS 부트스트랩 시스템은 tanzu cluster create를 실행하기 전에 키체인에 vCenter 인증서를 추가해야 합니다. 클러스터 배포를 위한 사전 요구 사항을 참조하십시오.

사용자 설명서

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

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

v2.1.1에서 해결됨

Tanzu Kubernetes Grid v2.1.0의 알려진 문제로 기록된 다음 문제는 Tanzu Kubernetes Grid v2.1.1에서 해결되었습니다.

사용자 지정 CNI를 배포할 수 없음

CNI:none 옵션은 독립형 관리 클러스터에서 배포된 워크로드 클러스터에서 작동하지 않습니다. 사용 가능한 유일한 옵션은 antrea(기본값) 및 calico입니다.
TKG 사용자 계정이 유휴 vCenter 세션을 생성

TKG의 vSphere 계정은 vSphere > 호스트 및 클러스터(Hosts and Clusters) 인벤토리 > 내 vCenter > 모니터링(Monitor) 탭 > 세션(Sessions)에 나열된 유휴 vCenter 세션을 생성합니다.

해결 방법: 모든 세션을 시작하고 중지하여 유휴 vCenter 세션을 제거합니다.
1. ssh를 vCenter에 root로 지정합니다.
2. 메시지가 표시되면 shell을 입력합니다.
3. service-control --stop --all을 실행합니다.
4. 서비스가 Stopped로 표시될 때까지 기다립니다.
5. service-control --start --all을 실행합니다.
LoadBalancer 서비스에는 수동 게이트웨이 또는 프런트 엔드 구성이 필요합니다.

AzureClusterName 및 ClusterName 간의 이름이 일치하지 않기 때문에 클래스 기반 Azure 워크로드 클러스터의 애플리케이션에서 사용하도록 배포된 LoadBalancer 유형의 서비스에는 인터넷에서 액세스할 수 없습니다.

해결 방법: 로드 밸런서 뒤에 있는 노드가 인터넷에 액세스할 수 있도록 NAT 게이트웨이, 프록시 또는 기타 내부 라우팅을 통해 로드 밸런서 서비스에 대한 고유한 경로를 제공합니다.

VMware 아웃바운드 연결을 위해 NAT 게이트웨이(사용 가능한 경우)를 사용하는 것이 좋습니다. NAT 게이트웨이를 사용할 수 없는 경우:
1. Azure Portal에서 CAPZ에서 생성된 LoadBalancer 리소스로 이동합니다. 이 리소스는 AzureCluster와 이름이 동일해야 합니다.
2. 프론트엔드 IP 구성(Frontend IP configuration)을 선택하고 추가(Add)를 클릭합니다.
3. 로드 밸런서 서비스에 대한 새 공용 IP 주소를 생성합니다.
4. 아래 규격을 사용하여 서비스를 구성하고 생성하고, loadBalancerIP 값을 IP-ADDRESS에 표시된 공용 IP 주소로 설정합니다.
```
  apiVersion: v1
  kind: Service
  metadata:
    name: frontend
    labels:
      app: guestbook
      tier: frontend
    namespace: sample-app
  spec:
    # Add the frontend public IP here
    loadBalancerIP: IP-ADDRESS
    type: LoadBalancer
    ports:
    - port: 80
    selector:
      app: guestbook
      tier: frontend
```
클러스터를 업그레이드해도 Kube-VIP 버전이 업데이트되지 않음

독립형 관리 및 워크로드 클러스터를 v2.1로 업그레이드해도 kube-vip를 현재 버전으로 업그레이드하지 않습니다.

해결 방법: AVI_CONTROL_PLANE_HA_PROVIDER = false로 구성된 대로 제어부 끝점에 Kube-VIP를 사용하는 업그레이드된 클러스터의 경우 kube-vip 구성 요소를 업데이트합니다.
1. 클러스터 업그레이드에 사용되는 현재 TKr BoM 파일을 검색합니다. 이 파일의 로컬 복사본을 tkr-로 시작하는 파일 이름으로 ~/.config/tanzu/tkg/bom/에서 찾습니다. 예: tkr-bom-v1.24.10+vmware.1-tkg.1.yaml.
2. BoM 파일의 현재 kube-vip 버전을 나열합니다. 예를 들면 다음과 같습니다.
```
$ cat ~/.config/tanzu/tkg/bom/tkr-bom-v1.24.10+vmware.1-tkg.1.yaml | yq '.components.kube-vip'
- version: v0.5.7+vmware.1
  images:
    kubeVipImage:
      imagePath: kube-vip
      tag: v0.5.7_vmware.1
```
3. 클러스터의 kcp 개체를 가져옵니다. 이 개체의 이름은 CLUSTER-NAME-control-plane 형식입니다.
  - 관리 클러스터 개체는 tkg-system 네임스페이스에 생성됩니다.
  - NAMESPACE가 설정되지 않은 경우 워크로드 클러스터 개체는 클러스터 생성 또는 default에 사용되는 네임스페이스에 있습니다.
4. kubectl edit를 실행하여 kcp 개체를 편집하고 boM 이미지의 현재 버전과 일치하도록 kube-vip 경로를 업데이트합니다. 다음을 실행하여 이 설정의 위치를 찾습니다.
```
kubectl get kcp <cluster-name>-control-plane -o jsonpath='{.spec.kubeadmConfigSpec.files[0]}' | jq
```
관리 클러스터를 v1.5.x에서 v2.1.0으로 업그레이드하면 AKO 운영자 암호의 null avi_ingress_node_network_list 때문에 노드 네트워크 오류가 발생

원래 TKG v1.5 이하에서 생성된 독립형 관리 클러스터를 사용하는 경우 v2.1.0으로 업그레이드하면 AKO 운영자 암호에서 avi_ingress_node_network_list에 null 값이 생성됩니다. 이로 인해 v2.1.0으로 업그레이드할 때 노드 네트워크 오류가 발생하고 로그에 누락된 Avi 구성 오류가 발생합니다.

해결 방법: Tanzu CLI를 v2.1.0으로 업그레이드한 후 tanzu mc upgrade를 실행하기 전에 다음을 수행합니다.
1. 관리 클러스터 컨텍스트로 전환합니다.
```
kubectl config use-context <MGMT-CLUSTER>-admin@<MGMT-CLUSTER>
```
2. AKO 운영자 암호를 검색하고 해당 데이터 값을 디코딩합니다.
```
kubectl get secret <MGMT-CLUSTER>-ako-operator-addon -n tkg-system -o jsonpath="{.data.values\.yaml}" | base64 --decode > values.yaml
```
3. 텍스트 편집기에서 values.yaml 파일을 엽니다. avi_ingress_node_network_list 설정은 다음과 비슷합니다.
```
avi_ingress_node_network_list: '""'
```
4. 클러스터 노드 네트워크의 범위를 사용하여 설정을 다음과 같이 변경합니다.
```
avi_ingress_node_network_list: '[{"networkName":"VM Network", "cidrs":["10.191.176.0/20"]}]'
```
5. 새 데이터 값을 base64로 인코딩하고 출력 문자열을 기록합니다.
```
base64 -w 0 values.yaml
```
6. AKO 운영자 암호를 편집합니다.
```
kubectl edit secret MGMT-CLUSTER-ako-operator-addon -n tkg-system
```
7. 암호에 새 인코딩된 데이터 값 문자열을 values.yaml 값으로 붙여 넣습니다. 저장 후 종료합니다.
TMC는 Default-Group SEG에 없는 서비스 엔진을 사용하여 클래스 기반 클러스터를 배포할 수 없습니다.

TKG와 통합되는 Tanzu Mission Control은 NSX ALB를 사용하고 NSX ALB의 Default-Group 서비스 엔진 그룹에 없는 서비스 엔진으로 구성된 새 클래스 기반 클러스터를 배포할 수 없습니다. 이러한 제한은 사용자 지정 서비스 엔진으로 구성된 기존 워크로드 클러스터 업그레이드에는 영향을 주지 않습니다.

자세한 내용은 Tanzu Mission Control Release Notes를 참조하십시오.
TMC 카탈로그가 패키지 나열 및 배포에 대해 지원되지 않음

TMC 설명서의 패키지 보기에 설명된 대로 Tanzu Mission Control(TMC)의 카탈로그 기능을 사용하여 TKG v2.1 워크로드 클러스터에 패키지를 나열하거나 설치할 수 없습니다. TMC UI는 조정 상태에 고정된 패키지 저장소를 표시합니다.

v2.1.0에서 해결됨

Tanzu Kubernetes Grid v1.6.1의 알려진 문제로 기록된 다음 문제는 Tanzu Kubernetes Grid v2.1.0에서 해결되었습니다.

DaemonSet이 영구 볼륨을 자동 복원하도록 구성된 경우 포드를 삭제하는 클러스터 및 포드 작업이 실패할 수 있음

DaemonSet에서 PV(영구 볼륨)를 사용하는 설치에서는 기본적으로 드레이닝 프로세스가 DaemonSets를 무시하고 시스템이 노드에서 볼륨이 분리될 때까지 무기한 대기하기 때문에 시스템 삭제가 실패할 수 있습니다. 영향을 받는 클러스터 작업에는 업그레이드, 스케일 다운, 삭제가 포함됩니다.
vSphere with Tanzu에서 tanzu cluster list가 DevOps 사용자에 대해 오류를 생성함

devOps 엔지니어 역할이 있는 사용자가 vSphere with Tanzu 사용자 역할 및 워크플로에 설명된 대로 tanzu cluster list를 실행하면 Error: unable to retrieve combined cluster info: unable to get list of clusters. User cannot list resource "clusters" at the cluster scope와 비슷한 오류 메시지가 표시될 수 있습니다.

이 문제는 -n 옵션이 없는 tanzu cluster command가 DevOps 엔지니어 사용자가 액세스할 수 없는 모든 네임스페이스에 액세스하려고 하기 때문에 발생합니다.

해결 방법: tanzu cluster list를 실행하는 경우 사용자가 액세스할 수 있는 네임스페이스를 지정하려면 --namespace 값을 포함합니다.

알려진 문제

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

업그레이드
패키지
클러스터 작업
네트워킹
ID 및 액세스 관리
스토리지
CLI
vSphere
AWS
Windows 및 다중 OS 워크로드 클러스터
Image Builder
AVS

업그레이드

v2.1.1에서 알려짐
v2.1.x에서 알려짐

v2.1.1에서 알려짐

다음은 v2.1.1의 알려진 업그레이드 문제입니다.

vSphere의 v2.1에서 v2.1.1으로의 업그레이드가 실패함

vSphere에서 v2.1에서 v2.1.1로의 업그레이드가 실패하고 Reconcile failed:Error 오류가 발생합니다. 이 오류는 tkg-clusterclass-vsphere 패키지가 조정되지 않고 설치가 차단되었기 때문입니다.

해결 방법: 다음 vSphere 리소스 변수가 로컬 환경에 설정된 경우 설정 해제합니다.
```
unset VSPHERE_CLONE_MODE
unset VSPHERE_DATACENTER
unset VSPHERE_DATASTORE
unset VSPHERE_FOLDER
unset VSPHERE_NETWORK
unset VSPHERE_RESOURCE_POOL
unset VSPHERE_SERVER
unset VSPHERE_STORAGE_POLICY_ID
unset VSPHERE_TEMPLATE
unset VSPHERE_WORKER_DISK_GIB
unset VSPHERE_WORKER_MEM_MIB
unset VSPHERE_WORKER_NUM_CPUS
```

v2.1.x에서 알려짐

다음은 v2.1.x의 알려진 업그레이드 문제입니다.

Azure에서 클러스터 업그레이드가 실패함

Azure에서 관리 클러스터 및 워크로드 클러스터 업그레이드가 context deadline exceeded 또는 unable to upgrade management cluster: error waiting for kubernetes version update for kubeadm control plane과 같은 오류와 함께 실패합니다. 이 문제는 Azure에서의 작업이 다른 플랫폼보다 오래 걸리는 경우가 있기 때문에 발생합니다.

해결 방법: tanzu management-cluster upgrade 또는 tanzu cluster upgrade를 다시 실행하여 --timeout 플래그에 더 긴 시간 초과를 지정합니다. 기본 시간 초과 값은 30분 0초입니다.
TKG v1.3 또는 이전 버전에서 원래 생성된 독립형 관리 클러스터의 업그레이드가 실패함

TKG v2.1에서 일반 클러스터를 TKG 독립형 관리 클러스터로 전환하는 구성 요소는 Carvel 패키지 tkg-pkg에 패키징됩니다. 원래 TKG v1.3 이하에서 생성된 독립형 관리 클러스터에는 tkg-pkg를 설치하기 위해 업그레이드 프로세스에 필요한 구성 암호가 부족하여 업그레이드가 실패합니다.

해결 방법: TKG v1.3 이하에서 생성된 독립형 관리 클러스터에 대해 독립형 관리 클러스터 업그레이드에 있는 추가 단계를 수행합니다.
TKG_NO_PROXY 설정에서 와일드카드 문자(*)로 생성된 클러스터의 업그레이드가 실패함

TKG v1.6은 TKG_NO_PROXY의 클러스터 구성 파일 설정에서 와일드카드 문자(*)를 허용하지 않습니다. 이 설정으로 이전 TKG 버전에서 생성된 클러스터는 workload cluster configuration validation failed: invalid string '*' in TKG_NO_PROXY 오류를 방지하려면 업그레이드하기 전에 특수 처리가 필요합니다.

해결 방법: 업그레이드하는 클러스터의 유형에 따라:
- 관리 클러스터:
  1. 관리 클러스터 kubectl 컨텍스트로 전환합니다.
  2. configMap kapp-controller-config를 편집합니다.
```
kubectl edit cm kapp-controller-config -n tkg-system
```
  3. data.noProxy 필드를 찾고 *를 제거하여 와일드카드 호스트 이름을 변경합니다. 예를 들어 *.vmware.com to를 변경합니다. .vmware.com
  4. 저장 후 종료합니다. 클러스터를 업그레이드할 준비가 되었습니다.
- 워크로드 클러스터:
  1. 워크로드 클러스터 kubectl 컨텍스트로 전환
  2. 클러스터 이름 및 네임스페이스의 환경 변수를 설정합니다. 예:
```
CLUSTER_NAME=my-test-cluster
NS=my-test-namespace
```
  3. 워크로드 클러스터의 kapp 컨트롤러 데이터 값을 가져오고 디코딩합니다.
```
kubectl get secret "${CLUSTER_NAME}-kapp-controller-data-values" -n $NS -o json | jq -r '.data."values.yaml"' | base64 -d > "${CLUSTER_NAME}-${NS}-kapp-controller-data-values"
```
  4. kappController.config.noProxy 설정에서 *를 제거하여 ${CLUSTER_NAME}-${NS}-kapp-controller-data-values 파일을 편집합니다. 예를 들어 *.vmware.com to .vmware.com을 변경합니다.
  5. 저장 후 종료합니다.
  6. 데이터 값 파일 ${CLUSTER_NAME}-${NS}-kapp-controller-data-values을 다시 인코딩합니다.
```
cat "${CLUSTER_NAME}-${NS}-kapp-controller-data-values" | base64 -w 0
```
  7. ${CLUSTER_NAME}-${NS}-kapp-controller-data-values 암호를 편집하고 새로 인코딩된 데이터 값 문자열에 붙여 넣어 data.value.yaml 설정을 업데이트합니다.
```
kubectl edit secret "${CLUSTER_NAME}-kapp-controller-data-values" -n "${NS}"
```
  8. 저장 후 종료합니다. 클러스터를 업그레이드할 준비가 되었습니다.
독립형 관리 클러스터 업그레이드 직후에 이전 버전의 TKr을 사용할 수 없음

독립형 관리 클러스터를 TKG v1.6에서 v2.1로 업그레이드하면 TKr 소스 컨트롤러가 클래스 기반 클러스터를 지원하는 최신 버전으로 대체된 다음 TKr을 다시 동기화합니다. 그 결과 tanzu mc upgrade 명령이 완료되면 tanzu cluster available-upgrades get 및 tanzu kubernetes-release get에 유효한 TKr 버전이 모두 표시되지 않을 수 있으며 Tanzu CLI가 워크로드 클러스터를 즉시 업그레이드하지 못할 수 있습니다.

해결 방법: TKr이 다시 다운로드될 때까지 몇 분 정도 기다립니다.

패키지

구성을 업데이트하려면 일부 패키지에 대한 업그레이드가 필요합니다.

알려진 문제: v2.1.1

TKG v2.1.1용 Tanzu Standard 패키지 저장소에 v2.1.0 저장소에 있는 다음과 같은 패키지 버전이 없습니다.
- cert-manager: 1.10.1+vmware.1-tkg.1.yml, 1.5.3+vmware.7-tkg.1.yml, 1.7.2+vmware.3-tkg.1.yml
- external-dns: 0.10.0+vmware.1-tkg.3.yml, 0.11.0+vmware.1-tkg.3.yml, 0.12.2+vmware.4-tkg.1.yml
- grafana: 7.5.16+vmware.1-tkg.2.yml
이로 인해 워크로드 클러스터를 TKG v2.1.0에서 v2.1.1로 업그레이드한 후 패키지를 최신 버전으로 업그레이드하지 않고는 tanzu package installed update를 실행할 수 없습니다.
- cert-manager: 1.10.1+vmware.1-tkg.2.yml
- external-dns: 0.12.2+vmware.4-tkg.2.yml
- grafana: 7.5.17+vmware.1-tkg.1.yml
이 문제는 패키지 구성을 변경해야 하는 경우에만 발생합니다. 설치된 패키지는 업그레이드 없이 계속 실행됩니다.

해결 방법: 다음 중 하나를 수행합니다.
- cert-manager, external-dns 또는 grafana 패키지 구성을 업데이트해야 하는 경우:
  1. tanzu package installed get을 실행하여 패키지 버전을 검색합니다.
  2. 위에 나열된 것처럼 v2.1.1 저장소에 설치된 패키지 버전이 없는 경우 -v를 실행할 때 최신 버전을 tanzu package installed update 플래그로 전달합니다.
- 워크로드 클러스터를 TKG v2.1.1로 업그레이드한 후 3개의 패키지를 위 버전으로 업데이트합니다.
tanzu package 명령은 패키지 설치 및 관리에 설명된 대로 참조하십시오.
medium 및 NSX Advanced Load Balancer가 있는 소규모 포드에서 Multus CNI가 실패함

vSphere NSX ALB를 사용하여 Multus CNI 패키지를 실행하는 medium 또는 더 작은 Worker 노드가 있는 워크로드 클러스터가 Insufficient CPU 또는 기타 오류와 함께 실패할 수 있습니다.

해결 방법: NSX ALB에서 Multus CNI를 사용하려면 대규모 large 또는 extra-large 크기의 Worker 노드가 있는 워크로드 클러스터를 배포합니다.
TKG BoM 파일에 관련 없는 cert-manager 패키지 버전이 포함되어 있음

Tanzu CLI가 ~/.config/tanzu/tkg에 설치하는 BoM(TKG Bill of Materials) 파일에는 cert manager(jetstack_cert-manager) 패키지용 v1.5.3 및 v1.7.2 버전이 모두 나열됩니다. cert-manager 설치에 설명된 대로 설치할 올바른 버전은 v1.5.3입니다.

해결 방법: cert-manager v1.5.3을 설치합니다.
Pinniped를 비활성화하려면 레거시 클러스터에서 수동 Secret를 삭제해야 합니다.

관리 클러스터에서 외부 ID 관리를 비활성화하면 사용되지 않은 Pinniped Secret 개체가 레거시 워크로드 클러스터에 남아 있습니다.

사용자가 이전 kubeconfig를 사용하여 클러스터에 액세스하려고 하면 로그인 팝업이 나타나고 실패합니다.

해결 방법: ID 관리 비활성화에 설명된 대로 레거시 클러스터의 Pinniped Secret를 수동으로 삭제합니다.
실행 ID가 10000000+를 초과하면 Harbor CVE 내보내기가 실패할 수 있음

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

이 Harbor 문제는 이후 버전의 TKG에 포함될 예정인 Harbor의 이후 버전에서 해결되었습니다.
Harbor 프록시 캐시 지원 없음

인터넷 제한 환경에서 Tanzu Kubernetes Grid를 실행하는 Harbor의 프록시 캐시 기능을 사용할 수 없습니다. 여전히 Harbor 프록시 캐시를 사용하여 이전 버전의 Tanzu Kubernetes Grid 이미지 및 애플리케이션 이미지와 같은 비 Tanzu 이미지의 이미지를 프록시할 수 있습니다.

해결 방법: 없음
패키지가 기본 기준선 PSA 프로파일을 준수하지 않음

TKG의 PSA 컨트롤러에서 지원되지 않는 기술 미리보기 상태에서 일부 TKG 패키지가 기본 baseline 프로파일을 준수하지 않습니다.

해결 방법: 포드 보안 승인 컨트롤러(기술 미리보기)에 설명된 대로 영향을 받는 패키지 네임스페이스에서 audit=privileged 및 warn=privileged 레이블을 설정합니다.
단일 노드 클러스터에 대한 표준 저장소 추가 실패

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

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

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

클러스터 작업

v2.1.1에서 알려짐
v2.1에서 알려짐

v2.1.1에서 알려짐

다음은 v2.1.1의 알려진 클러스터 작업 문제입니다.

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

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

SGG v2.1.1은 이전 버전의 Kubernetes를 실행하는 기존 클러스터를 완전히 지원합니다.

해결 방법: Kubernetes 1.24.10, 1.23.16 또는 1.22.17을 실행하는 워크로드 클러스터를 생성합니다. Kubernetes 프로젝트는 현재 부 버전의 최신 패치 버전에서 구성 요소를 실행할 것을 권장합니다.

v2.1에서 알려짐

tanzu cluster create가 기본값이 아닌 Kubernetes 버전으로 생성된 클러스터 규격의 유효성을 올바르게 검사하지 않음

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

해결 방법: 두 번째 단계에서 tanzu cluster create를 실행한 후 생성된 클러스터 매니페스트를 전달할 때 클래스 기반 클러스터 생성에 설명된 대로 첫 번째 단계에서와 동일한 --tkr 값 및 기타 옵션을 지정합니다.
클래스 기반 클러스터의 자동조정기에는 수동 주석이 필요합니다.

클러스터 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"로 변경됩니다.

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

ANTREA_NODEPORTLOCAL 항목이 포함된 레거시 구성 파일과 함께 tanzu cluster create --dry-run -f를 사용하여 ClusterClass 구성 파일을 생성하면 레이블을 포함하지 않는 자동 생성된 Antrea 구성을 초래하므로 Antrea가 성공적으로 조정되지 않습니다. 이 문제는 TKG 2.1.1에서 AntreaConfig 리소스에는 추가 기능 관리자가 지정된 워크로드 클러스터에 Antrea를 설치하기 위한 tkg.tanzu.vmware.com/package-name label이 필요하기 때문에 발생합니다. 이 문제는 2.1.0에는 적용되지 않습니다.

해결 방법: 누락된 레이블을 ClusterClass 구성 파일의 AntreaConfig에 추가하고 클러스터를 다시 생성합니다.
```
labels:
tkg.tanzu.vmware.com/cluster-name: rito
tkg.tanzu.vmware.com/package-name: antrea.tanzu.vmware.com.1.7.2---vmware.1-tkg.1-advanced 
```
IPv6 네트워킹은 vSphere 8에서 지원되지 않습니다.

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

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

TKG v2.1에서는 관리 클러스터로의 트래픽에 대해 수신 모드 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 관리를 다시 구성합니다.

스토리지

기본 StorageClass 개체를 변경하면 워크로드 클러스터에서 조정 이 실패함

TKG에 포함된 기본 StorageClass 개체의 속성을 수정하면 스토리지 클래스를 사용하는 워크로드 클러스터에서 패키지 조정이 실패합니다.

해결 방법: 스토리지 클래스를 사용자 지정하려면 기본 개체 정의를 수정하는 대신 다른 name을 사용하여 새 StorageClass 정의를 생성하고 새 스토리지 클래스를 사용하도록 클러스터를 재구성합니다.
워크로드 클러스터가 여러 데이터스토어에 스토리지를 분산할 수 없음

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

해결 방법: 없음

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 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로 전달하는 경우에도 발생할 수 있습니다.

해결 방법: 오류 출력에 있는 구성 매개 변수 또는 매개 변수를 로컬 환경 변수로 설정합니다. 이 오류를 방지하려면 auto-apply-generated-clusterclass-based-configuration 기능을 true로 설정하고 tanzu cluster create를 실행하여 구성을 미리 보지 않고 1단계로 클래스 기반 클러스터를 생성할 수 있습니다. auto-apply-generated-clusterclass-based-configuration을 true로 설정하려면 다음을 실행합니다.
```
tanzu config set features.cluster.auto-apply-generated-clusterclass-based-configuration true
```
이렇게 하면 1단계로 항상 클래스 기반 클러스터를 생성하도록 Tanzu CLI가 구성됩니다. 자세한 내용은 클래스 기반 클러스터 생성을 참조하십시오.
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 명령을 사용합니다.
Windows CMD: CLI 출력 열 머리글의 관련 없음 문자

cmD(Windows 명령 프롬프트)에서 열 형식의 CLI 명령 출력에 Tanzu 열 머리글에 관련 없는 문자가 포함됩니다.

Windows 터미널 또는 PowerShell에서는 이 문제가 발생하지 않습니다.

해결 방법: Windows 부트스트랩 시스템에서 Windows 터미널에서 Tanzu CLI를 실행합니다.
관리 클러스터를 생성하는 동안 무시 가능한 AKODeploymentConfig 오류 발생

tanzu management-cluster create를 실행하여 NSX ALB를 사용하여 관리 클러스터를 생성하면 다음 오류가 출력됩니다. no matches for kind ???AKODeploymentConfig??? in version ???networking.tkg.tanzu.vmware.com/v1alpha1???. 이 오류는 무시할 수 있습니다. 자세한 내용은 KB의 이 문서를 참조하십시오.

vSphere 워크로드 클러스터를 생성하는 동안 machinehealthcheck 및 clusterresourceset 오류 발생

워크로드 클러스터가 vSphere with Tanzu를 통해 tanzu cluster create 명령을 사용하여 vSphere에 배포되면 출력에 아래와 같이 machinehealthcheck 실행 및 clusterresourceset 리소스 액세스와 관련된 오류가 포함될 수 있습니다.

Error from server (Forbidden): error when creating "/tmp/kubeapply-3798885393": machinehealthchecks.cluster.x-k8s.io is forbidden: User "sso:[email protected]" cannot create resource "machinehealthchecks" in API group "cluster.x-k8s.io" in the namespace "tkg"
...
Error from server (Forbidden): error when retrieving current configuration of: Resource: "addons.cluster.x-k8s.io/v1beta1, Resource=clusterresourcesets", GroupVersionKind: "addons.cluster.x-k8s.io/v1beta1, Kind=ClusterResourceSet"
...

워크로드 클러스터가 생성되었습니다. 오류를 무시할 수 있습니다.

MHC가 비활성화된 경우 CLI가 최근에 삭제된 노드의 상태를 일시적으로 잘못 보고함

MHC(시스템 상태 점검)가 비활성화되면 tanzu cluster status와 같은 CLI 명령을 Tanzu 인프라가 다시 생성되는 동안 최신 노드 상태를 보고하지 않을 수 있습니다.

해결 방법: 없음

vSphere

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

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

해결 방법: 최소 medium 크기의 노드로 노드 풀을 구성합니다.
NSX ALB를 사용하면 이름이 동일한 클러스터를 생성할 수 없음

워크로드(AVI_ENABLE) 또는 제어부(AVI_CONTROL_PLANE_HA_PROVIDER)에 NSX Advanced Load Balancer 사용하는 경우 Avi 컨트롤러가 이름이 동일한 클러스터를 구분하지 못할 수 있습니다.

해결 방법: 각 클러스터에 고유한 CLUSTER_NAME 값을 설정합니다.
- 관리 클러스터: 서로 다른 부트스트랩 시스템에서도 CLUSTER_NAME 값이 동일한 여러 관리 클러스터를 생성하지 마십시오.
- 워크로드 클러스터: 동일한 CLUSTER_NAME이 있고 동일한 관리 클러스터 네임스페이스에 있는 워크로드 클러스터를 NAMESPACE 값으로 설정하여 생성하지 마십시오.
기존 배포에 외부 ID 관리를 추가하려면 더미 VSPHERE_CONTROL_PLANE_ENDPOINT 값을 설정해야 할 수 있습니다.

외부 ID 공급자를 기존 TKG 배포와 통합하려면 관리 클러스터용 Pinniped 추가 기능 암호 생성에 설명된 대로 추가 기능 암호를 생성하는 데 사용되는 관리 클러스터 구성 파일에서 더미 VSPHERE_CONTROL_PLANE_ENDPOINT 값을 설정해야 할 수 있습니다.

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 및 다중 OS 워크로드 클러스터

MacOS 시스템에서 Windows 시스템 이미지를 생성할 수 없음

Kubernetes Image Builder에서 사용하는 오픈 소스 packer 유틸리티의 문제로 인해 Windows 사용자 지정 시스템 이미지에 설명된 대로 MacOS 시스템에서 Windows 시스템 이미지를 빌드할 수 없습니다.

해결 방법: Linux 시스템을 사용하여 사용자 지정 Windows 시스템 이미지를 구축합니다.
Windows 및 다중 OS 워크로드 클러스터에는 백업 및 복원이 지원되지 않습니다.

Windows 기반 Worker 노드를 사용하여 워크로드 클러스터를 백업하고 복원할 수 없음

해결 방법: 없음

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 지원에 문의하십시오.