데이터 스토어를 SPBM으로 마이그레이션

이 문서에서는 vSphere 데이터 스토어를 스토리지 정책 기반 관리(SPBM)로 마이그레이션하는 방법을 보여줍니다.

이 페이지는 스토리지 성능, 사용량, 비용을 구성 및 관리하는 스토리지 전문가를 대상으로 합니다. Google Cloud 콘텐츠에서 참조하는 일반적인 역할 및 예시 태스크에 대해 자세히 알아보려면 일반 GKE 사용자 역할 및 태스크를 참고하세요.

1.30: 정식 버전
1.29: 미리보기
1.16 이하: 사용할 수 없음

컨텍스트

클러스터 구성 파일에서 데이터 스토어를 지정할 수 있는 위치 4개는 다음과 같습니다.

이러한 필드의 상속은 다음과 같습니다.

adminCluster.vCenter.datastore ->
  userCluster.vCenter.datastore ->
    (userCluster.masterNode.vsphere.datastore and userCluster.nodePools[i].vsphere.datastore)

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

  • userCluster.vCenter.datastore가 비어 있으면 adminCluster.vCenter.datastore에서 값을 상속합니다.

  • userCluster.nodePools[i].vsphere.datastore가 비어 있으면 userCluster.vCenter.datastore에서 값을 상속합니다.

마찬가지로 다음과 같은 4개 위치에서 스토리지 정책을 지정할 수 있습니다.

storagePolicyName 필드의 상속은 datastore 필드의 상속과 동일합니다.

시작하기 전에

  • 이 프로세스는 단방향 마이그레이션입니다. 이전 상태로 다시 마이그레이션할 수 없습니다.
  • 데이터 스토어는 설정할 새 스토리지 정책과 호환되어야 합니다.
  • 고가용성 (HA) 관리자 클러스터만 지원됩니다. 관리자 클러스터가 HA가 아닌 관리자인 경우 먼저 관리자 클러스터를 HA로 마이그레이션해야 합니다.

사용자 클러스터 마이그레이션

이전에 사용하는 단계는 전체 사용자 클러스터를 이전할지 아니면 컨트롤 플레인 노드와 워커 노드 풀을 별도로 이전할지에 따라 다릅니다. 이 옵션을 사용하면 컨트롤 플레인 노드와 워커 노드 풀에 대해 서로 다른 스토리지 정책을 선택할 수 있습니다.

유지보수 기간을 계획할 때 다음 사항을 참고하세요.

  • 전체 클러스터를 마이그레이션하는 데는 클러스터 업데이트가 한 번만 필요합니다.

  • 컨트롤 플레인 노드와 워커 노드 풀을 별도로 이전하려면 클러스터를 두 번 업데이트해야 합니다.

전체 클러스터

모든 컨트롤 플레인 노드와 워커 노드 풀을 포함한 전체 클러스터를 이전하려면 다음 단계를 따르세요. 사용자 클러스터 버전이 1.30 이상이어야 합니다.

  1. 다음과 같이 사용자 클러스터 구성 파일을 수정합니다.

    1. vCenter.storagePolicyName 필드를 스토리지 정책의 이름으로 설정합니다.

    2. 다음이 지정된 경우 삭제하거나 주석 처리합니다.

      • vCenter.datastore 필드
      • masterNode.vsphere 섹션
      • nodepools[i].vsphere.datastore
      • nodepools[i].vsphere.storagePolicyName

    다음 예시 구성은 이러한 변경사항을 보여줍니다.

    변경 전:

    vCenter:
      datastore: ds-1
    

    변경 후:

    vCenter:
      storagePolicyName: sp-1
      # datastore: ds-1
    
  2. 사용자 클러스터를 업데이트합니다.

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config USER_CLUSTER_CONFIG
    

    다음을 바꿉니다.

    • ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

    • USER_CLUSTER_CONFIG: 사용자 클러스터 구성 파일의 경로입니다.

번들로 제공되는 StorageClass 업데이트

클러스터에서 구성 설정을 업데이트한 후 번들로 제공되는 StorageClass을 업데이트해야 합니다.

  1. 번들로 제공되는 vsphere-csi-driver(이름은 standard-rwo)의 현재 기본 StorageClass을 가져와 storage-class.yaml라는 로컬 파일에 저장합니다.

    kubectl get storageclass standard-rwo -oyaml \
        --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml
    

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

  2. 파일을 변경해야 하므로 예방 조치로 storage-class.yaml의 사본을 만듭니다.

    cp storage-class.yaml storage-class.yaml-backup.yaml
    
  3. 클러스터에서 기본 StorageClass를 삭제합니다.

    kubectl delete storageclass standard-rwo \
        --kubeconfig USER_CLUSTER_KUBECONFIG
    
  4. 다음과 같이 storage-class.yaml에서 구성을 업데이트합니다.

    1. 다음 필드를 삭제하거나 주석 처리합니다.

      • parameters.datastoreURL
      • resourceVersion
    2. parameters.storagePolicyName 필드를 추가하고 스토리지 정책의 이름으로 설정합니다.

    다음 예시 구성은 이러한 변경사항을 보여줍니다.

    변경 전:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: standard-rwo
    Parameters:
      ...
      datastoreURL: ds//ds-1
    

    변경 후:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: standard-rwo
    Parameters:
      ...
      storagePolicyName: sp-1
    
  5. 수정된 StorageClass을 사용자 클러스터에 적용합니다.

    kubectl apply -f storage-class.yaml \
        --kubeconfig USER_CLUSTER_KUBECONFIG
    

