RSS
 

워크로드 클러스터 구성

이 항목에서는 Tanzu CLI를 사용하여 워크로드 클러스터를 배포할 때 워크로드 클러스터를 구성하는 방법을 설명합니다.

워크로드 클러스터를 구성하는 방법은 아래 섹션에 설명된 대로 클러스터 유형에 따라 다릅니다. 워크로드 클러스터 유형을 참조하십시오.

  • 클래스 기반 클러스터는 Cluster 개체에 Kubernetes 스타일 개체 규격을 사용합니다.

    • 또한 고급 사용자 지정을 위해 ClusterBootstrap 및 참조하는 개체에 규격이 필요할 수도 있습니다.

  • TKC 클러스터는 CLUSTER_NAME과 같은 대문자 밑줄 변수를 설정하는 플랫 구조의 클러스터 구성 파일을 사용합니다.

    • 워크로드 클러스터 또는 클러스터 계획을 사용자 지정하려면 고급 사용자 지정을 위해 계층 오버레이가 필요할 수 있습니다.

두 가지 유형의 클러스터 모두에 대해 새 클러스터를 생성하거나 클러스터의 개체 규격에 전달하여 kubectl apply를 실행하여 기존 클러스터의 구성을 수정할 수도 있습니다.

클래스 기반 워크로드 클러스터 구성

다른 Kubernetes 개체와 마찬가지로 개체 규격을 생성하고 편집하여 클래스 기반 워크로드 클러스터를 구성합니다. 클러스터 개체의 경우 다음과 같습니다.

  • Cluster 개체: 클러스터 토폴로지와 같은 대부분의 클러스터 옵션을 구성합니다. 실행 중인 클러스터의 구성을 변경하기 위해 이 개체 규격을 변경하고 다시 적용할 수 있습니다.
  • (선택 사항) ClusterBootstrap 개체: CNI(컨테이너 네트워크 인터페이스) 및 CSI(컨테이너 스토리지 인터페이스)와 같이 클러스터를 처음 생성할 때만 적용되고 실행 중인 클러스터에서 재구성할 수 없는 기본값이 아닌 옵션을 구성합니다. 자세한 내용은 일회성 인프라 설정 구성을 참조하십시오.

클래스 기반 클러스터 예

vSphere 8 설명서에는 클래스 기반 클러스터의 개체 규격 예시가 포함되어 있습니다.

클래스 기반 클러스터 개체 및 토폴로지 구조

Cluster 개체에서 구성할 수 있는 최상위 설정은 다음과 같이 구성됩니다. 구성할 수 있는 variables는 ClusterClass 토폴로지 변수를 참조하십시오.

clusterNetwork
  apiServerPort
  services
    CIDRBlocks
  pods
    CIDRBlocks
  serviceDomain
controlPlaneEndpoint
  host
  port
topology
  class
  version
  rolloutAfter
  controlPlane
    metadata
      annotations
    replicas
    nodeDrainTimeout
    nodeDeletionTimeout
    machineHealthCheck
      maxUnhealthy
      nodeStartupTimeout
      unhealthyConditions
  workers
    machineDeployments
      metadata
      class
      - class: node-pool
      name
      failureDomain
      replicas
      nodeDrainTimeout
      nodeDeletionTimeout
      machineHealthCheck
        maxUnhealthy
        nodeStartupTimeout
        unhealthyConditions
      variables
        name
        value
  variables
    name
    value

이러한 필드는 Tanzu Framework 저장소 cluster_types.go 의 Cluster 개체 유형 규격에 설정됩니다.

  • 선택적 필드: 각 필드의 json: 설정은 필드가 선택 사항인지 여부를 나타냅니다. 선택적 필드에는 omitempty 설정이 있습니다.
  • 유형 규격의 참조에 의해 중첩된 구조는 개체 규격 YAML에 들여쓰기됩니다. 예를 들어 Topology 구조체에는 유형 규격에 *Workers가 포함되므로 workers 개체 규격의 topology 아래에 들여쓰기됩니다.

node-pool 클래스 및 variables 옵션은 클러스터의 spec.topology.class 값으로 설정된 Cluster 개체의 클러스터 클래스에 정의됩니다. 기본적으로 TKG 2에서 이 개체는 워크로드 클러스터 유형에 설명된 TanzuKubernetesCluster와는 다른 tanzukubernetescluster라는 ClusterClass 개체입니다.

구성 가능한 variables에는 vmClass, storageClass, proxy, nodeLabels, extensionCert 및 기타 여러 가지 변수가 포함되며, ClusterClass 토폴로지 변수를 참조하십시오. 이러한 변수는 클러스터 개체의 기초가 되는 개체(예: KubeAdmConfig 및 Machine 개체)의 설정을 구성하고 재정의합니다.

