버전 정보는 연결된 Distributed Cloud 출시 노트를 참고하세요.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Distributed Cloud connected 스토리지 구성

이 페이지에서는 다음을 비롯하여 Distributed Cloud 연결 클러스터의 스토리지를 구성하는 방법을 설명합니다.

Rakuten Symcloud Storage
로컬 스토리지 스키마
문제 해결

Symcloud Storage용 Distributed Cloud 연결 구성

Distributed Cloud 연결 노드는 워크로드에 로컬 스토리지를 직접 노출하지 않습니다. 대신 Distributed Cloud 연결은 각 Distributed Cloud 연결 노드에서 실행되고 클러스터의 모든 Distributed Cloud 연결 노드에서 실행되는 워크로드에 로컬 스토리지를 제공하는 로컬 스토리지 추상화 레이어 역할을 하는 서드 파티 솔루션인 Rakuten Symcloud Storage를 사용합니다.

컨테이너 스토리지 인터페이스 (CSI)는 Kubernetes가 컨테이너화된 워크로드에 임의의 스토리지 시스템을 노출할 수 있도록 하는 많은 주요 스토리지 공급업체에서 지원하는 개방형 표준 API입니다. Distributed Cloud 연결에서 Symcloud Storage는 지원되고 관리되는 CSI 스토리지 솔루션입니다. Symcloud Storage가 활성화되면 필요한 Kubernetes StorageClasses 가 자동으로 구성됩니다. 그런 다음 적절한 스토리지 클래스를 사용하도록 워크로드를 구성할 수 있습니다.

Symcloud Storage는 Google Cloud Marketplace에서 배포되며 여기에 명시된 약관이 적용됩니다. Google은 Distributed Cloud 연결에서 Symcloud Storage 사용에 대한 제한적인 지원을 제공하며 지원을 위해 서드 파티 제공업체에 문의할 수 있습니다. Symcloud Storage의 소프트웨어 업데이트는 Distributed Cloud 연결 소프트웨어 업데이트에 포함되어 있습니다.

이 Distributed Cloud 연결 출시 버전은 Symcloud Storage 6.0.0-226을 제공하고 지원합니다 . 이 Distributed Cloud 연결 출시 버전에서는 다른 버전의 Symcloud Storage가 지원되지 않습니다.

Symcloud Storage 라이선스 가져오기

Google Cloud Marketplace에서 YAML 형식으로 Symcloud Storage 라이선스를 가져와야 합니다.

Marketplace로 이동

기본 요건

시작하기 전에 다음 단계를 완료하세요.

대상 Distributed Cloud 연결 프로젝트의 로깅 및 모니터링 을 구성합니다.
대상 Distributed Cloud 연결 클러스터를 만듭니다.
대상 Distributed Cloud 연결 클러스터의 포드가 데이터 센터에 연결할 수 있도록 Distributed Cloud 네트워킹을 구성합니다. Google Cloud
Symcloud Storage에서 추상화하지 않으려는 각 Distributed Cloud 노드의 각 local-block 영구 볼륨을 바인딩합니다. 바인딩된 local-block 영구 볼륨을 바인딩 해제하면 Symcloud Storage를 설치할 때 해당 영구 볼륨의 콘텐츠가 삭제됩니다. 자세한 내용은 Kubernetes 문서의 바인딩을 참조하세요.

Distributed Cloud 연결 노드에 Symcloud Storage 설치

Distributed Cloud 연결 노드에 Symcloud Storage를 설치하려면 다음 단계를 완료하세요.

다음 명령어를 사용하여 클러스터에 Symcloud Storage 라이선스를 적용합니다. LICENSE_FILE을 Symcloud Storage 라이선스 파일의 전체 경로와 이름으로 바꿉니다.
```
kubectl apply -f LICENSE_FILE -n robin-admin
```
다음 명령어를 사용하여 RobinCluster 서비스 및 모든 Symcloud Storage 노드의 상태를 확인합니다.
```
kubectl describe robinclusters -n robinio
```
이 명령어는 다음과 유사한 출력을 반환합니다.
```
[...]
Status:
[...]
Phase:              Ready
robin_node_status:
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]
 Status:           Ready
[...]
```
서비스 및 노드의 예상 상태는 Ready입니다.

Symcloud Storage를 기본 스토리지 클래스로 설정

