최근에 Tanzu와 함께 vSphere 7.0U2a에서 사용할 수 있는 VM Service라는 새로운 기능에 대해 게시했습니다. 간단히 말해서, 개발자는 이 새로운 서비스를 통해 Tanzu Kubernetes Clusters 및 PodVM을 각각의 네임스페이스로 프로비저닝할 수 없습니다. 이제 기본 가상 시스템도 프로비저닝할 수 있습니다. VM 서비스는 개발자에게 VirtualMachineClassBindings라는 새로운 기능을 도입했으며, 기존 기능인 VirtualMachineClass와 관련된 몇 가지 새로운 동작도 도입했습니다.
VirtualMachineClass는 가상 시스템에 사용할 수 있는 리소스 크기를 설명합니다. VM에 할당할 컴퓨팅 및 메모리 양을 설명하고 리소스가 보장(예약)되거나 “최선의 노력(best-effort)”이 보장되는 경우에도 설명합니다. 즉, 시스템에서 리소스 경합이 발생할 경우 이를 보장할 수 없습니다. 개발자가 이용할 수 있는 기존 클래스는 여러 가지가 있지만, 필요에 따라 맞춤형 클래스를 구축할 수 있는 기능도 있습니다. VirtualMachineClass는 Tanzu Kubernetes 제어부 및 작업자 노드의 노드를 구성하는 가상 시스템의 크기를 설명하기 때문에 이전 버전의 vSphere with Tanzu에서 사용할 수 있었습니다.
VirtualMachineClassBindings는 특정 네임스페이스에 할당된 가상 시스템 클래스를 설명하는 새로운 기능입니다. 이전에는 모든 네임스페이스가 모든 가상 시스템 클래스에 액세스할 수 있었습니다. 이제 vSphere 관리자 또는 플랫폼 관리자가 개발자가 생성할 수 있는 가상 시스템의 크기를 제어할 수 있습니다. 가상 시스템 클래스가 네임스페이스에 ‘바운드’된 경우에만 가상 시스템 생성에 사용할 수 있습니다. 여기에는 vSphere with Tanzu에 프로비저닝된 Tanzu Kubernetes 워크로드 클러스터의 제어부 및 작업자 노드를 백업하는 데 사용되는 가상 시스템의 생성이 포함됩니다. 나는 이 글의 뒷부분에서 이 점에 초점을 맞출 것이다. 왜냐하면 그것은 이전에 일이 어떻게 작용했는지에 대한 미묘한 행동 변화이기 때문이다.
먼저 아직 네임스페이스가 생성되지 않은 vSphere with Tanzu 환경에 대해 살펴보겠습니다.
$ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * 10.202.112.152 10.202.112.152 wcp:10.202.112.152:administrator@vsphere.local $ kubectl get virtualmachineclasses No resources found $ kubectl get virtualmachineclasses No resources found
처음에는 아무 것도 구성되지 않았습니다. 클래스나 바인딩이 없습니다. 이제 “new-namespace”라는 새 네임스페이스를 생성해 보겠습니다. 하지만 아직 이 네임스페이스에 VirtualMachineClass를 추가하지 마십시오.
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
10.202.112.152 10.202.112.152 wcp:10.202.112.152:administrator@vsphere.local
* new-namespace 10.202.112.152 wcp:10.202.112.152:administrator@vsphere.local new-namespace
$ kubectl get virtualmachineclasses
No resources found
$ kubectl get virtualmachineclassbindings
No resources found in new-namespace namespace.할당된 클래스가 없으므로 바인딩도 비어 있습니다. 이제 vSphere Client를 통해 모든 16개의 기존 가상 시스템 클래스를 네임스페이스 “new-namespace”에 할당할 수 있습니다.
이제 CLI의 네임스페이스 컨텍스트에서 16개의 가상 시스템 클래스 바인딩을 볼 수 있습니다. 바인딩이 할당되는 즉시 클래스가 다른 네임스페이스에도 표시됩니다. 이는 곧 다른 네임스페이스를 구축할 때 더욱 분명해질 것입니다.
$ kubectl get virtualmachineclasses NAME CPU MEMORY AGE best-effort-2xlarge 8 64Gi 2m36s best-effort-4xlarge 16 128Gi 2m30s best-effort-8xlarge 32 128Gi 2m35s best-effort-large 4 16Gi 114s best-effort-medium 2 8Gi 2m15s best-effort-small 2 4Gi 2m36s best-effort-xlarge 4 32Gi 2m36s best-effort-xsmall 2 2Gi 2m36s guaranteed-2xlarge 8 64Gi 2m36s guaranteed-4xlarge 16 128Gi 2m33s guaranteed-8xlarge 32 128Gi 2m25s guaranteed-large 4 16Gi 2m36s guaranteed-medium 2 8Gi 2m35s guaranteed-small 2 4Gi 2m34s guaranteed-xlarge 4 32Gi 73s $ kubectl get virtualmachineclassbindings NAME VIRTUALMACHINECLASS AGE best-effort-2xlarge best-effort-2xlarge 2m48s best-effort-4xlarge best-effort-4xlarge 96s best-effort-8xlarge best-effort-8xlarge 2m58s best-effort-large best-effort-large 96s best-effort-medium best-effort-medium 96s best-effort-small best-effort-small 2m59s best-effort-xlarge best-effort-xlarge 2m59s best-effort-xsmall best-effort-xsmall 2m38s guaranteed-2xlarge guaranteed-2xlarge 2m48s guaranteed-4xlarge guaranteed-4xlarge 96s guaranteed-8xlarge guaranteed-8xlarge 96s guaranteed-large guaranteed-large 2m38s guaranteed-medium guaranteed-medium 96s guaranteed-small guaranteed-small 2m18s
각 클래스에 대해 kubectl describe을 실행하여 각 클래스에 연결된 CPU 및 메모리 리소스 양을 확인할 수 있습니다.
이제 가상 머신 클래스 바인딩을 도입한 이유가 무엇인지 질문하고 싶으십니까? 두 번째 네임스페이스를 만들 때 차이가 명확해집니다. 새 네임스페이스(cormac-new-ns)에서는 다른 네임스페이스에 할당된 가상 시스템 클래스를 볼 수 있지만, 가상 시스템 클래스 바인딩을 통해 네임스페이스에 특별히 바인딩되어 표시되지 않는 한 이러한 가상 시스템 클래스를 사용할 수 없습니다. 따라서 가상 시스템 클래스가 한 번 이상 바인딩되면 다른 네임스페이스에 표시됩니다. 따라서 아래에서 강조 표시한 것처럼 VirtualMachineClasses는 이미 네임스페이스(new-namespace)에 바인딩되어 있기 때문에 모두 16개의 Virtual MachineClass를 볼 수 있지만 “cormac-new-ns” 네임스페이스 컨텍스트에서는 사용할 수 없습니다.
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* 10.202.112.152 10.202.112.152 wcp:10.202.112.152:administrator@vsphere.local
cormac-new-ns 10.202.112.152 wcp:10.202.112.152:administrator@vsphere.local cormac-new-ns
new-namespace 10.202.112.152 wcp:10.202.112.152:administrator@vsphere.local new-namespace
$ kubectl config use-context cormac-new-ns
Switched to context "cormac-new-ns".
$ kubectl get virtualmachineclasses
NAME CPU MEMORY AGE
best-effort-2xlarge 8 64Gi 6m9s
best-effort-4xlarge 16 128Gi 6m3s
best-effort-8xlarge 32 128Gi 6m8s
best-effort-large 4 16Gi 5m27s
best-effort-medium 2 8Gi 5m48s
best-effort-small 2 4Gi 6m9s
best-effort-xlarge 4 32Gi 6m9s
best-effort-xsmall 2 2Gi 6m9s
guaranteed-2xlarge 8 64Gi 6m9s
guaranteed-4xlarge 16 128Gi 6m6s
guaranteed-8xlarge 32 128Gi 5m58s
guaranteed-large 4 16Gi 6m9s
guaranteed-medium 2 8Gi 6m8s
guaranteed-small 2 4Gi 6m7s
guaranteed-xlarge 4 32Gi 4m46s
guaranteed-xsmall 2 2Gi 3m24s
$ kubectl get virtualmachineclassbindings
No resources found in cormac-new-ns namespace.그러나 이제 vSphere 클라이언트로 이동하여 이 네임스페이스에 가상 시스템 클래스를 할당하면 바인딩이 표시됩니다.
$ kubectl get virtualmachineclassbindings NAME VIRTUALMACHINECLASS AGE guaranteed-large guaranteed-large 10s
Tanzu를 사용하는 vSphere의 Tanzu Kubernetes에 대한 고려 사항
예를 들어 “cormac-new-ns” 네임스페이스에 Tanzu Kubernetes 워크로드 클러스터를 생성하려고 합니다. 이전 버전의 vSphere with Tanzu에서는 Virtual MachineClass 또는 Virtual Machine Bindings에 대해 걱정할 필요가 없었습니다. 저는 단순히 TanzuKubernetes Cluster 매니페스트를 만들어 적용했습니다. 컨텐츠 라이브러리에서 이미지를 사용할 수 있는 한, 저는 기꺼이 갈 수 있었습니다. 여기 그러한 manifest의 예가 있다.
$ cat tkgs-cluster.1.20.2-nobindingvmclass.yaml
apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
name: tkg-cluster-1-20-2
spec:
topology:
controlPlane:
count: 3
class: guaranteed-medium
storageClass: vsan-default-storage-policy
workers:
count: 5
class: best-effort-medium
storageClass: vsan-default-storage-policy
distribution:
version: v1.20.2이 예에서는 spec.topology.controlPlane.class 및 이 네임스페이스에 바인딩되지 않은 spec.topology.workers.class가 사용됩니다. 따라서 VirtualMachineClass 출력에는 나타나지만 VirtualMachineClassBinding 출력에는 나타나지 않습니다. 따라서 이 매니페스트를 적용하여 사용하려고 하면 다음과 같이 클러스터 생성에 실패합니다.
$ kubectl get TanzuKubernetesCluster
NAME CONTROL PLANE WORKER DISTRIBUTION AGE PHASE TKR COMPATIBLE UPDATES AVAILABLE
tkg-cluster-1-20-2 3 5 v1.20.2+vmware.1-tkg.2.3e10706 4m10s failed True
$ kubectl describe TanzuKubernetesCluster
Name: tkg-cluster-1-20-2
Namespace: cormac-new-ns
Labels: run.tanzu.vmware.com/tkr=v1.20.2---vmware.1-tkg.2.3e10706
Annotations: <none>
API Version: run.tanzu.vmware.com/v1alpha1
Kind: TanzuKubernetesCluster
Metadata:
Creation Timestamp: 2021-06-15T12:09:13Z
Finalizers:
tanzukubernetescluster.run.tanzu.vmware.com
.
.
.
Conditions:
Last Transition Time: 2021-06-15T12:09:32Z
Message: 1 of 2 completed
Reason: VirtualMachineClassBindingNotFound @ Machine/tkg-cluster-1-20-2-control-plane-lqwnh
Severity: Error
Status: False
Type: ControlPlaneReady
Last Transition Time: 2021-06-15T12:09:26Z
Message: 0/3 Control Plane Node(s) healthy. 0/5 Worker Node(s) healthy
Reason: WaitingForNodesHealthy
Severity: Info
Status: False
Type: NodesHealthy
Last Transition Time: 2021-06-14T08:33:41Z
Status: True
Type: TanzuKubernetesReleaseCompatible
Last Transition Time: 2021-06-14T08:33:41Z
Reason: NoUpdates
Status: False
Type: UpdatesAvailable
Node Status:
tkg-cluster-1-20-2-control-plane-lqwnh: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-2pbrd: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-4pf87: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-8pzdb: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-fzgpz: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-tzkth: pending
Phase: failed
Vm Status:
tkg-cluster-1-20-2-control-plane-lqwnh: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-2pbrd: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-4pf87: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-8pzdb: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-fzgpz: pending
tkg-cluster-1-20-2-workers-wlppj-778dff98c-tzkth: pending
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal PhaseChanged <invalid> vmware-system-tkg/vmware-system-tkg-controller-manager/tanzukubernetescluster-status-controller cluster changes from creating phase to failed phase이 매니페스트를 성공적으로 배포하려면 누락된 두 가상 시스템 클래스를 네임스페이스에 바인딩해야 합니다.
이제 바인딩을 쿼리하면 Tanzu Kubernetes Cluster에 필요한 두 바인딩을 볼 수 있습니다.
$ kubectl get virtualmachineclassbindings NAME VIRTUALMACHINECLASS AGE best-effort-medium best-effort-medium 5m30s guaranteed-large guaranteed-large 16m guaranteed-medium guaranteed-medium 2m31s
모든 것이 잘 진행됩니다. 클러스터를 다시 생성하려고 하면 이제 클러스터가 성공적으로 배포됩니다.
$ kubectl get TanzuKubernetesCluster NAME CONTROL PLANE WORKER DISTRIBUTION AGE PHASE TKR COMPATIBLE UPDATES AVAILABLE tkg-cluster-1-20-2 3 5 v1.20.2+vmware.1-tkg.2.3e10706 56m running True
결론적으로, vSphere with Tanzu(vSphere 7.0U2a)에 VM Service가 도입되면 VirtualMachineClasses를 사용하려면 먼저 네임스페이스에 바인딩해야 합니다. 이는 모든 네임스페이스가 모든 클래스에 액세스했던 이전 버전의 vSphere with Tanzu의 작업 방식과 다릅니다.
