This site will be decommissioned on December 31st 2024. After that date content will be available at techdocs.broadcom.com.

 

설치 관리자 인터페이스를 사용하여 관리 클러스터 배포

이 항목에서는 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 관리 및 워크로드 클러스터의 사용 중단을 참조하십시오.

사전 요구 사항

관리 클러스터를 배포하려면 먼저 환경이 대상 플랫폼에 대한 요구 사항을 충족하는지 확인해야 합니다.

일반적인 사전 요구 사항

  • 모든 요구 사항을 충족하고 독립형 관리 클러스터에서 사용할 Tanzu CLI 및 Kubernetes CLI 설치 절차를 따랐는지 확인합니다.

  • 프로덕션 배포의 경우 클러스터에 ID 관리를 사용하도록 설정하는 것이 좋습니다. 관리 클러스터를 배포하기 전에 수행할 준비 단계에 대한 자세한 내용은 구성 ID 관리의 ID 제공자 세부 정보를 참조하십시오.

  • 인터넷이 제한된 환경에서 vSphere 또는 AWS에 클러스터를 배포하는 경우 인터넷 제한 환경 준비 단계도 수행해야 합니다. 이러한 단계에는 TKG_CUSTOM_IMAGE_REPOSITORY를 환경 변수로 설정하는 것이 포함됩니다.

인프라 사전 요구 사항

각 대상 플랫폼에는 관리 클러스터 배포를 위한 추가 사전 요구 사항이 있습니다.

vSphere
vSphere에 관리 클러스터 배포 준비에 있는 모든 요구 사항을 충족했는지 확인합니다.
참고

vSphere 8의 vSphere with Tanzu에서는 관리 클러스터를 배포할 필요가 없습니다. vSphere with Tanzu Supervisor는 관리 클러스터입니다를 참조하십시오.

AWS
Azure


설치 관리자 인터페이스 시작

기본적으로 Tanzu Kubernetes Grid는 ~/.kube-tkg/config 파일에 모든 관리 클러스터의 kubeconfig를 저장합니다. 관리 클러스터의 kubeconfig 파일을 다른 위치에 저장하려면 tanzu mc create를 실행하기 전에 KUBECONFIG 환경 변수를 설정합니다.

  1. 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의 다른 시스템에서 실행되는 것을 포함하여 설치 관리자 인터페이스가 실행되는 위치를 변경하는 방법을 설명합니다.

  2. VMware vSphere, Amazon EC2 또는 Microsoft Azure의 배포 버튼을 클릭합니다.

    vSphere에 배포 버튼이 있는 Tanzu Kubernetes Grid 설치 관리자 인터페이스 시작 페이지

설치 관리자 인터페이스 옵션

기본적으로 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를 사용하여 다른 로컬 포트의 인터페이스를 제공합니다.
  • 부트스트랩 시스템에 대한 SSH 터널링 또는 X11 전달 디스플레이의 경우 설치 관리자 인터페이스가 로컬로 표시되도록 하려면 --browser none을 사용해야 할 수 있습니다.

  • Tanzu CLI를 실행하고 원격 시스템에서 관리 클러스터를 생성하고 로컬 또는 다른 곳에서 설치 관리자 인터페이스를 실행하려면 다음을 수행합니다.

    1. 원격 부트스트랩 시스템에서 다음 옵션 및 값으로 tanzu mc create --ui를 실행합니다.

      • --bind: 원격 시스템의 IP 주소 및 포트
      • --browser: none
      tanzu mc create --ui --bind 192.168.1.87:5555 --browser none

    2. 로컬 UI 시스템에서 원격 시스템의 IP 주소를 찾아 설치 관리자 인터페이스에 액세스합니다.

대상 플랫폼 구성

대상 플랫폼을 구성하는 옵션은 사용 중인 제공자에 따라 다릅니다.

vSphere
vSphere 인스턴스에 대한 연결을 구성합니다.

  1. IaaS 제공자 섹션에서 관리 클러스터를 배포할 vCenter Server 인스턴스의 IP 주소 또는 FQDN(정규화된 도메인 이름)을 입력합니다.

    Tanzu Kubernetes Grid에서 IPv6 주소에 대한 지원은 제한됩니다. APv6의 클러스터 배포(vSphere 전용)를 참조하십시오. IPv6 전용 네트워킹 환경에 배포하지 않는 경우 다음 단계에서 IPv4 주소를 입력해야 합니다.

  2. Tanzu Kubernetes Grid 작업에 필요한 권한이 있는 사용자 계정의 vCenter Single Sign-On 사용자 이름과 암호를 입력합니다.

    계정 이름에는 도메인(예: [email protected])이 포함되어야 합니다.

    vSphere에 연결 구성

  3. (선택 사항) SSL 지문 확인에서 확인 사용 안 함을 선택합니다. 이 확인란을 선택하면 설치 관리자가 vCenter Server에 연결할 때 인증서 지문 확인을 우회합니다.

  4. 연결을 클릭합니다.

  5. vCenter Server 인증서의 SSL 지문을 확인하고 유효한 경우 계속을 클릭합니다. 이 화면은 위의 확인 사용 안 함 확인란이 선택 취소된 경우에만 나타납니다.

    vCenter Server 인증서 지문 확인

    vCenter Server 인증서 지문을 가져오는 방법에 대한 자세한 내용은 vSphere 인증서 지문 가져오기를 참조하십시오.

  6. 관리 클러스터를 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.3 워크로드 클러스터 생성 및 관리의 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에 필요한 독립형 관리 클러스터를 계속 배포할 수 있습니다.

    vSphere 8에 관리 클러스터 배포

  7. 데이터센터 드롭다운 메뉴에서 관리 클러스터를 배포할 데이터 센터를 선택합니다.

  8. SSH 공용 키를 추가합니다. SSH 공용 키를 추가하려면 파일 찾아보기 옵션을 사용하거나 키의 컨텐츠를 텍스트 상자에 수동으로 붙여 넣습니다. 다음을 클릭합니다.

    데이터 센터 선택 및 SSH 공용 키 제공

