가장 최근에 올린 글에서 클러스터 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 구성은 매니페스트의 시작 부분에 있습니다.
Shell
x
AVI_CA_DATA_B64: LS0........AVI_CLOUD_NAME: Default-CloudAVI_CONTROLLER: 10.35.13.40AVI_DATA_NETWORK: VL3513-PRIV-DPGAVI_DATA_NETWORK_CIDR: 10.35.13.0/24AVI_ENABLE: "true"AVI_LABELS: ""AVI_PASSWORD: <encoded:Vk13YXJlMTIzIQ==>AVI_SERVICE_ENGINE_GROUP: Default-GroupAVI_USERNAME: adminCLUSTER_CIDR: 100.96.1.0/11CLUSTER_NAME: tkgm-lbCLUSTER_PLAN: devENABLE_CEIP_PARTICIPATION: "false"ENABLE_MHC: "true"IDENTITY_MANAGEMENT_TYPE: noneINFRASTRUCTURE_PROVIDER: vsphereLDAP_BIND_DN: ""LDAP_BIND_PASSWORD: ""LDAP_GROUP_SEARCH_BASE_DN: ""LDAP_GROUP_SEARCH_FILTER: ""LDAP_GROUP_SEARCH_GROUP_ATTRIBUTE: ""LDAP_GROUP_SEARCH_NAME_ATTRIBUTE: cnLDAP_GROUP_SEARCH_USER_ATTRIBUTE: DNLDAP_HOST: ""LDAP_ROOT_CA_DATA_B64: ""LDAP_USER_SEARCH_BASE_DN: ""LDAP_USER_SEARCH_FILTER: ""LDAP_USER_SEARCH_NAME_ATTRIBUTE: ""LDAP_USER_SEARCH_USERNAME: userPrincipalNameOIDC_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/13TKG_HTTP_PROXY_ENABLED: "false"VSPHERE_CONTROL_PLANE_DISK_GIB: "40"VSPHERE_CONTROL_PLANE_ENDPOINT: 10.35.13.240VSPHERE_CONTROL_PLANE_MEM_MIB: "8192"VSPHERE_CONTROL_PLANE_NUM_CPUS: "2"VSPHERE_DATACENTER: /CH-OCTO-DCVSPHERE_DATASTORE: /CH-OCTO-DC/datastore/vsanDatastoreVSPHERE_FOLDER: /CH-OCTO-DC/vm/TKGVSPHERE_NETWORK: VL3513-PRIV-DPGVSPHERE_PASSWORD: <encoded:QWRtaW4hMjM=>VSPHERE_RESOURCE_POOL: /CH-OCTO-DC/host/CH-Cluster/ResourcesVSPHERE_SERVER: 10.35.13.116VSPHERE_SSH_AUTHORIZED_KEY: ssh-rsa AAAA....== cormacVSPHERE_TLS_THUMBPRINT: 56:C1:C5:47:FF:00:C0:68:97:FF:A5:14:6B:0E:37:65:3C:CF:48:90VSPHERE_USERNAME: administrator@vsphere.localVSPHERE_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에서 실행되고 있으면 컨텍스트가 이 클러스터로 전환되고 해당 클러스터가 제거됩니다. 여기 전체 출력이 있습니다.
Shell
$ tanzu management-cluster create --file ./z2l657j5bm.yaml -v 6CEIP Opt-in status: falseValidating 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 whichturns a vSphere cluster into a platform for running Kubernetes workloads in dedicated resource pools. Configuring TanzuKubernetes 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 maydeploy 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]: NWould you like to deploy a non-integrated Tanzu Kubernetes Grid management cluster on vSphere 7.0? [y/N]: yDeploying 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 optionsSetting up management cluster...Validating configuration...Using infrastructure provider vsphere:v0.7.7Generating cluster configuration...Setting up bootstrapper...Fetching configuration for kind node image...kindConfig:kind: ClusterapiVersion: kind.x-k8s.io/v1alpha4kubeadmConfigPatches:- | 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.8nodes:- role: control-plane extraMounts: - hostPath: /var/run/docker.sock containerPath: /var/run/docker.sockcontainerdConfigPatches:- |- [plugins."io.containerd.grpc.v1.cri".registry.configs."cormac-tkgm.corinternal.com".tls] insecure_skip_verify = trueCreating kind cluster: tkg-kind-c33lkn8r994jb6dpv2p0Ensuring 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 locallyPreparing nodes ...Writing configuration ...Starting control-plane ...Installing CNI ...Installing StorageClass ...Waiting 2m0s for control-plane = Ready ...Ready after 35sBootstrapper created. Kubeconfig: /home/cormac/.kube-tkg/tmp/config_SxcKk9IaInstalling providers on bootstrapper...Fetching providersInstalling 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-vsphereWaiting for provider cluster-apiWaiting for provider control-plane-kubeadmWaiting for provider bootstrap-kubeadmWaiting for resource capi-kubeadm-control-plane-controller-manager of type *v1.Deployment to be up and runningpods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retryingWaiting for resource capv-controller-manager of type *v1.Deployment to be up and runningpods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retryingWaiting for resource capi-controller-manager of type *v1.Deployment to be up and runningWaiting for resource capi-kubeadm-bootstrap-controller-manager of type *v1.Deployment to be up and runningpods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retryingpods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingpods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retryingpods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retryingpods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingpods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retryingWaiting for resource capi-kubeadm-control-plane-controller-manager of type *v1.Deployment to be up and runningPassed waiting on provider control-plane-kubeadm after 10.14984304sWaiting for resource capv-controller-manager of type *v1.Deployment to be up and runningpods are not yet running for deployment 'capv-controller-manager' in namespace 'capi-webhook-system', retryingpods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingWaiting for resource capi-kubeadm-bootstrap-controller-manager of type *v1.Deployment to be up and runningpods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-webhook-system', retryingPassed waiting on provider infrastructure-vsphere after 15.238228291spods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingPassed waiting on provider bootstrap-kubeadm after 15.241068789sWaiting for resource capi-controller-manager of type *v1.Deployment to be up and runningPassed waiting on provider cluster-api after 20.256005572sSuccess 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, retryingcluster control plane is still being initialized, retryingcluster control plane is still being initialized, retryingcluster control plane is still being initialized, retryingcluster control plane is still being initialized, retryingGetting secret for clusterWaiting for resource tkgm-lb-kubeconfig of type *v1.Secret to be up and runningSaving management cluster kubeconfig into /home/cormac/.kube/configInstalling providers on management cluster...Fetching providersInstalling 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-vsphereWaiting for provider control-plane-kubeadmWaiting for provider cluster-apiWaiting for provider bootstrap-kubeadmWaiting for resource capi-kubeadm-control-plane-controller-manager of type *v1.Deployment to be up and runningWaiting for resource capv-controller-manager of type *v1.Deployment to be up and runningWaiting for resource capi-kubeadm-bootstrap-controller-manager of type *v1.Deployment to be up and runningpods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retryingpods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retryingpods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retryingWaiting for resource capi-controller-manager of type *v1.Deployment to be up and runningpods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingpods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retryingpods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retryingpods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retryingpods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingpods are not yet running for deployment 'capi-kubeadm-control-plane-controller-manager' in namespace 'capi-kubeadm-control-plane-system', retryingpods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retryingpods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retryingpods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingWaiting for resource capi-kubeadm-control-plane-controller-manager of type *v1.Deployment to be up and runningPassed waiting on provider control-plane-kubeadm after 15.104112709spods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retryingpods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retryingpods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingpods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retryingpods are not yet running for deployment 'capi-kubeadm-bootstrap-controller-manager' in namespace 'capi-kubeadm-bootstrap-system', retryingpods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingpods are not yet running for deployment 'capv-controller-manager' in namespace 'capv-system', retryingWaiting for resource capi-kubeadm-bootstrap-controller-manager of type *v1.Deployment to be up and runningPassed waiting on provider bootstrap-kubeadm after 25.113845112spods are not yet running for deployment 'capi-controller-manager' in namespace 'capi-system', retryingWaiting for resource capv-controller-manager of type *v1.Deployment to be up and runningPassed waiting on provider infrastructure-vsphere after 30.11258043sWaiting for resource capi-controller-manager of type *v1.Deployment to be up and runningPassed waiting on provider cluster-api after 30.152691662sSuccess 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 runningWaiting for resources type *v1alpha3.MachineDeploymentList to be up and runningWaiting for resources type *v1alpha3.MachineList to be up and runningWaiting for addons installation...Waiting for resources type *v1alpha3.ClusterResourceSetList to be up and runningWaiting for resource antrea-controller of type *v1.Deployment to be up and runningMoving all Cluster API objects from bootstrap cluster to management cluster...Performing move...Discovering Cluster API objectsMoving Cluster API objects Clusters=1Creating objects in the target clusterDeleting objects from the source clusterWaiting for additional components to be up and running...Waiting for resource tanzu-addons-controller-manager of type *v1.Deployment to be up and runningWaiting for resource tkr-controller-manager of type *v1.Deployment to be up and runningWaiting for resource kapp-controller of type *v1.Deployment to be up and runningpods are not yet running for deployment 'tanzu-addons-controller-manager' in namespace 'tkg-system', retryingpods are not yet running for deployment 'tanzu-addons-controller-manager' in namespace 'tkg-system', retryingContext set for management cluster tkgm-lb as 'tkgm-lb-admin@tkgm-lb'.Deleting kind cluster: tkg-kind-c33lkn8r994jb6dpv2p0Management 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 -ANAMESPACE NAME DESCRIPTION SINCE-DEPLOY AGEtkg-system antrea Reconcile succeeded 2m26s 2m28stkg-system metrics-server Reconcile succeeded 99s 2m29stkg-system tanzu-addons-manager Reconcile succeeded 2m28s 5m23stkg-system vsphere-cpi Reconcile succeeded 102s 2m28stkg-system vsphere-csi Reconcile succeeded 115s 2m28s이제 TKG 관리 클러스터가 가동되고 있으며 네트워킹용 Antrea 및 K8이 vSphere 스토리지를 사용할 수 있도록 vSphere CSI와 같은 모든 추가 기능이 있습니다. tanzu login 명령을 사용하여 이 관리 클러스터를 선택하고 로그인할 수 있습니다.
Shell
$ tanzu login? Select a server tkgm-lb ()
successfully logged in to management cluster using the kubeconfig tkgm-lbNSX ALB가 아직 VIP를 제공하도록 호출되지 않았습니다. 관리 클러스터용 VIP는 kube-vip에서 제공합니다. 이제 워크로드 클러스터 배포를 진행할 수 있습니다.
TKG 워크로드 클러스터
워크로드 클러스터를 배포하기 위해 다시 한 번 구성 파일을 생성합니다. 여기 제가 환경에서 사용하던 것이 있습니다. 샘플은 $HOME/.tanzu/tkg/clusterconfigs로 제공됩니다. 이 예에서 워크로드 클러스터는 인터넷에 액세스할 수 없는 공극 환경에서 배포됩니다. 따라서 모든 TKG 이미지는 구성 파일에서 TKG_CUSTOM_IMAGE_REPOSITORY에서 참조되는 로컬 하버 레지스트리에 있습니다.
Shell
$ cat tkgm-workload-lb.yaml##CLUSTER_NAME: tkgm-workload-lbCLUSTER_PLAN: prodCNI: antreaCONTROL_PLANE_MACHINE_COUNT: 1WORKER_MACHINE_COUNT: 2VSPHERE_CONTROL_PLANE_NUM_CPUS: 2VSPHERE_CONTROL_PLANE_DISK_GIB: 40VSPHERE_CONTROL_PLANE_MEM_MIB: 8192VSPHERE_WORKER_NUM_CPUS: 2VSPHERE_WORKER_DISK_GIB: 40VSPHERE_WORKER_MEM_MIB: 4096VSPHERE_NETWORK: VL3513-PRIV-DPGVSPHERE_DATACENTER: CH-OCTO-DCVSPHERE_RESOURCE_POOL: /CH-OCTO-DC/host/CH-Cluster/ResourcesVSPHERE_USERNAME: "administrator@vsphere.local"VSPHERE_PASSWORD: <encoded:QWRtaW4hMjM=>VSPHERE_SERVER: 10.35.13.116VSPHERE_DATASTORE: /CH-OCTO-DC/datastore/vsanDatastoreVSPHERE_FOLDER: /CH-OCTO-DC/vm/TKGVSPHERE_INSECURE: trueVSPHERE_SSH_AUTHORIZED_KEY: adfgsrhsrhVSPHERE_TLS_THUMBPRINT: 56:C1:C5:....VSPHERE_CONTROL_PLANE_ENDPOINT: 10.35.13.151TKG_CUSTOM_IMAGE_REPOSITORY: "http://cormac-tkgm.corinternal.com/library"TKG_CUSTOM_IMAGE_REPOSITORY_SKIP_TLS_VERIFY: trueENABLE_DEFAULT_STORAGE_CLASS: trueCLUSTER_CIDR: 100.96.3.0/11SERVICE_CIDR: 100.64.3.0/13이제 이 구성 파일을 적용하여 워크로드 클러스터를 구축할 수 있습니다. tanzu 명령을 사용하여 적용하면 제어부 노드 1개와 작업자 노드 2개를 포함하는 워크로드 클러스터를 생성할 수 있습니다. 구축이 완료되면 새 워크로드 클러스터 컨텍스트를 가져와 KUBECONFIG에 새 워크로드 클러스터 컨텍스트를 추가한 다음 해당 워크로드 컨텍스트를 전환합니다. 나는 이 출력물에 동사성을 첨가하지 않았다. Pinniped 구성은 OIDC 또는 LDAP ID 공급자가 구성되어 있지 않다는 경고 메시지가 표시됩니다. 따라서 관리 권한을 사용하여 워크로드 클러스터에 액세스해야 합니다. Pinniped 및 Dex를 사용한 OIDC 및 LDAP ID 관리는 TKGm v1.3의 또 다른 핵심 기능입니다.
Shell
$ tanzu cluster create --file ./tkgm-workload-lb.yamlValidating 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 manuallyCreating 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-contextsCURRENT 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-lbError: failed to get pinniped-info from management cluster: failed to get pinniped-info from the cluster... $ tanzu cluster kubeconfig get tkgm-workload-lb --adminCredentials of cluster 'tkgm-workload-lb' have been savedYou can now access the cluster by running 'kubectl config use-context tkgm-workload-lb-admin@tkgm-workload-lb'$ kubectl config get-contextsCURRENT 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-lbSwitched to context "tkgm-workload-lb-admin@tkgm-workload-lb".$ kubectl get nodesNAME STATUS ROLES AGE VERSIONtkgm-workload-lb-control-plane-smxtd Ready control-plane,master 4m58s v1.20.5+vmware.1tkgm-workload-lb-md-0-7986c58d4b-g92tl Ready <none> 3m29s v1.20.5+vmware.1tkgm-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개의 복제본과 연결된 로드 밸런서 서비스로 구성된 배포입니다.
Shell
$ cat nginx-from-harbor.yamlapiVersion: apps/v1kind: Deploymentmetadata: name: nginx-deployment labels: app: nginxspec: 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: v1kind: Servicemetadata: labels: app: nginx name: nginx-svcspec: type: LoadBalancer ports: - name: http port: 80 targetPort: 80 protocol: TCP selector: app: nginx이 애플리케이션을 적용할 때 NSX ALB에서 서비스에 할당되는 로드 밸런서 IP 주소/가상 IP(VIP)를 확인해야 합니다.
Shell
$ kubectl apply -f nginx-from-harbor.yamldeployment.apps/nginx-deployment createdservice/nginx-svc created$ kubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkubernetes ClusterIP 100.64.0.1 <none> 443/TCP 72mnginx-svc LoadBalancer 100.70.57.45 10.35.13.192 80:30922/TCP 4m26s$ ping 10.35.13.192PING 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 ms64 bytes from 10.35.13.192: icmp_seq=2 ttl=64 time=0.150 ms64 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 2032msrtt min/avg/max/mdev = 0.137/0.196/0.303/0.077 msNSX ALB에서 구성한 범위의 NSX ALB에서 VIP를 성공적으로 수신한 것으로 보입니다. 서비스가 ping 요청에 응답하기 전에 활성화될 때까지 잠시 기다려야 할 수 있습니다. 마지막 테스트는 http 포트 80의 Nginx 웹 서버 기본 랜딩 페이지에 도달할 수 있는지 확인하는 것입니다.
Shell
$ 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 andworking. 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에서 잘못된 구성 문제를 식별하는 데 매우 유용하다는 것을 알게 되었습니다.
Shell
$ kubectl logs ako-0 -n avi-system2021-06-14T13:58:21.274Z INFO api/api.go:52 Setting route for GET /api/status2021-06-14T13:58:21.274Z INFO ako-main/main.go:61 AKO is running with version: v1.3.12021-06-14T13:58:21.274Z INFO api/api.go:110 Starting API server at :80802021-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 scope2021-06-14T13:58:21.282Z INFO utils/utils.go:166 Initializing configmap informer in avi-system2021-06-14T13:58:21.282Z INFO lib/cni.go:96 Skipped initializing dynamic informers2021-06-14T13:58:21.472Z INFO utils/avi_rest_utils.go:99 Setting the client version to the current controller version 20.1.52021-06-14T13:58:21.492Z INFO cache/avi_ctrl_clients.go:72 Setting the client version to 20.1.52021-06-14T13:58:21.492Z INFO cache/avi_ctrl_clients.go:72 Setting the client version to 20.1.52021-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: POST2021-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: POST2021-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: POST2021-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.1922021-06-14T15:04:10.521Z WARN status/svc_status.go:37 Service hostname not found for service [default/nginx-svc] status update2021-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 주소)를 성공적으로 제공하고 있습니다.
