[번역] A first look at vSphere with Kubernetes in action

출처 : https://cormachogan.com/2020/04/01/a-first-look-at-vsphere-with-kubernetes-in-action

Cloud-Native-Apps-Icon-2020.png

VCF 4.0의 이전 게시물에서는 WLD(Workload Domain)에서 vSphere with Kubernetes를 구축하는 데 관련된 단계를 살펴보았다. 이 단계를 완료했을 때 Supervisor Control Plane VM을 롤아웃하고 ESXi 호스트가 Kubernetes worker node로 동작할 수 있는 Spherelet 구성 요소를 설치했었다. 이제 이 구성을 좀 더 자세히 살펴봅시다. 그러면 몇 가지 간단한 쿠버네티스 작업을 보여드리죠. vSphere의 슈퍼바이저 클러스터(Supervisor Cluster)에서 vSphere with Kubernetes를 함께 시작하십시오.

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

슈퍼바이저 클러스터(Supervisor Cluster) 개요

우선 내 슈퍼바이저 클러스터의 인벤토리를 살펴봅시다. 현재 내 Kubernetes worker 노드로 동작하는 3개의 물리적 ESXi 호스트가 있으며, 나는 쿠버네티스 API 서버와 다른 핵심 K8s 구성 요소를 실행할 3개의 제어부 가상 머신을 가지고 있다. 또한 VCF 4.0 SDDC 매니저를 통해 WLD에 배포된 NSX-T Edge 클러스터도 있다.

Supervisor-Inventory.png

이 배포를 보는 또 다른 흥미로운 방법은 Kubectl이라는 Kubernetes CLI 명령을 사용하는 것이다. 이것은 다음에 다루자. 우선 내 Supervisor 클러스터에 할당된 Load Balancer IP 주소를 찾아야 한다. 찾으려면 vSphere Client > Workload Management > Clusters로 이동한다. 여기서 우리는 아래에 강조 표시된 Control Plane 노드 IP 주소를 찾을 것이다. 이 주소는 NSX-T Edge 배포 중에 구성된 인그레이스(Ingress) 범위에서 할당된다.

Workload-Management.png

이제 이 IP 주소로 브라우저를 가리키면 다음과 같은 랜딩 페이지가 표시되며, 이 페이지에는 쿠버네티스 CLI Tools, kubectl 및 kubectl-vsphere가 포함된다.

k8s-cli-tools.png

이러한 툴을 데스크톱/워크스테이션에 다운로드한 후 이를 사용하여 Supervisor Cluster '컨텍스트'에 로그인하고 클러스터 세부 정보를 쿼리할 수 있다.

$ ./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

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 -o wide

NAME                               STATUS   ROLES    AGE    VERSION                    INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                 KERNEL-VERSION      CONTAINER-RUNTIME
422b0e3d39560ed4ea84169e6b77d095   Ready    master   2d2h   v1.16.7-2+bfe512e5ddaaaa   10.244.0.132   <none>        VMware Photon OS/Linux   4.19.84-1.ph3-esx   docker://18.9.9
422b341edb277e79d5ec7da8b50bf31a   Ready    master   2d2h   v1.16.7-2+bfe512e5ddaaaa   10.244.0.130   <none>        VMware Photon OS/Linux   4.19.84-1.ph3-esx   docker://18.9.9
422ba68078f4aaf4c9ba2afb27d4e945   Ready    master   2d2h   v1.16.7-2+bfe512e5ddaaaa   10.244.0.131   <none>        VMware Photon OS/Linux   4.19.84-1.ph3-esx   docker://18.9.9
esxi-dell-g.rainpole.com           Ready    agent    2d2h   v1.16.7-sph-30923be        10.27.51.7     <none>        <unknown>                <unknown>           <unknown>
esxi-dell-j.rainpole.com           Ready    agent    2d2h   v1.16.7-sph-30923be        10.27.51.122   <none>        <unknown>                <unknown>           <unknown>
esxi-dell-l.rainpole.com           Ready    agent    2d2h   v1.16.7-sph-30923be        10.27.51.124   <none>        <unknown>                <unknown>           <unknown>

$

vCenter 인벤토리에서 동일한 3개의 마스터 VM과 3개의 워커 노드를 볼 수 있다. 우리가 할 수 있는 또 다른 일은 네이티브 쿠버네티스, 그리고 Enterprise PKS와는 상당히 다른 슈퍼바이저 클러스터에 존재하는 네임스페이스에 대해 질의하는 것이다.