Kubeception 사용자 클러스터만 해당

Kubeception 사용자 클러스터의 경우 관리자 클러스터에서 사용자 클러스터 컨트롤 플레인 노드의 StorageClass를 업데이트해야 합니다. Kubeception 클러스터의 구성 필드 enableControlplaneV2false로 설정됩니다. Controlplane V2가 사용 설정되면 사용자 클러스터의 컨트롤 플레인은 사용자 클러스터 자체에서 실행됩니다. Controlplane V2가 사용 설정되지 않았으면 사용자 클러스터의 컨트롤 플레인이 kubeception이라고 하는 관리자 클러스터에서 실행됩니다.

다음 명령어를 실행하여 클러스터에 Controlplane V2가 사용 설정되었는지 확인합니다.

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

출력이 false이면 다음 단계에 따라 관리자 클러스터에서 사용자 클러스터 컨트롤 플레인 노드의 기본 StorageClass을 업데이트합니다.

  1. 번들로 제공되는 vsphere-csi-driver(이름은 USER_CLUSTER_NAME-csi)의 현재 기본 StorageClass을 가져와 storage-class-kubeception.yaml라는 로컬 파일에 저장합니다.

    kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml
    

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

  2. 파일을 변경해야 하므로 예방책으로 storage-class-kubeception.yaml의 사본을 만듭니다.

    cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml
    
  3. 클러스터에서 기본 StorageClass를 삭제합니다.

    kubectl delete storageclass USER_CLUSTER_NAME-csi \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    
  4. 다음과 같이 storage-class-kubeception.yaml에서 구성을 업데이트합니다.

    1. 다음 필드를 삭제하거나 주석 처리합니다.

      • parameters.datastoreURL
      • resourceVersion
    2. parameters.storagePolicyName 필드를 추가하고 스토리지 정책의 이름으로 설정합니다.

    다음 예시 구성은 이러한 변경사항을 보여줍니다.

    변경 전:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: standard-rwo
    Parameters:
      ...
      datastoreURL: ds//ds-1
    

    변경 후:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: standard-rwo
    Parameters:
      ...
      storagePolicyName: sp-1
    
  5. 수정된 StorageClass을 관리자 클러스터에 적용합니다.

    kubectl apply -f storage-class-kubeception.yaml \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

마이그레이션 후

마이그레이션 후 새 노드 풀을 만들면 새 풀은 업데이트된 클러스터에 따라 상속 규칙을 따릅니다.

예를 들어 vCenter.datastore를 스토리지 정책으로 마이그레이션했다고 가정합니다.

이제 새 노드 풀을 만들고 nodePools[i].vsphere.datastorenodePools[i].vsphere.storagePolicyName을 모두 비워 두면 새 노드 풀이 vCenter.storagePolicyName에 지정된 스토리지 정책을 상속합니다.

노드를 별도로

컨트롤 플레인 노드와 워커 노드 풀을 별도로 마이그레이션하려면 다음 단계를 따르세요.

  1. 버전 1.29만 해당: 현재 클러스터 구성을 가져옵니다. 사용자 클러스터가 버전 1.30 이상인 경우 이 단계는 필요하지 않습니다.

    gkectl get-config cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --cluster-name USER_CLUSTER_NAME \
      --output-dir ./gen-files
    

    다음을 바꿉니다.

    • ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터의 kubeconfig 파일 경로입니다.

    • USER_CLUSTER_NAME: 사용자 클러스터의 이름입니다.

    ./gen-files에서 user-cluster.yaml을 찾습니다.

    구성 파일을 가져오는 방법에 대한 자세한 내용은 클러스터에서 구성 파일 생성을 참조하세요.

    생성된 구성 파일에는 다음 예와 같이 각 수준(클러스터, masterNode(컨트롤 플레인 노드용), nodepools(작업자 노드용))에 datastore 이름이 설정되어 있습니다.

    apiVersion: v1
    kind: UserCluster
    ...
    # VCenter config in cluster level:
    vCenter:
      datastore: ds-1
    ...
    # VCenter config in master node level:
    masterNode:
      vsphere:
        datastore: ds-1
    ...
    # VCenter config in nodepool level:
    nodepools:
    - name: pool-1
      vsphere:
        datastore: ds-1
    - name: pool-2
      vsphere:
        datastore: ds-1
    

