[번역] Building a TKG Cluster in vSphere with Kubernetes

출처 : https://cormachogan.com/2020/04/07/building-a-tkg-guest-cluster-in-vsphere-with-kubernetes/

tanzu-logo.png

이제 vSphere with Kubernetes가 구축되었으므로 이 포스트의 다음 논리적 단계를 거쳐 TKG(Tanzu Kubernetes Grid) 게스트 클러스터를 구축한다. [업데이트] 게스트 클러스터가 Tanzu Kubernetes 클러스터의 공식 이름은 아니지만, 이 게시물에서 이 클러스터를 사용하여 vSphere with Kubernetes 클러스터와 차별화하도록 하겠다. TKG는 완전 CNCF 인증 쿠버네티스 유통이다. TanzuKubernetesCluster 매니페스트에 따라 가상 머신의 집합으로 구현되며, 나중에 살펴보게 된다. OS와 K8s 배포도 매니페스트에 명시되어 있다. Kubernetes 인프라와 함께 동일한 vSphere에 많은 TKG 게스트 클러스터가 구축되어 있을 수 있다. 격리/멀티 테넌시(Multi-tenancy)는 네임스페이스를 통해 달성된다. 각각에 하나 이상의 TKG 게스트 클러스터를 사용하여 여러 네임스페이스를 생성할 수 있다. 네임스페이스에는 자체 vSphere 리소스 집합이 있다. 그러면 여러 개발자 또는 개발 팀이 동일한 vSphere 플랫폼에서 동시에 작업할 수 있으며, 네임스페이스는 각각의 활동이 플랫폼의 서로 또는 다른 테넌트에 영향을 미치지 않도록 보장한다.

고지 사항: "이 게시물은 이전의 게시물처럼, 이 게시물은 vSphere with Kubernetes의 GA 이전 버전을 기반으로 하고 있다. 글 쓰는 시간과 제품이 보편적으로 사용 가능해지는 시기 사이에 크게 달라져서는 안 된다는 가정이지만, 나는 독자들이 특징적인 행동과 사용자 인터페이스가 그 이전에도 여전히 변할 수 있다는 것을 인식하기를 바란다."

이 게시물에서는 Kubernetes 환경에서 이미 구성된 vSphere에 TKG 게스트 클러스터를 배포하기 위해 다음 단계를 진행하고자 한다.

  • TKG 게스트 클러스터의 새 네임스페이스 생성
  • 컨텐츠 라이브러리를 생성하여 가상 시스템의 TKG 지원 이미지와 동기화
  • 이미지가 내 네임스페이스에 표시되는지 확인
  • TKG 게스트 클러스터 배포
  • 새 TKG 게스트 클러스터 컨텍스트로 변경
  • CNS(Cloud Native Storage)의 향상된 기능을 보여주는 간단한 PVC/PV를 생성하여 Kubernetes를 통해 vSphere의 TKG 게스트 클러스터 볼륨 처리

1. 새 네임스페이스 생성

이미 이전 vSphere with Kubernetes 포스트를 통해 이 작업을 수행하는 방법을 알아보았다. 과정은 똑같다. 여기 내 기존 네임스페이스가 있다.

1-namespace.png

다음으로, 새로운 네임스페이스를 만들었는데, 이번에는 tkg-guest-01이라고 한다.

2-create-ns.png

여기 성공적으로 생성된 네임스페이스가 있는데, 여기서 TKG 게스트 클러스터를 배포할 계획이다:

3-New-Namespace.png

다음 단계는 Add Storage다. 이전 게시물에서와 같이 vSAN 기본 스토리지 정책을 다시 한 번 사용할 것이다. 이 정책은 네임스페이스에 Kubernetes Storage Class로 표시된다는 점을 기억하자.

4-Add-Storage.png

그러면 네임스페이스 설정이 완료된다. 네임스페이스와 관련된 권한과 제한을 수정할 수 있지만, 이 연습의 기본값은 그대로 두겠다. 다음으로 컨텐츠 라이브러리로 이동한다.

2. 컨텐츠 라이브러리 구성

