릴리스 정보에는 다음과 같은 항목이 포함됩니다.
|
VMware vSphere with Tanzu 8.0 | 2022년 10월 11일 이 릴리스 정보의 추가 사항 및 업데이트 사항을 확인하십시오. |
vSphere with Tanzu 8.0에는 다음과 같은 새로운 기능과 향상된 기능이 추가되었습니다.
워크로드 관리 구성 모니터링
이제 감독자의 활성화, 비활성화 및 업그레이드 상태를 보다 자세히 추적할 수 있습니다. 감독자 활성화, 비활성화 또는 업그레이드를 시작하면 감독자는 감독자의 다양한 구성 요소(예: 제어부 VM)와 연결된 다양한 조건에 도달하여 원하는 상태에 도달하려고 시도합니다. 각 조건의 상태를 추적하고, 연결된 주의를 보고, 상태를 다시 시도하고, 도달한 조건과 해당 타임 스탬프를 볼 수 있습니다.
vSphere 영역
vSphere 영역은 vSphere 클러스터에 가용성 영역을 할당할 수 있는 새로운 구성체입니다. vSphere 영역에 감독자를 배포하면 특정 가용성 영역 및 장애 도메인에서 Tanzu Kubernetes Grid 클러스터를 프로비저닝할 수 있습니다. 그러면 워크로드가 여러 클러스터에 걸쳐 있을 수 있기 때문에 하드웨어 및 소프트웨어 장애에 대한 복원력이 향상됩니다.
다중 클러스터 감독자
vSphere 영역을 사용하면 여러 vSphere 클러스터에 감독자를 배포하여 Tanzu Kubernetes Grid 클러스터에 고가용성 및 장애 도메인을 제공할 수 있습니다. 이 릴리스는 메트로 클러스터 배포용이 아닙니다. 다중 클러스터 감독자의 사용 사례는 단일 물리적 데이터 센터의 별도 랙에 vSphere 클러스터를 배치하는 것입니다. 그런 다음 각 vSphere 클러스터를 별도의 vSphere 영역에 추가합니다. 이렇게 하면 지역화된 하드웨어 및 소프트웨어 장애에 대한 페일오버 및 복원력이 제공됩니다. 영역, 랙 또는 vSphere 클러스터가 오프라인 상태가 되면 감독자가 장애를 감지하고 다른 vSphere 영역에서 워크로드를 다시 시작합니다.
감독자가 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 사용자 지정 리소스 정의는 Kubernetes 클러스터의 VM 및 포드 모두에 대한 네트워크 보안 제어를 구성하는 기능을 제공합니다.
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
vSAN과 같은 공유 데이터스토어에서 여러 FCD 및 볼륨을 삭제하면 성능에 변화가 있을 수 있음
해결된 문제로 인해 성능 변화가 발생할 수 있습니다. 해결되지 않은 동안은 이 문제로 인해 FCD 삭제 작업 실패 후 오래된 FCD 및 볼륨이 데이터스토어에 남아 있게 됩니다.
해결 방법: 없음. 성능에 변화가 있어도 삭제 작업은 평소처럼 작동합니다.
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
vSphere 관리자가 클러스터 용량을 초과하는 리소스 제한으로 셀프 서비스 네임스페이스 템플릿을 구성하는 경우 경고가 트리거되지 않음
vSphere 관리자가 클러스터 용량을 초과하는 리소스 제한을 구성하는 경우 DevOps 엔지니어는 템플릿을 사용하여 리소스가 많은 vSphere 포드를 배포할 수 있습니다. 그 결과로 워크로드가 실패할 수 있습니다.
해결 방법: 없음
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" deleted