최근에 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의 작업 방식과 다릅니다.

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 항목은 *(으)로 표시합니다

You May Also Like

Tanzu Kubernetes Grid 개념

관리 클러스터(Management Cluster) 관리 클러스터는 Tanzu Kubernetes Grid 인스턴스를 생성할 때 배포하는 첫 번째 요소다. 관리 클러스터는 Tanzu…

vSphere with Tanzu VM Service 살펴보기

이 게시물에서는 이제 vSphere with Tanzu에서 VM 서비스라고 하는 새로운 서비스를 살펴보겠습니다. 개발자는 이 새로운 서비스를 통해 TKG…

VMware Tanzu Kubernetes Grid

VMware Tanzu Kubernetes Grid는 VMware에서 테스트, 서명, 지원하는 Kubernetes의 일관된 업스트림 호환 구현을 제공한다. Tanzu Kubernetes Grid는 VMware…