다음 단계는 컨텐츠 라이브러리를 만들어 외부 TKG 이미지와 동기화할 수 있도록 하는 것이다. 이것은 비교적 직선적인 것이지만, 완성도를 위해 여기에 포함시키겠다. 먼저 해야 할 일은 컨텐츠 라이브러리의 이름을 제공하는 것이다. 나는 항상 Kubernetes 라는 이름을 사용해 왔는데, 이것이 vSphere with Kubernetes 베타 데이에 주어진 지침이었기 때문이다. 다른 이름들이 사용될 수 있을지 100% 확신할 수 없다. 공식 의사들이 GA 시간에 알려줄 것 같아. [업데이트] 그리고 그들은 그렇게 한다. 어떤 이름이라도 사용할 수 있다. 여기서 또 다른 단계는 vCenter Server를 선택하는 것이다. 이 환경은 VCF(VMware Cloud Foundation) 4.0을 사용하여 구축되었으므로 관리 도메인용 vCenter Server와 Cubernetes와 함께 vSphere를 구축한 WLD(Workload Domain)용 vCenter Server가 최소 2개 이상 있을 것이다. WLD vCenter Server를 선택해야 한다.

6-create-lib-a.png

다음 단계는 Subscribed content library를 선택하고 URL을 제공하는 것이다. 나는 여기서 그것을 비웠다. 왜냐하면 계란이 계란인 것처럼, GA는 다시 바뀔 것이기 때문이다. 서브스크립션 URL이 확인되면 다시 돌아와서 업데이트할게. 이것은 GA 문서에서 다시 확인될 것이다. [업데이트] URL은 이제 문서에서 확인됨 – https://wp-content.vmware.com/v2/latest/lib.json 이다.

7-create-lib-b.png

컨텐츠 라이브러리를 저장할 데이터스토어를 선택한다. vSAN 데이터스토어를 선택했다.

8-create-lib-c.png

설정을 검토하고 Finish을 누른다.

9-create-lib-d.png

잠시 후 vSphere UI 작업 표시줄에 동기화 작업이 표시되는 것을 확인한다.

10-sync-task.png

나중에 다시 돌아와서 kubectl CLI에서 사용 가능한 이미지를 조회할 것이다. 그러나 다른 중요한 단계는 컨텐츠 라이브러리를 vSphere 클러스터에 연결하는 것이다. vSphere Cluster > Configure > Names > General을 선택하고 컨텐츠 라이브러리 Add Library 버튼을 클릭한다.

General-CL.png

방금 만든 Kubernetes Content Library 를 선택하고 OK를 클릭하여 클러스터에 추가한다.

Select-CL.png

General은 이제 이와 같은 것으로 보여져야 한다.

13-Content-Library-synced.png

이로써 현재 vSphere UI에 필요한 작업이 완료된다. 이제 TKG 게스트 클러스터 배포를 수행할 명령줄로 이동하십시오.

3. TKG 게스트 클러스터 배포

앞서 vSphere with Kubernetes 구축 사례에서 몇 가지 명령줄 툴을 살펴보았다. 두 가지-kubectl과 kubectl-vsphere가 있다. 전자는 API 서버와 통신하기 위한 일반적인 쿠버네티스 명령줄 도구다. 후자는 주로 인증에 사용되는 vSphere with Kubernetes 특정 툴이다. 시작하기 위해 로그인하고, 노드, 네임스페이스를 나열하고, 1단계에서 앞서 만든 새로운 네임스페이스로 컨텍스트를 설정한다. 그런 다음 StorageClass를 사용할 수 있고 TKG 게스트 클러스터 가상 시스템 이미지가 컨텐츠 라이브러리에서 동기화되어 있는지 확인하십시오. 이 이미지는 TKG 게스트 클러스터에서 제어부 VM 및 워커 노드 VM을 생성하는 데 사용된다.

$ kubectl-vsphere login --vsphere-username administrator@vsphere.local --server=20.0.0.1 \
--insecure-skip-tls-verify

Password: ***************
Logged in successfully.

You have access to the following contexts:
   20.0.0.1
   cormac-ns
   tkg-guest-01

