[번역] Tanzu Kubernetes Grid from the tkg Command Line Interface

출처 : https://cormachogan.com/2020/07/06/tanzu-kubernetes-grid-from-the-tkg-command-line-interface/

vSphere with Kubernetes를 살펴보고, 간단한 매니페스트 파일이 있는 네임스페이스에 TKG(Tanzu Kubernetes Grid) "게스트" 클러스터를 어떻게 배치할 수 있는지 살펴본 후, 이제는 고객이 vSphere 인프라 위에 TKG 클러스터를 배치할 수 있는 다른 방법을 살펴봐야 할 때라고 생각했다. 즉, vSphere with Kubernetes 또는 VMware Cloud Foundation(VCF) 없이 TKG를 배포한다. 이 게시물에서는 TKG 관리 클러스터를 먼저 배치하기 위한 tkg 코맨드-라인 도구를 살펴보고, 이 툴을 사용하면 워크로드 TKG 클러스터를 추가로 구축하는 것이 얼마나 간단한지 알 수 있다.

tanzu-logo.png

현재, TKG에는 이미 많은 훌륭한 게시물이 있다. 다음은 William Lam(기술 예고편)에서 나온 것이다. 여기 또 다른 Chip ZollerKendrick Coleman의 멋진 것이 있다. tkg CLI를 통해 vSphere와 AWS 모두에 구축할 수 있지만, 이 게시물에서만 vSphere에 초점을 맞추겠다.

Cluster-API 및 종류

잡초를 너무 많이 제거하지 않고, 이 배치 메커니즘은 Cluster-API, 즉 "클러스터 생성, 구성 및 관리에 선언적인 쿠베르네츠 스타일의 API를 가져오는 쿠베르네츠 프로젝트"에 크게 의존한다. 간단한 Kubernetes 클러스터가 먼저 일어서고, 이 클러스터는 Cluster-API를 통해 보다 실질적인 Kubernetes 클러스터를 구축하는 데 사용되며, TKG Management 클러스터인 경우. 단순한 쿠베르네테스 클러스터는 Kind를 기반으로 한다. Kind는 도커 컨테이너 "노드"를 사용하여 로컬 쿠베르네츠 클러스터를 실행하는 도구다. 다음과 같은 시각화의 변형은 그것이 어떻게 서로 연결되는지 이해하는 데 많은 도움이 되었기 때문에 여기서 한 번 더 공유하겠다.

clusterapi.png

1. 사전 요구사항

