새 설치 모델로 사용자 클러스터 만들기

이 문서에서는 VMware용 Anthos 클러스터 버전 1.13(GKE On-Prem)에서 미리보기 기능으로 사용할 수 있는 새 설치 모델을 사용하는 사용자 클러스터를 만드는 방법을 보여줍니다.

kubeception이란 무엇인가요?

kubeception은 Kubernetes 클러스터를 사용하여 다른 Kubernetes 클러스터를 만들고 관리하는 아이디어를 나타내는 용어입니다. VMware용 Anthos 클러스터와 관련하여 kubeception은 사용자 클러스터의 제어 영역이 관리자 클러스터의 하나 이상의 노드에서 실행되는 경우를 나타냅니다.

버전 1.13.0부터 사용자 클러스터의 제어 영역에서 사용자 클러스터 자체의 노드 한 개 이상에서 실행할 수 있습니다. 이전 버전의 VMware용 Anthos 클러스터에서는 kubeception이 유일한 옵션입니다. 즉, 모든 사용자 클러스터의 관리자 클러스터에 제어 영역이 있었습니다.

새 설치 모델은 관리자 및 사용자 클러스터 사이에 아키텍처 일관성을 제공하고 사용자 클러스터를 관리자 클러스터와 분리합니다. 이렇게 하면 서로 다른 지리적 사이트에서 클러스터를 실행할 때와 같은 시나리오에 이점이 있습니다.

시작하기 전에

관리자 클러스터가 있어야 하고 관리자 클러스터 버전이 1.13.0 이상이어야 합니다.

IP 주소 계획

사용자 클러스터의 IP 주소를 계획할 때는 새 설치 모델에 대해 다음 요구사항을 주의해야 합니다.

  • 사용자 클러스터의 제어 영역 노드는 사용자가 제공하는 고정 주소 목록에서 IP를 가져와야 합니다. 이는 워커 노드가 DHCP 서버에서 주소를 가져올 경우에도 마찬가지입니다. 고가용성(HA) 사용자 클러스터에는 제어 영역 노드 3개가 필요하고 HA가 아닌 사용자 클러스터에는 제어 영역 노드가 1개만 필요합니다.

  • 사용자 클러스터 제어 영역 노드는 사용자 클러스터 워커 노드와 동일한 VLAN에 있어야 합니다. 이는 kubeception 모델과 대조됩니다.

  • 사용자 클러스터 제어 영역 VIP는 사용자 클러스터 워커 노드 및 사용자 클러스터 제어 영역 노드와 동일한 VLAN에 있어야 합니다. 이는 kubeception 모델과 대조됩니다.

vSphere 환경 계획

관리자 클러스터 구성 파일과 사용자 클러스터 구성 파일 모두에는 관리자 또는 사용자 클러스터에서 사용할 vSphere 리소스를 지정할 수 있는 vCenter 섹션이 있습니다.

사용자 클러스터의 경우 기본적으로 관리자 클러스터와 동일한 vSphere 리소스를 사용하므로 사용자 클러스터의 경우 vCenter 섹션을 작성할 필요가 없습니다. 그러나 관리자 클러스터에 대해 지정한 것과 다른 vSphere 리소스를 사용자 클러스터서에 사용하도록 하려면 사용자 클러스터 구성 파일의 vCenter 섹션에서 원하는 필드를 입력할 수 있습니다. 자세한 내용은 vSphere 객체 계층 구조 설정을 참조하세요.

새 설치 모델에서 사용자 클러스터의 제어 영역 노드는 사용자 클러스터 자체에 있습니다. 따라서 제어 영역 노드는 사용자 클러스터 구성 파일에 지정된 vSphere 리소스를 사용합니다. 예를 들어 관리자 클러스터에 datacenter-1을 지정하고 사용자 클러스터에 datacenter-2를 지정한다고 가정해 보겠습니다. 사용자 클러스터의 제어 영역 노드는 datacenter-2에 배치됩니다.

