Kubernetes

PKS, vSphere with Kubernetes, CSI 등

[번역] A closer look at vSphere with Kubernetes Permissions

출처 : https://cormachogan.com/2020/07/10/a-closer-look-at-vsphere-with-kubernetes-permissions/

Cloud-Native-Apps-Icon-2020.png

최근 vSphere with Kubernetes에 대한 많은 게시물에서 단일 사용자(administrator@vsphere.local)를 사용하여 모든 작업을 수행한다. 이를 통해 허가 걱정 없이 다양한 활동을 할 수 있다. 이 vSphere SSO(Single Sign-On) 관리자는 모든 vK8s 네임스페이스에 대해 "edit" 권한을 가지고 있다. 이 게시물에서는 서로 다른 일부 vSphere SSO 사용자와 사용 권한을 서로 다른 네임스페이스에 할당하는 방법과 이러한 사용 권한이 (Kubernetes ClusterRole 및 RoleBinding 구성을 통해) vK8s 플랫폼에서 구현되는 방법에 대해 살펴보고자 한다.

먼저 vK8s에서 네임스페이스가 어떻게 표시되는지 살펴봅시다. 기본적으로 네임스페이스에 할당된 사용 권한은 없다.

0-vK8s-Permissions.png

이제 네임스페이스 권한에 사용할 수 있도록 새 vSphere SSO 사용자를 생성해 부자. 새 사용자를 추가하는 절차는 Administration > Single Sign On > Users and Groups 아래의 vSphere Client에서 찾을 수 있다.

1-Add-vSphere-SSO-User.png

사용자가 생성되면 이제 네임스페이스 권한에 역할과 함께 추가할 수 있다. 사용자에게 할당할 수 있는 두 가지 간단한 역할이 있는데, view 또는 edit다..

2-View-or-Edit-Permissions.png

이 테스트를 위해 사용자 cormac에게 네임스페이스 darren-ns에서는 볼 수 있지만 네임스페이스 cormac-ns에서는 편집할 수 있는 역할을 부여했다.

3-darren-ns.png

4-cormac-ns.png

이제 사용자 cormac으로 vK8s에 로그인하여 서로 다른 네임스페이스에서 수행할 수 있는 작업과 수행할 수 없는 작업에 대해 알아보자.

$ kubectl-vsphere login  --server=https://20.0.0.1 --insecure-skip-tls-verify --vsphere-username \
cormac@vsphere.local

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

