버전 1.5. 이 버전은 완전하게 지원되며 GKE On-Prem에 영향을 미치는 보안 취약점, 노출, 문제에 대한 최신 패치와 업데이트를 제공합니다. 자세한 내용은 출시 노트를 참조하세요. 이는 최신 버전이 아닙니다.

노드 풀 만들기 및 관리

GKE On-Prem 버전 1.3부터는 클러스터의 구성 파일에서 노드 풀을 정의하여 동일한 구성을 가진 사용자 클러스터의 노드 그룹을 만들 수 있습니다. 그러면 클러스터의 다른 노드에 영향을 주지 않고 노드 풀을 개별적으로 관리할 수 있습니다. 노드 풀에 대해 자세히 알아보기

하나 이상의 노드 풀을 모든 사용자 클러스터의 구성 파일에 정의할 수 있습니다. 노드 풀을 만들면 사용자 클러스터에 노드가 추가로 생성됩니다. 사용자 클러스터에서 노드 풀 생성, 업데이트, 삭제를 포함한 노드 풀 관리는 구성 파일의 nodePools 섹션을 수정하고 gkectl update cluster 명령어를 사용하여 기존 클러스터에 해당 변경사항을 배포하여 수행됩니다. 노드 풀을 삭제하면 해당 노드가 워크로드를 실행 중인지 여부에 관계없이 관련 노드가 즉시 삭제됩니다.

노드 풀 예시:

nodePools:
  - name: pool-1
    cpus: 4
    memoryMB: 8192
    replicas: 5

신규 설치를 위한 팁: 첫 번째 사용자 클러스터를 만들고 클러스터에서 노드 풀을 정의합니다. 그런 다음 클러스터 구성 파일을 사용하여 동일한 노드 풀 설정으로 추가 사용자 클러스터를 만듭니다.

시작하기 전에

  • 지원:

    • 사용자 클러스터 버전 1.3.0 이상만 지원됩니다.

    • 관리자 클러스터의 노드 풀이 지원되지 않습니다.

    • 현재 gkectl 업데이트 클러스터 명령어는 노드 풀 업데이트 및 고정 IP 추가에 대한 전체 지원을 제공합니다. Cloud Audit Logging을 사용 설정 및 자동 복구 사용 설정/사용 중지도 지원합니다. 구성 파일에 있는 다른 모든 변경사항은 무시됩니다.

    • 노드 풀의 노드는 다른 노드와 별도로 관리할 수 있지만 아무 클러스터의 노드는 별도로 업그레이드할 수 없습니다. 클러스터를 업그레이드하면 모든 노드가 업그레이드됩니다.

  • 리소스:

    • 노드의 워크로드를 방해하지 않고 노드 풀 replicas에 변경사항만 배포할 수 있습니다.

      중요: 다른 노드 풀 구성 변경사항을 배포하면 노드 풀의 노드가 다시 생성됩니다. 이러한 노드 풀에서 중단되면 안 되는 워크로드가 실행되고 있지 않은지 확인해야 합니다.

    • 노드 풀 변경 사항을 배포하면 원하는 노드가 생성되거나 업데이트된 후 원치 않는 노드는 삭제됩니다. 이 정책의 한 가지 이점은 업데이트 전후의 총 노드 수가 동일하더라도 업데이트 중 더 많은 리소스(예: IP 주소)가 필요할 수 있다는 점입니다. 최대 사용량에 대해 사용 가능한 IP 주소가 충분한지 확인해야 합니다.

노드 풀 만들기 및 업데이트

사용자 클러스터의 구성 파일을 수정하고 배포하여 노드 풀을 관리하세요. 사용자 클러스터에 하나 이상의 노드 풀을 만들고 배포할 수 있습니다.

