この文書は自動機械翻訳技術を使用して翻訳されています。正確な翻訳を提供するように努めておりますが、翻訳された内容の完全性、正確性、信頼性については一切保証いたしません。相違がある場合は、元の英語版英語が優先され、正式なテキストとなります。

これは未公開の文書です SUSE® Storage 1.12 (Dev).

ボリュームの作成

Kubernetesの永続ボリューム（PVs）および永続ボリューム要求（PVCs）に対応するLonghornボリュームの永続ストレージリソースを作成できます。Longhorn StorageClassを使用して、ワークロードのためにストレージを動的にプロビジョニングするためにkubectlを使用します。SUSE Storage UIからボリュームを作成する方法については、このセクションを参照してください。

このセクションでは、Kubernetesの永続ストレージの仕組みを理解していることを前提としています。詳細については、 Kubernetesドキュメントを参照してください。

アクセスモード

SUSE Storageは、次のKubernetes PersistentVolumeアクセスモードをサポートしています：

ReadWriteOnce (RWO)：ボリュームは、単一のノードによって読み書き可能としてマウントできます。同じノード上の複数のポッドがボリュームにアクセスできます。これはデフォルトで最も一般的なアクセスモードです。
ReadWriteOncePod (RWOP)：ボリュームは、クラスター内の単一のポッドによって読み書き可能としてマウントできます。このモードは最も強力な分離を提供し、同時にボリュームにアクセスできるのは1つのポッドのみであることを保証します。単一のライターアクセスを必要とするステートフルワークロードに推奨されます。
ReadWriteMany (RWX)：ボリュームは、複数のノードによって同時に読み書き可能としてマウントでき、複数のポッド間での共有アクセスを可能にします。詳細については、ReadWriteMany (RWX)ボリュームを参照してください。

ReadOnlyMany (ROX)はサポートされていません。複数のポッドからの読み取り専用アクセスには、ポッド仕様で読み取り専用マウントオプションを使用した ReadWriteMany を使用してください。

kubectl を使用して Longhorn ボリュームを作成します。

最初に、Longhorn StorageClass を作成する必要があります。Longhorn StorageClass には、PV をプロビジョニングするためのパラメータが含まれています。

次に、StorageClass を参照する PersistentVolumeClaim が作成されます。最後に、PersistentVolumeClaim がポッド内のボリュームとしてマウントされます。

ポッドがデプロイされると、Kubernetes マスターは PersistentVolumeClaim を確認し、リソース要求が満たされるかどうかを確認します。ストレージが利用可能な場合、Kubernetes マスターは Longhorn ボリュームを作成し、それをポッドにバインドします。

次のコマンドを使用して、longhorn という名前の StorageClass を作成します：
```
kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.12.0/examples/storageclass.yaml
```
次の例の StorageClass が作成されます：
```
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""
  fsType: "ext4"
#  backupTargetName: "default"
#  mkfsParams: "-I 256 -b 4096 -O ^metadata_csum,^64bit"
#  diskSelector: "ssd,fast"
#  nodeSelector: "storage,fast"
#  recurringJobSelector: '[
#   {
#     "name":"snap",
#     "isGroup":true,
#   },
#   {
#     "name":"backup",
#     "isGroup":false,
#   }
#  ]'
```
パラメータ mkfsParams は、各 StorageClass のファイルシステムフォーマットオプションを指定するために使用できます。

パラメータ backupTargetName は、バックアップ先を指定するために使用できます。デフォルトのバックアップ先 (default) の名前が、backupTargetName が指定されていない場合に使用されます。

パラメータは StorageClass の仕様から省略することができます。StorageClass を使用して PV とボリュームを作成する際に、指定されていないパラメータは一般的にグローバル設定から取得したデフォルト値を使用して設定されます。グローバル設定の完全なリストについては、StorageClass パラメータおよび設定を参照してください。

このコマンドを実行して Longhorn ボリュームを使用するポッドを作成します：

kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.12.0/examples/pod_with_pvc.yaml

volume-test という名前のポッドが起動され、longhorn-volv-pvc という名前の PersistentVolumeClaim も起動されます。PersistentVolumeClaim は Longhorn StorageClass を参照します：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: longhorn-volv-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 2Gi

PersistentVolumeClaim はポッド内のボリュームとしてマウントされます：

apiVersion: v1
kind: Pod
metadata:
  name: volume-test
  namespace: default