제어 영역 노드 마이그레이션

다음 단계에 따라 컨트롤 플레인 노드를 마이그레이션합니다.

  1. 사용자 클러스터 구성 파일을 다음과 같이 변경합니다.

    • masterNode.vsphere.storagePolicyName 필드를 스토리지 정책의 이름으로 설정합니다.
    • masterNode.vsphere.datastore 필드를 삭제하거나 주석 처리합니다.

    다음 예시 구성은 이러한 변경사항을 보여줍니다.

    변경 전:

    masterNode:
      vsphere:
        datastore: ds-1
    

    변경 후:

    masterNode:
      vsphere:
        # datastore: ds-1
        storagePolicyName: sp-1
    
  2. 사용자 클러스터를 업데이트합니다.

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config USER_CLUSTER_CONFIG
    

    다음을 바꿉니다.

    • ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로입니다.

    • USER_CLUSTER_CONFIG: 사용자 클러스터 구성 파일의 경로입니다.

    노드 풀을 업데이트하기 전에 업데이트 명령어가 완료될 때까지 기다립니다.

노드 풀 마이그레이션

모든 노드 풀을 마이그레이션하려면 다음 단계를 따르세요.

  1. 사용자 클러스터 구성 파일을 다음과 같이 변경합니다.

    • nodePools[i].vsphere.storagePolicyName 필드를 스토리지 정책의 이름으로 설정합니다.
    • nodePools[i].vsphere.datastore 필드를 삭제하거나 주석 처리합니다.

    다음 예시 구성은 이러한 변경사항을 보여줍니다.

    변경 전:

    nodepools:
    - name: pool-1
      vsphere:
        datastore: ds-1
    - name: pool-2
      vsphere:
        datastore: ds-1
    

    변경 후:

    nodepools:
    - name: pool-1
      vsphere:
        # datastore: ds-1
        storagePolicyName: sp-1
    - name: pool-2
      vsphere:
        # datastore: ds-1
        storagePolicyName: sp-1
    
  2. 사용자 클러스터를 업데이트합니다.

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config USER_CLUSTER_CONFIG
    

선택적으로 클러스터 수준에서 스토리지 정책 업데이트

사용자 클러스터의 경우 클러스터 수준 vCenter 섹션의 datastorestoragePolicyName 필드는 masterNodenodepools 섹션에서 사용하는 기본값입니다. 이전 단계를 완료하면 클러스터 수준 vCenter datastorestoragePolicyName 설정이 클러스터 구성요소에서 사용되지 않습니다. 클러스터 수준 vCenter 섹션을 그대로 두거나 masterNodenodepools와 일치하도록 업데이트할 수 있습니다.

설정을 그대로 두는 경우 클러스터 수준 vCenter 섹션 위에 masterNodenodepools 섹션의 설정으로 재정의되므로 설정이 무시된다는 주석을 추가하는 것이 좋습니다.

원하는 경우 클러스터 수준 vCenter 섹션을 masterNodenodepools 섹션과 일치하도록 변경하고 다음 단계에 따라 클러스터를 업데이트할 수 있습니다.

  1. 다음과 같이 사용자 클러스터 구성 파일을 수정합니다.

    • vCenter.storagePolicyName 필드를 스토리지 정책의 이름으로 설정합니다.
    • vCenter.datastore 필드를 삭제하거나 주석 처리합니다.
  2. 사용자 클러스터를 업데이트합니다.

    gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config USER_CLUSTER_CONFIG
    

    이 업데이트 명령어는 클러스터를 변경하지는 않지만 서버 측 (OnPremUserCluster) vCenter.datastorevCenter.storagePolicyName 필드를 업데이트합니다.

번들로 제공되는 StorageClass 업데이트

구성 설정을 업데이트한 후 번들로 제공되는 StorageClass를 업데이트해야 합니다.

  1. 번들로 제공되는 vsphere-csi-driver(이름은 standard-rwo)의 현재 기본 StorageClass을 가져와 storage-class.yaml라는 로컬 파일에 저장합니다.

    kubectl get storageclass standard-rwo -oyaml \
        --kubeconfig USER_CLUSTER_KUBECONFIG > storage-class.yaml
    

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

  2. 파일을 변경해야 하므로 예방 조치로 storage-class.yaml의 사본을 만듭니다.

    cp storage-class.yaml storage-class.yaml-backup.yaml
    
  3. 클러스터에서 기본 StorageClass를 삭제합니다.

    kubectl delete storageclass standard-rwo \
        --kubeconfig USER_CLUSTER_KUBECONFIG
    
  4. 다음과 같이 storage-class.yaml에서 구성을 업데이트합니다.

    1. 다음 필드를 삭제하거나 주석 처리합니다.

      • parameters.datastoreURL
      • resourceVersion
    2. parameters.storagePolicyName 필드를 추가하고 스토리지 정책의 이름으로 설정합니다.

    다음 예시 구성은 이러한 변경사항을 보여줍니다.

    변경 전:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: standard-rwo
    Parameters:
      ...
      datastoreURL: ds//ds-1
    

    변경 후:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: standard-rwo
    Parameters:
      ...
      storagePolicyName: sp-1
    
  5. 수정된 StorageClass을 사용자 클러스터에 적용합니다.

    kubectl apply -f storage-class.yaml \
        --kubeconfig USER_CLUSTER_KUBECONFIG
    