ClusterClass 토폴로지 변수

TKG 2 워크로드 클러스터의 기본 ClusterClass인 tanzukubernetescluster 클래스는 topology.variables 및 topology.workers.machineDeployments.variables에 설정된 다음 변수를 지원합니다. 노드 풀과 같은 시스템 배포와 관련된 변수 설정은 글로벌 설정을 재정의합니다.

이러한 변수는 vmClass 및 storageClass 개체에 설정된 proxy, KubeAdmConfig, Machine 설정과 같이 클러스터 개체의 기본이 되는 개체의 설정을 구성하고 재정의합니다. 이를 통해 사용자는 하위 수준 개체 규격을 편집하지 않고도 Cluster 개체 규격 내에서 클러스터를 완전히 구성할 수 있습니다.

  • clusterEncryptionConfigYaml
  • controlPlaneVolumes
  • defaultRegistrySecret
  • defaultStorageClass
  • extensionCert
  • nodePoolLabels
  • nodePoolTaints
  • nodePoolVolumes
  • ntp
  • proxy
  • storageClass
  • storageClasses
  • TKR_DATA
  • trust
  • user
  • vmClass

vSphere 8 설명서의 다음 항목에서는 storageClass 및 vmClass 설정을 변경하여 실행 중인 클러스터를 재구성하는 방법을 설명합니다.

구현 참고: ClusterClass 개체 규격에서 variables 및 patches 블록은 변수와 변수의 처리 방식을 정의합니다.

  • variables 정의는 기본 개체 설정에 직접 해당합니다.
  • patches 정의는 Sprig 함수 및 jsonPatch 규칙을 적용하여 구성 설정을 보다 복잡한 변경 집합으로 변환합니다.

일회성 인프라 설정 구성

Cluster 개체 규격에서 가장 일반적인 클러스터 설정을 구성할 수 있지만 일부 클러스터 구성 요소는 노드의 기반이 되는 TKr(Tanzu Kubernetes 릴리스)에서 가져옵니다. 예를 들어, TKr은 클러스터가 사용하는 CNI(Container Network Interface), CSI(Container Storage Interface) 및 Pinniped 버전을 지정합니다.

ClusterBootstrap 개체에 의해 클러스터 생성 시 적용되고 실행 중인 클러스터에서는 변경할 수 없는 이러한 인프라 수준 옵션입니다. 클러스터를 생성하기 전에 이러한 옵션을 구성하는 일반적인 절차는 다음과 동일합니다.

  1. ClusterBootstrap 개체 및 참조하는 모든 사용자 지정 개체(예: CalicoConfig 개체)의 개체 규격을 생성합니다.

  2. Cluster 개체 자체의 개체 규격을 생성합니다.

  3. 모든 개체 규격의 metadata는 생성하려는 클러스터의 이름 및 네임스페이스를 포함합니다. 예:

    apiVersion: run.tanzu.vmware.com/v1alpha3
kind: ClusterBootstrap
metadata:
  name: MY-CLUSTER
  namespace: MY-NAMESPACE

    사용자 지정에는 주석과 같은 추가 메타데이터가 필요할 수 있습니다.

  4. Cluster 정의를 포함한 모든 개체 규격을 단일 파일로 연결합니다. 규격을 3개의 대시(---)로 구성된 줄로 구분합니다.

  5. 개체 규격을 kubectl apply -f 옵션으로 전달합니다. 예를 들면 다음과 같습니다.

    kubectl config use-context SUPERVISOR-IP

    kubectl apply -f my-custom-cluster-objects.yaml

    여기서 SUPERVISOR-IP는 Supervisor의 컨텍스트입니다. vSphere with Tanzu 서비스 및 워크로드에서 Supervisor 컨텍스트 가져오기 및 사용을 참조하십시오.

대체 방법: 마지막 두 단계 대신 Cluster 개체를 제외한 모든 개체 규격에 kubectl apply -f를 실행한 다음 Cluster 개체 규격을 사용하여 tanzu cluster create -f를 실행할 수 있습니다.

이 절차의 특정 예를 보려면 클러스터의 CNI를 Calico로 설정하는 기본이 아닌 CNI를 사용하여 클러스터 생성을 참조하십시오.

구성 파일을 사용하여 TKC 클러스터 구성

TKC 기반 워크로드 클러스터를 생성하려면 변수를 설정하여 스토리지 클래스, VM 클래스, 서비스 도메인, 네임스페이스, 클러스터를 생성하는 데 필요한 기타 값을 정의합니다.

다음 표에는 TKC 기반 클러스터의 구성 파일에 포함할 수 있는 변수가 나열되어 있습니다. 또는 아래에 설명된 대로 로컬 환경 변수로 설정할 수 있습니다.