안티어피니티 그룹

관리자 클러스터 구성 파일과 사용자 클러스터 구성 파일 모두에는 true 또는 false로 설정할 수 있는 antiAffinityGroups.enabled 필드가 있습니다.

새 설치 모델에서 사용자 클러스터의 제어 영역 노드는 사용자 클러스터 구성 파일에 있는 antiAffinityGroups.enabled 값에 따라 배포됩니다.

반대로 kubeception 모델과 함께 사용자 클러스터의 제어 영역 노드는 관리자 클러스터 구성 파일의 antiAffinityGroups.enabled 값에 따라 배포됩니다.

예

여기에 표시된 사용자 클러스터 예시는 다음 특성을 갖습니다.

  • 워커 노드가 3개 있습니다.

  • 워커 노드에 고정 IP 주소가 사용됩니다.

  • 제어 영역 노드가 3개 있습니다. 즉, HA 클러스터입니다.

  • 부하 분산기는 MetalLB입니다.

  • 사용자 클러스터에 관리자 클러스터와 동일한 vSphere 리소스가 사용됩니다.

다음 다이어그램은 관리자 및 사용자 클러스터의 네트워크를 보여줍니다.

관리자 클러스터 및 사용자 클러스터
관리자 클러스터 및 사용자 클러스터(확대하려면 클릭)

다음은 IP 블록 파일의 예시와 사용자 클러스터 구성 파일의 일부입니다.

user-ipblock.yaml

blocks:
  - netmask: 255.255.255.0
    gateway: 172.16.21.1
    ips:
    - ip: 172.16.21.2
      hostname: worker-vm-1
    - ip: 172.16.21.3
      hostname: worker-vm-2
    - ip: 172.16.21.4
      hostname: worker-vm-3
    - ip: 172.16.21.5
      hostname: worker-vm-4

user-cluster.yaml

apiVersion: v1
kind: UserCluster
...
kubeception: false
network:
  hostConfig:
    dnsServers:
    - "203.0.113.2"
    - "198.51.100.2"
    ntpServers:
    - "216.239.35.4"
  ipMode:
    type: "static"
    ipBlockFilePath: "user-ipblock.yaml"
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "172.16.21.1"
    ips:
    - ip: "172.16.21.6"
      hostname: "cp-vm-1"
    - ip: "172.16.21.7"
      hostname: "cp-vm-2"
    - ip: "172.16.21.8"
      hostname: "cp-vm-3"
loadBalancer:
  vips:
    controlPlaneVIP: "172.16.21.40"
    ingressVIP: "172.16.21.30"
  kind: MetalLB
  metalLB:
    addressPools:
    - name: "address-pool-1"
      addresses:
    - "172.16.21.30-172.16.21.39"
...
masterNode:
  cpus: 4
  memoryMB: 8192
  replicas: 3
nodePools:
- name: "worker-node-pool"
  enableLoadBalancer: true

앞의 예시에서 이해가 필요한 중요 부분은 다음과 같습니다.

  • 워커 노드의 고정 IP 주소는 IP 블록 파일에 지정됩니다. 워커 노드가 3개뿐인데도 IP 블록 파일은 주소가 4개입니다. 추가 IP 주소는 클러스터 업그레이드, 업데이트, 자동 복구 중에 필요합니다.

  • 3개의 제어 영역 노드에 대한 고정 IP 주소는 사용자 클러스터 구성 파일의 network.controlPlaneIPBlock 섹션에 지정됩니다. 이 블록에는 추가 IP 주소가 필요하지 않습니다.

  • masterNode.replicas 필드는 3으로 설정됩니다.

  • 제어 영역 VIP와 인그레스 VIP는 모두 워커 노드 및 제어 영역 노드와 동일한 VLAN에 있습니다.

  • LoadBalancer 유형의 서비스를 위해 설정된 VIP는 사용자 클러스터 구성 파일의 loadBalancer.metalLB.addressPools 섹션에 지정됩니다. 이러한 VIP는 워커 노드 및 제어 영역 노드와 동일한 VLAN에 있습니다.

  • 사용자 클러스터 구성 파일에는 vCenter 섹션이 없습니다. 따라서 사용자 클러스터에 관리자 클러스터와 동일한 vSphere 리소스가 사용됩니다.