AWS
AWS 계정에 대한 연결을 구성합니다.

  1. IaaS 제공자 섹션에서 AWS 계정의 자격 증명을 입력하는 방법을 선택합니다. 다음 두 가지 옵션 중에서 선택할 수 있습니다.

    • 자격 증명 프로필(권장): 이미 존재하는 AWS 자격 증명 프로필을 선택합니다. 프로필을 선택하면 프로필에 구성된 액세스 키와 세션 토큰 정보가 UI에 실제 값을 표시하지 않고 설치 관리자로 전달됩니다. 자격 증명 프로필 설정에 대한 자세한 내용은 자격 증명 파일 및 프로필을 참조하십시오.

      자격 증명 프로필 선택

    • 일회성 자격 증명 AWS 계정의 액세스 키 ID 및 암호 액세스 키 필드에 AWS 계정 자격 증명을 직접 입력합니다. 또는 AWS 계정에 임시 자격 증명이 필요하도록 구성된 경우 세션 토큰에 AWS 세션 토큰을 지정합니다. 세션 토큰 획득에 대한 자세한 내용은 AWS 리소스에 임시 자격 증명 사용을 참조하십시오.

      AWS 자격 증명 입력

  2. 지역에서 관리 클러스터를 배포할 AWS 지역을 선택합니다.

    프로덕션 관리 클러스터를 배포하려는 경우 이 지역에는 3개 이상의 가용성 영역이 있어야 합니다.

  3. 연결(Connect)을 클릭합니다. 연결이 되면 다음(Next)을 클릭합니다.

  4. AWS용 VPC(VPC for AWS) 섹션의 드롭다운 메뉴에서 VPC ID를 선택합니다. VPC를 선택하면 VPC CIDR 블록이 자동으로 채워집니다. 프록시 또는 에어갭 환경과 같이 인터넷이 제한된 환경에서 관리 클러스터를 배포하는 경우 인터넷 연결 VPC가 아닙니다 확인란을 선택합니다.

    기존 VPC 사용

Azure
Microsoft Azure 계정에 대한 연결을 구성합니다.
중요

새 버전의 Tanzu Kubernetes Grid(예: v2.3)를 사용하여 관리 클러스터를 Azure에 처음 배포하는 경우, 해당 버전의 기본 이미지 라이센스를 수락했는지 확인합니다. 자세한 내용은 Microsoft Azure에 관리 클러스터 배포 준비의 기본 이미지 라이센스 수락을 참조하십시오.

  1. IaaS 제공자 섹션에서 Azure 계정의 테넌트 ID, 클라이언트 ID, 클라이언트 암호, 구독 ID 값을 입력합니다. Azure 애플리케이션을 등록하고 Azure Portal을 사용하여 암호를 생성할 때 이러한 값을 기록했습니다.

    Azure에 대한 연결 구성

  2. 공용 클라우드 또는 미국 정부 클라우드 중에서 Azure 환경을 선택합니다. 구성 파일에서 배포하고 AZURE_ENVIRONMENT를 설정하여 다른 환경을 지정할 수 있습니다.
  3. 연결을 클릭합니다. 설치 관리자는 연결을 확인하고 버튼 레이블을 연결됨으로 변경합니다.
  4. 관리 클러스터를 배포할 Azure 지역을 선택합니다.

  5. SSH 공용 키의 컨텐츠(예: .ssh/id_rsa.pub)를 텍스트 상자에 붙여 넣습니다.

  6. 리소스 그룹에서 기존 리소스 그룹 선택 또는 새 리소스 그룹 생성 라디오 버튼을 선택합니다.

    • 기존 리소스 그룹 선택을 선택하는 경우 드롭다운 메뉴를 사용하여 그룹을 선택한 후 다음을 클릭합니다.

      기존 리소스 그룹 선택

    • 새 리소스 그룹 생성을 선택하는 경우 새 리소스 그룹의 이름을 입력한 후 다음을 클릭합니다.

      새 리소스 그룹 생성

  7. Azure용 VNet 섹션에서 Azure에서 새 VNet 생성 또는 기존 VNet 선택 라디오 버튼을 선택합니다.

    • Azure에서 새 VNet 생성을 선택하는 경우 드롭다운 메뉴를 사용하여 VNet을 생성할 리소스 그룹을 선택하고 다음을 입력합니다.

      • VNet의 이름 및 CIDR 블록. 기본값은 10.0.0.0/16입니다.
      • 제어부 서브넷의 이름 및 CIDR 블록. 기본값은 10.0.0.0/24입니다.
      • Worker 노드 서브넷의 이름 및 CIDR 블록. 기본값은 10.0.1.0/24입니다.

      Azure에서 새 VNet 생성

      이러한 필드를 구성한 후 다음을 클릭합니다.

    • 기존 VNet 선택을 선택하는 경우 드롭다운 메뉴를 사용하여 VNet이 있는 리소스 그룹, VNet 이름, 제어부, Worker 노드 서브넷을 선택한 후 다음을 클릭합니다.

      기존 VNet 선택

    • Azure 개인 클러스터에 설명된 대로 관리 클러스터를 개인으로 설정하려면 개인 Azure 클러스터 확인란을 선택합니다.


관리 클러스터 설정 구성