다음 명령어를 사용하여 Distributed Cloud 연결 클러스터에서 Symcloud Storage를 기본 스토리지 클래스로 설정합니다. STORAGE_CLASS를 Symcloud Storage 클래스 중 하나로 바꿉니다.

kubectl patch storageclass STORAGE_CLASS -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

기본 스토리지 클래스 설정에 대한 자세한 내용은 Kubernetes 문서의 기본 StorageClass 변경 을 참조하세요.

Symcloud Storage 클래스

이 섹션에서는 Symcloud Storage가 Distributed Cloud 연결 클러스터에서 사용 설정할 수 있는 스토리지 클래스를 설명합니다. Distributed Cloud 연결의 Symcloud Storage는 robin-rwx 스토리지 클래스 또는 커스텀 구성된 RWX 파일 시스템 모드 볼륨을 지원하지 않습니다. Symcloud Storage 클래스에 대한 자세한 내용은 Kubernetes에서 Robin CNS 사용을 참조하세요.

`robin` 스토리지 클래스

robin 스토리지 클래스는 기본 읽기 쓰기 한 번 (RWO) 스토리지 클래스입니다. 다음 예에서는 클래스의 인스턴스화를 보여줍니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer

`robin-immediate` 스토리지 클래스

robin-immediate 스토리지 클래스는 해당 영구 볼륨 클레임을 만든 직후에 영구 볼륨이 생성된다는 점을 제외하고 robin과 동일합니다. 다음 예에서는 클래스의 인스턴스화를 보여줍니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-immediate
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

`robin-repl-3` 스토리지 클래스

robin-repl-3은 여러 Distributed Cloud 노드에 걸쳐 있는 3개의 복제본이 있는 RWO 스토리지 클래스입니다. 다음 예에서는 클래스의 인스턴스화를 보여줍니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
    name: robin-repl-3
    labels:
        app.kubernetes.io/instance: robin
        app.kubernetes.io/managed-by: robin.io
        app.kubernetes.io/name: robin
provisioner: robin
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: WaitForFirstConsumer
parameters:
    replication: "3"
    faultdomain: host

워크로드에 추상화된 Symcloud Storage 볼륨 구성

이 섹션에서는 Symcloud Storage 클래스를 사용하여 Distributed Cloud 연결 워크로드의 추상화된 스토리지를 구성하는 방법을 보여주는 예를 제공합니다. Symcloud Storage 볼륨 구성에 대한 자세한 내용은 Kubernetes에서 Robin CNS 사용을 참조하세요.

파일 시스템 모드에서 `ext4` RWO 볼륨 구성

다음 예에서는 ext4 파일 시스템을 사용하여 파일 시스템 모드에서 RWO 볼륨의 영구 볼륨 클레임을 구성하는 방법을 보여줍니다. STORAGE_CLASS를 Symcloud Storage 클래스 중 하나로 바꿉니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-fs-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

블록 모드에서 RWO 볼륨 구성

다음 예에서는 블록 모드에서 RWO 볼륨의 영구 볼륨 클레임을 구성하는 방법을 보여줍니다. STORAGE_CLASS를 Symcloud Storage 클래스 중 하나로 바꿉니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS
  volumeMode: Block

기존 볼륨 구성 수정

다음 예에서는 주석을 사용하여 기존 Symcloud Storage LZ4 압축 RWO 볼륨의 구성을 수정하는 방법을 보여줍니다. STORAGE_CLASS를 Symcloud Storage 클래스 중 하나로 바꿉니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: compressed-rwo-fs-pvc
  annotations:
    robin.io/compression: LZ4
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

다음 예에서는 주석을 사용하여 xfs 파일 시스템이 있는 기존 Symcloud Storage RWO 볼륨의 구성을 수정하는 방법을 보여줍니다. STORAGE_CLASS를 Symcloud Storage 클래스 중 하나로 바꿉니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: rwo-xfs-pvc
  annotations:
    robin.io/fstype: xfs
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: STORAGE_CLASS

Symcloud Storage CLI 클라이언트 구성

Symcloud Storage는 Symcloud Storage 구성을 관리하는 데 사용할 수 있는 명령줄 인터페이스 (CLI) 클라이언트를 제공합니다. Distributed Cloud 연결 클러스터에서 클라이언트를 구성하려면 다음 단계를 완료하세요.

Distributed Cloud 연결 클러스터에 배포된 RobinCluster 서비스 인스턴스에서 사용하는 Symcloud Storage 이미지 경로를 가져오고 환경 변수를 다음과 같이 설정합니다.

