VMware는 최근에 vSphere 7.0U3c를 출시했습니다. vSphere with Tanzu 및 TKG Service가 여러 가지 개선되었습니다. 이러한 향상된 기능 중 일부는 새로운 v1alpha2 Tanzu Kubernetes Cluster 형식과 Namespace Service에 대한 새로운 기능과 같은 최신 게시물에 설명되어 있습니다. 이 글에서는 기본으로 돌아가서 vSphere with Tanzu 설치 및 설정 경험에 대한 몇 가지 변경 사항을 살펴보겠습니다. 네트워킹의 주요 개선 사항 중 하나는 Management 네트워크와 Workload 네트워크 모두에 대해 DHCP 지원이 추가된 것입니다. 관리 네트워크는 vSphere with Tanzu 제어부를 구성하는 Supervisor 노드가 연결되는 곳입니다. Supervisor 노드도 워크로드 네트워크에 연결되지만, 이 네트워크는 TKG 서비스를 통해 배포할 때 Tanzu Kubernetes 워크로드 클러스터의 제어부 및 작업자 노드가 연결되는 곳이기도 합니다.
vSphere 7.0U3c 릴리스에는 Supervisor Cluster의 Kubernetes v1.21 지원이 포함되어 있습니다. 또한 배포 후 vSphere 관리자가 특정 네트워크 설정의 구성을 편집할 수 있으며, 워크로드 네트워크의 경우 관리자가 서비스 IP 범위를 확장하고 새 워크로드 네트워크를 추가할 수 있습니다. 후자의 기능은 여러 번 요청했다고 들었습니다.
vSphere 클러스터 생성, vSAN 사용, 스토리지 정책 설정 또는 NSX ALB(Advanced Load Balancer) 배포 단계는 수행하지 않겠습니다. 이 사이트에는 각각의 독립적인 단계를 다루는 글이 있습니다. 이 글에서 NSX-T 네트워킹 스택이 아닌 NSX ALB와 vSphere Distributed Switch 네트워킹을 사용하겠지만 NSX-T는 다른 네트워킹 스택 옵션입니다.
vSphere UI에서 Workload Management를 선택하는 시점부터 시작하겠습니다. 이 페이지는 요구사항과 사전 요구 사항을 안내하는 랜딩 페이지입니다.
기본 vSphere 인프라(예: Distributed Switch, NSX ALB, vSphere 클러스터)가 이러한 요구 사항을 모두 충족한다고 가정합니다. “Get Started” 버튼을 클릭하면 아래와 같이 vCenter 서버와 네트워킹 스택을 선택할 수 있습니다.
앞서 언급했듯이 NSX-T를 사용하지 않습니다. 대신 vSphere Distributed Switch와 NSX ALB(이미 배포된 상태)를 사용하여 vSphere with Tanzu와 함께 로드 밸런싱 기능을 제공하겠습니다. UI 맨 위의 노란색 경고는 계속 진행하기 전에 이 로드 밸런서를 배포해야 함을 나타냅니다. 이것은 2번 중 1번 메시지입니다. 두 번째 메시지는 NSX-T를 사용할 수 없으며 vSphere Distributed Switch 네트워킹만 사용할 수 있다는 점을 강조합니다.
다음 단계로 이동하여 Supervisor Cluster를 배포할 vSphere 클러스터를 선택합니다. UI는 클러스터를 호환되거나 호환되지 않는 버킷에 배치합니다. 예를 들어 클러스터에 vSphere Distributed Switch가 구성되어 있지 않으면 클러스터가 호환되지 않을 수 있습니다. 다행히 아래와 같이 호환되는 vSphere 클러스터를 여러 개 선택할 수 있습니다. 세 개의 Supervisor 노드가 각각 다른 ESXi 호스트에 배치된 선택된 클러스터에 가상 시스템으로 배포됩니다. 따라서 vSphere 클러스터에서 계속하려면 최소 3개의 노드가 필요하지만 패치 적용 및 업그레이드 시 복원력을 위해 4개의 ESXi 호스트가 권장됩니다.
다음 단계에서는 Supervisor 노드에 대한 스토리지 정책을 선택합니다. vSAN을 사용하도록 설정했으므로 이 예에서는 기본 vSAN 스토리지 정책이 선택됩니다. 그러나 vSAN은 필수가 아니며 vSphere 클러스터의 다른 공유 스토리지를 선택하는 정책을 생성할 수 있습니다.
다음으로, Supervisor 클러스터에 로드 밸런서에 대해 알려야 합니다. NSX ALB의 경우 마법사에 이름, IP 주소 및 포트, 로그인 사용자 이름 및 암호, SSL 인증서가 필요합니다. SSL 인증서는 Templates > Security > SSL/TLS Certificates 아래에 있습니다. 이 인증서는 NSX ALB 설치의 일부로 생성되어야 합니다. 오른쪽 표지에 동그라미로 표시된 아래쪽 화살표 아이콘을 클릭하면 키와 인증서가 모두 표시된 창이 나타납니다. 인증서를 복사할 수 있는 옵션이 있습니다.
관련된 NSX-ALB 정보가 모두 채워지면 나머지 설치 작업을 계속할 수 있습니다. NSX ALB는 포트 443을 사용하는 반면 HA-Proxy는 포트 5556을 사용합니다. 문자열에 포트를 포함해야 합니다.
이제 DHCP를 사용하여 특정 네트워크의 IP 주소를 제공하는 새로운 기능 중 하나를 살펴보겠습니다. 첫 번째는 관리 네트워크입니다. DHCP를 선택하면 더 이상 Supervisor 노드의 IP 주소 범위를 제공하지 않아도 됩니다. 추가 설정은 vSphere Distributed Switch에서 분산 포트 그룹을 선택하는 것 뿐이며, 해당 네트워크에서 사용할 수 있는 DHCP 서비스가 있는지 확인하는 것입니다. 그 모양은 다음과 같습니다.
DHCP는 구성이 필요한 마지막 네트워크인 워크로드 네트워크에도 사용할 수 있습니다. 워크로드 네트워크는 Supervisor 노드(관리 네트워크와 워크로드 네트워크 모두에서 멀티홈 처리됨)와 Tanzu Kubernetes 클러스터의 제어부 및 작업자 노드에서 모두 사용됩니다. 그러나 이 예에서는 비교를 위해 정적 구성을 구현하려고 합니다. 나중에 이 기능을 수정 및 확장하는 방법과 설정이 완료된 후 추가된 새 워크로드 네트워크에 대해 알아보겠습니다. 중요: 이러한 배포의 일반적인 특징 중 하나는 워크로드 네트워크가 로드 밸런서 네트워크에 대한 경로가 있어야 한다는 것입니다. API 서버가 Supervisor 제어판에서 프런트 엔드 로드 밸런서 가상 IP 주소와 연결되면 각 제어부 노드의 워크로드 IP 주소에 연결할 수 있어야 합니다. 올바르게 구성되지 않으면 Supervisor 제어부가 온라인 상태가 되지 않습니다.
네트워크 설정이 완료되면 UI는 컨텐츠 라이브러리를 입력하라는 메시지를 표시합니다. 이곳은 Tanzu Kubernetes Release (TKr) 이미지가 저장되는 곳입니다. 이 컨텐츠 라이브러리는 업스트림 VMware 저장소와 동기화되어 TKC(Tanzu Kubernetes Cluster) 구축에 필요한 최신 이미지를 제공합니다. subscribed Content Library here를 작성하는 방법에 대한 자세한 내용은 여기를 참조하십시오. 이러한 TKr은 워크로드 클러스터 구축을 위한 YAML 매니페스트의 일부로 추가되며 DevOps는 배포하려는 다양한 K8s 버전을 선택할 수 있습니다. 제 예에 있는 컨텐츠 라이브러리는 쿠버네티스라고 불리지만 당신이 원하는 모든 것을 부를 수 있습니다.
이제 선택 사항인 API 서버 DNS 이름뿐만 아니라 슈퍼바이저 클러스터 제어부 노드 VM의 크기를 선택하는 최종 단계에 도달하겠습니다.
이제 “Finish”을 클릭하여 슈퍼바이저 클러스터를 배포할 수 있습니다. 그러면 Supervisor 제어부를 구성하는 세 개의 가상 시스템 배포가 시작됩니다.
Supervisor 클러스터 관찰
Supervisor 클러스터가 NSX ALB로 프로비저닝된 경우 VM이 처음에는 관리 네트워크에서 단일 NIC로 배포됩니다. 그러나 VM 중 하나는 부동 IP 주소인 두 번째 IP 주소를 받고 제어부에서 etcd 리더 역할을 합니다. 즉, 감독자 제어부 노드 중 하나에 장애가 발생하더라도 SV 클러스터의 vCenter와 etcd 간 연결은 모든 제어부 노드에서 호스팅할 수 있는 부동 IP를 통해 이루어지기 때문에 통신에 영향을 미치지 않습니다.
그런 다음 제어부 VM이 재구성되고 워크로드 네트워크에 연결된 두 번째 NIC가 추가됩니다. 따라서 수퍼바이저 클러스터 제어부 노드 중 하나는 5개의 IP 주소(IPv4 주소 3개 및 IPV6 주소 2개)로 네트워크 구성을 가져야 합니다. IPv4 주소는 관리 네트워크의 노드 주소 및 워크로드 네트워크의 etcd 리더 IP 주소입니다.
나머지 두 제어부 노드에는 2 x IPv4 및 2 x IPv6 등 4개의 IP 주소가 표시되어야 합니다. 유일한 차이점은 이러한 노드에는 etcd 리더 IP 주소가 없다는 것입니다.
워크로드 관리 보기로 이동한 후 감독자 클러스터 보기를 선택하더라도 여전히 “구성 중” 상태여야 합니다. 또한 etcd 리더 IP 주소와 일치하는 제어부 노드 주소가 있어야 하며 이는 NSX ALB에서 로드 밸런서 IP 주소를 아직 할당하지 않았음을 나타냅니다.
모든 작업이 정상적으로 진행되면 곧 제어부 노드 주소의 변경 사항이 나타나야 하며, 이번에는 설정 중에 NSX ALB에 구성된 VIP(가상 IP) 범위에서 NSX ALB에서 할당된 IP 주소가 됩니다.
Control Plane Node Address가 업데이트된 잠시 후 Config Status가 Configing에서 Running으로 변경되어야 합니다.
Namespaces로 이동하면 다음 성공 메시지와 네임스페이스 생성 기능이 표시됩니다.
Kubernetes CLI 도구
지금까지는 좋아요. 마지막 단계는 코맨드 라인에서 vSphere와 TKG 워크로드 클러스터를 생성하는 기능을 포함하여 사용자 및 DevOps 팀이 Tanzu와 상호 작용할 수 있도록 하는 Kubernetes CLI Tools를 다운로드하는 것입니다. 이전 배포의 CLI 도구 세트가 이미 있는 경우에도 항상 최신 도구를 다운로드하여 모든 기능을 제공해야 합니다. 도구를 다운로드하려면 브라우저에서 이전에 https://를 사용하여 본 Control Plane Node Address의 IP 주소를 가리키기만 하면 됩니다. 또는 vSphere UI에서 네임스페이스를 선택하고 요약 탭의 상태 창에서 아래와 같이 CLI 도구에 대한 링크를 사용할 수 있습니다.
Open을 클릭하면 다양한 도구 배포를 다운로드할 수 있는 랜딩 페이지가 표시됩니다.
도구(kubectl, kubectl-vsphere)가 다운로드되고 설치되면 이러한 도구를 사용하여 슈퍼바이저 클러스터와 상호 작용할 수 있습니다. 여기서 자세히 설명하지는 않겠지만 도움말 출력과 로그인 단계를 보여드리겠습니다.
% kubectl-vsphere login --server=https://xx.xx.62.18 \
--vsphere-username administrator@vsphere.local \
--insecure-skip-tls-verify -h
Authenticate user with vCenter Namespaces:
To access Kubernetes, you must first authenticate against vCenter Namespaces.
You must pass the address of the vCenter Namspaces server and the username of
the user to authenticate, and will be prompted to provide further credentials.
Usage:
kubectl-vsphere login [flags]
Examples:
kubectl vsphere login --vsphere-username user@domain --server=https://10.0.1.10
Flags:
-h, --help help for login
--insecure-skip-tls-verify Skip certificate verification (this is insecure).
--server string Address of the server to authenticate against.
--tanzu-kubernetes-cluster-name string Name of the Tanzu Kubernetes cluster to login to.
--tanzu-kubernetes-cluster-namespace string Namespace in which the Tanzu Kubernetes cluster resides.
-u, --vsphere-username string Username to authenticate.
Global Flags:
--request-timeout string Request timeout for HTTP client.
-v, --verbose int Print verbose logging information.
% kubectl-vsphere login --server=https://xx.xx.62.18 \
--vsphere-username administrator@vsphere.local \
--insecure-skip-tls-verify
Logged in successfully.
You have access to the following contexts:
xx.xx.62.18
If the context you wish to use is not in this list, you may need to try
logging in again later, or contact your cluster administrator.
To change context, use `kubectl config use-context <workload name>`
%
% kubectl get nodes
NAME STATUS ROLES AGE VERSION
4224646f6ea51802fa48461a93654e89 Ready control-plane,master 157m v1.21.0+vmware.wcp.2
422480e1218564cc78909921aff30361 Ready control-plane,master 157m v1.21.0+vmware.wcp.2
42249d40784ee8e471b38bc78c883fc8 Ready control-plane,master 162m v1.21.0+vmware.wcp.2이제 Namespace Service를 사용하여 네임스페이스를 생성하거나, VM service를 사용하여 VM을 구축하거나, TKG 서비스를 사용하여 Tanzu Kubernetes 워크로드 클러스터를 생성할 준비가 되었습니다.
마지막으로, 이와 유사한 서비스가 현재 VMware Cloud에서도 제공되고 있음을 말씀드리고 싶습니다. VMware 클라우드를 사용하면 vSphere 관리자가 기본 SDDC 인프라를 관리할 필요 없이 Tanzu Kubernetes 클러스터를 구축할 수 있습니다. 여기에서 Tanzu Services에 대해 자세히 읽어보십시오.
출처 : https://cormachogan.com/2022/02/08/vsphere-with-tanzu-revisited-in-vsphere-7-0u3c/