You have access to the following contexts:
   20.0.0.1
   cormac-ns
   darren-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>`

이제 사용자 cormac은 네임스페이스 darren-ns에서만 볼 수 있다는 것을 기억하자. 네임스페이스 컨텍스트로 전환하여 해당 네임스페이스에서 사용자 cormac으로 영구 볼륨 클레임을 생성하려고 하면 어떻게 되는지 확인하자.

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


$ kubectl config use-context darren-ns
Switched to context "darren-ns".


$ kubectl apply -f block-pvc.yaml
Error from server (Forbidden): error when creating "block-pvc.yaml": persistentvolumeclaims is forbidden: \
User "sso:cormac@vsphere.local" cannot create resource "persistentvolumeclaims" in API group "" in the \
namespace "darren-ns"

우리가 알 수 있듯이, 사용자 cormac은 이 사용자가 해당 네임스페이스에 보기 역할만 가지고 있기 때문에 해당 네임스페이스에 새 개체를 만들 수 없다. 사용자 cormac이 편집 권한을 가진 네임스페이스 cormac-ns에서 유사한 작업을 시도해보자.

$ kubectl config use-context cormac-ns
Switched to context "cormac-ns".

$ kubectl apply -f ./Pacific/BT-DEMO/pacific-vsan-block-rwo/block-pvc.yaml
persistentvolumeclaim/block-pvc created
$

이 작전은 성공적이다. 그래서 어떻게 시행되는가? 사용자가 제공된 CLI 명령 kubectl-vsphere 로그인을 사용하여 vK8s에 로그인할 때 쿠베르네츠 환경에서는 쿠베르네츠 구성(일반적으로 .kube/config)이 클러스터, 컨텍스트 및 사용자 세부 정보로 업데이트된다는 점을 가장 먼저 알아야 한다. vK8s가 사용되도록 설정되면 토큰 Exchange 서비스가 vCenter 서버에서 실행됨 이렇게 하면 vSphere SSO 자격 증명이 필요하며 쿠베르네테스 RBAC와 함께 사용할 수 있도록 JSON 웹 토큰(JWT)으로 변환된다. 이를 통해 vSphere 사용자는 vK8s 클러스터에 로그인할 수 있다. 다음과 유사한 항목이 쿠베르네츠 구성 파일에 추가된다. 우리는 감독관 클러스터와 두 개의 네임스페이스 컨텍스트를 가지고 있지만, 모두 동일한 사용자를 가지고 있다. 구성 파일의 사용자 섹션에서 토큰을 볼 수 있다.

contexts:
- context:
    cluster: 20.0.0.1
    user: wcp:20.0.0.1:cormac@vsphere.local
  name: 20.0.0.1

- context:
    cluster: 20.0.0.1
    namespace: cormac-ns
    user: wcp:20.0.0.1:cormac@vsphere.local
  name: cormac-ns

- context:
    cluster: 20.0.0.1
    namespace: darren-ns
    user: wcp:20.0.0.1:cormac@vsphere.local
  name: darren-ns


- name: wcp:20.0.0.1:cormac@vsphere.local
  user:
    token: eyJraWQiOiI4QTVCNUMxREExNDUwMTg3QzMyQjI1NDBDMDBCQ0YzMUYzMkU2NEE3IiwiYWxnIjoiUlMyNTYifQ....

토큰은 로그인 시 할당되며 10시간 동안 지속된다. 일단 만료되면 사용자는 한 번 더 인증을 받아야 한다. 로그아웃 시 클러스터, 컨텍스트 및 사용자 토큰이 구성 파일에서 제거된다.

그러나 지금 발생하는 문제는 앞에서 본 사용 권한이 vSphere SSO에서 Kubernetes RBAC로 어떻게 전파되는가 하는 것이다. 이 사용자가 일부 네임스페이스에 대한 편집 권한을 가지고 있지만 다른 네임스페이스에 대한 사용 권한을 보는 방법 이를 이해하려면 ClusterRole 및 RoleBinding과 같은 Kubernetes 구성 요소를 살펴봐야 한다(참고: 이러한 구성 요소는 vK8s 네임스페이스가 아닌 Supervisor Control VM에서만 검사할 수 있음). 먼저 ClusterRoles 목록을 표시해 봅자. 여기서 다른 모든 역할 중에서 edit와 view라는 두 가지 역할이 있음을 알 수 있다. 이전에 네임스페이스 권한에서 보았던 역할 편집 및 보기에 매핑된 기능이다.

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get ClusterRole
NAME                                                                   AGE
admin                                                                  2d1h
aggregate-workload-cluster-admin                                       2d1h
cluster-admin                                                          2d1h
edit                                                                   2d1h
ncp-cluster-role                                                       2d1h
ncp-patch-role                                                         2d1h
nsx-node-agent-cluster-role                                            2d1h
system:aggregate-to-admin                                              2d1h
system:aggregate-to-edit                                               2d1h
system:aggregate-to-view                                               2d1h
system:auth-delegator                                                  2d1h
system:basic-user                                                      2d1h
system:certificates.k8s.io:certificatesigningrequests:nodeclient       2d1h
system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   2d1h
system:controller:attachdetach-controller                              2d1h
.
.
.
system:persistent-volume-provisioner                                   2d1h
system:public-info-viewer                                              2d1h
system:volume-scheduler                                                2d1h
view                                                                   2d1h
vmware-image-agent-clusterrole                                         2d1h
vmware-image-controller-clusterrole                                    2d1h
vmware-registry-manager-clusterrole                                    2d1h
.
.
.
wcp:guest-clusters-view                                                2d1h
wcp:guest-clusters-view-cluster-scope-vmresources                      2d1h
wcp:schedext-role-annotations                                          2d1h
wcp:schedext-role-namespaces                                           2d1h
root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]#

상상한 바와 같이, 두 역할의 주요 차이점은 view 역할이 일반적으로 개체를 가져오거나 나열하거나 감시할 수 있지만, edit 역할은 개체 생성, 삭제, 패치 및 업데이트와 같은 작업도 수행할 수 있다는 것이다. 역할에 대한 설명을 실행하면 역할과 관련된 전체 기능 집합을 볼 수 있다.

이제 네임스페이스에 대한 액세스를 제어하는 것으로 생각할 수 있는 RoleBindings에 대해 살펴봅시다. 우리는 사용자 cormac에게 두 개의 네임스페이스인 cormac-ns와 darren-ns를 할당한다. 이 사용자가 각 네임스페이스에 RoleBinding되어 있는 것을 볼 수 있다.

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get RoleBinding -n cormac-ns
NAME                                               AGE
wcp:cormac-ns:group:vsphere.local:administrators   2d1h
wcp:cormac-ns:user:vsphere.local:administrator     89m
wcp:cormac-ns:user:vsphere.local:cormac            93m

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get RoleBinding -n darren-ns
NAME                                               AGE
wcp:darren-ns:group:vsphere.local:administrators   25h
wcp:darren-ns:user:vsphere.local:administrator     89m
wcp:darren-ns:user:vsphere.local:cormac            90m

이제 RoleBindings를 자세히 살펴봅시다. 그러면 네임스페이스 cormac-ns의 cormac에 대한 RoleBinding이 ClusterRole을 편집하고, 네임스페이스 darren-ns의 RoleBinding은 ClusterRole만 볼 수 있다고 가정해보자. 정말 그렇다. 먼저 cormac-ns를 보자.

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl describe RoleBinding wcp:cormac-ns:user:vsphere.local:cormac -n cormac-ns

Name:         wcp:cormac-ns:user:vsphere.local:cormac
Labels:       managedBy=vSphere
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  edit
Subjects:
  Kind  Name                      Namespace
  ----  ----                      ---------
  User  sso:cormac@vsphere.local


root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get RoleBinding wcp:cormac-ns:user:vsphere.local:cormac -n cormac-ns -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2020-07-08T10:47:53Z"
  labels:
    managedBy: vSphere
  name: wcp:cormac-ns:user:vsphere.local:cormac
  namespace: cormac-ns
  resourceVersion: "1232328"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/cormac-ns/rolebindings/wcp:cormac-ns:user:vsphere.local:cormac
  uid: eec05c61-57a5-40ba-814c-7ade94c34011
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: edit
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: sso:cormac@vsphere.local
root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]#

cormac-ns의 RoleBinding에서 cormac이 사용하기 위한 edit clusterRole을 명확히 볼 수 있다. 다음에 darren-ns를 봅시다.

root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl describe rolebinding wcp:darren-ns:user:vsphere.local:cormac -n darren-ns

Name:         wcp:darren-ns:user:vsphere.local:cormac
Labels:       managedBy=vSphere
Annotations:  <none>
Role:
  Kind:  ClusterRole
  Name:  view
Subjects:
  Kind  Name                      Namespace
  ----  ----                      ---------
  User  sso:cormac@vsphere.local


root@4216cd4619c10fbf96e48deaa2ed8228 [ ~ ]# kubectl get rolebinding wcp:darren-ns:user:vsphere.local:cormac -n darren-ns -o yaml

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  creationTimestamp: "2020-07-08T10:50:18Z"
  labels:
    managedBy: vSphere
  name: wcp:darren-ns:user:vsphere.local:cormac
  namespace: darren-ns
  resourceVersion: "1233346"
  selfLink: /apis/rbac.authorization.k8s.io/v1/namespaces/darren-ns/rolebindings/wcp:darren-ns:user:vsphere.local:cormac
  uid: ac47c339-2503-40f6-8726-1b00ea243485
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: view
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: sso:cormac@vsphere.local

그리고 마지막으로 우리는 darren-ns 네임스페이스에서 cormac 사용자에게 사용되는 ClusterRole이 view다. 이 사용자가 앞서 PVC를 만들 수 없었던 이유다. 이를 통해 vSphere SSO 로그인이 ClusterRole 및 RoleBindings를 사용하여 Kubernetes와 함께 vSphere에서 구현되는 방법에 대한 좋은 통찰력을 얻으셨기를 바란다.

[번역] vSphere with Kubernetes on VCF 4.0.1 Consolidated Architecture

출처 : https://cormachogan.com/2020/07/08/vsphere-with-kubernetes-on-vcf-4-0-1-consolidated-architecture/

Cloud-Foundation-Icon-2020-264x190.png

VMware는 최근 VCF(VMware Cloud Foundation) 4.0.1의 가용성(availability 을 발표했다. 이번 릴리스에서는 VCF Management Domain에서 vSphere with Kubernetes 배포와 관련하여 몇 가지 향상된 기능을 소개했으므로 특히 관심이 많았다. 우리는 VCF 통합 아키텍처로 관리 도메인에 애플리케이션을 배포하는 것을 언급한다. VCF 버전 4.0의 Management Domain에서 vSphere with Kubernetes를 구축할 수 있었지만 완벽하게 통합되지는 않았다. 특히 필요한 vSphere for Kubernetes 검증 테스트를 수행할 관리 도메인을 선택할 수 없었다. VCF 4.0.1에서는 이제 SDDC Manager에서 관리 도메인을 선택하고 검증 단계를 수행할 수 있다. 이 간략한 게시물에서는 업데이트된 배포 절차를 중심으로 하겠다.

Cloud-Native-Apps-Icon-2020.png

이 워크플로우를 테스트하기 위해 VCF 4.0 환경을 VCF 4.0.1(vCenter Server, ESXi 호스트, NSX-T, SDDC Manager 및 vSAN)로 업그레이드했다. 그런 다음 현재 Kubernetes 환경이 포함된 vSphere를 관리 도메인에서 제거하고 새 vSphere를 다시 배포했다. VCF 4.0.1에서 Kubernetes Workload가 포함된 새 vSphere를 배포하려면 SDDC 관리자에서 솔루션을 선택하고 배포를 선택하십시오. 여기서 워크로드 도메인에 쿠버네티스를 포함한 vSphere를 구축한다.

 

1-Solutions-workload-mgmt.png

다음 단계에서는 적절한 워크로드 도메인, 적절한 라이센스 및 NSX-T Edge Cluster를 비롯한 모든 필수 구성 요소가 준비되었는지 확인한다. 이 모든 항목이 올바른 위치에 있으면 모든 항목을 선택한 다음 BEGIN을 클릭한다.

2-wcp-prerequisites.png

이를 통해 Kubernetes와 함께 vSphere의 워크로드 도메인을 선택할 수 있게 되었다. 이전 VCF 4.0에서는 관리 도메인이 옵션으로 표시되지 않았다. VCF 4.0.1에서는 이제 관리 도메인이 옵션으로 제공된다.

3-select-mgmt-domain.png

관리 도메인을 선택하면 vSphere와 Kubernetes와 호환되는 모든 vSphere 클러스터가 표시된다. 검증 단계로 이동할 클러스터를 선택한다.

4-select-cluster.png

이제 SDDC 매니저는 환경이 vSphere with Kubernetes에 적합한지 검증한다. 모든 단계가 성공한 경우 검토 단계로 이동한다.

5-validation.png

검토가 양호하면 "Complete in vSphere" 버튼을 클릭하십시오. 그러면 vSphere Client로 이동하여 VCF 4.0.1 관리 도메인에서 쿠베르네테스와 함께 vSphere 배포를 완료한다.

6-review.png

이 시점에서는 계속해서 워크로드 관리/vSphere with Kubernetes를 구축할 수 있다.

7-enable-workload-mgmt.png

이렇게 하면 워크플로 업데이트 검토가 완료된다. 이제 SDDC Manager for vSphere for Kubernetes 배포 환경에서 관리 도메인을 선택하고 검증할 수 있다. VMware Cloud Foundation에서 vSphere를 Kubernetes와 함께 실행하는 방법에 대해 자세히 알아보거나, VCF에 대해 자세히 알아보려면 여기에 여러 게시물을 참조하기 바란다.

 

[번역] 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을 사용할 수 있어야 한다는 구상이다. 어떤 장치를 사용하기로 결정하든 클러스터를 성공적으로 배포하려면 다음과 같은 구성 요소가 필요하다.

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 관리 클러스터를 구축하면 된다.