필수 변수
변수 값 유형 또는 예 설명
INFRASTRUCTURE_PROVIDER tkg-service-vsphere 항상 vSphere with Tanzu에서 TanzuKubernetesCluster 개체에 대한 tkg-service-vsphere.
CLUSTER_PLAN dev, prod 또는 사용자 지정 계획 노드 수를 설정합니다.
CLUSTER_CIDR CIDR 범위 포드에 사용할 CIDR 범위. 권장 범위는 100.96.0.0/11입니다. 권장 범위를 사용할 수 없는 경우에만 이 값을 변경합니다.
SERVICE_CIDR Kubernetes 서비스에 사용할 CIDR 범위. 권장 범위는 100.64.0.0/13입니다. 권장 범위를 사용할 수 없는 경우에만 이 값을 변경합니다.
SERVICE_DOMAIN 도메인 예: DNS가 없는 경우 my.example.com 또는 cluster.local. 노드에 FQDN을 할당하려는 경우 DNS 조회가 필요합니다.
CONTROL_PLANE_VM_CLASS vSphere with Tanzu 표준 VM 클래스(예: guaranteed-large).
vSphere with Tanzu 설명서에서 Supervisor에서 TKG 클러스터와 함께 가상 시스템 클래스 사용을 참조하십시오.		 제어부 노드의 VM 클래스
WORKER_VM_CLASS Worker 노드의 VM 클래스
선택적 변수
변수 값 유형 또는 예 설명
CLUSTER_NAME 문자열 CLUSTER-NAME 인수에 의해 재정의되어 tanzu cluster create로 전달됩니다.
이 이름은 RFC 952에 설명된 DNS 호스트 이름 요구 사항을 준수하고 RFC 1123에 수정된 DNS 호스트 이름 요구 사항을 준수해야 하며 42자 이하여야 합니다.
NAMESPACE 네임스페이스. 기본값은 default입니다. 클러스터를 배포할 네임스페이스입니다. Supervisor의 네임스페이스를 찾으려면 kubectl get namespaces를 실행합니다.
CNI antrea 또는 calico. 기본값: antrea 호스팅된 워크로드에 대한 컨테이너 네트워킹 인터페이스(Antrea 또는 Calico).
CONTROL_PLANE_MACHINE_COUNT 정수. CONTROL_PLANE_MACHINE_COUNT는 홀수여야 합니다.
기본값은 CLUSTER_PLAN에서 설정된 대로 dev의 경우 1, prod의 경우 3입니다.		 dev 또는 prod 계획 기본값보다 더 많은 제어부 노드가 있는 워크로드 클러스터를 배포합니다.
WORKER_MACHINE_COUNT Worker 노드가 dev 또는 prod 계획 기본값보다 많은 워크로드 클러스터를 배포합니다.
STORAGE_CLASSES 빈 문자열 ““를 사용하면 클러스터가 네임스페이스의 모든 스토리지 클래스를 사용하거나 kubectl get storageclasses의 쉼표로 구분된 값 문자열을 사용할 수 있습니다(예: “SC-1,SC-2,SC-3” 노드 사용자 지정에 사용할 수 있는 스토리지 클래스
DEFAULT_STORAGE_CLASS 위에서와 같이 기본값이 없는 경우 빈 문자열 ”” 또는 CLI의 값. 제어부 또는 Worker의 기본 스토리지 클래스
CONTROL_PLANE_STORAGE_CLASS kubectl get storageclasses에서 반환된 값 제어부 노드의 기본 스토리지 클래스
WORKER_STORAGE_CLASS Worker 노드의 기본 스토리지 클래스
NODE_POOL_0_NAME 문자열 노드 풀 이름, 레이블, taint. TanzuKubernetesCluster는 하나의 노드 풀만 있을 수 있습니다.
NODE_POOL_0_LABELS 문자열의 JSON 목록(예: [“label1”, “label2”])
NODE_POOL_0_TAINTS 키-값 쌍 문자열의 JSON 목록(예: [{“key1”: “value1”}, {“key2”: “value2”}]

다음 중 하나를 수행하여 위의 변수를 설정할 수 있습니다.

  • tanzu CLI --file 옵션으로 전달된 클러스터 구성 파일에 포함합니다. 예:

    CONTROL_PLANE_VM_CLASS: guaranteed-large

  • 명령줄에서 export(Linux 및 macOS) 또는 SET(Windows)을 실행하여 로컬 환경 변수로 설정합니다. 예:

    export CONTROL_PLANE_VM_CLASS=guaranteed-large

    참고: 워크로드 클러스터의 고유한 프록시 설정을 구성하려는 경우 TKG_HTTP_PROXY, TKG_HTTPS_PROXY, NO_PROXY를 환경 변수로 설정한 다음 Tanzu CLI를 사용하여 클러스터를 생성할 수 있습니다. 이러한 변수는 vSphere with Tanzu의 기존 프록시 구성보다 우선합니다.

노드 크기

Tanzu CLI는 구성 파일에 제공하는 설정에 따라 워크로드 클러스터의 개별 노드를 생성합니다. 모든 노드 VM이 동일한 크기를 가지도록 구성하거나 제어부 및 Worker 노드에 다른 크기를 설정할 수 있습니다.

Tanzu CLI는 클러스터 노드에 대해 다음과 같은 미리 정의된 구성을 제공합니다.

  • small: CPU 2개, 4GB 메모리, 20GB 디스크
  • medium: CPU 2개, 8 GB 메모리, 40 GB 디스크
  • large: CPU 4개, 16 GB 메모리, 40 GB 디스크
  • extra-large: CPU 8개, 32 GB 메모리, 80 GB 디스크

모든 제어부 및 Worker 노드 VM의 크기가 동일한 클러스터를 생성하려면 SIZE 변수를 지정합니다. SIZE 변수를 설정하면 모든 노드가 사용자가 설정한 구성으로 생성됩니다.

SIZE: "large"

제어부 및 Worker 노드 VM의 크기가 다른 클러스터를 생성하려면 CONTROLPLANE_SIZE 및 WORKER_SIZE 옵션을 지정합니다.

CONTROLPLANE_SIZE: "medium"
WORKER_SIZE: "extra-large"

CONTROLPLANE_SIZE 및 WORKER_SIZE 옵션을 SIZE 옵션과 결합할 수 있습니다. 예를 들어 SIZE: "large"를 WORKER_SIZE: "extra-large"와 함께 지정하면 제어부 노드는 large로 설정되고 Worker 노드는 extra-large로 설정됩니다.

SIZE: "large"
WORKER_SIZE: "extra-large"

최소 노드 크기

클러스터 복잡성 및 예상 요구량에 따라 워크로드 클러스터 노드의 크기를 구성합니다. 위의 노드 크기에 정의된 대로 small, medium, large 또는 extra-large로 설정할 수 있습니다.

샘플 애플리케이션을 실행하는 단일 Worker 워크로드 클러스터의 경우 다음과 같은 최소 VM 크기를 사용합니다.

  • 서비스가 설치되지 않음: small
  • 설치된 기본 서비스(Wavefront, Fluent Bit, Contour, Envoy, TMC 에이전트): medium

TKC 구성 예

다음 섹션에서는 구성 변수를 사용하여 TKC 워크로드 클러스터를 구성하는 일반적인 예를 보여 줍니다.

사용자 지정 제어부 및 Worker 노드 수가 포함된 워크로드 클러스터

클러스터 구성 파일에서 CLUSTER_PLAN을 dev 또는 prod로 설정하면 클러스터의 노드 수가 설정됩니다.

  • dev 계획: 제어부 노드 1개와 Worker 노드 1개.
  • prod 계획: 제어부 노드 3개와 Worker 노드 3개.

예를 들어 클러스터 구성 파일에서 다음을 수행합니다.

CLUSTER_PLAN: prod

기본적으로 정의되는 dev 및 prod 계획보다 더 많은 제어부 노드가 있는 워크로드 클러스터를 배포하려면 클러스터 구성 파일에 CONTROL_PLANE_MACHINE_COUNT 변수를 지정합니다. CONTROL_PLANE_MACHINE_COUNT에 지정하는 제어부 노드 수는 균등하지 않아야 합니다.

CONTROL_PLANE_MACHINE_COUNT: 5

WORKER_MACHINE_COUNT 변수에서 클러스터의 Worker 노드 수를 지정합니다. 예:

WORKER_MACHINE_COUNT: 10

특정 네임스페이스의 워크로드 클러스터

Tanzu Kubernetes Grid 인스턴스에서 네임스페이스를 생성한 경우 NAMESPACE 변수를 지정하여 워크로드 클러스터를 해당 네임스페이스에 배포할 수 있습니다. NAMESPACE 변수를 지정하지 않으면 Tanzu Kubernetes Grid는 클러스터를 default 네임스페이스에 배치합니다. 명령을 실행하기 전에 NAMESPACE 변수에서 식별하는 모든 네임스페이스가 있어야 합니다.

전용 네임스페이스에 서로 다른 유형의 클러스터를 생성할 수 있습니다. 예:

NAMESPACE: production

참고: 모든 네임스페이스의 모든 워크로드 클러스터에 고유한 이름을 제공해야 합니다. 다른 네임스페이스에서 사용 중인 클러스터 이름을 지정하면 클러스터 배포가 오류와 함께 실패합니다.

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