image_robin=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_robin}')
image_registry_path=$(kubectl get robincluster -o jsonpath='{.items[].spec.image_registry_path}')
ROBIN_CNS_IMAGE="$image_registry_path/$image_robin"

다음 콘텐츠로 robincli 리소스를 만듭니다.

kind: Deployment
apiVersion: apps/v1
metadata:
 name: robincli
 namespace: default
 labels:
   name: robincli
spec:
 replicas: 1
 selector:
   matchLabels:
     name: robincli
 template:
   metadata:
     annotations:
       product: robin
     labels:
       name: robincli
   spec:
     containers:
     - name: robincli
       image: ROBIN_CNS_IMAGE
       workingDir: /root
       command: ["/bin/bash","-c","mkdir -p /root/.robin; ln -s -t /usr/lib/python3.7/site-packages/ /opt/robin/current/python3/site-packages/robincli /opt/robin/current/python3/site-packages/stormgr_def.py /opt/robin/current/python3/site-packages/stormgr_lib.py; /opt/robin/current/bin/robin client add-context robin-master.robinio --set-current; while true; do sleep 10000; done"]
       resources:
         requests:
           memory: "10Mi"
           cpu: "100m"

ROBIN_CNS_IMAGE를 1단계에서 가져온 이미지의 전체 저장소 경로와 이름으로 바꿉니다.

Distributed Cloud 연결 클러스터에 robincli 리소스를 적용합니다.
초기 설치 시 Symcloud Storage는 임의 비밀번호로 robinio 네임스페이스에 default-admin-user 보안 비밀을 생성합니다. 다음 명령어를 사용하여 이러한 로그인 사용자 인증 정보를 가져옵니다.
1. 사용자 이름 가져오기:
```
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.username}' | base64 -d
```
2. 비밀번호 가져오기:
```
 
kubectl -n robinio get secret default-admin-user -o jsonpath='{.data.password}' | base64 -d
```
새로 만든 포드에 로그인하고 클라이언트를 실행합니다.
```
kubectl exec -it robincli -- bash
```

StatefulSet에서 스토리지 클래스 참조

다음 예에서는 StatefulSet 워크로드에서 Symcloud 스토리지 클래스를 참조하는 방법을 보여줍니다.

이 예에서는 고가용성을 위해 3개의 개별 작업자 노드에 복제된 볼륨을 제공하는 사전 구성된 robin-repl-3 스토리지 클래스를 사용한다고 가정합니다.

고가용성을 위해 StatefulSet를 구성할 때는 구성에 다음 권장사항을 포함하세요.

헤드리스 서비스: StatefulSet에는 컴패니언 헤드리스 서비스 가 필요합니다. serviceName 필드와 일치합니다. 헤드리스 서비스는 clusterIP: None이 있는 서비스입니다. 이 서비스는 세트의 각 포드에 안정적인 DNS 호스트 이름을 할당합니다.
포드 안티어피니티: robin-repl-3과 같은 복제된 스토리지 클래스를 사용하는 경우 데이터가 여러 작업자 노드에 안전하게 미러링됩니다. 하지만 Kubernetes가 모든 애플리케이션 포드를 동일한 워커 노드에 스케줄링하면 단일 노드 중단으로 인해 애플리케이션이 중단될 수 있습니다. 포드 안티어피니티를 구성하면 포드가 별도의 작업자 노드에 분산되어 컴퓨팅 가용성이 스토리지 중복성과 일치합니다.

다음 예에서는 헤드리스 서비스 (nginx)와 robin-repl-3 스토리지 클래스를 참조하는 포드 안티어피니티로 구성된 StatefulSet를 포함하는 완전한 구성을 보여줍니다. 워크로드 스토리지 요구사항이 시간이 지남에 따라 증가하면 PersistentVolumeClaim에서 스토리지 요청을 수정하여 볼륨 크기를 동적으로 조절할 수 있습니다.

statefulset.yaml

apiVersion: v1
kind: Service
metadata:
  name: nginx
  labels:
    app: nginx
spec:
  ports:
  - port: 80
    name: web
  clusterIP: None
  selector:
    app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - nginx
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: nginx
        image: registry.k8s.io/nginx-slim:0.8
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates: # Reference the storage class in this specification
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]
      resources:
        requests:
          storage: 10Gi # Symcloud Storage classes support dynamic volume expansion if more storage is needed
      storageClassName: robin-repl-3 # References the Symcloud storage class