관리 클러스터를 구성하는 옵션 중 일부는 사용 중인 제공자에 따라 다릅니다.

  1. 관리 클러스터 설정 섹션에서 개발 또는 프로덕션 타일을 선택합니다.

    • 개발을 선택하면 설치 관리자는 단일 제어부 노드와 단일 Worker 노드가 포함된 관리 클러스터를 배포합니다.
    • 프로덕션을 선택하면 설치 관리자는 제어부 노드 3개와 Worker 노드 3개가 포함된 고가용성 관리 클러스터를 배포합니다.

  2. 개발 또는 프로덕션 타일 중 하나에서 선택 유형 드롭다운 메뉴를 사용하여 제어부 노드 VM 또는 VM에 대해 다양한 CPU, RAM, 스토리지 조합 중에서 선택합니다.

    실행될 예상 워크로드에 따라 제어부 노드 VM에 대한 구성을 선택합니다. 예를 들어 일부 워크로드에는 큰 계산 용량이 필요하지만 스토리지가 상대적으로 적은 워크로드도 있고, 대용량의 스토리지와 더 적은 계산 용량이 필요할 수 있습니다. 프로덕션 타일에서 인스턴스 유형을 선택하면 선택한 인스턴스 유형이 Worker 노드 인스턴스 유형으로 자동 선택됩니다. 필요한 경우 이를 변경할 수 있습니다.

    Tanzu Mission Control에 관리 클러스터를 등록하려는 경우 워크로드 클러스터가 Tanzu Mission Control 설명서의 Tanzu Mission Control에 Tanzu Kubernetes 클러스터를 등록하는 요구 사항에 있는 요구 사항을 충족하는지 확인합니다.

    vSphere
    미리 정의된 CPU, 메모리, 스토리지 구성에서 크기를 선택합니다. 최소 구성은 CPU 2개와 4GB 메모리입니다.
    AWS
    인스턴스 크기를 선택합니다. 드롭다운 메뉴에는 크기가 아닌 알파벳순으로 선택 항목이 나열됩니다. 최소 구성은 CPU 2개와 8GB 메모리입니다. 호환되는 인스턴스 유형 목록은 지역에 따라 다릅니다. 서로 다른 크기의 인스턴스 구성에 대한 자세한 내용은 Amazon EC2 인스턴스 유형을 참조하십시오.
    Azure
    인스턴스 크기를 선택합니다. 최소 구성은 CPU 2개와 8GB 메모리입니다. 호환되는 인스턴스 유형 목록은 지역에 따라 다릅니다. 다양한 크기의 Azure용 노드 인스턴스 구성에 대한 자세한 내용은 Azure의 가상 시스템 크기를 참조하십시오.

    제어부 노드 구성 선택

  3. 필요한 경우 관리 클러스터의 이름을 입력합니다.

    이름을 지정하지 않으면 Tanzu Kubernetes Grid가 고유한 이름을 자동으로 생성합니다. 이름을 지정하는 경우 해당 이름은 숫자 문자가 아닌 문자로 끝나야 하며 RFC 952에 설명되어 있고 RFC 1123에 수정된 대로 DNS 호스트 이름 요구 사항을 준수해야 합니다.

  4. (선택 사항) MachineHealthCheck를 활성화하려면 시스템 상태 점검(Machine Health Checks) 확인란을 선택합니다. CLI를 사용하여 배포 후 클러스터에서 MachineHealthCheck를 활성화하거나 비활성화할 수 있습니다. 지침은 로드 클러스터의 시스템 상태 점검 구성을 참조하십시오.

  5. (선택 사항) 감사 로깅 사용 확인란을 선택하여 Kubernetes API 서버에 대한 요청을 기록합니다. 자세한 내용은 감사 로깅을 참조하십시오.

  6. 대상 플랫폼과 관련된 추가 설정을 구성합니다.

    vSphere
    vSphere 관련 설정을 구성합니다.
    1. Worker 노드 인스턴스 유형에서 Worker 노드 VM의 구성을 선택합니다.

    2. 제어부 끝점 제공자에서 Kube-Vip 또는 NSX Advanced Load Balancer를 선택하여 제어부 API 서버에 사용할 구성 요소를 선택합니다.

      NSX Advanced Load Balancer를 사용하려면 먼저 vSphere 환경에 배포해야 합니다. 자세한 내용은 NSX Advanced Load Balancer 설치를 참조하십시오. NSX Advanced Load Balancer를 제어부 끝점 제공자로 사용하는 장점에 대한 자세한 내용은 NSX Advanced Load Balancer 구성을 참조하십시오.

    3. 제어부 끝점에서 관리 클러스터에 대한 API 요청의 고정 가상 IP 주소 또는 FQDN을 입력합니다. 이 설정은 Kube-Vip를 사용하는 경우에 필요합니다.

      이 IP 주소가 DHCP 범위에 있지 않지만 DHCP 범위와 동일한 서브넷에 있는지 확인합니다. FQDN을 VIP 주소에 매핑한 경우 VIP 주소 대신 FQDN을 지정할 수 있습니다. 자세한 내용은 vSphere용 정적 VIP 및 로드 밸런서를 참조하십시오.

      NSX Advanced Load Balancer를 제어부 끝점 제공자로 사용하는 경우 VIP가 NSX Advanced Load Balancer 고정 IP 풀에서 자동으로 할당됩니다.

      vSphere 제어부 끝점 구성

    AWS
    AWS와 관련된 설정을 구성합니다.

    1. EC2 키 쌍에서 AWS 계정 및 관리 클러스터를 배포하는 지역에 이미 등록된 AWS 키 쌍의 이름을 지정합니다. AWS 계정 자격 증명 및 SSH 키 구성에서 이 설정을 지정했을 수 있습니다.

    2. (선택 사항) 배스천 호스트가 관리 클러스터를 배포하는 가용성 영역에 이미 있는 경우 배스천 호스트 확인란을 선택 취소합니다.

      이 옵션을 사용하도록 설정한 상태로 두면 Tanzu Kubernetes Grid는 배스천 호스트를 생성합니다.

    3. 이 AWS 계정에 관리 클러스터를 처음 배포하는 경우 AWS CloudFormation 스택 생성 확인란을 선택합니다.

      이 CloudFormation 스택은 Tanzu Kubernetes Grid가 AWS에서 클러스터를 배포하고 실행하는 데 필요한 IAM(ID 및 액세스 관리) 리소스를 생성합니다. 자세한 내용은 AWS에 관리 클러스터 배포 준비의 Tanzu Kubernetes Grid에서 설정한 사용 권한을 참조하십시오.

    4. 가용성 영역 구성:

      1. 가용성 영역 1 드롭다운 메뉴에서 관리 클러스터의 가용성 영역을 선택합니다. 개발 타일을 선택한 경우 가용성 영역을 하나만 선택할 수 있습니다. 아래 이미지를 참조하십시오.

        클러스터 구성

      2. AZ1 Worker 노드 인스턴스 유형 드롭다운 메뉴에서 이 가용성 영역에서 사용할 수 있는 인스턴스 목록에서 Worker 노드 VM의 구성을 선택합니다.

      3. 위의 프로덕션 타일을 선택한 경우 가용성 영역 2, 가용성 영역 3, AZ Worker 노드 인스턴스 유형 드롭다운 메뉴를 사용하여 관리 클러스터에 세 개의 고유한 가용성 영역을 선택합니다.

        Tanzu Kubernetes Grid는 제어부 노드 3개와 Worker 노드 3개를 포함하는 관리 클러스터를 배포하면 이러한 가용성 영역에 제어부 노드와 Worker 노드를 분산합니다.

      4. VPC 공용 서브넷(VPC public subnet) 및 VPC 개인 서브넷(VPC private subnet) 드롭다운 메뉴를 사용하여 VPC에서 서브넷을 선택합니다.

        프로덕션 관리 클러스터를 배포하는 경우 세 가지 가용성 영역 모두에 서브넷을 선택합니다. 이전 섹션에서 인터넷 연결 VPC가 아닙니다를 선택한 경우 공용 서브넷을 사용할 수 없습니다. 다음 이미지는 개발 타일을 보여줍니다.

      VPC 서브넷 설정

    Azure
    Worker 노드 인스턴스 유형에서 Worker 노드 VM의 구성을 선택합니다.

  7. 다음을 클릭합니다.

