가장 최근에 올린 글에서 클러스터 API가 TKG에서 어떻게 활용되는지 살펴보았습니다. 이 게시물은 TKG(Tantsu Kubernetes Grid) 멀티 클라우드 버전을 참조하며, TKGm이라고도 합니다. TKG가 탄주 포트폴리오의 다른 TKG 제품과 차별화될 수 있도록 이 게시물에 있는 멀티 클라우드 TKG를 참조하기 위해 이 명명 규칙을 사용할 것입니다. 이 게시물에서는 TKG v1.3의 새로운 기능, 즉 이제 NSX ALB – Advanced Load Balancer(이전의 AVI Vantage)를 지원하여 로드 밸런서 서비스를 활용하는 애플리케이션에 가상 IP 주소를 제공한다는 사실에 대해 자세히 알아보겠습니다. NSX ALB를 vSphere와 Tanzu를 통합하는 방법에 대한 단계를 이미 문서화했습니다. TKGm용 NSX 고급 로드 밸런서의 설정은 매우 유사하지만 워크플로우는 약간 다릅니다. 이것은 이전에 배포된 버전 20.1.4와 비교하여 NSX ALB 버전 20.1.5의 새 설치 관리자 워크플로우입니다. TKG 관리 클러스터 설치 관리자 UI에는 NSX ALB와의 통합을 수용하는 몇 가지 추가 단계도 있습니다. 우리는 이 게시물에 있는 것들을 다룰 것이다.
시작하기 전에 TKGm이 Kube-VIP를 계속 사용하여 관리 클러스터 API 서버와 워크로드 클러스터 API 서버 모두에 프런트엔드 가상 IP 주소를 제공한다는 점을 강조해야 합니다. NSX ALB는 TKGM과 통합되면 로드 밸런서 서비스가 필요한 애플리케이션에 가상 IP 주소를 제공합니다. 따라서 관리 클러스터와 워크로드 클러스터의 구성 파일 모두에서 해당 클러스터의 vSphere IP 주소 끝점이 지정됩니다. 이러한 IP 주소는 정적 주소로 간주되며 DHCP IP 주소 범위를 벗어나야 합니다.
NSX ALB 배포
NSX ALB 배포는 vSphere with Tanzu 블로그 게시물에 이미 요약되어 있는 배포 단계와 대부분 동일합니다. 버전 20.1.5의 큰 차이점은 어플라이언스의 전원을 켜고 시스템 설정, Email/SMTP 및 Multi-tenant 구성을 처음 구성한 후 VMware vCenter/vSphere ESX의 설정 이후 단계로 바로 시작할 수 있다는 점입니다. 시작 UI 아래에 나와 있습니다.
NSX ALB를 구성하는 나머지 단계는 vCenter 및 vSphere 환경에 대한 세부 정보가 추가되고, 인증서가 생성되며, NSX ALB 서비스 엔진과 로드 밸런싱 VIP에 대한 네트워크 및 주소 범위가 선택되고, IPAM 프로필이 생성되는 등 앞에서 설명한 것과 동일합니다. 이 단계는 이미 사용 가능하므로 여기서는 반복하지 않습니다.
TKG 관리 클러스터
TKG 관리 클러스터의 배포는 Cluster API 블로그 게시물에서도 자세히 다루었습니다. 당사와 관련된 추가 항목이 하나 있으며, 이는 NSX ALB 섹션 포함입니다. TKG 관리 클러스터 생성 UI에서 이 새(선택 사항) NSX ALB 섹션은 다음과 같이 표시되며, 현재 부분적으로만 채워져 있습니다.
TKG 관리 클러스터를 생성하기 위한 결과 매니페스트 파일은 다음과 같이 보입니다. 이 파일은 TKGm UI 설치 프로그램이 실행되는 호스트의 $HOME/.tanzu/tkg/clusterconfigs 폴더에 생성됩니다. 이 설정에 구성된 LDAP 또는 OIDC가 없습니다. 대부분의 NSX ALB 구성은 매니페스트의 시작 부분에 있습니다.
AVI_CA_DATA_B64: LS0........ AVI_CLOUD_NAME: Default-Cloud AVI_CONTROLLER: 10.35.13.40 AVI_DATA_NETWORK: VL3513-PRIV-DPG AVI_DATA_NETWORK_CIDR: 10.35.13.0/24 AVI_ENABLE: "true" AVI_LABELS: "" AVI_PASSWORD: <encoded:Vk13YXJlMTIzIQ==> AVI_SERVICE_ENGINE_GROUP: Default-Group AVI_USERNAME: admin CLUSTER_CIDR: 100.96.1.0/11 CLUSTER_NAME: tkgm-lb CLUSTER_PLAN: dev ENABLE_CEIP_PARTICIPATION: "false" ENABLE_MHC: "true" IDENTITY_MANAGEMENT_TYPE: none INFRASTRUCTURE_PROVIDER: vsphere LDAP_BIND_DN: "" LDAP_BIND_PASSWORD: "" LDAP_GROUP_SEARCH_BASE_DN: "" LDAP_GROUP_SEARCH_FILTER: "" LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: "" LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cn LDAP_GROUP_SEARCH_USER_ATTRIBUTE: DN LDAP_HOST: "" LDAP_ROOT_CA_DATA_B64: "" LDAP_USER_SEARCH_BASE_DN: "" LDAP_USER_SEARCH_FILTER: "" LDAP_USER_SEARCH_NAME_ATTRIBUTE: "" LDAP_USER_SEARCH_USERNAME: userPrincipalName OIDC_IDENTITY_PROVIDER_CLIENT_ID: "" OIDC_IDENTITY_PROVIDER_CLIENT_SECRET: "" OIDC_IDENTITY_PROVIDER_GROUPS_CLAIM: "" OIDC_IDENTITY_PROVIDER_ISSUER_URL: "" OIDC_IDENTITY_PROVIDER_NAME: "" OIDC_IDENTITY_PROVIDER_SCOPES: "" OIDC_IDENTITY_PROVIDER_USERNAME_CLAIM: "" SERVICE_CIDR: 100.64.1.0/13 TKG_HTTP_PROXY_ENABLED: "false" VSPHERE_CONTROL_PLANE_DISK_GIB: "40" VSPHERE_CONTROL_PLANE_ENDPOINT: 10.35.13.240 VSPHERE_CONTROL_PLANE_MEM_MIB: "8192" VSPHERE_CONTROL_PLANE_NUM_CPUS: "2" VSPHERE_DATACENTER: /CH-OCTO-DC VSPHERE_DATASTORE: /CH-OCTO-DC/datastore/vsanDatastore VSPHERE_FOLDER: /CH-OCTO-DC/vm/TKG VSPHERE_NETWORK: VL3513-PRIV-DPG VSPHERE_PASSWORD: <encoded:QWRtaW4hMjM=> VSPHERE_RESOURCE_POOL: /CH-OCTO-DC/host/CH-Cluster/Resources VSPHERE_SERVER: 10.35.13.116 VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAA....== cormac VSPHERE_TLS_THUMBPRINT: 56:C1:C5:47:FF:00:C0:68:97:FF:A5:14:6B:0E:37:65:3C:CF:48:90 VSPHERE_USERNAME: administrator@vsphere.local VSPHERE_WORKER_DISK_GIB: "40" VSPHERE_WORKER_MEM_MIB: "8192" VSPHERE_WORKER_NUM_CPUS: "2"
tanzu management-cluster create 명령을 사용하면 위의 구성 파일을 사용하여 관리 클러스터를 원격 설치할 수 있습니다. 출력이 보다 상세하도록 -v 6 옵션을 포함했습니다. 설치 관리자가 vSphere 7을 감지하면 TKGm 대신 vSphere with Tanzu를 설정하는 옵션이 제공됩니다. TKGm 관리 클러스터 배포를 계속하려면 적절하게 대응해야 합니다. 이는 매우 작은 종류(Kubernetes in Docker) 클러스터를 생성하고, 클러스터 API 제공자 확장을 해당 클러스터에 추가한 다음, 이러한 제공자를 사용하여 vSphere에서 VM이 지원하는 TKG 관리 클러스터를 구축하는 일반적인 Cluster API 배포 모델을 거칩니다. 관리 클러스터가 VM에서 실행되고 있으면 컨텍스트가 이 클러스터로 전환되고 해당 클러스터가 제거됩니다. 여기 전체 출력이 있습니다.
$ tanzu management-cluster create --file ./z2l657j5bm.yaml -v 6
CEIP Opt-in status: false
Validating the pre-requisites...
vSphere 7.0 with Tanzu Detected.
You have connected to a vSphere 7.0 with Tanzu environment that includes an integrated Tanzu Kubernetes Grid Service which
turns a vSphere cluster into a platform for running Kubernetes workloads in dedicated resource pools. Configuring Tanzu
Kubernetes Grid Service is done through the vSphere HTML5 Client.
Tanzu Kubernetes Grid Service is the preferred way to consume Tanzu Kubernetes Grid in vSphere 7.0 environments. Alternatively you may
deploy a non-integrated Tanzu Kubernetes Grid instance on vSphere 7.0.
Note: To skip the prompts and directly deploy a non-integrated Tanzu Kubernetes Grid instance on vSphere 7.0, you can set the 'DEPLOY_TKG_ON_VSPHERE7' configuration variable to 'true'
Do you want to configure vSphere with Tanzu? [y/N]: N
Would you like to deploy a non-integrated Tanzu Kubernetes Grid management cluster on vSphere 7.0? [y/N]: y
Deploying TKG management cluster on vSphere 7.0 ...
Identity Provider not configured. Some authentication features won't work.
no os options provided, selecting based on default os options
Setting up management cluster...
Validating configuration...
Using infrastructure provider vsphere:v0.7.7
Generating cluster configuration...
Setting up bootstrapper...
Fetching configuration for kind node image...
kindConfig:
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
kubeadmConfigPatches:
- |
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
imageRepository: projects.registry.vmware.com/tkg
etcd:
local:
imageRepository: projects.registry.vmware.com/tkg
imageTag: v3.4.13_vmware.7
dns:
type: CoreDNS
imageRepository: projects.registry.vmware.com/tkg
imageTag: v1.7.0_vmware.8
nodes:
- role: control-plane
extraMounts:
- hostPath: /var/run/docker.sock
containerPath: /var/run/docker.sock
containerdConfigPatches:
- |-
[plugins."io.containerd.grpc.v1.cri".registry.configs."cormac-tkgm.corinternal.com".tls]
insecure_skip_verify = true
Creating kind cluster: tkg-kind-c33lkn8r994jb6dpv2p0
Ensuring node image (cormac-tkgm.corinternal.com/library/kind/node:v1.20.5_vmware.1) ...
Image: cormac-tkgm.corinternal.com/library/kind/node:v1.20.5_vmware.1 present locally
Preparing nodes ...
Writing configuration ...
Starting control-plane ...
Installing CNI ...
Installing StorageClass ...
Waiting 2m0s for control-plane = Ready ...
Ready after 35s
Bootstrapper created. Kubeconfig: /home/cormac/.kube-tkg/tmp/config_SxcKk9Ia
Installing providers on bootstrapper...
Fetching providers
Installing cert-manager Version="v0.16.1"
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v0.3.14" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-vsphere" Version="v0.7.7" TargetNamespace="capv-system"
installed Component=="cluster-api" Type=="CoreProvider" Version=="v0.3.14"
installed Component=="kubeadm" Type=="BootstrapProvider" Version=="v0.3.14"
installed Component=="kubeadm" Type=="ControlPlaneProvider" Version=="v0.3.14"
installed Component=="vsphere" Type=="InfrastructureProvider" Version=="v0.7.7"
Waiting for provider infrastructure-vsphere
Waiting for provider cluster-api
Waiting for provider control-plane-kubeadm
Waiting for provider bootstrap-kubeadm
Waiting for resource capi-kubeadm-control-plane-controller-manager of type *v1.Deployment to be up and running
pods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retrying
Waiting for resource capv-controller-manager of type *v1.Deployment to be up and running
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retrying
Waiting for resource capi-controller-manager of type *v1.Deployment to be up and running
Waiting for resource capi-kubeadm-bootstrap-controller-manager of type *v1.Deployment to be up and running
pods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retrying
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
pods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retrying
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retrying
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
pods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retrying
Waiting for resource capi-kubeadm-control-plane-controller-manager of type *v1.Deployment to be up and running
Passed waiting on provider control-plane-kubeadm after 10.14984304s
Waiting for resource capv-controller-manager of type *v1.Deployment to be up and running
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capi-webhook-system', retrying
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
Waiting for resource capi-kubeadm-bootstrap-controller-manager of type *v1.Deployment to be up and running
pods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-webhook-system', retrying
Passed waiting on provider infrastructure-vsphere after 15.238228291s
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
Passed waiting on provider bootstrap-kubeadm after 15.241068789s
Waiting for resource capi-controller-manager of type *v1.Deployment to be up and running
Passed waiting on provider cluster-api after 20.256005572s
Success waiting on all providers.
Start creating management cluster...
patch cluster object with operation status:
{
"metadata": {
"annotations": {
"TKGOperationInfo" : "{\"Operation\":\"Create\",\"OperationStartTimestamp\":\"2021-06-14 13:34:45.170398929 +0000 UTC\",\"OperationTimeout\":1800}",
"TKGOperationLastObservedTimestamp" : "2021-06-14 13:34:45.170398929 +0000 UTC"
}
}
}
cluster control plane is still being initialized, retrying
cluster control plane is still being initialized, retrying
cluster control plane is still being initialized, retrying
cluster control plane is still being initialized, retrying
cluster control plane is still being initialized, retrying
Getting secret for cluster
Waiting for resource tkgm-lb-kubeconfig of type *v1.Secret to be up and running
Saving management cluster kubeconfig into /home/cormac/.kube/config
Installing providers on management cluster...
Fetching providers
Installing cert-manager Version="v0.16.1"
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v0.3.14" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-vsphere" Version="v0.7.7" TargetNamespace="capv-system"
installed Component=="cluster-api" Type=="CoreProvider" Version=="v0.3.14"
installed Component=="kubeadm" Type=="BootstrapProvider" Version=="v0.3.14"
installed Component=="kubeadm" Type=="ControlPlaneProvider" Version=="v0.3.14"
installed Component=="vsphere" Type=="InfrastructureProvider" Version=="v0.7.7"
Waiting for provider infrastructure-vsphere
Waiting for provider control-plane-kubeadm
Waiting for provider cluster-api
Waiting for provider bootstrap-kubeadm
Waiting for resource capi-kubeadm-control-plane-controller-manager of type *v1.Deployment to be up and running
Waiting for resource capv-controller-manager of type *v1.Deployment to be up and running
Waiting for resource capi-kubeadm-bootstrap-controller-manager of type *v1.Deployment to be up and running
pods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retrying
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retrying
pods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retrying
Waiting for resource capi-controller-manager of type *v1.Deployment to be up and running
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
pods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retrying
pods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retrying
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retrying
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
pods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retrying
pods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retrying
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retrying
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
Waiting for resource capi-kubeadm-control-plane-controller-manager of type *v1.Deployment to be up and running
Passed waiting on provider control-plane-kubeadm after 15.104112709s
pods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retrying
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retrying
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retrying
pods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retrying
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
pods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retrying
Waiting for resource capi-kubeadm-bootstrap-controller-manager of type *v1.Deployment to be up and running
Passed waiting on provider bootstrap-kubeadm after 25.113845112s
pods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retrying
Waiting for resource capv-controller-manager of type *v1.Deployment to be up and running
Passed waiting on provider infrastructure-vsphere after 30.11258043s
Waiting for resource capi-controller-manager of type *v1.Deployment to be up and running
Passed waiting on provider cluster-api after 30.152691662s
Success waiting on all providers.
Waiting for the management cluster to get ready for move...
Waiting for resource tkgm-lb of type *v1alpha3.Cluster to be up and running
Waiting for resources type *v1alpha3.MachineDeploymentList to be up and running
Waiting for resources type *v1alpha3.MachineList to be up and running
Waiting for addons installation...
Waiting for resources type *v1alpha3.ClusterResourceSetList to be up and running
Waiting for resource antrea-controller of type *v1.Deployment to be up and running
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
Waiting for additional components to be up and running...
Waiting for resource tanzu-addons-controller-manager of type *v1.Deployment to be up and running
Waiting for resource tkr-controller-manager of type *v1.Deployment to be up and running
Waiting for resource kapp-controller of type *v1.Deployment to be up and running
pods are not yet running for deployment 'tanzu-addons-controller-manager' in namespace 'tkg-system', retrying
pods are not yet running for deployment 'tanzu-addons-controller-manager' in namespace 'tkg-system', retrying
Context set for management cluster tkgm-lb as 'tkgm-lb-admin@tkgm-lb'.
Deleting kind cluster: tkg-kind-c33lkn8r994jb6dpv2p0
Management cluster created!
You can now create your first workload cluster by running the following:
tanzu cluster create [name] -f [file]
Some addons might be getting installed! Check their status by running the following:
kubectl get apps -A
$ kubectl get apps -A
NAMESPACE NAME DESCRIPTION SINCE-DEPLOY AGE
tkg-system antrea Reconcile succeeded 2m26s 2m28s
tkg-system metrics-server Reconcile succeeded 99s 2m29s
tkg-system tanzu-addons-manager Reconcile succeeded 2m28s 5m23s
tkg-system vsphere-cpi Reconcile succeeded 102s 2m28s
tkg-system vsphere-csi Reconcile succeeded 115s 2m28s이제 TKG 관리 클러스터가 가동되고 있으며 네트워킹용 Antrea 및 K8이 vSphere 스토리지를 사용할 수 있도록 vSphere CSI와 같은 모든 추가 기능이 있습니다. tanzu login 명령을 사용하여 이 관리 클러스터를 선택하고 로그인할 수 있습니다.
$ tanzu login ? Select a server tkgm-lb () ✔ successfully logged in to management cluster using the kubeconfig tkgm-lb
NSX ALB가 아직 VIP를 제공하도록 호출되지 않았습니다. 관리 클러스터용 VIP는 kube-vip에서 제공합니다. 이제 워크로드 클러스터 배포를 진행할 수 있습니다.
TKG 워크로드 클러스터
워크로드 클러스터를 배포하기 위해 다시 한 번 구성 파일을 생성합니다. 여기 제가 환경에서 사용하던 것이 있습니다. 샘플은 $HOME/.tanzu/tkg/clusterconfigs로 제공됩니다. 이 예에서 워크로드 클러스터는 인터넷에 액세스할 수 없는 공극 환경에서 배포됩니다. 따라서 모든 TKG 이미지는 구성 파일에서 TKG_CUSTOM_IMAGE_REPOSITORY에서 참조되는 로컬 하버 레지스트리에 있습니다.
$ cat tkgm-workload-lb.yaml #! -- See https://docs.vmware.com/en/VMware-Tanzu-Kubernetes-Grid/1.3/vmware-tanzu-kubernetes-grid-13/GUID-tanzu-k8s-clusters-vsphere.html # #! --------------------------------------------------------------------- #! Basic cluster creation configuration #! --------------------------------------------------------------------- # CLUSTER_NAME: tkgm-workload-lb CLUSTER_PLAN: prod CNI: antrea #! --------------------------------------------------------------------- #! Node configuration #! --------------------------------------------------------------------- CONTROL_PLANE_MACHINE_COUNT: 1 WORKER_MACHINE_COUNT: 2 VSPHERE_CONTROL_PLANE_NUM_CPUS: 2 VSPHERE_CONTROL_PLANE_DISK_GIB: 40 VSPHERE_CONTROL_PLANE_MEM_MIB: 8192 VSPHERE_WORKER_NUM_CPUS: 2 VSPHERE_WORKER_DISK_GIB: 40 VSPHERE_WORKER_MEM_MIB: 4096 #! --------------------------------------------------------------------- #! vSphere configuration #! --------------------------------------------------------------------- VSPHERE_NETWORK: VL3513-PRIV-DPG VSPHERE_DATACENTER: CH-OCTO-DC VSPHERE_RESOURCE_POOL: /CH-OCTO-DC/host/CH-Cluster/Resources VSPHERE_USERNAME: "administrator@vsphere.local" VSPHERE_PASSWORD: <encoded:QWRtaW4hMjM=> VSPHERE_SERVER: 10.35.13.116 VSPHERE_DATASTORE: /CH-OCTO-DC/datastore/vsanDatastore VSPHERE_FOLDER: /CH-OCTO-DC/vm/TKG VSPHERE_INSECURE: true VSPHERE_SSH_AUTHORIZED_KEY: adfgsrhsrh VSPHERE_TLS_THUMBPRINT: 56:C1:C5:.... VSPHERE_CONTROL_PLANE_ENDPOINT: 10.35.13.151 #! --------------------------------------------------------------------- #! Common configuration #! --------------------------------------------------------------------- TKG_CUSTOM_IMAGE_REPOSITORY: "http://cormac-tkgm.corinternal.com/library" TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY: true ENABLE_DEFAULT_STORAGE_CLASS: true CLUSTER_CIDR: 100.96.3.0/11 SERVICE_CIDR: 100.64.3.0/13
이제 이 구성 파일을 적용하여 워크로드 클러스터를 구축할 수 있습니다. tanzu 명령을 사용하여 적용하면 제어부 노드 1개와 작업자 노드 2개를 포함하는 워크로드 클러스터를 생성할 수 있습니다. 구축이 완료되면 새 워크로드 클러스터 컨텍스트를 가져와 KUBECONFIG에 새 워크로드 클러스터 컨텍스트를 추가한 다음 해당 워크로드 컨텍스트를 전환합니다. 나는 이 출력물에 동사성을 첨가하지 않았다. Pinniped 구성은 OIDC 또는 LDAP ID 공급자가 구성되어 있지 않다는 경고 메시지가 표시됩니다. 따라서 관리 권한을 사용하여 워크로드 클러스터에 액세스해야 합니다. Pinniped 및 Dex를 사용한 OIDC 및 LDAP ID 관리는 TKGm v1.3의 또 다른 핵심 기능입니다.
$ tanzu cluster create --file ./tkgm-workload-lb.yaml
Validating configuration...
Warning: Pinniped configuration not found. Skipping pinniped configuration in workload cluster. Please refer to the documentation to check if you can configure pinniped on workload cluster manually
Creating workload cluster 'tkgm-workload-lb'...
Waiting for cluster to be initialized...
Waiting for cluster nodes to be available...
Waiting for addons installation...
Workload cluster 'tkgm-workload-lb' created
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* tkgm-lb-admin@tkgm-lb tkgm-lb tkgm-lb-admin
$ tanzu cluster list
NAME NAMESPACE STATUS CONTROLPLANE WORKERS KUBERNETES ROLES PLAN
tkgm-workload-lb default running 1/1 2/2 v1.20.5+vmware.1 <none> prod
$ tanzu cluster kubeconfig get tkgm-workload-lb
Error: failed to get pinniped-info from management cluster: failed to get pinniped-info from the cluster
...
$ tanzu cluster kubeconfig get tkgm-workload-lb --admin
Credentials of cluster 'tkgm-workload-lb' have been saved
You can now access the cluster by running 'kubectl config use-context tkgm-workload-lb-admin@tkgm-workload-lb'
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* tkgm-lb-admin@tkgm-lb tkgm-lb tkgm-lb-admin
tkgm-workload-lb-admin@tkgm-workload-lb tkgm-workload-lb tkgm-workload-lb-admin
$ kubectl config use-context tkgm-workload-lb-admin@tkgm-workload-lb
Switched to context "tkgm-workload-lb-admin@tkgm-workload-lb".
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
tkgm-workload-lb-control-plane-smxtd Ready control-plane,master 4m58s v1.20.5+vmware.1
tkgm-workload-lb-md-0-7986c58d4b-g92tl Ready <none> 3m29s v1.20.5+vmware.1
tkgm-workload-lb-md-0-7986c58d4b-zb58j Ready <none> 3m31s v1.20.5+vmware.1이제 워크로드 클러스터가 가동되어 실행되고 있지만 다시 한 번 VIP에 대해 NSX ALB를 사용하지 않았습니다. VIP(endpoint)가 구성 파일에 정의되어 있으며, 이를 워크로드 클러스터의 API 서버에 대한 프런트엔드 IP 주소로 구성하는 데 다시 한 번 Kube-VIP가 사용되었습니다. 이제 유형 로드 밸런서 서비스가 필요한 애플리케이션 배포를 진행하면 NSX ALB가 이 VIP를 제공하는 것을 볼 수 있습니다.
로드 밸런서 응용 프로그램
NSX ALB를 테스트하기 위해 Nginx Web Server 앱을 사용합니다. 여기 매니페스트가 있습니다. 3개의 복제본과 연결된 로드 밸런서 서비스로 구성된 배포입니다.
$ cat nginx-from-harbor.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
selector:
matchLabels:
app: nginx
replicas: 3 # tells deployment to run 3 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: cormac-tkgm.corinternal.com/library/nginx:latest
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
labels:
app: nginx
name: nginx-svc
spec:
type: LoadBalancer
ports:
- name: http
port: 80
targetPort: 80
protocol: TCP
selector:
app: nginx이 애플리케이션을 적용할 때 NSX ALB에서 서비스에 할당되는 로드 밸런서 IP 주소/가상 IP(VIP)를 확인해야 합니다.
$ kubectl apply -f nginx-from-harbor.yaml deployment.apps/nginx-deployment created service/nginx-svc created $ kubectl get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE kubernetes ClusterIP 100.64.0.1 <none> 443/TCP 72m nginx-svc LoadBalancer 100.70.57.45 10.35.13.192 80:30922/TCP 4m26s $ ping 10.35.13.192 PING 10.35.13.192 (10.35.13.192) 56(84) bytes of data. 64 bytes from 10.35.13.192: icmp_seq=1 ttl=64 time=0.303 ms 64 bytes from 10.35.13.192: icmp_seq=2 ttl=64 time=0.150 ms 64 bytes from 10.35.13.192: icmp_seq=3 ttl=64 time=0.137 ms ^C --- 10.35.13.192 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2032ms rtt min/avg/max/mdev = 0.137/0.196/0.303/0.077 ms
NSX ALB에서 구성한 범위의 NSX ALB에서 VIP를 성공적으로 수신한 것으로 보입니다. 서비스가 ping 요청에 응답하기 전에 활성화될 때까지 잠시 기다려야 할 수 있습니다. 마지막 테스트는 http 포트 80의 Nginx 웹 서버 기본 랜딩 페이지에 도달할 수 있는지 확인하는 것입니다.
$ curl 10.35.13.192
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>
<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>
<p><em>Thank you for using nginx.</em></p>
</body>
</html>성공! 현재 NSX ALB는 TKG 워크로드 클러스터에 로드 밸런서 서비스를 위한 VIP를 제공하고 있습니다.
TKGm에서 NSX ALB 문제 해결
NSX ALB와 TKG 간의 이러한 통합은 새로운 AKO 확장을 통해 제공됩니다. VIP 제공에 문제가 있을 경우 특별한 AKO 포드를 쿼리할 수 있습니다. 다음은 내 설정의 AKO 포드에서 가져온 로그 조각입니다. 이러한 로그는 NSX ALB에서 잘못된 구성 문제를 식별하는 데 매우 유용하다는 것을 알게 되었습니다.
$ kubectl logs ako-0 -n avi-system
2021-06-14T13:58:21.274Z INFO api/api.go:52 Setting route for GET /api/status
2021-06-14T13:58:21.274Z INFO ako-main/main.go:61 AKO is running with version: v1.3.1
2021-06-14T13:58:21.274Z INFO api/api.go:110 Starting API server at :8080
2021-06-14T13:58:21.274Z INFO ako-main/main.go:67 We are running inside kubernetes cluster. Won't use kubeconfig files.
2021-06-14T13:58:21.282Z INFO utils/ingress.go:36 networking.k8s.io/v1/IngressClass not found/enabled on cluster: ingressclasses.networking.k8s.io is forbidden: User "system:serviceaccount:avi-system:ako-sa" cannot list resource "ingressclasses" in API group "networking.k8s.io" at the cluster scope
2021-06-14T13:58:21.282Z INFO utils/utils.go:166 Initializing configmap informer in avi-system
2021-06-14T13:58:21.282Z INFO lib/cni.go:96 Skipped initializing dynamic informers
2021-06-14T13:58:21.472Z INFO utils/avi_rest_utils.go:99 Setting the client version to the current controller version 20.1.5
2021-06-14T13:58:21.492Z INFO cache/avi_ctrl_clients.go:72 Setting the client version to 20.1.5
2021-06-14T13:58:21.492Z INFO cache/avi_ctrl_clients.go:72 Setting the client version to 20.1.5
2021-06-14T13:58:21.560Z INFO cache/controller_obj_cache.go:2641 Setting cloud vType: CLOUD_VCENTER
.
.
.
2021-06-14T15:04:10.521Z INFO rest/dequeue_nodes.go:577 key: admin/default-tkgm-workload-lb--default-nginx-svc, msg: creating/updating Pool cache, method: POST
2021-06-14T15:04:10.521Z INFO rest/avi_obj_pool.go:267 key: admin/default-tkgm-workload-lb--default-nginx-svc, msg: Added Pool cache k {admin default-tkgm-workload-lb--default-nginx-svc--80} val {default-tkgm-workload-lb--default-nginx-svc--80 admin pool-ba01367d-ac34-4262-a0b8-0ffc3caea09f 146553777 {<nil> <nil> <nil> { } 0 } { } 1623683050279030 false false}
2021-06-14T15:04:10.521Z INFO rest/dequeue_nodes.go:577 key: admin/default-tkgm-workload-lb--default-nginx-svc, msg: creating/updating L4PolicySet cache, method: POST
2021-06-14T15:04:10.521Z INFO rest/avi_obj_l4ps.go:191 Modified the VS cache for l4s object. The cache now is :{"Name":"default-tkgm-workload-lb--default-nginx-svc","Tenant":"admin","Uuid":"","Vip":"","CloudConfigCksum":"","PGKeyCollection":null,"VSVipKeyCollection":[{"Namespace":"admin","Name":"default-tkgm-workload-lb--default-nginx-svc"}],"PoolKeyCollection":[{"Namespace":"admin","Name":"default-tkgm-workload-lb--default-nginx-svc--443"},{"Namespace":"admin","Name":"default-tkgm-workload-lb--default-nginx-svc--80"}],"DSKeyCollection":null,"HTTPKeyCollection":null,"SSLKeyCertCollection":null,"L4PolicyCollection":[{"Namespace":"admin","Name":"default-tkgm-workload-lb--default-nginx-svc"}],"SNIChildCollection":null,"ParentVSRef":{"Namespace":"","Name":""},"PassthroughParentRef":{"Namespace":"","Name":""},"PassthroughChildRef":{"Namespace":"","Name":""},"ServiceMetadataObj":{"namespace_ingress_name":null,"ingress_name":"","namespace":"","hostnames":null,"namespace_svc_name":null,"crd_status":{"type":"","value":"","status":""},"pool_ratio":0,"passthrough_parent_ref":"","passthrough_child_ref":"","gateway":""},"LastModified":"","InvalidData":false,"VSCacheLock":{}}
2021-06-14T15:04:10.521Z INFO rest/avi_obj_l4ps.go:200 Added L4 Policy Set cache k {admin default-tkgm-workload-lb--default-nginx-svc} val {default-tkgm-workload-lb--default-nginx-svc admin l4policyset-72c5338c-c68e-442e-9771-d5905a48aa1f 3045110946 [default-tkgm-workload-lb--default-nginx-svc--443 default-tkgm-workload-lb--default-nginx-svc--80] 1623683050397000 false}
2021-06-14T15:04:10.521Z INFO rest/dequeue_nodes.go:577 key: admin/default-tkgm-workload-lb--default-nginx-svc, msg: creating/updating VirtualService cache, method: POST
2021-06-14T15:04:10.521Z INFO rest/avi_obj_vs.go:374 key:admin/default-tkgm-workload-lb--default-nginx-svc, msg: Service Metadata: {"namespace_ingress_name":null,"ingress_name":"","namespace":"","hostnames":null,"namespace_svc_name":["default/nginx-svc"],"crd_status":{"type":"","value":"","status":""},"pool_ratio":0,"passthrough_parent_ref":"","passthrough_child_ref":"","gateway":""}
2021-06-14T15:04:10.521Z INFO rest/avi_obj_vs.go:396 key: admin/default-tkgm-workload-lb--default-nginx-svc, msg: updated vsvip to the cache: 10.35.13.192
2021-06-14T15:04:10.521Z WARN status/svc_status.go:37 Service hostname not found for service [default/nginx-svc] status update
2021-06-14T15:04:10.536Z INFO status/svc_status.go:83 key: admin/default-tkgm-workload-lb--default-nginx-svc, msg: Successfully updated the status of serviceLB: default/nginx-svc old: [] new [{IP:10.35.13.192 Hostname:}]
.
.
.물론 모든 작업이 예상대로 진행되었으면 vSphere UI에 배포되는 서비스 엔진을 관찰할 수 있어야 하며 NSX ALB 관리 포털에 로그인하면 가상 서비스가 표시되는 것을 볼 수 있습니다. 다음은 Applications > Dashboard에서 가져온 보기입니다.
Applications > Virtual Services 보기.
대시보드로 돌아가서 View VS List 대신 View VS Tree를 수행하고 + 기호를 클릭하여 확장하는 것이 좋습니다. 여기에는 서비스와 연결된 TKG 노드의 VS, 풀, 네트워크 및 IP 주소가 표시됩니다. 이 경우 Nginx 애플리케이션에는 3개의 복제본이 있으므로 3개의 다른 노드가 표시됩니다.
이제 TKG 워크로드 클러스터가 NSX 고급 로드 밸런서와 통합되어 로드 밸런서 서비스를 요청하는 내 TKG 클러스터의 애플리케이션에 VIP(가상 IP 주소)를 성공적으로 제공하고 있습니다.