Symcloud Storage의 제한사항

Distributed Cloud 연결에서 Symcloud Storage를 사용하는 경우 Distributed Cloud 연결 클러스터가 3개 이상의 Distributed Cloud 연결 노드로 구성된 경우에만 고가용성을 달성할 수 있습니다.

클러스터에서 Symcloud Storage를 사용하는 노드 삭제

Symcloud Storage 볼륨 복제본은 Distributed Cloud 연결 클러스터 내의 작업자 노드에 저장됩니다. 클러스터에서 노드를 삭제하면 해당 노드에 저장된 Symcloud Storage 볼륨 데이터를 사용할 수 없게 됩니다. 이를 방지하려면 다음 중 하나를 수행해야 합니다.

전체 클러스터를 삭제하는 경우 클러스터 자체를 삭제하기 전에 워크로드와 해당 Symcloud Storage 영구 볼륨을 삭제합니다.
클러스터에서 특정 노드를 삭제하는 경우 클러스터에서 해당 노드를 삭제하기 전에 해당 노드에 저장된 워크로드 데이터를 마이그레이션해야 합니다. 자세한 내용은 디스크에서 볼륨 비우기를 참조하세요.

로컬 스토리지 스키마 구성

스토리지 스키마는 하나 이상의 파티션의 논리적 그룹입니다. 각 파티션은 논리적으로 독립적인 스토리지 단위입니다. 파티션은 물리적 디스크 공간이 소진될 때까지 클러스터에서 순차적으로 생성됩니다. 각 스토리지 스키마에는 스토리지 스키마를 식별하는 고유한 이름이 있습니다.

Distributed Cloud 연결 클러스터의 새 로컬 스토리지 스키마를 만들려면 Google에 요청해야 합니다. 스키마를 테스트하고 클러스터에서 만든 후에는 gcloud CLI를 사용하여 적용할 수 있습니다.

스키마를 클러스터에 적용한 후에는 수정할 수 없습니다. 기존 스키마를 변경하려면 Google에 기존 스키마 삭제를 요청한 후 새 스키마 생성을 요청하여 기존 스키마를 대체해야 합니다.

로컬 스토리지 스키마의 파티션 정의

로컬 스토리지 스키마를 요청하려면 먼저 해당 스키마의 파티션을 정의해야 합니다.

파티션에는 다음과 같은 속성이 있습니다.

크기. 파티션 크기를 바이너리 바이트로 지정하거나 로컬 디스크의 나머지 공간을 모두 사용하도록 할 수 있습니다.
유형. 파티션을 Kubernetes 영구 볼륨 (PV) 또는 로컬 디스크의 Linux 로컬 볼륨으로 구성할 수 있습니다.
모드. 파티션에 저장된 볼륨을 블록 볼륨 또는 파일 시스템 볼륨으로 구성할 수 있습니다. 영구 볼륨 파티션의 경우 파티션의 스토리지 클래스는 각각 local-block 또는 local-disks입니다. 로컬 볼륨 파티션의 경우 포함된 파일 시스템의 바인딩 및 마운트 지점을 지정할 수 있습니다.

로컬 스토리지 스키마 요청

Distributed Cloud 연결 클러스터의 새 로컬 스토리지 스키마를 요청하려면 Google 지원팀에 문의하고 스키마에서 만들려는 각 파티션의 크기, 유형, 모드, 마운트 및 바인딩 지점(선택사항)을 제공하세요.

요청을 받으면 스키마의 견고성을 보장하기 위해 일련의 테스트를 실행한 후 Distributed Cloud 연결 클러스터에서 스키마를 만듭니다.

기본 로컬 스토리지 스키마

Distributed Cloud 연결은 다음과 같은 기본 로컬 스토리지 스키마와 함께 제공됩니다.

default_control_plane_node. 이 스키마는 다음 파티션을 정의합니다.
- 파일 시스템 모드의 100GB 로컬 볼륨 파티션
- 남은 여유 디스크 공간을 차지하는 블록 모드의 영구 볼륨 파티션
default_worker_node. 이 스키마는 블록 모드의 410GB 영구 볼륨 파티션을 정의합니다.

클러스터에 로컬 스토리지 스키마 적용

Distributed Cloud 연결 클러스터에 로컬 스토리지 스키마를 적용하려면 다음 중 하나를 수행하세요.