If the context you wish to use is not in this list, you may need to try
logging in again later, or contact your cluster administrator.

To change context, use `kubectl config use-context <workload name>`


$ kubectl get nodes
NAME                               STATUS   ROLES    AGE   VERSION
423aace716b34ba158132148a4d1cb47   Ready    master   24h   v1.16.7-2+bfe512e5ddaaaa
423ac0a8088af7f83a732d1e317296d1   Ready    master   24h   v1.16.7-2+bfe512e5ddaaaa
423ae8cd4e4a6d6cb36858057c11a78b   Ready    master   24h   v1.16.7-2+bfe512e5ddaaaa
esxi-dell-g.rainpole.com           Ready    agent    24h   v1.16.7-sph-4d52cd1
esxi-dell-j.rainpole.com           Ready    agent    24h   v1.16.7-sph-4d52cd1
esxi-dell-l.rainpole.com           Ready    agent    24h   v1.16.7-sph-4d52cd1


$ kubectl get ns
NAME                                STATUS   AGE
cormac-ns                           Active   21h
default                             Active   3d
kube-node-lease                     Active   3d
kube-public                         Active   3d
kube-system                         Active   3d
tkg-guest-01                        Active   34m
vmware-system-capw                  Active   3d
vmware-system-csi                   Active   3d
vmware-system-kubeimage             Active   3d
vmware-system-nsx                   Active   3d
vmware-system-registry              Active   3d
vmware-system-registry-1812432932   Active   21h
vmware-system-tkg                   Active   3d
vmware-system-ucs                   Active   3d
vmware-system-vmop                  Active   3d

$ kubectl config get-contexts
CURRENT   NAME           CLUSTER    AUTHINFO                                   NAMESPACE
*         20.0.0.1       20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local
          cormac-ns      20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local   cormac-ns
          tkg-guest-01   20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local   tkg-guest-01


$ kubectl config use-context tkg-guest-01
Switched to context "tkg-guest-01".


$ kubectl config get-contexts

CURRENT   NAME           CLUSTER    AUTHINFO                                   NAMESPACE
          20.0.0.1       20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local
          cormac-ns      20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local   cormac-ns
*         tkg-guest-01   20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local   tkg-guest-01


$ kubectl get sc
NAME                          PROVISIONER              AGE
vsan-default-storage-policy   csi.vsphere.vmware.com   38m


$ kubectl get virtualmachineimages
NAME                                            AGE
photon-3-k8s-v1.16.8---vmware.1-tkg.1.6b5edc7   44m

모든 게 정상인 것 같다. 새로운 네임스페이스로 전환하여 스토리지 클래스와 가상 시스템 이미지를 모두 사용할 수 있는지 확인했다. 이제 TKG 게스트 클러스터 구축을 진행할 수 있다. 이것이 클러스터를 배치하기 위해 사용하는 메니페스트다.

apiVersion: run.tanzu.vmware.com/v1alpha1
kind: TanzuKubernetesCluster
metadata:
name: ch-tkg—cluster01
spec:
topology:
   controlPlane:
     count: 1
     class: guaranteed-small
     storageClass: vsan-default-storage-policy
   workers:
     count: 3
     class: guaranteed-small
     storageClass: vsan-default-storage-policy
distribution:
   version: v1.16

이 매니페스트에서 단일 제어부/마스터 노드 및 3개의 워커 노드를 요청한다. 스토리지 클래스에 vsan-default-storage-policy를 사용하도록 이 네임스페이스에서 구성한 유일한 정책을 사용한다. 노드의 크기가 guaranteed-small로 설정됨(GA 설명서에 옵션의 전체 목록이 표시됨). Guaranteed는 vSphere의 리소스 예약과 유사하다. 다음 명령을 실행해서 사용 가능한 옵션도 표시할 수 있다.

$ kubectl get virtualmachineclasses
NAME                AGE
best-effort-large   46h
best-effort-medium  46h
best-effort-small   46h
best-effort-xlarge  46h
best-effort-xsmall  46h
guaranteed-large    46h
guaranteed-medium   46h
guaranteed-small    46h
guaranteed-xlarge   46h
guaranteed-xsmall   46h