$ ./kubectl get ns
NAME                      STATUS   AGE
default                   Active   2d3h
kube-node-lease           Active   2d3h
kube-public               Active   2d3h
kube-system               Active   2d3h
vmware-system-capw        Active   2d3h
vmware-system-csi         Active   2d3h
vmware-system-kubeimage   Active   2d3h
vmware-system-nsx         Active   2d3h
vmware-system-registry    Active   2d3h
vmware-system-tkg         Active   2d3h
vmware-system-ucs         Active   2d3h
vmware-system-vmop        Active   2d3h

$

만약 그렇게 마음이 내키면, kubectl get pods -A를 실행하여 슈퍼바이저 클러스터에서 현재 실행되고 있는 모든 파드들을 살펴볼 수 있을 것이다.

첫 네임스페이스 생성

vSphere Client로 돌아가서 Workload Management > Namespaces로 이동하십시오. 이것은 우리를 첫번째 네임스페이스를 만들 수 있는 다음 랜딩 페이지로 데려다 줄 것이다.

18-create-namespace.png

여기서 네임스페이스는 단순히 클러스터의 리소스를 여러 소비자 간에 나누는 방법이다. 모든 면에서, 우리는 슈퍼바이저 클러스터의 네임스페이스가 vSphere 리소스 풀과 매우 유사하다고 볼 수 있다. 네임스페이스를 만들 때는 인벤토리로부터 클러스터 객체를 선택한 다음 이름과 선택적 설명을 제공해야 한다. 이 예에서, 단순히 cormac-ns라고 했다.

Create-Namespace.png

네임스페이스를 성공적으로 생성하면 vSphere Client의 다음 보기에 배치된다. 상태 창은 네임스페이스가 성공적으로 생성되었음을 알려준다. 그것은 또한 우리가 이미 방문했던 도구 페이지 링크뿐만 아니라 약간의 인벤토리 정보도 가지고 있다. 용량과 사용은 네임스페이스에 대한 CPU, 메모리 및 스토리지 제한을 편집할 수 있게 해준다. TKG(Tanzu Kubernetes Grid) 게스트 클러스터를 배치할 때만 Tanzu Kubernetes가 적용된다. 우리는 이것을 다른 글로 다시 방문할 것이다.

Namespace-View.png

여기에 표시되는 설정과 정보의 많은 부분이 바로 이해된다고 생각한다. 그러나 스토리지에 대해 언급하겠다. 이 vSphere 환경에서 생성된 사용 가능한 정책 목록에서 스토리지 정책을 선택하여 네임스페이스에 'ADD STORAGE'를 실행하십시오. 기본 vSAN 스토리지 정책을 선택하여 작업을 단순하게 유지하겠지만, 물론 클러스터에 있는 호스트의 수와 vSAN 클러스터에서 사용하도록 설정한 데이터 서비스에 따라 보다 세분화된 정보를 얻을 수 있다.

Select-Storage.png스토리지 정책(또는 정책)이 네임스페이스에 할당된 후에는 네임스페이스에서 쿠버네티스 Storage Class로 사용할 수 있게 된다. kubectl CLI로 돌아가서 시연해 봅시다. 우선, 우리는 우리의 새로운 네임스페이스(cormac-ns)가 만들어지는 것을 보게 될 것이다. 그런 다음 로그아웃한 다음 슈퍼바이저 클러스터에 다시 로그인하여 새로운 '컨텍스트'를 수집할 것이다. 다른 방법이 있을 수도 있지만, 이것이 내가 나를 위해 일한다는 것을 알게 된 방법이다. 다시 로그인하면 cormac-ns 네임스페이스가 이미 컨텍스트(* 반대)로 설정되어 있으므로 다시 로그인한 후 컨텍스트를 변경할 필요가 없다는 것을 알 수 있다.

$ kubectl get ns
NAME                      STATUS   AGE
cormac-ns                 Active   15m
default                   Active   2d3h
kube-node-lease           Active   2d3h
kube-public               Active   2d3h
kube-system               Active   2d3h
vmware-system-capw        Active   2d3h
vmware-system-csi         Active   2d3h
vmware-system-kubeimage   Active   2d3h
vmware-system-nsx         Active   2d3h
vmware-system-registry    Active   2d3h
vmware-system-tkg         Active   2d3h
vmware-system-ucs         Active   2d3h
vmware-system-vmop        Active   2d3h


$ 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


$ 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

Password:
Logged in successfully.

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

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
*         cormac-ns   20.0.0.1   wcp:20.0.0.1:administrator@vsphere.local   cormac-ns


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