방화벽 규칙 만들기

표준 방화벽 규칙 외에도 다음 방화벽 규칙을 필요에 따라 만듭니다.

From

소스 포트

To

Dst 포트

프로토콜

설명

관리자 클러스터 노드

전체

사용자 클러스터 제어 영역 VIP

443

https

관리자 클러스터의 노드 및 포드가 사용자 클러스터의 Kubernetes API 서버와 통신할 수 있도록 합니다.

관리자 클러스터 노드

전체

사용자 클러스터 제어 영역 노드

443

https

사용자 클러스터 제어 영역 노드의 IP 주소를 사용하여 관리자 클러스터의 노드와 포드가 사용자 클러스터의 Kubernetes API 서버와 통신할 수 있도록 합니다.

관리자 클러스터 노드

전체

사용자 클러스터 vCenter Server

443

https

관리자 클러스터가 사용자 클러스터의 수명 주기를 관리하도록 허용합니다. 관리자 클러스터 구성 파일에서 vCenter 주소와 다른 vCenter.address 값을 지정한 경우에 필요합니다.

사용자 클러스터 제어 영역 노드

1024 - 65535

온프레미스 로컬 Docker 레지스트리

레지스트리에 따라 달라집니다.

TCP/https

관리자 클러스터 구성 파일에서 비공개 레지스트리를 지정한 경우에 필요합니다.

새 모델로 사용자 클러스터 만들기

이 섹션에서는 새 설치 모델을 사용하는 사용자 클러스터를 만드는 방법을 보여줍니다. 이 예시에서 사용자 클러스터는 관리자 클러스터와 동일한 vCenter Server 인스턴스를 사용합니다.

사용자 클러스터 만들기의 안내를 따릅니다.

사용자 클러스터 구성 파일을 입력할 때 다음을 수행합니다.

  • kubeception를 false로 설정합니다.

  • vCenter.address 값을 지정하지 않습니다.

  • network.controlPlaneIPBlock 섹션을 입력합니다. HA 사용자 클러스터가 필요하면 3개의 IP 주소를 지정합니다. 그렇지 않으면 IP 주소를 1개 지정합니다.

사용자 클러스터가 실행될 때 제어 영역이 사용자 클러스터의 1개 또는 3개 노드에서 실행되는지 확인합니다.

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get nodes

USER_CLUSTER_KUBECONFIG를 사용자 클러스터 kubeconfig 파일 경로로 바꿉니다.

출력은 워커 노드와 함께 1개 또는 3개의 제어 영역 노드를 보여줍니다. 예를 들면 다음과 같습니다.

cp-vm-1       Ready    control-plane,master   18m
cp-vm-2       Ready    control-plane,master   18m
cp-vm-3       Ready    control-plane,master   18m
worker-vm-1   Ready                           6m7s
worker-vm-2   Ready                           6m6s
worker-vm-3   Ready                           6m14s

사용자 클러스터의 제어 영역이 관리자 클러스터에서 실행되지 않는지 확인합니다.

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get nodes --output wide

ADMIN_CLUSTER_KUBECONFIG를 관리자 클러스터 kubeconfig 파일의 경로로 바꿉니다.

출력은 관리자 클러스터 자체의 제어 영역 노드를 보여줍니다. 그러나 사용자 클러스터의 제어 영역 노드를 표시하지 않습니다. 예를 들면 다음과 같습니다.

admin-vm-1   Ready    control-plane,master   82m
admin-vm-2   Ready                           71m
admin-vm-3   Ready                           71m