VMware NSX Advanced Load Balancer 구성

NSX Advanced Load Balancer 구성은 vSphere 배포에만 적용됩니다.

vSphere
ALB(VMware NSX Advanced Load Balancer)는 vSphere용 L4+L7 로드 밸런싱 솔루션을 제공합니다. NSX ALB에는 워크로드에 대한 로드 밸런싱 및 수신 리소스의 수명 주기를 관리하기 위해 Kubernetes API와 통합되는 Kubernetes 운영자가 포함되어 있습니다. NSX ALB를 사용하려면 먼저 vSphere 환경에 배포해야 합니다. 자세한 내용은 NSX Advanced Load Balancer 설치를 참조하십시오.
중요

TKG 독립형 관리 클러스터 및 해당 워크로드 클러스터에서 NSX Advanced Load Balancer를 사용하려면 NSX ALB v22.1.2 이상이 필요합니다.

선택 사항인 VMware NSX Advanced Load Balancer 섹션에서 NSX Advanced Load Balancer를 사용하도록 Tanzu Kubernetes Grid를 구성할 수 있습니다. 기본적으로 모든 워크로드 클러스터는 로드 밸런서를 사용합니다.

  1. 컨트롤러 호스트 컨트롤러 VM의 IP 주소 또는 FQDN을 입력합니다.
  2. 컨트롤러 호스트를 배포할 때 설정한 사용자 이름과 암호를 입력합니다.

  3. 컨트롤러 인증서를 생성하는 데 사용되는 CA(인증 기관)의 컨텐츠를 컨트롤러 인증 기관 텍스트 상자에 붙여 넣고 자격 증명 확인을 클릭합니다.

    인증서 컨텐츠는 -----BEGIN CERTIFICATE-----로 시작합니다.

    자체 서명된 컨트롤러 인증서가 있는 경우 시스템 액세스 설정 > SSSL 인증서 아래의 Avi 컨트롤러 UI > 관리 > 세팅 > 액세스 설정 탭에 구성된 SSL/TLS 인증서를 사용해야 합니다. Avi 컨트롤러 설정:에 설명된 대로 인증서 콘텐츠를 검색합니다. 사용자 지정 인증서에 설명된 대로 인코딩되지 않은 사용자 지정 인증서 컨텐츠를 검색합니다.

    Avi 관리자 > 시스템 액세스 설정 > SSL 인증서: System-Default-Portal-Cert, System-Default-Portal-Cert-EC256

  4. 클라우드 이름 드롭다운 메뉴를 사용하여 NSX Advanced Load Balancer 배포에서 생성한 클라우드를 선택합니다.

    예: Default-Cloud.

  5. 워크로드 클러스터(Workload Cluster) 및 관리 클러스터(Management Cluster) 섹션에서 서비스 엔진 그룹 이름(Service Engine Group Name) 드롭다운 메뉴를 사용하여 서비스 엔진 그룹을 선택합니다.

    예: Default-Group.

  6. 워크로드 클러스터 - 데이터부 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 인터페이스의 인프라 > 네트워크 보기에서 네트워크를 볼 수 있습니다.

  7. 워크로드 클러스터 - 데이터부 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 워크로드 및 관리 클러스터 설정

  8. (선택 사항) 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를 사용하여 워크로드 클러스터에서 로드 밸런서를 사용하도록 설정하는 경우:

    1. kubectl을 관리 클러스터의 컨텍스트로 설정합니다.

      kubectl config use-context management-cluster@admin

    2. 레이블이 정의된 해당 워크로드 클러스터의 Cluster 개체에 레이블을 지정합니다. 여러 키-값을 정의하는 경우 모두 적용해야 합니다.

      kubectl label cluster <cluster-name> team=tkg

    NSX ALB 레이블

  9. 다음을 클릭하여 메타데이터를 구성합니다.