그런 다음 관심 있는 클래스를 설명하여 리소스를 비롯한 자세한 내용을 확인할 수 있다.

$ kubectl describe virtualmachineclasses guaranteed-small
Name:         guaranteed-small
Namespace:
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"vmoperator.vmware.com/v1alpha1","kind":"VirtualMachineClass","metadata":{"annotations":{},"name":"guaranteed-small"},"spec"...
API Version:  vmoperator.vmware.com/v1alpha1
Kind:         VirtualMachineClass
Metadata:
  Creation Timestamp:  2020-04-06T08:51:21Z
  Generation:          1
  Resource Version:    1342
  Self Link:           /apis/vmoperator.vmware.com/v1alpha1/virtualmachineclasses/guaranteed-small
  UID:                 e6a23ad0-d67c-42ac-8a4c-34af6ac2ee07
Spec:
  Hardware:
    Cpus:    2
    Memory:  4Gi
  Policies:
    Resources:
      Requests:
        Cpu:     2000m
        Memory:  4Gi
Events:          <none>

마지막으로 컨텐츠 라이브러리의 VM 이미지와 일치하는 배포 버전 v1.16을 선택했으며, 전체 이미지 이름을 매니페스트에 입력할 필요는 없다. 진행해도 될 것 같다.

$ kubectl apply -f cormac-tkg-cluster-01.yaml
tanzukubernetescluster.run.tanzu.vmware.com/ch-tkg--cluster created

이제 TKG 게스트 클러스터를 구축하기 위해 커버 아래에 진행될 여러 가지 일들이 있다. VMworld 2019의 이 Project Pacific 포스트에서 많은 이동 부품에 대해 논의한다. 여기에는 Guest Cluster Manager, 클러스터 API 및 VM Operator가 포함된다. 자세한 내용은 여기서 다루지 않겠지만, TKG 게스트 클러스터를 구축하기 위해 이 구성 요소들이 어떻게 함께 작동하는지에 관심이 있으시다면 Pacific 글을 다시 확인해 보기 바란다.

4. Kubectl을 통한 TKG 전개 검토

배치가 어떻게 진행됐는지 보겠다. 먼저 클러스터부터 보시죠.

$ kubectl get TanzuKubernetesCluster
NAME               CONTROL PLANE   WORKER   DISTRIBUTION                     AGE   PHASE
ch-tkg-cluster01   1               3        v1.16.8+vmware.1-tkg.3.60d2ffd   12m   running

또한 제어부 및 노드를 백업하는 VM을 쿼리할 수 있다.

$ kubectl get VirtualMachines
NAME                                              AGE
ch-tkg-cluster01-control-plane-82qdg              11m
ch-tkg-cluster01-workers-l5rxp-6bb6c57c49-6vg6h   5m33s
ch-tkg-cluster01-workers-l5rxp-6bb6c57c49-hrrcj   5m32s
ch-tkg-cluster01-workers-l5rxp-6bb6c57c49-qs6mg   5m32s

매우 흥미로운 것은 클러스터에 대한 describe다. 토폴로지(1개의 제어부 노드 및 3개의 작업자 노드)를 볼 수 있다. 유통판도 볼 수 있고. 클러스터에서 사용되는 다양한 추가 기능도 볼 수 있다.