노드 풀을 만들거나 업데이트하려면 다음 안내를 따르세요.

  1. 노드 풀을 만들거나 업데이트할 사용자 클러스터의 구성 파일을 편집기에서 엽니다.

  2. 사용자 클러스터 구성 파일의 nodePools 섹션에서 하나 이상의 노드 풀을 정의합니다.

    1. 필요한 최소 노드 풀 속성을 구성합니다. 각 노드 풀에 다음 속성을 지정해야 합니다.

      • nodePools.name: 노드 풀의 고유한 이름을 지정합니다. 이 속성을 업데이트하면 노드가 다시 생성됩니다. 예를 들면 - name: pool-1입니다.

      • nodePools.cpus: 풀의 각 워커 노드에 할당된 CPU 수를 지정합니다. 이 속성을 업데이트하면 노드가 다시 생성됩니다. 예를 들면 cpus: 4입니다.

      • nodePools.memoryMB: 사용자 클러스터의 각 워커 노드에 할당되는 메모리 양(MB)을 지정합니다. 이 속성을 업데이트하면 노드가 다시 생성됩니다. 예를 들면 memoryMB: 8192입니다.

      • nodePools.replicas: 풀의 총 워커 노드 수를 지정합니다. 사용자 클러스터는 모든 풀에서 노드를 사용하여 워크로드를 실행합니다. 노드에 영향을 미치거나 워크로드를 실행하지 않고도 이 속성을 업데이트할 수 있습니다. 예를 들면 replicas: 5입니다.

      일부 nodePools 속성은 기존 구성 파일workernode(DHCP|고정 IP)와 동일하며, workernode 섹션은 여전히 모든 사용자 클러스터의 기존 구성 파일에 필요합니다. workernode 섹션을 삭제하거나 nodepools로 바꿀 수 없습니다. 신규 사용자 클러스터 구성 파일에는 workernode 섹션이 더 이상 없습니다. 사용자 클러스터에 노드 풀을 하나 이상 정의하고 기존 구성 파일의 기본 workernode 풀을 대체할 때 비taint 노드가 충분한지 확인해야 합니다.

      예를 들면 다음과 같습니다.

      nodePools:
      - name: pool-1
        cpus: 4
        memoryMB: 8192
        replicas: 5
      

      여러 노드 풀이 있는 사용자 클러스터 구성 파일예시를 참조하세요.

    2. 선택적 노드 풀 속성을 구성합니다. 노드 풀 구성에 labeltaint를 추가하면 노드 워크로드를 조정할 수 있습니다. 또한 노드 풀에서 사용되는 vSphere Datastore를 정의할 수 있습니다.

      • nodePools.labels: 노드 풀을 고유하게 식별하도록 key : value 쌍을 한 개 이상 지정합니다. keyvalue는 문자나 숫자로 시작해야 하며 문자, 숫자, 하이픈, 점, 밑줄을 포함할 수 있습니다. 길이는 각각 최대 63자(영문 기준)입니다.

        자세한 구성 정보는 label을 참조하세요.

        중요: 라벨의 키(kubernetes.io, k8s.io, googleapis.com)는 GKE On-Prem에서 사용하도록 예약되어 있으므로 이러한 키를 지정할 수 없습니다.

        예를 들면 다음과 같습니다.

        labels:
          key1: value1
          key2: value2
        
      • nodePools.taints: 노드 풀의 taints를 정의하도록 key, value, effect를 지정합니다. 이러한 taints는 pod에 구성한 tolerations에 해당됩니다.

        key는 필수이며 value는 선택사항입니다. 둘 다 문자나 숫자로 시작해야 하며 문자, 숫자, 하이픈, 점, 밑줄을 포함할 수 있습니다. 길이는 최대 253자(영문 기준)입니다. 원하는 경우 key 프리픽스를 / 앞에 DNS 하위 도메인과 함께 추가할 수 있습니다. 예를 들면 example.com/my-app입니다.

        유효한 effect 값은 NoSchedule, PreferNoSchedule 또는 NoExecute입니다.

        자세한 구성 정보는 taint를 참조하세요.

        예를 들면 다음과 같습니다.

        taints:
          - key: key1
            value: value1
            effect: NoSchedule
        
      • nodePools.bootDiskSizeGB: 풀의 각 워커 노드에 할당되는 부팅 디스크의 크기를 GB 단위로 지정합니다. 이 구성은 GKE On-Prem 버전 1.5.0부터 사용할 수 있습니다.

        예를 들면 다음과 같습니다.

        bootDiskSizeGB: 40
        
      • nodePools.vsphere.datastore: 풀의 각 노드가 생성될 vSphere Datastore를 지정합니다. 이렇게 하면 사용자 클러스터의 기본 vSphere Datastore가 재정의됩니다.

        예를 들면 다음과 같습니다.

        vsphere:
          datastore: datastore_name
        

    노드 풀이 여러 개 있는 구성 예시는 예시를 참조하세요.

  3. gkectl update cluster 명령어를 사용하여 사용자 클러스터에 변경사항을 배포합니다.

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG_FILE] --dry-run --yes
    
    각 항목의 의미는 다음과 같습니다.
    • [ADMIN_CLUSTER_KUBECONFIG]: 관리자 클러스터의 kubeconfig 파일을 지정합니다.
    • [USER_CLUSTER_CONFIG_FILE]: 사용자 클러스터의 configuration 파일을 지정합니다.
    • --dry-run: 선택적 플래그. 변경사항만 보려면 이 플래그를 추가합니다. 사용자 클러스터에는 변경사항이 배포되지 않습니다.
    • --yes: 선택적 플래그. 명령어를 자동으로 실행하려면 이 플래그를 추가합니다. 계속할지 여부를 확인하는 프롬프트가 중지됩니다.

    명령어를 조기에 중단한 경우 동일한 명령어를 다시 실행하여 작업을 완료하고 변경사항을 사용자 클러스터에 배포할 수 있습니다.

    변경사항을 되돌려야 하면 구성 파일의 변경사항을 되돌리고 변경사항을 사용자 클러스터에 다시 배포해야 합니다.

  4. 모든 노드를 검사하여 변경이 성공했는지 확인합니다. 다음 명령어를 실행하여 사용자 클러스터의 모든 노드를 나열합니다.

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide
    

    여기서 [USER_CLUSTER_KUBECONFIG]는 사용자 클러스터의 kubeconfig 파일입니다.