AWS
Tanzu Kubernetes Grid on AWS는 관리 클러스터를 배포할 때 로드 밸런서를 자동으로 생성합니다.
Azure
Tanzu Kubernetes Grid on Azure는 관리 클러스터를 배포할 때 로드 밸런서를 자동으로 생성합니다.


메타데이터 구성

이 섹션은 모든 대상 플랫폼에 대해 동일합니다.

선택 사항인 메타데이터 섹션에서 선택적으로 이 관리 클러스터의 설명 정보를 입력합니다.

여기에서 지정하는 모든 메타데이터는 관리 클러스터 및 관리 클러스터가 관리하는 워크로드 클러스터에 적용되며 선택한 클러스터 관리 도구를 사용하여 액세스할 수 있습니다.

  • 위치: 클러스터가 실행되는 지리적 위치입니다.
  • 설명: 이 관리 클러스터에 대한 설명입니다. 설명의 최대 길이는 63자이며 문자로 시작하고 끝나야 합니다. 공백 없이 소문자, 숫자, 하이픈만 포함할 수 있습니다.
  • 레이블: 사용자가 클러스터를 식별하는 데 도움이 되는 키/값 쌍입니다(예: release : beta environment : staging 또는 environment : production). 자세한 내용은 Kubernetes 설명서의 레이블 및 선택기를 참조하십시오.
    추가를 클릭하여 클러스터에 여러 레이블을 적용할 수 있습니다.

클러스터 메타데이터 추가

vSphere에 배포하는 경우 다음을 클릭하여 리소스 구성으로 이동합니다. AWS 또는 Azure에 배포하는 경우 다음을 클릭하여 Kubernetes 네트워크 및 프록시 구성으로 이동합니다.

vSphere 리소스 구성

이 섹션은 vSphere 배포에만 적용됩니다.

vSphere
리소스 섹션에서 관리 클러스터에서 사용할 vSphere 리소스를 선택합니다.
  1. 관리 클러스터 VM을 배치할 VM 폴더를 선택합니다.

  2. 관리 클러스터에서 사용할 vSphere 데이터스토어를 선택합니다. VM의 스토리지 정책은 구성 파일에서 관리 클러스터를 배포할 때만 지정할 수 있습니다.

  3. 가용성 영역 지정에서 관리 클러스터 노드를 배치할 위치를 선택한 다음 세부 사항을 입력합니다.

    • AZ 없음: 클러스터, 호스트 또는 리소스 풀별로 노드를 배치하려면 노드를 배치할 클러스터, 호스트 또는 리소스 풀을 선택합니다.

      클러스터, 호스트 또는 리소스 풀 선택(AZ 없음)

    • 클러스터 기반 AZ: 데이터 센터의 여러 계산 클러스터에 노드를 분산하려면 다음 방법 중 하나로 해당 AZ를 지정합니다.

      • AZ가 포함된 영역 또는 영역을 이름 또는 범주별로 선택합니다.
      • 이름, 클러스터 또는 범주별로 최대 3개의 특정 AZ를 선택합니다.

      지역, 영역 또는 개별적으로 클러스터 기반 AZ 선택)

    • 호스트 그룹 기반 AZ: 단일 계산 클러스터의 여러 호스트에 노드를 분산하려면 다음 방법 중 하나로 해당 AZ를 지정합니다.

      • AZ가 포함된 영역 또는 영역을 이름 또는 범주별로 선택합니다.
      • 이름, 호스트 그룹 또는 VM 그룹으로 최대 3개의 특정 AZ를 선택합니다.

      지역, 영역 또는 개별적으로 호스트 그룹 기반 AZ 선택)

    참고

    vSphere 적절한 리소스가 아직 없는 경우 Tanzu Kubernetes Grid 설치 관리자를 종료하지 않고 vSphere로 이동하여 생성합니다. 그런 다음 새로 고침 버튼을 클릭하여 새 리소스를 선택할 수 있습니다.

  4. 다음(Next)을 클릭하여 Kubernetes 네트워크와 프록시를 구성합니다.
AWS
AWS 배포에는 해당되지 않습니다.
Azure
Azure 배포에는 해당되지 않습니다.


Kubernetes 네트워크 및 프록시 구성

