이 게시물에서는 Cluster API를 살펴본 다음 TKG v.1.3.1의 변경 사항을 살펴보겠습니다. TKG는 Cluster API를 광범위하게 사용하여 Kubernetes 클러스터를 생성하므로, 이 게시물의 첫 부분에서 보이는 내용을 두 번째 부분에서 TKG에 적용할 수 있을 것입니다. 클러스터 API에는 이미 방대한 양의 정보와 문서가 있으므로 여기서는 모든 내용을 다루지는 않겠습니다. 이 링크에서는 클러스터 API를 지원하기 위해 클러스터에 추가되는 모든 사용자 지정 리소스에 대해 설명하는 클러스터 API 개념으로 이동합니다. 이것은 클러스터 API 빠른 시작 안내서에 연결하여 사용자가 직접 클러스터 API를 설정할 수 있도록 도와줍니다.
이름에서 알 수 있듯이 Cluster API의 목적은 K8s에서 생성, 구성, 관리, 모니터링 및 삭제와 같은 클러스터 작업을 활성화하는 것입니다. 클러스터 API에는 두 가지 클러스터 개념이 있습니다. 관리 클러스터는 하나 이상의 인프라 공급자를 포함하여 클러스터 API 구성 요소가 설치된 Kubernetes 클러스터입니다. 이 관리 클러스터는 이제 워크로드 클러스터의 라이프사이클을 담당합니다. 워크로드 클러스터는 관리 클러스터에서 프로비저닝 및 관리하는 K8s 클러스터일 뿐입니다.
클러스터 API가 작동하는 것을 보려면 K8s 클러스터가 필요합니다. 간단하게 Kubernetes in Docker(kind) 클러스터에 간단한 Kubernetes를 생성한 다음 clusterctl 바이너리를 설치한 후 마지막으로 해당 Cluster를 초기화하여 하나 이상의 워크로드 클러스터를 구현할 수 있도록 합니다.
1부: 1단계 – kind 클러스터 만들기
kind 바이너리를 설치하는 방법을 보여주지 않을 것이다. 도커 컨테이너에 쿠버네티스를 배치하기 때문에 도커를 설치해야 합니다. 여기서 빠른 시작을 할 수 있습니다. Docker가 실행 중이고 Kind가 설치되면 다음과 같이 Kubernetes 클러스터를 생성할 수 있습니다.
$ kind create cluster Creating cluster "kind" ... ✓ Ensuring node image (kindest/node:v1.21.1) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ ✓ Installing CNI 🔌 ✓ Installing StorageClass 💾 Set kubectl context to "kind-kind" You can now use your cluster with: kubectl cluster-info --context kind-kind Have a nice day! 👋 $
위 출력의 kubectl 명령으로 컨텍스트를 전환하고, 실행중인 파드를 확인합니다.
$ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE kube-system coredns-558bd4d5db-lfnth 1/1 Running 0 24s kube-system coredns-558bd4d5db-rkktw 1/1 Running 0 24s kube-system etcd-kind-control-plane 1/1 Running 0 28s kube-system kindnet-h2brs 1/1 Running 0 25s kube-system kube-apiserver-kind-control-plane 1/1 Running 0 28s kube-system kube-controller-manager-kind-control-plane 1/1 Running 0 28s kube-system kube-proxy-vht8q 1/1 Running 0 25s kube-system kube-scheduler-kind-control-plane 1/1 Running 0 40s local-path-storage local-path-provisioner-547f784dff-zgqn5 1/1 Running 0 24s
1부: 2단계 – clusterctl 바이너리
clusterctl 도구는 Cluster API를 실행하는 방법과 특히 관리 클러스터를 생성하는 방법입니다. GitHub에서 다운로드할 수 있습니다. 다음은 Cluster API 빠른 시작 가이드와 같이 버전 v0.3.17을 다운로드하는 방법입니다.
$ curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v0.3.17/clusterctl-linux-amd64 \ -o clusterctl
clusterctl 바이너리를 사용할 수 있고 실행 파일로 변경되며 $PATH에서 사용할 수 있는 모드를 사용하면 관리 클러스터 생성을 진행할 수 있습니다.
1부: 3단계 – 클러스터 API 관리 클러스터 초기화
clusterctl init 명령은 Cluster API core provider, kubeadm 부트스트랩 프로바이더 및 kubeadm control-plane 프로바이더를 자동으로 추가합니다. vSphere 위에서 실행할 때 init 명령은 –infrastructure vsphere 옵션을 사용하여 vSphere 제공자를 포함합니다(VSPHERE_USERNAME 및 VSPHERE_PASSWORD 환경 변수를 설정해야 함). 이렇게 하면 4개의 제공자를 종류 클러스터(현재 kubeconfig 컨텍스트)에 추가할 수 있습니다. 필요한 환경 변수를 포함하는 관리 클러스터를 초기화하는 샘플 스크립트는 이 GitHub repo에서 찾을 수 있습니다. 다음은 필요한 모든 환경 변수를 이전에 내보냈다고 가정한 실행 방법의 예입니다.
$ kubectl config get-contexts CURRENT NAME CLUSTER AUTHINFO NAMESPACE * kind-kind kind-kind kind-kind $ clusterctl init --infrastructure vsphere Fetching providers Installing cert-manager Version="v1.1.0" Waiting for cert-manager to be available... Installing Provider="cluster-api" Version="v0.3.17" TargetNamespace="capi-system" Installing Provider="bootstrap-kubeadm" Version="v0.3.17" TargetNamespace="capi-kubeadm-bootstrap-system" Installing Provider="control-plane-kubeadm" Version="v0.3.17" TargetNamespace="capi-kubeadm-control-plane-system" Installing Provider="infrastructure-vsphere" Version="v0.7.7" TargetNamespace="capv-system" Your management cluster has been initialized successfully! You can now create your first workload cluster by running the following: clusterctl config cluster [name] --kubernetes-version [version] | kubectl apply -f -
이렇게 하면 다음과 같이 제공자에 해당하는 여러 개체가 종류 클러스터에 생성됩니다. 추가된 내용을 알려드리기 위해 포드 리스트를 보여드리는 것입니다. 4개 프로바이더 모두 각자의 네임스페이스에 배치된 팟을 볼 수 있습니다.
$ kubectl get pods -A NAMESPACE NAME READY STATUS RESTARTS AGE capi-kubeadm-bootstrap-system capi-kubeadm-bootstrap-controller-manager-f98476fd6-vtzm9 2/2 Running 0 47s capi-kubeadm-control-plane-system capi-kubeadm-control-plane-controller-manager-86f749cf89-lk7dc 2/2 Running 0 43s capi-system capi-controller-manager-58f797cb65-cxmwd 2/2 Running 0 50s capi-webhook-system capi-controller-manager-7d596cc4cb-jrdfs 2/2 Running 0 52s capi-webhook-system capi-kubeadm-bootstrap-controller-manager-5499744c7c-nvw5j 2/2 Running 0 49s capi-webhook-system capi-kubeadm-control-plane-controller-manager-5869f67c96-9c9p7 2/2 Running 0 45s capi-webhook-system capv-controller-manager-66ffbd8dfc-p9ctb 2/2 Running 0 41s capv-system capv-controller-manager-bfbb4c968-mq5hv 2/2 Running 0 39s cert-manager cert-manager-86cb5dcfdd-bsthf 1/1 Running 0 71s cert-manager cert-manager-cainjector-84cf775b89-vvdqc 1/1 Running 0 71s cert-manager cert-manager-webhook-7f9f4f8dcb-pr75w 1/1 Running 0 71s kube-system coredns-558bd4d5db-5g95k 1/1 Running 0 4m26s kube-system coredns-558bd4d5db-hhzbs 1/1 Running 0 4m26s kube-system etcd-kind-control-plane 1/1 Running 0 4m43s kube-system kindnet-x7xqh 1/1 Running 0 4m26s kube-system kube-apiserver-kind-control-plane 1/1 Running 0 4m30s kube-system kube-controller-manager-kind-control-plane 1/1 Running 0 4m30s kube-system kube-proxy-szwrd 1/1 Running 0 4m26s kube-system kube-scheduler-kind-control-plane 1/1 Running 0 4m43s local-path-storage local-path-provisioner-547f784dff-j69rp 1/1 Running 0 4m26s
기본 Cluster API 제공자는 kubeadm을 사용하여 제어 평면을 부트스트랩합니다. kubeadm은 쿠버네티스의 일부이며, 쿠버네티스 군집을 만드는 것이 목적이다. kubeadm 부트스트랩 공급자는 클러스터 인증서를 생성하고 제어 영역을 초기화합니다. 제어 영역 초기화가 완료될 때까지 기다렸다가 다른 노드(예: 작업자 노드)를 생성하고 클러스터에 연결합니다. 제어부 초기화는 시스템 기반이며, 이는 (최소한 vSphere의 경우) 생성 평면을 구축하기 위해 가상 시스템이 프로비저닝된다는 것을 의미하며, 이는 kube-apiserver, kube-controller-manager 및 kube-scheduler와 같은 쿠버네티스 서비스를 위한 정적 포드를 생성하는 데 사용됩니다. 이 모든 연결 방법에 대한 자세한 내용은 Cluster API 북의 개념 가이드에서 확인할 수 있습니다.
이제 워크로드 클러스터를 구축할 수 있는 모든 것이 갖춰졌습니다.
1부: 4단계 – 워크로드 클러스터 생성
첫 번째 워크로드 클러스터를 생성하기 전에 상당한 수의 추가 환경 변수를 구성해야 합니다. 전체 목록은 cluster-api-provider-vsphere 설명서에서 찾을 수 있지만 vCenter Server의 IP 주소, vCenter Server 자격 증명 및 데이터 센터 및 데이터스토어와 같은 여러 인벤토리 항목을 제공하는 변수가 필요합니다. 환경 변수가 채워지면 새 워크로드 클러스터를 생성하도록 지정할 수 있습니다. 이 예에서는 Cluster API 퀵 스타트 가이드에 따라 제어부 노드 1개와 작업자 노드 3개를 포함하는 클러스터를 vsphere-quickstart라고 합니다. K8s 버전 v1.18.6은 VSPHERE_TEMPLATE 환경 변수가 참조하는 VM 템플릿과 일치합니다. 이는 vSphere 인벤토리의 템플릿 VM을 참조하며, 사전에 업로드해야 하며 Kubernetes 워크로드 클러스터 제어 영역 및 작업자 노드를 제공할 실제 VM을 생성하는 데 사용됩니다. 필요한 환경 변수를 포함하는 워크로드 클러스터를 생성하는 샘플 스크립트는 이 GitHub repo에서 찾을 수 있습니다.
이 명령은 클러스터, KubeadmControlPlane, vSphere Cluster, vSphere MachineTemplate, MachineDeployment 등과 같은 새 워크로드 클러스터를 구축하는 모든 개체를 포함하는 단일 매니페스트(YAML) 출력을 생성합니다. 다음은 필요한 모든 환경 변수를 이전에 내보냈다고 가정한 실행 방법의 예입니다.
$ clusterctl config cluster vsphere-quickstart --infrastructure vsphere \ --kubernetes-version v1.18.6 --control-plane-machine-count 1 --worker-machine-count 3 > cluster.yaml $ kubectl apply -f cluster.yaml cluster.cluster.x-k8s.io/vsphere-quickstart created vspherecluster.infrastructure.cluster.x-k8s.io/vsphere-quickstart created vspheremachinetemplate.infrastructure.cluster.x-k8s.io/vsphere-quickstart created kubeadmcontrolplane.controlplane.cluster.x-k8s.io/vsphere-quickstart created kubeadmconfigtemplate.bootstrap.cluster.x-k8s.io/vsphere-quickstart-md-0 created machinedeployment.cluster.x-k8s.io/vsphere-quickstart-md-0 created secret/vsphere-csi-controller created configmap/vsphere-csi-controller-role created configmap/vsphere-csi-controller-binding created secret/csi-vsphere-config created configmap/csi.vsphere.vmware.com created configmap/vsphere-csi-node created configmap/vsphere-csi-controller created configmap/internal-feature-states.csi.vsphere.vmware.com created
그러면 vSphere 인프라에 4개의 새 VM(제어판 노드용 1개, 작업자 노드용 3개)을 배포하는 프로세스가 시작됩니다. 이러한 VM의 크기 및 리소스 사용량은 템플릿 Vsphere_TEMPLATE와 동일합니다. 이러한 VM이 vSphere 인벤토리에 나타나기 시작합니다.
1부: 5단계 – CNI 적용
잠시 후 VM을 배포하고 워크로드 클러스터를 구성해야 합니다. 다음과 같이 워크로드 컨텍스트에 액세스하여 워크로드 클러스터의 노드 목록을 표시할 수 있습니다.
$ clusterctl get kubeconfig vsphere-quickstart > quickstart-kubeconfig $ kubectl get nodes --kubeconfig quickstart-kubeconfig -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME vsphere-quickstart-d9cr2 NotReady master 7m24s v1.18.6+vmware.1 10.27.51.50 10.27.51.50 VMware Photon OS/Linux 4.19.132-1.ph3 containerd://1.3.4 vsphere-quickstart-md-0-57ff99b55-8zk44 NotReady <none> 4m59s v1.18.6+vmware.1 10.27.51.51 10.27.51.51 VMware Photon OS/Linux 4.19.132-1.ph3 containerd://1.3.4 vsphere-quickstart-md-0-57ff99b55-b55q8 NotReady <none> 4m53s v1.18.6+vmware.1 10.27.51.52 10.27.51.52 VMware Photon OS/Linux 4.19.132-1.ph3 containerd://1.3.4 vsphere-quickstart-md-0-57ff99b55-gn9pn NotReady <none> 4m57s v1.18.6+vmware.1 10.27.51.53 10.27.51.53 VMware Photon OS/Linux 4.19.132-1.ph3 containerd://1.3.4
4개의 노드가 있는 동안에는 위에서 강조 표시한 대로 모두 NotReady 상태입니다. 이는 CNI(컨테이너 네트워크 인터페이스)가 아직 구축되지 않았기 때문에 노드 간, 포드 간 통신이 아직 가능하지 않기 때문이다. 잘 알려진 CNI인 Calico를 선택하자. 빠른 시작 클러스터 kubec 구성을 참조하여 다음과 같이 배포할 수 있습니다.
$ kubectl apply -f https://docs.projectcalico.org/manifests/calico.yaml --kubeconfig quickstart-kubeconfig configmap/calico-config created customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created clusterrole.rbac.authorization.k8s.io/calico-node created clusterrolebinding.rbac.authorization.k8s.io/calico-node created daemonset.apps/calico-node created serviceaccount/calico-node created deployment.apps/calico-kube-controllers created serviceaccount/calico-kube-controllers created poddisruptionbudget.policy/calico-kube-controllers created
짧은 시간(나의 경우 1분 미만) 내에 노드가 Ready 상태로 전환되어야 합니다.
$ kubectl get nodes --kubeconfig quickstart-kubeconfig -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME vsphere-quickstart-d9cr2 Ready master 11m v1.18.6+vmware.1 10.27.51.50 10.27.51.50 VMware Photon OS/Linux 4.19.132-1.ph3 containerd://1.3.4 vsphere-quickstart-md-0-57ff99b55-8zk44 Ready <none> 8m40s v1.18.6+vmware.1 10.27.51.51 10.27.51.51 VMware Photon OS/Linux 4.19.132-1.ph3 containerd://1.3.4 vsphere-quickstart-md-0-57ff99b55-b55q8 Ready <none> 8m34s v1.18.6+vmware.1 10.27.51.52 10.27.51.52 VMware Photon OS/Linux 4.19.132-1.ph3 containerd://1.3.4 vsphere-quickstart-md-0-57ff99b55-gn9pn Ready <none> 8m38s v1.18.6+vmware.1 10.27.51.53 10.27.51.53 VMware Photon OS/Linux 4.19.132-1.ph3 containerd://1.3.4
클러스터 API를 사용하여 vSphere에 워크로드 클러스터를 구축했습니다. vSphere UI에서와 같은 모습입니다.
앞서 언급한 바와 같이, 필요한 환경 변수 목록을 포함하고, 이 GitHub repo에서 kind 클러스터를 관리 클러스터로 초기화한 다음 워크로드 클러스터를 배포하는 데 사용된 일부 스크립트를 찾을 수 있습니다.
Part 2: 클러스터 API 및 TKG
이 게시물의 마지막 부분에서는 TKG, Tanzu Kubernetes Grid 클러스터와 Cluster API를 사용하는 방법에 대해 알아보겠습니다. 이것은 TKG 독립형이며, 종종 TKG 멀티 클라우드 또는 줄여서 TKGm이라고 합니다. TKGi 즉 Integrated TKG(이전의 엔터프라이즈 PKS) 또는 vSphere with Tanzu의 TKG service(TKGs)를 통해 프로비저닝된 TKG와 TKG를 혼동하지 마십시오. 이 경우 TKG에는 관리 클러스터라는 개념도 있으며, 이 개념을 사용하여 하나 이상의 워크로드 클러스터를 생성할 수 있습니다.
가장 먼저 짚고 넘어가야 할 것은 TKG v1.3.x에 새로운 CLI가 생겼다는 점입니다. 새로운 CLI는 tanzu라고 불리는 반면, 이전 버전의 TKG(1.1, 1.2)에서는 tkg이라고 불렸다. TKG 설명서가 상당히 상세하기 때문에 나는 이 게시물에 있는 TKG의 배포 및 구성 단계를 모두 거치지 않을 것입니다. 대신 Cluster API가 어떻게 활용되는지 다시 한 번 보여드리고자 합니다. 새로운 Tanzu CLI에는 K8s 관리자가 관리 클러스터 및 워크로드 클러스터와 상호 작용할 수 있도록 지원하는 플러그인 세트가 함께 제공됩니다. 플러그인은 다음과 같이 표시할 수 있습니다.
$ tanzu plugin list NAME LATEST VERSION DESCRIPTION REPOSITORY VERSION STATUS alpha v1.3.1 Alpha CLI commands core not installed cluster v1.3.1 Kubernetes cluster operations core v1.3.1 installed kubernetes-release v1.3.1 Kubernetes release operations core v1.3.1 installed login v1.3.1 Login to the platform core v1.3.1 installed management-cluster v1.3.1 Kubernetes management cluster operations core v1.3.1 installed pinniped-auth v1.3.1 Pinniped authentication operations (usually not directly invoked) core v1.3.1 installed
이미 TKG 관리 클러스터와 워크로드 클러스터를 배포했습니다. TKG 관리 클러스터에 로그인하려면 먼저 tanzu 로그인 명령을 사용하여 로그인해야 합니다. tkgm이라는 단일 관리 클러스터만 있기 때문에 제공된 서버 목록에서 선택한 다음 Enter 키를 누릅니다.
$ tanzu login ? Select a server [Use arrows to move, type to filter] > tkgm () + new server <hit enter> $ tanzu login ? Select a server tkgm () ✔ successfully logged in to management cluster using the kubeconfig tkgm $
아시다시피 관리 클러스터가 여러 개 있는 경우 목록을 위아래로 이동하여 관리하려는 클러스터를 선택할 수 있습니다. 관리 클러스터를 선택하고 로그인했으므로 사용 가능한 클러스터를 쿼리할 수 있습니다. -include-management-cluster 옵션을 포함하면 관리 클러스터와 워크로드 클러스터를 모두 볼 수 있습니다. 그렇지 않으면 워크로드 클러스터만 나열됩니다.
$ tanzu cluster list --include-management-cluster NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN my-vsphere-tkc default running 3/3 3/3 v1.20.5+vmware.1 <none> prod tkgm tkg-system running 1/1 1/1 v1.20.5+vmware.1 management dev $ tanzu cluster list NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN my-vsphere-tkc default running 3/3 3/3 v1.20.5+vmware.1 <none> prod
list 옵션이 아닌 get 옵션을 사용하면 클러스터에 대한 추가 정보를 얻을 수 있습니다. 다음은 관리 클러스터 tkgm에서 get한 내용입니다. 앞서 파트 1에서 살펴본 클러스터 API 프로비저닝 클러스터와 몇 가지 유사점이 있습니다. 제공자 목록은 관리 클러스터의 클러스터 API, kubeadm 부트스트랩, kubeadm 제어부 및 vSphere 인프라 제공자를 보여 줍니다(앞에서 본 것과 동일).
$ tanzu management-cluster get
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES
tkgm tkg-system running 1/1 1/1 v1.20.5+vmware.1 management
Details:
NAME READY SEVERITY REASON SINCE MESSAGE
/tkgm True 26h
├─ClusterInfrastructure - VSphereCluster/tkgm True 26h
├─ControlPlane - KubeadmControlPlane/tkgm-control-plane True 26h
│ └─Machine/tkgm-control-plane-c8wwv True 26h
└─Workers
└─MachineDeployment/tkgm-md-0
└─Machine/tkgm-md-0-76b576db5c-86j2n True 26h
Providers:
NAMESPACE NAME TYPE PROVIDERNAME VERSION WATCHNAMESPACE
capi-kubeadm-bootstrap-system bootstrap-kubeadm BootstrapProvider kubeadm v0.3.14
capi-kubeadm-control-plane-system control-plane-kubeadm ControlPlaneProvider kubeadm v0.3.14
capi-system cluster-api CoreProvider cluster-api v0.3.14
capv-system infrastructure-vsphere InfrastructureProvider vsphere v0.7.7클러스터 API 개념에 설명된 클러스터 인프라, 시스템 배포 및 시스템과 같은 세부 정보 섹션에 표시되는 정보는 클러스터 API 개념에 설명되어 있지만 이러한 구성 요소가 기존 Kubernet 환경에서 새로운 Kuberntes 워크로드 클러스터 “objects”를 만들 수 있는 구성 요소라고 할 수 있습니다. 따라서 이 TKG 관리 클러스터를 사용하여 새로운 tanzu CLI를 사용하는 클러스터 API 메커니즘을 통해 TKG 워크로드 클러스터를 생성할 수 있습니다. 이 게시물이 Cluster API와 TKG에서 워크로드 클러스터를 생성하는 데 어떻게 사용되는지에 대한 통찰력을 제공하는 데 도움이 되었기를 바랍니다.