노드 풀 삭제

사용자 클러스터에서 노드 풀을 삭제하려면 다음 안내를 따르세요.

  1. 사용자 클러스터 구성 파일의 nodePools 섹션에서 정의를 삭제합니다.

  2. 영향을 받는 노드에서 실행 중인 워크로드가 없는지 확인합니다.

  3. gkectl update cluster 명령어를 실행하여 변경사항을 배포합니다.

    gkectl update cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] --config [USER_CLUSTER_CONFIG_FILE] --dry-run --yes
    
    각 항목의 의미는 다음과 같습니다.
    • [ADMIN_CLUSTER_KUBECONFIG]: 관리자 클러스터의 kubeconfig 파일을 지정합니다.
    • [USER_CLUSTER_CONFIG_FILE]: 사용자 클러스터의 configuration 파일을 지정합니다.
    • --dry-run: 선택적 플래그. 변경사항만 보려면 이 플래그를 추가합니다. 사용자 클러스터에는 변경사항이 배포되지 않습니다.
    • --yes: 선택적 플래그. 명령어를 자동으로 실행하려면 이 플래그를 추가합니다. 계속할지 여부를 확인하는 프롬프트가 중지됩니다.
  4. 모든 노드를 검사하여 변경이 성공했는지 확인합니다. 다음 명령어를 실행하여 사용자 클러스터의 모든 노드를 나열합니다.

    kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes -o wide
    

    여기서 [USER_CLUSTER_KUBECONFIG]는 사용자 클러스터의 kubeconfig 파일입니다.

예시

다음 구성 예시에서는 속성이 서로 다른 노드 풀 4개가 있습니다.

  • pool-1: 최소 필수 속성만 지정됨
  • pool-2: vSphere Datastore 포함
  • pool-3: bootDiskSizeGB 포함
  • pool-4: taint 및 label 포함
  • pool-5: 모든 속성 포함
apiVersion: v1
kind: UserCluster
...
# (Required) List of node pools. The total un-tainted replicas across all node pools
# must be greater than or equal to 3
nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 5
- name: pool-2
  cpus: 8
  memoryMB: 16384
  replicas: 3
  vsphere:
    datastore: my_datastore
- name: pool-3
  cpus: 8
  memoryMB: 8192
  replicas: 3
  bootDiskSizeGB: 40
- name: pool-4
  cpus: 4
  memoryMB: 8192
  replicas: 5
  taints:
    - key: "example-key"
      effect: NoSchedule
  labels:
    environment: production
    app: nginx
- name: pool-5
  cpus: 8
  memoryMB: 16384
  replicas: 3
  taints:
    - key: "my_key"
      value: my_value1
      effect: NoExecute
  labels:
    environment: test
  vsphere:
    datastore: my_datastore
  bootDiskSizeGB: 60
...

문제 해결

  • 일반적으로 gkectl update cluster 명령어는 실패 시 세부정보를 제공합니다. 명령어가 성공했지만 노드가 표시되지 않으면 클러스터 문제 진단 가이드를 따라 문제를 해결할 수 있습니다.

  • 노드 풀 생성 또는 업데이트 중에 사용 가능한 IP 주소 부족과 같이 클러스터 리소스가 부족하면 발생할 수 있습니다. IP 주소를 사용할 수 있는지 확인하는 방법에 대한 자세한 내용은 사용자 클러스터 크기 조절 주제를 참조하세요.

  • 일반 문제 해결 가이드를 검토할 수도 있습니다.

  • Creating node MachineDeployment(s) in user cluster… 이후로 더 이상 진행하지 않습니다.

    사용자 클러스터에서 노드 풀을 만들거나 업데이트하는 데 시간이 걸릴 수 있습니다. 하지만 대기 시간이 매우 길어 문제가 있다고 의심되는 경우에는 다음 명령어를 실행하면 됩니다.

    1. kubectl get nodes를 실행하여 노드 상태를 가져옵니다.
    2. 사용할 수 없는 노드에는 kubectl describe node [node_name]을 실행하여 세부정보를 가져옵니다.