spec:
  containers:
  - name: volume-test
    image: nginx:stable-alpine
    imagePullPolicy: IfNotPresent
    volumeMounts:
    - name: volv
      mountPath: /data
    ports:
    - containerPort: 80
  volumes:
  - name: volv
    persistentVolumeClaim:
      claimName: longhorn-volv-pvc

より多くの例はこちらで利用可能です。

ワークロードをKubernetesのStorageClassなしでPVsにバインドする

StorageClassオブジェクトをKubernetesで作成せずに、Longhorn StorageClassを使用してワークロードをPVにバインドすることが可能です。

StorageClassはPVCとPVを一致させるために使用されるフィールドでもあるため、Provisionerによって作成される必要はなく、カスタムStorageClass名でPVを手動で作成し、同じStorageClass名を要求するPVCを作成することができます。

PVCがKubernetesリソースとして存在しないStorageClassを要求すると、KubernetesはPVCを同じStorageClass名のPVにバインドしようとします。StorageClassはラベルのように使用され、一致するPVを見つけるために使用され、StorageClass名でラベル付けされた既存のPVのみが使用されます。

PVCがStorageClassを指定した場合、Kubernetesは：

StorageClassに一致するラベルを持つ既存のPVを探します。
既存のStorageClass Kubernetesリソースを探します。StorageClassが存在する場合、それを使用してPVを作成します。

Longhorn UIを使用してLonghornボリュームを作成する

PV/PVCを作成する際にLonghornボリュームがすでに存在するため、Longhornボリュームの動的プロビジョニングにはStorageClassは必要ありません。ただし、PVCバインディングの目的で使用するために、PVC/PVにフィールド`storageClassName`を設定する必要があります。ユーザーが関連するStorageClassオブジェクトを作成する必要はありません。

デフォルトでは、Longhornで作成されたPV/PVCのStorageClassは`longhorn-static`です。ユーザーは必要に応じて`Setting - General - Default Longhorn Static StorageClass Name`でそれを変更できます。

ユーザーはSUSE Storageによって作成されたPVCとPVを手動で削除する必要があります。

既存のLonghornボリュームのPV/PVC作成

現在、ユーザーは既存のLonghornボリュームのために、私たちのLonghorn UIを通じてPV/PVCを作成できます。新しく作成されたポッドは、切り離されたボリュームのみを使用できます。

Longhornボリューム作成のエラー

Longhornボリュームの作成は、さまざまな理由でエラーになる可能性があります。問題は次のように分類されています：

ストレージ不足
ディスクが見つかりません
ディスクが利用できません
タグが満たされていません
ノードが見つかりません
ノードが利用できません
ノード候補のいずれにも準備完了のエンジンイメージが含まれていません
ハードアフィニティを満たすことができません
レプリカのスケジューリングに失敗しました
未使用の失敗したレプリカはサポートされていません
レプリカはすでにスケジュールされています
Longhornクライアント操作に失敗しました
互換性のないボリュームサイズ

このエラーにより、ワークロードがプロビジョニングされたPVを使用できず、警告メッセージが表示されます。

# kubectl describe pod workload-test

Events:
  Type     Reason              Age                From                     Message
  ----     ------              ----               ----                     -------
  Warning  FailedAttachVolume  14s (x8 over 82s)  attachdetach-controller  AttachVolume.Attach
  failed for volume "pvc-e130e369-274d-472d-98d1-f6074d2725e8" : rpc error: code = Aborted
  desc = volume pvc-e130e369-274d-472d-98d1-f6074d2725e8 is not ready for workloads

ユーザーがエラーの原因を理解できるように、SUSE StorageはそれらをPVアノテーション`longhorn.io/volume-scheduling-error`に要約します。エラーはこのアノテーションにまとめられ、セミコロンで区切られます。例えば、`longhorn.io/volume-scheduling-error: insufficient storage;disks are unavailable`のようになります。アノテーションは`kubectl describe pv <pvc name>`を使用して確認できます。

# kubectl describe pv pvc-e130e369-274d-472d-98d1-f6074d2725e8
Name:            pvc-e130e369-274d-472d-98d1-f6074d2725e8
Labels:          <none>
Annotations:     longhorn.io/volume-scheduling-error: insufficient storage
                 pv.kubernetes.io/provisioned-by: driver.longhorn.io

...