Kubeception 사용자 클러스터만 해당

Kubeception 사용자 클러스터의 경우 관리자 클러스터에서 사용자 클러스터 컨트롤 플레인 노드의 StorageClass를 업데이트해야 합니다. Kubeception 클러스터의 구성 필드 enableControlplaneV2false로 설정됩니다. Controlplane V2가 사용 설정되면 사용자 클러스터의 컨트롤 플레인은 사용자 클러스터 자체에서 실행됩니다. Controlplane V2가 사용 설정되지 않았으면 사용자 클러스터의 컨트롤 플레인이 kubeception이라고 하는 관리자 클러스터에서 실행됩니다.

다음 명령어를 실행하여 클러스터에 Controlplane V2가 사용 설정되었는지 확인합니다.

kubectl get onpremuserclusters --kubeconfig USER_CLUSTER_KUBECONFIG \
  -n kube-system -o jsonpath='{.items[0].spec.enableControlplaneV2}' && echo

출력이 false이면 다음 단계에 따라 관리자 클러스터에서 사용자 클러스터 컨트롤 플레인 노드의 기본 StorageClass을 업데이트합니다.

  1. 번들로 제공되는 vsphere-csi-driver(이름은 USER_CLUSTER_NAME-csi)의 현재 기본 StorageClass을 가져와 storage-class-kubeception.yaml라는 로컬 파일에 저장합니다.

    kubectl get storageclass USER_CLUSTER_NAME-csi -oyaml \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG > storage-class-kubeception.yaml
    

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

  2. 파일을 변경해야 하므로 예방책으로 storage-class-kubeception.yaml의 사본을 만듭니다.

    cp storage-class-kubeception.yaml storage-class-kubeception-backup.yaml
    
  3. 클러스터에서 기본 StorageClass를 삭제합니다.

    kubectl delete storageclass USER_CLUSTER_NAME-csi \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    
  4. 다음과 같이 storage-class-kubeception.yaml에서 구성을 업데이트합니다.

    1. 다음 필드를 삭제하거나 주석 처리합니다.

      • parameters.datastoreURL
      • resourceVersion
    2. parameters.storagePolicyName 필드를 추가하고 스토리지 정책의 이름으로 설정합니다.

    다음 예시 구성은 이러한 변경사항을 보여줍니다.

    변경 전:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: standard-rwo
    Parameters:
      ...
      datastoreURL: ds//ds-1
    

    변경 후:

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
      name: standard-rwo
    Parameters:
      ...
      storagePolicyName: sp-1
    
  5. 수정된 StorageClass을 관리자 클러스터에 적용합니다.

    kubectl apply -f storage-class-kubeception.yaml \
        --kubeconfig ADMIN_CLUSTER_KUBECONFIG
    

관리자 클러스터 마이그레이션

관리자 클러스터도 스토리지 정책 이름으로 업데이트해야 합니다.

  1. 관리자 클러스터 구성 파일을 다음과 같이 변경합니다.

    • vCenter.datastore 필드를 삭제하거나 주석 처리합니다.
    • vCenter.storagePolicyName 필드를 스토리지 정책의 이름으로 설정합니다.
  2. 관리자 클러스터를 업데이트합니다.

    gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
      --config ADMIN_CLUSTER_CONFIG
    

    다음을 바꿉니다.

    • ADMIN_CLUSTER_KUBECONFIG: 관리자 클러스터 kubeconfig 파일의 경로
    • ADMIN_CLUSTER_CONFIG: 관리자 클러스터 구성 파일의 경로입니다.

SPBM을 사용한 스토리지 마이그레이션

데이터 스토어에서 SPBM으로 마이그레이션한 후 클러스터에서 이제 SPBM을 사용합니다. 하지만 이전에서는 이전 데이터 스토어의 스토리지 워크로드 (예: 머신 데이터 디스크 또는 컨테이너 볼륨)를 이동하지 않습니다.

스토리지 워크로드를 이동하려면 스토리지 정책 기반 관리를 사용한 스토리지 마이그레이션을 참고하세요.