TKG(Tanzu Kubernetes Grid) 클러스터는 Kubernetes 노드로 구성되고 클러스터에 가입된 가상 시스템 집합으로 구성됩니다. 이러한 클러스터를 만들고 원하는 상태 유지 보수에는 슈퍼바이저 클러스터에 배포된 Kubernetes 사용자 지정 리소스 및 컨트롤러 계층이 포함됩니다. 이 TKG 문제 해결 시리즈의 첫 번째 블로그/비디오는 TKC(Tanzu Kubernetes Cluster) 리소스 생성과 함께 Kubernetes 사용자 지정 리소스 및 Cluster API 오픈 소스 프로젝트에 대한 소개에 초점을 맞춥니다. 1부 블로그/비디오는 여기에서 확인할 수 있습니다. TKC 및 관련 TKG 컨트롤러는 TKG 클러스터를 조정하는 리소스 계층의 최상위 수준입니다. 이 파트 2 블로그/비디오에서는 TKC가 Cluster API를 구현하는 리소스 집합으로 분해되는 방법에 대해 살펴봅니다. 또한 Cluster API가 어떻게 구성되어 있는지 살펴봅니다. 리소스는 vSphere에서 VM을 생성하고 Kubernetes 클러스터를 구성하는 데 필요한 구성을 유지하는 가상 시스템 리소스로 추가로 조정됩니다. Part 2 비디오로 바로 이동하려면 여기를 클릭하십시오.
사용자 지정 리소스 및 컨트롤러 계층
단순화된 뷰는 TKG 컨트롤러에 의해 Tanzu Kubernetes Cluster(TKC) 리소스가 Cluster API 구현 리소스 또는 개체 집합으로 조정된다는 것입니다. TKG 컨트롤러는 vSphere 제공자별 가상 시스템 리소스도 생성합니다. 이러한 모든 리소스에 대한 조정 프로세스에는 상태를 모니터링하고 감시하는 특정 리소스 집합에 대한 적절한 구성 및 상태를 업데이트하는 컨트롤러 집합이 포함됩니다. 시리즈의 다음 비디오에서 문제 해결을 드릴다운하면 각 컨트롤러의 활동 로그가 있음을 알 수 있습니다. 개별 리소스에 발생하는 전환은 해당 리소스에 대해 설명하면 확인할 수 있습니다. 또한 우리는 하위 수준의 활동이 요약 양식의 상위 수준의 객체에 반영되는 패턴을 구현했습니다. 따라서 문제 해결은 TKC 리소스를 설명하고 잠재적으로 TKG 컨트롤러에 대한 로그를 보는 것으로 시작합니다.
TKG Controller에서 Cluster API 개체 생성
TKG는 TKC 리소스를 Cluster API 사용자 지정 리소스를 정의하는 yaml 규격 집합으로 조정합니다. 개체는 클러스터, 제어부 및 작업자로 논리적으로 그룹화됩니다. 또한 Cluster API는 특정 공급자 플랫폼(vSphere, Azure, AWS 등)과 독립적인 일반 규격을 vSphere 관련 구성과 구분합니다. 클러스터 개체에는 클러스터 자체의 정의가 포함되어 있으며 가상 시스템을 쿠버네티스 노드로 변환하기 위한 KubeAdm 코드와 vSphere 관련 구성을 포함하는 WCP 클러스터 및 KubeadmControlPlane 개체를 참조합니다. WCP 시스템 템플릿에는 제어부 노드가 될 기본 가상 시스템에 대한 정의가 포함되어 있습니다. WCP는 Workload Control Plane의 약자이며 Supervisor Cluster를 구현하는 vCenter 서비스의 엔지니어링 이름입니다. Spec보다 문제 해결 측면에서 더 흥미로운 점은 개체의 Status 섹션입니다. 클러스터는 ControlPlane 및 Infrastructure 가용성 상태를 보고하는 반면 WCP 클러스터는 인프라 가용성, 특히 네트워킹 및 로드 밸런싱에 초점을 맞춥니다. 따라서 TKC 리소스 수준 또는 클러스터 리소스 수준에서 인프라 오류가 발생한 경우 WCPCluster 리소스를 확인하여 자세한 내용을 확인할 수 있습니다.
Cluster
Status:
Conditions:
Last Transition Time: 2021-07-13T18:46:40Z
Status: True
Type: Ready
Last Transition Time: 2021-07-13T18:46:40Z
Status: True
Type: ControlPlaneReady
Last Transition Time: 2021-07-13T18:38:15Z
Status: True
Type: InfrastructureReady
Control Plane Initialized: true
Control Plane Ready: true
Infrastructure Ready: true
Observed Generation: 3
Phase: ProvisionedWCPCluster
Status:
Conditions:
Last Transition Time: 2021-07-13T18:38:14Z
Status: True
Type: Ready
Last Transition Time: 2021-07-13T18:38:06Z
Status: True
Type: ClusterNetworkReady
Last Transition Time: 2021-07-13T18:38:14Z
Status: True
Type: LoadBalancerReady
Last Transition Time: 2021-07-13T18:38:06Z
Status: True
Type: ResourcePolicyReady
Ready: true
Resource Policy Name: tkg-cluster제어부 개체는 클러스터를 구성하는 다음 단계의 세부 정보입니다. 각 제어부 노드는 Cluster API의 시스템입니다. 각 제어부 노드에 대해 일반 시스템 리소스와 WCP 시스템이라는 공급자별 시스템 리소스가 있습니다. 노드를 Kubernetes 클러스터로 설정하는 데 사용할 Kubeadm 구성의 추상화를 저장하는 KubeAdmConfig 리소스도 있습니다. 작업자 노드는 제어부 노드와 매우 유사한 프로세스로 구성됩니다.
kubectl describe machine “ControlPlaneNodeName” 명령을 실행하여 제어부 시스템의 상태를 확인합니다. 여기에서 인프라가 준비되었고 각 Kubernetes 구성 요소가 Healthy(컨트롤러 관리자, API, EtcD, 스케줄러 등)임을 확인할 수 있습니다. 인프라에 나타나는 오류는 해당 WCPMachine을 확인해야 합니다. WCPMachine 상태에는 가상 시스템의 VM IP 및 조건이 포함됩니다. 잠시 후 확인하겠지만, 이 정보는 가상 시스템의 진실 소스인 가상 시스템 리소스에서 이 리소스로 다시 반영되었습니다.
Control Plane Machine
Status:
Bootstrap Ready: true
Conditions:
Last Transition Time: 2021-07-13T18:45:12Z
Status: True
Type: Ready
Last Transition Time: 2021-07-13T18:56:53Z
Status: True
Type: APIServerPodHealthy
Last Transition Time: 2021-07-13T18:38:24Z
Status: True
Type: BootstrapReady
Last Transition Time: 2021-07-17T10:58:54Z
Status: True
Type: ControllerManagerPodHealthy
Last Transition Time: 2021-07-18T13:16:49Z
Status: True
Type: EtcdMemberHealthy
Last Transition Time: 2021-07-13T18:56:53Z
Status: True
Type: EtcdPodHealthy
Last Transition Time: 2021-07-13T18:56:50Z
Status: True
Type: HealthCheckSucceeded
Last Transition Time: 2021-07-13T18:45:12Z
Status: True
Type: InfrastructureReady
Last Transition Time: 2021-07-13T18:56:49Z
Status: True
Type: NodeHealthy
Last Transition Time: 2021-07-13T18:56:53Z
Status: True
Type: SchedulerPodHealthy
Infrastructure Ready: true
Last Updated: 2021-07-13T18:56:50Z
Node Ref:
API Version: v1
Kind: Node
Name: tkg-cluster-control-plane-xztwk
UID: 74b8ce8c-a282-4caf-9545-abd3696361ba
Observed Generation: 3
Phase: RunningControl Plane WCPMachine
Status:
Conditions:
Last Transition Time: 2021-07-13T18:45:12Z
Status: True
Type: Ready
Last Transition Time: 2021-07-13T18:45:12Z
Status: True
Type: VMProvisioned
Ready: true
Vm ID: 4214a174-360d-09f4-2672-6bf3bc323984
Vm Ip: 192.168.120.8
Vmstatus: ready시스템 개체가 준비되면 가상 시스템 사용자 지정 리소스가 생성되고 VMService(VM Operator Controller라고도 함)가 이러한 리소스를 vCenter에 대한 API 호출로 조정하여 실제 VM을 인스턴스화합니다. VM의 규격 및 상태를 유지하는 가상 시스템 리소스와 실제 vCenter에서 생성된 가상 시스템의 차이점에 주목하십시오.이는 Kubernetes 및 VM 서비스에 새로 들어온 사용자에게 혼란스러운 지점입니다.
VirtualMachine Status는 vSphere에 배포된 VM에 한정됩니다. kubectl describe vm “VMName”에는 VM이 배포된 호스트, 전원 상태, IP 주소 및 MOID(Managed Object Reference ID)와 같은 내용이 표시됩니다.
Virtual Machine
Status:
Bios UUID: 4214a174-360d-09f4-2672-6bf3bc323984
Change Block Tracking: false
Conditions:
Last Transition Time: 2021-07-13T18:48:59Z
Status: True
Type: Ready
Last Transition Time: 2021-07-13T18:38:26Z
Status: True
Type: VirtualMachinePrereqReady
Host: esx-02a.corp.local
Instance UUID: 50143365-56f2-636e-8207-40a932645926
Network Interfaces:
Connected: true
Ip Addresses:
192.168.120.8/24
fe80::250:56ff:fe94:a347/64
Mac Address: 00:50:56:94:a3:47
Connected: true
Ip Addresses:
fe80::748b:89ff:fee1:2fda/64
Mac Address: 76:8b:89:e1:2f:da
Connected: true
Ip Addresses:
fe80::fc5e:bff:feea:a037/64
Mac Address: fe:5e:0b:ea:a0:37
Connected: true
Ip Addresses:
fe80::3c67:bfff:fe47:8886/64
Mac Address: 3e:67:bf:47:88:86
Connected: true
Ip Addresses:
fe80::ece4:b8ff:fe48:5c32/64
Mac Address: ee:e4:b8:48:5c:32
Connected: true
Ip Addresses:
fe80::6cf6:88ff:fe55:62ed/64
Mac Address: 6e:f6:88:55:62:ed
Connected: true
Ip Addresses:
fe80::40f2:69ff:fe7a:6d51/64
Mac Address: 42:f2:69:7a:6d:51
Phase: Created
Power State: poweredOn
Unique ID: vm-5021
Vm Ip: 192.168.120.8Cluster API Controller
이 블로그는 각 사용자 지정 리소스의 조정을 감시하는 컨트롤러에 의해 조정되는 방법에 대한 자세한 설명이 아니라, 문제를 해결할 때 리소스의 계층 구조 및 스택 위아래 기본 탐색에 대한 통찰력을 제공하기 위한 목적으로 작성되었습니다.
TKC 리소스에 오류가 발생할 경우 적절한 하위 수준의 사용자 지정 리소스를 살펴보는 것이 근본 원인을 제공하는 경우가 많습니다. 그렇지 않은 경우도 있으며 리소스를 조정하는 컨트롤러에서 추가 조사를 수행해야 합니다. 이 정보는 kubectl logs “Controller Name” -n “Namespace Name” 명령을 통해 볼 수 있습니다. 이 경우 어떤 컨트롤러가 특정 리소스에 작용하는지 이해하는 것이 유용합니다. 이 컨트롤러 몇 개에 대해 자세히 알아보겠습니다. 대부분의 컨트롤러는 가용성을 높이기 위해 3개의 포드가 있는 ReplicaSet로 구현됩니다. 로그에서 여러 포드를 확인하여 어떤 포드가 리더이며 로그 정보를 쓰고 있는지 확인해야 할 수 있습니다.
CAPI(Cluster API Controller)가 WCP 특정 개체를 제외한 ClusterAPI 리소스를 조정합니다. 조정에는 개체의 상태 및 원하는 상태를 보장하고 다양한 개체 간에 적절한 정보를 반영하는 작업이 포함됩니다.
CAPW(Cluster API Controller for WCP)는 WCPMachine 리소스를 조정하고 VirtualMachine 리소스를 생성합니다. 또한 VirtualNetwork 리소스와 상호 작용하며 네트워킹 문제를 해결하는 시작점이 될 수 있습니다.
Virtual Machine Operator Controller는 vCenter에 대한 API 호출을 통해 VirtualMachine 리소스를 Virtual Machine으로 조정합니다. VMOperator는 VM의 기본 이미지가 들어 있는 VirtualMacineImage 리소스와 VM의 사용 가능한 리소스(vCPU, RAM 및 기타 GPU)를 정의하는 VirtualMachineClass를 사용합니다.
vmware-system-capw capi-controller-manager-644998658d-9mg7d 2/2 Running 2 5d19h vmware-system-capw capi-controller-manager-644998658d-ffgdt 2/2 Running 0 4d14h vmware-system-capw capi-controller-manager-644998658d-kxk6v 2/2 Running 3 5d19h vmware-system-capw capi-kubeadm-bootstrap-controller-manager-65b8d5c4dc-b9q76 2/2 Running 0 4d14h vmware-system-capw capi-kubeadm-bootstrap-controller-manager-65b8d5c4dc-rqbfg 2/2 Running 3 5d19h vmware-system-capw capi-kubeadm-bootstrap-controller-manager-65b8d5c4dc-vxv7m 2/2 Running 0 5d19h vmware-system-capw capi-kubeadm-control-plane-controller-manager-8565c86bbf-9ss6p 2/2 Running 3 5d19h vmware-system-capw capi-kubeadm-control-plane-controller-manager-8565c86bbf-c22jl 2/2 Running 0 4d14h vmware-system-capw capi-kubeadm-control-plane-controller-manager-8565c86bbf-dwhsc 2/2 Running 1 5d19h vmware-system-capw capw-controller-manager-58d769bd99-w2h7p 2/2 Running 2 5d19h vmware-system-capw capw-controller-manager-58d769bd99-w56hq 2/2 Running 0 4d14h vmware-system-capw capw-controller-manager-58d769bd99-z2rft 2/2 Running 3 5d19h vmware-system-vmop vmware-system-vmop-controller-manager-7578487c6f-85tkc 2/2 Running 1 5d19h vmware-system-vmop vmware-system-vmop-controller-manager-7578487c6f-pxd88 2/2 Running 6 5d19h vmware-system-vmop vmware-system-vmop-controller-manager-7578487c6f-wbth6 2/2 Running 0 4d14h
이 블로그의 목표는 Cluster API 및 vSphere with Tanzu 구현에 대한 전문가를 만드는 것이 아니라 맞춤형 리소스 구조에 대한 기본적인 이해를 촉진하는 것입니다. TKC(Tanzu Kubernetes Cluster)는 최고의 리소스입니다. Kubectl describe tkc “ClusterName”을 문제 해결 시작점으로 설명하고 클러스터의 상태를 알려줍니다. 오류 메시지가 표시되는 위치에 따라 WCPMachine 및 VirtualMachine 개체를 자세히 살펴봅니다. 이러한 구성 요소의 오류(또는 오류가 없는 경우)는 연결된 컨트롤러로 이동하여 로그에서 근본 원인을 확인하는 것을 의미합니다. 다음 동영상은 이 블로그의 일부 자료를 살펴보고 실제 환경의 리소스를 살펴봅니다. 이 시리즈의 비디오를 따라가면 일반적인 오류를 살펴보고 몇 가지 문제 해결 시나리오를 살펴볼 수 있습니다.
출처 : https://core.vmware.com/blog/tanzu-kubernetes-grid-service-troubleshooting-deep-dive-part-2
