Kubernetesからディスクリソースをデプロイする

コンテナは起動時の変更を保持しませんが、k8sのVolume機能を利用するとホストのストレージをmountできます。公式リファレンスにサポートしているVolumeのリストがありますが、AWSのEBSやGCPのpersistentDiskなど、クラウドサービスのストレージサービスも実行環境しだいで利用できます。

また、 PersistentVolumeClaimを用いて、リソース作成操作(kubectl create)と連動してpersistentDiskなどを作成することも可能です。

PersistentVolumeClaimは以下のように、StorageClassと容量、ReadWrite設定などを指定します。

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-pvc
spec:
  storageClassName: gcp-persistentdisk
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

StorageClassは利用するディスクの種類に合わせて設定します。以下の例は、GCPのpersistentDiskの例です。

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcp-persistentdisk
provisioner: kubernetes.io/gce-pd
parameters:
  type: pd-standard
  fstype: ext4
  replication-type: none

StorageClassは、サービスごとに利用できるオプションが異なるため、公式リファレンスをもとに利用する設定に応じてmanifestを記述します。

StorageClassとPersistentVolumeClaimをkubectlで作成すると、ディスクが割りあてられ、コンテナのVolumeとして指定可能になります。kubectl get pvcで確認できます。

アクセスモードの注意点

kubernetesのPersistentVolumeClaimのアクセスモードには、ReadWriteOnce / ReadOnlyMany / ReadWriteMany がありますが、事実上の選択肢はあまりないことに注意が必要です。
コンテナがディスクを専有する ReadWriteOnce については問題なく利用できますが、コンテナ間で共有する他のモードには制約があります。

まずReadOnlyManyについては、GCPのpersistentDiskなどもサポートしていますが、WriteノードとReadノードは同時に接続できません。
Writeしたあと接続を解除したうえでReadMany接続です。1ノードだけWriteできれば使いどころは出てくるのですが、コンテンツ更新にメドが立ちづらい点が大きなネックです。

また、ReadWriteManyが実現できれば運用の手間は減るのですが、サポートしているデバイスが限られます。というよりも、ReadWriteManyについては情報がない状態が続いており、ほとんど未知の技術に近いと言えます。
Rookがサポートしている cdphが有力に見えますが、どの環境で動作するのかは不明です。
GKEでは動作しませんでした。ストレージクラスタは問題なく構築できるのですが、ノードイメージにcephが含まれていないためmount時のmodprobeでエラーになります。RBDも必要としているため、この先GKEで動かせる見通しはなさそうです。