사용자 클러스터 업그레이드

VMware용 Anthos 클러스터 업그레이드의 안내를 따릅니다.

새 설치 모델을 사용하여 사용자 클러스터를 업그레이드할 때는 사용자 제어 영역 노드를 포함하여 전체 사용자 클러스터가 업그레이드됩니다.

이와 달리 kubeception 모델을 사용해 배포된 사용자 클러스터의 경우 제어 영역 노드가 사용자 클러스터 업그레이드 중에 업그레이드되지 않으며 관리자 클러스터가 업그레이드될 때까지 업그레이드되지 않습니다.

사용자 클러스터 삭제

사용자 클러스터를 삭제하려면 다음 안내를 따르세요.

gkectl delete cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG --cluster USER_CLUSTER

USER_CLUSTER를 사용자 클러스터 이름으로 바꿉니다.

새 설치 모델을 사용하는 사용자 클러스터를 삭제할 때는 클러스터의 데이터 디스크가 자동으로 삭제되지 않습니다. 따라서 데이터 디스크를 수동으로 삭제해야 합니다. HA 클러스터에는 3개의 데이터 디스크가 있고 HA가 아닌 클러스터에는 1개의 데이터 디스크가 있습니다.

사용자 클러스터의 데이터 디스크는 다음 위치 중 하나에 있습니다.

  • ADMIN_CLUSTER/USER_CLUSTER/

  • ADMIN_DISK_FOLDER/ADMIN_CLUSTER/USER_CLUSTER/

ADMIN_CLUSTER를 관리자 클러스터 이름으로 바꿉니다.

관리자 클러스터 구성 파일의 vCenter.dataDisk 필드에 폴더를 지정한 경우 ADMIN_DISK_FOLDER를 폴더 이름으로 바꿉니다.

HA가 아닌 클러스터의 경우 데이터 디스크 이름은 USER_CLUSTER-0-data.vmdk입니다.

HA 클러스터의 경우 데이터 디스크 이름이 다음과 같이 지정됩니다.

  • USER_CLUSTER-0-data.vmdk.
  • USER_CLUSTER-1-data.vmdk.
  • USER_CLUSTER-2-data.vmdk.

vSphere 클라이언트를 사용하여 데이터 디스크를 삭제할 수 있습니다.

자체 vCenter Server로 사용자 클러스터 만들기

특정 상황에서는 자체 vCenter Server 인스턴스를 사용하는 사용자 클러스터를 만드는 것이 좋습니다. 즉, 관리자 클러스터 및 연결된 사용자 클러스터에 서로 다른 vCenter Server 인스턴스가 사용됩니다.

예를 들어 에지 위치에서 vCenter Server를 실행하는 물리적 머신과 ESXi를 실행하는 하나 이상의 물리적 머신을 사용할 수 있습니다. 그러면 vCenter Server의 로컬 인스턴스를 사용하여 데이터 센터, 클러스터, 리소스 풀, 데이터 스토어, 폴더를 포함한 vSphere 객체 계층 구조를 만들 수 있습니다.

새 모델로 사용자 클러스터 만들기의 안내를 따릅니다.

이 섹션에 설명된 단계 외에도 사용자 클러스터 구성 파일의 전체 vCenter 섹션을 작성합니다. 특히 관리자 클러스터 구성 파일에 지정한 vCenter Server 주소와 다른 vCenter.address 값을 지정합니다.

예

vCenter:
  address: "vc-edge.example"
  datacenter: "vc-edge"
  cluster: "vc-edge-workloads"
  resourcePool: "vc-edge-pool
  datastore: "vc-edge-datastore
  caCertPath: "/usr/local/google/home/me/certs/edge-cacert.pem"
  credentials:
    fileRef:
      path: "credential.yaml"
      entry: "vCenter-edge"
  folder: "edge-vm-folder"

문제 해결

클러스터 생성 및 업그레이드 문제 해결을 참조하세요.

다음 단계