이 섹션은 모든 대상 플랫폼에 대해 동일하지만 입력하는 정보 중 일부는 사용 중인 제공자에 따라 다릅니다.

  1. Kubernetes 네트워크 섹션에서 Kubernetes 서비스의 네트워킹을 구성하고 다음을 클릭합니다.

    • (vSphere 전용) 네트워크 이름에서 Kubernetes 서비스 네트워크로 사용할 vSphere 네트워크를 선택합니다.
    • 클러스터 서비스 CIDR 및 클러스터 포드 CIDR 범위를 확인합니다. 권장 CIDR 범위인 100.64.0.0/13 및 100.96.0.0/11을 사용할 수 없는 경우 클러스터 서비스 CIDR 및 클러스터 포드 CIDR에서 값을 업데이트합니다.

    Kubernetes 서비스 네트워크 구성

  2. (선택 사항) 관리 클러스터에서 프록시로 송신 HTTP(S) 트래픽을 보내려면(예: 인터넷 제한 환경에서) 사용 가능한 프록시 설정을 전환하고 아래 지침에 따라 프록시 정보를 입력합니다. Tanzu Kubernetes Grid는 이러한 설정을 kubelet, containerd, 제어부에 적용합니다.

    하나의 프록시를 HTTP 트래픽에 사용하고 다른 프록시를 HTTPS 트래픽에 사용하거나 HTTP 및 HTTPS 트래픽 모두에 동일한 프록시를 사용하도록 선택할 수 있습니다.

    중요

    클러스터를 배포한 후에는 프록시를 변경할 수 없습니다.

    1. HTTP 프록시 정보를 추가하려면 다음을 수행합니다.

      1. HTTP 프록시 URL에서 HTTP 요청을 처리하는 프록시의 URL을 입력합니다. URL은 http://로 시작해야 합니다. 예: http://myproxy.com:1234.

      2. 프록시에 인증이 필요한 경우 HTTP 프록시 사용자 이름과 HTTP 프록시 암호에서 HTTP 프록시에 연결하는 데 사용할 사용자 이름과 암호를 입력합니다.

        참고

        설치 관리자 인터페이스를 사용하여 관리 클러스터를 배포할 때 암호에는 영숫자가 아닌 문자를 사용할 수 없습니다.

    2. HTTPS 프록시 정보를 추가하려면 다음을 수행합니다.

      • HTTP 및 HTTPS 트래픽 모두에 동일한 URL을 사용하려면 https 프록시에 동일한 구성 사용을 선택합니다.

      • HTTPS 트래픽에 다른 URL을 사용하려면 다음을 수행합니다.

        1. HTTPS 프록시 URL에서 HTTPS 요청을 처리하는 프록시의 URL을 입력합니다. URL은 http://로 시작해야 합니다. 예: http://myproxy.com:1234.

        2. 프록시에 인증이 필요한 경우 HTTPS 프록시 사용자 이름과 HTTPS 프록시 암호에서 HTTPS 프록시에 연결하는 데 사용할 사용자 이름과 암호를 입력합니다.

          참고

          설치 관리자 인터페이스를 사용하여 관리 클러스터를 배포할 때 암호에는 영숫자가 아닌 문자를 사용할 수 없습니다.

    3. 프록시 없음에서 HTTP(S) 프록시를 우회해야 하는 쉼표로 구분된 네트워크 CIDR 또는 호스트 이름 목록을 입력합니다. 관리 클러스터가 인프라와 동일한 네트워크에서 실행되는 경우 동일한 프록시 뒤에 있는 관리 클러스터가 인프라와 직접 통신하도록 인프라 CIDR 또는 FQDN으로 설정합니다.

      예: noproxy.yourdomain.com,192.168.0.0/24.

      vSphere
      프록시 없음 목록에는 다음이 포함되어야 합니다.
      • vCenter의 IP 주소 또는 호스트 이름. vCenter로의 트래픽은 프록시할 수 없습니다.
      • 네트워크 이름에서 선택한 vSphere 네트워크의 CIDR. vSphere 네트워크 CIDR에는 제어부 끝점의 IP 주소가 포함됩니다. 제어부 끝점에서 FQDN을 입력한 경우 FQDN과 vSphere 네트워크 CIDR을 모두 프록시 없음에 추가합니다. 내부적으로 Tanzu Kubernetes Grid는 localhost, 127.0.0.1, 클러스터 포드 CIDR 및 클러스터 서비스 CIDR의 값, .svc, .svc.cluster.local을 이 필드에 입력하는 목록에 추가합니다.
      AWS
      내부적으로 Tanzu Kubernetes Grid는 localhost, 127.0.0.1, VPC CIDR, 클러스터 포드 CIDR, 클러스터 서비스 CIDR, .svc, .svc.cluster.local, 169.254.0.0/16을 이 필드에 입력하는 목록에 추가합니다.
      Azure
      내부적으로 Tanzu Kubernetes Grid는 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 등이 포함될 수 있지만 이에 국한되지는 않습니다.


ID 관리 구성