로컬 스토리지 스키마를 클러스터의 컨트롤 플레인 노드에 적용하려면 클러스터를 만들 때 --control-plane-node-storage-schema 플래그를 사용합니다. 자세한 내용은 클러스터 만들기를 참조하세요.
로컬 스토리지 스키마를 클러스터의 작업자 노드에 적용하려면 클러스터의 노드 풀을 만들 때 --node-storage-schema를 사용합니다. 자세한 내용은 노드 풀 만들기를 참조하세요.

Distributed Cloud 연결은 클러스터 또는 노드 풀이 성공적으로 생성되면 로컬 스토리지 스키마에 정의된 파티션을 만듭니다.

문제 해결

PersistentVolumeClaims가 예기치 않게 보류 중이거나 워크로드가 볼륨을 연결하지 못하는 경우 이 섹션에 나열된 문제 해결 단계를 실행합니다.

PersistentVolumeClaims가 보류 중으로 유지됨

PersistentVolumeClaims가 Pending 상태로 유지되면 스토리지 클래스의 volumeBindingMode를 확인합니다. 사전 구성된 Symcloud Storage 클래스는 volumeBindingMode: WaitForFirstConsumer를 사용하며, 클레임을 참조하는 포드가 예약될 때까지 볼륨 프로비저닝을 지연시킵니다. 워크로드 포드가 성공적으로 예약되었는지 확인합니다.

포드 예약이 완료되었지만 클레임이 보류 중으로 유지되거나 볼륨 연결이 실패하면 Symcloud Storage 컨트롤 플레인 및 노드 수준 데몬의 상태를 확인합니다.

컨트롤 플레인 상태 확인

Symcloud Storage 컨트롤 플레인이 정상이고 볼륨을 프로비저닝할 준비가 되었는지 확인하려면 볼륨을 프로비저닝할 준비가 되었는지 확인하려면 kubectl describe 명령어를 실행하여 RobinCluster 커스텀 리소스의 상태를 확인합니다.

kubectl describe robinclusters -n robinio

명령어 출력에서 Phase가 Ready인지 확인합니다.

스토리지 데몬 상태 확인

모든 노드 수준 스토리지 데몬 포드가 실행 중인지 확인하려면 kubectl get 명령어를 실행합니다.

kubectl get pods -n robinio

명령어 출력에서 모든 포드가 Running 상태인지 확인합니다. 실패한 스토리지 데몬 포드가 있는 노드에 워크로드가 예약되면 중앙 RobinCluster 상태와 관계없이 볼륨 연결이 중단됩니다.

지원팀에 문의

Symcloud Storage 컨트롤 플레인 상태가 Ready가 아니거나 스토리지 데몬 포드가 Running 상태가 아닌 경우 Google 지원팀에 문의하세요. 지원 티켓을 제출할 때는 실행한 문제 해결 명령어의 출력을 제공하세요.

Distributed Cloud connected 스토리지 구성 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

Symcloud Storage용 Distributed Cloud 연결 구성

Symcloud Storage 라이선스 가져오기

기본 요건

Distributed Cloud 연결 노드에 Symcloud Storage 설치

Symcloud Storage를 기본 스토리지 클래스로 설정

Symcloud Storage 클래스

robin 스토리지 클래스

robin-immediate 스토리지 클래스

robin-repl-3 스토리지 클래스

워크로드에 추상화된 Symcloud Storage 볼륨 구성

파일 시스템 모드에서 ext4 RWO 볼륨 구성

블록 모드에서 RWO 볼륨 구성

기존 볼륨 구성 수정

Symcloud Storage CLI 클라이언트 구성

StatefulSet에서 스토리지 클래스 참조

statefulset.yaml

Symcloud Storage의 제한사항

클러스터에서 Symcloud Storage를 사용하는 노드 삭제

로컬 스토리지 스키마 구성

로컬 스토리지 스키마의 파티션 정의

로컬 스토리지 스키마 요청

기본 로컬 스토리지 스키마

클러스터에 로컬 스토리지 스키마 적용

문제 해결

PersistentVolumeClaims가 보류 중으로 유지됨

컨트롤 플레인 상태 확인

스토리지 데몬 상태 확인

지원팀에 문의

Distributed Cloud connected 스토리지 구성

`robin` 스토리지 클래스

`robin-immediate` 스토리지 클래스

`robin-repl-3` 스토리지 클래스

파일 시스템 모드에서 `ext4` RWO 볼륨 구성