이번 주에는 vSphere용 TKG v1.4.1의 새로운 기능에 대해 살펴봤지만 최근에 기능이 저하되었습니다. TKG v1.4.1 릴리스 노트에서 확인할 수 있습니다. 가장 주목할 만한 기능은 TKG v1.4.1이 이제 Tanzu Mission Control에서 지원되므로 이제 TMC에서 중앙에서 관리하는 Kubernetes 클러스터 제품군에 이 기능을 추가할 수 있습니다. 잠시 후 설명드릴 TMC에 TKG 관리 클러스터를 등록하는 방법과 관련하여 몇 가지 사항이 변경되었습니다. 또한 OIDC 및 LDAP과 통합되는 ID 관리 구성 요소(예: Pinniped 및 Dex)에는 NSX Advanced Load Balancer가 구성되어 vSphere 환경에서도 사용 가능한 경우)가 기본적으로 로드 밸런서 서비스가 할당된다는 점도 주목했습니다. TKG v1.4에서는 이러한 서비스를 NodePort에서 LoadBalancer로 변환하기 위해 몇 가지 추가 수동 구성을 건너뛰어야 했는데, 더 이상 이 작업을 수행할 필요가 없어 다행입니다. 이 두 가지 아이템을 좀 더 자세히 살펴보겠습니다.
Tanzu Mission Control 지원
UI를 통해 TKG v1.4.1 관리 클러스터를 설치할 경우 가장 먼저 TMC 등록 섹션이 없다는 것을 알 수 있습니다. 현재 TKG v1.4.1 설치 관리자 UI는 다음과 같습니다.
말했듯이, TKG v1.4.1은 이제 TMC에 추가될 수 있지만, TKG v1.4에서는 불가능합니다. TKG 관리 클러스터를 Tanzu Mission Control에 추가하려면 아래와 같이 TMC 포털로 이동하여, Administration 섹션에서 Management clusters 탭을 선택하고 Register Management Cluster 버튼을 클릭해야 합니다.
클러스터의 이름을 제공하고 필요한 경우 필요한 프록시 세부 정보를 추가한 후 TMC는 해당 클러스터를 TMC에 추가하는 데 필요한 TMC 구성 요소를 만드는 데 필요한 YAML 매니페스트를 제공합니다. 여기서와 같이 YAML 매니페스트의 내용도 볼 수 있습니다.
매니페스트를 복사한 다음 TKG V1.4.1 관리 클러스터 컨텍스트로 전환하고 kubectl을 통해 YAML 매니페스트를 TKG 관리 클러스터에 적용합니다.
% kubectl apply -f 'https://xxxxx.tmc.cloud.vmware.com/installer?id=3b49e3a047863f4xxx87f6f5943bbc48&source=registration&type=tkgm' namespace/vmware-system-tmc created configmap/stack-config created secret/tmc-access-secret created customresourcedefinition.apiextensions.k8s.io/agents.clusters.tmc.cloud.vmware.com created customresourcedefinition.apiextensions.k8s.io/extensionconfigs.intents.tmc.cloud.vmware.com created customresourcedefinition.apiextensions.k8s.io/extensionintegrations.clusters.tmc.cloud.vmware.com created customresourcedefinition.apiextensions.k8s.io/extensionresourceowners.clusters.tmc.cloud.vmware.com created customresourcedefinition.apiextensions.k8s.io/extensions.clusters.tmc.cloud.vmware.com created serviceaccount/extension-manager created clusterrole.rbac.authorization.k8s.io/extension-manager-role created clusterrolebinding.rbac.authorization.k8s.io/extension-manager-rolebinding created service/extension-manager-service created deployment.apps/extension-manager created serviceaccount/extension-updater-serviceaccount created Warning: policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+ podsecuritypolicy.policy/vmware-system-tmc-agent-restricted created clusterrole.rbac.authorization.k8s.io/extension-updater-clusterrole created clusterrole.rbac.authorization.k8s.io/vmware-system-tmc-psp-agent-restricted created clusterrolebinding.rbac.authorization.k8s.io/extension-updater-clusterrolebinding created clusterrolebinding.rbac.authorization.k8s.io/vmware-system-tmc-psp-agent-restricted created deployment.apps/extension-updater created serviceaccount/agent-updater created clusterrole.rbac.authorization.k8s.io/agent-updater-role created clusterrolebinding.rbac.authorization.k8s.io/agent-updater-rolebinding created deployment.apps/agent-updater created Warning: batch/v1beta1 CronJob is deprecated in v1.21+, unavailable in v1.25+; use batch/v1 CronJob cronjob.batch/agentupdater-workload created
모든 작업이 정상적으로 진행되면 TKG v1.4.1 관리 클러스터에 vmware-system-tmc 네임스페이스의 새 개체 무리가 생성되고 클러스터가 곧 TMC에 표시될 것입니다. 이미 존재하는 워크로드 클러스터는 아래와 같이 TMC에서도 관리할 수 있습니다. 물론 새로운 워크로드 클러스터도 TMC에서 직접 인스턴스화할 수 있습니다.
아이덴티티 관리
이에 대해서는 크게 언급할 것이 없습니다. 즉, 즉시 사용할 수 있습니다. 이전 TKG v1.4에서는 Pinniped 및 Dex 서비스를 NodePort에서 LoadBalancer로 변환하기 위해 ytt 오버레이를 생성하는 방법에 대해 게시했습니다. TKG v1.4.1에서는 더 이상 이 작업을 수행할 필요가 없습니다. 서비스가 LoadBalancer로 자동으로 구현되므로 깔끔합니다.
주의: vSphere Multi-Datacenter 구축
하지만 인벤토리에 여러 데이터 센터 개체가 있는 vSphere 환경에 TKG v1.4.1을 구축하는 데 어려움이 있었습니다. CAPV 컨트롤러에서 이 정보를 구문 분석하는 데 어려움이 있으며 데이터 센터 설정이 구성되지 않은 것으로 결론을 내립니다. 인벤토리에 여러 데이터 센터가 있다는 것을 알기 때문에 계속할 수 없습니다. 클러스터 제어부가 초기화되기를 기다리는 동안 부트스트랩/kind 클러스터 생성 “시간 초과”와 함께 실패합니다. 작성 당시 이 문제가 보고되어 조사 중입니다. 데이터 센터를 검색할 수 없는 CAPV 컨트롤러에 대한 로그 항목은 다음과 같이 결정할 수 있습니다. 먼저 docker ps를 사용하여 부트스트랩 클러스터 역할을 하는 kind 컨테이너의 이름을 찾은 후 다음 명령을 사용하여 로그를 표시하여 종류 클러스터의 이름과 capv 컨트롤러 관리자 포드 이름을 사용자 이름으로 바꿉니다.
% docker exec -it tkg-kind-c7e4237blargg0nnv10g-control-plane \ kubectl logs capv-controller-manager-6b84586c64-749vh -n capv-system manager
다음과 유사한 오류가 표시됩니다.
E0110 15:03:11.918610 1 controller.go:257] controller-runtime/controller \ "msg"="Reconciler error" "error"="unexpected error while probing vcenter for \ infrastructure.cluster.x-k8s.io/v1alpha3, Kind=VSphereCluster tkg-system/tkg141mgmt: \ unable to find datacenter \"\": default datacenter resolves to multiple instances, \ please specify" "controller"="vspherecluster" "name"="tkg141mgmt" "namespace"="tkg-system"
해결방법
공식적인 방법이 아니라는 점을 강조하지만, 아래와 같이 문제를 해결할 수 있었습니다. 이 접근 방식에는 몇 가지 단점이 있을 수 있지만 다중 데이터 센터 vSphere 환경에서 TKG v1.4.1 배포를 진행할 수 있습니다. 간단히 말해서 의심되는 CAPV 컨트롤러 이미지(v0.7.11)를 TKG v1.4.0에서 사용할 수 있는 작동 버전(v0.7.10)으로 교체합니다.
1 단계: kind에 편집기를 설치
kind 컨테이너에 편집기가 없어서 설치해야 합니다. vi를 설치하고 있습니다. 원한다면 nano와 같은 대체품을 설치할 수 있습니다.
% docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 3bcaff36587f projects.registry.vmware.com/tkg/kind/node:v1.21.2_vmware.1-v0.8.1 "/usr/local/bin/entr…" 6 seconds ago Up 1 second 127.0.0.1:60798->6443/tcp tkg-kind-c7g021vblarn8hbvdrs0-control-plane % docker exec -it 3bcaff36587f bash root@tkg-kind-c7g021vblarn8hbvdrs0-control-plane:/# which vi root@tkg-kind-c7g021vblarn8hbvdrs0-control-plane:/# apt-get update root@tkg-kind-c7g021vblarn8hbvdrs0-control-plane:/# apt-get install vim -y root@tkg-kind-c7g021vblarn8hbvdrs0-control-plane:/# which vi /usr/bin/vi
2 단계: capv-controller-manager 배포를 편집
이제 편집기를 사용할 수 있으므로 Next 구성을 필요에 따라 변경할 수 있습니다. capv-controller-manager 포드의 실행을 담당하는 배포를 식별합니다.
# kubectl get deploy -A NAMESPACE NAME READY UP-TO-DATE AVAILABLE AGE capi-kubeadm-bootstrap-system capi-kubeadm-bootstrap-controller-manager 0/1 1 0 13s capi-kubeadm-control-plane-system capi-kubeadm-control-plane-controller-manager 0/1 1 0 9s capi-system capi-controller-manager 0/1 1 0 16s capi-webhook-system capi-controller-manager 0/1 1 0 18s capi-webhook-system capi-kubeadm-bootstrap-controller-manager 0/1 1 0 15s capi-webhook-system capi-kubeadm-control-plane-controller-manager 0/1 1 0 11s capi-webhook-system capv-controller-manager 0/1 1 0 6s capv-system capv-controller-manager 0/1 1 0 4s cert-manager cert-manager 1/1 1 1 9m19s cert-manager cert-manager-cainjector 1/1 1 1 9m19s cert-manager cert-manager-webhook 1/1 1 1 9m18s kube-system coredns 2/2 2 2 10m local-path-storage local-path-provisioner 1/1 1 1 9m56s
다음 명령은 capv-controller-manager 배포에 대한 편집기를 엽니다. 여기서는 cluster-api-vsphere-controller 이미지의 버전을 버전 0.7.11에서 버전 0.7.10으로 변경해야 합니다. 읽기 쉽도록 매니페스트의 많은 부분을 제거했습니다.
# kubectl edit deploy capv-controller-manager -n capv-system
containers:
- args:
- --secure-listen-address=0.0.0.0:8443
- --upstream=http://127.0.0.1:8080/
- --logtostderr=true
- --v=10
image: projects.registry.vmware.com/tkg/cluster-api/kube-rbac-proxy:v0.8.0_vmware.1
imagePullPolicy: IfNotPresent
name: kube-rbac-proxy
ports:
- containerPort: 8443
name: https
protocol: TCP
resources: {}
terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
- args:
- --metrics-addr=127.0.0.1:8080
env:
- name: HTTP_PROXY
- name: HTTPS_PROXY
- name: NO_PROXY
image: projects.registry.vmware.com/tkg/cluster-api/cluster-api-vsphere-controller:v0.7.11_vmware.1
imagePullPolicy: IfNotPresent이제 이미지가 다음과 같이 표시됩니다.
image: projects.registry.vmware.com/tkg/cluster-api/cluster-api-vsphere-controller:v0.7.10_vmware.1
변경 사항을 매니페스트에 저장하기만 하면 새 CAPV 컨트롤러 포드가 자동으로 실행되며 이전 이미지를 사용하여 포드를 삭제합니다. 이제 kind/bootstrap 클러스터가 TKG 관리 클러스터 제어부 및 작업자 노드를 구성하는 가상 시스템을 배포할 수 있습니다.
3 단계: TKG 관리 클러스터에 대해 반복
이제 TKG 관리 클러스터 자체에서도 동일한 단계를 구현해야 하므로 아직 완료되지 않았습니다. TKG 관리 클러스터의 CAPV 컨트롤러 관리자에서 위의 단계를 반복하여 버전을 v0.7.11에서 v0.7.10으로 변경하면 TKG 관리 클러스터가 온라인 상태가 됩니다. 후속 TKG 워크로드 클러스터를 성공적으로 배포하는 데 필요한 단계는 없습니다. 그러나 TKG 관리 클러스터를 삭제하려면 삭제 작업을 위해 실행되는 kind/bootstrap 클러스터에서 이 단계를 반복해야 합니다. kind/bootstrap 클러스터만 변경하면 TKG 관리 클러스터를 제거할 수 있으므로 TKG 관리 클러스터에서 반복할 필요는 없습니다.
이제 VMware 기술 자료(KB) 문서 87396이 공개되어 TKG v1.4.1에서 이 문제를 해결하는 옵션에 대해 설명했습니다.
출처 : https://cormachogan.com/2022/01/14/tkg-v1-4-1-some-new-features/