이 섹션은 모든 대상 플랫폼에 대해 동일합니다. Tanzu Kubernetes Grid가 ID 관리를 구현하는 방법에 대한 자세한 내용은 ID 및 액세스 관리 정보를 참조하십시오.

  1. ID 관리(Identity Management) 섹션에서 선택적으로 ID 관리 설정 사용(Activate Identity Management Settings)을 비활성화합니다.

    외부 ID 제공자 구성

    개념 증명 배포의 ID 관리를 비활성화할 수 있지만 프로덕션 배포에서 ID 관리를 구현하는 것이 좋습니다. ID 관리를 비활성화하는 경우 나중에 다시 활성화할 수 있습니다. ID 관리를 다시 사용하도록 설정할 수 있는 방법에 대한 지침은 ID 관리 구성의 기존 배포에서 ID 관리 사용 및 구성을 참조하십시오.

  2. ID 관리를 사용하도록 설정하는 경우 OIDC 또는 LDAPS를 선택합니다.

    아래에서 OIDC 또는 LDAPS 탭을 선택하여 구성 정보를 확인합니다.

    OIDC
    OIDC 제공자 계정의 세부 정보(예: Okta)를 입력합니다.
    • 발급자 URL: OIDC 서버의 IP 또는 DNS 주소입니다.
    • 클라이언트 ID: OIDC 제공자로부터 가져온 client_id 값입니다. 예를 들어 제공자가 Okta인 경우, client_id 및 secret를 가져오려면 Okta에 로그인하고 Web 애플리케이션을 생성한 후 클라이언트 자격 증명 옵션을 선택합니다.
    • 클라이언트 암호: OIDC 제공자로부터 가져온 secret 값입니다.
    • 범위: 토큰 응답에서 요청할 추가 범위의 쉼표로 구분된 목록입니다. 예: openid,groups,email.
    • 사용자 이름 할당: 사용자 이름 클레임의 이름입니다. JWT(JSON Web Token) 클레임에서 사용자 이름을 설정하는 데 사용됩니다. 제공자에 따라 user_name, email 또는 code와 같은 할당을 입력합니다.
    • 그룹 할당: 그룹 할당의 이름입니다. 이는 JWT 클레임에서 사용자의 사용자 그룹을 설정하는 데 사용됩니다. 예: groups.

    외부 ID 제공자 구성

    LDAPS
    회사의 LDAPS 서버 세부 정보를 입력합니다. LDAPS 끝점을 제외한 모든 설정은 선택 사항입니다.
    • LDAPS 끝점: LDAPS 서버의 IP 또는 DNS 주소입니다. LDAP 서버의 주소와 포트를 host:port 형식으로 입력합니다.
    • Bind DN: 애플리케이션 서비스 계정의 DN입니다. 커넥터는 이러한 자격 증명을 사용하여 사용자와 그룹을 검색합니다. LDAP 서버가 익명 인증에 대한 액세스를 제공하는 경우에는 필요하지 않습니다.
    • 바인딩 암호: Bind DN이 설정된 경우 애플리케이션 서비스 계정의 암호입니다.

    사용자 검색 특성을 제공합니다.

    • 기본 DN: LDAP 검색을 시작할 지점입니다. 예: OU=Users,OU=domain,DC=io.
    • 필터: LDAP 검색에서 사용할 선택적 필터입니다.
    • 사용자 이름: 사용자 ID가 포함된 LDAP 특성입니다. 예: uid, sAMAccountName.

    그룹 검색 특성을 입력합니다.

    • 기본 DN: LDAP 검색을 시작할 지점입니다. 예: OU=Groups,OU=domain,DC=io.
    • 필터: LDAP 검색에서 사용할 선택적 필터입니다.
    • 이름 특성: 그룹의 이름을 가지고 있는 LDAP 특성입니다. 예: cn.
    • 사용자 특성: 그룹 레코드의 멤버 자격 특성 값으로 사용되는 사용자 레코드의 특성입니다. 예: distinguishedName, dn.
    • 그룹 특성: 사용자/멤버 정보를 유지하는 그룹 레코드의 특성입니다. 예: member.

    LDAPS 서버 CA 인증서의 컨텐츠를 ROOT CA 텍스트 상자에 붙여 넣습니다.

    외부 ID 제공자 구성

    (선택 사항) LDAP 설정을 확인합니다.

    1. LDAP 구성 확인 옵션을 클릭합니다.

    2. 사용자 이름과 그룹 이름을 입력합니다.

      참고

      Tanzu Kubernetes Grid v1.4.x 이상에서는 이러한 필드가 무시되고 사용자 이름이 cn으로, 그룹 이름이 ou로 되돌아갑니다. 이 알려진 문제에 대한 업데이트는 VMware Tanzu Kubernetes Grid 1.5 Release Notes 를 참조하십시오.

    3. 시작을 클릭합니다.

      확인 후 오류가 표시되면 이후 단계에서 면밀히 확인해야 합니다.

      참고

      LDAP 호스트는 관리 클러스터 노드가 아닌 이 점검을 수행합니다. 따라서 이 확인이 실패하더라도 LDAP 구성이 작동할 수 있습니다.

  3. 다음을 클릭하여 기본 OS 이미지 선택으로 이동합니다.

기본 OS 이미지 선택

OS 이미지 섹션에서 드롭다운 메뉴를 사용하여 Tanzu Kubernetes Grid VM 배포에 사용할 OS와 Kubernetes 버전 이미지 템플릿을 선택하고 다음을 클릭합니다.

기본 OS 이미지 선택 항목이 생성되는 방법

OS 이미지 드롭다운 메뉴에는 다음 조건을 모두 충족하는 OS 이미지가 포함됩니다.

  • 이미지는 IaaS에서 사용할 수 있습니다.
    • vSphere에서 기본 이미지 템플릿을 vSphere로 가져오기에 설명된 대로 이미지를 가져와야 합니다. 설치 관리자 인터페이스를 종료하지 않고 이미지를 지금 가져올 수 있습니다. 가져온 후 새로 고침 버튼을 사용하여 드롭다운 메뉴에 표시합니다.
    • Azure에서는 Microsoft Azure에 관리 클러스터 배포 준비의 기본 이미지 라이센스 수락에 설명된 대로 라이센스를 수락해야 합니다.
  • OS 이미지는 관리 클러스터가 실행되는 Kubernetes 버전의 TKr(Tanzu Kubernetes 릴리스의 BoM) 파일에 나열됩니다.
    • Tanzu Kubernetes Grid v2.3 관리 클러스터는 Kubernetes v1.26.8에서 실행됩니다.
    • 사용자 지정 이미지를 사용하려면 시스템 이미지 빌드에 설명된 대로 TKr의 BoM 파일을 수정하여 이미지를 나열합니다.
    • vSphere, AWS, Azure 이미지는 BoM의 ova, ami, azure 블록에 각각 나열됩니다.
  • IaaS의 이미지 이름은 TKr BoM의 식별자와 일치합니다.
    • vSphere, AWS, Azure 이미지는 각각 version, id, sku 필드 값으로 식별됩니다.

