이 항목에서는 Tanzu Kubernetes Grid 설치 관리자 인터페이스를 사용하여 vSphere with Tanzu Supervisor를 사용하도록 설정하지 않은 경우, AWS(Amazon Web Services) 및 Microsoft Azure에 vSphere 관리 클러스터를 배포하는 방법을 설명합니다. Tanzu Kubernetes Grid 설치 관리자 인터페이스는 관리 클러스터의 배포를 안내하며, 선택 또는 재구성할 수 있도록 다양한 구성을 제공합니다. 지정된 대상 플랫폼에 관리 클러스터를 배포하는 것이 이번이 처음인 경우 구성 파일에서 배포해야 한다고 명시된 경우를 제외하고 설치 프로그램 인터페이스를 사용하는 것이 좋습니다.
중요Tanzu Kubernetes Grid v2.4.x는 AWS 및 Azure에서 독립형 TKG 관리 클러스터 생성을 지원하는 TKG의 마지막 버전입니다. AWS 및 Azure에서 독립형 TKG 관리 클러스터를 생성하는 기능은 Tanzu Kubernetes Grid v2.5 릴리스에서 제거됩니다.
지금부터 VMware Tanzu Mission Control을 사용하여 AWS 및 Azure에서 새 독립형 TKG 관리 클러스터 또는 새 TKG 워크로드 클러스터를 생성하는 대신 네이티브 AWS EKS 및 Azure AKS 클러스터를 생성하는 것이 좋습니다. Tanzu Mission Control을 사용하여 네이티브 AWS EKS 및 Azure AKS 클러스터를 생성하는 방법에 대한 자세한 내용은 Tanzu Mission Control 설명서의 AWS EKS 클러스터의 수명 주기 관리 및 Azure AKS 클러스터의 수명 주기 관리를 참조하십시오.
자세한 내용은 VMware Tanzu Kubernetes Grid v2.4 Release Notes에서 AWS 및 Azure에서 TKG 관리 및 워크로드 클러스터의 사용 중단을 참조하십시오.
관리 클러스터를 배포하려면 먼저 환경이 대상 플랫폼에 대한 요구 사항을 충족하는지 확인해야 합니다.
프로덕션 배포의 경우 클러스터에 ID 관리를 사용하도록 설정하는 것이 좋습니다. 관리 클러스터를 배포하기 전에 수행할 준비 단계에 대한 자세한 내용은 구성 ID 관리의 ID 제공자 세부 정보를 참조하십시오.
인터넷이 제한된 환경에서 vSphere 또는 AWS에 클러스터를 배포하는 경우 인터넷 제한 환경 준비 단계도 수행해야 합니다. 이러한 단계에는 TKG_CUSTOM_IMAGE_REPOSITORY
를 환경 변수로 설정하는 것이 포함됩니다.
각 대상 플랫폼에는 관리 클러스터 배포를 위한 추가 사전 요구 사항이 있습니다.
참고vSphere 8의 vSphere with Tanzu에서는 관리 클러스터를 배포할 필요가 없습니다. vSphere with Tanzu Supervisor는 관리 클러스터입니다를 참조하십시오.
t3.large
또는 t3.xlarge
)에 대한 자세한 내용은 Amazon EC2 인스턴스 유형을 참조하십시오.Standard_D2s_v3
또는 Standard_D4s_v3
)에 대한 자세한 내용은 Azure의 가상 시스템 크기를 참조하십시오.기본적으로 Tanzu Kubernetes Grid는 ~/.kube-tkg/config
파일에 모든 관리 클러스터의 kubeconfig
를 저장합니다. 관리 클러스터의 kubeconfig
파일을 다른 위치에 저장하려면 tanzu mc create
를 실행하기 전에 KUBECONFIG
환경 변수를 설정합니다.
Tanzu CLI를 다운로드하고 설치한 시스템에서 --ui
옵션과 함께 tanzu mc create
명령을 실행합니다.
tanzu management-cluster create --ui
사전 요구 사항이 충족되면 설치 관리자 인터페이스가 브라우저에서 시작되고 관리 클러스터를 구성하는 단계를 안내합니다.
주의
tanzu mc create
명령을 완료하는 데 시간이 걸립니다.tanzu mc create
가 실행 중일 때는 동일한 부트스트랩 시스템에서tanzu mc create
의 추가 호출을 실행하여 여러 관리 클러스터를 배포하거나, 컨텍스트를 변경하거나,~/.kube-tkg/config
를 편집합니다.
아래의 설치 관리자 인터페이스 옵션 섹션에서는 Tanzu CLI의 다른 시스템에서 실행되는 것을 포함하여 설치 관리자 인터페이스가 실행되는 위치를 변경하는 방법을 설명합니다.
VMware vSphere, Amazon EC2 또는 Microsoft Azure의 배포 버튼을 클릭합니다.
기본적으로 tanzu mc create --ui
는 기본 브라우저의 http://127.0.0.1:8080에서 설치 관리자 인터페이스를 로컬로 엽니다. --browser
및 --bind
옵션을 사용하여 설치 관리자 인터페이스가 실행되는 위치를 제어할 수 있습니다.
--browser
는 인터페이스를 열 로컬 브라우저를 지정합니다.
chrome
, firefox
, safari
, ie
, edge
또는 none
입니다.--bind
와 함께 none
을 사용하여 다른 시스템에서 인터페이스를 실행합니다.--bind
는 인터페이스를 제공할 IP 주소와 포트를 지정합니다.
주의기본값이 아닌 IP 주소와 포트에서 설치 관리자 인터페이스를 작동하면 인터페이스가 실행되는 동안 Tanzu CLI가 잠재적인 보안 위험에 노출될 수 있습니다. VMware는 보안 네트워크의 IP와 포트를
–bind
옵션으로 전달하는 것을 권장합니다.
--browser
및 --bind
의 사용 사례에는 다음이 포함됩니다.
http://127.0.0.1:8080
을 사용하는 경우 --bind
를 사용하여 다른 로컬 포트의 인터페이스를 제공합니다.--browser none
을 사용해야 할 수 있습니다.Tanzu CLI를 실행하고 원격 시스템에서 관리 클러스터를 생성하고 로컬 또는 다른 곳에서 설치 관리자 인터페이스를 실행하려면 다음을 수행합니다.
원격 부트스트랩 시스템에서 다음 옵션 및 값으로 tanzu mc create --ui
를 실행합니다.
--bind
: 원격 시스템의 IP 주소 및 포트--browser
: none
tanzu mc create --ui --bind 192.168.1.87:5555 --browser none
로컬 UI 시스템에서 원격 시스템의 IP 주소를 찾아 설치 관리자 인터페이스에 액세스합니다.
대상 플랫폼을 구성하는 옵션은 사용 중인 제공자에 따라 다릅니다.
IaaS 제공자 섹션에서 관리 클러스터를 배포할 vCenter Server 인스턴스의 IP 주소 또는 FQDN(정규화된 도메인 이름)을 입력합니다.
Tanzu Kubernetes Grid에서 IPv6 주소에 대한 지원은 제한됩니다. APv6의 클러스터 배포(vSphere 전용)를 참조하십시오. IPv6 전용 네트워킹 환경에 배포하지 않는 경우 다음 단계에서 IPv4 주소를 입력해야 합니다.
Tanzu Kubernetes Grid 작업에 필요한 권한이 있는 사용자 계정의 vCenter Single Sign-On 사용자 이름과 암호를 입력합니다.
계정 이름에는 도메인(예: [email protected]
)이 포함되어야 합니다.
(선택 사항) SSL 지문 확인에서 확인 사용 안 함을 선택합니다. 이 확인란을 선택하면 설치 관리자가 vCenter Server에 연결할 때 인증서 지문 확인을 우회합니다.
연결을 클릭합니다.
vCenter Server 인증서의 SSL 지문을 확인하고 유효한 경우 계속을 클릭합니다. 이 화면은 위의 확인 사용 안 함 확인란이 선택 취소된 경우에만 나타납니다.
vCenter Server 인증서 지문을 가져오는 방법에 대한 자세한 내용은 vSphere 인증서 지문 가져오기를 참조하십시오.
관리 클러스터를 vSphere 7 또는 vSphere 8 인스턴스에 배포하는 경우 배포를 계속할지 여부를 확인합니다.
vSphere 7 및 vSphere 9에서 vSphere with Tanzu는 관리 클러스터로 작동하고 독립형 관리 클러스터보다 더 뛰어난 환경을 제공하는 기본 제공 Supervisor를 제공합니다. Supervisor가 없는 경우 Tanzu Kubernetes Grid 관리 클러스터를 vSphere 7 또는 vSphere 8로 배포하는 것은 지원되지만 기본 옵션은 vSphere with Tanzu를 사용하도록 설정하고 가능하면 Supervisor를 사용하는 것입니다. VMware Solution은 Supervisor 클러스터를 지원하지 않기 때문에 관리 클러스터를 배포해야 합니다.
자세한 내용은 Tanzu CLI를 사용하여 TKG 2.4 워크로드 클러스터 생성 및 관리의 vSphere with Tanzu Supervisor는 관리 클러스터입니다를 참조하십시오.
vSphere with Tanzu 사용하도록 설정된 경우 설치 관리자 인터페이스는 TKG 서비스를 Kubernetes 워크로드를 실행하는 기본 방법으로 사용할 수 있다고 명시하고 있으며, 이 경우 독립형 관리 클러스터가 필요하지 않습니다. 선택을 제공합니다.
구성 vSphere with Tanzu은 vSphere 8 설명서의 Supervisor 구성 및 관리에 설명된 대로 Supervisor를 구성할 수 있도록 vSphere Client를 엽니다.
TKG 관리 클러스터 배포를 사용하면 vSphere 7 또는 vSphere 8에 독립형 관리 클러스터를, Azure VMware Solution에 필요한 독립형 관리 클러스터를 계속 배포할 수 있습니다.
데이터센터 드롭다운 메뉴에서 관리 클러스터를 배포할 데이터 센터를 선택합니다.
SSH 공용 키를 추가합니다. SSH 공용 키를 추가하려면 파일 찾아보기 옵션을 사용하거나 키의 컨텐츠를 텍스트 상자에 수동으로 붙여 넣습니다. 다음을 클릭합니다.
IaaS 제공자 섹션에서 AWS 계정의 자격 증명을 입력하는 방법을 선택합니다. 다음 두 가지 옵션 중에서 선택할 수 있습니다.
자격 증명 프로필(권장): 이미 존재하는 AWS 자격 증명 프로필을 선택합니다. 프로필을 선택하면 프로필에 구성된 액세스 키와 세션 토큰 정보가 UI에 실제 값을 표시하지 않고 설치 관리자로 전달됩니다. 자격 증명 프로필 설정에 대한 자세한 내용은 자격 증명 파일 및 프로필을 참조하십시오.
일회성 자격 증명 AWS 계정의 액세스 키 ID 및 암호 액세스 키 필드에 AWS 계정 자격 증명을 직접 입력합니다. 또는 AWS 계정에 임시 자격 증명이 필요하도록 구성된 경우 세션 토큰에 AWS 세션 토큰을 지정합니다. 세션 토큰 획득에 대한 자세한 내용은 AWS 리소스에 임시 자격 증명 사용을 참조하십시오.
지역에서 관리 클러스터를 배포할 AWS 지역을 선택합니다.
프로덕션 관리 클러스터를 배포하려는 경우 이 지역에는 3개 이상의 가용성 영역이 있어야 합니다.
AWS용 VPC(VPC for AWS) 섹션의 드롭다운 메뉴에서 VPC ID를 선택합니다. VPC를 선택하면 VPC CIDR 블록이 자동으로 채워집니다. 프록시 또는 에어갭 환경과 같이 인터넷이 제한된 환경에서 관리 클러스터를 배포하는 경우 인터넷 연결 VPC가 아닙니다 확인란을 선택합니다.
중요새 버전의 Tanzu Kubernetes Grid(예: v2.4)를 사용하여 관리 클러스터를 Azure에 처음 배포하는 경우, 해당 버전의 기본 이미지 라이센스를 수락했는지 확인합니다. 자세한 내용은 Microsoft Azure에 관리 클러스터 배포 준비의 기본 이미지 라이센스 수락을 참조하십시오.
IaaS 제공자 섹션에서 Azure 계정의 테넌트 ID, 클라이언트 ID, 클라이언트 암호, 구독 ID 값을 입력합니다. Azure 애플리케이션을 등록하고 Azure Portal을 사용하여 암호를 생성할 때 이러한 값을 기록했습니다.
AZURE_ENVIRONMENT
를 설정하여 다른 환경을 지정할 수 있습니다.SSH 공용 키의 컨텐츠(예: .ssh/id_rsa.pub
)를 텍스트 상자에 붙여 넣습니다.
리소스 그룹에서 기존 리소스 그룹 선택 또는 새 리소스 그룹 생성 라디오 버튼을 선택합니다.
기존 리소스 그룹 선택을 선택하는 경우 드롭다운 메뉴를 사용하여 그룹을 선택한 후 다음을 클릭합니다.
새 리소스 그룹 생성을 선택하는 경우 새 리소스 그룹의 이름을 입력한 후 다음을 클릭합니다.
Azure용 VNet 섹션에서 Azure에서 새 VNet 생성 또는 기존 VNet 선택 라디오 버튼을 선택합니다.
Azure에서 새 VNet 생성을 선택하는 경우 드롭다운 메뉴를 사용하여 VNet을 생성할 리소스 그룹을 선택하고 다음을 입력합니다.
10.0.0.0/16
입니다.10.0.0.0/24
입니다.10.0.1.0/24
입니다.이러한 필드를 구성한 후 다음을 클릭합니다.
기존 VNet 선택을 선택하는 경우 드롭다운 메뉴를 사용하여 VNet이 있는 리소스 그룹, VNet 이름, 제어부, Worker 노드 서브넷을 선택한 후 다음을 클릭합니다.
Azure 개인 클러스터에 설명된 대로 관리 클러스터를 개인으로 설정하려면 개인 Azure 클러스터 확인란을 선택합니다.
관리 클러스터를 구성하는 옵션 중 일부는 사용 중인 제공자에 따라 다릅니다.
관리 클러스터 설정 섹션에서 개발 또는 프로덕션 타일을 선택합니다.
개발 또는 프로덕션 타일 중 하나에서 선택 유형 드롭다운 메뉴를 사용하여 제어부 노드 VM 또는 VM에 대해 다양한 CPU, RAM, 스토리지 조합 중에서 선택합니다.
실행될 예상 워크로드에 따라 제어부 노드 VM에 대한 구성을 선택합니다. 예를 들어 일부 워크로드에는 큰 계산 용량이 필요하지만 스토리지가 상대적으로 적은 워크로드도 있고, 대용량의 스토리지와 더 적은 계산 용량이 필요할 수 있습니다. 프로덕션 타일에서 인스턴스 유형을 선택하면 선택한 인스턴스 유형이 Worker 노드 인스턴스 유형으로 자동 선택됩니다. 필요한 경우 이를 변경할 수 있습니다.
Tanzu Mission Control에 관리 클러스터를 등록하려는 경우 워크로드 클러스터가 Tanzu Mission Control 설명서의 Tanzu Mission Control에 Tanzu Kubernetes 클러스터를 등록하는 요구 사항에 있는 요구 사항을 충족하는지 확인합니다.
필요한 경우 관리 클러스터의 이름을 입력합니다.
이름을 지정하지 않으면 Tanzu Kubernetes Grid가 고유한 이름을 자동으로 생성합니다. 이름을 지정하는 경우 해당 이름은 숫자 문자가 아닌 문자로 끝나야 하며 RFC 952에 설명되어 있고 RFC 1123에 수정된 대로 DNS 호스트 이름 요구 사항을 준수해야 합니다.
(선택 사항) MachineHealthCheck
를 활성화하려면 시스템 상태 점검(Machine Health Checks) 확인란을 선택합니다. CLI를 사용하여 배포 후 클러스터에서 MachineHealthCheck
를 활성화하거나 비활성화할 수 있습니다. 지침은 로드 클러스터의 시스템 상태 점검 구성을 참조하십시오.
(선택 사항) 감사 로깅 사용 확인란을 선택하여 Kubernetes API 서버에 대한 요청을 기록합니다. 자세한 내용은 감사 로깅을 참조하십시오.
대상 플랫폼과 관련된 추가 설정을 구성합니다.
제어부 끝점 제공자에서 Kube-Vip 또는 NSX Advanced Load Balancer를 선택하여 제어부 API 서버에 사용할 구성 요소를 선택합니다.
NSX Advanced Load Balancer를 사용하려면 먼저 vSphere 환경에 배포해야 합니다. 자세한 내용은 NSX Advanced Load Balancer 설치를 참조하십시오. NSX Advanced Load Balancer를 제어부 끝점 제공자로 사용하는 장점에 대한 자세한 내용은 NSX Advanced Load Balancer 구성을 참조하십시오.
제어부 끝점에서 관리 클러스터에 대한 API 요청의 고정 가상 IP 주소 또는 FQDN을 입력합니다. 이 설정은 Kube-Vip를 사용하는 경우에 필요합니다.
이 IP 주소가 DHCP 범위에 있지 않지만 DHCP 범위와 동일한 서브넷에 있는지 확인합니다. FQDN을 VIP 주소에 매핑한 경우 VIP 주소 대신 FQDN을 지정할 수 있습니다. 자세한 내용은 vSphere용 정적 VIP 및 로드 밸런서를 참조하십시오.
NSX Advanced Load Balancer를 제어부 끝점 제공자로 사용하는 경우 VIP가 NSX Advanced Load Balancer 고정 IP 풀에서 자동으로 할당됩니다.
EC2 키 쌍에서 AWS 계정 및 관리 클러스터를 배포하는 지역에 이미 등록된 AWS 키 쌍의 이름을 지정합니다. AWS 계정 자격 증명 및 SSH 키 구성에서 이 설정을 지정했을 수 있습니다.
(선택 사항) 배스천 호스트가 관리 클러스터를 배포하는 가용성 영역에 이미 있는 경우 배스천 호스트 확인란을 선택 취소합니다.
이 옵션을 사용하도록 설정한 상태로 두면 Tanzu Kubernetes Grid는 배스천 호스트를 생성합니다.
이 AWS 계정에 관리 클러스터를 처음 배포하는 경우 AWS CloudFormation 스택 생성 확인란을 선택합니다.
이 CloudFormation 스택은 Tanzu Kubernetes Grid가 AWS에서 클러스터를 배포하고 실행하는 데 필요한 IAM(ID 및 액세스 관리) 리소스를 생성합니다. 자세한 내용은 AWS에 관리 클러스터 배포 준비의 Tanzu Kubernetes Grid에서 설정한 사용 권한을 참조하십시오.
가용성 영역 구성:
가용성 영역 1 드롭다운 메뉴에서 관리 클러스터의 가용성 영역을 선택합니다. 개발 타일을 선택한 경우 가용성 영역을 하나만 선택할 수 있습니다. 아래 이미지를 참조하십시오.
AZ1 Worker 노드 인스턴스 유형 드롭다운 메뉴에서 이 가용성 영역에서 사용할 수 있는 인스턴스 목록에서 Worker 노드 VM의 구성을 선택합니다.
위의 프로덕션 타일을 선택한 경우 가용성 영역 2, 가용성 영역 3, AZ Worker 노드 인스턴스 유형 드롭다운 메뉴를 사용하여 관리 클러스터에 세 개의 고유한 가용성 영역을 선택합니다.
Tanzu Kubernetes Grid는 제어부 노드 3개와 Worker 노드 3개를 포함하는 관리 클러스터를 배포하면 이러한 가용성 영역에 제어부 노드와 Worker 노드를 분산합니다.
VPC 공용 서브넷(VPC public subnet) 및 VPC 개인 서브넷(VPC private subnet) 드롭다운 메뉴를 사용하여 VPC에서 서브넷을 선택합니다.
프로덕션 관리 클러스터를 배포하는 경우 세 가지 가용성 영역 모두에 서브넷을 선택합니다. 이전 섹션에서 인터넷 연결 VPC가 아닙니다를 선택한 경우 공용 서브넷을 사용할 수 없습니다. 다음 이미지는 개발 타일을 보여줍니다.
다음을 클릭합니다.
NSX Advanced Load Balancer 구성은 vSphere 배포에만 적용됩니다.
중요TKG 독립형 관리 클러스터 및 해당 워크로드 클러스터에서 NSX Advanced Load Balancer를 사용하려면 NSX ALB v22.1.2 이상이 필요합니다.
선택 사항인 VMware NSX Advanced Load Balancer 섹션에서 NSX Advanced Load Balancer를 사용하도록 Tanzu Kubernetes Grid를 구성할 수 있습니다. 기본적으로 모든 워크로드 클러스터는 로드 밸런서를 사용합니다.
컨트롤러 인증서를 생성하는 데 사용되는 CA(인증 기관)의 컨텐츠를 컨트롤러 인증 기관 텍스트 상자에 붙여 넣고 자격 증명 확인을 클릭합니다.
인증서 컨텐츠는 -----BEGIN CERTIFICATE-----
로 시작합니다.
자체 서명된 컨트롤러 인증서가 있는 경우 시스템 액세스 설정 > SSSL 인증서 아래의 Avi 컨트롤러 UI > 관리 > 세팅 > 액세스 설정 탭에 구성된 SSL/TLS 인증서를 사용해야 합니다. Avi 컨트롤러 설정:에 설명된 대로 인증서 콘텐츠를 검색합니다. 사용자 지정 인증서에 설명된 대로 인코딩되지 않은 사용자 지정 인증서 컨텐츠를 검색합니다.
클라우드 이름 드롭다운 메뉴를 사용하여 NSX Advanced Load Balancer 배포에서 생성한 클라우드를 선택합니다.
예: Default-Cloud
.
워크로드 클러스터(Workload Cluster) 및 관리 클러스터(Management Cluster) 섹션에서 서비스 엔진 그룹 이름(Service Engine Group Name) 드롭다운 메뉴를 사용하여 서비스 엔진 그룹을 선택합니다.
예: Default-Group
.
워크로드 클러스터 - 데이터부 VIP 네트워크 이름(Workload Cluster - Data Plane VIP Network Name) 드롭다운 메뉴에서 로드 밸런서 부동 IP 풀이 상주하는 네트워크의 이름을 선택합니다.
워크로드 클러스터와 관리 클러스터 모두의 데이터부 및 제어부에서 사용할 동일한 네트워크가 자동으로 선택됩니다. 필요한 경우 변경할 수 있습니다.
NSX ALB용 VIP 네트워크는 Tanzu Kubernetes Grid가 사용하는 Kubernetes 네트워크와 동일한 vCenter Server 인스턴스에 있어야 합니다. 이를 통해 NSX Advanced Load Balancer vCenter Server Kubernetes 네트워크를 검색하고 서비스 엔진을 배포 및 구성할 수 있습니다.
NSX Advanced Load Balancer 인터페이스의 인프라 > 네트워크 보기에서 네트워크를 볼 수 있습니다.
워크로드 클러스터 - 데이터부 VIP 네트워크 CIDR(Workload Cluster - Data Plane VIP Network CIDR) 및 워크로드 클러스터 - 제어부 VIP 네트워크 CIDR(Workload Cluster - Control Plane VIP Network CIDR) 드롭다운 메뉴에서 워크로드 클러스터 및 관리 클러스터의 데이터부 및 제어부에서 사용할 로드 밸런서 VIP에 사용할 서브넷의 CIDR을 선택하거나 입력합니다.
VIP 네트워크의 구성된 서브넷 중 하나에서 옵니다. NSX Advanced Load Balancer 인터페이스의 인프라 > 네트워크 보기에서 특정 네트워크의 서브넷 CIDR을 볼 수 있습니다. 해당하는 관리 클러스터 설정에 동일한 CIDR이 자동으로 적용됩니다. 필요한 경우 변경할 수 있습니다.
(선택 사항) NSX ALB를 선택적으로 사용하도록 설정하거나 여러 클러스터 그룹에 NSX ALB 설정을 사용자 지정할 클러스터를 식별하기 위한 하나 이상의 클러스터 레이블을 입력합니다.
기본적으로 NSX Advanced Load Balancer는 이 관리 클러스터와 함께 배포된 모든 워크로드 클러스터에서 사용하도록 설정되고 클러스터는 동일한 VMware NSX Advanced Load Balancer 컨트롤러, 클라우드, 서비스 엔진 그룹, VIP 네트워크를 공유합니다. 나중에 변경할 수 없습니다.
필요한 경우 클러스터의 하위 집합에서만 NSX ALB를 사용하도록 설정하거나 나중에 다른 클러스터 그룹에 NSX ALB 설정을 사용자 지정하는 기능을 유지할 수 있습니다. 이 방법은 다음과 같은 시나리오에서 유용합니다.
전역이 아닌 선택적으로 NSX ALB를 사용하도록 설정하려면 key: value
형식의 레이블을 추가합니다. 여기에서 정의하는 레이블은 레이블 선택기를 생성하는 데 사용됩니다. 일치하는 레이블이 있는 워크로드 클러스터 Cluster
개체만 로드 밸런서를 사용하도록 설정됩니다. 따라서 워크로드 클러스터의 Cluster
개체에 해당하는 레이블이 있는지 확인해야 합니다.
예를 들어 team: tkg
를 사용하여 워크로드 클러스터에서 로드 밸런서를 사용하도록 설정하는 경우:
kubectl
을 관리 클러스터의 컨텍스트로 설정합니다.
kubectl config use-context management-cluster@admin
레이블이 정의된 해당 워크로드 클러스터의 Cluster
개체에 레이블을 지정합니다. 여러 키-값을 정의하는 경우 모두 적용해야 합니다.
kubectl label cluster <cluster-name> team=tkg
다음을 클릭하여 메타데이터를 구성합니다.
이 섹션은 모든 대상 플랫폼에 대해 동일합니다.
선택 사항인 메타데이터 섹션에서 선택적으로 이 관리 클러스터의 설명 정보를 입력합니다.
여기에서 지정하는 모든 메타데이터는 관리 클러스터 및 관리 클러스터가 관리하는 워크로드 클러스터에 적용되며 선택한 클러스터 관리 도구를 사용하여 액세스할 수 있습니다.
release : beta
environment : staging
또는 environment : production
). 자세한 내용은 Kubernetes 설명서의 레이블 및 선택기를 참조하십시오.vSphere에 배포하는 경우 다음을 클릭하여 리소스 구성으로 이동합니다. AWS 또는 Azure에 배포하는 경우 다음을 클릭하여 Kubernetes 네트워크 및 프록시 구성으로 이동합니다.
이 섹션은 vSphere 배포에만 적용됩니다.
관리 클러스터에서 사용할 vSphere 데이터스토어를 선택합니다. VM의 스토리지 정책은 구성 파일에서 관리 클러스터를 배포할 때만 지정할 수 있습니다.
가용성 영역 지정에서 관리 클러스터 노드를 배치할 위치를 선택한 다음 세부 사항을 입력합니다.
AZ 없음: 클러스터, 호스트 또는 리소스 풀별로 노드를 배치하려면 노드를 배치할 클러스터, 호스트 또는 리소스 풀을 선택합니다.
클러스터 기반 AZ: 데이터 센터의 여러 계산 클러스터에 노드를 분산하려면 다음 방법 중 하나로 해당 AZ를 지정합니다.
호스트 그룹 기반 AZ: 단일 계산 클러스터의 여러 호스트에 노드를 분산하려면 다음 방법 중 하나로 해당 AZ를 지정합니다.
참고vSphere 적절한 리소스가 아직 없는 경우 Tanzu Kubernetes Grid 설치 관리자를 종료하지 않고 vSphere로 이동하여 생성합니다. 그런 다음 새로 고침 버튼을 클릭하여 새 리소스를 선택할 수 있습니다.
이 섹션은 모든 대상 플랫폼에 대해 동일하지만 입력하는 정보 중 일부는 사용 중인 제공자에 따라 다릅니다.
Kubernetes 네트워크 섹션에서 Kubernetes 서비스의 네트워킹을 구성하고 다음을 클릭합니다.
100.64.0.0/13
및 100.96.0.0/11
을 사용할 수 없는 경우 클러스터 서비스 CIDR 및 클러스터 포드 CIDR에서 값을 업데이트합니다.(선택 사항) 관리 클러스터에서 프록시로 송신 HTTP(S) 트래픽을 보내려면(예: 인터넷 제한 환경에서) 사용 가능한 프록시 설정을 전환하고 아래 지침에 따라 프록시 정보를 입력합니다. Tanzu Kubernetes Grid는 이러한 설정을 kubelet, containerd, 제어부에 적용합니다.
하나의 프록시를 HTTP 트래픽에 사용하고 다른 프록시를 HTTPS 트래픽에 사용하거나 HTTP 및 HTTPS 트래픽 모두에 동일한 프록시를 사용하도록 선택할 수 있습니다.
중요클러스터를 배포한 후에는 프록시를 변경할 수 없습니다.
HTTP 프록시 정보를 추가하려면 다음을 수행합니다.
http://
로 시작해야 합니다. 예: http://myproxy.com:1234
.프록시에 인증이 필요한 경우 HTTP 프록시 사용자 이름과 HTTP 프록시 암호에서 HTTP 프록시에 연결하는 데 사용할 사용자 이름과 암호를 입력합니다.
참고설치 관리자 인터페이스를 사용하여 관리 클러스터를 배포할 때 암호에는 영숫자가 아닌 문자를 사용할 수 없습니다.
HTTPS 프록시 정보를 추가하려면 다음을 수행합니다.
HTTPS 트래픽에 다른 URL을 사용하려면 다음을 수행합니다.
http://
로 시작해야 합니다. 예: http://myproxy.com:1234
.프록시에 인증이 필요한 경우 HTTPS 프록시 사용자 이름과 HTTPS 프록시 암호에서 HTTPS 프록시에 연결하는 데 사용할 사용자 이름과 암호를 입력합니다.
참고설치 관리자 인터페이스를 사용하여 관리 클러스터를 배포할 때 암호에는 영숫자가 아닌 문자를 사용할 수 없습니다.
프록시 없음에서 HTTP(S) 프록시를 우회해야 하는 쉼표로 구분된 네트워크 CIDR 또는 호스트 이름 목록을 입력합니다. 관리 클러스터가 인프라와 동일한 네트워크에서 실행되는 경우 동일한 프록시 뒤에 있는 관리 클러스터가 인프라와 직접 통신하도록 인프라 CIDR 또는 FQDN으로 설정합니다.
예: noproxy.yourdomain.com,192.168.0.0/24
.
localhost
, 127.0.0.1
, 클러스터 포드 CIDR 및 클러스터 서비스 CIDR의 값, .svc
, .svc.cluster.local
을 이 필드에 입력하는 목록에 추가합니다.localhost
,
127.0.0.1
, VPC CIDR,
클러스터 포드 CIDR,
클러스터 서비스 CIDR,
.svc
,
.svc.cluster.local
,
169.254.0.0/16
을 이 필드에 입력하는 목록에 추가합니다.
localhost
,
127.0.0.1
, VNet CIDR,
클러스터 포드 CIDR,
클러스터 서비스 CIDR,
.svc
,
.svc.cluster.local
,
169.254.0.0/16
,
168.63.129.16
을 이 필드에 입력하는 목록에 추가합니다.
중요관리 클러스터 VM이 Tanzu Kubernetes Grid 환경의 외부 서비스 및 인프라 끝점과 통신해야 하는 경우, 위에서 구성한 프록시로 해당 끝점에 연결할 수 있는지 확인하거나 해당 끝점을 프록시 없음에 추가합니다. 환경 구성에 따라 OIDC 또는 LDAP 서버, Harbor 및 vSphere, VMware NSX 및 NSX Advanced Load Balancer 등이 포함될 수 있지만 이에 국한되지는 않습니다.
이 섹션은 모든 대상 플랫폼에 대해 동일합니다. Tanzu Kubernetes Grid가 ID 관리를 구현하는 방법에 대한 자세한 내용은 ID 및 액세스 관리 정보를 참조하십시오.
ID 관리(Identity Management) 섹션에서 선택적으로 ID 관리 설정 사용(Activate Identity Management Settings)을 비활성화합니다.
개념 증명 배포의 ID 관리를 비활성화할 수 있지만 프로덕션 배포에서 ID 관리를 구현하는 것이 좋습니다. ID 관리를 비활성화하는 경우 나중에 다시 활성화할 수 있습니다. ID 관리를 다시 사용하도록 설정할 수 있는 방법에 대한 지침은 ID 관리 구성의 기존 배포에서 ID 관리 사용 및 구성을 참조하십시오.
ID 관리를 사용하도록 설정하는 경우 OIDC 또는 LDAPS를 선택합니다.
아래에서 OIDC 또는 LDAPS 탭을 선택하여 구성 정보를 확인합니다.
client_id
값입니다. 예를 들어 제공자가 Okta인 경우, client_id
및 secret
를 가져오려면 Okta에 로그인하고 Web 애플리케이션을 생성한 후 클라이언트 자격 증명 옵션을 선택합니다.secret
값입니다.openid,groups,email
.user_name
, email
또는 code
와 같은 할당을 입력합니다.groups
.host:port
형식으로 입력합니다.사용자 검색 특성을 제공합니다.
OU=Users,OU=domain,DC=io
.uid, sAMAccountName
.그룹 검색 특성을 입력합니다.
OU=Groups,OU=domain,DC=io
.cn
.distinguishedName, dn
.member
.LDAPS 서버 CA 인증서의 컨텐츠를 ROOT CA 텍스트 상자에 붙여 넣습니다.
(선택 사항) LDAP 설정을 확인합니다.
사용자 이름과 그룹 이름을 입력합니다.
참고Tanzu Kubernetes Grid v1.4.x 이상에서는 이러한 필드가 무시되고 사용자 이름이
cn
으로, 그룹 이름이ou
로 되돌아갑니다. 이 알려진 문제에 대한 업데이트는 VMware Tanzu Kubernetes Grid 1.5 Release Notes 를 참조하십시오.
시작을 클릭합니다.
확인 후 오류가 표시되면 이후 단계에서 면밀히 확인해야 합니다.
참고LDAP 호스트는 관리 클러스터 노드가 아닌 이 점검을 수행합니다. 따라서 이 확인이 실패하더라도 LDAP 구성이 작동할 수 있습니다.
OS 이미지 섹션에서 드롭다운 메뉴를 사용하여 Tanzu Kubernetes Grid VM 배포에 사용할 OS와 Kubernetes 버전 이미지 템플릿을 선택하고 다음을 클릭합니다.
OS 이미지 드롭다운 메뉴에는 다음 조건을 모두 충족하는 OS 이미지가 포함됩니다.
ova
, ami
, azure
블록에 각각 나열됩니다.version
, id
, sku
필드 값으로 식별됩니다.이 섹션은 모든 대상 플랫폼에 대해 동일합니다.
CEIP 참여(CEIP Participation) 섹션에서 선택적으로 이 확인란의 선택을 취소하여 VMware 고객 환경 향상 프로그램에서 옵트아웃하고 다음(Next)을 클릭합니다.
관리 클러스터를 배포한 후 프로그램을 옵트인하거나 옵트아웃할 수도 있습니다. CEIP에 대한 자세한 내용은 CEIP에 참여 관리 및 https://www.vmware.com/solutions/trustvmware/ceip.html을 참조하십시오.
구성 검토를 클릭하여 구성한 관리 클러스터의 세부 정보를 확인합니다. 설치 관리자 마법사로 돌아가 구성을 수정하려면 구성 편집을 클릭합니다.
구성 검토를 클릭하면 설치 관리자는 ~/.config/tanzu/tkg/clusterconfigs
하위 디렉토리에 있는 클러스터 구성 파일을 인터페이스에 지정한 설정으로 채웁니다. 필요한 경우 구성 내보내기를 클릭하여 이 구성 파일의 복사본을 내보낼 수 있습니다.
관리 클러스터 배포를 클릭합니다.
관리 클러스터를 배포하는 데 몇 분 정도 걸릴 수 있습니다. tanzu mc create
의 첫 번째 실행은 필요한 Docker 이미지를 부트스트랩 시스템의 이미지 저장소로 끌어와야 하기 때문에 후속 실행보다 오래 걸립니다. 이후 실행에서는 이 단계가 필요하지 않으므로 더 빠릅니다. 설치 관리자 인터페이스 또는 tanzu mc create --ui
를 실행한 터미널에서 관리 클러스터 배포의 진행률을 확인할 수 있습니다. tanzu mc create
를 실행하는 시스템이 로컬 작업이 완료되기 전에 종료되거나 다시 시작되면 배포가 실패합니다. 배포가 완료되기 전에 실행 중인 브라우저 또는 브라우저 탭을 실수로 닫으면 터미널에서 배포가 계속됩니다.
(선택 사항) CLI 명령과 동일에서 복사 버튼을 클릭하여 지정한 구성에 CLI 명령을 복사합니다. 이 CLI 명령에는 설치 관리자가 입력한 구성 파일의 경로가 포함됩니다.
(vSphere 전용) 관리 클러스터를 vSphere에 배포한 후 클러스터가 배포된 후 제어부 노드의 DHCP 예약 구성(vSphere만 해당)에 설명된 대로 해당 제어부 노드의 IP 주소를 고정으로 구성해야 합니다.
~/.config/tanzu/tkg/clusterconfigs
UNIQUE-ID.yaml
형식의 생성된 파일 이름으로 저장합니다. 이 구성 파일은 CLUSTER_NAME
과 같은 대문자 밑줄 변수를 설정하는 플랫 구조를 가지고 있습니다. 배포가 완료된 후 필요에 따라 구성 파일의 이름을 기억에 남는 이름으로 변경하고 나중에 사용할 수 있도록 다른 위치에 저장할 수 있습니다. 또한 설치 관리자는 관리 클러스터의 Cluster
개체를 위한 Kubernetes 스타일의 클래스 기반 개체 규격을 생성합니다. 이 규격은 관리 클러스터와 동일한 이름을 가진 파일에 저장됩니다. 이 클래스 기반 개체 규격은 참고용으로만 제공됩니다. 클래스 기반 개체 규격에서 관리 클러스터를 배포하는 것은 아직 지원되지 않습니다. TKG 2.x의 클러스터 유형에 대한 자세한 내용은 Tanzu Kubernetes Grid 정보의 워크로드 클러스터를 참조하십시오.관리 클러스터를 배포하는 동안 일어나는 일과 kubectl
을 관리 클러스터에 연결하는 방법에 대한 자세한 내용은 새로 배포된 독립형 관리 클러스터 검사 및 등록을 참조하십시오.