$ kubectl describe TanzuKubernetesCluster ch-tkg-cluster01
Name:         ch-tkg-cluster01
Namespace:    tkg-guest-01
Labels:       <none>
Annotations:  kubectl.kubernetes.io/last-applied-configuration:
                {"apiVersion":"run.tanzu.vmware.com/v1alpha1","kind":"TanzuKubernetesCluster","metadata":{"annotations":{},"name":"ch-tkg-cluster01","name...
API Version:  run.tanzu.vmware.com/v1alpha1
Kind:         TanzuKubernetesCluster
Metadata:
  Creation Timestamp:  2020-04-02T12:50:56Z
  Finalizers:
    tanzukubernetescluster.run.tanzu.vmware.com
  Generation:        1
  Resource Version:  1702313
  Self Link:         /apis/run.tanzu.vmware.com/v1alpha1/namespaces/tkg-guest-01/tanzukubernetesclusters/ch-tkg-cluster01
  UID:               50ba1cfd-dd88-4f71-90f9-28fcc1303df9
Spec:
  Distribution:
    Full Version:  v1.16.8+vmware.1-tkg.3.60d2ffd
    Version:       v1.16
  Settings:
    Network:
      Cni:
        Name:  calico
      Pods:
        Cidr Blocks:
          192.168.0.0/16
      Service Domain:  cluster.local
      Services:
        Cidr Blocks:
          10.96.0.0/12
  Topology:
    Control Plane:
      Class:          guaranteed-small
      Count:          1
      Storage Class:  vsan-default-storage-policy
    Workers:
      Class:          guaranteed-small
      Count:          3
      Storage Class:  vsan-default-storage-policy
Status:
  Addons:
    Cloudprovider:
      Name:     vmware-guest-cluster
      Status:   applied
      Version:  v1.16.8+vmware.1-tkg.3.60d2ffd
    Cni:
      Name:     calico
      Status:   applied
      Version:  v1.16.8+vmware.1-tkg.3.60d2ffd
    Csi:
      Name:     pvcsi
      Status:   applied
      Version:  v1.16.8+vmware.1-tkg.3.60d2ffd
    Dns:
      Name:     CoreDNS
      Status:   applied
      Version:  v1.6.5_vmware.2
    Proxy:
      Name:     kube-proxy
      Status:   applied
      Version:  1.16.8+vmware.1
    Psp:
      Name:     defaultpsp
      Status:   applied
      Version:  v1.16.8+vmware.1-tkg.3.60d2ffd
  Cluster API Status:
    API Endpoints:
      Host:  20.0.0.3
      Port:  6443
    Phase:   provisioned
  Node Status:
    Ch - Tkg - Cluster 01 - Control - Plane - 82 Qdg:                         ready
    Ch - Tkg - Cluster 01 - Workers - L 5 Rxp - 6 Bb 6 C 57 C 49 - 6 Vg 6 H:  ready
    Ch - Tkg - Cluster 01 - Workers - L 5 Rxp - 6 Bb 6 C 57 C 49 - Hrrcj:     ready
    Ch - Tkg - Cluster 01 - Workers - L 5 Rxp - 6 Bb 6 C 57 C 49 - Qs 6 Mg:   ready
  Phase:                                                                      running
  Vm Status:
    Ch - Tkg - Cluster 01 - Control - Plane - 82 Qdg:                         ready
    Ch - Tkg - Cluster 01 - Workers - L 5 Rxp - 6 Bb 6 C 57 C 49 - 6 Vg 6 H:  ready
    Ch - Tkg - Cluster 01 - Workers - L 5 Rxp - 6 Bb 6 C 57 C 49 - Hrrcj:     ready
    Ch - Tkg - Cluster 01 - Workers - L 5 Rxp - 6 Bb 6 C 57 C 49 - Qs 6 Mg:   ready
Events:                                                                       <none>

CNI – Calico

위 Addons 섹션인 CNI(Container Network Interface)에는 Calico에 대한 참조가 있다. TKG 클러스터에서 Calico가 파드 간 통신을 제공하는 데 이용되고 있기 때문이다. 포드 및 서비스에 대한 CIDR은 설명 출력에서 더 멀리 뒤로 보인다.

CSI – pvCSI

또한 위의 Addons 섹션인 CSI(Container Storage Interface)에서는 반가상화 CSI 또는 pvCSI에 대한 참조가 있다. 이것은 TKG 게스트 클러스터용 CSI 드라이버의 수정 버전이다. pvCSI라고 불리는 이유는 게스트 클러스터에서 감독자 클러스터로 요청을 "프록시"하고 vCenter 및 CNS와 통신하여 적절한 vSphere 스토리지에 영구 볼륨(퍼스트 클래스 디스크, VMDK)을 생성하기 때문이다. 곧 우리는 이 간접적인 수준을 반영하는 CNS에 대한 업데이트를 보게 될 것이다.

5. UI를 통한 TKG 구축 검토

UI 관점에서, 이제 tkg-guest-01 네임스페이스에 배치된 TKG 클러스터를 볼 수 있다. 제어부 노드와 세 개의 워커 노드도 볼 수 있다.

17-TKG-invenory.png

tkg-guest-01 Namespace > Configure > VMware Resources > Tanzu Kubernetes를 선택하면 TKG 클러스터에 대한 자세한 내용을 볼 수 있다. API 서버의 로드 밸런서 IP 주소(20.0.0.3)는 초기 vSphere with Kubernetes 배포 시 제공한 Ingress 범위에서 제공된다는 점에 유의한다.

16-namesapce-tkg-compute.png

이와같이 이번 릴리스에서는 NSX-T가 TKG 클러스터(Load Balancers 및 SNAT의 송신 및 송신)의 남북 트래픽을, Calico가 동서 트래픽을 처리한다. 포드는 192.168.0.0/16 범위에서 IP 주소를 할당받고, 서비스는 캘리코가 10.96.0/12 범위에서 IP 주소를 할당받는다.

마지막으로 보여드릴 것은 VMware Resources > Virtual Machines이다. 여기서 VM 클래스에 대한 매니페스트를 포함하여 TKG 클러스터 노드 VM에 대한 세부 정보를 볼 수 있다.

VMs.png

VM 클래스는 노드 구성 방법에 대한 세부 정보를 볼 수 있으며, 노드에는 리소스 보증이 포함된다.

guarantee-small.png

6. 컨텍스트를 TKG로 변경, 게스트 클러스터 레벨에서 작동

이제 컨텍스트를 바꾸자. 네임스페이스 컨텍스트를 사용하는 대신 컨텍스트를 TKG 클러스터로 전환한다. 이를 통해 게스트 클러스터의 컨텍스트에서 작업을 실행할 수 있다. 이렇게 하려면 로그인 명령에서 TKG 클러스터 네임스페이스와 클러스터 이름을 지정하여 로그아웃한 후 다시 로그인하십시오. 아래에서 볼 수 있듯이 로그인은 다소 긴 명령이다.

$ kubectl-vsphere logout
Your KUBECONFIG context has changed.
The current KUBECONFIG context is unset.
To change context, use `kubectl config use-context <workload name>`
Logged out of all vSphere namespaces.


$ kubectl-vsphere login --vsphere-username administrator@vsphere.local \
--server=20.0.0.1 --insecure-skip-tls-verify --tanzu-kubernetes-cluster-namespace=tkg-guest-01 \
--tanzu-kubernetes-cluster-name=ch-tkg-cluster01

Password: **************
Logged in successfully.

You have access to the following contexts:
   20.0.0.1
   ch-tkg-cluster01
   cormac-ns
   tkg-guest-01
   tkg-guest-02


If the context you wish to use is not in this list, you may need to try
logging in again later, or contact your cluster administrator.

To change context, use `kubectl config use-context <workload name>`


$ kubectl config get-contexts
CURRENT   NAME               CLUSTER    AUTHINFO                                   NAMESPACE
          20.0.0.1           20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local
*         ch-tkg-cluster01   20.0.0.3   wcp:20.0.0.3:administrator@vsphere.local
          cormac-ns          20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local   cormac-ns
          tkg-guest-01       20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local   tkg-guest-01
          tkg-guest-02       20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local   tkg-guest-02
Now that we are in the context of the cluster, and kubectl commands should only apply to this context. For example, when I run some kubectl commands, the output should reflect the TKG guest cluster and not the Supervisor cluster. Let’s display the K8s nodes of the TKG to prove my point. As you can see, the output now reflects the TKG cluster. Compare this to the list of nodes we displayed when we first logged in to the namespace back in step 3.

$ kubectl get nodes -o wide
NAME                                              STATUS   ROLES    AGE     VERSION            INTERNAL-IP   EXTERNAL-IP   OS-IMAGE                 KERNEL-VERSION      CONTAINER-RUNTIME
ch-tkg-cluster01-control-plane-82qdg              Ready    master   12m     v1.16.8+vmware.1   10.244.1.18   <none>        VMware Photon OS/Linux   4.19.97-5.ph3-esx   docker://18.9.9
ch-tkg-cluster01-workers-l5rxp-6bb6c57c49-6vg6h   Ready    <none>   4m34s   v1.16.8+vmware.1   10.244.1.20   <none>        VMware Photon OS/Linux   4.19.97-5.ph3-esx   docker://18.9.9
ch-tkg-cluster01-workers-l5rxp-6bb6c57c49-hrrcj   Ready    <none>   4m40s   v1.16.8+vmware.1   10.244.1.19   <none>        VMware Photon OS/Linux   4.19.97-5.ph3-esx   docker://18.9.9
ch-tkg-cluster01-workers-l5rxp-6bb6c57c49-qs6mg   Ready    <none>   4m34s   v1.16.8+vmware.1   10.244.1.21   <none>        VMware Photon OS/Linux   4.19.97-5.ph3-esx   docker://18.9.9

7. vSphere with Kubernetes에서 TKG 게스트 클러스터의 CNS

앞에서 pvCSI에 대한 참조를 보고 CNS와 통합하여 Supervisor Cluster와 TKG 게스트 클러스터 정보를 모두 표시하는 방법을 언급하였다. 지금 그 내용을 잠깐 보겠다. 이제 이 클러스터는 표준 Kubernetes 배포와 동일한 방식으로 사용될 수 있지만, 나는 매우 단순한 PVC(영구 볼륨 클레임) 매니페스트 파일을 사용하여 새로운 CNS 기능을 보여주기 위해 독립형 PV(영구 볼륨)를 만들 것이다.

apiVersion: v1 
kind: PersistentVolumeClaim 
metadata:
  name: tkg-pvc
spec:
 storageClassName: vsan-default-storage-policy
 accessModes:
   - ReadWriteOnce
 resources:
   requests:
     storage: 1Gi

이제 TKG 게스트 클러스터에 PV를 생성한다.

$ kubectl apply -f pvc.yaml
persistentvolumeclaim/tkg-pvc created


$ kubectl get pvc
NAME      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
tkg-pvc   Bound    pvc-48317d1c-7f72-4dfd-bf35-8f7b3e930204   1Gi        RWO            vsan-default-storage-policy   30s


$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM             STORAGECLASS                  REASON   AGE
pvc-48317d1c-7f72-4dfd-bf35-8f7b3e930204   1Gi        RWO            Delete           Bound    default/tkg-pvc   vsan-default-storage-policy            13s

이 볼륨은 TKG 게스트 클러스터에서 요청한 영구 볼륨입니다. 이 요청은 vCenter Server 및 CNS와 통신하고 볼륨 생성 작업을 요청하고 볼륨에 대한 정보를 검색 및 저장할 수 있도록 Supervisor 클러스터로 이동해야 한다. 게스트 레벨에는 영구 볼륨 클레임이, 슈퍼바이저 레벨에는 해당 영구 볼륨 클레임이 있다. vSphere with Kubernetes의 CNS UI는 PV가 TKG 클러스터에서 생성될 때 두 가지 모두를 보여준다.

vSphere 클러스터 개체를 선택하고 Monitor > Cloud Native Storage > Container Volume으로 이동하면 Persistent Volume이 표시된다. PV에 대한 몇 가지 정보를 볼 수 있다.

CNS-PP-1.png

다음으로, 볼륨을 클릭하면 감독자 및 게스트 클러스터 수준에서 이 영구 볼륨에 대한 정보를 포함하여 추가적인 Kubernetes 관련 정보를 볼 수 있다.

CNS-PP-2.png

따라서 VI Admin은 게스트 클러스터에서 생성된 K8s 볼륨을 감독자 클러스터 및 vSphere까지 추적할 수 있다. 나는 이 행동을 내 스스로 보기 시작했을 뿐이고 앞으로 더 많은 것을 할 수 있기를 바란다.

이로써 이 게시물은 vSphere with Kubernetes에 게스트 클러스터로 구축된 Tanzu Cubernetes 그리드에 대한 첫 번째 관점에서 마무리된다. 어떻게 생각하는지 알려줘.