배포 마무리

이 섹션은 모든 대상 플랫폼에 대해 동일합니다.

  1. CEIP 참여(CEIP Participation) 섹션에서 선택적으로 이 확인란의 선택을 취소하여 VMware 고객 환경 향상 프로그램에서 옵트아웃하고 다음(Next)을 클릭합니다.

    관리 클러스터를 배포한 후 프로그램을 옵트인하거나 옵트아웃할 수도 있습니다. CEIP에 대한 자세한 내용은 CEIP에 참여 관리 및 https://www.vmware.com/solutions/trustvmware/ceip.html을 참조하십시오.

  2. 구성 검토를 클릭하여 구성한 관리 클러스터의 세부 정보를 확인합니다. 설치 관리자 마법사로 돌아가 구성을 수정하려면 구성 편집을 클릭합니다.

    구성 검토를 클릭하면 설치 관리자는 ~/.config/tanzu/tkg/clusterconfigs 하위 디렉토리에 있는 클러스터 구성 파일을 인터페이스에 지정한 설정으로 채웁니다. 필요한 경우 구성 내보내기를 클릭하여 이 구성 파일의 복사본을 내보낼 수 있습니다.

  3. 관리 클러스터 배포를 클릭합니다.

    관리 클러스터를 배포하는 데 몇 분 정도 걸릴 수 있습니다. tanzu mc create의 첫 번째 실행은 필요한 Docker 이미지를 부트스트랩 시스템의 이미지 저장소로 끌어와야 하기 때문에 후속 실행보다 오래 걸립니다. 이후 실행에서는 이 단계가 필요하지 않으므로 더 빠릅니다. 설치 관리자 인터페이스 또는 tanzu mc create --ui를 실행한 터미널에서 관리 클러스터 배포의 진행률을 확인할 수 있습니다. tanzu mc create를 실행하는 시스템이 로컬 작업이 완료되기 전에 종료되거나 다시 시작되면 배포가 실패합니다. 배포가 완료되기 전에 실행 중인 브라우저 또는 브라우저 탭을 실수로 닫으면 터미널에서 배포가 계속됩니다.

    관리 클러스터 배포 모니터링

  4. (선택 사항) CLI 명령과 동일에서 복사 버튼을 클릭하여 지정한 구성에 CLI 명령을 복사합니다. 이 CLI 명령에는 설치 관리자가 입력한 구성 파일의 경로가 포함됩니다.

  5. (vSphere 전용) 관리 클러스터를 vSphere에 배포한 후 클러스터가 배포된 후 제어부 노드의 DHCP 예약 구성(vSphere만 해당)에 설명된 대로 해당 제어부 노드의 IP 주소를 고정으로 구성해야 합니다.

후속 작업

  • 구성 파일 저장: 설치 관리자는 관리 클러스터의 구성을 ~/.config/tanzu/tkg/clusterconfigs UNIQUE-ID.yaml 형식의 생성된 파일 이름으로 저장합니다. 이 구성 파일은 CLUSTER_NAME과 같은 대문자 밑줄 변수를 설정하는 플랫 구조를 가지고 있습니다. 배포가 완료된 후 필요에 따라 구성 파일의 이름을 기억에 남는 이름으로 변경하고 나중에 사용할 수 있도록 다른 위치에 저장할 수 있습니다. 또한 설치 관리자는 관리 클러스터의 Cluster 개체를 위한 Kubernetes 스타일의 클래스 기반 개체 규격을 생성합니다. 이 규격은 관리 클러스터와 동일한 이름을 가진 파일에 저장됩니다. 이 클래스 기반 개체 규격은 참고용으로만 제공됩니다. 클래스 기반 개체 규격에서 관리 클러스터를 배포하는 것은 아직 지원되지 않습니다. TKG 2.x의 클러스터 유형에 대한 자세한 내용은 Tanzu Kubernetes Grid 정보의 워크로드 클러스터를 참조하십시오.
  • ID 관리 구성: 관리 클러스터용 OIDC 또는 LDAP ID 관리를 사용하도록 설정한 경우 ID 관리 구성 완료에 설명된 배포 후 단계를 수행하여 액세스를 사용하도록 설정해야 합니다.
  • Tanzu Mission Control에 관리 클러스터 등록: 관리 클러스터를 Tanzu Mission Control에 등록하려면 Tanzu Mission Control에 관리 클러스터 등록을 참조하십시오.
  • 워크로드 클러스터 배포: 관리 클러스터가 생성되면 Tanzu CLI를 사용하여 TKG 2.3 워크로드 클러스터 생성 및 관리의 워크로드 클러스터 생성에 설명된 대로 워크로드 클러스터를 배포할 수 있습니다.
  • 또 다른 관리 클러스터 배포: 둘 이상의 관리 클러스터를 vSphere, Azure, AWS의 하나 또는 전부에 배포하려면 관리 클러스터 관리를 참조하십시오. 이 항목에서는 기존 관리 클러스터를 CLI 인스턴스에 추가하고, 자격 증명을 획득하고, 관리 클러스터를 확장/삭제하고, 네임스페이스를 추가하고, CEIP를 옵트인하거나 옵트아웃하는 방법에 대한 정보도 제공합니다.

관리 클러스터를 배포하는 동안 일어나는 일과 kubectl을 관리 클러스터에 연결하는 방법에 대한 자세한 내용은 새로 배포된 독립형 관리 클러스터 검사 및 등록을 참조하십시오.

check-circle-line exclamation-circle-line close-line
Scroll to top icon