$

위의 마지막 명령어인 스토리지 클래스를 표시하면 기본 vSAN 스토리지 정책을 이제 Supervisor Cluster의 Persistent Volumes에서 사용할 수 있음을 알 수 있다. vSphere UI의 네임스페이스 요약에 있는 스토리지 창에는 네임스페이스에 존재하는 영구 볼륨 클레임의 수가 보고된다. 우리는 이것을 곧 보게 될 것이다.

우리는 당분간 네임스페이스를 떠나서 한 가지 행동을 더 할 것이다. 우리는 이제 슈퍼바이저 클러스터에서 Harbor 이미지 레지스트리를 활성화할 것이다. 이 기능이 활성화되면 이미지 레지스트리에 이미지를 밀어 올리고 이를 사용하여 슈퍼바이저 클러스터에 첫 번째 애플리케이션을 배포할 것이다.

Harbor 이미지 레지스트리 사용

Supervisor 클러스터의 정말 깔끔한 특징은 컨테이너 이미지를 위한 내장된 하버 이미지 레지스트리를 포함하고 있다는 것이다. 이미지 레지스트리를 사용하도록 설정하려면 vCenter 인벤토리에서 클러스터 개체를 선택한 후 아래와 같이 Configure > Namespaces > Image Registry로 이동한다.

Enable-Harbor.png

Enable Harbor 버튼을 클릭한다. 하버 애플리케이션에 필요한 영구 볼륨에 대한 스토리지 정책을 선택하라는 메시지가 표시된다(다시 한 번 vSAN 기본값을 선택함). 즉시 vmware-system-registry라고 불리는 새로운 네임스페이스가 생성되며, 여기서 하버 애플리케이션을 지원하는 PodVM이 배치된다. 총 7개의 PodVM이 생성되었으며, 배치가 완료되면 하버 UI에 대한 링크가 제공된다.

그리고 CNS(Cloud Native Storage)가 Supervisor Cluster와 완전히 통합되어 있기 때문에 하버 애플리케이션을 대신하여 구축된 4 x Persistent Volume을 볼 수 있다. 꽤 멋지지, 응?

harbor-pvs.png

또한 하버 이미지 레지스트리 네임스페이스에 대해 살펴보자. 흥미로운 정보가 있기 때문이다.

harbor-namespace.png

이제 Storage 창이 4개의 PVC를 보고하고 200GB의 제한이 있는 스토리지 정책(vSAN 기본값)을 보고하는 것을 볼 수 있다. Capacity and Usage에도 일부 사용량이 표시되고 있다. EDIT LIMITS를 클릭하고 스토리지를 확장하면 전체 스토리지 제한은 없지만 vSAN 기본 스토리지 정책에 의해 소비될 수 있는 스토리지 양은 200GB임을 알 수 있다.

storage-policy-limit.png

마지막으로 지적해야 할 항목은 현재 7개의 파드(파란선)이 가동되고 있다는 것이다. 일부 포드들은 보류 중(노란색 선) 상태였지만, 지금은 실행하고 있다 – 이것은 정상이다. 고장난 파드(빨간색 선)는 없다.

이미지를 하버로 푸시(push)

다음 단계는 이미지를 하버 이미지 레지스트리에 푸시하는 것이다. 첫 번째 단계는 신뢰를 구축하는 것이다. 그렇게 하려면 SSO 자격 증명을 사용하여 하버 UI에 로그인하고, 아래와 같이 리포지토리에서 레지스트리 인증서를 받아야 한다.

harbor-registry-cert.png

그러면 이 인증서는 로컬 노트북/데스크탑/워크스테이션의 도커 인증서 위치에 복사해야 한다. 내 우분투 17.10에 이 위치는 /etc/docker/certs.d에 있다. 그런 다음 하버 레지스트리의 FQDN 또는 IP 주소와 일치하는 디렉토리를 생성하고 다운로드한 레지스트리 인증서를 배치한다. 그렇지 않으면 레지스트리와 통신하려고 시도하는 x509 오류가 발생할 것이다.