TKG를 구축하기 위해 랩톱이나 데스크톱 또는 VM을 사용할 수 있어야 한다는 구상이다. 어떤 장치를 사용하기로 결정하든 클러스터를 성공적으로 배포하려면 다음과 같은 구성 요소가 필요하다.

  • 단말기에 Dicker를 설치해야 한다. 이것을 하는 데는 여러 가지 방법이 있다.
  • tkg CLI를 설치해야 한다. 이는 MyVMware에서 이용할 수 있다.
  • kubectl 바이너리도 이용할 수 있어야 할 것이다. 버전은 배치되는 TKG 클러스터의 버전에 따라 달라진다. 이것은 설치 시에 확인되고 보고된다.
  • 로드 밸런서/HA 프록시용 및 TKG 클러스터 VM용 이미지 2개가 필요하다. 이 기능은 VMware에서 제공되며, TKG를 배포할 vSphere 환경에 OVA를 배포하고 템플릿으로 변환한다. 이러한 기능은 MyVMware에서도 사용할 수 있다. 사용하는 tkg CLI 버전과 일치하는 올바른 OVA 버전을 사용하는지 확인한다.
  • SSH 공용 키의 복사본을 근처에 보관하십시오(대개 .ssh/id_rsa.pub 아래의 HOME 폴더에 있음 TKG 노드에는 비밀번호 인증이 설정되어 있지 않으므로 노드에 SSH를 사용할 수 있는 유일한 방법이다.

2. TKG 관리 클러스터 구축

tkg 명령줄 도구를 사용하여 관리 클러스터 배포를 시작하십시오. tkg init 명령은 부트스트랩 클러스터 생성을 시작한다. -u 옵션은 UI를 실행하여 인프라 유형을 선택할 수 있으며 관리 클러스터 세부 정보를 추가하십시오.

$ tkg version
Client:
        Version: v1.1.2
        Git commit: c1db5bed7bc95e2ba32cf683c50525cdff0f2396

$ tkg init -u

Logs of the command execution can also be found at: /tmp/tkg-20200702T123104396946940.log

Validating the pre-requisites...
Serving kickstart UI at http://127.0.0.1:8080

이 때 홈 폴더에 .tkg 폴더가 생성된다. 여기에는 부트스트랩 프로세스에서 사용할 여러 구성 요소가 포함되어 있다. 지금은 구성 YAML 파일을 이용해 TKG를 배치하는 방법도 있지만 UI를 통해 어떻게 하는지도 먼저 살펴보겠다. 데스크톱/랩톱/VM에서 브라우저를 열고 위에 표시된 것처럼 http:///127.0.0.1:8080을 가리키기만 한다.

TKG 관리 클러스터를 성공적으로 구축하기 위해 UI에서 제공해야 할 다양한 입력 정보를 검토해보자. 첫 번째 단계는 TKG가 배치될 인프라 유형을 선택하는 것이다. 현재 옵션으로는 vSphere와 AWS가 있다. 우리는 vSphere를 구축할 것이다.

1-TKG-Welcome.png

다음으로 vSphere에 대한 세부 정보, 즉 vCenter Server, 사용자 이름 및 암호를 추가한다. 입력하고, connect를 클릭하여 데스크톱/노트북/VM에서 환경에 연결할 수 있는지 확인한다.

2-TKG-IaaS-Provider.png

주의 사항 – vSphere 7.0 환경에 TKG를 배포하려고 한다. 이것은 지원되지 않으며, 다음의 메시지에는 분명히 다음과 같은 내용이 기재되어 있다. 작성 당시 7.0은 TKG 독립형으로 지원되는 플랫폼이 아니다. TKG 클러스터를 vSphere 7과 함께 사용하려면 vSphere with Kubernetes의 컨텍스트에서 TKG 클러스터를 사용해야 한다.

3-TKG-vSphere-7-warning.png

이 창의 마지막 단계는 TKG 관리 클러스터를 프로비저닝할 vSphere 인벤토리에서 데이터 센터를 선택하고 공개 키를 추가하여 TKG 노드에 SSH를 허용한다.

5-TKG-IaaS-post-connection-.png

Management Cluster Settings으로 이동하려면 Next를 클릭한다. 여기서 인스턴스 유형을 선택할 수 있다. Development를 선택하면 단일 제어부 노드와 단일 작업자 노드가 배치된다. Production이 선택되면 제어부 노드 3개와 작업자 노드 1개가 배포된다. 이때 관리 클러스터 이름을 추가하고(선택적으로) API Server 로드 밸런서(HA Proxy라고 함)를 선택한다. HA Proxy는 위의 필수 구성 요소에 나열된 템플릿으로 변환된 가져온 OVA입니다. 다른 버전의 TKG는 서로 다른 버전의 OVA에 의존하므로 OVA가 TKG 릴리스와 호환되는지 확인한다. 마지막으로 작업자 노드와 HA Proxy 리소스(또는 배포하려는 VM 크기를 선택)를 선택한다.

6-TKG-Mgmt-cluster-settings.png

다음 화면에서는 VM 폴더 및 데이터스토어와 같은 vSphere 리소스는다. 선택하고 Next를 클릭한다.

7-TKG-resources.png

다음으로, Kubernetes 노드에 대한 VM 네트워크를 선택한다. 이 네트워크는 DHCP를 사용할 수 있어야 하며 데스크톱/노트북/VM(TKG를 배포할 위치)에서도 연결할 수 있어야 한다. 이것은 나를 포함한 몇몇 사람들을 밖으로 끌어냈다. 클러스터 포드 및 서비스 CIDR은 기본값으로 유지될 수 있다.

8-TKG-k8s-network.png

마지막이지만 중요한 것은 Kubernetes 노드 OS 이미지의 OVA 템플릿을 선택한다. 이 OVA는 필수 구성 요소 단계에서 템플릿으로 다운로드, 배포 및 변환한 두 번째 OVA입니다. 마법사를 완료하려면 Next를 클릭한다.

9-TKG-OS-image.png

이제 구성을 검토한다.

10-TKG-Review-config.png

그리고 모든 것이 좋아 보이면 마지막 단계를 클릭하여 TKG 관리 클러스터를 구축하면 된다.

11-TKG-Confirm-Settings.png

12-TKG-Deploy-Start.png

그리고 이제 UI는 TKG Management Cluster 서기에 관련된 다양한 단계를 표시한다. 앞서 말한 것처럼 먼저 Kind 클러스터(도커를 사용하는 쿠베르네츠)가 일어선다. 그런 다음 vSphere에서 TKG 관리 클러스터를 불러오기 위해 선언적인 Kubernetes 스타일 API 요청을 하는 데 사용된다. 먼저 Kind 부트 스트랩 클러스터가 구성되어 있다.

13-TKG-Step-2-Logs.png

이때 데스크톱/랩톱/VM에서 Docker 명령을 실행하여 부트스트랩(kind) 클러스터를 확인한다.

$ docker ps
CONTAINER ID        IMAGE                                                COMMAND                 \
 CREATED             STATUS              PORTS                       NAMES

5192939d9c20        registry.tkg.vmware.run/kind/node:v1.18.3_vmware.1   "/usr/local/bin/entr…"  \
 13 minutes ago      Up 13 minutes       127.0.0.1:46861->6443/tcp   tkg-kind-brush57avu7rf0bd8ed0-control-plane

3단계는 부트스트랩 클러스터에 제공자(provider)를 설치하는 것이다. 제공자는 서로 다른 인프라에서 Cluster-API를 실행하는 데 필요한 구성 요소라고 생각할 수 있으며, 이 경우에는 vSphere가 해당된다.

14-TKG-Step-3-Logs.png

4단계에서는 부트스트랩 클러스터가 가동되어 실행 중임 이제 TKG 관리 클러스터 구축에 착수한다.

15-TKG-Step-4-Logs.png

6단계는 관리 클러스터에 추가 기능을 추가하는 것이다. TKG 관리 클러스터를 사용하여 추가 워크로드 TKG 클러스터를 신속하게 구축할 것임을 기억하자. 그것을 하기 위해 필요한 구성 요소들이 여기에 추가된다.

16-TKG-Step-6-Logs.png

일단 TKG 관리 클러스터가 일어서면, 우리는 더 이상 부트스트랩 클러스터가 필요하지 않다. 이 단계는 관리 클러스터를 삭제하기 전에 부트스트랩 클러스터의 정보로 업데이트하십시오.

17-TKG-Step-7-Logs.png

그리고 8단계에서는 TKG 관리 클러스터 배치가 완료된다.

18-TKG-Deploy-Complete.png

tkg init -u 전체 출력:

$ tkg init -u

Logs of the command execution can also be found at: /tmp/tkg-20200702T123104396946940.log

Validating the pre-requisites...
Serving kickstart UI at http://127.0.0.1:8080
Validating configuration...
web socket connection established
sending pending 2 logs to UI
Using infrastructure provider vsphere:v0.6.5
Generating cluster configuration...
Setting up bootstrapper...
Bootstrapper created. Kubeconfig: /home/cormac/.kube-tkg/tmp/config_FOd8QIxS
Installing providers on bootstrapper...
Fetching providers
Installing cert-manager
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v0.3.6" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v0.3.6" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v0.3.6" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-vsphere" Version="v0.6.5" TargetNamespace="capv-system"
Start creating management cluster...
Saving management cluster kuebconfig into /home/cormac/.kube/config
Installing providers on management cluster...
Fetching providers
Installing cert-manager
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v0.3.6" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v0.3.6" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v0.3.6" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-vsphere" Version="v0.6.5" TargetNamespace="capv-system"
Waiting for the management cluster to get ready for move...
Moving all Cluster API objects from bootstrap cluster to management cluster...
Performing move...
Discovering Cluster API objects
Moving Cluster API objects Clusters=1
Creating objects in the target cluster
Deleting objects from the source cluster
Context set for management cluster tkg-mgmt-vsphere-20200702124420 as 'tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420'.

Management cluster created!

You can now create your first workload cluster by running the following:

  tkg create cluster [name] --kubernetes-version=[version] --plan=[plan]

이 시점에서 검토하기에 흥미로운 것은 이 프로세스의 일부로 생성된 .tkg/config.yaml 파일이다. tkg init 명령을 실행할 때 생성된 원본 바닐라 config.yaml은 다음과 같다.

$ cat .tkg/config.yaml
cert-manager-timeout: 30m0s
overridesFolder: /home/cormac/.tkg/overrides
NODE_STARTUP_TIMEOUT: 20m
BASTION_HOST_ENABLED: "true"
providers:
  - name: cluster-api
    url: /home/cormac/.tkg/providers/cluster-api/v0.3.6/core-components.yaml
    type: CoreProvider
  - name: aws
    url: /home/cormac/.tkg/providers/infrastructure-aws/v0.5.4/infrastructure-components.yaml
    type: InfrastructureProvider
  - name: vsphere
    url: /home/cormac/.tkg/providers/infrastructure-vsphere/v0.6.5/infrastructure-components.yaml
    type: InfrastructureProvider
  - name: tkg-service-vsphere
    url: /home/cormac/.tkg/providers/infrastructure-tkg-service-vsphere/v1.0.0/unused.yaml
    type: InfrastructureProvider
  - name: kubeadm
    url: /home/cormac/.tkg/providers/bootstrap-kubeadm/v0.3.6/bootstrap-components.yaml
    type: BootstrapProvider
  - name: kubeadm
    url: /home/cormac/.tkg/providers/control-plane-kubeadm/v0.3.6/control-plane-components.yaml
    type: ControlPlaneProvider
images:
    all:
        repository: registry.tkg.vmware.run/cluster-api
    cert-manager:
        repository: registry.tkg.vmware.run/cert-manager
        tag: v0.11.0_vmware.1
release:
    version: v1.1.2
Now, after running the setup of the TKG management domain, this is what we see updated in the config.yaml:

$ cat .tkg/config.yaml
cert-manager-timeout: 30m0s
overridesFolder: /home/cormac/.tkg/overrides
NODE_STARTUP_TIMEOUT: 20m
BASTION_HOST_ENABLED: "true"
providers:
  - name: cluster-api
    url: /home/cormac/.tkg/providers/cluster-api/v0.3.6/core-components.yaml
    type: CoreProvider
  - name: aws
    url: /home/cormac/.tkg/providers/infrastructure-aws/v0.5.4/infrastructure-components.yaml
    type: InfrastructureProvider
  - name: vsphere
    url: /home/cormac/.tkg/providers/infrastructure-vsphere/v0.6.5/infrastructure-components.yaml
    type: InfrastructureProvider
  - name: tkg-service-vsphere
    url: /home/cormac/.tkg/providers/infrastructure-tkg-service-vsphere/v1.0.0/unused.yaml
    type: InfrastructureProvider
  - name: kubeadm
    url: /home/cormac/.tkg/providers/bootstrap-kubeadm/v0.3.6/bootstrap-components.yaml
    type: BootstrapProvider
  - name: kubeadm
    url: /home/cormac/.tkg/providers/control-plane-kubeadm/v0.3.6/control-plane-components.yaml
    type: ControlPlaneProvider
images:
    all:
        repository: registry.tkg.vmware.run/cluster-api
    cert-manager:
        repository: registry.tkg.vmware.run/cert-manager
        tag: v0.11.0_vmware.1
release:
    version: v1.1.2
VSPHERE_FOLDER: /Datacenter/vm/Discovered virtual machine
VSPHERE_WORKER_MEM_MIB: "4096"
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa xxxxxxxxxx
    cormac@pks-cli.rainpole.com
CLUSTER_CIDR: 100.96.0.0/11
VSPHERE_HAPROXY_TEMPLATE: /Datacenter/vm/Templates/photon-3-haproxy-v1.2.4+vmware.1
VSPHERE_NETWORK: VM Network
VSPHERE_RESOURCE_POOL: /Datacenter/host/OCTO-Cluster/Resources
VSPHERE_PASSWORD: <encoded:Vk13YXJlMTIzIQ==>
VSPHERE_CONTROL_PLANE_NUM_CPUS: "2"
VSPHERE_DATASTORE: /Datacenter/datastore/vsanDatastore
VSPHERE_CONTROL_PLANE_DISK_GIB: "40"
VSPHERE_CONTROL_PLANE_MEM_MIB: "4096"
VSPHERE_HA_PROXY_MEM_MIB: "4096"
SERVICE_CIDR: 100.64.0.0/13
VSPHERE_SERVER: 10.27.51.106
VSPHERE_DATACENTER: /Datacenter
VSPHERE_WORKER_NUM_CPUS: "2"
VSPHERE_HA_PROXY_DISK_GIB: "40"
VSPHERE_HA_PROXY_NUM_CPUS: "2"
VSPHERE_USERNAME: administrator@vsphere.local
VSPHERE_WORKER_DISK_GIB: "40"
tkg:
    regions:
      - name: tkg-mgmt-vsphere-20200702124420
        context: tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420
        file: /home/cormac/.kube-tkg/config
        isCurrentContext: false
    current-region-context: tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420

이제 이 config.yaml을 사용하여 UI가 아닌 명령행에서 직접 미래의 TKG 관리 클러스터를 배포할 수 있다.

$ cat .tkg/config.yaml
cert-manager-timeout: 30m0s
overridesFolder: /home/cormac/.tkg/overrides
NODE_STARTUP_TIMEOUT: 20m
BASTION_HOST_ENABLED: "true"
providers:
  - name: cluster-api
    url: /home/cormac/.tkg/providers/cluster-api/v0.3.6/core-components.yaml
    type: CoreProvider
  - name: aws
    url: /home/cormac/.tkg/providers/infrastructure-aws/v0.5.4/infrastructure-components.yaml
    type: InfrastructureProvider
  - name: vsphere
    url: /home/cormac/.tkg/providers/infrastructure-vsphere/v0.6.5/infrastructure-components.yaml
    type: InfrastructureProvider
  - name: tkg-service-vsphere
    url: /home/cormac/.tkg/providers/infrastructure-tkg-service-vsphere/v1.0.0/unused.yaml
    type: InfrastructureProvider
  - name: kubeadm
    url: /home/cormac/.tkg/providers/bootstrap-kubeadm/v0.3.6/bootstrap-components.yaml
    type: BootstrapProvider
  - name: kubeadm
    url: /home/cormac/.tkg/providers/control-plane-kubeadm/v0.3.6/control-plane-components.yaml
    type: ControlPlaneProvider
images:
    all:
        repository: registry.tkg.vmware.run/cluster-api
    cert-manager:
        repository: registry.tkg.vmware.run/cert-manager
        tag: v0.11.0_vmware.1
release:
    version: v1.1.2
VSPHERE_FOLDER: /Datacenter/vm/Discovered virtual machine
VSPHERE_WORKER_MEM_MIB: "4096"
VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa xxxxxxxxxx
    cormac@pks-cli.rainpole.com
CLUSTER_CIDR: 100.96.0.0/11
VSPHERE_HAPROXY_TEMPLATE: /Datacenter/vm/Templates/photon-3-haproxy-v1.2.4+vmware.1
VSPHERE_NETWORK: VM Network
VSPHERE_RESOURCE_POOL: /Datacenter/host/OCTO-Cluster/Resources
VSPHERE_PASSWORD: <encoded:Vk13YXJlMTIzIQ==>
VSPHERE_CONTROL_PLANE_NUM_CPUS: "2"
VSPHERE_DATASTORE: /Datacenter/datastore/vsanDatastore
VSPHERE_CONTROL_PLANE_DISK_GIB: "40"
VSPHERE_CONTROL_PLANE_MEM_MIB: "4096"
VSPHERE_HA_PROXY_MEM_MIB: "4096"
SERVICE_CIDR: 100.64.0.0/13
VSPHERE_SERVER: 10.27.51.106
VSPHERE_DATACENTER: /Datacenter
VSPHERE_WORKER_NUM_CPUS: "2"
VSPHERE_HA_PROXY_DISK_GIB: "40"
VSPHERE_HA_PROXY_NUM_CPUS: "2"
VSPHERE_USERNAME: administrator@vsphere.local
VSPHERE_WORKER_DISK_GIB: "40"
tkg:
    regions:
      - name: tkg-mgmt-vsphere-20200702124420
        context: tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420
        file: /home/cormac/.kube-tkg/config
        isCurrentContext: false
    current-region-context: tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420

3. TKG 관리 클러스터 배포 쿼리

이 시점에서 TKG 관리 클러스터는 이제 내 vSphere 환경에 배포되었다. 다음과 같이 질의할 수 있다.

$ tkg get management-cluster
MANAGEMENT-CLUSTER-NAME            CONTEXT-NAME
tkg-mgmt-vsphere-20200702124420 *  tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420

단일 제어부 VM과 단일 작업자 VM을 제공하는 "dev" 배포를 요청했었습니다. 컨텍스트를 관리 클러스터로 전환하면 확인할 수 있다.

$ kubectl config get-contexts
CURRENT   NAME                                                                    CLUSTER                           AUTHINFO                                NAMESPACE
          tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420   tkg-mgmt-vsphere-20200702124420   tkg-mgmt-vsphere-20200702124420-admin


$ kubectl config use-context tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420
Switched to context "tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420".


$ kubectl config get-contexts
CURRENT   NAME                                                                    CLUSTER                           AUTHINFO                                NAMESPACE
*         tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420   tkg-mgmt-vsphere-20200702124420   tkg-mgmt-vsphere-20200702124420-admin


$ kubectl get nodes
NAME                                                   STATUS   ROLES    AGE    VERSION
tkg-mgmt-vsphere-20200702124420-control-plane-ftrdz    Ready    master   111m   v1.18.3+vmware.1
tkg-mgmt-vsphere-20200702124420-md-0-cfd484f8b-xhcjc   Ready    <none>   108m   v1.18.3+vmware.1

관리 클러스터는 vSphere 인벤토리에도 분명히 표시된다:

TKG-mgmt-cluster.png

TKG 관리 클러스터는 이전에 요청된 대로 제공된다. 이제 TKG 워크로드 클러스터를 구축하는 데 주목해 봅시다.

4. TKG 워크로드 클러스터 구축

이 모든 것은 tkg 명령줄에서 할 수 있다. 다시 한 번, 제어부 VM과 작업자 VM이 각각 하나씩 있는 단순한 클러스터를 구축하고자 한다. 그러기 위해 tkg 명령어에 "dev"라고 하는 계획을 명시한다(대안 계획은 "prod"이다). 클러스터를 생성한 후 다른 tkg 명령을 사용하여 자격 증명을 검색하십시오. 이렇게 하면 KUBECONFIG가 자동으로 채워진다. 워크로드 클러스터로 컨텍스트를 변경한 후 노드를 쿼리할 수 있으며, 마스터와 작업자가 한 명인 것을 다시 한 번 확인할 수 있다.

$ tkg create cluster cormac-workload --plan dev
Logs of the command execution can also be found at: /tmp/tkg-20200701T171627162185280.log
Validating configuration...
Creating workload cluster 'cormac-workload'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...

Workload cluster 'cormac-workload' created


$ tkg get cluster
NAME             NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES
cormac-workload  default    running  1/1           1/1      v1.18.3+vmware.1


$ tkg get credentials cormac-workload
Credentials of workload cluster 'cormac-workload' have been saved
You can now access the cluster by running 'kubectl config use-context cormac-workload-admin@cormac-workload'

$ kubectl config get-contexts
CURRENT   NAME                                                                    CLUSTER                           AUTHINFO                                NAMESPACE
          cormac-workload-admin@cormac-workload                                   cormac-workload                   cormac-workload-admin
*         tkg-mgmt-vsphere-20200702124420-admin@tkg-mgmt-vsphere-20200702124420   tkg-mgmt-vsphere-20200702124420   tkg-mgmt-vsphere-20200702124420-admin


$ kubectl config use-context cormac-workload-admin@cormac-workload
Switched to context "cormac-workload-admin@cormac-workload".


$ kubectl get nodes
NAME                                    STATUS   ROLES    AGE    VERSION
cormac-workload-control-plane-9g2n9     Ready    master   3m4s   v1.18.3+vmware.1
cormac-workload-md-0-5475745498-ncstb   Ready    <none>   89s    v1.18.3+vmware.1

이제 애플리케이션용으로 이 워크로드 클러스터를 사용한다. 스토리지 클래스, 영구 볼륨, 영구 볼륨 클레임, 포드 등을 구축할 수 있다. 물론, 추가 워크로드 클러스터를 구축하기 위해 tkg 명령을 더 많이 실행할 수 있다. 위의 예에서 나는 가장 간단한 클러스터만 만들었다. prod나 생산계획을 선택할 경우, 제어부 노드 수, 작업자 노드 수, 노드에 사용할 이미지 등의 요구 사항도 지정할 수 있다. 예를 들어 3개의 제어부 노드와 5개의 작업자 노드가 있는 워크로드 클러스터.

$ tkg create cluster cormac-workload --plan=prod -c 3 -w 5
Logs of the command execution can also be found at: /tmp/tkg-20200703T095705874206587.log
Validating configuration...
Creating workload cluster 'cormac-workload'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...

Workload cluster 'cormac-workload' created

$

vSphere 인벤토리에서 해당 클러스터는 다음과 같이 표시된다.

TKG-workload-cluster.png

$ kubectl config get-contexts
CURRENT   NAME                                                                    CLUSTER                           AUTHINFO                                NAMESPACE
*         tkg-mgmt-vsphere-20200703085854-admin@tkg-mgmt-vsphere-20200703085854   tkg-mgmt-vsphere-20200703085854   tkg-mgmt-vsphere-20200703085854-admin


$ tkg get credentials cormac-workload
Credentials of workload cluster 'cormac-workload' have been saved
You can now access the cluster by running 'kubectl config use-context cormac-workload-admin@cormac-workload'


$ kubectl config get-contexts
CURRENT   NAME                                                                    CLUSTER                           AUTHINFO                                NAMESPACE
          cormac-workload-admin@cormac-workload                                   cormac-workload                   cormac-workload-admin
*         tkg-mgmt-vsphere-20200703085854-admin@tkg-mgmt-vsphere-20200703085854   tkg-mgmt-vsphere-20200703085854   tkg-mgmt-vsphere-20200703085854-admin


$ kubectl config use-context cormac-workload-admin@cormac-workload
Switched to context "cormac-workload-admin@cormac-workload".


$ kubectl get nodes
NAME                                    STATUS   ROLES    AGE     VERSION
cormac-workload-control-plane-8jgrn     Ready    master   3m1s    v1.18.3+vmware.1
cormac-workload-control-plane-96mnz     Ready    master   5m46s   v1.18.3+vmware.1
cormac-workload-control-plane-cvrj6     Ready    master   10m     v1.18.3+vmware.1
cormac-workload-md-0-5475745498-2pg9d   Ready    <none>   5m49s   v1.18.3+vmware.1
cormac-workload-md-0-5475745498-md8vn   Ready    <none>   5m46s   v1.18.3+vmware.1
cormac-workload-md-0-5475745498-q75st   Ready    <none>   5m43s   v1.18.3+vmware.1
cormac-workload-md-0-5475745498-vfq6t   Ready    <none>   5m43s   v1.18.3+vmware.1
cormac-workload-md-0-5475745498-xjm9d   Ready    <none>   5m51s   v1.18.3+vmware.1

5. TKG 정리

TKG 정리는 두 개의 폴더로 이루어진 과정이다. 먼저 워크로드 클러스터를 제거한 다음 관리 클러스터를 삭제한다. 워크로드 클러스터를 삭제한 후 클러스터로부터 쿼리하기 위해 컨텍스트를 관리 클러스터로 변경했다. 이 단계는 필요하지 않다. 단지 클러스터를 쿼리하는 또 다른 방법일 뿐이다.

또 다른 흥미로운 점은 친절한 부트스트랩 클러스터가 다시 한번 일어선다는 것이다. 현재 통신하고 있는 개체를 삭제하는 대신 관리 클러스터를 완전히 삭제하기 위해 클러스터로 전환할 수 있도록 하기 위해서입니다.

$ tkg get cluster
NAME             NAMESPACE  STATUS   CONTROLPLANE  WORKERS  KUBERNETES
cormac-workload  default    running  1/1           1/1      v1.18.3+vmware.1


$ tkg delete cluster cormac-workload
Deleting workload cluster 'cormac-workload'. Are you sure?: y█
workload cluster cormac-workload is being deleted


$ tkg get cluster
NAME  NAMESPACE  STATUS  CONTROLPLANE  WORKERS  KUBERNETES


$ kubectl config get-contexts
CURRENT   NAME                    CLUSTER      AUTHINFO           NAMESPACE
          tkgmgmt-admin@tkgmgmt   tkgmgmt      tkgmgmt-admin


$ kubectl config use-context  tkgmgmt-admin@tkgmgmt
Switched to context "tkgmgmt-admin@tkgmgmt".


$ kubectl get cluster -A
NAMESPACE    NAME      PHASE
tkg-system   tkgmgmt   Provisioned


$ tkg get management-cluster
MANAGEMENT-CLUSTER-NAME  CONTEXT-NAME
tkgmgmt *                tkgmgmt-admin@tkgmgmt


$ tkg delete management-cluster tkgmgmt
Logs of the command execution can also be found at: /tmp/tkg-20200702T122047044190616.log
Deleting management cluster 'tkgmgmt'. Are you sure?: y█
Verifying management cluster...
Setting up cleanup cluster...
Installing providers to cleanup cluster...
Fetching providers
Installing cert-manager
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v0.3.6" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v0.3.6" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v0.3.6" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-vsphere" Version="v0.6.5" TargetNamespace="capv-system"
Moving Cluster API objects from management cluster to cleanup cluster...
Performing move...
Discovering Cluster API objects
Moving Cluster API objects Clusters=1
Creating objects in the target cluster
Deleting objects from the source cluster
Waiting for the Cluster API objects to get ready after move...
Deleting regional management cluster...
Management cluster 'tkgmgmt' deleted.
Deleting the management cluster context from the kubeconfig file '/home/cormac/.kube/config'
warning: this removed your active context, use "kubectl config use-context" to select a different one

Management cluster deleted!
$

그리고 이때 TKG 클러스터의 모든 흔적이 제거된다.

6. TKG 배치 문제 해결

TKG 관리클러스터가 왜 성공적으로 배치되지 않았는지 알 필요가 있을 수 있다. 이렇게 하는 방법 중 하나는 다음과 같이 docker exec를 사용해서 부트스트랩 클러스터 / 친절한 제어부 컨테이너에 로그인하는 것이다.

$ docker ps
CONTAINER ID        IMAGE                                                COMMAND                  \
CREATED             STATUS              PORTS                       NAMES
e9b5fb8b986a        registry.tkg.vmware.run/kind/node:v1.18.3_vmware.1   "/usr/local/bin/entr…"   \
2 minutes ago       Up 2 minutes        127.0.0.1:45919->6443/tcp   tkg-kind-brveafnavu7g23j0t5e0-control-plane


$ docker exec -it e9b5fb8b986a /bin/bash
root@tkg-kind-brveafnavu7g23j0t5e0-control-plane:/#

이제 부트스트랩 클러스터의 다양한 로그 파일을 살펴본다. 이것들은 모두 /var/log에 있다.

root@tkg-kind-brveafnavu7g23j0t5e0-control-plane:/# cd /var/log
root@tkg-kind-brveafnavu7g23j0t5e0-control-plane:/var/log# ls pods
capi-kubeadm-bootstrap-system_capi-kubeadm-bootstrap-controller-manager-6857dfc668-zk67x_4300c6dc-3f50-41cd-99d8-d4203419c420
capi-kubeadm-control-plane-system_capi-kubeadm-control-plane-controller-manager-85f4885cf5-trh22_2332d4da-dd31-444b-b96e-5de1ec1ddb15
capi-system_capi-controller-manager-5df8c8fb59-l47fm_4e8a98df-4af9-40eb-a418-503e7a668a14
capi-webhook-system_capi-controller-manager-7d8d9b87b8-6hq9x_4568906b-4ce9-4a89-a11f-eb2400525f0a
capi-webhook-system_capi-kubeadm-bootstrap-controller-manager-dff99d987-l4vr6_ef3f7ef8-0dcf-4aef-b609-c12103be59d5
capi-webhook-system_capi-kubeadm-control-plane-controller-manager-6cc995dd6c-wgcsd_d563e990-4c77-4769-9a96-548b9d4f1e24
capi-webhook-system_capv-controller-manager-5cdc58c9ff-c54h6_001d37d5-d68d-4afa-9589-a2bd3d4e622d
capv-system_capv-controller-manager-546d5b4b78-xznd2_3f607f72-fe7c-4577-ac58-3630c4e9d492
cert-manager_cert-manager-b56b4dc78-lp22b_875bee0e-8f0e-48d7-bd84-0ec0ecf24ff7
cert-manager_cert-manager-cainjector-6b54f84d85-qgjbp_8b8223d7-90d4-42b2-8866-3003004326aa
cert-manager_cert-manager-webhook-6fbc6d7449-qmqgm_fd9e4e02-12cd-4c1b-8a74-0f24b0e86043
kube-system_coredns-dbbffcb66-c8mz4_7540534d-5ebf-46e5-b3a7-808d253e4152
kube-system_coredns-dbbffcb66-mgh54_cd93a10e-c34a-4e7c-a4d0-8762b70fe68c
kube-system_etcd-tkg-kind-brveafnavu7g23j0t5e0-control-plane_90686900a9bab245caac254dd65ae1a6
kube-system_kindnet-9tk2p_1abf6881-ef5d-4646-a375-0f5d6b3e5916
kube-system_kube-apiserver-tkg-kind-brveafnavu7g23j0t5e0-control-plane_ee85bcff6177159f1125b2226dcad9b5
kube-system_kube-controller-manager-tkg-kind-brveafnavu7g23j0t5e0-control-plane_fb74d22435982c7fbf6da8e6f249e2c9
kube-system_kube-proxy-hv2r7_36381438-854b-49e3-8d66-4f7739e22729
kube-system_kube-scheduler-tkg-kind-brveafnavu7g23j0t5e0-control-plane_f3f4e6af5f879aff5937d22e94bac1f7
local-path-storage_local-path-provisioner-774f7f8fdb-7hsnc_ba3591cd-582e-4d6a-b10d-86ffe757c3f7

root@tkg-kind-brveafnavu7g23j0t5e0-control-plane:/var/log# ls containers
capi-controller-manager-5df8c8fb59-l47fm_capi-system_kube-rbac-proxy-9b15f6205a69b0ed9ea1bbd340638173b28cb38921aa19bfd6fb2a7ca3557840.log
capi-controller-manager-5df8c8fb59-l47fm_capi-system_manager-2d1c9b815014c12f2d2ae8af2bc23545027f0db2d22616e7aac5356effae4f87.log
capi-controller-manager-7d8d9b87b8-6hq9x_capi-webhook-system_kube-rbac-proxy-d485df7899eba33eede51e72c8dd7fcc5a7b5c4aca477c8250243054012f797b.log
capi-controller-manager-7d8d9b87b8-6hq9x_capi-webhook-system_manager-c48c3ea0ad7dd0f5dca73a33131bf5d80019eab149f6e861be19351f0c7ac985.log
capi-kubeadm-bootstrap-controller-manager-6857dfc668-zk67x_capi-kubeadm-bootstrap-system_kube-rbac-proxy-310665e0515da7f65a0ba03bbea227e6575f338fa5b634fb29ebb59289e35e46.log
capi-kubeadm-bootstrap-controller-manager-6857dfc668-zk67x_capi-kubeadm-bootstrap-system_manager-99e238b941406409f404b632dd1740152b5d98f406a808819f0c6fc556bda1ff.log
capi-kubeadm-bootstrap-controller-manager-dff99d987-l4vr6_capi-webhook-system_kube-rbac-proxy-dde7c58b183dcc2d516447a7932a727f909fb96fb1cad89a961468d28f74c142.log
capi-kubeadm-bootstrap-controller-manager-dff99d987-l4vr6_capi-webhook-system_manager-4cfcba0bf1c76530c8b6116c61fe6a15f09d7cd3c157c1b109ca75da5ded93f5.log
capi-kubeadm-control-plane-controller-manager-6cc995dd6c-wgcsd_capi-webhook-system_kube-rbac-proxy-b8afb5f7b555fdbd40e2407d8cb102e590ba6d7a6967b146f68789fe0bed6ffd.log
capi-kubeadm-control-plane-controller-manager-6cc995dd6c-wgcsd_capi-webhook-system_manager-096060da6ca21b1f3b0805b2a440c1fe59b4a12d18b5aeae2fdcf781ef6f3ad9.log
capi-kubeadm-control-plane-controller-manager-6cc995dd6c-wgcsd_capi-webhook-system_manager-9944a9dfeec54333536a08646868fe2e1e1b3ee6099f3e94a8bd8ff39bdaa230.log
capi-kubeadm-control-plane-controller-manager-85f4885cf5-trh22_capi-kubeadm-control-plane-system_kube-rbac-proxy-d56a61de271e47500144c2f99b6f1087a145c4a9a48024cfc4df4fd813f4e656.log
capi-kubeadm-control-plane-controller-manager-85f4885cf5-trh22_capi-kubeadm-control-plane-system_manager-c56da1c0852fe5a557d31bb7aff6b49166075ea7f6ec94ea11255d4d7a957e2b.log
capv-controller-manager-546d5b4b78-xznd2_capv-system_kube-rbac-proxy-a6ec83a76cc218412087e02aebe18df758d261032d8980777347d507425b6163.log
capv-controller-manager-546d5b4b78-xznd2_capv-system_manager-7f755d80002ba9f7b115662c68d3c5603a51e495741a47b8668818da8f47fa1d.log
capv-controller-manager-5cdc58c9ff-c54h6_capi-webhook-system_kube-rbac-proxy-a32432af21eb459ab1cdae2fcb827c2631cfdad4f89480faf46eb9c18063b955.log
capv-controller-manager-5cdc58c9ff-c54h6_capi-webhook-system_manager-d21d2386d64424b891f45aa869f042a2df84401864f0e152f4365f61c79bd631.log
cert-manager-b56b4dc78-lp22b_cert-manager_cert-manager-ddd1b4fc3a639d0baf6e08ef3d03e94f6d201f06870dde7fe0fd7d8969d2bb97.log
cert-manager-cainjector-6b54f84d85-qgjbp_cert-manager_cainjector-7190813bdac45dc26838c47cb3b31d087db8c6d03024631cfdac400f4112c3b9.log
cert-manager-webhook-6fbc6d7449-qmqgm_cert-manager_cert-manager-ce208041b82f8e8d3f1a557ce448b387c3d5800e25a12b9f1f477f9ca49e91c5.log
cert-manager-webhook-6fbc6d7449-qmqgm_cert-manager_cert-manager-f0dee859352a94e3a11f516eb616c37af9cd4abf14e44eef2ab64a1fc7abea15.log
coredns-dbbffcb66-c8mz4_kube-system_coredns-7fff45ced9afca22169f9d81b41b5cd87a62352b55aa90d406b3d7e2f1d1878c.log
coredns-dbbffcb66-mgh54_kube-system_coredns-d1fbb9b15590eeb5e4ce776b7f570820413347db90956af4a8a0a461b7d392a0.log
etcd-tkg-kind-brveafnavu7g23j0t5e0-control-plane_kube-system_etcd-9b7343b8a053e720c8acaf9179ff455869415057e9f0243be004f9cae433ace5.log
kindnet-9tk2p_kube-system_kindnet-cni-78de1eeacb92283157c7498fb0a1bbabf1e46691d6f5474842204154dea7f9fc.log
kube-apiserver-tkg-kind-brveafnavu7g23j0t5e0-control-plane_kube-system_kube-apiserver-6672c0be051251a783a63c86ed7c51cef15e5be2d02b62f50b101d454e30e55c.log
kube-controller-manager-tkg-kind-brveafnavu7g23j0t5e0-control-plane_kube-system_kube-controller-manager-99d8f7c5b66b32826c93871e4967ad015adec1c8516818c8ecd7fd08f45f4585.log
kube-proxy-hv2r7_kube-system_kube-proxy-84733041e786bbc53d07fcce291f7db54da22a80b6cb915afdb5658cab013928.log
kube-scheduler-tkg-kind-brveafnavu7g23j0t5e0-control-plane_kube-system_kube-scheduler-a6deb97edc6aa4d5cbe68e2f29b9639e7cf8cc060938721d6001efe4299461d0.log
local-path-provisioner-774f7f8fdb-7hsnc_local-path-storage_local-path-provisioner-b01f701fefab582d1b22d30a8b8eaee9bb9780f53ef68a0bf5b9d314210f32b8.log
root@tkg-kind-brveafnavu7g23j0t5e0-control-plane:/var/log#

자세한 문제 해결을 위해 쿠버네티스에 대한 충돌 복구 및 진단을 고려한다(단순 충돌). 이렇게 하면 이전에 표시한 대로 클러스터에 실행하지 않고도 클러스터에서 필요한 모든 로그를 수집할 수 있다. 여기서 더 많은 충돌 세부사항을 찾을 수 있다.

이를 통해 TKG(독립형) 제품을 잘 이해하고, 쿠베르네츠 클러스터를 매우 단순하고 신속하게 구축하는 데 어떻게 활용할 수 있는지 잘 이해하셨기를 바란다.