인증을 받으면 인터넷 저장소에서 이미지를 내리고 태그를 붙여 항만 등록부에 올릴 수 있다. 푸시 명령 형식은 레지스트리/프로젝트/리포지토리:태그 입니다. 그래서 나의 하버 레지스트리는 20.0.0.2 (또 다른 수신 IP 주소는 NSX-T가 NSX-T에 의해 제공된다. 내 프로젝트는 슈퍼바이저 클러스터의 모든 네임스페이스에 대해 자동으로 만들어진 cormac-ns다. 리포지토리가 busybox이고 태그가 제공되지 않기 때문에 :latest가 사용된다.

$ docker pull k8s.gcr.io/busybox
Using default tag: latest
latest: Pulling from busybox
a3ed95caeb02: Pull complete
138cfc514ce4: Pull complete
Digest: sha256:d8d3bc2c183ed2f9f10e7258f84971202325ee6011ba137112e01e30f206de67
Status: Downloaded newer image for k8s.gcr.io/busybox:latest
k8s.gcr.io/busybox:latest


$ docker tag k8s.gcr.io/busybox 20.0.0.2/cormac-ns/busybox


$ docker push 20.0.0.2/cormac-ns/busybox
The push refers to repository [20.0.0.2/cormac-ns/busybox]
5f70bf18a086: Pushed
44c2569c4504: Pushed
latest: digest: sha256:d2af0ba9eb4c9ec7b138f3989d9bb0c9651c92831465eae281430e2b254afe0d size: 1146
$

이 이미지는 현재 우리의 하버 이미지 레지스트리에 저장되어 있으며 우리가 감시자 클러스터에 앱을 배치하는 데 사용하는 모든 매니페스트 YAML 파일에서 참조할 수 있다.

busybox-in-harbor.png

첫 번째 StatefulSet 생성

vSphere with Kubernetes로 이 첫 번째 연습을 마치기 위해서, 나는 내 네임스페이스에 작은 애플리케이션을 만들 것이다. 이미지를 다운로드해서 하버에 푸시한 다음 내 매니페스트 파일 내에서 사용할 것이다. 그 어플리케이션은 내가 전에 여러 번 사용했던 신뢰할 수 있는 카산드라 스테이트풀세트 어플리케이션일 것이다. 하버에 푸시하고, 풀하는 법을 봤으니 여기서 단계를 반복하지 않겠다. 대신, 나는 간단히 서비스와 애플리케이션을 위한 3 x 리플리카 StatefulSet을 만들고 배포 후 서비스, 포드 및 PVC를 포함한 StatefulSet을 쿼리할 것이다.

배포된 후 이 StatefulSet을 쿼리하려면 kubectl을 사용한다.

$ kubectl get sts
NAME        READY   AGE
cassandra   3/3     6m57s

서비스:

$ kubectl get svc
NAME        TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)    AGE
cassandra   ClusterIP   10.96.0.35   <none>        9042/TCP   8m38s

파드:

$ kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
cassandra-0   1/1     Running   0          6m56s
cassandra-1   1/1     Running   0          6m8s
cassandra-2   1/1     Running   0          91s

그리고 마지막으로 PVC, 물론 CNS에도 나타난다.

$ kubectl get pvc
NAME                         STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                  AGE
cassandra-data-cassandra-0   Bound    pvc-019d8f46-ccc8-402c-a038-6acd36abd103   1Gi        RWO            vsan-default-storage-policy   7m46s
cassandra-data-cassandra-1   Bound    pvc-3143a4d4-0d23-482a-8720-5e2912cd3e33   1Gi        RWO            vsan-default-storage-policy   6m58s
cassandra-data-cassandra-2   Bound    pvc-a4c5e528-7868-46d0-9df0-b5304ed90925   1Gi        RWO            vsan-default-storage-policy   3m7s

CNS의 볼륨은 다음과 같다. 여기에서 나는 app:cassandra에서 필터링했다. 그래서 우리는 앞에서 이미 살펴본 하버 볼륨을 표시하지 않는다.

cassandra-filter.png

이제 vSphere Client의 네임스페이스 보기로 돌아가 봅시다. 이제 우리는 Storage, Capacity and Usage, Pods에 대해 좀 더 흥미로운 세부사항을 볼 수 있다. 이전에 CNS 보기에서 보았던 3개의 영구 볼륨 클레임과 함께 현재 실행 중인 파드(StatefulSet 매니페스트에서 3개의 복제본을 요청함)가 있다.

namespace-with-sts.png

아주 깔끔하다. OK – 이것이 슈퍼바이저 클러스터에서 할 수 있는 몇 가지 일에 대해 합리적인 감사를 드렸으면 좋겠다. 처음에 VCF 4.0을 얼마나 쉽게 배포했는지 확인하려면 이전 VCF 4.0 게시물을 다시 확인하십시오. 계속 주시하고, 우리는 네임스페이스에 배치된 Tanzu Kubernetes Grid 게스트 클러스터를 향후 포스트에서 자세히 살펴볼 것이다.